The system prompt is a job description
Lesson 4 of 5 in What Is an Agent? The Loop That Changes Everything.
If an agent is an employee, the system prompt is its job description — the standing instructions that shape every decision the model makes inside the loop. It arrives in the context window before any user message, it applies to every iteration, and the user typically never sees it.
New builders treat the system prompt as a magic incantation. Experienced ones treat it the way a manager treats an actual job description: role, resources, boundaries, definition of done, and when to escalate. Miss one of those five and you get the corresponding failure — an agent that wanders off-task, misuses tools, oversteps, never stops, or ploughs ahead when it should have asked.
1 · Role and goal — who you are, what done looks like
“You are a support triage agent for Acme. Your job is to resolve or route every inbound ticket. A ticket is resolved when the customer’s question is answered with a cited policy; it is routed when assigned to the right queue with a one-line summary.”
The single highest-leverage section. A crisp definition of done is what the model checks itself against every loop iteration — vague goals produce agents that either stop too early or gold-plate forever.
2 · Tool guidance — when to reach for which tool
“Use search_kb before answering any policy question. Use refund only for orders under €100 and less than 30 days old. Never call send_email more than once per ticket.”
Tool schemas tell the model what a tool accepts; the system prompt tells it when the tool is appropriate. Most flailing agents — wrong tool, tool spam, tools ignored — trace back to guidance that never said when.
3 · Constraints — the boundaries of the job
“Never discuss competitors’ pricing. Do not promise delivery dates. If the customer is angry, do not attempt humour.”
Behavioural boundaries the model should respect. Necessary — and, as the warning below explains, not sufficient: a constraint written in prose is a request, not a mechanism.
4 · Output contract and stopping condition — how to finish
“When the ticket is resolved or routed, output a JSON summary with fields status, action_taken, confidence. Then stop. Never process more than one ticket per run.”
Defines both the shape of the result and the stopping condition. Agents without an explicit definition of “finished” burn tokens re-verifying their own work — or stop the loop mid-task.
5 · Escalation rules — when to hand back to a human
“If the customer mentions legal action, a safety issue, or a refund over €100, stop and escalate to the human queue with your notes so far.”
The most safety-critical section, and the most commonly omitted. An agent that cannot say “this one is above my pay grade” will improvise instead — always in the situations where improvisation is most expensive.
Key terms: system prompt, stopping condition, structured outputs, guardrails, context engineering
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.