Six Agent Alignment Patterns the Industry Has Not Published

A practitioner meta-review found six production-born patterns — evidence gates, hallucination taxonomies, runtime correction injection, certainty routing, verification contracts, and hooks as governance — that have no equivalent in published frameworks from Anthropic, Google, OpenAI, or Microsoft.

Technique · Next AI Labs · Human-Agent Research · 18 min read

We ran a systematic meta-review comparing our agent alignment infrastructure against published best practices from Anthropic, Google DeepMind, OpenAI, and Microsoft. The review covered agent frameworks (Anthropic's agent patterns, Google A2A, OpenAI Swarm, Microsoft AutoGen), safety guidelines (Anthropic's constitutional AI principles, Google's AI principles, OpenAI's safety frameworks), and operational playbooks from teams running agents in production.

We found six patterns — each one built from a real production failure — that have no published equivalent in any of the frameworks we reviewed.

This is not a claim of superiority. These are patterns born from necessity. We built them because agents broke things in ways that existing frameworks did not prevent. Some of these patterns are ugly. All of them are reproducible.

The Risk Landscape

Before describing the patterns, it helps to understand what goes wrong when autonomous agents operate without them.

Agents confidently assert false things. Not occasionally — routinely. One of our agents fabricated a 28x CAC-to-LTV ratio and propagated it into six articles before a human noticed. The number was plausible, well-formatted, and cited with apparent authority. It was also completely made up.

Agents lose human intent mid-task. A user says "make this faster." The agent interprets "faster" as "remove the validation step." The user meant "optimize the database query." The agent's interpretation was reasonable. It was also wrong. And because the agent never surfaced its interpretation for confirmation, the error compounded through three subsequent implementation decisions before detection.

Agents claim completion without verification. "Tests pass" when no tests were run. "Endpoint returns 200" when no request was made. "The fix is deployed" when the code was written but never committed. These are not lies — the agent genuinely believes it has completed the work. The problem is structural: nothing in the standard agent loop requires proof.

Mistakes compound across sessions. A correction made in session 47 is forgotten by session 48. The same error recurs. The human corrects it again. And again. Each correction costs human attention. The agent never gets smarter because it has no mechanism to carry corrections forward.

These are not hypothetical risks. They are things that happened to us, repeatedly, until we built the systems described below.

Pattern 1: The Evidence Gate

Every published agent safety framework we reviewed treats verification as a recommendation. "Agents should verify their outputs." "Include a review step." "Consider adding human oversight."

We tried recommendations. They did not work.

The failure mode is specific: when an agent is 2,000 tokens into a task and reaches the completion step, the instruction "verify your work before reporting completion" competes with the momentum of the conversation. The agent has context, it has a plan, it has produced what looks like a solution. Stopping to run a test or make a request introduces friction. In our measurements, agents skipped verification in roughly 40% of cases when it was framed as an instruction.

So we moved verification out of the model's decision space entirely.

The evidence gate is a shell script that fires at the OS level when an agent attempts to stop. It inspects the conversation transcript for a specific pattern: did the agent make a runtime claim ("works," "tests pass," "returns 200," "is live") AND did the transcript contain actual execution evidence (a curl response, test output, a database query result)?

If the agent made a claim without evidence, the script exits with code 2. This is a blocking exit — the agent cannot complete its turn. It receives a message explaining what evidence is missing and must go produce it.

The critical design decision: the gate does not evaluate whether the evidence is good. It checks whether evidence exists. "I read the code and it looks correct" does not count — that is reasoning, not evidence. A curl response with a 500 error counts — it is evidence, even though it shows failure. The gate enforces the act of checking, not the outcome.

Agent claims "endpoint returns 200"
         |
    [Evidence Gate fires]
         |
  Was a real request made? ──── No ──→ exit 2 (BLOCKED)
         |                              Agent must make the request
        Yes
         |
  Evidence exists in transcript ──→ Agent may complete

What we learned: The rate of unverified completion claims dropped from roughly 40% to near zero. More surprisingly, agents started structuring their work differently — running verification earlier in the process rather than treating it as a final step. The gate changed the agent's workflow, not just its completion behavior.

