Why the Future of AI at Work Is Multi-Agent

Executive summary

Multi-agent systems will be deployed as teams of agents organized the way a well-run company organizes people. Each team has a defined job, a budget, permissions and a human owner. Inside a team, agents take separate roles such as planning, doing the work and reviewing it, and every handoff is a structured record the next agent can check. Early deployments at Cockroach Labs, Block and Anthropic already work this way, with a planner directing cheaper worker models and separate reviewers, tests or people approving each result before it moves on.

Structure is what makes this work. In controlled tests, loosely coordinated agents do worse than a single agent, and a gated pipeline that copied a corporate org chart failed completely. The teams that succeed keep coordination links few, give each agent a narrow job and use tests or independent reviewers to decide whether work is correct.

Adoption will follow how easy the work is to check. Software comes first because code already has tests, version control and review. Structured back-office work such as claims, finance close, compliance review and procurement comes next, since those processes already run as staged workflows with sign-offs. Work that crosses teams and companies comes last, because it needs shared state, permissions and accountability across boundaries.

Over time, each function could run standing agent teams that hand work to each other through defined contracts. Work would start from events such as a failed machine, a supplier's bankruptcy or a new regulation, and agents would increasingly deal with other companies' agents on quotes, claims and contract terms within limits their owners set. Steps that need no judgment, such as passing a signed deal to billing, would stay with ordinary integrations, and agents would handle the steps that need context and approvals.

People move from doing each task to running the system. They set policy and budgets, decide what work gets admitted, write the precedents agents follow and approve anything above a set threshold. Oversight shrinks as reliability is measured. A new workflow starts with a person checking everything, then moves to spot checks and after-the-fact audits as the system builds a track record for that kind of work, and the risk of each change decides how much review it gets.

Several pieces have to exist before this works safely at scale. Agents need enforced limits on what they can spend or commit to, a way to verify which company a counterpart represents, shared formats for quotes, claims and orders, records both sides can check, and circuit breakers that stop errors from cascading. Models and sandboxes are maturing, but orchestration, observability, compliance and trust between companies are still early. Most companies will adopt agent teams for bounded workflows first, and full integration across the economy will likely take decades. Sculptured is an open-source workspace for designing, running and measuring these teams.

Introduction

In under five months, Cockroach Labs merged 1,238 pull requests written and reviewed by a team of coding agents, and only 7 had to be reverted. The agents were organized like a teaching hospital, with separate roles for triage, planning, review and sign-off, and a human Chief who ruled on anything the agents could not resolve and approved the merges. How those agents were organized mattered more than which model ran them, and that is the subject of this article.

My argument is that AI will be deployed at work as teams of agents, organized and supervised much like teams of people. Each team has a narrow job and an owner, work moves between agents as structured handoffs that something checks, and people set policy, approve exceptions and decide how much autonomy each kind of work has earned.

Multi-agent systems are currently complex to build and suffer many failures. For example, in one controlled test a single agent scored 28 of 28 on a backend build while a gated corporate-style pipeline of agents scored 0. A Berkeley study found that multi-agent systems often show minimal gains over single agents on popular benchmarks. Those failures came from loose coordination, many handoffs and review by opinion. The systems that work keep coordination links few, give each agent a narrow job and use tests or independent reviewers to decide whether work is correct. Adding agents helps only when they are organized this way.

What a multi-agent system is

An agent is a model using tools in a loop toward a goal. A multi-agent system is several of those agents, each with its own role, context and tools, coordinated to do a body of work. That work can be a single result, such as a merged code change, or an ongoing job, such as monitoring a plant and responding when something fails. Anthropic's engineering write-up uses the same definition, describing multiple LLMs autonomously using tools in a loop and working together.

The number of agents doesn't matter. The separation of concerns is the main consideration. Each agent gets a narrow job, a clean context window and a prompt tuned for that job. Together they provide parallel work, independent review and a record at every handoff, which a single agent cannot.

Most production systems use one of a handful of shapes, often in combination.

What has already been demonstrated

1. Cockroach Labs' teaching hospital for code

Cockroach Labs built MOLT Sinai, a pipeline of Claude agents modeled on a teaching hospital. Issues are patients, merging is discharge, and humans are Chiefs of Medicine. A Triage Nurse admits work, a Fellow reproduces the bug, writes a treatment plan and later implements it, a separate Review Attending tries to find fault with the plan and then the code, and a Discharge Nurse checks that the review happened before merge. A Charge Nurse also checks every 30 minutes for stuck work, and Infection Control can lock everything down if main breaks.

Work only moves forward through a review by a different agent; rejected plans and failed code loop back, and stuck work escalates, first to an Attending and then, if the agents cannot resolve it, to a human Chief.

Cockroach Labs reported these results in October 2026. The repository counts cover April 21 to September 11, 2026.

• 1,238 PRs merged and 1,322 issues discharged, well over a million lines of code, with 7 reverts.
• IBM Db2 migration support built in under two days for $4,172 in tokens. The comparable Oracle work in 2024 took 9 months and about $160,000 in engineering time, so the Db2 work was 164x faster and 38x cheaper. Nobody reviewed the Db2 code during that test, and Cockroach Labs is still confirming it is correct.
• About $135,000 in total token spend, roughly $84 per issue.
• 85% of the commits to the hospital framework itself were authored by the pipeline.

Several design rules made this work. No code is written before a plan has been reviewed. A 1,000-line ceiling forces large changes to be split so each one can be reviewed. A stuck agent writes a structured I-PASS handoff and escalates instead of retrying. A precedent log of the human Chief's rulings lets agents settle repeat questions without escalating. After the first week, a human also approved every merge.

