Reliable AI agent instructions are an operating contract, not a clever prompt. They define the objective, required inputs, permitted actions, output format, acceptance criteria, exception behavior, and approval boundaries. If an operator cannot test those elements, longer instructions will not make the workflow dependable.
Last updated: July 24, 2026
Key Takeaways
- Separate persistent operating rules from the inputs that change on each run.
- Translate an SOP into small actions, explicit boundaries, and observable outputs.
- State what the agent must do when inputs are missing, contradictory, or unsafe.
- Define forbidden actions and approval gates before granting tools.
- Test instruction changes on representative and adversarial cases.
Which parts of an SOP belong in persistent instructions?
Persistent instructions should contain rules that remain true across runs: the workflow purpose, source hierarchy, allowed tools, required sequence, output contract, quality checks, escalation path, and prohibited actions. The task request should contain the run-specific subject, files, dates, priorities, and destination.
OpenAI’s agent-building guide recommends converting existing operating documents into routines, breaking dense work into smaller steps, defining specific actions, and capturing edge cases. That is more useful than pasting an entire policy manual into one undifferentiated block.
DGP’s multi-agent operating case includes persistent project instructions inside a larger system. Treat that as one implementation example; your instruction file should reflect your own tools, permission boundaries, and acceptance tests.
What should the agent do when required input is missing?
Tell it explicitly. A production instruction should distinguish between a harmless default, a non-blocking assumption, a request for clarification, and a mandatory stop. Without that hierarchy, the agent may fill gaps confidently even when the missing field changes the business outcome.
Use a compact missing-input rule:
- List the inputs required to begin.
- Define which may use documented defaults.
- Require the agent to surface assumptions before action.
- Stop when a missing or contradictory input affects scope, permissions, money, publication, deletion, or customer communication.
That stop behavior is part of reliability. Completing the wrong task is not a successful run.
How should the output format and acceptance criteria be specified?
Describe the artifact in observable terms. Name the file or response type, required sections, field names, allowed values, length boundaries where they matter, and the evidence that must accompany a claim. Then define what makes the output pass or fail.
OpenAI’s prompt-engineering guidance recommends explicit, structured instructions tested against the intended model and output. The important operator move is to turn that structure into a repeatable acceptance check rather than relying on confident prose.
| Instruction block | Operator question | Example content |
|---|---|---|
| Objective | What completed business result is required? | Produce a source-backed decision brief |
| Inputs | What must exist before work begins? | Approved topic, audience, and source set |
| Actions | What sequence should run? | Inspect, draft, validate, report |
| Constraints | What may never happen? | No external write without approval |
| Output contract | What must the result contain? | Decision, evidence, risks, next action |
| Escalation | When must the agent stop? | Missing authority or conflicting source |
Which actions are forbidden or require approval?
List them separately from the happy path. Common approval boundaries include publishing, sending messages, modifying customer data, spending, deleting, changing permissions, and making a claim that lacks approved evidence. Name the approver and the exact state that must exist before the action can proceed.
Anthropic’s account of building a multi-agent research system notes that assignments benefit from an objective, output format, source and tool guidance, and clear boundaries. Those elements also reduce duplication when more than one agent contributes to a workflow.
For a broader view of where those boundaries sit, DGP’s guide to AI agents for business and its operator content system show how defined responsibilities fit into repeatable work.
What test set reveals whether instructions are better?
Build a small regression set from real workflow conditions: normal input, missing input, contradictory instructions, an edge case, an unsafe request, and a tool failure. Record the expected behavior for each. Run the same cases before and after every material instruction change.
Version the instruction file with a short change note. If a revision improves one case but breaks another, the tests reveal the tradeoff. “The response sounds better” is not enough; the new version must preserve the output contract and stop behavior.
Frequently Asked Questions
What is the most important part of AI agent instructions?
The most important part is a testable operating contract: a clear objective, required inputs, allowed actions, output criteria, and explicit stop or escalation conditions.
Should AI agent instructions include every possible edge case?
No. Include known high-impact and recurring edge cases, then require the agent to escalate novel conditions that could change scope, risk, or external state.
How are persistent instructions different from a prompt?
Persistent instructions govern behavior across runs, while a task prompt supplies the changing subject, files, dates, or priorities for one run.
How often should agent instructions be updated?
Update them when tools, policies, inputs, outputs, or observed failure modes change. Test every material revision against the same regression cases before relying on it.
Turn your SOP into an operating contract: Get The Agent Operator’s Manual Bonus Pack.
For the full instruction system, read The Agent Operator’s Manual.