Why this has no published equivalent: Every framework we reviewed operates at the instruction level. Anthropic's agent patterns describe verification as part of the agentic loop. Google's A2A protocol defines task lifecycle states (submitted, working, completed) but has no mechanism to validate what "completed" means. OpenAI Swarm handles agent handoffs but not completion proof. None of them use operating system primitives to enforce behavior the model cannot override.

Pattern 2: A Named Taxonomy of Hallucination

The industry treats "hallucination" as a single failure category. This is like treating "infection" as a single disease. The word describes a symptom — the agent stated something false with confidence — but tells you nothing about the mechanism, the propagation pattern, or the fix.

We tracked every hallucination incident across 7,400+ agent sessions and classified them by root cause. Seven distinct failure modes emerged, each requiring a different intervention.

Number inflation. The agent takes a real number and inflates it. Not randomly — in a specific direction. "100+ corrections" becomes "300+ corrections." A count of 533 becomes 1,337. The inflation tends toward rounder or more impressive numbers. The fix is not "be more careful with numbers" — it is requiring agents to query the source of any number before stating it.

Source fabrication. The agent cites a source that does not exist. In one case, an agent attributed a framework to Barabasi's network science work and cited "Confucian-Ubuntu philosophy" — neither reference existed in any input the agent had received. The agent was not lying; it was pattern-matching on what sounded authoritative for the topic. The fix requires provenance tracking: every cited source must trace to a specific input document.

Metric propagation. A fabricated number enters one document and then propagates. Our worst case: a made-up 28x CAC-to-LTV ratio appeared in a single internal analysis. Because agents read each other's outputs, the number was subsequently cited in six downstream articles as established fact — each citation lending it more apparent authority. By the time a human caught it, the number had become "well-known" within the agent corpus. The fix is a hallucination taxonomy approach: flag any metric that appears in multiple documents but has no primary source.

Confidence laundering. The agent takes an uncertain estimate ("we think this might be around 30%") and, through successive restatements, drops the hedging. By the third reference, "might be around 30%" has become "the 30% rate" — stated as established fact. Each restatement is individually reasonable. The cumulative effect is that uncertainty disappears. The fix requires preserving confidence qualifiers through citation chains.

Completion hallucination. The agent states that a task is done when it is not. "Tests pass" when no tests were run. "Deployed" when the code was committed but not pushed. This is what the evidence gate was built to catch, and it is the most dangerous type because it directly corrupts the human's model of system state.

Intent substitution. The agent replaces the human's stated intent with a related but different intent that the agent finds easier to satisfy. "Make this accessible" becomes "add ARIA labels" — a reasonable interpretation that is not what the human meant. The danger is that the substitution is plausible enough that neither the agent nor a casual reviewer catches it.

Temporal confusion. The agent conflates what was true, what is true, and what is planned to be true. A feature that was discussed as a future plan gets described as implemented. A bug that was fixed gets described as still present. The agent has no temporal model of the codebase — everything in its context is equally "now."

Each of these failure modes has a different detection strategy and a different fix. Treating them as one category — "hallucination" — is like treating all infections with the same antibiotic.

Pattern 3: Runtime Correction Injection

The standard approach to improving agent behavior is training-time intervention: RLHF, constitutional AI, fine-tuning. These methods work. They also require access to model weights, significant compute, and weeks of iteration.

We needed something that works at runtime, with the model as-is, and improves within hours rather than weeks.

The correction injection system works like this: when a human corrects an agent, the correction is stored as a structured database record — not a chat message, not a note, but a record with fields for the trigger context (what was the agent doing when it made the mistake), the correction (what the human said), and the fix (what the agent should do instead).

Each record tracks an evidence count. When the same correction pattern appears in three or more distinct sessions — confirmed across different tasks, not just repeated in one conversation — the correction graduates to auto-injection status.

Auto-injection means: the next time an agent enters a context that matches the trigger, the correction is injected into the agent's context window before it starts working. The agent does not need to remember the correction. The infrastructure remembers for it.

