Scope drift with coding agents gets blamed on the agent. It is almost never the agent.
An agent will build what the last message told it to build. If the definition of the work lives in a chat history rather than a document, then the definition changes every time somebody rephrases it, and by task fifty you are building something nobody chose.
One artifact decides what gets built. It is written before anything starts, it is broken into dependency-ordered tasks, and it is locked and versioned once agreed.
Locked matters more than it sounds. An unlocked spec is where drift comes from, every single time, because an unlocked spec is not a decision, it is a suggestion that erodes under pressure. When a change is actually needed the spec gets versioned, deliberately, and everybody can see what changed and when.
A locked, versioned spec is the only thing that lets an engagement run hundreds of tasks and still arrive where it intended to.
Most task lists get ordered by importance. For agent work, order by dependency instead.
An agent given task nine when tasks four and seven are unbuilt will invent the missing pieces rather than stop. The inventions are plausible, which is what makes them expensive. You do not notice for two days, and by then three other tasks have been built on top of the invention.
Order the work so that nothing is reachable before the thing it rests on exists.
One scope, one job per agent. Research is one agent. Build is another. Review is a third.
The instinct is to let a single agent plan, build and check its own work in one pass, because it feels efficient. It produces an agent grading its own homework, and it will pass itself every time. Separate the roles and the review is worth something.
Never automate a workflow that has not been run manually first.
Two reasons. The obvious one is that you cannot automate a process you do not understand, and running it by hand is how you find the branches nobody mentioned. The less obvious one is that a client who has watched the flow work manually will trust the automated version. A client handed an automation they have never seen run will poke at it for a month.
Prototype it somewhere visible, watch it work, then productionise it.
An agent that can only produce text will produce drafts. An agent wired into the actual CRM, database or task system does the work.
The difference between "here is the SQL you should run" and the row actually being updated is the difference between a demo and a delivery. Wire the integrations the work needs rather than reading the output and doing it yourself.
Every project gets a short context file that points at detail rather than inlining it. Keep it lean. A context file that tries to hold everything gets stale within a week and then quietly misleads every session that reads it.
Point at the spec. Point at the conventions. Let the detail live where it is maintained.
Predictability, mostly. The work still moves fast, and it moves toward the thing that was agreed rather than somewhere adjacent to it.
None of this is exotic. It is the structure we hold every engagement to, and the loop it produces is two human gates with everything else delegated.
The agent was never the risk. The missing document was.
Maxpertise is an AI-native engineering company. We embed native AI engineers inside your team, live in about 10 days. Please enable JavaScript to view the site, or email contact@maxpertise.net.