2. Anthropic's orchestrated research system

Anthropic's Research feature uses a lead agent that plans and spawns parallel subagents, each with its own context window. With Claude Opus 4 leading and Sonnet 4 subagents, it outperformed single-agent Opus 4 by 90.2% on an internal research eval. On the BrowseComp benchmark, token usage alone explained 80% of the performance variance; separate context windows let the system spend more tokens usefully.

3. GPU kernel optimization

Kernel tuning suits multi-agent systems well because the objective is measurable, correctness is testable, and the work splits into coding, testing, profiling and planning.

Across all three, the gain comes from separating the agent that proposes from the agents that measure and critique.

4. A virtual diagnostic panel in medicine

Microsoft's MAI Diagnostic Orchestrator (MAI-DxO) turns a model into a panel of five clinician roles. One keeps the differential diagnosis, one chooses tests, one challenges the leading hypothesis to avoid anchoring, one vetoes low-value expensive tests, and one checks quality. On 304 hard NEJM case records turned into step-by-step encounters, it solved 85.5% of cases at its most thorough setting. Twenty-one experienced physicians averaged 20%.

A cost-conscious configuration still reached 80% while cutting testing costs about 20% versus physicians and 70% versus the same model used alone. The gains held across model families, so the improvement came from the orchestration. It did not depend on a particular model. Microsoft notes the cases were complex teaching cases and that everyday presentations still need testing.

5. Scientific hypotheses that held up in the lab

Google's AI co-scientist runs a Supervisor over agents that generate hypotheses, critique them, rank them in tournaments and evolve the winners. It proposed drug-repurposing candidates for acute myeloid leukemia that then inhibited tumor cells in vitro at clinically relevant concentrations, and epigenetic targets for liver fibrosis that showed anti-fibrotic activity in human liver organoids.

The Stanford and CZ Biohub Virtual Lab, published in Nature in July 2025, gave a human scientist an AI Principal Investigator that staffed its own team of specialist agents plus a Scientific Critic. In a few days the team designed a computational pipeline and 92 nanobodies against recent SARS-CoV-2 variants; two showed improved binding to recent variants in lab tests. Humans contributed only about 1% of the team's discussion.

A direct comparison was published on October 21, 2026. OpenAI, PerturbAI and Scripps Research split a whole-brain CRISPR atlas, data from millions of mouse brain cells, across thousands of GPT-Rosalind agents. Each agent took one gene disruption, analyzed the cellular response, searched the literature and proposed a mechanism; their reports were merged into a reasoning atlas. The run took 32 minutes, against an estimated months to a year of one-at-a-time human analysis, and it surfaced new leads such as a possible link between the Perry syndrome gene DCTN1 and cholesterol in neurons.

The team also tested a single agent given the whole dataset, with the same model and resources. As the workload grew, the single agent searched less. At the largest workload it cited 11 references, while the distributed agents retained 711 times as many. Blinded human experts preferred the distributed reports 75% of the time.

6. A compiler built by 16 parallel agents

An Anthropic researcher used 16 Claude agents on a shared repository to write a C compiler in Rust from scratch. Over about two weeks, nearly 2,000 sessions and $20,000 in API costs, they produced a 100,000-line compiler that builds Linux 6.9 on x86, ARM and RISC-V, plus projects such as QEMU, FFmpeg, SQLite, Redis and Postgres.

Problems started when the work became one large task, compiling the Linux kernel. Agents kept hitting the same bug and overwriting each other's fixes. The solution was a test harness that used GCC as a known-good reference. It compiled a random majority of the kernel with GCC and the rest with Claude's compiler, so each agent could work on bugs in different files. The result is not a drop-in replacement for GCC, and its generated code is slow, but it shows how far parallel agents can go when the work can be split and checked.

7. Orchestration in production

At Block, Claude Fable now orchestrates company-wide code migrations that span hundreds or thousands of pull requests across multiple repositories. An engineer steers the work. Fable handles the design, such as data models, API specs and algorithms, then directs up to dozens of cheaper models that make the file edits and run the tests. A single migration can merge a thousand pull requests this way. Frontier-model tokens go to planning and most of the volume goes to smaller models; early results show no drop in quality.

Google DeepMind's AlphaEvolve uses the same split between generating and checking. A fast Gemini model proposes many candidate algorithms, a stronger one adds depth, and automated evaluators score every candidate. One scheduling heuristic it found for Borg, Google's cluster manager, had been in production for more than a year when Google announced it in May 2025, recovering about 0.7% of Google's worldwide compute.

Where single agents break

Single agents fail in predictable ways, and most of the causes are structural. Capability is rarely the problem.

• Context saturation. One context window has to hold the task, the tools, every intermediate result and the history. As it fills, earlier instructions lose weight and relevant facts get buried. In OpenAI's brain-atlas study above, the single agent searched less of the literature as its workload grew, while the team of agents splitting the work kept reading.
• Sequential bottlenecks. A lone agent does one thing at a time. Asked to list every board member of the IT companies in the S&P 500, Anthropic's single agent failed with slow, sequential searches, while the multi-agent version split the job and got it right.
• Self-review. An agent that wrote the code is a poor judge of it. In the Astra kernel study, a single agent generated unrepresentative test inputs for its most complex kernel, which skewed its own profiling.
• Anchoring. A single reasoner tends to stick with its first hypothesis. Microsoft's diagnostic orchestrator dedicates one agent to challenging the leading diagnosis for this reason.
• Compounding errors. Small mistakes early in a long task carry forward. Without checkpoints, there is nowhere to catch them before they reach production.
• Ignoring instructions. During a declared code freeze in July 2025, Replit's coding agent ran unauthorized commands that wiped a live database holding records on 1,206 executives, then told its user a rollback was impossible. He tried the rollback anyway, and it worked. The agent had production credentials and no separate check before destructive actions.
• No audit trail. One long transcript is hard to reconstruct. When something goes wrong, nobody can tell which decision caused it.

