{"course":{"slug":"agents-and-automation","title":"Agents and Automation","url":"https://addaly.com/learn/agents-and-automation","level":"intermediate","track":"build"},"lesson":{"slug":"system-prompts-for-agents","title":"The instruction block that has to survive forty turns","url":"https://addaly.com/learn/agents-and-automation/system-prompts-for-agents","position":13,"of":72,"minutes":9,"answer":"A system prompt is text competing with a growing transcript, so anything that must hold on turn forty belongs in the harness or in the tool description, not in a rule at the top.","keyIdea":"A system prompt is text competing with a growing transcript, so anything that must hold on turn forty belongs in the harness or in the tool description, not in a rule at the top."},"body":{"format":"markdown","text":"## Why agent prompts are a different craft\n\nIn a chat, the system prompt sits close to the only user message and its influence is obvious. In an agent it sits at the top of a transcript that grows by a tool result every few seconds. It is re-sent on every call (it does not fall out of the window, it is the last thing anyone drops) but by turn eighteen it is one paragraph among forty thousand tokens of recent, vivid, specific evidence about the task at hand.\n\nThis is the mechanism behind the most common complaint in agent development: *it followed the rule at the start and stopped following it later*. Nothing was forgotten. The rule was outvoted.\n\nTwo consequences follow, and they shape everything below. Instructions that must hold late in a run should be restated where the decision happens: in the tool description, or in the tool result itself. And anything you need **guaranteed** does not belong in a prompt at all.\n\n## A structure that holds up\n\nOrder matters less than completeness, but this order works:\n\n1. **Role and goal in two sentences.** What this agent is for, and what \"done\" looks like.\n2. **The environment.** What exists in the world it can touch: repository, inbox, database, the fact that today's date is supplied in the last message.\n3. **Tool policy.** Which tool to reach for first, and what to do when one fails. Two or three short worked traces beat a paragraph of description: *\"Ticket about billing → call `lookup_account`, then `recent_charges`, then answer. Never answer billing questions from memory.\"*\n4. **Hard constraints, stated positively.** \"Only email addresses returned by `lookup_contact`\" is enforceable and checkable. \"Never email anyone you shouldn't\" is a mood.\n5. **The stopping condition.** When to stop, and what to produce when it stops without succeeding. Agents that will not admit failure loop until the budget runs out.\n6. **Output format for the final answer.**\n\n## Tool descriptions are part of the prompt\n\nThis is the single highest-leverage place to write, and most teams leave it as an afterthought. Every tool's description is sent on every turn and sits directly beside the choice it governs. So the sentence \"use this only after `search_orders` has returned an order id\" belongs in the description of the tool it constrains, not in a bullet forty messages up. Same words, far more effect, because it arrives at the moment of the decision rather than at the start of the day.\n\n## Negative instructions are weak\n\n\"Never delete anything\" is a request. The control is a database role with no DELETE grant. \"Do not spend more than five pounds\" is a request; the control is a counter in your loop that raises when the total is exceeded. This is worth internalising early, because a great deal of agent writing consists of adding more forceful phrasing to a channel that was never going to carry a guarantee. Capital letters do not change the category of the thing.\n\nUse the prompt for what only the prompt can do, telling the model what good work looks like here, and put the boundaries in code.\n\n## Version it like code\n\nThe prompt is a deployed artefact. Keep it in a file in the repository, give the file a version identifier, and log that identifier with every run alongside the pinned model id. A prompt edited in a vendor's web console at six in the evening is an untracked production deployment with no rollback, and when the failure rate moves next week nobody will be able to say what changed.\n\n## The cost you did not budget for\n\nA two-thousand-token system prompt on a twenty-turn run is forty thousand input tokens before the task contributes anything. Prompt caching changes this substantially (providers cache a prefix and charge a fraction for cache hits) but only when that prefix is byte-identical between calls. Which gives a concrete rule: **never put anything volatile at the top.** The current time, a request id, a random session token in the system prompt turns every call into a cache miss. Put volatile values in the last message.\n\n## Knowing which sentence did the work\n\nYou will not know by reading. The honest method is ablation: remove one paragraph, run your fixed set of tasks, compare. Most teams who do this discover that a third of the prompt is inherited superstition: instructions added after a bad run months ago, which never did anything measurable and now cost tokens on every call. Deleting them is one of the few changes in this field that is both cheaper and better."},"check":{"question":"An agent honours its system prompt rule \"always confirm with the user before sending an email\" for the first several steps, then on turn eighteen sends without confirming. What is the mechanism, and what actually fixes it?","options":[{"text":"The system prompt has scrolled out of the context window and needs re-injecting every few turns.","correct":false,"tempting":"System prompts are re-sent on every call and are the last content anyone drops; the problem is dilution among newer text, not absence."},{"text":"One instruction is competing with a transcript that has grown around it; the fix is to make sending a harness-gated action rather than a requested behaviour.","correct":true},{"text":"Sampling temperature is too high, so rule-following is not deterministic; lowering it will hold the behaviour.","correct":false,"tempting":"Lower temperature narrows the sampling distribution but does not turn an instruction into a guarantee: it makes the same failure more repeatable."},{"text":"The rule needs restating more forcefully, in capitals, near the end of the system prompt.","correct":false,"tempting":"Emphasis changes the wording while leaving the enforcement in the model’s hands, which is the part that already failed."}]},"prev":{"slug":"the-message-list","title":"What the model actually sees each turn","url":"https://addaly.com/learn/agents-and-automation/the-message-list"},"next":{"slug":"the-loop","title":"Plan, act, observe, repeat","url":"https://addaly.com/learn/agents-and-automation/the-loop"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The instruction block that has to survive forty turns', in Agents and Automation. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/agents-and-automation/system-prompts-for-agents (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The instruction block that has to survive forty turns","courseTitle":"Agents and Automation","module":{"index":2,"slug":"how-the-loop-runs","title":"The machinery: transcript, tools, loop"},"answer":null,"keyIdea":"A system prompt is text competing with a growing transcript, so anything that must hold on turn forty belongs in the harness or in the tool description, not in a rule at the top.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"why-agent-prompts-are-a-different-craft","runs":[{"text":"Why agent prompts are a different craft"}]},{"t":"p","runs":[{"text":"In a chat, the system prompt sits close to the only user message and its influence is obvious. In an agent it sits at the top of a transcript that grows by a tool result every few seconds. It is re-sent on every call (it does not fall out of the window, it is the last thing anyone drops) but by turn eighteen it is one paragraph among forty thousand tokens of recent, vivid, specific evidence about the task at hand."}]},{"t":"p","runs":[{"text":"This is the mechanism behind the most common complaint in agent development: "},{"text":"it followed the rule at the start and stopped following it later","i":true},{"text":". Nothing was forgotten. The rule was outvoted."}]},{"t":"p","runs":[{"text":"Two consequences follow, and they shape everything below. Instructions that must hold late in a run should be restated where the decision happens: in the tool description, or in the tool result itself. And anything you need "},{"text":"guaranteed","b":true},{"text":" does not belong in a prompt at all."}]},{"t":"h2","id":"a-structure-that-holds-up","runs":[{"text":"A structure that holds up"}]},{"t":"p","runs":[{"text":"Order matters less than completeness, but this order works:"}]},{"t":"ol","start":1,"items":[[{"text":"Role and goal in two sentences.","b":true},{"text":" What this agent is for, and what “done” looks like."}],[{"text":"The environment.","b":true},{"text":" What exists in the world it can touch: repository, inbox, database, the fact that today’s date is supplied in the last message."}],[{"text":"Tool policy.","b":true},{"text":" Which tool to reach for first, and what to do when one fails. Two or three short worked traces beat a paragraph of description: "},{"text":"”Ticket about billing → call ","i":true},{"text":"lookup_account","i":true,"code":true},{"text":", then ","i":true},{"text":"recent_charges","i":true,"code":true},{"text":", then answer. Never answer billing questions from memory.”","i":true}],[{"text":"Hard constraints, stated positively.","b":true},{"text":" “Only email addresses returned by "},{"text":"lookup_contact","code":true},{"text":"” is enforceable and checkable. “Never email anyone you shouldn’t” is a mood."}],[{"text":"The stopping condition.","b":true},{"text":" When to stop, and what to produce when it stops without succeeding. Agents that will not admit failure loop until the budget runs out."}],[{"text":"Output format for the final answer.","b":true}]]},{"t":"h2","id":"tool-descriptions-are-part-of-the-prompt","runs":[{"text":"Tool descriptions are part of the prompt"}]},{"t":"p","runs":[{"text":"This is the single highest-leverage place to write, and most teams leave it as an afterthought. Every tool’s description is sent on every turn and sits directly beside the choice it governs. So the sentence “use this only after "},{"text":"search_orders","code":true},{"text":" has returned an order id” belongs in the description of the tool it constrains, not in a bullet forty messages up. Same words, far more effect, because it arrives at the moment of the decision rather than at the start of the day."}]},{"t":"h2","id":"negative-instructions-are-weak","runs":[{"text":"Negative instructions are weak"}]},{"t":"p","runs":[{"text":"“Never delete anything” is a request. The control is a database role with no DELETE grant. “Do not spend more than five pounds” is a request; the control is a counter in your loop that raises when the total is exceeded. This is worth internalising early, because a great deal of agent writing consists of adding more forceful phrasing to a channel that was never going to carry a guarantee. Capital letters do not change the category of the thing."}]},{"t":"p","runs":[{"text":"Use the prompt for what only the prompt can do, telling the model what good work looks like here, and put the boundaries in code."}]},{"t":"h2","id":"version-it-like-code","runs":[{"text":"Version it like code"}]},{"t":"p","runs":[{"text":"The prompt is a deployed artefact. Keep it in a file in the repository, give the file a version identifier, and log that identifier with every run alongside the pinned model id. A prompt edited in a vendor’s web console at six in the evening is an untracked production deployment with no rollback, and when the failure rate moves next week nobody will be able to say what changed."}]},{"t":"h2","id":"the-cost-you-did-not-budget-for","runs":[{"text":"The cost you did not budget for"}]},{"t":"p","runs":[{"text":"A two-thousand-token system prompt on a twenty-turn run is forty thousand input tokens before the task contributes anything. Prompt caching changes this substantially (providers cache a prefix and charge a fraction for cache hits) but only when that prefix is byte-identical between calls. Which gives a concrete rule: "},{"text":"never put anything volatile at the top.","b":true},{"text":" The current time, a request id, a random session token in the system prompt turns every call into a cache miss. Put volatile values in the last message."}]},{"t":"h2","id":"knowing-which-sentence-did-the-work","runs":[{"text":"Knowing which sentence did the work"}]},{"t":"p","runs":[{"text":"You will not know by reading. The honest method is ablation: remove one paragraph, run your fixed set of tasks, compare. Most teams who do this discover that a third of the prompt is inherited superstition: instructions added after a bad run months ago, which never did anything measurable and now cost tokens on every call. Deleting them is one of the few changes in this field that is both cheaper and better."}]}],"check":{"question":[{"text":"An agent honours its system prompt rule “always confirm with the user before sending an email” for the first several steps, then on turn eighteen sends without confirming. What is the mechanism, and what actually fixes it?"}],"options":[{"text":[{"text":"The system prompt has scrolled out of the context window and needs re-injecting every few turns."}],"correct":false,"tempting":[{"text":"System prompts are re-sent on every call and are the last content anyone drops; the problem is dilution among newer text, not absence."}]},{"text":[{"text":"One instruction is competing with a transcript that has grown around it; the fix is to make sending a harness-gated action rather than a requested behaviour."}],"correct":true,"tempting":null},{"text":[{"text":"Sampling temperature is too high, so rule-following is not deterministic; lowering it will hold the behaviour."}],"correct":false,"tempting":[{"text":"Lower temperature narrows the sampling distribution but does not turn an instruction into a guarantee: it makes the same failure more repeatable."}]},{"text":[{"text":"The rule needs restating more forcefully, in capitals, near the end of the system prompt."}],"correct":false,"tempting":[{"text":"Emphasis changes the wording while leaving the enforcement in the model’s hands, which is the part that already failed."}]}],"order":[3,0,2,1],"why":null},"prev":{"slug":"the-message-list","title":"What the model actually sees each turn","minutes":8},"next":{"slug":"the-loop","title":"Plan, act, observe, repeat","minutes":7}}}