What belongs in the system block of a helpdesk ReAct agent's prompt?
answer
- stable prefix versus volatile tail
- standing instructions, not case data
- who the agent is, what it may call
- catalogue grounds choice, runtime enforces it
- observations must never gain instruction authority
basics
~20 sThe stable, per-agent material: role and scope, the catalogue of available tools with when each applies, the required output format, escalation and refusal rules, and the operating limits. Per-request data — the customer's ticket, retrieved documents, tool results — belongs downstream, not here.
solid answer
~50 sThink of the prompt as two regions: a **stable prefix** that is identical on every step of every session, and a **volatile tail** that grows as the loop runs. The system block is the prefix. It carries the agent's role and scope ("you handle billing and account questions for support agents, not end customers"), the tool catalogue with a one-line statement of when each tool applies and when it does not, the required response format, the policy rules — what must be escalated, what must never be done without confirmation — and the operating limits the model should pace itself against. What does not belong is anything that changes per request: the ticket text, the customer record, retrieved articles, and above all tool observations. Keeping the prefix byte-stable makes the whole thing easier to cache, easier to version, and far easier to reason about when the agent misbehaves.
code
markdown · 16 linesYou assist human support agents with billing and account questions.
You never speak directly to end customers.
Available actions:
- LookupAccount[accountId] - current plan, status and billing contact.
Use before any statement about a customer's plan.
- ListInvoices[accountId] - the last twelve invoices. Use for payment
disputes. Do not use to check plan status.
- IssueCredit[accountId, amountCents] - applies account credit.
Requires explicit human approval in the request; never call it otherwise.
Rules:
- State a plan, price or invoice fact only after an action returned it.
- Escalate to a human when the request involves cancellation or legal threat.
- Aim to finish within eight steps; if you cannot, return what you have
found and say what is still unknown.go deeper
Know that the system block describes the agent itself — its role, the tools it can use, and the rules it must follow — while the specific request and any tool results arrive separately.
Explain the split between the stable prefix and the volatile tail, and name what goes in each: role, catalogue, format and policy above; request, thoughts and observations below.
Demonstrate diagnosis. Map real misbehaviour back to a framing gap — wrong tool chosen because the catalogue lacked applicability notes, missed escalation because the rule lived only in an exemplar — and show you validate actions in the runtime rather than trusting the catalogue.
Own the prompt as a versioned artefact. Argue for a byte-stable prefix that can be diffed, cached and rolled back, a clean provenance boundary between instructions and untrusted tool output, and a policy surface that survives ownership changing hands.
## Two regions, not one prompt The most useful mental model for a ReAct agent's prompt is that it has a **stable prefix** and a **volatile tail**. The prefix is what defines the agent: who it is, what it may do, what tools exist, what format it must emit, what it must never do. The tail is what happens in this particular run: the user's request, each thought the model wrote, each observation your runtime appended. The system block is the top of the prefix. Everything you put there is paid for and re-sent on every step of every session, and — more importantly — everything you put there is a *standing instruction* rather than a fact about this case. That distinction is the whole discipline of system framing. ## What goes in it For a helpdesk agent, the system block earns its keep with five kinds of content. **Role and scope.** A single, concrete sentence about who the agent serves and what it is for. "You are an assistant to human support agents handling billing and account questions" does real work: it fixes the register, and it implicitly establishes that the reader is staff rather than a customer, which changes what is safe to disclose. **The tool catalogue.** The list of actions available, each with a short statement of *when it applies and when it does not*. This is the highest-leverage part of the block, because the model's tool choice is made against this list before any thought is written. Note the limit: the catalogue **grounds** selection, it does not enforce it. A model can still name something not on the list; only your runtime can refuse to execute it. **Output and protocol requirements.** What a well-formed step looks like, and what the terminating step looks like. Keep this a declaration of the contract, brief and literal, and let the exemplars carry the demonstration. **Policy.** The rules that are true regardless of the ticket: what requires human approval, what must be escalated, what the agent must refuse, what it must never state as fact without a tool result behind it. Policy in the system block is policy you can audit and version; policy scattered through exemplars is policy nobody can find. **Operating limits.** A statement of roughly how many steps the agent should expect to use and what to do when it has not succeeded — return what it has, or hand off — so the model paces itself rather than grinding. This is advisory framing; the hard cap that actually terminates the run lives in the runtime, not in prose. ## What stays out Everything case-specific. The current ticket text, the customer's account record, retrieved knowledge-base articles, prior conversation turns, and every tool observation belong in the volatile tail. Three reasons: 1. **Stability.** A prefix that changes per request cannot be cached, and a prefix that changes per request is not a specification of the agent — it is a mixture of specification and data, and you will not be able to tell which part caused a bad run. 2. **Provenance.** Observations placed in the system block acquire the authority of instructions. Tool output is untrusted data; keeping it structurally distinct from your instructions is basic hygiene. 3. **Versioning.** You want to be able to say "agent prompt v7 behaves like this" and reproduce it. That only works if the prefix is a fixed artefact. ## Ordering and stability Within the block, put the most invariant material first — role, then catalogue, then policy, then format — and keep the byte layout identical across turns. Two payoffs: the unchanged prefix is reusable by prompt caching, and diffs between agent versions become readable. Resist the temptation to interpolate the current timestamp or a request id into the middle of the block; if you truly need dynamic values, put them at the end of the prefix or in the tail, where they invalidate the least. ## Where the exemplars sit The few-shot trajectories are part of the stable prefix too, and it matters little whether they live at the end of the system block or as a leading exchange — what matters is that they are before the volatile tail and do not move between turns. Some teams keep them separate purely so the two artefacts can be versioned independently: the policy changes on a different cadence from the format demonstration. ## How this fails in production The characteristic system-framing failures are diagnosable: - **The agent uses a plausible-but-wrong tool.** The catalogue lists names without saying when each applies, so the model is choosing on the name alone. - **The agent does something it should have escalated.** The rule existed in someone's head or in an exemplar, not in the block. - **The agent's behaviour changed and nobody knows why.** Case data was being interpolated into the prefix. - **The agent is verbose and unfocused.** Scope was never stated, so it is trying to be a general assistant. The repair for all four is the same move: decide whether the missing thing is a standing instruction or a fact about this case, and put it in the region that matches.
- Why is it a problem to interpolate the current ticket into the system block?It destroys the prefix's two useful properties. A per-request prefix cannot be reused by prompt caching, and it stops being a versionable specification of the agent — when a run goes wrong you can no longer separate "the agent is configured badly" from "this input was unusual". It also blurs the line between your instructions and untrusted case data, which is exactly the boundary you want structurally visible.
- Does listing a tool catalogue in the system prompt stop the model calling something else?No. The catalogue grounds selection — it makes the right tool likely — but it is prose, and a model can still emit an action naming something that does not exist. Enforcement has to live in the runtime: validate the parsed action against the real registry, and on a miss return an error observation naming the valid options rather than executing anything.
- How do you decide whether a rule belongs in the system block or in an exemplar?Ask whether it is a standing instruction or a demonstration. Rules that must hold on every run — escalation triggers, refusals, scope — belong in the system block where they can be audited and versioned. Exemplars should show the shape of a well-formed step. Policy hidden inside an exemplar is policy nobody can find when it needs changing.
saying these in an interview costs you the question
- Pastes the current ticket or record into the system block
- Assumes listing tools prevents the model calling anything else
- Lists tool names with no guidance on when each applies
- Lets tool observations sit alongside standing instructions
- Rebuilds the prefix per request, then wonders why behaviour drifts