How to Write Instructions for an AI Agent That Ships

Most AI agents fail on inputs their builder never tested. The instructions covered the happy path, listed the steps, and stopped. Learning how to write instructions for an AI agent that ships means writing past the steps into the standard: what a correct output looks like, what a wrong one looks like, and how to tell the difference on a case you have not seen yet.

This is the part most builders skip. They write a procedure, run it on three clean examples, and publish. Then a buyer feeds it a messy real-world input and the output is confidently wrong. Below is a step-by-step way to write instructions that hold up.

Start with the finished output, then work backward

Before writing a single instruction, write the output. Draft the exact deliverable you want the agent to produce, on a real input, by hand. A contract review memo. A one-page equity research brief. A weekly ops report. Write it the way a specialist would write it, with the section headers, the tone, the level of detail, and the judgment calls visible.

That artifact becomes your reference. Every instruction you write from here on serves the goal of reproducing something that looks and reads like it. When the agent produces something different, you compare against this reference and adjust. Without it, you are tuning against a vague sense of "good," and vague standards produce vague outputs.

Do this for at least three real inputs before you touch the instructions. If you cannot produce a consistent output by hand across three cases, the agent will not either, and the problem is with your process, not the model.

Write the job in one sentence, then the standard in one paragraph

The job sentence names what the agent does and what it produces. "Review a SaaS vendor contract and return a redline memo flagging risk clauses, missing protections, and negotiation points." That is the job. If it takes more than one sentence, split it into two agents.

The standard paragraph is the part builders forget. It describes what a correct output looks like. Length. Structure. Tone. What must always be present. What must never be present. What level of certainty is acceptable and how uncertainty should be expressed.

For the contract reviewer, a standard paragraph might read: "A correct memo is one to two pages, organized by risk tier (high, medium, low). Each flagged clause quotes the exact contract language, states the risk in plain English, and proposes a specific redline. The memo never invents clauses that are not in the document. When a clause is ambiguous, the memo says so and asks a clarifying question rather than guessing. The tone is direct and useful to a non-lawyer founder."

That paragraph does more work than ten steps. It gives the agent something to check itself against.

Write the steps, then write the edge cases

Now write the procedure. Numbered steps, plain language, in the order a specialist would work. Keep each step to one action.

1. Read the full document once before flagging anything.
2. Identify the contract type and note it at the top of the memo.
3. Extract every clause related to liability, indemnity, termination, IP ownership, data handling, auto-renewal, and payment terms.
4. For each extracted clause, compare against the standard protections listed in the reference file.
5. Flag missing protections and non-standard language.
6. Draft the memo using the structure in the standard paragraph.
7. Before returning, re-read the memo and remove any claim not directly supported by the contract text.

Steps are the easy part. The edge cases are what separate an agent that demos well from one that ships. List every weird input you have ever seen a real specialist handle, and write what the agent should do in each one.

• The contract is a scanned PDF with OCR errors: extract what you can, flag any section you cannot read cleanly, and list the page numbers.
• The contract references an external schedule that is not attached: note the missing schedule and mark the review as partial.
• Two clauses contradict each other: quote both, flag the contradiction, do not attempt to resolve it.
• The governing law is a jurisdiction you have no reference data for: state that plainly instead of guessing at local requirements.
• The document is not a contract at all: stop, say so, and do not produce a memo.

These are the cases you would catch as a specialist without thinking about it. Written down, they become instructions. Unwritten, they become failure modes.

Tell the agent what a wrong output looks like

Positive examples are useful. Negative examples are more useful, because they cut off the specific ways agents drift. Include a short section in the instructions titled something like "outputs to reject before returning" and list the failure patterns a specialist would spot in a junior's draft.

For a contract reviewer, that list might include:

• Any memo that flags a clause without quoting the exact language from the document.
• Any risk rating with no reasoning attached.
• Any recommendation that references case law, statutes, or precedents the agent cannot cite.
• Any memo longer than two pages that repeats points across sections.
• Any use of hedging phrases like "it may be advisable to consider" instead of a concrete redline.

Ask the agent to check its draft against that list and rewrite anything that matches, before returning the output. This self-check adds one pass and removes most of the shipping-day embarrassments.

Give it memory of what "good" looked like last time

Instructions get sharper across runs when the agent can carry forward what worked. In an agent on Augex, this happens through the memory layer: buyer preferences, prior decisions, and format choices persist so run five is smarter than run one. When you write instructions, name the things worth remembering.

Examples for the contract reviewer:

• Remember this buyer's standard liability cap and flag anything above it.
• Remember which clauses this buyer treats as deal-breakers versus negotiable.
• Remember the preferred memo format from the last accepted output and match it.

Without pointers like these, the agent starts every run from zero. With them, the second run reflects the first buyer's actual standards, and the tenth run reflects a body of accumulated judgment.

Test against inputs you did not write the instructions for

Testing against your own examples proves the instructions match themselves. Testing against fresh inputs, ideally supplied by someone else, proves the instructions match reality. Ask a peer in the same domain to send you five real cases with no context. Run the agent. Compare the output to what you would have written by hand.

For each miss, ask one question: was the standard unclear, or was the edge case unwritten? Fix the instructions accordingly. Do this three or four rounds and the agent stops surprising you.

A practical checklist before you publish:

• The job fits in one sentence with a clear finished state.
• The standard paragraph describes what a correct output contains and excludes.
• The steps cover the happy path in the order a specialist works.
• At least five edge cases are named with a specific handling rule for each.
• A "reject before returning" list catches the top failure patterns.
• Memory pointers name what should carry across runs.
• The agent has been tested on inputs you did not write the instructions against.

Hit those seven and the agent will hold up on a Tuesday afternoon when a buyer feeds it something you never anticipated. That is the bar for shipping.

Good instructions describe the standard, not just the steps. Telling an agent what a correct output looks like, including the edge cases you would catch, is what makes its work hold up on inputs you never tested. Steps show the agent how to move. The standard tells it when to stop, when to flag, and when to ask. That is what a specialist actually does, and it is what your instructions have to encode.

Ready to put this into practice? Create your first agent and draft the standard paragraph before you write a single step. If your team is on the buying side, browse the marketplace and read a few listings closely, the ones written by experts who thought hard about edge cases stand out immediately.