Why send schema-validated payloads between agents instead of free-text messages?

## The problem with free text at a seam When agent A sends agent B a paragraph, there is still a contract between them — it is just written nowhere and enforced by nothing. A stops emitting the delivery date; B keeps running. A renames "unit price" to "price per unit"; B keeps running. A hedges ("roughly 1,200, possibly in euros"); B keeps running. In every case the system does not fail loudly, it degrades quietly, and the defect surfaces several steps later as a wrong answer whose cause is expensive to trace. This is the central argument for structured payloads between agents: **turn a silent degradation into a loud, local failure.** ## What a schema actually gives you A schema — in practice JSON Schema, because it is what tool and agent ecosystems already speak — declares: - **Which fields must be present** (`required`), so an omission is an error rather than a default. - **Types**, so `quantity: "a dozen"` is rejected before anyone reasons about it. - **Enums and ranges**, so `currency` must be one of a known set and `quantity` must be a positive integer. - **Shape of nested objects and arrays**, so a list of line items cannot arrive as a single blob of prose. Two properties matter more than the list itself. First, validation is **deterministic and free**: it is a library call, not a model call, so it costs no tokens, adds a millisecond, and cannot itself be wrong in the way a judging model can. Second, the error is **specific**: "required property `currency` is missing at `/items/0`" is something the producing agent can act on, unlike "that didn't look right". ## A concrete rejection A procurement intake agent builds a `QuoteRequest` from an unstructured purchase request and sends it to a negotiation agent. The buyer's email said "120 units of SKU-4471, need it in two weeks" and never mentioned a currency. The intake agent, generating JSON from free text, simply omits the field. With a schema, the negotiation agent's boundary rejects the payload immediately and returns an error naming `currency`. The intake agent can then do the right thing: ask the user, look up the buyer's default, or fail the request explicitly. Without a schema, the likely outcome is that the model on the other side assumes dollars, negotiates a contract in the wrong currency, and nobody notices until reconciliation. Note what the boundary should *not* do: it should not guess. Silently defaulting `currency` to USD and logging a warning is how a validation layer becomes a source of bugs — it converts an error the system could have surfaced into data the system now believes. ## Where validation belongs Validate on the **receiving** side, always — that is your trust boundary, and the sender's promises are not enforcement. Validating on the sending side too is a cheap extra: it catches the model's own malformed generation before it crosses the wire, where the fix is local and the context that produced it is still available. Many stacks also constrain the model at generation time (structured-output or strict schema modes), which reduces malformed payloads but does not remove the need for the receiver's check — the message may have crossed a network, a queue, or an organizational boundary since. Treat an incoming agent message as **untrusted input** regardless of schema conformance. Schema validity says nothing about authorization, and a well-formed payload from an agent you did not expect to hear from is still an attack surface. ## What a schema cannot check This is the half of the answer that separates a middle from a senior response: - **Semantically wrong but structurally valid.** `unit_price: 12.40` when the real quote was 1240.00 passes every check. - **Hallucinated values.** A model asked to fill a schema will fill it — a required field is pressure to invent, not permission to omit. Optional fields plus an explicit `unknown` signal often produce more honest payloads than making everything required. - **Cross-field consistency**, unless you encode it: `delivery_date` before `order_date` needs a business rule, not a type. - **Stale or unauthorized data.** Freshness and permission live outside the schema. So the layered answer is: schema validation at the boundary for shape, business rules for consistency, and verification against a source of truth for anything consequential. ## The cost Schemas are not free. They must be versioned and evolved on both sides, and inside one codebase where both agents deploy together, a shared typed object is usually enough — a formal schema earns its keep when the two ends are released independently or owned by different teams. Overly rigid schemas also constrain what agents can express; a common compromise is a small typed envelope (identity, task id, structured fields) around a free-text section for genuinely open content.