There's a reflex I've caught myself in dozens of times now. The agent produces something slightly off. My first move is to add more: another paragraph to AGENTS.md, another example in the prompt, another link to a doc, another conversation turn explaining what I actually meant.

It almost never works. After a point, more context stops helping and starts diluting. The agent is now holding three paragraphs of preamble, two examples, and a style guide, and it still can't tell when it's finished.

What actually moved the needle for me was the opposite: stop adding context, and add a hard stop.

What a hard stop looks like

A hard stop is one sentence, written before the agent starts, that says exactly what has to be true when the work is done. Not "make the login better." Not "refactor the auth flow." Something like:

The login endpoint returns 200 for the seeded test user and 401 for a wrong password. Here is the command to prove it: npm run test:login. Paste the output.

That's it. One observable condition. One command. One piece of evidence the agent has to come back with.

The difference this makes is not subtle. Agents are fluent at sounding done. They are much worse at producing a specific, checkable artifact on demand. When you give them a vague goal, they optimize for the shape of a finished thing. When you give them a hard stop, they optimize for actually passing the gate.

Why context pile-up plateaus

There's a reason the "just add more context" strategy stops paying. Models have a limited attention budget, and every additional paragraph you add is competing with the actual task signal. A 6,000-token AGENTS.md doesn't get read with uniform care; the middle of it gets washed out. The agent walks away with the gist of your style preferences and a much fuzzier sense of what "done" means.

I've seen this play out in predictable ways:

  • Five style-guide paragraphs about naming conventions, and the agent still names the function handleLoginThing().
  • A long prompt describing the desired error UX, and the agent returns a 500 with no message.
  • A whole paragraph about not touching unrelated files, and the diff still includes a reformat of three neighboring files it "tidied up."

None of these are failures of context. They're failures of verification. The agent had enough to write the code. It never had a reason to check that the code satisfied the thing you actually cared about.

The cheap version

You don't need a fancy setup. The hard stop is just two things:

  1. One observable condition. Something you can check without trusting the agent's prose.
  2. One command that produces evidence. A test, a curl, a build, a diff size, a lint run — something whose output the agent has to paste back.

When the work touches API behavior, the hard stop is embarrassingly concrete: re-run the spec against the live endpoint and show me the diff. That's the version of this we built into Powerduck — local-first, the OpenAPI document stays the source of truth, and the agent's job is to make the spec and the live server agree, not to write a convincing summary of why they mostly do.

Where this breaks

The hard stop is weak on open-ended work: design choices, exploratory refactors, anything where you don't yet know what "good" looks like. For that, the honest move is to split the task — have the agent produce three small candidates with a constraint on each, then pick one and only then attach a hard stop. Don't ask for the whole thing in one shot and a vague definition of done.

The other failure mode is writing a hard stop you can't actually verify. "It feels faster" is not a gate. "It handles edge cases" is not a gate. If you can't build a one-line command that proves the condition, the condition is too soft to be a stop.

The next time the agent drifts

Before you add another paragraph to AGENTS.md, ask yourself: what's the one sentence that tells the agent it's done, and what's the one command that proves it?

If you can answer both in under thirty seconds, you have a much better prompt than whatever you were about to append.