The system currently holds 8,500+ corrections from 7,400+ sessions. Graduated corrections cover patterns like: "never state a metric as fact without querying its source," "never interpret 'make it faster' without confirming what 'faster' means," "never remove code that looks unused — it may be scaffolding for an upcoming feature."

Graduated enforcement. Not all corrections are equal. The system tracks three enforcement levels:

• Level 1: The correction is injected as context. The agent sees it and can choose to follow it.
• Level 2: The correction is injected with explicit framing — "This correction has been confirmed across N sessions. Following it is required."
• Level 3: The correction triggers an evidence gate check — the agent must demonstrate compliance, not just acknowledge the directive.

Enforcement escalates based on honor rate. If agents follow a Level 1 correction 90%+ of the time, it stays at Level 1. If the honor rate drops below a threshold, the system automatically escalates to Level 2 or 3.

The compound effect. Each correction makes every future session slightly better. Session 1,000 is measurably more aligned than session 100 — not because the model improved, but because the correction corpus grew. This is compound learning applied to alignment: the system gets smarter without retraining.

What the industry has instead: RLHF (training-time, requires weight access), constitutional AI (training-time, requires model provider), prompt engineering (manual, does not compound). None of these provide runtime correction injection that automatically escalates enforcement based on observed compliance.

Pattern 4: Certainty as a Routing Variable

Every published agent framework we reviewed treats agent confidence as invisible. The agent has an internal sense of how certain it is about a task — but this sense is never exposed, never measured, and never used to gate behavior.

We make certainty routing explicit. At every decision point, the agent produces a certainty score from 0 to 100. This score is not confidence in its own ability — it is confidence that it understands what the human wants.

The distinction matters. An agent can be highly capable and completely misaligned. "I can definitely build this feature" is irrelevant if the agent misunderstands which feature to build.

The certainty score routes to different governance depths:

Certainty 95-100: Proceed. Requirements are unambiguous.
Certainty 85-94:  Proceed with stated assumptions. Validate them.
Certainty 70-84:  Reflect first. Assumptions are fuzzy.
Certainty 60-69:  Dispatch independent evaluator.
Certainty 50-59:  Write a plan before implementation.
Certainty 20-49:  Declare scope before starting.
Certainty 0-19:   Predict most likely intent. Propose it. Proceed.

The counterintuitive rule at the bottom of the scale: When certainty is very low, the agent does not stop and ask. Asking an open question ("what do you want?") puts the cognitive burden on the human. Instead, the agent predicts the most likely intent, proposes it as a default, and begins acting on it. The human corrects a wrong proposal faster than they answer an open question.

This inverts the standard pattern. Most frameworks say: low confidence means ask for clarification. We found that low confidence means make your best prediction explicit and act on it — because the act of proposing a specific interpretation gives the human something concrete to react to.

The independent evaluator at score 60-69. When certainty is moderate, the system dispatches a second agent — one that has no access to the first agent's reasoning — with only the verification contract and the code diff. This evaluator runs the verification commands independently and returns structured pass/fail results. The generator and evaluator never share context, which prevents the "I think my own work looks good" failure mode.

Why this has no published equivalent: Anthropic's agent patterns describe planning and reflection loops. OpenAI Swarm defines handoff conditions. Google A2A has task states. None of them expose agent certainty as a runtime variable that gates behavior. The score is invisible in every published framework.

Pattern 5: Verification Contracts

A verification contract is a set of falsifiable statements generated before any code is written. Each statement follows the form: When {specific conditions} Then {testable UX outcome}.

Example for a checkout flow fix:

• When a user clicks "Subscribe" with a valid card, the Stripe session creates within 3 seconds
• When the payment succeeds, the user's access tier updates to FULL_ACCESS before the redirect completes
• When the payment fails, the user sees a specific error message — not a blank screen or a generic 500

These are not aspirational goals. They are the acceptance criteria. At task completion, the evidence gate checks whether the agent produced evidence for each contract item. "Tests pass" is not sufficient — the specific scenarios in the contract must be demonstrated.

