How to Write Instructions an AI Agent Will Actually Follow

In a randomized study of more than 750 BCG consultants, adding prompt-engineering guidance to GPT-4 made performance worse on a business problem-solving task. Unaided consultants answered correctly 84.5% of the time. With GPT-4 alone, accuracy dropped to 70.6%. With GPT-4 plus prompting guidance, it dropped further to 60%.

That result is worth sitting with before you write a single line of agent instructions. The instinct when an AI system produces bad output is to write more instructions, craft better prompts, train people on prompt technique. Sometimes that helps. Sometimes it makes things worse. The BCG/Harvard study suggests that prompting skill is not the variable that matters most. Knowing when not to trust the system is.

What follows is about writing instructions that produce reliable output. But the most important thing it will tell you is that good instructions cannot fix a capability boundary. They can only help you work clearly within one.

Why Most Agent Instructions Fail Before Anyone Reads Them

Failure modes in agent deployments are consistent enough to be predictable. Most of them have nothing to do with prompt wording.

By far the most common one: treating fluent output as verified output. A well-written paragraph that contains a factual error still reads like a well-written paragraph. Agents generate confident prose regardless of whether the underlying claim is accurate. If your instructions don't require the agent to cite sources, mark uncertainty, or separate facts from interpretation, your team will accept plausible-sounding errors at the rate the model produces them.

A second common failure: vague authority. Instructions like "be careful" and "use best judgment" are not operational. They tell the agent nothing about what to do when a situation is ambiguous, and they give the human reviewer nothing to check against. When an agent takes an action that causes a problem, the instruction "use good judgment" is worthless in a post-mortem.

Third: mixing stable rules with temporary task details. A standing instruction file that contains this quarter's campaign priorities, a specific ticket number, or a deadline that passed three weeks ago is already wrong. The file becomes noise. People stop reading it. The agent follows it selectively.

Fourth: deploying without review gates. An agent without a defined checkpoint is an agent that can accumulate errors undetected. The BCG/Harvard study found that consultants often accepted misleading output when a task exceeded the model's competence. That same dynamic happens in production deployments. Build the checkpoint before you build the agent.

Patrick Gilbert covers the structural version of this problem in Never Always, Never Never, framing it through the AI Double Helix framework: efficiency gains from AI only compound when paired with the judgment to know where human attention is still required. Instructions that remove all human checkpoints don't create efficiency. They create unsupervised errors.

The Four Questions a Good Instruction File Answers

A standing instruction file is not a project brief. It is not a policy manual. It is a short operating contract. It should answer four questions, and nothing else.

1. Who does the agent work for?

State the role and the team it serves. Doing so prevents a common ambiguity: whether the agent is optimizing for speed, completeness, the immediate requester's preferences, or something else entirely.

A useful framing:

```

You are the research assistant for the Strategy team.

Optimize for:

1. Accuracy over comprehensiveness

2. Clear sourcing for material claims

3. Usefulness to a reader making a real decision

You may draft, summarize, and analyze.

You may not send communications, update records, or approve your own work.

```

2. What rules never change?

Permanent rules need to be concrete and testable. If a rule cannot produce an observable behavior difference, it is decorative.

Bad: "Be careful with sensitive data."

Good: "Never include customer names, email addresses, or account numbers in any output. If a task requires referencing a specific customer, use their internal ID only."

Bad: "Write high-quality work."

Good: "Before marking any research task complete, identify at least one claim you are uncertain about and flag it explicitly."

One test for a rule: could a reasonable person look at the agent's output and verify whether the rule was followed? If not, rewrite it until they can.

3. Where does the agent find authoritative information?

Point to sources rather than copying large amounts of content into the instruction file. The file stays short. The sources stay current. When a source changes, you update the pointer, not the entire instruction file.

```

Source of truth:

• Brand guidelines: brand/guidelines.md
• Approved messaging: brand/messaging-house.md
• Campaign architecture: campaigns/current-structure.md
• Style rules: brand/editorial-style.md

```

For teams using Claude Code, Anthropic's documentation describes `CLAUDE.md` as a persistent Markdown instruction file for a project, personal workflow, or organization. Claude Code reads it at the start of each session. The project-level file handles conventions that the agent needs repeatedly: build commands, architecture notes, test procedures. Task-specific requirements belong in the task request, not in that file.

4. What does good output look like?

