Step 1: Instructions

What a prompt is made of, why examples beat adjectives, how a search beats hand-tuning, and when to move on.

An agent returns a wrong or badly shaped answer, and the team wants a stronger model. Can better instructions fix it first? Often they can, and instructions are the cheapest thing to change. This is the first step on the intelligence ladder. Treat the prompt as engineering. Fix the output shape so it cannot drift. Teach by example rather than by adjective. Let a search method find a better prompt than a person would write. This step is done only when a fixed test set shows that instruction changes no longer help.

The five parts of a prompt

A prompt is not one block of text. It has parts, and each does a different job.

The system instruction sets standing rules. It says who the agent is, what it may and may not do, and how it behaves when unsure. It is the same on every call. That matters for cost, as the next section shows.

The task instruction describes this piece of work.

The examples show completed instances of the task. This part does the most and gets used the least. A model infers a pattern from two or three good examples far more reliably than from a paragraph describing it. "Write formally" is an adjective, and every model reads it differently. Three samples of your actual house style leave no doubt.

The input is the material for this instance.

The output contract states the shape you want back. Enforce it rather than ask for it. Modern APIs accept a schema and force the model's output to match it. The model then cannot return prose where you expected fields. Asking politely for JSON in the prompt gets JSON most of the time. That is a trap. It works often enough that you build on it, and fails often enough to break in production.

foundation · journey

The five parts of a prompt, in cache order

Stable parts first: everything before the first change is billed at cache rates.

1
System instruction
Standing rules. Identical on every call.
Gate · Cached
2
Task instruction
What this job is. Stable per workload.
Gate · Cached
3
Examples
Two or three completed instances of the task.
Gate · Cached
4
Input
The material for this instance. Varies every call.
Gate · Billed fresh
5
Output contract
A schema the reply must match, enforced.
Gate · Enforced, not requested

The system instruction, examples and definitions never change between calls, so they sit at the front and stay cached. The input varies, so it goes last.

A rulebook, task card, worked examples, case file and output form flow in order through a reasoning model. — **The prompt is an assembled system**Standing rules, the task, worked examples, the changing input and the enforced output shape do different jobs. Treating them as separate parts makes the prompt testable and keeps its stable start cacheable.

Put the stable parts first

Put the parts that never change first and the parts that vary last. Providers cache the unchanging start of a prompt. A cache hit is billed at a fraction of the price of fresh input. Any change in that start invalidates everything after it. So a timestamp near the top of a system instruction quietly destroys the saving on every call.

That one ordering choice often decides whether an agent is affordable at volume. It costs nothing to get right. Each agent's spending is tracked in the observability and FinOps layer (R12).

Let a search method improve the prompt

The usual habit is to write a prompt, read the failures and rewrite it. That is a search, run by hand, slowly, on a small sample.

Run it as a search instead. One published method, GEPA, treats prompts as candidates to change and select. The system reads its own failures and proposes revisions. It keeps a varied set of candidates rather than improving just one. It beat a reinforcement-learning baseline by six points on average, and by up to twenty. It needed up to 35 times fewer trial runs. Gains appeared from as few as ten training examples (GEPA, arXiv 2507.19457, ICLR 2026).

Two things follow. Teams that hand-tune and then blame the model have usually not tried this. Their limit is not the model's limit. And ten examples is a low bar. You can do this long before you have enough data to change the model itself.

A related method, ACE, treats context as something that builds up. Rather than rewriting one prompt, it grows and curates a playbook across many runs. It improved agent benchmarks by 10.6 points and finance tasks by 8.6. It needed no weight updates and no labelled training data (ACE, arXiv 2510.04618, ICLR 2026).

A playbook that grows across runs is a form of memory, and it changes how the agent behaves. So each addition must pass the same tests as any other change before it takes effect. Nothing is kept just because it piled up. The learning flywheel sets out those tests and how a change is promoted. A prompt change also re-runs the evals at the change stage of the agent lifecycle.

Worked example: a utility inspection brief

Four boxes in order. Task: investigate this asset. Evidence: use dated observations. Output: findings, gaps and the next check. Boundary: no unsupported conclusion. — **Prepare an inspection brief**Proposed industrial example. Evaluate against the simpler existing process before adopting it.

Consider a utility inspection assistant. A vague instruction to "summarize the issue" may produce readable prose. That prose can leave out the asset, the observation date, the source or the open question.

Specify the output: asset identifier, observed condition, evidence references, uncertainty, and recommended next check. Include approved examples of good briefs. Add counterexamples that show unsupported conclusions. Check the required fields outside the model.

The task stays evidence preparation. A clear instruction does not let the agent operate equipment or certify a condition. Evaluate the brief against representative cases and reviewer effort. The example is a proposed design, not a measured deployment.

What this step does not fix

Missing knowledge. If the asset history is not in the context, no instruction recovers it. A model asked to summarise evidence it cannot see will still write a fluent story. That is the failure to watch for here. It is a step 2 problem.

When this step is done

Compare instruction changes against a fixed eval suite, and inspect the failures that remain. An eval suite is a set of test tasks with known right answers.

Move on when the scores on that suite stop improving. Without a fixed suite, you cannot tell a real limit from a bad day. That difference decides whether you are about to spend a quarter's budget for nothing. Use a fixed set of representative inspection cases, including missing and conflicting evidence.

Evidence and limits

Independently measured Both published results above are peer-reviewed and independent of this guide. GEPA and ACE were both presented at ICLR 2026. Their gains were measured on public benchmarks and finance tasks, not on utility work. The inspection example is a proposed design.

Next step

When instructions stop helping, go to step 2: context.

Explore this topic

GEPA, reflective prompt evolution, arXiv 2507.19457, ICLR 2026.
ACE, context as an evolving playbook, arXiv 2510.04618, ICLR 2026.
A growing playbook as memory that must pass the same tests as any change: the learning flywheel.
Industrial scenarios on this page are proposed designs, illustrated in the use cases.