Give an AI agent a loose brief and it will do something. That is the problem, not the fix. It will pick a reasonable-sounding interpretation of what you asked for and run with it, and by the time you notice the interpretation was wrong, it has already touched a dozen files, invented a naming convention nobody agreed to, and quietly deleted a column it decided was redundant. Nobody lied to you. The brief just left room to wander, and an agent that can act at speed will wander at speed too.
The fix is not a longer prompt or a stricter tone. It is a brief with edges: a written statement of what the project is and what it explicitly is not, a set of conditions a machine can check rather than a feeling of "looks about right", and a gate that blocks anything from shipping unless it clears those conditions. We run this on every engagement, and on our own codebase. None of it is exotic. All of it is the difference between an agent that stays on task and one you have to babysit.
The vision anchor
A vision anchor is a short document, written before any code gets touched, that states what the project is and, just as deliberately, what it is not. The "is not" half does the real work. Most briefs describe the destination and leave the boundaries implied, and an agent has no way to infer an implied boundary. It only has the words in front of it.
A useful anchor for even a small task names the shape of the output, the inputs it is allowed to touch, and a short list of things that are explicitly out of scope, phrased as plainly as the goal itself. "This script does not deduplicate records" is worth more than a paragraph of nuance about data quality, because it is something an agent, or a reviewer, can check a single line of output against.
Write the anchor once and refer back to it whenever a request threatens to expand. When a follow-up message says "while you're in there, could you also..." the anchor is what tells you, in under a minute, whether that request belongs in this project or the next one.
Done-conditions, not done-feelings
"Improve the import script" is not a done-condition. Nobody, human or agent, can check it against anything. It invites whichever interpretation feels most complete at the time, which is exactly the drift the anchor was meant to prevent.
A done-condition is a statement with a pass or fail outcome that does not depend on judgement. The output file exists at a named path. Its header row matches an agreed schema exactly. The row count in the output equals the count of non-blank rows in the input. A row missing a required field causes the script to exit with an error and a message naming the row, rather than being silently dropped. Each of those can be checked by running something, not by reading the code and deciding it looks fine.
Writing done-conditions before the work starts forces a second, quieter benefit: it forces you to decide what "finished" actually means before you are relying on an agent's judgement to decide it for you. Most scope drift is not the agent being careless. It is the brief never having defined an edge for the agent to respect.
Gates on every commit
A done-condition that only gets checked when someone remembers to check it is a done-condition that gets skipped under deadline pressure, by an agent or by a person. The condition needs to live as a test that runs automatically, every time, and a commit that fails it does not land, no matter how reasonable the change looks.
This is the part teams skip because it feels like process for its own sake. It is not. An agent working fast will happily produce a change that reads as correct and quietly breaks a condition nobody was watching for in that moment. A gate does not care how confident the change looks. It runs the check and either the commit passes or it does not ship. That is the whole mechanism, and its value is precisely that it does not require anyone to notice anything.
The same pattern runs on the codebase behind this website: a rules file that states what may and may not appear on a public page, a registry of the only claims allowed to publish, and an automated check that scans every change before it ships and blocks anything that violates either one. Nobody re-reads the rules file before each commit. The gate does that instead.
A small worked example
Take the import script from above. The vague version of the brief is "clean up this CSV and get it ready to import." An agent handed that line has to guess at a schema, guess at what counts as a duplicate, and guess at what to do with a malformed row, and a different guess each time is not a bug in the agent, it is the brief working as designed against itself.
The anchor version states the goal directly: this script normalises a lead export into a fixed schema for import. It does not deduplicate leads. It does not enrich company data from any external source. It does not touch any column outside the schema listed below.
The done-conditions attached to that anchor are checkable on sight: the output file exists at the agreed path, its header row matches the schema exactly, its row count equals the input's non-blank row count, and any row missing a required field produces a named error rather than a silent drop.
The gate is a short test file that asserts all four conditions and runs on every commit to that script. If a later change, from an agent or from a person in a hurry, adds a helpful-looking deduplication step, the row count condition fails and the commit is blocked before it reaches anything real. The anchor told the agent the boundary. The done-condition made the boundary checkable. The gate made the boundary enforced without anyone standing over the work watching for it.
Where this fits
None of this replaces judgement. Someone still has to decide what belongs in scope and what a correct output looks like. What it removes is the part where that judgement has to be re-applied by hand on every single change, by someone tired enough to miss the one that matters. Write the anchor once, write the done-conditions once, wire the gate once, and the discipline runs itself from there.
If you are briefing AI systems on real work and want a second pair of eyes on how the brief is structured before anything ships, book the free audit. We will look at how a project is scoped and checked today, and tell you plainly where it would drift.