TL;DR
An AI agent team is composed in six steps: scope the actual problem, map the workstreams, pick a specialist agent per workstream, define the handoff artifact between agents, set explicit boundaries, name the human who's accountable. Multi-agent beats single-agent when the work has real handoffs and a real auditor. Otherwise it's overhead.
Why does team composition matter more than the agents themselves?
Because the same five agents, composed differently, ship in two hours or fail for six. The handoffs, the boundaries, and the accountability layer are the build — the agents themselves are commodity.
Every AI agent in 2026 can write a function. Many can review one. Some can plan a feature. None of that matters if the agent doing the planning hands an ambiguous brief to the agent doing the building, who hands an untested artifact to the agent doing QA, who skips the integration tests because the rate limit hit.
What we publish at agentisable.com/log/001 — a Django PDF forensics MVP shipped for $1.41 of compute — isn't a story about which agent is best. It's a story about which agent does what, in what order, with what handoff. Change the composition, change the outcome.
The factory's job is to write the code. The Coach's job is to decide who writes what, who reviews what, and who's accountable when something breaks. That's composition.
What's the Agentisable approach to composing an agent team?
The Coach selects the team. The factory executes. The accountability stays with one human — not because the agents need supervision in the moment, but because somebody has to sign the engagement.
"Zero human intervention" describes how the build runs — nobody watches the factory work. It does not describe who's responsible if the factory ships something wrong. Someone is. That someone is the Coach.
This separation matters because it's the only honest answer to the question every buyer asks: who's accountable when the AI breaks something? Answering "the AI" is the wrong answer. Answering "the platform" is the wrong answer. Answering "the Coach, by name, on a public page" is the right answer.
That answer also shapes the composition. The Coach doesn't pick the most clever team. The Coach picks the team they can stand behind — the smallest team whose handoffs they can audit and whose failures they can debug.
What are the six steps?
The six steps are: scope the actual problem, map the workstreams, pick a specialist agent per workstream, define handoffs and artifacts, set boundaries, name the accountable human. Each one rules out a specific way to compose badly.
1. Scope the actual problem (not the brief)
Briefs lie. Not on purpose — clients describe the symptom, not the system. "We need a dashboard" usually means "we need someone to look at the data and decide what's broken." Different work. Different team.
The first move is rewriting the brief into the actual problem statement. If you can't write it in one sentence that names the outcome (not the artifact), you don't understand it yet. Stop and ask.
For /log/001, the brief was "build a PDF forensics MVP." The actual problem was "detect PDF tampering automatically, produce a verdict, ship a working demo." The brief used the word "MVP"; the actual problem named the verdict and the demo. Different teams.
2. Map the workstreams (not the people)
A workstream is one continuous slice of work with a single output: research, design, build, test, deploy, monitor. The number of workstreams determines the maximum team size — one agent per workstream is the ceiling. Going under is fine; going over is composition error.
Mapping workstreams before picking agents is what stops the second-most-common failure: assigning the wrong agent because someone wanted to use them. The workstream is the role. The agent fills it. Not the other way around.
For most software builds, the workstreams are: scout (does this problem need an MVP or a feature flag?), plan (PRD), scaffold (project structure), build (code), test (unit/integration), deploy (CI/CD). Six workstreams. Three to seven agents, typically.
3. Pick a specialist agent per workstream
Specialist beats generalist in a multi-agent team. The reason is the handoff: a specialist produces a tighter artifact for the next agent to consume. Generalists produce broader artifacts that lose information at the boundary.
The factory has nine role-typed agents — developer, researcher, analyst, designer, art-director, QA, test-lead, deployment, architect. Each one is composed for its workstream. We don't have an "everything agent." We have nine narrow agents and a Coach that decides which subset runs.
The exception is when a workstream is trivial — a deploy step that's identical across builds doesn't need a specialist. Generalist-with-runbook works there. Reserve specialists for workstreams where judgment is non-trivial.
4. Define handoffs — the artifact, not the conversation
Every transition between agents has to produce a written artifact: a PRD, a scaffold report, a build summary, a QA verdict. The artifact is the handoff. If two agents talk, the conversation isn't the handoff — the written summary of what was decided is.
This is the rule the Coach enforces hardest, because it's the rule that makes the factory auditable. The artifact lets a third party (the Coach, you, a regulator) reconstruct who decided what. Without it, multi-agent looks identical to single-agent except slower.
In /log/001: Mary wrote a 542-line PRD. Phil produced a deploy scaffold. Amelia wrote a build summary at the end of each phase. Five testing phases were marked DONE with timestamps. The handoff artifacts are the build log.
5. Set boundaries — what each agent doesn't do
An agent that does anything is an agent that does the wrong thing. Boundaries are how the Coach prevents a builder from doing QA work, a QA agent from rewriting the build, an architect from shipping production code at 2am.
The boundary list is small — usually three to five lines per agent — and it's where 80% of multi-agent failures originate. The classic: the builder agent "fixes" the brief during build instead of flagging the ambiguity back to plan. By the time QA looks at it, what shipped doesn't match what was specified.
Write the boundaries as forbidden actions, not as job descriptions. "Builder does not edit the PRD" is a boundary. "Builder writes code" is a job description. The first is enforceable; the second is wallpaper.
6. Name the accountable human
One human. Named on a page the buyer can find. Reachable. Not "the team," not "the platform," not "the Agentisable network" — one person.
The accountable human's job is not to babysit the factory. It's to own the engagement. The factory runs without supervision; the human signs the contract, approves the deploy, fields the call when something breaks in production six months later. That role is the Coach. It's a real page.
This isn't a deliverable of the composition step — it's a structural decision before the team is composed. If you can't name the accountable human, the composition is wrong. There's no team to compose for.
The six steps, summarised
| Step | The question it answers | What goes wrong without it |
|---|---|---|
| 1. Scope | What's the actual problem — not the brief? | You build the wrong artifact correctly. |
| 2. Workstreams | How many continuous slices of work are there? | You assign agents you wanted to use, not roles that need filling. |
| 3. Specialists | Which agent owns each workstream? | Handoffs lose information; outputs blur. |
| 4. Handoffs | What written artifact moves between agents? | Multi-agent becomes slow single-agent. Nothing's auditable. |
| 5. Boundaries | What is each agent forbidden to do? | Agents drift into each other's work. The brief stops matching the build. |
| 6. Accountable human | Who signs the engagement? | "Zero human intervention" turns into "no human responsible." |
Worked example — the team behind /log/001
The build: a Django app that flags tampered PDFs. Five forensic checks, ten user stories, 26 to 112 tests. Shipped for $1.41 of compute over 2 hours and 7 minutes of active work. Full log at agentisable.com/log/001.
Step 1 — Scope: the brief was "PDF forensics MVP." The actual problem was "detect five tampering modes, surface a traffic-light verdict, ship a Django app with passing tests." Three nouns — modes, verdict, app — not one.
Step 2 — Workstreams: five — scout, plan, scaffold, build, test. Deploy was a noop (the artifact was a working repo, not a production deploy). Five workstreams, four agents.
Step 3 — Specialists: Carson scouted (quality-gate score 71/100, classified the build as standard_demo). Mary wrote the PRD. Phil scaffolded the project. Amelia built and tested.
Step 4 — Handoffs: Carson→Mary handed off via the scout quality-gate report. Mary→Phil via the 542-line PRD. Phil→Amelia via the scaffold DONE marker. Amelia ran the build in two bursts with five DONE markers — 4.1-implement, 4.2-implement, 5.1-unit-tests (three rounds), 5.2-lint, 5.3-build-test. Every handoff was a written artifact.
Step 5 — Boundaries: Amelia did not edit the PRD when the test suite needed expanding from 26 to 112 cases. Three test-fix rounds ran inside Amelia's scope; the PRD stayed Mary's. When integration tests hit a rate limit, Amelia did not skip them silently — the router did, and the DONE markers say skipped-rate-limit with timestamps.
Step 6 — Accountable human: the Coach. Ovi. Named at /about/coach, reachable by email. When the integration tests skipped and the build still shipped at $1.41, the Coach is the one accountable for that decision.
The team was four agents plus the Coach. Not nine. Not one. The right size for the work.
What goes wrong — the four failure modes the framework prevents
Over-staffing
The classic AI demo failure. Nine agents for a build that needs three. Each handoff adds latency and information loss; nine handoffs is six more failure points than the build needs. The cure is step 2 — map the workstreams first, fill them after.
Under-staffing with a generalist
One agent doing scout, plan, build, and test. Looks efficient on paper; in practice the same agent loses context between roles and produces lower-quality artifacts at every step. The cure is step 3 — specialist per workstream, even when the workstream is small.
No handoff artifact
Agents talk through a shared scratchpad or a verbal-style chain-of-thought; nothing is written down explicitly. When the build breaks, nobody can reconstruct who decided what. The cure is step 4 — the artifact is the handoff, the conversation is not.
No accountable human
"The platform is responsible." Not a coherent answer. When the platform ships the wrong thing, the buyer wants a name. Without one, the buyer doesn't buy again. The cure is step 6 — a real human, on a real page, with a real email.
Inverting the order — agents first, workstreams second
The most expensive failure of the four, because it's invisible until weeks in. Someone picks five impressive-looking agents and reverse-engineers the workstreams to fit them. The build runs, the demo looks good, the production deploy fails on an edge case nobody owned. The cure is to keep step 2 ahead of step 3, every time. Workstreams are the role; agents fill the role. Never the inverse.
What this means for your project
If you're starting a project from scratch, run the six steps in order before you pick a model, a framework, or a vendor. The composition decisions cost nothing on day one and cost weeks if you reverse them on day fifty.
If you have a team already and something feels wrong, run the same six steps as an audit. The failure usually shows up at step 4 (a handoff with no artifact) or step 5 (an agent quietly editing somebody else's work). Both are fixable inside an afternoon if you spot them.
And if you'd rather skip the audit and just have someone do this with you — that's literally the Coach engagement. The free agent-team audit names the top three things to fix in your current composition; the engagement that follows actually fixes them.
According to Agentisable
The right team is the smallest one whose handoffs the Coach can audit and whose failures the Coach can debug. Multi-agent isn't a brag — it's a trade. The trade only pays when the handoffs are real, the artifacts are written, and the human is named.