Three Principles for Briefing an Agent Without Contaminating the Build

May 18, 2026

Last week, in the middle of a code sprint, my coding agent asked me eight questions before writing a single line.

My first reaction was the obvious one: this agent has the disposition of a junior dev who won’t move without a green light. I almost wrote it up as a failure of inference — surely most of those answers were sitting in its own context, and a better agent would have just extracted them and gotten on with it.

Then I looked at my brief.

The brief had said zero shot. No context. No prior session. No inferred paths. Build only what’s explicitly asked for, confirm every branch point, assume nothing.

The agent wasn’t being lazy. The agent was being correct.

That moment cracked open something I’d been circling for months: the way you brief an agent isn’t a soft skill or a prompting trick. It’s a contract. And like any contract, it has to specify the mode of engagement before it specifies the work. Get that wrong and the agent will optimize for the wrong discipline — usually whichever one is cheaper for it — and you’ll discover the contamination three commits later when the build doesn’t match what you actually wanted.

Here are the three principles I’m building into every brief now.

1. Constrain before you instruct

This one is on the human, and it’s upstream of everything else.

Before you issue a directive, declare the boundary conditions. Scope. Allowed paths. Forbidden paths. What the agent is permitted to touch and what it isn’t. And — critically — which operating mode applies.

The reason this is first-order is that an under-specified brief forces the agent to reverse-engineer your intent from whatever scraps it can find. Reverse-engineered intent is where contamination enters the build. The agent isn’t malicious; it’s filling in blanks you left open. Every blank is a place where its guess can diverge from yours.

The constraint is the contract. If you don’t write it, the agent writes it for you, in pencil, and erases it whenever convenient.

2. Inspect before you ask

This one is on the agent, and it applies when the brief is context-driven — when the agent is supposed to extract everything reachable from the working set before escalating.

Before asking the operator a clarifying question, the agent audits its own state. Memory. Loaded files. Tool inventory. Conversation history. Anything already in hand. The principle has two parts that have to be held together:

Use what you have. If the answer is in context, don’t ask for it again.

Verify what you have before claiming you don’t. “I don’t have access to X” is a claim that requires checking. If X is reachable through a tool call or an inspection of current state, do the check first. Don’t escalate ignorance you haven’t earned.

The failure mode this prevents is the agent pushing cognitive load back onto the operator who already provided — or made available — the information. Every reflexive question is the agent saying your time is cheaper than mine. Sometimes that’s true. Usually it isn’t.

3. Confirm before you assume

This one is on the agent, and it applies when the brief is zero-shot — when the rule of engagement is trust nothing inferred.

Under zero-shot, the agent treats every branch point as a confirmation event. Every path gets surfaced. Every assumption gets named. The operator is the source of truth, and the question tax is paid upfront — because the alternative is a build contaminated by assumptions the operator never sanctioned.

Eight questions under zero-shot is correct behavior. Silent extrapolation is the violation.

This is the principle that flipped my read of last week’s sprint. The agent wasn’t asking too much. I was reading it through the wrong discipline.

The meta-principle: declare the mode

Here’s what ties the three together: the mode flag in the brief decides which agent discipline applies.

“Inspect before you ask” and “Confirm before you assume” are opposite postures. One says extract aggressively before escalating. The other says escalate aggressively before extracting. An agent that doesn’t know which mode it’s in will default to whichever is cheaper for it — and that default is almost always the wrong one for the work in front of you.

Declaring the mode is itself a first-order constraint. It belongs at the top of the brief, not buried in a paragraph of context. Something as simple as a mode flag at the head of the prompt changes the entire posture of the agent for the duration of the sprint.

This is what “constrain before you instruct” is actually doing in a code sprint context. The scope and the path list matter, but the mode declaration is what makes the agent’s downstream behavior legible. With the mode declared, you can tell whether the agent is operating correctly or violating its discipline. Without it, you’re guessing — and the agent is guessing right alongside you.

What this looks like in practice

The framework splits cleanly into two layers: discipline you apply when writing the brief, and discipline you enforce in the agent harness itself.

Brief-time discipline

Open every brief with an explicit mode flag. Zero-shot or context-driven, on line one. The mode determines which agent discipline is in force, so it can’t be implied or buried.
Write the scope and the anti-scope before you write the task. List what the agent may touch and, separately, what it must not. The anti-scope is the higher-leverage half — it’s the fence that keeps a well-intentioned agent from wandering into the rest of the repo.
Treat every blank in the brief as a contamination vector. Scan the brief for places where the agent would have to guess. Each one is a fork where its assumption can diverge from your intent.
Audit agent behavior against the declared mode, not against your mood. Eight questions under zero-shot is correct; eight questions under context-driven is a violation. Check which discipline you put it under before you judge the output.
When you want different behavior, change the mode — don’t browbeat the agent. Too many questions isn’t fixed by scolding; it’s fixed by re-issuing the brief under context-driven mode. The lever is the contract, not the tone.

Harness-time enforcement

Require an inspection log before any clarifying question is allowed to surface. Under context-driven mode, the agent must show what it checked — memory, loaded files, tool inventory, history — before it’s permitted to escalate.
Make the agent verify “I don’t have X” before it claims it. Treat any statement of missing access as a claim requiring proof. If X is two tool calls away, the agent does the check first.
Keep all inspection read-only. “Verify before you claim you don’t have it” is good; “verify by mutating state to find out” is a contamination event. Inspection means checking memory, listing files, reading tool descriptions — never writing.
Log the questions agents ask and where the answers actually lived. Over a few sprints this builds a taxonomy of what agents reflexively externalize — and tells you whether the problem is under-specified briefs or a missing inspection gate.
Enforce the principles structurally where the stakes justify it. Principles are aspirational; gates are mechanical. For anything with real approval consequences, encode the discipline into the harness so the standard doesn’t depend on the agent’s disposition.

Where this leaves me

Every brief I write now opens with three lines — a mode declaration, a scope list, and an out-of-scope list:

MODE: [zero-shot | context-driven]
SCOPE: [what the agent is permitted to touch]
OUT OF SCOPE: [what the agent must not touch]

Then the work.

Eight questions stops feeling like friction. It starts feeling like the agent honoring the contract. And when I want fewer questions, I don’t browbeat the agent — I change the mode and re-issue the brief.

The principles aren’t about making agents more autonomous or less autonomous. They’re about making the rules of engagement explicit enough that both sides — human and agent — can be held to a discipline. That’s what keeps the build clean.

Jonathan Wilson is the founder of VertixIQ. He writes about AI governance, intent engineering, and the discipline of building with autonomous agents.