Multi-agent AI systems promise scale, automation, and autonomous decision-making, but most enterprise deployments struggle long before they reach production. As agents begin coordinating with other agents, failures multiply: handoff loops, cascading errors, context bloat, conflicting actions, and runaway token costs quickly turn promising demos into unreliable systems.
The solution is not better prompts or larger models, but a stronger harness: the orchestration, policies, memory, verification, and observability layers that govern how agents operate in the real world. In part 2 of the blog, we explore why harness engineering is becoming the foundation of enterprise multi-agent systems, the architectural patterns that are surviving in production, how leading organisations are structuring reliable agent workflows, and what enterprises must build to scale AI systems safely, efficiently, and predictably.
Scale AI agents with stronger orchestration.
Industry estimates for 2026 suggest that enterprise multi-agent workflows handling parallel tasks can consume up to 70% more infrastructure resources than expected during initial pilot phases, largely due to orchestration overhead, repeated tool calls, and uncontrolled context growth. The result is forcing enterprises to rethink AI systems not as standalone models but as distributed operational architectures that require structured governance and execution control.
Multi-agent: where the harness becomes the architecture
Single-agent systems are difficult enough. Multi-agent systems make the harness load-bearing. The reason is that almost everything that can go wrong in a single agent gets multiplied, and several new failure modes appear that have no single-agent equivalent.
The first multiplier is the handoff loops. When agent A can delegate to B, and B back to A, and neither owns the task, the system enters a polite, expensive, infinite ping-pong. Production surveys in 2026 have converged on this as the number-one multi-agent failure mode. The fix is not in the prompt; it is in the harness, which has to enforce a clear owner per task and a budget on handoffs.
The second is cascade failure. A paper titled “From Spark to Fire,” published earlier this year, found that a single atomic falsehood injected into a hub-and-spoke multi-agent topology can infect 100% of agents in the system because the orchestrator distributes the corrupted context downward. Multi-agent systems amplify misinformation faster than single-agent systems, and the harness is the only place to install firebreaks.
The third is context bloat at the orchestrator. In hub-and-spoke patterns, the orchestrator accumulates context from every worker. Past three or four workers, this routinely exceeds context windows. The harness either passes the full context (expensive and eventually impossible) or summarises (lossy, and accumulating summarisation errors degrade quality). There is no prompt that fixes this. Only structure does.
The fourth is conflicting actions on shared resources. If a fraud-detection agent and an adjudication agent both decide on the same claim in parallel, without coordination, the system will eventually take contradictory actions. Locks, queues, transactional gates, and structured inter-agent protocols are harness concerns.
The fifth is token economics. According to some careful measurements, multi-agent systems use around 15 times as many tokens as single-agent chat for the same task. A workflow that costs $0.50 in testing can cost $50,000 a month at 100,000 executions. The harness is where token budgets are set, pruning occurs, and cost per task is observed. Teams that ship multi-agent systems without a clear cost-per-task metric tend to discover the number from the finance team rather than from their telemetry.
Two things follow from this list. First, the popular framing of multi-agent systems as “free-roaming swarms” has not survived contact with the production environment. The patterns that have survived (agent-flow assembly lines, hub-and-spoke orchestration with bounded workers, and tightly constrained collaboration) share a structural property: explicit boundaries, deterministic handoffs, and human checkpoints. Wells Fargo’s deployment, giving 35,000 bankers access to 1,700 procedures in 30 seconds, is a bounded orchestration system, not a swarm. Anthropic’s three-agent harness for long-running coding is Plan-Execute-Verify with phase gates, not autonomous emergence.
Second, the centre of gravity in multi-agent systems has moved from the agents themselves to the harness around them. The agents are the workers. The harness is the supervisor, the timekeeper, the contract enforcer, and the auditor. In production systems that work, the harness is closer in complexity to a payments engine than to a chatbot.
An example: an enterprise claims platform
The abstract case is easier to follow when supported by something concrete. Consider an insurance company building an agentic claims processing platform: the kind of system being scoped, today, in nearly every large insurer’s GenAI roadmap.
A claim arrives. Several things have to happen, in some order: the claim has to be parsed and structured, the policy has to be looked up and validated as in-force, the claim has to be screened for fraud signals, the supporting documents (photos, repair estimates, medical records) have to be evaluated, the claim has to be adjudicated against policy terms, a settlement amount has to be computed, regulatory checks have to be performed, and the customer has to be notified. Some of these steps depend on others. Some can run in parallel. Several involve calling into systems of record that the agent does not own.
The naive version, which is what most teams build first, is a free-form multi-agent system. There are six or seven specialist agents (Intake, Fraud, Policy, Documents, Adjudication, Notification), and they hand off to one another based on what each agent deems the next logical step. The system works on the demo. It collapses in production. Fraud and Adjudication race, sometimes producing contradictory verdicts. The Documents agent and the Policy agent enter handoff loops when the policy is ambiguous. Context bloat at the orchestrator means that the third claim in a session consumes 10 times as many tokens as the first. There is no auditable record of why a particular claim was denied, because the agents had a free-form conversation rather than producing structured artefacts. The compliance team, correctly, refuses to sign off.
Figure 3. The same problem, two architectures. The model is identical in both. The difference is the harness.
The second version, which is what production teams converge on after a few painful months, looks structurally different. A Planner agent reads the incoming claim and produces a structured, machine-readable plan: the phases that must run, the inputs each one needs, the decision points, and the expected outputs. The plan is an artifact written to durable storage, not a free-form chat message.
A pool of specialist agents (Intake, Policy, Fraud, Documents, Adjudication, Notification) executes one phase at a time, in the order dictated by the plan. Each agent has narrow, scoped access to tools and a strict input/output schema. Agents do not call each other. They write output to the shared claim file, and the orchestrator decides what to run next. When two phases can run in parallel, such as Fraud and Documents, the harness runs them concurrently against an immutable snapshot of the claim file and merges the results through a deterministic protocol.
A Verifier agent runs after each phase, in a fresh context window, with read-only access. Its job is to grade the output against the plan and against policy rules: is this adjudication consistent with the policy terms that were looked up? Did the fraud check actually inspect the fields it was supposed to? The verifier never edits. It either passes the phase or kicks it back with a reason.
A human approval gate sits before any payout above a threshold. Typically, a small fraction of claims need it; the rest auto-process. The threshold is policy, not prompt. The harness will not call the payout API without the gate, and no model output can override that.
Underneath all of this, the harness maintains a structured claim file and an audit log that captures every model call, every tool call, every decision, and every retry. The compliance team is no longer dealing with a chat transcript. They are dealing with a structured record that maps cleanly to their existing claim-handling controls.
The two architectures use the same underlying model. They run on the same cloud. The difference between them, measured in cost per claim, defect rate, time-to-resolution, and regulatory acceptability, is entirely in the harness. This is what the Stanford finding looks like when it stops being a benchmark and starts being a balance sheet.
What a harness engineer actually does
The job title is new enough that it is still being shaped, but the shape is reasonably clear. A harness engineer is the person (or the function) responsible for the components in the anatomy diagram above. The role sits at the intersection of platform engineering, site reliability engineering, and applied machine learning, and it is closer in spirit to the first two than to the third.
Day-to-day, the work looks like a mix of the following. Designing the orchestration loop and the handoff protocol between agents. Writing tool definitions and stress-testing the model’s use of them. Building the verifier, which may be deterministic code, a separate model with a graded rubric, or a human-in-the-loop workflow. Defining the eval set and the metrics (task completion rate, step efficiency, recovery rate, latency, cost per task) and keeping them running in CI. Owning the observability story so that every production incident produces a trace that can be inspected, not a vague complaint. Setting policy boundaries: what the agent can call, what it cannot, what blast radius is permitted, and what requires escalation. Managing the cost and token budget per task, with alerts when those move.
The skills involved are a specific combination. The engineer needs enough distributed systems intuition to design retry and consistency models. They need sufficient applied ML literacy to reason about why a model behaves as it does (token economics, context window effects, sampling behaviour, common failure modes) without needing to train one. They need enough product sense to define what “done” means for a task in a gradable way; this is unglamorous work that often proves to be the highest-leverage activity in the entire effort. And they need to know what to automate and what to leave to humans, because over-automation in safety-relevant domains is how trust gets burned faster than it can be rebuilt.
In organisational terms, harness engineering tends to sit in a platform or shared-services group rather than inside individual product teams. The pattern most enterprises are converging on looks like an internal agent platform team that owns the harness primitives (orchestration runtime, eval framework, observability, policy enforcement, MCP gateway) and product teams that compose agents on top. The same pattern that played out with internal developer platforms over the last decade is playing out again, on a faster timeline, for agents.
Where to start, if you are starting
The temptation, on reading a piece like this, is to launch a six-month program. That is the wrong instinct. Harness engineering is best learned in the smallest concrete system that has real users and real consequences. A short list of practical next steps for an enterprise beginning the work.
- Start with one bounded workflow. Pick a single business process (a single class of claims, a single category of support tickets, a single procurement workflow) where the steps are knowable in advance,e and the failure modes are well understood. Multi-agent systems with vague success criteria fail. Bounded ones with crisp definitions of “done” succeed.
- Instrument before you optimise. Before any model is tuned, before any tool is added, build the trace. Every model call, every tool call, every state transition, is captured and queryable. The teams that ship in 2026 are not the ones with the best prompts; they are the ones with the best telemetry.
- Build the eval before the agent. Define, in writing, what a successful run looks like for fifty representative cases. Run those cases against whatever you build, every day. This is the closest thing to a unit test that agentic systems have, and it is the single fastest way to detect regressions.
- Make the verifier a separate process. Even a simple one. A schema check. A second model with no tools that grades the output. A scripted dry-run. The generator and the evaluator must not be in the same context window. This single discipline rules out a class of failure modes that no amount of prompt tuning can fix.
- Treat tools as products. Each tool the agent can call deserves the same care as a public API: a clean name, a clear description, validated inputs, structured errors, and a contract. The tool surface is the agent’s interface to the world; if it is sloppy, the agent will be sloppy in proportion.
- Keep humans on the loop, not always in it. Define the autonomy boundary explicitly. Below a threshold, the agent acts. Above it, the agent proposes, and a human approves. As confidence grows, raise the threshold. As problems emerge, lower it. This dial is a harness concern, and it should be adjustable without redeploying the model.
None of these steps requires frontier models. None of them requires a new framework. They require deliberate work on the engineering surface that surrounds the model.
The takeaway
The model is becoming a commodity. That sentence has been said in too many industry talks to feel original anymore, but the data is now firmly on its side. Foundation models are getting cheaper, more capable, and more interchangeable each quarter. The differentiation between an enterprise system that works and one that does not is not in the model it uses. It is the discipline of the software around the model.
Harness engineering is the name for that discipline. It is what turns a probabilistic function into a system that an enterprise can run on, audit, govern, and improve. It is what closes the 95% pilot-to-production gap that has frustrated executive committees for two years. And in multi-agent systems specifically, where the failure modes are structural rather than linguistic, it is no longer an option. It is the architecture.
The teams that internalise this earliest will, in five years, look like the teams that internalised cloud-native infrastructure or modern data platforms ahead of their peers. Same model. Different harnesses. Six times the outcome.
