Why
Multi-agent systems are usually framed as a coordination problem. In production most of the pain is narrower than that: agents exchange prose, and prose is opaque to every part of the system except a language model. Nothing else can validate it, route on it, enforce it, or aggregate it.
What a prompt actually carries
A planning agent delegating to a research agent typically sends something like this:
Please research the tradeoffs between approach A and approach B.
Keep it under 400 words. Focus on operational cost. Don't use
external tools. When you're done, reply with "Final Answer:"
followed by your recommendation.Four concerns are collapsed into one string. Only the first belongs there:
- An objective. Genuinely a natural-language instruction, and it should stay one.
- An output constraint. Unenforceable by the sender, discoverable only by inspecting the reply, after the tokens are spent.
- A capability restriction. This one deserves scrutiny, because it reads as a rule and functions as a suggestion. If the receiving agent has tools bound, no code path prevents their use. There is no enforcement point — only a sentence addressed to a model.
- A completion protocol. The literal string
Final Answer:now determines downstream control flow, because something is matching on it. It has no schema, no version, and no test that fails when the prompt is reworded.
flowchart LR
P["One prompt string"] --> O["Objective"]
P --> L["Under 400 words"]
P --> T["No external tools"]
P --> C["Reply with<br/>'Final Answer:'"]
O --> OM["Prompt builder<br/>belongs here"]
L --> LM["Nowhere.<br/>No enforcement point"]
T --> TM["Nowhere.<br/>No enforcement point"]
C --> CM["Nowhere.<br/>Convention in English"]
class P context
class O,OM model
class L,T,C check
class LM,TM,CM refusal
That last one is the clearest structural defect. Two agents are coupled through a convention encoded in English, inside a prompt, owned by neither and protected by no type system. It is the same class of error as parsing HTML with a regular expression, and it degrades the same way: correct until the input shifts slightly, then wrong in a manner that is expensive to trace.
Four properties prose cannot support
Constraints are unenforceable
A constraint is only a constraint if something other than the constrained party enforces it. When "do not include personal data" lives in the prompt, the enforcement mechanism is the model's cooperation.
Consider the ordinary case: the model is summarising a document that contains personal data, having been instructed to omit it. You are relying on it to notice the conflict and resolve it in your favour. It usually will. A compliance rate is not a control — at production volume it is a prediction of how many incidents you will have, not whether you will have any.
Once that restriction is a structured field, admission control compares it against policy before invocation, and an output scanner checks the result before it crosses the boundary. Neither component needs to be intelligent, which is precisely the property you want in a control.
Dispatch cannot depend on intent
Drafting and reviewing are different operations with different risk profiles. Drafting benefits from a capable model and some sampling temperature. Review wants determinism, an independent model so it is not grading its own output, and no tool access at all.
Delivered as prose, the two are indistinguishable to the runtime, so both receive whatever the framework was configured with — in practice the expensive configuration, everywhere, on the grounds of safety.
Completion is undefined
Without a declared contract, completion is a judgement made after the fact. The common resolution is a reviewer agent whose prompt restates what the first agent should have been told. The two descriptions drift, because no shared artifact constrains either.
Worth noticing: the contract already exists in these systems. It is distributed across two prompts and one engineer's recollection.
Telemetry is uninformative
Invocation counts, token totals, and latency percentiles have the shape of observability without the substance, because they aggregate operations with nothing in common.
The questions a platform team actually needs answered are per-intent: is verification retrying more than drafting, which policy ceiling is being hit, what does each capability cost per run, which acceptance criterion fails most often. Every one requires intent to be a field rather than a paragraph.
"This is structured prompting with extra steps"
The most reasonable challenge, and it deserves a measurement rather than a definition.
Partition a frame into the fields the prompt builder may read and the fields it may not, then count. In the reference implementation, five of thirteen top-level sections contribute any prompt text. The remaining eight — constraints, acceptance criteria, quality requirements, failure policy, handoff, metadata, capability, intent type — are consumed by code that never calls a model.
Structured prompting reorganises the text entering an inference call. A frame mostly specifies the conditions under which that call is permitted to happen and what will constitute an acceptable result.
There is a sharper form of the distinction. Certain fields are deliberately withheld from the model:
- A personal-data exclusion check is not advertised, because the source artifact contains personal data and instructing the model to abstain is exactly the advisory control the specification exists to replace. The check runs on the output regardless.
- A confidence threshold is not advertised, because a model told the bar clears it rhetorically. You asked for better work and received a more assured register.
A structured prompt has no coherent way to express "this field exists and the model must not observe it." A contract does, because a contract has more than one reader.
What adoption actually costs
A proposal listing only benefits is marketing. These are the real ones.
Schema versioning becomes your problem
Frames are contracts and contracts change. You need a version field, a compatibility policy, and a defined behaviour for a receiver handed a minor version it only partly understands. Prompt-passing lets you skip this work by failing silently instead.
Capability registries need an owner
Addressing capabilities rather than agent instances only helps if something authoritative resolves capability names to implementations. That registry is infrastructure: it has an owner, a deployment story, and a staleness problem.
Criteria must compile to checks
"Contains a clear recommendation" is not evaluable. Expressing acceptance criteria as typed checks is genuine design work, and it is where most of the adoption effort lands.
It is also where most of the value is. Writing the check forces the caller to decide what it actually wanted, a question that frequently turns out never to have been answered.
More surface between request and response
Admission control, artifact resolution, dispatch, validation, and repair are all code, and code has defects. For a two-agent prototype the overhead is not worth paying. Break-even arrives with the first production incident nobody can reconstruct afterwards.
Frames do not reduce hallucination, improve reasoning, or establish truth. A frame can require that a summary contain a recommendation section; it cannot make the recommendation sound. Everything in scope here is an interface problem.
Why a standard rather than a framework feature
Most agent frameworks already model a structured task. Those models are not interoperable, and each is coupled to its framework's execution model. An agent written for one cannot be invoked by another without a translation layer, and translation layers discard precisely the guarantees worth having.
The web resolved the equivalent problem by separating layers. HTTP moves bytes and knows nothing of their meaning. OpenAPI describes what an endpoint accepts and returns, independent of any server framework. JSON Schema validates payloads, independent of both. A service written in one language is callable from any other because the contract sits outside all of them.
Agent systems have a transport story and a rapidly improving tool-calling story. The gap is the middle: a description of a single interaction's semantics, owned by neither party, that both can validate against. That is the whole of the ambition.
Where this pays off → · How to implement it → · Specification →