How to Write Reliable AI Agent Instructions

AI agent instructions are the system prompt that fixes an agent’s remit, tone, and the rules it must follow. Written well, they read less like a prompt and more like an operating contract — ownership, scope, evidence, exceptions, and escalation, all stated so plainly the agent cannot guess.

Most agents that go wrong were not broken. They were under-specified. Someone wrote “You are a helpful deal-desk assistant,” pointed it at a CRM, and shipped it — and then were surprised when it approved a discount it should have flagged, or invented a policy nobody wrote, or answered a question that belonged to a human.

The failure did not start when the agent acted. It started in the instructions, where nobody said who owned the outcome, where the job ended, or what the agent should do when the answer was “it depends.” An agent fills every gap you leave with a plausible guess. Reliable instructions leave fewer gaps.

This post is about writing those instructions for real business work in Insulin agents — where instructions are one of several controls, not a wish you hope the model honours. It pairs with scoping an agent to its integrations: scope decides what an agent can reach; instructions decide what it should do within that reach.

What makes AI agent instructions “reliable”?

Reliable AI agent instructions specify the outcome, the boundary, the evidence, and the escalation — not just the persona. The Insulin agents page defines instructions as “a system prompt that fixes the agent’s remit, tone, and the rules it must follow.” The word doing the work there is fixes: an instruction is only reliable when it removes a decision the agent would otherwise improvise.

A prompt tells an agent who to be. A contract tells it what it owns, where it stops, what counts as done, and who to call when the situation is outside the contract. The difference shows up the first time a request is ambiguous. A persona-only agent guesses. A well-specified agent has already been told what to do with ambiguity, so it does that instead.

That is the frame for everything below: you are not writing a personality. You are writing the operating contract for a repeatable piece of business work.

The seven parts of an agent instruction contract

A complete instruction covers seven things, in roughly this order. Each closes a gap an agent would otherwise fill with a guess.

Part	The question it answers	What vagueness costs you
Role & ownership	Who is this agent, and what one outcome does it own?	An agent that owns “everything” owns nothing, and reaches for work outside its lane.
Objective	What does a successful run produce?	Without a definition of done, the agent stops when it runs out of ideas, not when the work is finished.
Scope & boundaries	Where does the job end?	An unbounded agent answers questions that belong to another team or another human.
Tools	Which connected systems may it act on, and how?	Silent assumptions about what it can touch; see the note on permission below.
Sources of truth	What must it ground answers in?	A generic answer where a cited one was required.
Approvals & exceptions	What must a human confirm, and what does “it depends” trigger?	The agent acts on the consequential case it should have paused on.
Output & tone	What shape and register is the result?	Inconsistent results that a downstream step or reader cannot rely on.

You do not need a wall of text. You need each of the seven answered in one or two unambiguous sentences. A short contract that names all seven beats a long one that is eloquent about the persona and silent about escalation.

Role and ownership come first — and narrow

State the single outcome the agent owns before anything else. “You own first-pass review of inbound deal-desk offers” is ownership. “You help the sales team” is not — it is a vibe, and an agent given a vibe will wander into pricing, into contracts, into forecasting, wherever the conversation drifts.

Narrow ownership is what makes the rest of the contract writable. You cannot define “done,” “out of scope,” or “escalate” for a job you have not bounded. This is also why ownership pairs with scope in the product: an Insulin agent is granted an allowlist of connected systems, and the tightest instruction in the world cannot make an agent reach a system it was never given. Write the ownership, then grant exactly the tools that ownership needs.

Define exceptions before you define the happy path

Name the cases the agent must not handle on its own — this is the part most instructions skip, and it is where the expensive failures live. The happy path is easy: the agent does the obvious thing with the obvious input. The damage comes from the edge — the discount past the approval threshold, the contract clause the agent has never seen, the refund larger than a stated limit.

For each, write the trigger and the response in the same breath: “If the requested discount exceeds 20%, do not approve it — summarise the request and hand it to a human.” An exception without a defined response is not an exception; it is a gap, and the agent will fill it. Undefined exceptions are the single most common root cause of an agent doing something it should not have.

When should an agent ask a human instead of acting?

An agent should ask a human whenever the action is consequential, irreversible, or outside the cases its instructions explicitly cover. In Insulin this is not left to the agent’s judgement alone — execution runs through approval workflows in chat. As the agents page states, “You see the plan before it runs, and you decide whether it runs at all.”

That gives you two complementary controls, and reliable instructions use both:

The product-level gate. Because tool execution surfaces a plan for approval, a human already sees what the agent intends before it touches an integration. This holds even if the instructions are imperfect — it is a floor, not a suggestion.
The instruction-level rule. Your contract tells the agent when to stop and ask on its own — before it drafts the plan, not only when it is about to run one. “When the offer is non-standard, ask the account owner before proceeding” pauses the agent earlier and with better framing than a generic approval prompt would.

