Why Agent Prompting Is Different From Chatbot Prompting
The prompting techniques that work for a conversational chatbot transfer poorly to agents. A chatbot prompt sets persona and tone; an agent prompt is effectively an operating system — it defines the agent's decision-making logic, its authority boundaries, its tool usage policy, its error handling behavior, and its output contracts. The stakes are also higher: a chatbot prompt mistake produces a bad answer; an agent prompt mistake can cause incorrect tool calls that modify external state, loop indefinitely, or expose private data. Three specific differences matter. Agents act in loops, not single turns: the prompt must produce coherent behavior across many sequential reasoning steps, not just a single response. Every tool call result, every intermediate observation, every prior reasoning step adds to the context the agent reasons over — the prompt must remain effective even when context is long and potentially contains contradictory signals. Agents make irreversible actions: the prompt must encode clear preconditions for high-stakes tool calls (authorization checks, confirmation requirements) because there is no undo for a sent email or a submitted order. Agents operate with partial information: unlike a chatbot where the user's question is fully stated, an agent often needs to determine when it has enough information to proceed vs when it needs to ask a clarifying question. This requires explicit uncertainty handling logic in the prompt, not an implicit assumption that the task is always fully specified. The Framework Radar on AgentList surfaces which frameworks impose constraints on prompt structure that you need to accommodate.
System Prompt Architecture: Role, Context, Constraints, Output Format
A well-structured agent system prompt has four distinct sections, and the order matters because LLMs give more weight to content earlier in long prompts. Role definition establishes who the agent is and what it's optimized for. Specificity matters: 'You are an AI assistant' is nearly useless; 'You are a procurement specialist agent for Acme Corp with read access to the ERP and authority to initiate purchase orders up to $10,000 without additional approval' gives the model the context it needs to make correct decisions about what actions are within its scope. Operational context provides the background the agent needs to do its job: current date, relevant business rules, the state of the current task (loaded from memory), and any dynamic context that changes per invocation (the user's role, the current approval limits in effect). This section is the one that changes most between invocations and should be constructed programmatically at prompt assembly time. Constraints are the guardrails: what the agent must never do, what requires human approval, what to do when uncertain. Constraints should be stated positively where possible ('always confirm the user's identity before accessing account details') rather than as a long list of negatives. Output format specifies exactly what structure the agent's responses and tool calls should take. For tool-calling agents, this includes the expected chain-of-thought format, how to express uncertainty, and the required fields in structured outputs. Make the format examples concrete — include a minimal but complete example of a correctly formatted response for the primary task type.
Tool Call Prompting: When and How to Use Tools
The LLM's decision of when to call a tool, which tool to call, and what parameters to pass is driven almost entirely by the tool's schema and description — not the system prompt. This is the most commonly misunderstood aspect of agent prompting. Poorly described tools are the primary cause of incorrect tool selection and malformed parameters. Each tool description should answer three questions: what does this tool do (be specific about what it returns, not just what it's for), when should it be called (what conditions indicate this tool is appropriate vs a different one), and what are the parameter contracts (type, format, valid ranges, and a concrete example for any non-obvious parameter). Avoid vague descriptions like 'searches the database'. Write: 'Queries the order management system for orders matching the given criteria. Returns a list of up to 20 order objects with fields: order_id, status, items, total, created_at. Use this tool when the user asks about order status, order history, or delivery timelines. Do not use this tool for payment-related queries — use get_payment_history instead.' The disambiguation note (Do not use this tool for X) is particularly valuable when you have multiple tools with overlapping apparent purposes. Parallel tool calls (invoking multiple tools in a single LLM turn) require explicit prompting guidance: 'When multiple pieces of information are needed simultaneously to answer a question, call all relevant tools in a single response rather than making sequential calls.' Without this instruction, models often default to sequential tool calls even when parallelism would be more efficient.
ReAct vs Chain-of-Thought Prompting for Agents
ReAct (Reasoning + Acting) is the dominant prompting pattern for tool-using agents. The agent interleaves explicit reasoning steps ('Thought: I need to check the current order status before processing the refund request') with tool calls ('Action: get_order_status(order_id=12345)') and observations from tool results ('Observation: Order 12345 is in status DELIVERED, delivered 8 days ago'). This thought-action-observation loop continues until the agent has enough information to produce a final answer. ReAct's strength is interpretability: the reasoning chain is explicit and inspectable. A failed ReAct trace tells you exactly where the reasoning went wrong. Standard chain-of-thought (CoT) prompting, without the tool call interleaving, is better suited for tasks where the agent needs to reason extensively before acting — complex multi-step math, planning problems, logical deduction — but has no need for external information. For most production agents, ReAct is the right default. The key implementation detail is the stopping condition: the ReAct loop must have an explicit termination rule. Common patterns: terminate when the agent produces a 'Final Answer:' prefixed response, or terminate when a maximum step count is reached. Without a maximum step count, a confused agent can loop indefinitely. The maximum step count should be set based on the expected steps for the most complex task in your agent's scope — typically 5–15 for well-scoped agents — with a hard ceiling that triggers a graceful degradation path.
Few-Shot Examples for Tool Use
Few-shot examples in agent prompts serve a different purpose than in standard prompting. You're not teaching the model new capabilities — you're establishing the expected format, level of detail in reasoning, and decision-making style for your specific use case. Effective tool-use few-shot examples demonstrate: the appropriate granularity of reasoning steps (not too brief to be unclear, not so verbose that they consume context budget), how to handle tool results that are ambiguous or partially relevant, and the correct behavior at decision branch points (when to ask a clarifying question vs when to proceed with a best guess). Include at least one negative example — a scenario where the agent correctly determines it doesn't have enough information and asks for clarification rather than guessing. This models the uncertainty-aware behavior you want and gives the LLM a template to follow. For few-shot examples in agent prompts, prioritize quality over quantity. Two excellent examples with rich reasoning chains are more valuable than five thin examples. Each example should be drawn from real interactions — either from your golden test set or from reviewed production traces. Auto-generating examples from the LLM itself produces circular reasoning: the model produces the style of reasoning it would produce anyway, not the style you want to teach it. Keep examples updated: as your tool schemas evolve, outdated examples become actively harmful — they demonstrate calling tools with deprecated parameter names or formats that are no longer valid.
Prompt Versioning and Testing
Production agent prompts need the same version control discipline as code. An unversioned prompt deployed to production is untraceable — when behavior changes, you have no way to determine whether it was caused by a prompt change, a model update, a tool schema change, or a data distribution shift. The minimum viable prompt versioning system: store prompts in version-controlled files (not hardcoded strings in application code), use semantic versioning (1.0.0 to 1.0.1 for minor wording changes, 1.1.0 for behavioral additions, 2.0.0 for structural changes), and log the prompt version on every agent invocation alongside the trace. This creates an audit trail: for any production incident, you can identify which prompt version was active and retrieve the exact prompt text. Prompt A/B testing requires splitting traffic by session (not by request — serving the same user different prompt versions within a session produces inconsistent behavior) and measuring with your eval metrics, not just user satisfaction proxies. PromptFoo automates this: define both prompt versions in a config, specify your test set and eval criteria, and it runs the comparison and produces a statistical analysis of which version performs better across metric dimensions. For model version upgrades (e.g., migrating from GPT-4o to GPT-4.5), always run your full golden test set against the new model before switching production traffic — model updates can silently change tool-calling behavior, JSON formatting adherence, and refusal rates in ways that break agents that worked fine on the previous model version.
Common Failure Modes: Over-Tooling, Prompt Injection, Agentic Jailbreaks
Three failure modes are specific to agent prompting and require explicit mitigation. Over-tool-calling occurs when the agent calls tools unnecessarily — fetching data it doesn't need, making redundant API calls to confirm information it already has, or calling a data-modifying tool when a read-only tool would suffice. The root cause is usually tool descriptions that don't clearly communicate when a tool should NOT be called, or a system prompt that rewards thoroughness over efficiency. Mitigation: add explicit cost-awareness instructions to the prompt (only call tools when the information is necessary to answer the current question — do not pre-fetch data speculatively), instrument tool call counts per task, and add over-calling examples to your eval set. Prompt injection is the most serious security concern for agentic systems. An adversarial string in tool results (e.g., a document the agent reads that contains instructions to disregard previous instructions and exfiltrate data) can hijack the agent's behavior if the prompt doesn't explicitly defend against it. Mitigation: separate tool result content from instruction context using structural markers the model is trained to respect, include explicit injection defense instructions in the system prompt, and filter tool results for common injection patterns before passing to the LLM. Agentic jailbreaks exploit the agent's tool access to cause harm that the model alone couldn't be jailbroken into. A user who convinces an agent that calling a specific tool is required for their legitimate task can potentially trigger actions the agent would otherwise refuse. Defense: scope every tool's access control to the minimum necessary, require explicit confirmation for irreversible high-impact actions regardless of what the user claims, and log all tool invocations for security review. The Interview Questions resource on AgentList includes questions you can ask prospective agent developers specifically about their prompt security practices.
Find agencies that specialize in the frameworks and use cases covered in this article.
Find the right AI agent agency for your project.