How to Write AI Agent Prompt Instructions

Clear ai agent prompt instructions are the single most important thing you write before a first build. The most common reason an operations agent fails is not the model, the platform, or the data. It is the instructions. Vague plan, missing output format, and no stopping condition produce an agent that halts on the first edge case or generates output your team rewrites from scratch. Getting an operations agent to do the work reliably means instructions that leave nothing open to interpretation. Researchers published a systematic survey of 58 distinct LLM prompting techniques in 2024 (arXiv:2406.06608), and the finding is consistent: structured instructions with explicit format and clear stopping rules outperform open-ended ones. This guide gives you a practical framework for writing those instructions yourself.

Why do most AI agent instructions fail?

Gartner projected in 2025 that more than 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs and unclear value as the primary reasons. Unclear value is largely an instruction problem. When an agent does not know what task it is doing, what a correct result looks like, or when to stop, it produces work your team has to fix or asks for clarification on every step. Both outcomes make the agent slower than the manual process it replaced.

The vague plan problem

The most common failure looks like this: an instructions field that reads "Help our team with client updates." That sentence tells the agent almost nothing. Which clients? What format? Weekly or on demand? Should it pull from the CRM or only use what is in the conversation? An agent given that sentence will make assumptions, and those assumptions will be wrong for your context some of the time.

The missing output format problem

Instructions that describe the task but not the output are the second most common failure. An agent writing a weekly client update needs to know: how many sections, what headers, what tone, and what to include when there is nothing significant to report. Without that specification, your team edits the format every time, or the agent writes three paragraphs when the client expects five bullet points.

The one-sentence task description test

Before writing any instructions, write one sentence completing this template: "The agent reads [input], does [one operation], and writes [specific output] for [named recipient]." If you need the word "and" to connect two operations, you have two tasks. Split them into two agents.

What belongs in a complete agent instruction set?

The Schulhoff et al. systematic survey (2024) documents five categories of techniques that reliably improve instruction following in LLM-based agents: role assignment, task definition, format specification, example provision (few-shot), and constraint setting. Those five categories map directly to five required fields in any agent instruction set that works in production.

The five required fields

Every agent instruction set needs: (1) a role statement that names what the agent is and who it serves, (2) a task definition that names the exact operation with its inputs and outputs, (3) a format specification for the output including length and structure, (4) at least two worked examples showing input and correct output, and (5) constraints that name what the agent must never do. Omitting any one predicts a failure mode: no role statement means unpredictable persona drift; no constraints mean the agent acts outside its intended plan when it hits an ambiguous input.

What order to write them in

Write the role statement first, the task definition second. A well-written role statement plus task definition gets you 60-70% of the way to a reliable agent. Add format and examples next, then constraints last. Constraints written before examples tend to be too broad; examples show you which specific constraints actually matter for your use case.

The role statement formula

A working role statement has three parts: "You are a [specific function] for [named organization or team]. Your readers are [who reads the output]. Your job is [one verb phrase that names what the agent produces, not what it thinks about]." Example: "You are a weekly status writer for the Meridian account team. Your readers are the three account managers on that team. Your job is to draft the Friday client update email for each active account using the data in the input." That is a role statement. "You are a helpful AI assistant" is not.

How do you define task plan for an operations agent?

Task plan answers two questions: what the agent reads, and what the agent writes. It does not answer "how" the agent thinks, because you do not control that. You control inputs and outputs, and defining both precisely is the entire plan exercise.

Bounding the input

Name every data source the agent is allowed to use. If it should pull from the CRM, name the specific fields. If it should use only what is passed in the conversation, say so explicitly. "Use the available data" does not bound the input; it invites the agent to invent data when real data is thin. A bounded input instruction: "You will receive a JSON object with three fields: account name, last activity date, and open action items. You have no other data source. Do not infer information that is not in those three fields."

What "done" looks like

The task definition is complete when it names the stopping condition: the agent is done when it has produced one draft per account in the input. It does not send, does not revise unless asked, and does not look up additional information. A missing stopping condition produces runaway loops: the agent keeps refining output because it was never told when its work was finished.

Weekly report plan example

For a weekly client report agent: "Read the three input fields for each account. Write one update section per account. The section contains: one sentence summarizing last week's activity, up to three open action items as a bulleted list, and one sentence stating the next planned contact date. If the last activity date is more than 14 days ago, add a one-sentence note flagging the gap. Stop after completing all accounts in the input. Do not add commentary, summaries, or recommendations that are not in the input data."

What output format does the agent need?

Salesforce's 2026 State of Marketing report (n=4,450) found that 75% of marketers have adopted AI tools, yet 84% still run generic campaigns. That gap is partly a format problem. When an agent's output does not match what the team expects, the team edits before using it. After a few rounds of that, the team stops using the agent. A precise output format specification is what makes output usable without rework.

Format matching downstream use

Write the format specification to match exactly how the output gets used. If the account manager copies the update into an email, write the format as email-ready prose: no markdown, no asterisks, no headers. If the output feeds into a dashboard field, specify plain text under a character limit. If the output gets reviewed in Notion, markdown is fine. The format you specify should be copy-paste ready for the next step, with zero reformatting needed.

Length and structure constraints

Specify maximum length, not just structure. "A summary paragraph" is ambiguous. "A paragraph of no more than 80 words" is not. For each section the agent writes, name the section header exactly as it should appear, the content type, and the word or item limit. This sounds tedious but takes fewer than ten minutes for a typical operations agent and prevents weeks of output-editing cycles.

Three output types for operations

