AI agents do not stay aligned on their own. They launch well, run for a few weeks, and then drift — the same agent that gave clean answers in the demo starts making subtly wrong decisions in production. The cause is not a bad model. It is the absence of a loop that keeps the agent aligned as your product, your data, and your users change underneath it.
The fix is not a better prompt or one more fine-tune. It is a continuous alignment loop: an operating system that captures what your agents do and where they fail, processes that signal into diagnosed fixes, proposes changes through human approval and governed context, and deploys them — then runs again. Alignment is not a launch event. It is a loop you operate.
For leaders, the implication is sharp: your durable advantage is not the model you picked. It is the speed and safety of your alignment loop. Anyone can wire up an agent. The teams that win are the ones who can detect a drift on Monday and ship a governed fix by Wednesday.
This post follows AI Context in Live Operations, which covered keeping context fresh at the moment of action. Here we zoom out to the loop that keeps the whole agent aligned over time.
Key Takeaways
- AI agents drift after launch. Model behavior itself changes over time, so a fix that worked at launch decays without a loop to maintain it.
- A continuous alignment loop has four stages: Capture (collect what agents do and where they fail), Process (diagnose the signal into fixes), Propose (approve changes through governed context), and Deploy (ship and repeat).
- The safety rail is the Propose stage: no change reaches production without human approval and governed context — domain experts, service context, and written constitutions.
- The moat is the loop, not the model. Build or buy the loop, and the same agents keep improving instead of quietly decaying.
What this post covers
After reading this, you will be able to map your own alignment loop, name the stage you are missing, and see why the human-approval gate is the part most teams skip — and most need.
- Why AI agents drift out of alignment after launch
- The four stages of a continuous alignment loop
- A worked example of the loop catching a drifting support agent
- Why the human-approval gate is the safety rail, not a bottleneck
- What it takes to build the loop, and where the work actually sits
Why agents drift out of alignment
The technical explanation. An agent is aligned when its behavior matches what you actually want. That match decays for three reasons. The model underneath changes — provider updates shift behavior even when your prompt is identical. The world changes — new products, new policies, new edge cases the agent never saw. And usage changes — users ask things you never tested. Drift is not a bug you fix once. It is entropy, and entropy is continuous.
This is measurable. A Stanford and Berkeley study tracked the same GPT-4 service over three months and found its accuracy at identifying prime numbers fell from 84% to 51% — the model got worse at a task it had done well, with no change on the user's side. If the model under your agent can move that far on its own, an agent you shipped and forgot is not stable. It is drifting silently.
The business explanation. Picture a support agent you launched last quarter. It handled refunds cleanly in testing. Since then, your refund policy changed, a new product line shipped, and the model got a silent update. No one told the agent. It still answers with total confidence — it is just increasingly wrong. Nothing alarms, because every individual answer looks plausible. The failure is quiet, and quiet failures are the expensive ones.
The four stages of a continuous alignment loop
The loop is not complicated to describe. It is four stages that run continuously, each feeding the next, with a governance gate before anything ships.
1. Capture — collect what agents do and where they fail. You cannot fix what you cannot see. Capture pulls together the full signal: agent logs (what the agent did and decided), production logs (what the surrounding systems saw), human review comments (where a person flagged a bad answer), and test results (what your evals caught). This telemetry is the raw material for every improvement.
2. Process — turn raw signal into diagnosed fixes. Raw logs are noise. The Process stage normalizes them, classifies the feedback, and attributes each failure to a cause — was it the prompt, the context, the model, or a missing tool? Then it runs evals to score behavior and critiques the current version against the last one. The output is not "the agent is bad." It is "here is the specific change that would fix this specific failure."
3. Propose — route each fix through approval and governed context. This is the stage most teams skip, and the one that makes the loop safe. Each proposed change is routed to the right owner — a domain expert or service owner — for approval. Approved changes update governed context: the service context, the domain constitutions (the written rules the agent must follow), and the reusable action bundles. Nothing reaches production unreviewed.
4. Deploy — ship the change and start the loop again. Approved, governed changes are pushed back to the agents that consume them, and users are nudged to the latest version. Then Capture starts recording again against the new baseline. The loop never ends, because drift never ends.
A business example: the loop catches a drifting support agent
Return to the support agent. Over six weeks, its refund answers slowly degrade after a policy change no one propagated to it.
Without a loop, this surfaces as an angry customer, then a manager spot-check, then a scramble. With a continuous alignment loop, it plays out differently. Capture records the agent's refund decisions and a reviewer's flag on a wrong one. Process classifies the pattern — refunds citing an outdated policy — and attributes it to stale domain context, not a model fault. Propose routes the fix to the refund policy owner, who approves an updated constitution. Deploy ships the new governed context to the agent. The next refund is correct, and the whole cycle took days, not a quarter — with a record of who approved what and why.
The difference is not that the loop prevents drift. Nothing prevents drift. The difference is that the loop catches it fast, fixes it safely, and proves what changed.
The human-approval gate is the safety rail, not the bottleneck
The instinct is to automate the whole loop for speed. Resist it at one point: the Propose stage. An agent that can rewrite its own instructions and ship them to production with no human in the loop is not aligned — it is unsupervised. The value of the gate is not slowing things down. It is that every change to how the agent behaves is owned by a named person, checked against written rules, and auditable after the fact.
This is why governed context matters more than raw automation. Domain constitutions give the agent explicit rules to follow. Service context tells it what each downstream system expects. Domain experts own the decisions the model should not make alone. The gate turns "the AI changed something" into "this person approved this change against this rule on this date." That is the difference between an agent you can run in a regulated business and one you cannot.
What it takes to build the loop
The concept is simple; the build has four real dependencies. In rough order:
- Make downstream systems consumable. Expose the systems your agents act on through MCPs or APIs, so agents can both read current context and receive governed updates.
- Build the processing layer. Normalization, classification, attribution, evals, and version critique — the machinery that turns raw telemetry into specific, diagnosed fixes.
- Set up context governance across every process. Constitutions, service context, and an approval path for each type of change. This is organizational work as much as technical.
- Identify the domain experts. Every governed change needs an owner. Name them before you need them, not during an incident.
Most teams already have the first stage — logs and telemetry — sitting unused. The work is turning that exhaust into a loop.
None of this requires a proprietary platform. Every stage maps to mature open-source tooling, as the exhibit below lays out — OpenTelemetry and Langfuse for capture, Ragas, DeepEval and promptfoo for evals, Open Policy Agent and Git-based review for the human-approval gate, and Argo CD, Kubernetes and MCP for deploy. The differentiator is not the tools. It is whether you run them as one governed loop.
Where Inherent fits
A continuous alignment loop rests on one foundation: you must be able to trust and audit the context your agents run on. That is the layer Inherent is built around — managed ingestion, deterministic retrieval, and source-and-timestamp metadata on every chunk, so governed context is real and every change is traceable. The loop's Capture and Propose stages both depend on it: Capture needs auditable records of what the agent saw, and Propose needs governed context an expert can approve with confidence. Without that layer, the loop is a diagram. With it, the loop is an operating system your agents actually run inside.
The next step
Sketch your own alignment loop on one page. Draw the four stages — Capture, Process, Propose, Deploy — and for each, write down what you have today and what is missing. Most teams find they capture plenty and deploy fast, but have no real Process stage and no human-approval gate at all.
The stage you are missing is where your agents are quietly drifting right now. That is the highest-leverage thing to build next.
Once you have your one-page loop, DM Flow on X @human_in_loop with the stage you are missing — the honest answer is usually Propose.