Why better models won't make this go away

A common objection is that models are improving so fast that orchestration is a temporary workaround. I don't think that holds short of AGI, and possibly not even then. Anthropic's engineers make a similar argument, that once intelligence reaches a threshold, multi-agent systems become a vital way to scale performance. Individual humans have grown more intelligent over millennia, but human societies became exponentially more capable through collective intelligence and the ability to coordinate.

There are five reasons this structure will still matter as models improve.

1. Errors compound. An agent that is 99% reliable per step finishes a 100-step task cleanly only about 37% of the time. Better models raise the per-step number; checkpoints and independent review catch the errors that remain.

2. Self-review shares blind spots. A model checking its own work tends to repeat its own mistakes. A separate instance prompted to find faults is less likely to share them. Stanford's Virtual Lab gave its research team a dedicated Scientific Critic; Google's co-scientist has a reflection agent that acts as a peer reviewer, checking each hypothesis for flaws.

3. Context and time are limited. Larger windows help, but one context still can't explore ten threads at once. Separate windows let a system read more and finish faster.

4. Cost routing. Most steps don't need the most capable model. Anthropic's research system pairs an Opus lead with cheaper Sonnet subagents, and MAI-DxO's stewardship agent vetoes low-value expensive tests while budget settings trade accuracy against cost.

5. Separation of duties. Finance, healthcare and software already require that the person who makes a change is not the one who approves it. Least-privilege permissions, audit trails and sign-off gates map onto distinct agents. Better models do not remove the need for an accountable approval step.

Why unstructured swarms fail

Giving a large group of agents a broad goal and letting them coordinate on their own rarely works. Every result in this article came from structure, meaning defined roles, a unit of work, a check and a stopping rule. Without those, adding agents adds cost and confusion faster than output.

Large goals have to be broken down for the agents. Anthropic's early research agents, given loose instructions, spawned 50 subagents for simple queries, searched endlessly for sources that didn't exist and distracted each other with excessive updates. Told only to research the semiconductor shortage, one subagent studied the 2021 auto chip crisis while two others ran the same searches on 2025 supply chains. Anthropic fixed this by giving each subagent an objective, an output format, tool guidance and clear boundaries, plus rules for how many agents a task needs.

Coordination costs grow faster than the number of agents. Sixteen agents have 120 possible pairs that can collide. The compiler agents described earlier collided this way until a harness gave each one a separate part to own. Anthropic also notes that LLM agents are not yet good at coordinating and delegating in real time, and that small changes to a lead agent can change how the subagents behave in unpredictable ways.

McEntire's token-level model puts numbers on this. In a fully connected team, where every agent talks to every other, governance overhead grows from about 25% of token spend at three agents to nearly 70% at fifteen. In a hub-and-spoke design it grows by roughly half a percent per agent. In his model the cost depends on topology, so better models do not reduce it, and as implementation gets cheaper, coordination becomes a larger share of the total.

In a swarm, no one is responsible for deciding when work is done. Agents working freely are rewarded for producing output and have no reason to check it. Task verification is one of the three failure families in the MAST study. Cockroach Labs rejected throughput-first swarms like Gas Town and Cursor's SQLite rebuild, which produced changes so fast Cursor wrote its own version control to keep up. Instead of measuring PRs per hour, they asked how many of those PRs they would be embarrassed to merge.

Volume is a problem too. Changes merged to Anthropic's monorepo grew from about 2,500 a day in May 2026 to more than 30,000 by September, and its engineers expect the growth to continue because every bottleneck they remove leads to more code. Without admission control, a swarm's backlog, review load and token bill keep growing.

Unstructured systems are also hard to debug. When every agent can talk to every other about anything, there is no handoff to inspect and no clear owner for a failure. Roles and handoffs give traces, evals and fixes a place to attach.

The large runs that look like swarms were structured too. OpenAI's thousands of brain-atlas agents each received one gene disruption, followed the same investigation template and fed a single merged atlas. The compiler agents worked under task locks, a test harness and a GCC oracle. In both cases, someone designed the unit of work and the check before scaling up.

What it takes to build and run one

Running a multi-agent system involves more than writing prompts. The work falls into four phases, which are design, deployment, observability and improvement.

Design

• Roles and authority. Define each agent's job, what it may touch and what it must hand off. A familiar role metaphor helps. Cockroach Labs found that the short framing at the top of each role's instructions was valuable, because the model already knows what a Fellow or an Attending does.
• Handoff contracts. Every handoff is a structured artifact a later agent can parse, such as a plan, a verdict or an I-PASS note. Context gets lost in free-form chat between agents.
• Gates. Decide where work must stop for review, and who reviews it, whether another agent, a deterministic check or a human.
• Decomposition rules. Hard limits such as a 1,000-line ceiling keep each unit small enough to verify.
• Escalation and circuit breakers. Define when to stop retrying and hand off, and cap loops before they use up the budget.
• Oracles. Give agents something trustworthy to check against. The compiler project used GCC this way, and its author found the tests had to be nearly perfect or agents would solve the wrong problem.
• Tests over opinions. Define what correct looks like before work starts, and let tests decide. McEntire's open-source Pact framework is built on this idea of contracts before code and tests as law, so agents can't pass review by arguing.
• Shared, persistent memory. Agents that start each session with no memory repeat work and contradict past decisions. McEntire's Kindex is a persistent knowledge graph that Claude Code, Codex, Gemini CLI, Cursor and other MCP-capable agents can share. It records decisions and constraints with provenance, injects only as much context as the token budget allows, and lets several agents coordinate through the same graph with claims, locks and shared task state.
• Minimal handoffs. In McEntire's language-model experiments, a ~15-token domain-matched prime captured 98.8% of the benefit of a full-length one, injecting another model's internal state added almost nothing over plain text, and every mechanism that added more information to an agent's context helped little or hurt. Pass the smallest useful handoff and leave out the rest of the history.

