Most vendor conversations about multi-agent systems focus on capability: what the agents can do, how fast they can do it, and how many steps they can string together without human input. That framing misses the harder answer:. the right unit of analysis for agentic AI is not capability, it’s authority. Who authorized the agent to act? What can it decide on its own? What happens when it is wrong in production? This post maps the delegation patterns your vendors are selling, the arithmetic that explains why unconstrained autonomy is risky, and the accountability model Ceiba uses to ensure a named engineer always holds the outcome.
The question behind every agent demo
A CTO watching a multi-agent demo is rarely asking whether the agents can do the work. She already knows they can generate code, write user stories, flag security issues, and reconstruct architecture documentation. The question she is actually asking and that most vendor demos deliberately avoid answering is: what happens the morning one of them does the work wrong in production?
That question is now the design constraint.
Thoughtworks principal Matt Kamelman frames this as a discipline he calls delegation architecture: the design of what judgment an organization transfers to a system acting on its behalf, how much discretion that system holds, which of its actions remain reversible, and who answers for the result. Kamelman’s framing matters because it reorients the conversation away from orchestration — which is an engineering problem — toward accountability, which is an organizational one. Capability is the wrong unit of analysis. Bounded autonomy is the right one.
Google DeepMind researchers Tomasev, Franklin, and Osindero make the same point from a different angle in their February 2026 paper on intelligent AI delegation. They argue that true delegation is not simply task decomposition: it is the transfer of authority, responsibility, and accountability between principals and agents — a sociotechnical phenomenon that existing orchestration frameworks are not designed to handle.
Ceiba’s position on this is direct: every agent in a Ceiba delivery flow holds delegated authority from a named senior engineer, and that engineer keeps the accountability. The authority is explicit. The escalation path is defined before the pipeline runs. The engineer’s name is on the deliverable.
You might also be interested in:
The four delegation patterns and the one nobody puts on the diagram
Before evaluating any multi-agent architecture, engineering leaders need a clear taxonomy of how work moves between agents. Fast.io’s analysis and OpenAI’s practical guide to building agents both converge on four primary patterns:
Sequential handoff
A linear pipeline where each agent completes its task and passes output to the next. Simple to instrument, straightforward to debug, but brittle: there is no feedback loop, and an error in step three propagates cleanly through steps four through ten.
Router
A dispatcher agent classifies incoming intent and routes to a specialist. Effective when classification is reliable. When the router misclassifies which it will the task reaches the wrong expert and the wrong expertise is applied to the problem.
Hierarchical (supervisor and workers)
A manager agent decomposes a task, assigns sub-tasks to worker agents, reviews outputs, and integrates results. This is the standard pattern for coding workflows, and it is the most token-expensive. Coordination overhead is real: published analyses put multi-agent hierarchical architectures at 1.6x to 6.2x the token consumption of comparable single-agent workflows.
Bidirectional
Agents share state and iterate. Strong for exploratory and generative work. Hardest to bound. Prone to convergence loops when agents reinforce each other’s errors rather than correcting them.
The fifth pattern the one that rarely appears on vendor architecture diagrams is Human-in-the-Loop (HITL). Fast.io lists HITL alongside the four as a delegation pattern in its own right: the agent pauses execution and escalates to a human before proceeding. Most vendor demos treat HITL as a fallback for when the system fails. That framing treats human judgment as a recovery mechanism rather than a design position.
The arithmetic of autonomy: why compound error rates matter
The most common argument for maximizing agent autonomy is speed: fewer human checkpoints means faster throughput. The arithmetic of multi-step agent chains complicates that argument significantly.
Errors compound, they do not average
In a sequential pipeline, per-step reliability compounds rather than averages. A ten-step chain where each agent performs at 95% per-step accuracy yields roughly 60% end-to-end reliability not 95%. Each additional step degrades the expected outcome. The MAST study (Cemri et al., 2025), which analyzed 1,642 execution traces across seven open-source multi-agent frameworks and catalogued fourteen distinct failure modes, found success rates on hard programming tasks falling to approximately 25%. These are not outlier numbers. They are the baseline for complex, multi-step agentic work without robust human review gates.
Failures are correlated, not independent
The International AI Safety Report 2026 surfaces a finding that most architecture discussions ignore: agents sharing a base model or a common toolset fail in the same direction at the same time. Redundancy across identical agents buys less safety than engineering intuition suggests. When the underlying model has a systematic blind spot, every agent built on it shares that blind spot. Horizontal scaling of agents is not a substitute for architectural diversity.
Coordination has a ceiling
Published analyses of multi-agent coordination efficiency put the performance plateau near four agents. Beyond that, coordination overhead, shared state management, inter-agent communication, conflict resolution, context propagation begins consuming the efficiency gains that the agents were deployed to produce. This does not mean large multi-agent architectures are wrong. It means they require explicit coordination design, not just more agents.
None of this argues against agentic AI. It argues against delegating a ten-step chain of consequential decisions and calling the retry loop a control. The question is not whether to use agents it is which decisions to hand them, under what constraints, with what oversight.
You might also be interested in:
→ Observability Beyond Logs: Understanding AI System Behavior
Task tiers: what Ceiba delegates, and to whom
The autonomy spectrum is a delegation decision. The questions that determine where a task lands are not about what the agent can do, rather they are about the consequences if it does it wrong.
Three questions govern every task placement:
- Is the action reversible?
- Is the consequence immediately observable?
- Does the client’s revenue, compliance exposure, or production stability sit on the other side of it?
Ceiba structures delivery around three tiers:
| Tier | Example Work | Delegated To |
Human Role |
| High Autonomy | Codebase archaeology, documentation reconstruction, test scaffolding, exploratory spikes | Architect and Developer agents | Spot check — automated gates absorb the volume |
| Bounded Autonomy | User stories from requirements, implementation against approved specs, OWASP and best-practice review gates | Product, Developer, and Review agents | Reviews every story that clears the automated gate |
| Human-Led | Architecture decisions, data model changes, anything touching auth, payments, or regulated data, production release calls | Agent drafts, engineer decides | Signs off by name — no release without it |
High autonomy: the agents run, engineers spot-check
Codebase archaeology, documentation reconstruction, test scaffolding, and exploratory spikes are reversible, observable, and low-stakes. If the documentation agent produces an inaccurate component inventory, the engineer catches it on review and reruns. Automated gates absorb the volume. Human attention is reserved for the exceptions that the gates surface.
Bounded autonomy: automated gates before human review
User story generation from approved requirements, implementation against validated specifications, and automated security reviews against OWASP Top 10 for LLM Applications criteria operate in bounded autonomy. A failed check sends the story back to the agent for rework before a human reviewer spends a minute on it. The engineer reviews every story that clears the automated gate, not every story the agent produces. This is how human attention scales without becoming the bottleneck.
Human-led: the agent drafts, the engineer decides
Architecture decisions, data model changes, anything touching authentication, payments, or regulated data, and production release calls are human-led by design. The agent produces a draft: an architecture proposal, a migration plan, a risk summary. The engineer makes the decision and puts their name on it. No automated gate clears this class of work to production.
Guardrails, governance, and the FinOps reality
What guardrails do and what they do not
Guardrails are constraints: spending caps, data-access restrictions, blocked destructive commands, approval thresholds. They are necessary and they are not sufficient. Ceiba maps agent controls against OWASP Top 10 for LLM Applications (v2025) and aligns the governance layer with the NIST AI Risk Management Framework.
Kamelman’s observation from the Thoughtworks delegation architecture piece lands precisely here: a coding agent can pass every automated test and still introduce an architecture that grows harder to change every quarter. The constraint held. It represented the wrong thing. Guardrails stop known bad actions. They do not encode engineering judgment.
This is the accountability gap that distinguishes mature agentic delivery from delegating to a black box and hoping. Guardrails constrain. Engineers judge.
The FinOps dimension
Delegation architecture is not just an accountability problem. It is a cost problem. Hierarchical multi-agent patterns consume tokens. A supervisor agent that decomposes a task, assigns it to three workers, reviews each output, and integrates results burns significantly more inference budget than a well-scoped single-agent workflow. At current frontier model pricing which sits below actual compute cost, subsidized by venture capital that cost structure is manageable. When subsidies normalize, it will not be.
Ceiba addresses this as an engineering constraint rather than a pricing risk. The Ceiba Method is model-independent by design. Agents have operated across GitHub Copilot, Claude, and open-source models without architectural changes. Ceiba routes each workload to the cheapest model that clears its quality bar for that tier, running open-source models on dedicated H200 GPU infrastructure for high-volume and IP-sensitive work, reserving frontier model inference for tasks that genuinely require complex reasoning. When a provider changes pricing or limits capacity, the workload moves while the contract does not.
This is FinOps applied to AI delivery: measure cost per workload, assign each task to the model that meets its quality threshold, and build the abstraction layer before the pricing shock arrives.
You might also be interested in:
→ The Engineering Manager’s Guide to AI Agent Delegation
→ Strategies to Mitigate Codebase Cognitive Debt
The Ceiba Method: delegating to a team that already did this to itself
Where the agents run
Ceiba’s agents run inside the client’s security perimeter, packaged as a VS Code extension, executing under the client’s credentials, with specifications and documentation stored in the client’s own repositories. There is no black-box external service holding proprietary code. Every artifact the agents produce lives in the client’s infrastructure from the moment it is generated. The audit trail is native to the client’s development environment.
Who holds the authority
Senior engineers in Latin America, operating in the same time zone as US delivery teams. Nearshore matters here for a reason that engineering leaders understand immediately: supervision requires overlapping hours. A HITL architecture where the human is seven time zones away and asleep when the agents encounter an edge case is not a control. It is a delayed review. Ceiba’s engineers set the autonomy level per workload, define the escalation criteria, review what the agents produce, and sign off on the deliverable.
The marketplace review flow
Ceiba maintains an internal marketplace where engineering team members can propose new agents and skills ranging from domain-specific code reviewers to specialized architecture validators. Every proposal passes a structured approval flow that evaluates construction quality, token efficiency, and security compliance before the agent becomes an official capability. The method improves continuously because the engineers using it are also the ones extending it.
The honest version of the productivity claim
The METR randomized trial (July 2025) found experienced developers 19% slower with AI tools while believing they were 20% faster. METR revised its confidence in the result in February 2026 the developers who benefit most from AI tools had disproportionately opted out of the study, skewing the baseline. The honest read of that result is not a percentage. It is the perception gap: engineers consistently overestimate how much AI tools are helping them and underestimate how much validation work the tools are creating.
Ceiba’s engineers spend fewer hours on boilerplate, documentation reconstruction, and test scaffolding. They spend more hours on architecture decisions, data model design, and the judgment calls that determine whether the software the agents produce is actually solving the right problem. That is the delegation the Ceiba Method is built for not replacing engineering judgment, but preserving it for the decisions where it is irreplaceable.
Delegation is an architecture decision. Treat it like one
The question is not whether your organization will use AI agents. It is whether you will design the delegation architecture before deploying them or reconstruct it after something goes wrong in production.
As Thoughtworks’ operating system for enterprise AI puts it: the hard questions for 2026 are not which model to use or which agent framework to adopt. They are how much autonomy you are prepared to delegate, to which agents, under what constraints, with what observability, and under whose accountability.
Ceiba engineers built this accountability model on themselves first every agent in Ceiba’s own delivery operation runs under the same tiering, the same escalation criteria, and the same named-engineer sign-off that client engagements use. The method is not a specification. It is operational.
Bring one delivery problem, one AI inference bill, or one stalled pilot. In a single working session, Ceiba’s technical team will map your workloads onto the autonomy spectrum, show you the cost economics behind each tier, and identify where your current delegation architecture has accountability gaps.
Let’s Talk
You might also be interested in:
- Observability Beyond Logs: Understanding AI System Behavior
- The AI Readiness Gap
- The Engineering Manager’s Guide to AI Agent Delegation
- The Prompting Layer Is Now an Engineering Responsibility
