Agentic Delivery Notes
Too Many Agents, Too Little Delivery
Why an AI organization chart is not an operating model.
Agent count can increase faster than accepted output. This field note explains how to recognize the failure and redesign the workflow around the smallest accountable team.
Central thesisMore agents do not automatically create more delivery capacity. They also create coordination, context, handoff, review, authority, and verification costs.
The argument in one view
A clearer path from role-first structure to accepted output.
The operating model I now use to keep agent-assisted work accountable to delivery.
- 01Define the deliverable
Start with the result a person or downstream system must be able to inspect and use.
- 02Add defensible boundaries
Separate work only for a distinct capability, context, permission or evaluation need.
- 03Keep synthesis accountable
Give one owner responsibility for resolving conflicts and assembling the result.
- 04Test accepted output
Measure whether the final artifact passes its acceptance test, not how many roles were active.
- Distinct inputCapability or constraint
A specialist adds something the orchestrator cannot reliably supply alone.
- Accountable synthesisOne integrated deliverable
An owner resolves conflicts and assembles the work into a coherent result.
- Explicit acceptanceTested and owned
The result passes a defined check and reaches a named decision owner.
More roles are not the outcome. A stronger acceptance chain is.
Failure signals
Diagnose the delivery system, not the agent count
An agent count alone cannot diagnose a workflow. A four-agent system with clean boundaries may outperform one overloaded orchestrator; a two-agent system can still loop indefinitely. The useful evidence is behavioral. Look for the relationship between coordination work and accepted output.
- 01More plans exist than completed artifacts.
- 02The same context is repeatedly restated or rediscovered.
- 03Reviews begin before a reviewable artifact exists.
- 04Recommendations conflict without one accountable synthesizer.
Root cause
The operating model was defined in the wrong order
- 01
Outcome defined after roles
The roster was designed before the accepted result and intended user were explicit.
- 02
Handoffs defined before contracts
Responsibilities sounded distinct, but required inputs, outputs, and formats were not.
- 03
Reviews defined before acceptance
Reviewers were added before the system defined what passing, revising, blocking, or abstaining meant.
From a role-first hierarchy to an outcome-first delivery path
The before model adds layers between the owner and acceptance. The after model gives one orchestrator the synthesis path, adds specialists only at a defensible boundary, and ends with an explicit verification decision.
Decision tree
Do you need another agent?
Follow the “yes” path downward. A “no” answer identifies the work to do before adding another agent.
No new agent without a distinct boundary, an output contract, an acceptance test, and an accountable synthesizer.
- 01Is there a concrete deliverable and acceptance test?YesContinue to the next question↓No
Define the result and how it will be accepted before designing roles.
- 02Does the work cross a distinct capability, context, permission, execution, or evaluation boundary?YesContinue to the next question↓No
Keep the work with the accountable orchestrator.
- 03Can the boundary have an explicit input, output, authority, and verification contract?YesContinue to the next question↓No
Clarify the contract before adding another worker.
- 04Will the boundary improve accepted delivery enough to justify coordination and verification cost?YesContinue to the bounded-agent decision↓No
Prototype or measure the bottleneck before making the role permanent.
YesAdd a bounded specialist. Give it a clear contract, one accountable synthesizer, an explicit verifier, and a named decision owner to accept the result.
Measurement
Measure delivery outcomes, not agent activity
Agent count, run count, token volume, generated documents, reviews, and status updates can describe system activity. Used alone, they cannot tell you whether the requested result became usable. A workflow can generate ten documents and still leave the owner without one decision-ready artifact.
Context only
Weak when used alone
- Number of agents
- Number of runs
- Token volume
Outcome oriented
Measure the path to acceptance
- Accepted deliverables per week
- Counts results that passed the defined acceptance test and are usable.
- Median request-to-acceptance time
- Measures the full delivery path, including handoffs and rework.
- First-pass acceptance rate
- Shows whether framing, execution, and validation align before revision.
Methods, limitations and evidence boundary
I wrote this note from my delivery experience. It offers a diagnosis to test: compare accepted output and coordination cost before changing the team’s structure.
Methods, limitations and evidence boundary
I wrote this note from my delivery experience. It offers a diagnosis to test: compare accepted output and coordination cost before changing the team’s structure.
Start with the deliverable, the accountable owner, and the acceptance test. Add another agent only after the work proves that a real boundary exists.
Before creating another agent, remove every role name from the workflow diagram. Label each box only with its required input, output, authority, and acceptance test. Any box that cannot be described that way is not yet a justified agent.
Primary sources used
- OpenAI · A practical guide to building agents
Incremental orchestration, single-agent-first design, explicit exit conditions, and bounded guardrails.
- Anthropic · Building effective agents
Choosing the simplest effective pattern and using parallel or evaluator workflows only when their task boundary fits.