The contract serves three functions:

Alignment lock. The contract is generated at the moment when the agent and human agree on what "done" means. It captures that agreement in falsifiable form. When the agent is 2,000 tokens deep in implementation, it can reference the contract instead of trying to reconstruct the original intent from memory — which is where intent drift typically begins.

Scope boundary. The contract says what is in scope and, by omission, what is not. An agent that starts optimizing database queries when the contract says nothing about performance is visibly out of scope. Without a contract, scope creep is invisible until someone notices the agent has been working on the wrong thing for an hour.

Evaluator input. When the system dispatches an independent evaluator (at certainty scores of 60-69), the evaluator receives only the contract and the diff. No access to the generator's reasoning, no shared context. The evaluator's job is to run the contract's verification commands and report whether each item passes or fails. This structural separation prevents self-assessment bias.

What the industry has instead: Google A2A defines task lifecycle states — submitted, working, input-required, completed — but these describe progress, not content. There is no mechanism to say what "completed" means for a specific task. OpenAI Swarm defines handoff protocols between agents but not completion criteria. Anthropic's patterns describe evaluation loops but do not formalize the evaluation criteria as pre-task contracts.

Pattern 6: Hooks as a Governance Layer

The most counterintuitive pattern: the majority of our agent governance is not implemented in prompts, instructions, or agent code. It is implemented in shell scripts.

We run 29 hooks as governance that fire at specific lifecycle events: before a tool is used, after a tool completes, when an agent attempts to stop, when a subagent finishes, when a session starts, when a session ends, when a user submits a prompt. Each hook is a shell script that can inspect the event, modify the context, or block the action.

The evidence gate described in Pattern 1 is one of these hooks. But the pattern extends far beyond verification:

• A hook fires on every user message and injects governance scoring, alignment gates, and task tracking context — before the agent sees the message.
• A hook fires after every bash command and detects failure streaks — three consecutive failures trigger an automatic diagnostic injection.
• A hook fires when a subagent completes and checks whether the subagent's output aligns with the parent's scope declaration.
• A hook fires at session end and automatically captures a structured compaction of the session's work — solving the persistence gap that we described in a previous article.

Why shell scripts? Because they run outside the model's decision space. A prompt instruction that says "always check for security vulnerabilities before committing code" is a soft gate — the agent may or may not follow it, depending on context window pressure, task momentum, and the model's own prioritization. A shell script that runs exit 2 when a security scanner finds issues is a hard gate. The agent cannot override it. The agent cannot forget it. The agent does not need to be convinced.

The architecture:

User message arrives
        |
   [PreToolUse hooks] ──→ Can block tool execution
        |
   Agent processes
        |
   [PostToolUse hooks] ──→ Can inject diagnostics
        |
   Agent attempts to stop
        |
   [Stop hooks] ──→ Evidence gate, completion protocol
        |                (blocking — exit 2 = cannot stop)
        |
   Session ends
        |
   [SessionEnd hooks] ──→ Auto-compaction, correction capture

The governance escalation model. Not everything needs a hard gate. The hooks implement a spectrum:

• Inject — Add context that the agent sees but can ignore (most hooks)
• Warn — Add context with explicit "this is required" framing (escalated corrections)
• Block — Exit nonzero; the agent cannot proceed until the condition is met (evidence gate, security scanner)

Most hooks inject. A few warn. Only the most critical block. This is deliberate — blocking everything would make the system unusable. The art is in choosing which rules are worth the friction of enforcement.

What the industry has instead: Nothing, as far as we can find. Published agent frameworks operate entirely within the model's context. Rules are instructions. Guardrails are prompts. Safety checks are tool calls that the agent decides whether to make. The idea of using operating system primitives — exit codes, shell scripts, process lifecycle events — as an agent governance layer appears to be novel.

How These Patterns Interact

The six patterns are not independent. They form a reinforcement loop:

1. certainty routing determines governance depth at task start
2. verification contract locks alignment into falsifiable criteria
3. hooks as governance enforce the rules throughout execution
4. evidence gate enforces proof at completion
5. hallucination taxonomy classifies failures that get through
6. correction injection ensures failures improve future sessions