Most operations agent outputs are one of three types. Structured prose: sections with headers, plain text, no formatting. Structured lists: headers, then bulleted items, no nested bullets. Structured data: JSON or CSV with named fields. Pick one type per agent and name it explicitly. Mixing types in one output instruction produces inconsistent formatting across runs.

How do you handle exceptions in agent instructions?

An exception is any input the agent was not designed to handle: a missing field, a value outside the expected range, an ambiguous request, or a situation where the agent would need data it was not given. Instructions that do not address exceptions produce agents that either halt silently, hallucinate missing data, or produce output that looks correct but is wrong. All three outcomes are worse than a clean escalation.

The stop condition

For each input field your agent reads, write what happens when that field is missing or empty. The agent either uses a specified default ("if open action items is empty, write 'No open items'"), skips the section ("if last activity date is missing, omit the date sentence entirely"), or escalates ("if account name is missing, stop and return an error message listing which record is incomplete"). Write the rule explicitly. The default behavior of an agent without an exception rule is to guess, and guessed data in a client update is a trust problem.

The escalation rule

An escalation rule tells the agent when to stop and ask a human rather than proceed with uncertain data. Every production operations agent needs at least one. A simple escalation rule: "If any required input field is empty or the input contains fewer than three accounts, stop and return the message: 'Input incomplete. Required fields are: account name, last activity date, open action items. Accounts in input: [count].'" That one rule catches the most common failure mode, the incomplete input, before the agent generates output your team has to throw away.

The two-line escalation format

Write every escalation in two lines: (1) the condition that triggers it, and (2) the exact message the agent returns. Do not write "the agent should flag problems." That is not an instruction. Write "If [specific condition], return exactly: [exact message]." The message should be short enough to copy into a Slack notification without editing.

How do you test agent instructions before going live?

Testing agent instructions is not optional, and it does not require a test environment. You run the agent against three inputs: a typical input, a minimal input with the least data you expect the agent to ever receive, and a broken input that triggers at least one exception rule. If the agent produces the correct output format on all three, the instructions are ready. If it fails on any one of them, the failing input shows you exactly which part of the instruction set needs revision.

The three-test rule

Typical input: the most common case, the one you designed the agent for. Check that the output matches the format specification section by section. Minimal input: the smallest complete input the agent should handle, one account with one item in each field. Check that the agent produces the minimum valid output and does not pad or invent content. Broken input: an input with one missing required field. Check that the escalation rule fires and returns the exact message you specified. Run all three before any human uses the agent.

What a passing run looks like

A passing run produces output that requires zero edits before use. Not "pretty good output," and not "output that is correct but formatted wrong." Zero edits. If your team edits the output before using it, the agent is not ready. Edit the instructions instead. The instruction revision cycle is faster than the output editing cycle, and it makes every subsequent run better.

Edge case inputs to test

After the three-test rule passes, test two additional edge cases specific to your operation: an input with more accounts than your team typically handles in one run, and an input where one account has a last activity date in the future (a common data entry error). Both test whether your format and constraint specifications hold under unusual but plausible conditions. Document which edge cases you tested and what the agent produced. That record is the beginning of your evaluation suite.

How do you know when to rewrite your agent's instructions?

Track one metric: how many times per week your team manually edits or discards the agent's output. One edit per week is within tolerance for a new agent. Five edits in the first week means the instructions have a systematic problem. The pattern of edits tells you where the problem is: consistent format errors point to the format specification, consistent content errors point to the task definition, and unpredictable errors point to a missing exception rule.

Correction frequency as the signal

Log every correction your team makes to agent output for the first two weeks. A shared document with three columns, date, what was wrong, and what was changed, is enough. If you see the same correction more than twice, that correction belongs in the instructions. The first two weeks of corrections are a feedback mechanism, not a sign the agent is broken.

The two rewrites that fix 80% of failures

Most instruction failures trace to one of two rewrites: tighten the task definition to remove ambiguity about what counts as complete output, or add a missing exception rule for the most common bad input your team encountered. Applied after the first week of real-world use, these two revisions resolve the majority of early-stage agent failures.

Version labeling

Label every instruction revision with a date and a one-line summary of what changed: "2026-09-13: added escalation rule for missing last-activity-date." This matters when something breaks three months later. The revision history tells you which change caused the regression. Store it in the same document as the instructions, below the active version.

What comes next after writing your agent's instructions?

These five fields, the testing protocol, and the exception handling rules give you a complete instruction set for a first operations agent. The work is specification, not programming. For operations tasks on a repeatable schedule, the agent versus RPA decision matters before you write a word, and the build sequence covers the surrounding architecture. Once instructions are written and tested, a free audit confirms whether your specific workflow is ready.

Methodology

This guide on ai agent prompt instructions draws on three primary sources. Schulhoff et al.'s 2024 systematic survey (arXiv:2406.06608) catalogued 58 text-based LLM prompting techniques through a PRISMA-grounded review of published prompting research; the five-category framework used here (role, task, format, examples, constraints) is derived from that taxonomy. Salesforce's 10th edition State of Marketing report (n=4,450 decision makers, Oct-Nov 2025) provided the adoption and gap data showing that AI tool adoption and actual effective use are not the same thing. Gartner's 2025 projection (URL-slug-confirmed) that 40%+ of agentic AI projects will be canceled by end of 2027 contextualizes why instruction quality is a business risk, not just a technical preference. Instruction patterns, exception handling structures, and the three-test protocol were derived from the source taxonomy and adapted for non-technical operations teams. No client results are cited. The Operations Agent page covers how a built agent fits into a complete operations workflow.