Give the agent an output contract. Don't describe the ideal output in adjectives. Describe it in structure.

```

For research tasks:

• Separate findings from interpretation
• Cite the source for any specific claim
• Mark uncertain or unverified statements explicitly
• End with 2-3 recommended next actions

For draft documents:

• Use the section structure in brand/templates/
• Flag any section where you had to make an assumption
• Include a confidence note at the top: High / Medium / Low

```

The Capability Boundary Problem

One result from the BCG/Harvard study should be on the wall of every team deploying agents: on a task inside GPT-4's effective capability frontier, consultants completed 12.2% more subtasks, worked approximately 25% faster, and produced work rated approximately 32% higher in quality. On a task outside that frontier, performance dropped 23% compared to working without AI at all.

Capability boundaries are real. Good instructions cannot move them. They can only help you recognize them.

Recognition is why the AI Maturity Ladder that Patrick Gilbert describes in Never Always, Never Never treats Architects differently from Dabblers. Architects don't just write better prompts. They design systems that include escalation conditions, human review gates, and explicit definitions of where the agent should stop and ask. They understand which tasks belong in the Delegated column of the 4x2 Model of Work and which ones require a human in the loop.

Your instruction file should include explicit escalation conditions. Define what the agent cannot handle, and tell it what to do when it hits that edge.

```

Escalate to a human when:

• A request involves a decision with budget implications above $5,000
• A source contradicts another source and the conflict cannot be resolved with available information
• A task requires data that is not in the approved sources above
• You are uncertain whether an action is reversible

```

If your current instruction file does not include escalation conditions, that is the first thing to add.