Each pattern covers a gap that the others leave open. Verification contracts prevent intent drift but cannot enforce themselves — the evidence gate does that. The evidence gate catches unverified claims but cannot prevent the underlying mistakes — correction injection addresses that. Correction injection improves over time but cannot handle novel failure modes — the hallucination taxonomy provides the classification framework for new patterns.

Remove any one piece and a specific class of failure returns.

What We Reviewed

The meta-review covered:

• Anthropic: Building effective agents (2025), constitutional AI documentation, Claude agent patterns, model spec
• Google DeepMind: Agent-to-Agent (A2A) protocol, Gemini agent safety documentation, responsible AI practices
• OpenAI: Swarm framework, agent safety guidelines, preparedness framework
• Microsoft: AutoGen framework, responsible AI standard, AI red team practices

For each framework, we mapped every recommended practice to our implementation and flagged gaps in both directions — patterns they recommend that we lack, and patterns we implement that they do not describe. The six patterns above are the ones where the gap was entirely one-directional: we have them, no published framework describes them.

We also found patterns in the published frameworks that we had not implemented. This review was not a victory lap — it was a gap analysis. The frameworks we reviewed are excellent. They simply operate at a different layer of the stack.

What We Still Don't Know

These are real open questions, not performative humility.

Does correction injection plateau? Our corpus is at 8,500+ corrections. The correction-per-session rate has declined, which could mean the system is converging on comprehensive coverage — or it could mean agents are learning to avoid triggering corrections without actually improving alignment. We cannot yet distinguish between these explanations.

Are our hallucination categories complete? Seven failure modes emerged from 7,400+ sessions. A different domain — medical, legal, financial — would almost certainly surface additional categories. We do not know whether our taxonomy generalizes or whether it is specific to the software engineering and coaching domains where we operate.

What happens when hooks conflict? With 29 hooks, we have not yet encountered a case where two hooks issue contradictory directives. But the system has no formal conflict resolution mechanism. As the hook count grows, this becomes increasingly likely.

Is certainty-routing calibrated correctly? The thresholds (20, 50, 60, 70) were set based on observed failure rates, not derived from theory. A task scored at 55 gets a plan requirement; a task scored at 45 does not. The boundary is arbitrary. We have not run controlled experiments to determine optimal thresholds.

Would these patterns work with different models? Our entire system runs on one model family. The evidence gate is model-agnostic (it inspects transcripts, not model internals), but correction injection depends on the model responding consistently to injected context. A model with different instruction-following characteristics might require different enforcement levels.

Can the evidence gate be gamed? An agent could, in theory, make a trivial curl request just to satisfy the gate without meaningfully verifying the claim. We have not observed this behavior, but we have not tested for it adversarially either.

Reproducing These Patterns

None of this requires our specific infrastructure. The key architectural decisions are:

1. Move critical rules out of the prompt and into the runtime. Any rule important enough that you would be upset if the agent ignored it should not be an instruction. It should be code that runs regardless of the agent's decisions. Shell hooks, middleware, validators — the mechanism matters less than the principle.

1. Store corrections as structured data, not conversation history. Trigger context, correction text, fix description, evidence count, enforcement level. Make them queryable. Inject them automatically.

1. Expose agent certainty and route on it. Do not let the agent operate at one governance depth for all tasks. A trivial rename and a payment flow rewrite should not get the same level of oversight.

1. Write acceptance criteria before implementation, not after. Make them falsifiable. Enforce them at completion. Give them to an independent evaluator who has no access to the implementer's reasoning.

1. Classify your failures. "Hallucination" is not a diagnosis. Track the mechanism, the propagation pattern, and the fix for each distinct type.

1. Make corrections compound. Every human correction should improve every future session. If you are correcting the same mistake for the third time, your system is broken — not the agent.

This article describes patterns developed during 7,400+ production agent sessions. The meta-review was conducted in Q1 2026 against frameworks published through March 2026. Published frameworks continue to evolve, and some of these gaps may close in future releases.