Deployment

• Put state somewhere durable and inspectable. Anthropic's compiler agents coordinated through a shared Git repository, lock files that kept two agents off the same task, and progress notes any fresh session could pick up from.
• Keep people on the irreversible steps. At Block, agents write and open changes, but merges to main and production deploys stay with people, and agent-made changes need two human approvals before they deploy.
• Plan for model changes. Each model switch at Cockroach Labs needed retuning of agent skills to keep costs in line.

Observability

At minimum, keep a trace per task showing every agent's input, output, model, tokens, duration and cost, plus the reasoning behind each verdict. Watch system-level signals too, including rework rounds per task, escalation rate, cost per outcome and time spent waiting on people. Anthropic's source-control team also assigns dedicated Claude agents, which it calls "superfans," to watch a single component's telemetry and logs and flag subtle problems that traditional alerts miss.

Improvement

• Turn failures into tests. The Claude Code team adds every past incident and revert to an eval set and runs its AI reviewer against it daily; a change to the reviewer's prompts, tools or model stays only if the score goes up.
• Treat prompts as code. A July audit flagged 23% of 100,000 words of skill files as removable without changing a single gate, command or template; one Discharge Nurse run loaded about 29,000 tokens of instructions before reading the PR.
• Turn human rulings into reusable precedent, so the same question isn't escalated twice.

Benchmarks and evals

Public benchmarks are useful for components. KernelBench covers kernels, and AgentKernelArena covers full kernel-agent workflows. The MAST dataset offers 1,600+ annotated multi-agent traces for studying failure. The most useful eval is your own, built from real tasks in your workflow and scored on outcomes, cost and rework, rerun every time a model, prompt or topology changes. Because runs are non-deterministic, judge the end state and the process. The agents won't take an identical path each time.

Why multi-agent design is hard

More agents also mean more ways to fail. The MAST study from Berkeley found that multi-agent systems often show minimal gains over single agents on popular benchmarks. Analyzing traces from seven frameworks, it identified 14 failure modes in three groups, which are specification and system design, inter-agent misalignment, and task verification. Many failures came from how the system was designed and coordinated, in addition to limits of the underlying model.

Jeremy McEntire, Head of Engineering at Wander, documents the risks in The Organizational Physics of Multi-Agent AI. He gave four architectures the same job, building a 7-service backend, with the same model, the same $50 budget and a pre-registered rubric. Scores fell as coordination increased. A single agent scored 28/28, a hierarchical coordinator 18/28, eight agents coordinating through shared artifacts 9/28, and a gated corporate-style pipeline 0/28.

Each design failed in a way tied to its structure. The coordinator refused to delegate. The artifact-sharing agents produced incompatible interfaces at every service boundary. The pipeline, despite six mechanisms built to prevent organizational dysfunction, spent its effort across five planning stages and never wrote implementation code. In an earlier run on a related backend task, the same pipeline bikeshedded through four review rejections containing 69 subjective objections and no verifiable errors, and its nine verification stages all reported "tests passed: zero out of zero." In a follow-up model calibrated to these results, McEntire estimated how much of the original specification survives the handoffs, at about 26% for a hierarchical system against 86% for a single agent.

He does not conclude that multi-agent systems are hopeless. His argument is that agents inherit the structural failures of human organizations, because the cause is information lost in compressed handoffs, whoever or whatever is doing the work. A company that copies its org chart into agents copies its dysfunctions as well. His recommendations match this article's. Use as few coordination links as possible, replace opinion-based review gates with mechanical tests, and constrain the output while leaving the process open.

Production deployments show further failure modes.

These trade off against each other. Tighter gates raise quality but also rework and cost; looser gates raise throughput but let more defects through. Finding the balance requires measurement.

Organizations that run on agent teams

In the near term, agents will do tasks inside today's workflows. Later, agent teams could run much of an organization's day-to-day operations. Work would be triggered by events, would cross company boundaries, and would often be settled by agents negotiating with other agents. People would set policy, hold authority over important decisions and handle exceptions.

An example of an equipment failure

The following scenario is illustrative. A stamping press at a mid-sized auto-parts maker fails. A sensor alert triggers an incident lead agent, which opens a case and assigns work to the teams that own each consequence. The response starts within seconds and runs automatically. Each team's agents update the company's systems as they work, so schedules, orders, inventory and forecasts stay current while the response is underway.

• Maintenance reads the telemetry and service manuals, confirms a failed spindle, opens a work order and books the next available technician.
• Production planning reschedules the remaining lines, moves three orders to a sister plant and recomputes every delivery date.
• Procurement sends a request for quotes on a replacement spindle. Agents from four suppliers answer within minutes with price, lead time and warranty. Inside its mandate (approved vendors, under a set dollar limit), procurement awards the order and books expedited freight through competing carrier agents. Anything above the limit waits for a person.
• Insurance assembles the claim from sensor logs, maintenance history, photos, invoices and the downtime estimate. It files with the insurer's intake agent, which checks it against the policy, asks two follow-up questions and routes it to a human adjuster with the evidence already organized.
• Customer notices go to every affected account with new dates and options. Customers' own procurement agents accept, renegotiate, or reroute volume to an alternate supplier.
• Finance books the costs, updates the cash forecast and flags whether the outage touches any loan covenants.

