How do you catch semantic misalignment when two agents both report success?

## What semantic misalignment is Semantic misalignment is the situation where two agents in a fleet operate on the same words while holding different meanings for them. The planner writes "stage"; it means the pre-production environment. The executor reads "stage"; it means a step in the build pipeline. Both agents do competent, internally coherent work. Both report success. The composed result is wrong, and nothing in the run signals it. It is the coordination failure that matters most in practice — more than deadlock, more than races. Deadlock is loud: work stops and a deadline fires. A race corrupts state in ways that verification and diffs can surface. Misalignment produces a clean run with a wrong answer, which is the most expensive kind of failure because it is discovered downstream, often by a user. ## Why multi-agent designs are structurally prone to it The handoff medium is natural language. Prose is expressive and lossy at the same time: it carries intent well enough for humans who share context, and terribly for a receiver that has none. Compounding this, the isolation that makes multi-agent designs pay — giving each subagent its own clean context rather than the orchestrator's full history — is exactly what removes shared grounding. The subagent gets a paragraph where the orchestrator had a conversation. Every ambiguity in that paragraph is resolved by the subagent's priors, not by the task's actual intent. Three recurring sources: - **Underspecification.** The subtask omits a constraint the orchestrator considered obvious. The worker fills it in, plausibly and wrongly. - **Overloaded vocabulary.** Domain words with multiple readings — stage, environment, customer, order, run, ticket, job — resolved differently on each side. - **Long-horizon drift.** Over many steps, the working definition an agent holds slides away from the original, especially after summarization or compaction, and no single step looks wrong. ## Detection The governing rule: never treat an agent's claim of success as evidence of success. A misaligned agent is not lying; it genuinely satisfied its own criterion. **Verify the artifact, not the report.** Take the produced output and check it against the original request. Where a programmatic check exists — a test, a schema, a dry-run plan, a type check, a query that counts rows — use it, because it is deterministic and cheap. Where the check must be judgemental, use a separate reviewer agent, and give it the original request plus the artifact, deliberately *not* the producing agent's trajectory. A reviewer that reads the producer's reasoning tends to be persuaded by it and inherits the same misreading; one with a clean context is the whole point of the generator-verifier split. **Surface disagreement explicitly.** Before work starts, have each worker restate its subtask, the key terms and its acceptance criteria in its own words. Diff those restatements against the plan. This is a small number of tokens and it catches the overloaded-vocabulary class before any work is wasted. **Assert invariants.** Properties that must hold of the joint result regardless of interpretation — the environment touched, the resource count, the schema version, referential integrity across the artifacts different agents produced. An invariant violation is a hard signal where two success reports are not. **Watch for the fingerprint.** Two agents describing the same object with different nouns, mismatched identifiers across handoffs, or a result that is internally consistent but answers a question nobody asked, all read as misalignment rather than tool failure. Tool failures produce errors; misalignment produces coherent wrongness. ## Prevention, which is where the leverage is **One frozen referent.** A plan artifact accepted before fan-out, which every worker cites. Disagreement then happens once, in front of the orchestrator, rather than N times in private. **Typed handoffs.** Replace prose parameters with enumerated values and stable identifiers: an environment field constrained to a known set, a resource ID rather than a name, a version rather than "latest". This converts an entire class of ambiguity into a validation error at the boundary — the receiving side either matches the contract or fails loudly. **Orchestrator-written acceptance criteria.** Each dispatched subtask carries a checkable definition of done, written by the component that holds the whole picture. "Done" defined by the worker is defined by the worker's interpretation. **Return artifacts, not claims.** A subagent that hands back a diff, a file, or a structured record gives the orchestrator something to inspect. One that hands back "completed successfully" gives it nothing. **Single-writer discipline as containment.** When workers can only propose, a misaligned worker produces a rejected proposal instead of corrupted shared state. ## Honest limits Verification costs tokens, and thorough cross-checking can approach the cost of the work itself — one reason single-agent designs sometimes match multi-agent ones at equal budget. Judgemental verification is itself fallible, and correlated: a verifier sharing the producer's model, prompt framing and context can share its blind spot. The mitigations are to prefer deterministic checks wherever one exists, to vary the verifier's context, and to accept that for genuinely ambiguous requests the right move is to escalate the ambiguity rather than let an agent resolve it silently.