A brief an agent cannot misread

Here is a brief. It is an illustration I made up, not a real one, but you have probably written its cousin.

Clean up the notification settings page and make it faster.

A person reading that would stop you in the hallway. Clean up how? Faster than what? Is the page slow, or is it ugly? Does "settings page" include the email preferences tab that another team owns? You would get answers to all of that in about a minute, and the task would quietly become something specific before anyone opened an editor.

An agent does not stop you in the hallway. It reads the sentence, picks the most plausible reading, and gets to work. It might reorganize the component tree, rename a dozen props for consistency, remove a tab it decided was redundant, and hand back a tidy diff that is technically about the notification settings page. Every step was reasonable. None of it was what you meant.

This is an opinion piece about project management with AI, and my claim is simple. I think handing work to an agent is handing it to an assignee who will not ask a clarifying question unless the brief tells it to. That changes what a good brief has to do.

It is the same brief, plus two things

A good brief for an agent is the same document a good project manager would write for a person. Outcome, scope, what done looks like, who to talk to. None of that is new. If you have ever written a decent ticket or handed work to a contractor, you already know the shape.

The difference is that a person fills gaps with judgment and a quick question, and an agent fills them with a guess. So I think the brief needs two additions that people rarely bother to write down for a human: what the agent may not touch, and when it should stop and ask instead of continuing.

Those two lines carry more weight than they look like they should. The first turns a vague boundary into an explicit one. The second turns a silent wrong turn into a visible pause.

The parts I would not skip

Here is the list I keep coming back to. It is reasoning, not a framework, and I would not defend the exact order.

The outcome, in one sentence. If you cannot say what should be different when the work is finished, the agent cannot either. This is where "make it better" goes to die, and it is the sentence most worth writing carefully.

Non-goals. Say what the task is not. It feels redundant, since the scope already implies it, but a literal reader treats unmentioned things as open. A line like "not a redesign, not the email tab" closes doors the agent would otherwise walk through.

What done looks like, and how anyone will check. Not "works well." Something a reviewer can verify: the page loads without the extra request, the existing tests still pass, the layout at a narrow width is unchanged. If checking requires judgment, say whose.

What is off limits. Files, services, shared components, anything with an owner who did not agree to be part of this. This is the "may not touch" line, and it earns its place the first time it prevents a cross-team surprise.

Where to stop and ask. Name the situations. "If the fix needs a change to the shared settings component, stop and ask." "If two of the requirements conflict, stop and ask." An agent will not invent these tripwires, but it is much more likely to respect ones you give it.

What the reviewer will look at first. This one is easy to forget. Tell the agent, and the person reviewing, where the risk lives. It focuses the first read on the part most likely to be wrong.

The same brief, rewritten

Here is the earlier brief rewritten. Again, this is an illustration, not a real brief.

Outcome: The notification settings page renders its list of preferences without waiting on the slow preferences request, so the page is usable while that request finishes.

Not in scope: Visual redesign. The email preferences tab. Renaming props or restructuring components.

Done means: The list renders from cached data first and updates when the request returns. Existing tests pass. The page looks the same as before at desktop and narrow widths.

Off limits: The shared settings layout component. Anything under the email preferences directory.

Stop and ask if: The change needs edits to the shared layout component, or the cached data and the fresh data disagree in a way you cannot resolve from the code.

Reviewer will look first at: How stale cached data is handled when the request fails.

Read that as the agent would. The ambiguity in "make it faster" is gone, because it now names the specific slowness. The scope is bounded on both sides. There is a way to tell whether the work is finished. And the two places where a guess would be most expensive have been turned into pauses.

It is also longer than one sentence, and that is fine. The length is doing work. Most of it is the answers you would have given in the hallway, written down before the agent needed them.

How we work

We write briefs for agents, and each one has a named owner and a definition of done. That is all I will claim about it: it is how we work.

The owner matters more than it sounds. When a brief has a name on it, there is someone to ask when the stop-and-ask line fires, and someone accountable when the result comes back off target. A brief with no owner can produce output with no owner too.

The cheapest place to catch the error

The reframe I would leave you with is about timing. When an agent returns the wrong thing, the instinct is to fix the output: send it back, add a comment, try again. Sometimes that is right. But the wrong output usually traces to a gap in the brief, and the brief is the cheapest place to close it. A sentence added before the work starts costs almost nothing. The same sentence added after a misread costs a round of review, a rework, and another round of review.

That suggests treating the brief as something worth reviewing in its own right. Before the agent runs, someone other than the author reads it and asks the hallway questions. What does "faster" mean here? What happens if the shared component needs to change? Who owns the email tab? A brief that has survived those questions is much harder to misread, because the misreadings have already been argued out on paper.

So the next time an agent hands back something that is on-topic and plainly not what you meant, resist the urge to blame the agent first. Look at the brief and ask what a very literal, very willing reader would have done with it. Then rewrite it until the answer is the thing you actually wanted.