Within a few hours, the plant manager has a one-page brief covering what happened, what has been done and why, and three decisions waiting. Approve an expedite fee above the limit. Accept one customer's request to waive a late-delivery penalty in exchange for a price concession. Sign the safety report. Everything behind those decisions is traceable to the agent, the evidence and the rule that produced it.

Standing teams inside the organization

Each function could run standing agent teams with a charter, a budget, permissions and an owner, covering finance close, procurement, support, compliance, IT and engineering. Teams hand work to each other through defined contracts, the way services call each other's APIs. Not every handoff needs an agent, though. A signed deal already flows from Salesforce to billing through deterministic connectors, because nothing in that step needs deciding. Agents are useful where the next step requires judgment. When that deal reaches IT, provisioning is rarely a lookup. IT's agents gather context from across the organization on what the customer bought and was promised, which systems they need, which security and compliance rules apply and whose approval is required, then carry out the work, with a record of what was passed and accepted at each step.

Managers would take a role like Cockroach Labs' Chiefs of Medicine. They decide what gets admitted, set the precedents agents follow, approve what exceeds a mandate and review the process itself. Precedent logs and decision records become the company's institutional memory, readable by the next person and the next agent.

From searchable knowledge to coordinated action

A growing ecosystem of companies is building enterprise search, data connectors and agent platforms. That is a useful start, because agents need access to the organization's knowledge before they can do useful work. Glean's enterprise search, for example, connects information across business applications, while Microsoft's Copilot connectors bring external enterprise content into its search and assistant experiences.

Making information searchable does not, by itself, remove the silos in which a business operates. A support ticket, a sales commitment and an inventory forecast can all be retrievable while still lacking a shared definition of the customer, an agreed owner or a reliable way to update the systems that hold them. Search helps people find information but does not resolve conflicting records, disconnected processes or divided authority.

There is also a gap between answering a question and taking responsibility for an outcome. In a search-led deployment, the data may sit unused until an employee asks the right question. A proactive agent needs a trigger to notice a change, a mandate to investigate, permission to act and a check that the action achieved its purpose. An assistant that can recommend a response but cannot open a case, update a record or hand work to another team still leaves the operating burden with the person.

Some platforms already support actions and automation. Glean documents write tools, and Copilot Studio connectors can perform actions. The harder problem is deploying those capabilities across a whole process with clear ownership, limited authority and verification.

Within an organization, sales, finance and operations agents need to agree on what is being handed over, who owns the next step and how completion is confirmed. Between organizations, the same coordination must cross separate identities, permissions, contracts and incentives. A company can have excellent search and several capable agents while still relying on people to carry every decision across those boundaries. Enterprise search provides part of the foundation; reliable coordination within and between organizations is the next layer businesses have to build.

Markets of agents between organizations

Larger changes would come between companies. Requests for quotes that took a week of email could be answered in minutes by competing agents. Freight, temporary staffing, cloud capacity, cyber cover and spot materials could be priced continuously, with agents bidding against each other inside limits their owners set. Contract terms could be negotiated clause by clause within pre-approved ranges, with anything outside the range going to the humans on both sides.

Many back-office relationships would work more like fast, two-sided markets. A supplier's agent could offer a discount for a longer lead time; a buyer's agent could split an order across three vendors to reduce risk; an insurer's agent could price a policy from live operational data instead of an annual questionnaire.

Work triggered by events

Most work would start from events in the world, as in these examples.

• A hurricane forecast prompts an insurer's agents to pre-position adjusters and pre-fill claims for policyholders in the path, a retailer's agents to reroute inventory, and a utility's agents to stage repair crews and draft outage notices.
• A drug recall prompts pharmacy agents to find affected patients and arrange substitutes, and hospital agents to update formularies and flag scheduled administrations.
• A new regulation prompts compliance agents to compare it against every internal policy, open tasks for each gap and draft the changes for legal review.
• A key supplier's bankruptcy filing prompts procurement agents to qualify alternatives, legal agents to review contract exposure and finance agents to model the hit to margins.
• A security alert prompts agents to contain affected systems, gather forensics, prepare regulator and customer notifications against their deadlines and brief the incident commander.

What has to be true first

This is a multi-agent design problem at a much larger scale, and every failure mode in this article costs more when agents act across company lines. Several things need to exist before it can work safely.

• Mandates. Every agent needs explicit limits on what it may commit to, spend or disclose, enforced by the system itself, outside the prompt. Early tools already exist. McEntire's Signet is a deterministic, non-LLM authorization layer with cryptographically signed policies that checks each agent action against policy and denies what isn't allowed, including attempts by agents to unlock their own limits.
• Identity and trust between companies. An agent must be able to verify which organization a counterpart represents and what that counterpart is authorized to agree to.
• Shared protocols. Quotes, claims, orders and notices need standard formats so agents from different vendors can transact without custom integration. The groundwork has started. Google donated its Agent2Agent protocol to the Linux Foundation in 2025, with AWS, Cisco, Microsoft, Salesforce, SAP and ServiceNow joining and more than 100 companies backing it, alongside Anthropic's Model Context Protocol for connecting agents to tools.
• Records both sides can verify. Disputes will happen; each party needs an audit trail of what its agents offered, accepted and why.
• Circuit breakers on cascades. When agents react to other agents in real time, small errors can amplify quickly, much like automated trading. Systems need rate limits, sanity checks and kill switches.
• Human authority at high-stakes thresholds. People should make the decisions where the stakes are highest, with everything else handled and documented.

