How to Instruct an AI Agent So It Does What You Asked

The single most common mistake in working with AI agents is treating "what I want" as if it were the same thing as "what I typed."

It almost never is. The agent follows the room your prompt gives it, and most prompts give it more room than you intended. "Clean this up" allows the agent to clean up everything. "Improve the styling" allows it to rewrite the file. "Fix this" allows it to fix the wrong thing in the right way.

Once you have watched an agent "fix" the wrong thing, the lesson lands fast: the agent is not the bottleneck on quality. The instruction is.

This is the pattern we use for every non-trivial agent request, plus the templates you can copy directly into your own prompts.

The three lines that keep agents inside the task

Every effective instruction we have used has three parts. Drop any of them and the failure modes return.

Part	What it answers	Example
Goal	What outcome should exist when the agent is done?	"Update only the pricing section to reflect the new $29 plan."
Constraint	What must not change?	"Do not rewrite the introduction, change the layout, or touch the CTA."
Procedure	How should the agent work?	"First identify the exact lines you will edit, then wait for approval."

The pattern is simple, and operators tend to converge on it after enough bad runs. Once it is in your head, every prompt feels incomplete without all three.

What changes when the instruction has boundaries

The fastest way to internalize the pattern is to read paired examples.

Bad instruction	Better instruction
"Clean this up."	"Fix grammar and tighten sentences in the pasted draft. Do not change structure, examples, or claims."
"Improve the styling."	"Adjust spacing and typography only. Do not change copy, layout hierarchy, or component behavior."
"Fix this bug."	"Find why the submit button fails on mobile. Report the cause first. Do not edit files until I approve the fix."
"Clean up the references."	"Remove duplicate citations only. Leave every other section, including footnotes and inline links, untouched."
"Make it better."	"Suggest three concrete improvements. Do not modify any files."

The good examples all do the same three things: the goal is small, the off-limits list is explicit, and the procedure is something the agent can verify against.

The templates we reuse before agent work gets risky

Copy these directly. Fill in the bracketed parts. They take thirty seconds to fill in and prevent the surprise rewrites, scope creep, and wrong-file edits that ruin agent runs.

Template 1: file or content edit

Goal: [what you want changed]
Target: [the specific file and section]
Change: [property or text, from current value to new value]
Off-limits: anything outside the named target
Procedure: show the diff first, apply only after approval

This is the workhorse template. Use it for code edits, document edits, configuration tweaks — anything where the agent will modify a specific thing inside a specific file.

Template 2: writing or rewriting prose

Goal: [what should change about the text]
Target: [the section or passage to rewrite]
Off-limits: heading structure, tables, bullet lists, existing voice
Procedure: produce three options, wait for selection, apply only the chosen one

The "three options" pattern is the highest-leverage technique we know for prose work with agents. It costs nothing extra and consistently produces better outcomes than asking for a single rewrite.

Template 3: analysis or research, no changes

Goal: [what you want to learn or evaluate]
Target: [the project, file, or domain to analyze]
Output: [the structure of the answer you want — bullet list, comparison table, three options, etc.]
Off-limits: no file modifications of any kind

When you do not want the agent to touch anything, say so explicitly. "Just give me your analysis" can still result in a file modified to "demonstrate the recommendation." Naming "no modifications" as an off-limits item closes that path.

The three-line version for rushed requests

For situations where you do not have time to fill in a full template, the floor is:

Action: [what to do, in one specific sentence]
Target: [the file, section, or scope]
Off-limits: nothing else gets touched

Three lines. Thirty seconds. This is enough to prevent the failures that create the most cleanup work.

Match the granularity to the task

Not every kind of work needs the same level of specificity.

Task type	Granularity	Risk if loose	What works
Strategy or ideation	Coarse	Low	"Generate three options. I will choose."
Long-form writing	Medium	Medium	"Rewrite this section, preserve structure."
Code edits	Fine	Medium	"Change this exact thing in this exact file."
Visual or styling work	Very fine	High	"Change this property to this value, name everything else off-limits."

The pattern: the more visual or aesthetic the work, the more precise the instruction has to be. Agents will make styling and structure decisions unless you remove that room.

The reverse is also true. For ideation work, asking for narrow output is wasteful. "Give me three completely different framings" produces better results than "give me a framing that does X, Y, and Z."

Reusable off-limits phrases

Constraints work better when they are concrete. A few lines we use repeatedly:

For file operations:

Do not create new files.
Do not delete files.
Do not modify any file outside [the target].

For dependency management:

Do not install new dependencies.
Do not modify package.json or equivalent.
Confirm before changing any configuration file.

For scope:

Limit changes to [single file / single function / single section].
Preserve the existing heading structure.
Match the voice of surrounding content.

For verification:

Show the diff before applying.
After applying, summarize what changed.
If any change is outside the requested scope, stop and explain why.

They work because they turn assumptions into explicit permissions and prohibitions. The agent stops guessing what you would tolerate.

Standing instructions versus session instructions

Some constraints come up every time. Others are specific to one task. The two should live in different places.

Session instructions go in the prompt. They cover the immediate task — what to change, what to leave alone, what success looks like.

Standing instructions live in the agent's persistent rules file or project settings, depending on the tool. They cover the things you never want to repeat:

- Always confirm before deleting files
- Do not add dependencies without explicit approval
- Match the existing code style of the project
- Surface unexpected changes for review before applying

Anything you find yourself typing twice in session instructions is a candidate for the standing file. The cleaner the standing instructions, the shorter the session instructions need to be.

The pre-flight check

Before you send any non-trivial agent request, three questions are worth asking yourself:

Is the goal a specific, observable outcome? "Improve" is not a goal. "Change the color from X to Y" is.
Is the off-limits list explicit? If you are imagining boundaries that are not in the prompt, the agent is not.
Does the procedure include a checkpoint? "Show me first" prevents most one-shot disasters.

If the outcome is observable, the boundaries are explicit, and the checkpoint is built in, send the prompt. If not, tighten it first. This thirty-second check prevents most of the rework that turns a one-prompt task into a two-hour cleanup.

Why this works

The framework is not about constraining the agent. It is about removing ambiguity. Agents do not have judgment about what you would consider a reasonable scope; they have words to follow. The job of the instruction is to leave as little of that judgment as possible to the agent.

The best agent users we have seen all end up with some version of this pattern: a precise goal, explicit boundaries, and a checkpoint before the agent changes anything. The result is not slower work — it is faster work, because the work that comes back is the work they actually wanted.