The Harness.

§ 01More agents do not make an architecture.

You will say that why another write-up on multi-agent systems in 2026, when pretty much everyone has one now. And you would be right, to be honest. A planner agent, a researcher agent, a coder agent, a reviewer agent, and an executor agent that quietly does most of the actual work while the others keep busy having meetings about it. Put them in a loop and it does look pretty much like a system.

But I have built a few of these now, and I have slowly landed on a slightly awkward conclusion — most of them are not really systems at all. They are a bunch of language models taking turns, which is about as much an architecture as five people in a group chat are a company.

And here is the part nobody really likes to hear. The agents are the easy bit, honestly. They are replaceable; you can swap one model for another over a coffee. The hard bit, the one that decides whether the whole thing survives a real Tuesday in production, is the harness around them — the unglamorous layer that decides who is allowed to do what, who owns the truth, and what happens when something breaks. And something always breaks; as of now there is no model clever enough to change that.

Think of it like a climbing harness (the name is not an accident :) ). It does not make you a better climber. It just makes sure that one bad move is not the end of the story. That is pretty much the whole idea, and the rest of this is me trying to make it concrete. NIST treats AI risk as a lifecycle thing — design, development, use, evaluation — and not a "which model did you pick" thing [1], and the moment your agents start acting over time and across tools, you feel exactly why.

§ 02A few definitions first.

Quick vocabulary, so we mean the same things when I use these words.

An Agent is a bounded worker that can look at some context, think about a task, produce something, and sometimes use a tool. The word doing the heavy lifting there is bounded.

The Harness is everything wrapped around the agent — permissions, budgets, schemas, memory, checks, logging, recovery. Unglamorous, and also the part that does most of the real work; a bit like plumbing, which you only really think about on the day it fails.

Orchestration is how you split a goal into pieces, hand them out, and keep track of the whole thing without it quietly turning into chaos.

Now, notice that none of this cares how clever the model is, and that is pretty much the point. You get good behaviour out of a probabilistic thing by surrounding it with rules that are not probabilistic.

§ 03The five planes (or: a restaurant).

A serious agent system keeps five planes apart. A shaky one stuffs all five into one giant prompt and then looks genuinely surprised when nobody can tell what went wrong. If it helps, picture a restaurant kitchen:

• Control plane — the head chef. Decides who does what, what gets sent back, what gets escalated. This is authority.
• Data plane — the order tickets flying between stations. Messages, retrieved documents, tool outputs, telemetry.
• State plane — the inventory book and the reservations. The single source of truth about what is actually going on.
• Execution plane — the cooking itself. LLM calls, code edits, browser automation, database queries, shell commands.
• Assurance plane — the health inspector quietly standing in the corner. Policy, verification, sandboxing, rollback, human sign-off. OWASP pretty much lives here: least privilege, validated outputs, human approval for risky moves, and adversarial testing for prompt injection [4].

Put all five inside one supervisor's prompt and it is not really five planes — it is one very stressed chef doing everyone's job at once. And that is usually the table where dinner goes wrong.

§ 04Agents need contracts, not personality prompts.

Agents should not be defined by a personality, to be honest. "You are a brilliant, meticulous senior engineer who deeply cares about quality" is a lovely sentence that constrains pretty much nothing — it is the prompt version of hiring someone by telling them to "just be great" and hoping for the best. A contract works far better: an actual job description that says what the agent may touch and, more importantly, what it may not.

agent:
  id: verifier.payment_policy.v1
  role: independent_verifier
  allowed_tools:    [policy_lookup, transaction_limit_checker]
  forbidden_tools:  [payment_execute, database_write]
  output_schema:
    decision: approve | reject | repair | escalate
    risk_score: number
    human_approval_required: boolean

Allowed tools, forbidden tools, input and output schemas, budget and retry limits, escalation rules. The narrower the boundary, the easier the 2 a.m. debugging. A verifier that physically cannot call payment_execute is not going to pay anyone by accident — and honestly, you would be surprised how reassuring "physically cannot" feels at 2 a.m.

§ 05Orchestration patterns, and when to use them.

No single pattern wins everything. Real systems mix a few, depending on the risk, the latency, and how much it stings when something fails.

• Hierarchical supervisor — one boss breaks the mission down, hands bounded tasks to specialists, and a verifier checks the work. The safest default for SaaS, fintech, legal-tech and healthcare. Pretty easy to audit, though the supervisor can become a bottleneck (every team has met this bottleneck, and sometimes it has a name).
• Blackboard — agents post to a shared, structured workspace. Pretty lovely for research and diagnostics, as long as every note carries its evidence, author, confidence and verification status. Skip that and the workspace slowly becomes a group chat, with everything that implies.
• Event-driven mesh — an event bus decouples who produces from who consumes. Scales nicely, but cause-and-effect gets a bit slippery unless traces are mandatory. OpenTelemetry's traces, metrics, logs and baggage [2] map onto this almost one-to-one.
• Auction or market — agents bid for work by capability, cost, latency and risk; pretty common in robot fleets [6]. One rule: never allocate on speed or cost alone. Fast, cheap and unsafe is a real option, and the system will happily pick it for you if you let it.
• Hybrid — what everything turns into eventually, and honestly that is fine.