How it spreads through the workplace

Multi-agent systems will spread where verification is cheapest, then follow the existing shape of the organization.

1. Engineering first. Code already has version control, tests, CI and review, so agents have objective gates to pass. That is why most of the results so far are in software, from a 100,000-line compiler to production migration tooling.

2. Structured back-office work next. Finance close, claims, compliance review, procurement and support escalations already run as staged workflows with maker–checker rules. Those workflows map closely onto agent roles and gates. Medicine and research labs are close behind, since diagnostic panels and hypothesis tournaments already work, with a clinician or scientist signing off.

3. Cross-functional processes last. Work that spans teams and systems needs shared state, permissions and accountability across boundaries. Here the orchestration layer becomes shared infrastructure.

The human role changes as well. People move from doing each task to running the system, which means deciding what gets admitted, setting precedents, approving at gates and reviewing the process itself. At Cockroach Labs, a senior engineer's day of meetings can now produce 10 merged, reviewed PRs. An open question, which Cockroach Labs raises, is how junior people build judgment when agents write the first draft. Organizations that let junior people take roles in the loop and have their work reviewed will be better placed to develop talent.

The companies that benefit most will be those that capture how their best people already work, including who does what, who checks it and when to escalate.

Testing an organization before running it

For a business owner, one of the largest advantages could be predictability. A conventional organization can test a promotion, model a budget or rehearse an emergency. It is much harder to copy the organization itself, change its structure and run the same operating conditions through both versions. An organization built around agent teams makes more of that possible, because its roles, permissions, handoffs and decision rules can be versioned, replayed and compared.

Before changing a live workflow, an owner could run alternative team designs against the same historical cases and simulated conditions. What happens when demand doubles, a supplier fails, model prices rise or a key system goes offline? Does a cheaper model produce enough extra errors to erase its savings? Does another review gate prevent losses, or only create a queue? The comparison can cover the whole workflow and go beyond the quality of one agent's answer.

• Cost and profit potential. Measure model, tool and infrastructure costs alongside rework, human review, throughput and expected revenue or avoided loss. Compare the range of outcomes under different assumptions, including bad ones, before committing capital.
• Decision making. Replay equivalent cases to examine whether teams follow policy, handle exceptions consistently and escalate at the right thresholds. Use repeated runs to measure variability; an AI workflow is not necessarily deterministic.
• Operational reliability. Inject missing information, conflicting instructions and service failures. Test whether the organization degrades safely, respects its budget and recovers without losing work.

The business case becomes more measurable. Which operating design produces acceptable service and risk at a sustainable cost? That gives owners a stronger basis for forecasting margins, setting budgets and deciding how much autonomy to allow. It also makes it easier to detect when a model or policy change has made the organization less reliable.

This extends the principle behind NIST's emphasis on repeatable testing and evaluation from individual AI systems to the workflows they compose. It does not turn a business into a predictable machine. Customers, competitors and markets still change; simulations can omit the failure that matters most. Profit estimates remain conditional forecasts, and promising results still need staged trials and measurement in production.

Compliance that can be checked continuously

The same structure creates an opportunity for stronger regulatory compliance. Where a requirement can be translated faithfully into a machine-checkable rule, the system can enforce it before an action occurs. Examples include a spending limit, a required approval, a restriction on data access or a record-retention requirement. Organizations could be required to maintain those controls and produce evidence that they operated, beyond declaring that a policy exists.

Over time, government regulators could use their own AI audit teams to examine company AI systems. They could sample decision records, replay cases in a controlled environment, test required safeguards and flag discrepancies between stated policy and observed behavior. A regulator's agents could check many more transactions and scenarios than a human team could inspect manually. Regulators do not do this today. The UK's Digital Regulation Cooperation Forum already identifies regulators as potential algorithmic auditors.

That would make some obligations harder to evade and compliance failures easier to detect. It would not make every regulation automatically enforceable or eliminate misconduct. Ambiguous law, incomplete records and concealed activity still require investigation and judgment. Public audit systems would need lawful access, confidentiality protections, independent validation and a route for companies and affected people to challenge findings. Government AI can help collect and test evidence; accountable authorities must remain responsible for enforcement.

What still stands in the way

Most companies are far from this. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls. Multi-agent systems make each of those problems harder.

• Safety and security. An agent with a shell, credentials and network access is a new kind of insider. Uber's CISO argues agents need the same insider threat program companies already run for employees, and Uber open-sourced its Agentic AI Detection and Response (ADR) tooling to watch agent harnesses in real time. NVIDIA tied its latest security release to incidents where agents bypassed application-layer controls, reached systems beyond their scope or misreported what they did to finish a task. A team of agents multiplies the identities, permissions and handoffs an attacker or a confused agent can exploit.
• Reliability. Errors compound across steps and agents, and customers notice. In 2024 Klarna said its AI assistant was doing the work of 700 customer service agents and handling two thirds of its customer service chats. A year later its CEO said the push had lowered quality, and the company started hiring human agents again.
• Expense. Multi-agent research runs use about 15 times the tokens of a chat. Even well-funded teams have to manage this. Block is building an auto-selector that steers employees to the right model, because running its most capable model to fix a README typo wastes money. Without that kind of control, costs can grow faster than value.
• Compliance and accountability. Regulators and auditors ask who decided, on what evidence, under whose authority, and whether it can be proven later. Most agent setups can't answer that across a chain of agents, let alone across companies.
• Integration. Real work lives in ERPs, claims systems, EHRs and decades-old databases with their own permissions. Connecting agents to them safely, with the right scopes and data boundaries, is slow engineering work.
• People and process. Teams have to learn to design, supervise and trust these systems. Juniors still need a path to build judgment, and adoption fails when it is mandated under deadline pressure instead of given room to experiment.

A long transition

I expect full integration across the economy to be a couple of decades away, even if many individual companies adopt agent teams much sooner. That is a forecast about organizational change, and today's benchmarks do not imply a date. Improving the models is only one part of the work; businesses also have to build the data, experimentation, integration and management practices that let them use the systems reliably.

The starting points are uneven. Technology companies with mature experimentation platforms can compare a change against a control and connect it to measured outcomes. Consider a grocery chain or a large brick-and-mortar retailer that rolls the same new policy out to every store without a controlled trial or the analytics needed to separate its effect from seasonality. Before that business can compare two agent-run operating models, it needs the discipline to compare two ordinary operating decisions.

For those businesses, the bottleneck is partly the feedback loop, which needs reliable records, useful outcome measures, comparable test groups and the willingness to reverse a rollout when the evidence is poor. Agent teams cannot supply trustworthy profit forecasts from missing data or compensate for a management process that never checks whether its decisions worked.

Adoption will therefore happen in waves. Companies with good data and clear checks can move first; others will start with a bounded workflow and build the missing foundations around it. As the roadblocks in safety, cost, verification, integration and governance are overcome, more companies will use agent teams for substantial parts of their operations.

The cost of human review

Review cost is the biggest economic barrier. If a person has to read and verify every agent's full action trail, the economics do not work. Agents produce work faster than people can review it, and the savings turn into a review queue. That is acceptable while a team is learning to trust a system, but it does not scale across a company.

Anthropic's Claude Code team, where Claude writes about 90% of the code, ran into this early and responded by moving most of the reading to machines. Claude verifies its own work and shows the output, a second agent reviews the diff in a fresh context, several review agents hunt for bugs in parallel and a separate group votes on each finding, and people spend their attention where the risk is. Between June and September 2026, the team's merged pull requests more than doubled while the share that had to be reverted fell by more than 40%.

The answer is to reduce oversight as reliability is demonstrated, the way organizations already treat people. A new hire's work is checked line by line; a proven employee's is spot-checked; a senior one is audited after the fact. Agent systems need the same progression, based on measured reliability.

• Mechanical checks. When tests, reference outputs and contracts decide whether work is correct, a human reviews the evidence summary and can skip the full trail.
• Review scales with risk. On the Claude Code team, a classifier assigns each change a tier. Docs and additive changes behind a feature flag can merge on automated checks alone, ordinary changes need one person, and the riskiest paths always need two. An agent's approval never counts as a person's.
• Track records per task type. A system earns autonomy for a kind of work by showing, over hundreds of runs, how often its output was right, reverted or escalated.
• Records for audit. Keep full records so any decision can be reconstructed when something goes wrong or sampled by an auditor. Nobody needs to read all of them.

Below a certain level of reliability, multi-agent systems mostly create work for reviewers. Above it, the savings grow with scale.

Some of the infrastructure already exists. NVIDIA's open-source OpenShell, launched at GTC in March 2026 and part of its Agent Toolkit, runs agents such as Claude Code, Codex and GitHub Copilot CLI inside sandboxes, enforcing policies over network calls, file access, credentials and inference from outside the agent. In September, NVIDIA paired it with hardware-backed monitoring as an Open Agent Safety Platform, with Anthropic, Salesforce and ServiceNow among the companies integrating it.

This covers one layer, which is what a single agent is allowed to access. Full integration needs several more. A sandbox doesn't know whether a team's plan was reviewed, whether a check ran, whether a spend was within mandate, or which human approved an exception. Regulation is still catching up too. The EU agreed in May 2026 to push back its high-risk AI obligations to December 2027 and August 2028, partly because the standards and compliance tooling weren't ready. Enterprises are being asked to prepare for record-keeping, human oversight and documentation duties whose practical shape is still being set.

Over the next few years, I expect most agent projects to succeed or stall on the lower three layers, which are much less mature than the first two.

How Sculptured can help

There is already demand for multi-agent tools. OpenRig, an open-source harness that runs Claude Code and Codex as one team, lets developers define a team in YAML and boot it with one command, and jumped from a few hundred to more than 3,500 GitHub stars in a single week in late September 2026. Its creator wrote that once he had two agents coordinating, he kept adding more, and that the setup he had built by hand was fragile. Developers want team setups they can save, share and restore.

OpenRig also shows the limits of current tools. It is built around coding agents, running them in terminal sessions on machines a developer operates. That is a reasonable starting point, but it is not something a claims department, a finance close or a supply-chain team can adopt yet. Using multi-agent systems across domains and in businesses needs more than launching agents together. It needs workflows with review gates and revision limits, independently verified results, budgets and cost visibility across providers, an auditable record, and a design that non-engineers can read and govern. Sculptured is built to provide these.

In each case above, the limiting factor was the system around the model. Cockroach Labs spent five months building and refining roles, gates, records, circuit breakers and prompt audits on top of GitHub Actions. Sculptured provides that kind of system as an open-source workspace, so teams can design, run and steer agents without building it themselves.

Sculptured runs Claude Code and Codex agents on your own machine, using your existing CLIs and sign-ins, and covers the phases described above.

