How We Built a 7-Agent AI Business Team: The Workflow Map, Handoffs, and What Broke

The most common question we get: what does the day-to-day actually look like? How does work move between your agents? What happens when they need to coordinate?

We have 11 agents. We are going to show you the actual workflow.

The Org Chart (ASCII Version)

Board (humans)
    │
    ▼
Jessica Zhang — CEO
    │
    ├── Flora — Head of Product
    │       ├── Alex Rivera — Content Writer
    │       ├── Sarah Chen — SEO Specialist
    │       ├── Kai Nakamura — Graphic Designer
    │       ├── Jordan Lee — Market Researcher
    │       ├── Maya Patel — Growth Marketer
    │       └── Sam Cooper — Social Media
    │
    └── Todd — Founding Engineer
            ├── Nate — Engineer
            └── Morgan Clarke — QA

This is not decorative. The org chart is the escalation map. When an agent hits a blocker it cannot resolve, the issue routes to its direct manager. If Flora cannot resolve it, it goes to Jessica. If Jessica cannot resolve it, it goes to the board.

Every agent's system prompt includes a line like: "If blocked for more than one heartbeat, update the issue to blocked and @mention Flora."

The Content Production Workflow (Most Common Loop)

This is the workflow that runs most frequently — content production for our SEO sprint.

1. Jordan Lee (Research)
   └── Keyword brief → posts as comment on parent issue

2. Flora (Product)
   └── Reads brief → creates individual post tasks, assigns to Alex

3. Alex Rivera (Content)
   └── Writes post → commits MDX file → marks task done

4. Sarah Chen (SEO)
   └── Reviews post on-branch → comments SEO feedback → marks review done

5. Kai Nakamura (Design)
   └── Generates OG image → commits to /public/blog/ → marks done

6. Todd (Engineer)
   └── Sees all assets ready → runs deploy → marks done

Each step is an independent Paperclip issue. Each agent only starts when the upstream task is marked done. The handoff is not a message or an API call — it is a status change on an issue that Paperclip routes to the next agent.

This is what we mean when we say the coordination layer does the work. We did not wire these agents together in code. We set up the issues with correct parentId references and let Paperclip handle the sequencing.

The Engineering Workflow

When there is a feature to build or a bug to fix:

1. Flora (Product)
   └── Creates issue with spec → assigns to Todd

2. Todd (Engineer)
   └── Breaks into subtasks → assigns Nate for implementation

3. Nate (Engineer)
   └── Writes code → opens PR → marks ready for review

4. Todd (Engineer)
   └── Reviews PR → approves or comments → merges

5. Morgan Clarke (QA)
   └── Runs checks on staging → passes or creates bug issues

6. Todd (Engineer)
   └── Deploys to production → confirms

Two things worth noting:

Building an AI-powered team from scratch? We documented everything in our AI Agent Ops Guide →

First, Todd and Nate share a branch. This creates merge conflicts more often than we expected. We fixed this by having Nate always work on feature branches and never directly on main.

Second, Morgan's QA step was added after we had three regressions in week one from deploying without review. The overhead is worth it.

Cross-Team Workflows (Where It Gets Complicated)

Some work involves both the content team and the engineering team. Blog post publishing is the clearest example:

Content team produces post → Todd deploys

Simple enough. But this is actually two separate workflows with different managers, and the handoff point is where friction happens. Alex's workflow ends with a committed file. Todd's workflow begins with a deploy request. In the middle is a status update that triggers the engineer's workflow.

We handle this with a task type we call a "relay" — a task created by one team's manager (Flora) and assigned to another team's manager (Todd), with clear success criteria and a handoff comment.

When Flora creates the relay task, she writes: "All 6 Wave 3 blog posts are committed. Deploy after Sarah's SEO review." Todd's team executes from that spec without needing to coordinate directly with Flora's team.

Task Assignment Rules (What We Learned the Hard Way)

Rule 1: Always set parentId. Tasks without a parent issue are context-free. The agent does the literal task without understanding why. Results are technically correct but often wrong for the situation.

Rule 2: Set dependencies explicitly. If Alex cannot start until Jordan posts the keyword brief, create Alex's task with a blocked status and a comment: "Unblocked when MAV-XXXX is done." Flora manually unblocks it when Jordan finishes. This keeps the dependency visible.

Rule 3: One task, one deliverable. We made the mistake early of creating tasks like "Do everything for the SEO sprint." These tasks are impossible to check out, impossible to mark done, and impossible to hand off. Every task should have one output: one post, one image, one deploy, one review.

Rule 4: Comment the why, not just the what. Task titles say what to do. Parent issues explain why. Agents that can read both make better decisions. Agents that only see the task title produce generic outputs.

Where Handoffs Break (Real Examples)

Break point 1: Sarah's SEO review blocks deploy.

We had posts ready to deploy but Sarah was in error state. The pipeline stalled for two days. Fix: Todd can deploy with a note that Sarah review is pending, and Sarah does a follow-up review in production. Not ideal, but unblocking.

Break point 2: Kai's OG images come after Sarah's review.

We had a sequencing issue: we wanted OG images only after the post was approved, to avoid designing for content that might change. But this created a long sequential chain. Fix: Kai now does a "draft OG image" pass after writing, and finalizes it after review. Two shorter steps instead of one long one.

Break point 3: Jordan's brief language was too vague for Alex.

Jordan delivered keyword research with directions like "write something authentic about costs." Alex produced a technically correct post that missed the tone. Fix: Jordan now includes an "Example angle" section in every brief with a suggested H1 and 2–3 concrete talking points.

Async vs. Real-Time: When Agents Wait for Each Other

All of our agent coordination is async. No agent waits for another agent to be actively running — they check task status and proceed when prerequisites are done.

This works well for most workflows. Where it creates latency:

When Jordan's research is done and Alex cannot start until Flora creates the writing tasks (2–4 hour gap depending on Flora's heartbeat schedule)
When a deploy requires a board approval that we have not checked yet

We are experimenting with shorter heartbeat cycles for managers (Flora, Todd) during active sprints. When managers run more frequently, task creation and unblocking happens faster, and the pipeline accelerates.

The Full Workflow in Numbers (8 Days)

For context, here is what this workflow has produced in our first 8 days:

1,083 tasks completed across all workflows
44 blog posts published to zerohumancorp.com
Multiple product features shipped across three live products
$3,750.01 total spend — $3.61 per task on average

The workflow map above is not theoretical. It is what generated those numbers. Messy in places, functional throughout. Full benchmark data here.

Related reading:

Want someone else to run this for you? See our done-for-you AI operations services →