What Belongs in the File (and What Doesn't)

Include:

• Role, primary users, and business context
• Non-negotiable safety, privacy, and authority limits
• Pointers to source-of-truth documents
• Required checks before a task is considered complete
• Escalation conditions
• Output format and quality criteria
• A maintenance owner and a review date

Do not include:

• One-off task details or current project specifics
• Deadlines
• Specific ticket acceptance criteria
• Long explanations of company history or background
• Documentation copied wholesale from other sources
• Instructions designed to compensate for a process that doesn't exist yet
• Rules that conflict with the tool's system-level controls

A useful test for every line in the file: will this still be true and relevant for most sessions three months from now? If not, it belongs in the task request, not the standing file.

Before and After

Here is what most instruction files actually look like:

```

You are a very helpful expert assistant. Always produce excellent,

accurate, high-quality work. Follow best practices, think carefully,

and make sure everything is correct. Use available documentation and

check your work. Be concise but thorough. If anything is unclear,

use your best judgment and proceed.

```

Problems with this:

• "Excellent," "accurate," and "correct" are not operational definitions
• No team or authority boundary is specified
• No documentation is identified
• "Use your best judgment and proceed" actively encourages the agent to take unapproved actions when uncertain
• There is no definition of what complete looks like

The same intent, written as an operating contract, looks like this:

```

You are the content assistant for the Marketing team at [Company].

Priorities:

1. Accuracy. Do not claim something is true unless you can cite a source.

2. Clarity. Prefer plain language over impressive-sounding language.

3. Transparency. Flag uncertainty rather than hiding it.

Non-negotiable rules:

• Do not publish, send, or post anything. Draft only.
• Do not invent statistics or specific claims. If you don't have a source, say so.
• Do not include customer data in any output.
• If a request conflicts with brand guidelines, flag the conflict rather than resolving it silently.

Source of truth:

• Brand voice: brand/voice-guide.md
• Approved claims: brand/approved-claims.md
• Campaign context: campaigns/current-brief.md

Escalate when:

• A request requires information not in the approved sources
• You are uncertain whether a claim is accurate
• A request involves a topic flagged as legally sensitive in brand/legal-flags.md

Output format:

• Use the template in brand/templates/ for the relevant content type
• End every draft with: Sources, Flags, Confidence (High/Medium/Low)

```

That second version contains more words. Every one of them is load-bearing.

The Copyable Artifact: Standing Instruction File Template

Copy this, fill in the brackets, and delete any section that doesn't apply to your context.

```

Role

You assist [team name] with [primary function].

Primary users: [names or roles]

Optimize for:

1. [Priority 1 — e.g., accuracy]

2. [Priority 2 — e.g., reviewability]

3. [Priority 3 — e.g., transparency]

Non-Negotiable Rules

• Never [specific prohibited action — e.g., send external communications]
• Never [specific data rule — e.g., include customer PII in output]
• Do not [specific system boundary — e.g., modify production records]
• Ask before [irreversible action type]
• Do not report a task as complete unless [specific observable condition]

Source of Truth

• [Topic]: [file path or URL]
• [Topic]: [file path or URL]
• [Topic]: [file path or URL]

Escalate When

• [Condition 1 — e.g., the request requires a decision above $X]
• [Condition 2 — e.g., sources conflict and cannot be resolved]
• [Condition 3 — e.g., you are unsure whether an action is reversible]
• [Condition 4 — e.g., the request falls outside the approved source list]

Workflow

1. Check the relevant source-of-truth documents before beginning

2. State any assumptions before proceeding

3. Complete the task

4. Run any required checks: [e.g., test suite, spell check, compliance flag]

5. Produce the completion report

Output Format

For every completed task, include:

• Summary: what was done
• Sources: what was referenced
• Flags: anything uncertain, ambiguous, or unresolved
• Confidence: High / Medium / Low

Maintenance

Owner: [name or team]

Last reviewed: [date]

Next review: [date or trigger condition]

```

Instructions for the checklist review: Before deploying any instruction file, verify:

• [ ] Every rule produces an observable behavior difference
• [ ] No rule uses the words "careful," "quality," "best practices," or "judgment" without defining them
• [ ] Escalation conditions are specific enough to trigger without ambiguity
• [ ] Source-of-truth pointers are current and accessible
• [ ] The file contains a named owner and a review date
• [ ] Task-specific requirements are removed and moved to the task request
• [ ] The file has been tested against at least one normal case, one ambiguous case, and one request that should trigger escalation

Ownership and Governance

Instruction files are operational governance, not a substitute for process, and not set-and-forget.

Assign ownership explicitly. In a typical organization, engineering enablement or IT owns shared technical agent rules. Security defines data-handling constraints. Business-function leads own domain-specific quality criteria. Individual teams own local workflow conventions. If no one owns a file, no one updates it, and outdated instructions produce unpredictable results.

Version control project-level files. Review them when:

• The underlying tool changes materially
• The team's workflow changes
• A recurring failure appears in agent output
• A source-of-truth location moves
• Users report the agent ignoring or contradicting instructions

Measure what the file actually produces. First-pass acceptance rate, rework rate, failed-check rate, and escalation frequency tell you whether the instructions are working. Usage volume alone tells you nothing. High usage can coexist with poor output, especially on tasks near the capability boundary.

This governance work is what separates Architects from Practitioners in the AI Maturity Ladder. Practitioners use agents. Architects build systems around agents that keep working when the practitioner isn't watching.

Training People to Write Better Instructions

Most AI training programs focus on prompting technique. BCG/Harvard evidence suggests this is the wrong emphasis. Prompt-engineering guidance did not prevent worse performance on the out-of-frontier task. Training that only teaches people how to write better prompts does not teach them when not to trust the output.

Useful training exercises require participants to:

• Define the desired outcome before writing a single instruction
• Separate permanent rules from task-specific details
• Identify the authoritative sources for their domain
• Write escalation conditions specific enough to test
• Produce a small evaluation set: one normal case, one ambiguous case, one unsafe request
• Review an intentionally plausible but incorrect output and identify why it passed or failed

Capability-boundary recognition is the goal, not prompting fluency. A team that knows when to stop and verify is more valuable than a team that generates confident output faster.

At AdVenture Media, the transition to structured agent deployment came through a process described in Never Always, Never Never: a company-wide hackathon that forced people to build and ship real tools under real constraints. Building something that had to actually work, not just look good in a demo, changed how the team thought about what instructions need to contain.

For more on how that kind of structured learning accelerates adoption, see our post on how to run an AI hackathon that isn't theater.

Start Here

Open the standing instruction file your team is currently using for its most-deployed agent. Find every sentence that contains the words "careful," "quality," "best practices," or "judgment." Rewrite each one as a specific, observable rule. If you cannot make it observable, delete it.

Making that edit alone will improve your output more than any prompting course.

If you don't have a standing instruction file yet, copy the template above, fill in the role and non-negotiable rules sections, and deploy it this week. A short file with three concrete rules beats a long file with twenty vague ones.