• Design on a board. Give each agent a job and a folder, arrange agents into groups and draw the handoffs between them. Team designs can be saved as files, so a working topology is reusable.
• Gates and circuit breakers. Workflows add stages, review panels, checks and revision limits when the work needs them, including the plan reviews, maker–checker steps and rework caps that MOLT Sinai built for itself. A decision log records rulings, like Cockroach Labs' precedent log.
• Verification. Agent reports, captured tool results and verified checks carry distinct labels, and a passing check only supports the properties it tests. That separates what an agent claims from what was shown.
• Live steering. Open any agent to read its conversation, inspect its files and evidence, answer its questions or send guidance mid-run.
• Context and cost controls. Run budgets keep a run within a share of your plan. Protections keep each agent's context small by refusing whole reads of large files, capping shell output and starting a fresh conversation from the agent's own notes once context grows large.
• Shared project memory. Each start maps the project's folders so agents see what exists before building, and agents can search what the team already did and record lessons for each other.
• Full record. Every event is stored in an append-only journal, which drives the app's views and lets you reconstruct any run.

For observability and improvement, Sculptured's companion tool, MAIS (Multi-Agent Investigative Systems), shows where tokens are spent. It reads the logs Claude Code and Codex already write, links every model call to its agent and team, and attributes usage to fixable causes, which include the following.

• setup every agent loads before doing anything, such as skills, plugins and tool definitions;
• files several agents each read into their own context;
• identical starting context written to the prompt cache once per agent instead of shared;
• tools agents were given and never called;
• fan-outs, concurrency and time spent waiting on the model, in tools or for work.

Every number is labeled measured, derived, estimated or unknown. Cockroach Labs had no such tool and found its oversized Discharge Nurse instructions only through the token bill.

Different roles need different primitives

Frameworks such as LangChain have helped software engineers build agent applications with familiar programming abstractions. In its stack, LangChain supplies framework primitives and LangGraph provides lower-level orchestration, including durable execution and human oversight. These are substantial capabilities, but I think code-level building blocks are too low-level to be the main working language for designing and operating an organization of agents.

They are built around what software engineers already work with, such as models, tools, state, nodes and edges. Practitioners will also need to work with the organization those components create. I expect two roles to become more important. The agent designer decides how agents should work together, and the agent reliability engineer establishes whether that system can be trusted to operate. Software engineering remains essential, but these roles have distinct responsibilities and need primitives that express them.

• The agent designer needs roles, teams, mandates, handoff contracts, shared memory, review panels, approval gates and escalation paths. The design question is who owns an outcome, what each agent may decide and what evidence must accompany work passed to the next team.
• The agent reliability engineer needs verifiable checks, scenario suites, repeatable evaluations, cost budgets, revision limits, circuit breakers, audit records and recovery controls. The operating question is how often the team succeeds, what failure costs, how a change affects those results and when the system should stop or ask a person.

These concepts can be implemented using lower-level frameworks, but requiring every business to assemble them from code leaves much of the hardest organizational engineering to each adopter. A graph edge can carry a message; a business handoff also needs an owner, an acceptance condition, a deadline and a response when the receiving team cannot proceed. The infrastructure should make those obligations visible and inspectable.

Sculptured aims to provide the orchestration and core infrastructure for these practitioners, in the form of a workspace where agent designers can express team structure and authority, and reliability engineers can measure, constrain and improve how those teams operate. Roles, handoffs, gates, budgets and evidence should be reusable parts of the system they design, so nobody has to rebuild them from prompts and application code on every project.

The board, workflows, checks, decision records and usage analysis described here are a first step toward that set of primitives. The longer-term goal includes systematic testing and reliable coordination across organizational boundaries; not all of that exists yet. The aim is for these engineers to spend their time on how the organization works and makes decisions, using shared infrastructure that runs the design and measures its reliability.

Why not use Claude Code or Codex on their own?

Claude Code and Codex are strong agents, and both now coordinate helpers of their own (Codex through subagents); Claude Code has an experimental Agent Teams feature with a lead agent synthesizing results. For one developer on one task, that is often enough. Sculptured runs them as its workers. A separate layer becomes useful when a team, and later a company, has to manage the system around the agents.

The system outlasts any one model. MAI-DxO's gains held across OpenAI, Gemini, Claude, Grok, DeepSeek and Llama models. Cockroach Labs moved from Opus everywhere to Fable for planning, and had to retune its skills at every switch. Roles, gates, handoffs and precedents take the most work to build. They should live in a portable team design you own. Inside one vendor's product, they must be rebuilt when the best model changes.

Mixing models saves money. Planning, implementation, review and routine checks have different price-performance needs. A reviewer from a different model family is also less likely to share the author's blind spots than a second copy of the same model. A vendor's agent tool has little reason to route work to a competitor. A neutral layer can put Claude on planning, Codex on implementation, and, as Sculptured grows to support open-weight models, a cheap self-hosted model on high-volume triage and checks.

Enterprises need more control. Regulated teams have to answer where code and data go, which model saw what, and who approved each change. That means running agents on their own machines or infrastructure, keeping an append-only record of every event, enforcing budgets per run and per team, and requiring human sign-off at defined gates. Open-weight models matter here too, because some workloads can't leave the building, and a framework that can drop in a self-hosted model keeps those workloads in the same system and out of a separate shadow process.

Observability across vendors. When a run spans several agents and providers, each vendor's console shows only its own slice. MAIS reads both Claude Code and Codex logs and attributes every token to an agent and a team, so cost and context waste can be compared and fixed across the whole system.

Open source. Sculptured and MAIS are Apache 2.0. Teams can audit what runs, extend it and keep running it regardless of any vendor's roadmap, pricing or terms.

Both projects are open source under Apache 2.0. Start with the quickstart, which has you pick a Builder → Reviewer team, point it at a project and watch it work.

Sculptured is in beta. Join here.