Write the escalation as a rule with a named recipient and a reason, not “ask if unsure.” Unsure is a feeling; an agent does not have one reliably. “If a required field is missing, or the amount exceeds the stated limit, stop and ask [the deal owner] — do not fill in a value” is a rule it can execute every time.

One caution that belongs in every contract: instructions are not a permission system. Telling an agent “never touch billing” is guidance that can be misread or argued around. Not granting it the billing integration is a boundary it cannot cross. Use instructions to shape judgement and escalation; use scope and approvals to make the consequential things impossible or gated. Never rely on an instruction to enforce what a policy or permission control should enforce.

Ground the agent, and set the tone deliberately

Tell the agent what to answer from, and how to sound, or it will default to generic. Two of the seven parts are easy to under-write because they feel cosmetic. They are not.

Sources of truth. If the answer must reflect your pricing, your contracts, or your runbooks, say so and attach them. Insulin agents can be given knowledge bases so they answer “from your pricing, contracts, and runbooks — with cited sources,” and the docs note each base attaches in Read or Edit mode. An instruction that says “quote list price from the attached pricing knowledge base, and cite it” produces a grounded, checkable answer; one that says “be accurate about pricing” produces confident guesses. Pair the instruction with a connected knowledge base so “ground your answer” has something concrete to ground in.

Tone. Register is part of the contract because the output is often read by a customer or pasted into a system. “Write in plain, direct English; no hedging; lead with the decision” is an instruction. So is “always state the discount as a percentage and a dollar figure.” These are not stylistic flourishes — they are what makes the output usable by the next step or the next person without cleanup.

A reusable instruction template

Copy this and fill each line. It maps one-to-one to the seven parts, and to the fields you configure on an Insulin agent — its instructions, its scoped integrations, its knowledge bases, its approvals. Keep it in plain English; that is the language you author agents in.

Role & ownership: You are the [role]. You own [the one outcome], for [who/what].
Objective: A successful run produces [the concrete deliverable], and is done when [definition of done].
Scope & boundaries: You handle [in scope]. You do not handle [explicitly out of scope] — hand those to [owner].
Tools: Act only on [the granted systems], and only to [the allowed actions].
Sources of truth: Ground [these kinds of answers] in [named knowledge base], and cite the source.
Approvals & exceptions: Before [consequential action], stop and ask [named human]. If [named edge case], do not act — [the response]. Never [the hard prohibition].
Output & tone: Return [format]. Write in [register]. Always [specific formatting rule].

Nothing in that template is Insulin-specific except that Insulin gives four of the lines a real enforcement point rather than a hope. The template is the discipline; the product is what turns “don’t touch billing” from a sentence into a boundary and “ask before running” from a request into a gate.

Two habits keep instructions reliable over time. Write them from a real task you watched fail or nearly fail — the exceptions you need are the ones that actually came up, not the ones you imagine. And revisit the exceptions whenever the job grows, because a widened job is exactly when a new edge case slips in with no rule attached.

Frequently asked questions

What are AI agent instructions? AI agent instructions are the system prompt that fixes an agent’s remit, tone, and the rules it must follow. Reliable ones specify ownership, scope, sources, exceptions, and escalation — not just a persona — so the agent has fewer gaps to fill with a guess.

Why do most enterprise AI agents fail? Most fail because they were under-specified: vague ownership and undefined exceptions. When instructions do not say where the job ends or what to do with an edge case, the agent improvises, and that is where the expensive mistakes happen.

When should an AI agent ask a human instead of acting? Whenever an action is consequential, irreversible, or outside the cases its instructions cover. In Insulin, tool execution also runs through approval workflows in chat, so you see the plan before it runs and decide whether it runs at all.

Can instructions replace permission and policy controls for an agent? No. Instructions shape judgement and can be misread or argued around. Use scope to make out-of-bounds systems unreachable and approvals to gate consequential actions, and rely on instructions only for judgement and escalation.

What should a complete agent instruction include? Seven parts: role and ownership, objective and definition of done, scope and boundaries, tools, sources of truth, approvals and exceptions, and output and tone. Answer each in one or two unambiguous sentences rather than writing a long persona.

Takeaways

Reliable AI agent instructions read like an operating contract — ownership, objective, scope, tools, sources, approvals, and output — not a persona.
Most agent failures start upstream, in vague ownership and undefined exceptions; an agent fills every gap you leave with a plausible guess.
Name ownership narrowly first, then define exceptions before the happy path — the trigger and the response in the same sentence.
Tell the agent when to ask a human as an explicit rule with a named recipient, and lean on Insulin approval workflows as the floor beneath it.
Instructions are not a permission system: use scope to make things unreachable and approvals to gate them, and reserve instructions for judgement and escalation.

Write the contract, then give it teeth. See how Insulin agents turn instructions, scope, and approvals into real controls, attach a knowledge base so grounded answers have a source, and read the Insulin agents documentation for the full configuration model.

How to Write Reliable Instructions for Enterprise AI Agents