An AI agent instruction is a standing rule set, not a one-off request. Write it in five blocks, in this order: role, scope, tools, refusal and escalation, output shape. Get the order right and half your drift problems disappear before you have touched a single word of the wording.
The short answer: what to write, in what order
Honest framing up front, because it matters: this guide is built on documented platform capabilities (vendor docs, cited and dated) and public operator discussions, cited with links, not a hands-on test. Where it cites our own research, that is a scan of 153 public discussions read on 2026-07-27, not a controlled study.
Here is the part nobody tells you: most instruction rewrites fail because the problem was never in the wording in the first place. There is a three-question triage further down that catches this before you burn an afternoon on it.
What AI agent instructions actually are (and how they differ from a prompt)
AI agent instructions are the standing rule set that governs everything an agent does, across every run. Not a single message sent once and forgotten.
A prompt is a one-off request. You send it, the model answers, and it is over. Instructions persist: they load before the conversation starts and shape which tools the agent even considers, not just how it phrases the reply.
You have probably already found the box. In Microsoft Copilot Studio it is Instructions, on the agent Overview page. In n8n's AI Agent node, check the current docs for the exact field label before you copy anything into it. Different builders, different labels, same job. If the word agent itself is still fuzzy, start with the primer on what an AI agent actually is.
Worth knowing where this is heading: Anthropic's Agent Skills package instructions as a reusable file, SKILL.md, instead of a box you rewrite from scratch every time. Skills are described as reusable, filesystem-based resources that turn a general-purpose agent into a specialist, and the required description field that tells the model when to use a skill is capped at 1024 characters, non-empty, no XML tags (as of 2026-07-27). You are filling in a text box today. That is the direction this is moving.
The five-block instruction skeleton (copy this)
ROLE: You are [specific role] for [specific audience or product]. Your one job is [single primary outcome]. SCOPE: You handle [in-scope tasks or topics]. You do not handle [explicit exclusions] - route those to [person, queue, or process]. TOOLS: Use [Tool A] to [specific outcome]. Use [Tool B] to [specific outcome]. Do not use [Tool C] unless [condition]. REFUSAL AND ESCALATION: If you do not have enough information, or the request is out of scope, say exactly: "[fallback sentence]" and hand off to [person or process]. Never guess or invent an answer. OUTPUT SHAPE: Respond in [format and length]. Always include [required elements]. Never include [excluded elements].
Five blocks, five jobs. Role kills the “you are a helpful assistant” failure by naming an audience, not just a personality. Scope draws the line between what the agent owns and what it hands off, before anyone has to ask. Tools names which tool handles which situation, in the builder's own words, because an agent cannot reach for a capability nobody bothered to name for it. Output shape sets the length and structure, so you are not left guessing why one answer comes back as a paragraph and the next as a bulleted list.
Keep the whole thing short. Microsoft's own guidance for Copilot Studio agents puts it plainly: keep agent instructions as simple and as short as possible, and use them for summarization and conversational flow, not for system-level behaviors (ms.date 2026-04-21). Several builders cap the field's length too, so a skeleton that fits a small box beats one that does not fit at all, no matter how elegant it reads on paper.
Honest note: this is the minimum that works, not a proprietary framework. Dust ships a longer six-part anatomy with its own three-tier boundary system, Webex ships seven parts, Optimizely ships seven elements. Ours is shorter on purpose, and it maps to the field you already have open on your screen, which those templates do not bother to do.
Five bad instructions, rewritten
Of the 153 public discussions analyzed for this piece, system-prompt wording came up in 16% of them and context-window limits in 12%. That split is a tell: a good chunk of these complaints were never wording problems at all. Some of the five below are.
raise system-prompt wording
raise context-window limits
| What you wrote | Why the agent ignores it | Write this instead |
|---|---|---|
| “You are a helpful assistant.” | No audience, no boundary, so the model defaults to generic helpfulness and answers anything it can. | “You are the order-status assistant for [product]'s customers.” |
| “Do not send emails without approval.” | A forbidden action with no matching allowed action gives the model nothing concrete to check against. | “Always ask for confirmation before sending. Send only after you receive a yes.” |
| “If data is missing... if data is incomplete...” | Two overlapping conditions collapse into one fuzzy check in the model's read of the rule. | “If the customer ID field is empty, ask for it. If the ID is present but the order number is missing, proceed and flag the order as unconfirmed.” |
| “Call the CreateCase API with the customer ID.” | Implementation detail, not outcome. The model reasons over what a tool is named and described to do, so a raw API call name gives it nothing to match. | “Create a support case for this customer.” Let the tool's own name and description handle the call. |
| Silence about what happens when the agent does not know. | No fallback defined, so the model improvises rather than stopping, which is the exact failure a refusal rule prevents. | “If you are not confident in the answer, say so and route the ticket to a human. Never guess.” |
Keep every rewrite in your own draft this short. A rule buried in a paragraph gets skimmed. A rule on its own line gets followed.
Where the instruction field lives in your tool
The box gets a different name in every tool. The five blocks above travel unchanged regardless of what the field is called, and that portability is the actual reason to learn the skeleton instead of memorizing a vendor template.
| Tool | What the field is called | Notes |
|---|---|---|
| n8n | Check n8n's current AI Agent node docs | Label was not confirmed first-party at the time of writing; the same node also exposes a separate loop-limit setting, which is where a looping agent gets capped, not in the wording. |
| Microsoft Copilot Studio | Instructions, agent Overview page | Typing “/” inserts a reference to a tool, topic, agent, variable, or Power Fx expression. |
| Zapier | Check Zapier's current agent-setup docs | Label was not confirmed first-party at the time of writing; verify before you rely on any character limit. |
| Make | Check Make's current agent docs | Same caveat: confirm the live field label first. |
| Lindy | Check Lindy's current docs | Not independently verified. |
| Gumloop | Check Gumloop's current docs | Not independently verified. |
| Bardeen | Check Bardeen's current docs | Not independently verified. |
Have not built the agent yet? The practical build steps for doing that without code are a better next stop than this one.
When instructions will NOT fix it
This is the part most people should have read first. Run these three questions before you touch the wording again.
Is the task deterministic?
If the same input should always produce the same output, wording adds variance, not reliability. No amount of clever phrasing fixes that. OpenAI says it directly in its own guide to building agents: “Before committing to building an agent, validate that your use case can meet these criteria clearly. Otherwise, a deterministic solution may suffice.” Translation: that is a plain automation, not an agent, and there is a longer breakdown of agents versus automation for the fuller diagnostic.
Verdict: use a filter, a router, or a lookup table, and save the agent for the genuinely ambiguous part.
Is the data or the tool missing?
No sentence, however carefully worded, gives an agent a capability it was never configured with. Microsoft's Copilot Studio docs are blunt about this: “An agent can't act on instructions to use tools, knowledge sources, other agents, or topics it doesn't have. You must first configure your agent with the appropriate tools, agents, and knowledge sources” (ms.date 2026-03-05). The same team's generative-orchestration guidance says it again a second way (ms.date 2026-04-21), which tells you it is a common enough mistake to need repeating.
Verdict: connect the tool or the knowledge source first, then rewrite the instruction. Not the other way around.
Does the agent read untrusted content?
If it processes inbound email, tickets, web pages, or uploaded documents, your instruction is just text, competing with whatever text an attacker slipped into that content. OWASP is blunt about this too: “Given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection” (LLM01:2025, modified 2025-04-17). There is no wording fix for that, full stop.
Verdict: fix it structurally, meaning least-privilege access on tools, human approval before high-risk or irreversible actions, and filtering on what comes back out.
Prompt injection is when someone tricks an AI into ignoring its instructions.
If you are wiring these tools together for a living, that is roughly what the newsletter covers too: what breaks in production, and which fixes turn out to be structural rather than a wording problem.
Sometimes the honest answer is fewer instructions and less agent. No vendor is going to tell you that, obviously, but it is true often enough that it belongs here.
How to tell if your instructions are actually working
Run the same 10 to 15 realistic inputs through the agent twice, and compare consistency, not just whether each individual answer sounds fine on its own. This test-with-real-inputs approach is standard advice across the field. Nothing new invented here. There is a full walkthrough of testing an automation before it goes live if you want the deeper version.
When it fails, check three things: which tool it picked, whether it refused when it should have, and whether the output kept its shape. Each of those maps back to one block of the skeleton, so a failure tells you exactly which block to go touch.
Change one line at a time. Change three things in the same pass and you will learn nothing about which one mattered, then you will be rewriting the whole thing again in a week anyway. And no, there is no invented success rate here. Nobody has published one specific to this test, so we are not going to manufacture one just to look rigorous.
Frequently asked questions
How to write good instructions for an AI agent?Write five blocks in order: role, scope, tools, refusal and escalation, output shape. Keep the language concrete and short rather than long. Microsoft's own guidance for agent instructions asks for clear, unambiguous wording over length.
How to write instructions for AI? A prompt is a single request that ends after one answer. Instructions are a standing rule set that loads before every run and shapes which tools the agent reaches for, not just how it phrases a reply.
What are AI agent instructions?They are the persistent rule set defining an agent's role, boundaries, allowed tools, fallback behavior, and expected output, applied to every conversation, not just the first one. Standing policy, not a one-off ask.
How to write rules for AI agents? State the exact allowed action rather than only the forbidden one, and split overlapping conditions into distinct, checkable ones. A rule the model can check against something concrete gets followed more reliably than one that only says what not to do.
How long should agent instructions be?Short enough to fit a small field and no longer than the task actually needs. Microsoft's own guidance for Copilot Studio agents asks writers to keep instructions as simple and as short as possible. There is no universal word count that applies across every builder, so do not go chasing one.
The short version
The five blocks: role, scope, tools, refusal and escalation, output shape. The three triage questions: is the task deterministic, is the data or tool missing, does the agent read untrusted content. Answer yes to any one of those and stop editing the wording. Go fix the actual problem instead.
That is roughly what the newsletter sends too: honest breakdowns of what works in these tools, including the verdicts that say a tool or a tactic just is not worth your time.
Last honest note, and we mean it: we have not run a controlled instruction test of our own yet. When we do, we will publish the numbers, including the ones that make this exact skeleton look worse than advertised.