To stop "cheap" from quietly winning the auction, I score the candidates with a weighted thing rather than a single number — capability and confidence pull up, cost, latency and risk pull down:

Score = 0.30·C + 0.20·Q − 0.20·K − 0.15·L − 0.15·R

C capability, Q confidence, K cost, L latency, R risk.

§ 06The harness layer, in a bit more detail.

The harness is the piece that makes a probabilistic agent behave inside boundaries that are not. A reasonably complete one carries identity and access control, tool whitelists, data egress controls, output validation, risk scoring, budget ceilings, approval gates, sandboxed execution, rollback and an immutable audit log. LangGraph's docs put durable execution, persistence, human-in-the-loop and runtime visibility right at the centre for pretty much the same reasons [3].

In plain terms, the runtime gate is a bouncer with a checklist:

None of it is exciting, honestly, and that is exactly what you want sitting between a probabilistic agent and your production database. And if you want to know what this looks like in actual tools rather than boxes, here is the boring, dependable stack — nothing exotic, on purpose:

§ 07Verification, and why the executor cannot check itself.

This is the step everyone skips and then quietly regrets. Verification has to be independent and weighted by risk — because asking the agent that did the work to confirm the work is a bit like asking a student to grade their own exam. The results are wonderful, and honestly not trustworthy at all.

A read costs you a schema check. A payment costs you a human in the loop. That is pretty much the whole trick: the more a mistake would hurt, the more it has to survive before it counts.

§ 08State, memory, and planning for failure.

Multi-agent systems wobble the moment "state" gets fuzzy. It helps to keep three layers — a local working memory, a shared mission workspace, and one canonical state that holds the truth. And agents do not get to edit the truth directly. They propose a change, and the harness verifies it and then commits it — a bit like how you cannot just walk into the bank and rewrite your own balance; you submit a transaction and let the system decide. (Agents opening pull requests against reality, if you like.)

Also, please design the sad path before throwing a party for the happy one.

Every mission, task, tool call and decision carries a trace id. Once the agents start acting asynchronously, "what just happened" turns into a proper distributed-systems question, and a trace record is pretty much the only honest answer to it:

{
  "trace_id": "trace_abc",
  "mission_id": "mission_001",
  "agent_id": "planner.v2",
  "tool_name": "database.write",
  "policy_bundle": "policy.finance.v3",
  "risk_score": 0.72,
  "decision": "request_human_approval",
  "latency_ms": 1200,
  "retry_count": 1
}

§ 09The autonomy maturity ladder.

Most teams will tell you they are running L4. So will most demos, to be honest. The honest difference between L2 and L4 was never the number of agents — it is governance, verification, state, observability and recovery, which is to say, all the parts that do not demo well.

There is no shame in sitting at L2, honestly. The shame is in putting "L4" on the slide.

§ 10Where this pays off: agentic coding.

This is where the whole thing starts paying rent. The point of agentic coding is not faster code — it is faster product, without quietly trading away quality, security or trust along the way. A real product is auth, tenant isolation, billing, observability, audit logs, rollback and cost control. The screens are the easy 20%; the other 80% is the part that pages you on a Saturday.

So you give each concern its own agent with its own contract — Product, UX, Architecture, Backend, Frontend, QA, Security, DevOps — and a Verifier that refuses to ship if tests, tenant isolation or audit logging are missing. Think of it less as one genius doing everything and more as a small, slightly bureaucratic factory: every station has one job, and someone signs off before the next station starts.

Underneath, it runs as a mission-to-commit loop: intake, then a policy check, then a task graph, then specialist work, then independent verification, then commit, then a trace. The important bit is that state only gets written after something other than the author has checked it.

And there is one rule I keep coming back to.

MCP standardises how agents reach files, databases and tools [5] — which is great, and honestly also pretty much exactly why least privilege and tool isolation matter more, not less, once everything is one connector away.

§ 11A few rules I try to follow.

If you ignore everything else, keep these. I have learned most of them the slow way, to be honest.

1. Start hierarchical before reaching for swarm behaviour.
2. Define the canonical state before building agent memory.
3. Define the contracts before writing the prompts.
4. Add verification before adding more agents.
5. Keep planning, execution and approval separate.
6. Trace every agent and every tool call.
7. Treat all external content as untrusted.
8. Sandbox code execution and browser automation.
9. Put a human gate on the high-impact actions.
10. Optimise for recoverability, not for the demo.

§ 12So, in the end.

Multi-agent systems are not powerful because they are crowded. They get powerful when responsibilities are split cleanly, autonomy is bounded, authority is explicit, state is coherent, verification is independent, and failure is recoverable. Take those away and "more agents" just means more confident output that nobody checked — and confident-but-wrong is a pretty painful way to be wrong.

This was the easy-reading version. The full paper has the complete reference architecture, the mission-to-commit and recovery diagrams, the agent-contract, event-envelope and state-transition schemas, the implementation stack and the autonomy table — basically all the detail I only waved at here. If it saves you even one 2 a.m., that is a win. And if you are building one of these and want to argue about any of it, you can always reach me at sagnik@sgnk.ai — I have some good discussions to be done with you :) — Sagnik

§ ReferencesWhere this comes from.

§ CiteHow to cite this work.

If this informed your thinking, you can cite it as:

Plain text: