Adding agents does not create an agent team.
It creates more actors that can produce work, pass work, duplicate work, and occasionally make the same mistake at higher speed.
The useful question is not, “How many agents can we run?” It is, “What happens when one agent is uncertain, wrong, blocked, or outside its authority?”
If the answer is vague, the business does not have a digital workforce. It has a collection of automations with no operating discipline.
A current Cockroach Labs case offers a better model. The company describes a five-month coding-agent pipeline organised like a teaching hospital. Issues became patients. Agents took distinct roles for triage, diagnosis and planning, implementation, review, and discharge. Other agents watched for stuck work, locked down the workflow when the main branch broke, and reviewed process failures.[1]
That structure matters more than the metaphor. Each role had a defined job. Reviewers could reject work. Failed checks sent work backwards. Difficult cases moved up an escalation path. Humans did not supervise every routine action, but they owned the standards and the exceptional cases.
The result was not a straight line
In Cockroach Labs’ reported Db2 migration case, one GitHub issue eventually became 32 sub-issues and 27 merged pull requests. Reviewers sent work back 55 times. Nine issues were escalated, including two that reached a human.[1]
Those figures should change how leaders think about agent performance.
Fifty-five send-backs are not automatically evidence of failure. They can be evidence that the operating system is catching incomplete or weak work before release. Two human escalations are not proof that the agents lacked autonomy. They show that the team had a threshold for handing judgment to someone accountable.
Cockroach Labs also reports major speed and cost differences against an earlier Oracle-support project. Those figures come from one company’s software-engineering case. They are not a universal benchmark for finance, sales, operations, or customer service, and they should not be treated as a forecast for every SME.[1]
The transferable lesson is the shape of the work: defined roles, explicit evidence, independent review, send-back loops, and named owners for exceptions.
Build five stages before you add five agents
An SME can apply the same logic without copying a software team or inventing a complicated agent architecture.
Start with one recurring workflow. Customer onboarding, invoice processing, lead qualification, stock replenishment, and service-ticket resolution are all suitable examples.
Then design five stages.
1. Intake
The intake role receives the case and checks whether it belongs in the workflow.
It should confirm the required inputs, identify missing data, classify urgency, and reject obviously invalid requests. It should not begin execution when the case is incomplete.
For an invoice workflow, intake might confirm the supplier, purchase order, invoice amount, tax fields, and supporting documents. Missing evidence goes back to the requester instead of being guessed.
2. Workup
The workup role investigates the case and proposes what should happen.
This is where the agent gathers context, compares the request with policy, identifies dependencies, and records assumptions. It should produce a short plan before any consequential action.
The plan can be simple: what the agent found, what it intends to change, what evidence supports the change, and what could go wrong.
3. Review
The reviewer is not another copy of the worker.
Its job is to find faults: missing evidence, policy conflicts, unsupported assumptions, incorrect totals, weak tests, or scope changes. The reviewer needs the authority to reject the plan or completed work.
This separation is important. If the same agent defines the plan, executes it, and approves it, the business has created a fast path around its own controls.
4. Send back or escalate
Not every problem needs a human.
If the failure is routine and repairable, send it back with a clear reason. Ask for the missing document, rerun the calculation, correct the field, or narrow the scope.
Escalate when judgment, permission, or risk exceeds the agent’s role. Examples include an invoice above an approval limit, a discount outside policy, a customer complaint involving legal exposure, or a system change that could affect production.
The escalation should arrive as a decision package, not a vague alert. Include the case, the evidence, the failed rule, the options, and the recommended next action.
5. Release
Release is a separate decision.
The release role checks that approval exists, required tests passed, records are complete, and rollback is possible where needed. Only then should the workflow update the ERP, send the email, approve the payment, publish the page, or close the ticket.
A completed task is not the same as an authorised outcome.
Write the escalation ladder down
An escalation ladder should not live inside a prompt or in one employee’s head.
For each exception, define five things:
| Field | Question to answer |
|---|---|
| Trigger | What condition stops normal execution? |
| Evidence | What facts, records, logs, or failed checks must accompany the escalation? |
| Receiving owner | Which named role decides what happens next? |
| Permitted action | What may the agent do while waiting, and what is forbidden? |
| Release or rollback condition | What evidence allows work to resume, or requires the last action to be reversed? |
Take a lead-qualification workflow. A normal lead may move from enrichment to scoring to a draft response. A lead involving an existing strategic account might trigger escalation. The agent can prepare the account history and recommended response, but it cannot send the message until the account owner approves it.
The same pattern works in finance. An agent can match invoices and prepare a payment batch. A duplicate invoice, changed bank account, missing purchase order, or amount above threshold should stop the flow and route a complete evidence package to the finance owner.
This is what practical human oversight looks like. The human is not watching every click. The human appears at a designed decision point with enough evidence to make the decision.
The Agent Boss designs the work
The manager of an agent team should not spend the day distributing small tasks to bots.
The higher-value job is to define the work boundaries:
- what counts as a complete input;
- what evidence a worker must produce;
- who can reject the work;
- which exceptions need human judgment;
- what conditions permit release;
- and how failures improve the process next time.
That is the Agent Boss role. It is less about supervising activity and more about designing a reliable division of labour.
More agents can increase throughput. They can also increase handoffs, inconsistency, and review load. Agent count is therefore a poor maturity measure.
A better measure is whether the team can answer these questions:
- Who owns the case now?
- What evidence must they produce?
- Who can send it back?
- What triggers human escalation?
- Who is accountable for release?
If those answers are clear, the business can expand the team with discipline.
If they are not, adding another agent will not solve the operating problem. It will only give the confusion another worker.
Sources
[1] https://www.cockroachlabs.com/blog/experiment-running-hospital-code — Five months treating bugs like patients and coding agents like a medical team