Multi-agent software development works better as a pipeline of durable artifacts with narrow roles, human gates and a visible cost ceiling than as a shared chat. That is the argument in Palahepitiya Gamage Amila's write-up, The operating model behind a multi-agent engineering team, published on 02/10/2026. If you run a thin bench and are weighing agents to add delivery capacity, the operating model matters more than the number of agents.
This article restructures the author's model for a seed-stage or early Series A CTO. Every claim about the experiment belongs to the author, not to WireApps.
Why does a shared agent chat break down?
The author's starting point is that demos of multi-agent systems look like a chat room. In that setup, memory is shared and fuzzy, and nobody can point to the contract that was meant to constrain the next step. Two agents can invent different scopes for the same ticket.
The author's answer is to change the source of truth. It is the latest approved plan, plus the findings that forced a re-plan, plus the review against the contract. Chat is not the ledger.
How does a piece of work move through the pipeline?
The source describes a sequence with a human gate in the middle:
Request
Route
Plan
Challenge
Human approval
Execute
UI QA
Review
Final approval
Each stage produces an artifact that the next stage consumes. The plan is a document, not a conversation. The challenge is a written finding, not an impression. Nothing is executed until a person has approved the plan, and nothing ships until a person has approved the result.
Which roles does a multi-agent pipeline need?
The author describes eight roles. The table below summarises each with its boundary, in our wording.
Role | Job | Boundary |
|---|---|---|
Orchestrator | Makes one shallow classification and routes the request | Must not design the solution |
Planner | Writes the plan as a contract: scope, acceptance criteria, assumptions, estimated tokens and time, cost ceiling and stop conditions | Never executes its own plan |
Challenger | Attacks the plan and returns findings only | A critical finding blocks the plan until it is revised; must not patch the plan |
Human gate | Approves the plan before execution and the result after | Gates do not silently expire; the queue shows blocked work rather than inventing consent |
Executor | Follows the approved steps and logs transitions | Stops at the cost ceiling; scope creep is a re-plan request |
UI QA | Checks the build against the design using screenshots or the live UI | Critical UI findings block |
Reviewer | Compares the result with the plan and returns read-only findings | Critical divergence goes back to planning |
Verification (on demand) | A side skill that returns bounded, checked facts and sits beside Execute | Makes no product or delivery decisions |
The recurring rule is separation. The agent that proposes is not the agent that challenges, and the agent that builds is not the agent that reviews. The source also describes heavier models on planning and challenge and lighter models on approved execution. We report that as the author's design, not as a recommendation.
What did a three-day run cost?
The author reports a run of roughly three days, with about 1,000 recorded requests and about 126.8 million tokens. It spanned GLM, DeepSeek and Qwen, and came to under 40 USD, roughly.
Read that as one author's single gateway export, not a benchmark. It says nothing about a different team, stack or workload. Your token mix, repository size and review depth will move the figure in either direction. The point in the source is that you need to see spend before the next step runs, and stop at the ceiling.
What can a seed-stage CTO copy this week?
The write-up supports six practices that need no special tooling:
Written boundaries. State what each agent may touch and what it may never touch. Put it in a file, not in a prompt you retype.
One-page role profiles. For each role, write the mission, inputs, outputs, forbidden actions, escalation rule and a success test. If you cannot write the success test, the role is not narrow enough.
One model registry. Keep a single list mapping roles to models, so changing a model is an edit in one place rather than a hunt through prompts.
The plan as a durable artifact. Attach a cost ceiling and a named human gate to every plan. The approver is named, so approval is never ambient.
A small handoff schema. Define the few fields every handoff must carry. Keep it small enough that agents and humans both follow it.
The smallest useful observability. Record enough to answer what ran, what it cost and who approved it. Add more only when a question demands it.
What should you measure in a pilot?
Start with a narrow workload and track five things:
Re-plans: how often a plan returns to the planner. A high count points to unclear requests or weak role profiles.
Blocked findings: how often the challenger stops a plan. Zero can mean the challenger is toothless, not that the plans are good.
Review defects: what the reviewer catches after execution. This shows whether the plan and challenge stages are doing their job.
Time to approval: how long plans wait at the human gate. This is your bottleneck indicator.
Spend: cost per approved plan against the ceiling you set.
These are our suggested pilot metrics, built on the author's structure. They are not figures from the write-up.
What this does not tell you
The source is one practitioner's account of one run. It does not show how the pipeline behaves on a large legacy codebase, under regulated change control, or with a team that has never worked with agents. It does not establish that the model split is optimal, or that the cost would hold at your volume. Treat it as a well-structured starting hypothesis and test it on a contained piece of work before you widen it.
Where an embedded pod fits
Putting these boundaries and gates in place lands on the person who is already stretched. Senior engineers, in pods of 3 to 8, embedded in your workflow can help a CTO write the role profiles, set the gates and wire up the handoffs, with the CTO keeping control of the product. Production Claude-integrated AI agents have been running in WireApps client products since 2024.
For related reading, see our practical guide to AI agent integration, how a seed-stage CTO stops being the bottleneck, and what a technical readiness report covers.
If you want to pressure-test your own operating model, Book a Strategy Call on the WireApps website.
FAQs
Is multi-agent software development just several chatbots in one thread?
No. In the author's model each agent has a narrow role and passes a written artifact to the next stage. The structure is the point, not the agent count.
Does the human gate slow delivery down?
It adds a stop, but one approval on a one-page plan is far cheaper than untangling a run that went the wrong way. Track time to approval so the gate does not become the new bottleneck.
Can I use the 40 USD figure to budget my own pilot?
No. It comes from one author's single gateway export over roughly three days. Set your own cost ceiling per plan and measure against it.
Which models should I use?
The source describes heavier models on planning and challenge and lighter models on approved execution. That is the author's design. Keep your own model registry and test against your workload.
For the full account, read Palahepitiya Gamage Amila's The operating model behind a multi-agent engineering team (02/10/2026).
Share
