Agent system prompts are structurally different from chatbot system prompts. A chatbot prompt shapes tone and knowledge. An agent prompt defines a decision-making system: what tools exist, when to use each, when to stop, and how to handle situations where the right action is unclear. Getting this wrong produces agents that loop indefinitely, use tools unnecessarily, or take dangerous actions on ambiguous instructions.
The Core Difference: Behavior vs. Capability
A chatbot system prompt answers: who are you and what do you know?
An agent system prompt answers: what can you do, when should you do each thing, when should you stop, and what should you never do?
This distinction determines what needs to be in the prompt. Tone and persona matter less. Tool descriptions, decision logic, and stopping conditions matter much more.
Listing Tools With Precise Descriptions
Every tool available to the agent must be described with enough precision that the model can make a correct use/don't-use decision for any input. Vague tool descriptions produce unpredictable tool selection.
Weak tool description:
- search: Search the web for information
Strong tool description:
- web_search(query: string): Search the web for current information. Use when:
- The user asks about events after your training cutoff
- The user asks for current prices, availability, or status
- The user asks about a specific person, company, or document you may not have accurate data on
Do NOT use for: general knowledge questions you can answer accurately from training, mathematical calculations, code generation.
The "Do NOT use for" instruction is as important as the "Use when" instruction. Without it, models use available tools unnecessarily — a common failure mode called "tool overuse."
Full tool block structure:
## Available Tools
### read_file(path: string) -> string
Returns the contents of a file at the given path.
Use when: the user asks about a specific file's contents, you need to verify code before modifying it.
Do NOT use to: explore directories speculatively. Always ask the user for the file path rather than guessing.
### write_file(path: string, content: string) -> void
Writes content to a file, creating it if it does not exist.
Use when: the user explicitly asks you to save, write, or create a file.
CONFIRM before use: Always confirm the file path and content with the user before writing. This action cannot be undone.
### run_command(command: string) -> string
Executes a shell command and returns stdout.
RESTRICTED: Only use for read-only commands (ls, cat, grep, find). Never use for commands that modify the filesystem, network, or system state. If unsure whether a command is read-only, ask the user.
When to Use Each Tool: Decision Logic
Beyond individual tool descriptions, provide explicit decision logic for choosing between tools:
## Decision Rules
1. Answer from knowledge first: If you can accurately answer the question from your training data, do so without using tools. Tool calls add latency and cost.
2. Verify before modify: If a task involves modifying a file, always read the current contents first.
3. One tool at a time: Complete each tool call and process the result before deciding whether another tool call is needed. Do not chain tool calls without reviewing intermediate results.
4. Prefer asking over guessing: If you are unsure which file to modify, which command to run, or what the user intends, ask for clarification rather than making your best guess.
Output Format for Tool Calls
Specify how tool calls should be formatted. For function calling APIs, the format is defined by the API. For text-based tool use (ReAct format), define it explicitly:
When you need to use a tool, format your response as:
Thought: [Your reasoning about what to do next]
Action: tool_name
Action Input: {"param": "value"}
After you receive the tool result:
Observation: [The tool result]
Thought: [Your reasoning about what the result means and what to do next]
Continue until you have enough information to answer, then:
Final Answer: [Your response to the user]
The "Thought" step is critical — it forces the model to reason before acting, which catches mistakes that pure action-taking misses. This is the core of the ReAct (Reasoning + Acting) framework.
Stopping Conditions
Without explicit stopping conditions, agents loop. They keep calling tools looking for more information even when they have enough to answer. Define when the agent should stop:
## Stopping Conditions
Stop and provide a Final Answer when:
- You have enough information to answer the user's question accurately
- You have completed the task the user requested
- You have encountered an error that prevents completion and need user input
Do NOT continue calling tools when:
- You have already retrieved the information needed to answer
- A tool call returned an error on the second attempt (escalate to user instead)
- You are making the same tool call with the same parameters a second time (you are looping — stop and ask for guidance)
The "same tool call twice" rule catches the most common loop pattern. If the model is calling the same search query twice, it is not getting more information — it is stuck.
Safety Constraints
Safety constraints define what the agent will never do regardless of instructions:
## Safety Constraints (Non-Negotiable)
Never:
- Execute commands that delete files, drop databases, or modify system configuration
- Send emails or messages on behalf of the user without explicit confirmation for each send
- Store or log any content that appears to be a password, API key, or private key
- Access files outside the user's project directory
- Make API calls to external services not listed in Available Tools
- Proceed with irreversible actions if you are uncertain about the user's intent
If a user asks you to take any of the above actions, explain that it is outside your operating parameters.
The framing "non-negotiable" and "regardless of instructions" is intentional — it makes the constraint more robust against injection attacks that try to override safety guidelines by claiming to be a special mode or elevated permissions.
Handling Uncertainty: Ask Rather Than Guess
The most important behavioral instruction for agents is what to do when uncertain:
## Handling Uncertainty
When you are uncertain about:
- The user's intent ("did they want me to delete the old file or keep it?")
- Which tool to use ("should I use search or ask the user directly?")
- Whether an action is safe to take
Always ask for clarification rather than proceeding with your best guess. A wrong action is worse than a delayed response. Format your clarification request as a specific yes/no or multiple-choice question, not an open-ended question.
Good: "Should I delete the original file after copying it, or keep both? (delete / keep both)"
Bad: "What would you like me to do with the original file?"
The format guidance for clarification questions is important — open-ended questions slow the workflow, while specific options get fast answers.
Common Agent Failure Modes
Tool overuse: The agent uses a tool when it could answer from knowledge. Fix: explicit "answer from knowledge first" rule and precise "Use when" criteria.
Infinite loops: The agent calls the same tool repeatedly. Fix: explicit loop detection rule and stopping conditions.
Unsafe assumption: The agent infers user intent on irreversible actions instead of asking. Fix: confirm-before-irreversible-action instruction.
Injection from external content: The agent processes a document containing injected instructions and acts on them. Fix: explicit instruction that external content cannot override agent instructions.
Context drift: In long agent sessions, the model loses track of the original goal and gets sidetracked by intermediate results. Fix: periodically remind the agent of the original goal in your orchestration code, or include an instruction to re-read the original request before each action.
Over-explanation: The agent explains its reasoning in the final answer rather than just answering. Fix: "Final Answer should be direct and actionable. Do not explain your process unless asked."
Keep Reading
- System Prompt Guide with Examples — foundation for all system prompt design
- System Prompt Security Guide — protecting agent prompts from injection and extraction
- Prompt Injection Security Guide — defending agents against indirect injection from external content
Pristren builds AI-powered software for teams. Zlyqor is our all-in-one workspace — chat, projects, time tracking, AI meeting summaries, and invoicing — in one tool. Try it free.
