The H-Edges Pattern Drop: The AI Drift Guard
A simple pattern for preventing drift in multi‑step workflows
There’s a point in multi‑step workflows where things start to wobble. It’s rarely dramatic. You run a sequence that worked fine last week, and now one step feels slightly off. Maybe the model reorders something. Maybe it adds a detail you didn’t approve. Maybe it changes a condition that was supposed to stay fixed. I’ve seen this enough times that I’m pretty sure the root cause is drift creeping in between steps.
The Drift Guard is meant to stop that.
It’s a small pattern, but it helps keep multi‑step work predictable. You don’t need anything complicated. You just need a way to check whether the model stayed inside the boundaries you set at the start.
A Grounded Example: Customer Support Workflow
Imagine a workflow that generates a customer‑ready summary from a support ticket. It has four steps:
Extract the key facts
Rewrite them in customer‑friendly language
Add a short explanation of what happens next
Produce a final version for the support agent to send
This works well until the model starts “helping” a little too much. Maybe it adds a promise the team can’t keep. Maybe it softens a statement that needs to stay firm. Maybe it invents a next step that doesn’t exist. None of these mistakes are huge on their own, but they stack up.
A Drift Guard catches them before they spread.
More Real‑World Situations Where Drift Shows Up
To make this more concrete, here are a few places where drift tends to sneak in.
Engineering Documentation
A developer uses a multi‑step workflow to generate internal documentation. The model starts adding explanations for design decisions that were never made. It’s trying to be helpful, but it’s rewriting history.
Data Science Pipelines
A data scientist runs a workflow that cleans data, summarizes trends, and produces a short narrative. The model quietly “fixes” missing values by inventing them. It’s subtle, but it changes the analysis.
Legal Drafting
A legal team uses a workflow to generate a first‑pass clause for a contract. The model adds obligations that weren’t approved. Even a small drift here can create real risk.
Marketing Campaigns
A marketing lead uses a workflow to produce a campaign brief. The model adds claims that aren’t allowed. It doesn’t feel malicious. It’s just guessing.
Recruiting
A recruiter uses a workflow to rewrite job descriptions. The model softens requirements or adds new ones. Over time, the role drifts away from what the team actually needs.
In all these cases, the workflow didn’t break. It mutated. And mutation is harder to spot than failure.
Micro‑Mechanics: Why Drift Appears
I’ve noticed that drift usually shows up when the model tries to infer something you didn’t specify. In multi‑step workflows, each step becomes a chance for the model to guess. If the workflow has five steps, that’s five opportunities for drift. If it has ten, that’s ten.
The Drift Guard acts like a small checkpoint between steps. It doesn’t slow the workflow down. It just keeps the model from wandering.
The Drift‑Guard Protocol
A reproducible version you can drop into any multi‑step workflow:
DEFINE the expected output for the step This is the anchor. It doesn’t need to be long. It just needs to be clear enough that you can compare against it.
VALIDATE the boundaries This is where you confirm what the model must avoid. For example: “Don’t add commitments,” or “Don’t change the timeline.”
CHECK the step output Look for drift. Even small drift counts. If the model wandered, you catch it here.
LOG the deviation This part matters more than people think. Logging helps you spot patterns. If the same drift keeps showing up, you can tighten the protocol.
Once you have this in place, multi‑step workflows stop mutating behind your back.
Extended Example: Engineering Workflow With Drift Guard
Let’s walk through a longer example to show how this works in practice.
A software engineer has a workflow for generating a release note:
Extract the changes from the commit history
Rewrite them in customer‑friendly language
Add a short explanation of why the change matters
Produce a final version for the product team
Without a Drift Guard, the model starts adding things like:
“This update improves performance” even when no performance work was done
“This feature will expand in future releases” even though no future work is planned
“Users asked for this change” even when no user feedback exists
With a Drift Guard, the engineer defines the expected output for each step, validates the boundaries, checks the output, and logs any drift.
After a few runs, the engineer notices that the model keeps adding future promises. The log makes the pattern obvious. The engineer tightens the protocol: “Avoid any reference to future work unless explicitly provided.”
The drift disappears.
Reflection: What I Keep Seeing
I’ve watched teams run multi‑step workflows without any drift guard, and the results usually get worse over time. The model starts rewriting tone, adding details, or shifting meaning. It doesn’t happen all at once. It happens gradually, which makes it harder to notice.
Teams that use a Drift Guard tend to get better results. Their workflows stay stable. Their outputs stay predictable. It’s not magic. It’s just a small pattern that keeps the model inside the boundaries you actually care about.
Identity
Deterministic beats probabilistic when the stakes are real.
Closing Line
If you don’t guard the steps, the steps start rewriting themselves.