Prompt Engineering for Agents
Why agent prompting is different from chatbot prompting
Overview
In Module 1, we built our first agent -- a calculator that uses tools to solve math problems step by step. That agent worked, but take another look at its system prompt: "You are a calculator assistant. Use the provided tools to solve math problems step by step." A single sentence. For a calculator, that was enough. For anything more complex, it would fall apart.
Prompt engineering for agents is fundamentally different from prompting a chatbot or a text completion model. A chatbot prompt shapes a single response. An agent prompt shapes an entire chain of decisions -- which tools to call, in what order, how to interpret results, when to retry, and when to stop. Getting this right is the difference between an agent that reliably completes tasks and one that spirals into confused loops or produces dangerously wrong outputs.
This lesson explains why agent prompting is its own discipline, introduces the anatomy of a well-structured agent prompt, and shows you how to build one. In the next lesson, we will layer on Chain-of-Thought reasoning to make our agents think more carefully before acting.
Why Agent Prompts Are Different
When you prompt a chatbot, the interaction is simple: the user sends a message, the model responds, done. The model's job is to produce helpful, coherent text in a single turn. If the response is slightly off, the user can follow up and course-correct.
An agent operates in a fundamentally different context. It runs in a loop, making a sequence of decisions without human intervention between steps. Each decision -- which tool to call, what arguments to pass, how to interpret the result -- builds on the previous one. A bad decision early in the chain does not just produce a poor response; it cascades, causing the agent to call the wrong tools, misinterpret results, or loop indefinitely.
This means an agent prompt must do several things that a chatbot prompt never needs to worry about:
- Tool selection -- the model must understand what tools are available and choose the right one for each step
- Multi-turn state management -- the model must track what it has already done and what remains
- Output format constraints -- the model must produce responses that your code can parse and route correctly
- Error recovery -- the model must know what to do when a tool fails or returns unexpected results
- Behavioral boundaries -- the model must know what it should not do, not just what it should do
- Stopping conditions -- the model must know when the task is complete and it should stop acting
graph LR
subgraph Chatbot["Chatbot Prompt"]
C1["Personality & tone"]
C2["Knowledge boundaries"]
C3["Response style"]
end
subgraph Agent["Agent Prompt"]
A1["Role definition"]
A2["Tool instructions"]
A3["Output format"]
A4["Error recovery"]
A5["Behavioral boundaries"]
A6["Stopping conditions"]
end
Chatbot --- Agent
style Chatbot fill:#fff5f5,stroke:#fc8181
style Agent fill:#f0fff4,stroke:#68d391
Notice the asymmetry. A chatbot prompt has three concerns. An agent prompt has six or more. And the agent concerns are harder -- they involve reasoning about actions and their consequences, not just generating appropriate text.
The Anatomy of an Agent Prompt
A well-structured agent prompt is not a wall of text. It is organized into distinct sections, each serving a specific purpose. Think of it like a job description: you would not hand someone a rambling paragraph and expect them to know exactly what to do. You would give them a role, responsibilities, procedures, and boundaries.
Here are the six core sections of an agent prompt:
Role definition tells the model who it is and what its primary mission is. This anchors every subsequent decision. A model that knows it is a "code review assistant" will make different tool choices than one told it is a "data analysis agent."
Capability boundaries specify what the agent can and cannot do. This is where you list what tools are available (the API provides tool definitions, but the prompt gives context about when to use them) and what topics or domains are out of scope.
Tool instructions explain how to use the available tools effectively. While the API's tool definitions tell the model the function signatures, the prompt provides the strategy: when to prefer one tool over another, how to chain tool calls, and what to do with ambiguous results.
Output format specification defines how the agent should structure its responses. Should it think step-by-step before acting? Should it summarize results in a particular format? Should it use markdown, JSON, or plain text?
Behavioral guidelines set the rules of engagement. These include safety constraints ("never delete files without confirmation"), quality standards ("always verify results before reporting"), and interaction patterns ("ask for clarification when the request is ambiguous").
Error handling instructions tell the agent what to do when things go wrong. This is the section most people forget, and it is the one that matters most in production. Tools fail, APIs time out, and data is malformed. Without explicit recovery instructions, the agent will either hallucinate a result or loop endlessly.
A Side-by-Side Comparison
Let's make the difference concrete. Here is the same task -- helping a user query a database -- with a chatbot prompt and an agent prompt.
This works fine for a chatbot. The user asks "How do I join two tables?", the model explains JOINs. But this prompt would fail catastrophically for an agent that actually executes queries. It says nothing about which tools to use, how to handle errors, or when to stop.
The difference is stark. The agent prompt is longer, but every section earns its place. Remove the procedure section and the agent might query before checking the schema. Remove the constraints and it might run destructive queries. Remove the error handling and a single typo in a query could crash the loop.
Building a Prompt: The Research Agent Example
Let's walk through constructing an agent prompt from scratch for a more realistic scenario: a research agent that searches the web and summarizes findings. This example shows how each section works together.
Notice the patterns:
- The role is one sentence that establishes the mission.
- Tool instructions go beyond the API schema -- they include usage strategy ("Use specific, targeted queries") and chaining advice ("reformulate and try again").
- The procedure is numbered, giving the model a clear decision sequence.
- Error handling covers three specific failure modes with concrete recovery actions.
- Constraints are stated as absolute rules with "NEVER" and "Do NOT."
- The completion section tells the model exactly when to stop.
Common Prompt Engineering Mistakes for Agents
Even experienced engineers make these mistakes when writing agent prompts. Each one seems minor but can cause significant failures in a multi-step execution loop.
Missing stopping conditions. Without explicit instructions about when the task is complete, agents tend to keep acting -- running extra searches, making unnecessary API calls, or looping back to re-verify work they have already done. Always include a "when you are done" section.
Vague tool instructions. Telling the model "use the available tools" is like telling a new employee "use the office equipment." They need to know which tool for which situation, and what to do when a tool's output is ambiguous.
No error recovery path. In a chatbot, a failed response is mildly annoying. In an agent, a failed tool call without a recovery plan means the agent either hallucinates a result (dangerous) or enters an infinite retry loop (expensive). Always specify what to do when things go wrong.
Over-constraining the model. The opposite mistake is also common. If your prompt is so prescriptive that the model cannot exercise judgment, you have built a rigid script, not an agent. The goal is to set boundaries while leaving room for the model to reason about novel situations.
Key takeaway: A good agent prompt balances structure with flexibility. It provides clear procedures for common cases and clear principles for novel ones.
Prompt Structure as a Design Pattern
You can think of the six-section agent prompt as a design pattern -- a reusable template that you adapt to each new agent. Here is the pattern:
graph TD A["Role Definition<br/>Who you are and your mission"] --> B["Capability Boundaries<br/>What you can and cannot do"] B --> C["Tool Instructions<br/>How and when to use each tool"] C --> D["Output Format<br/>How to structure responses"] D --> E["Behavioral Guidelines<br/>Rules, constraints, safety"] E --> F["Error Handling & Completion<br/>Recovery paths and stopping conditions"] style A fill:#ebf8ff,stroke:#3182ce style B fill:#ebf8ff,stroke:#3182ce style C fill:#e6fffa,stroke:#38b2ac style D fill:#e6fffa,stroke:#38b2ac style E fill:#fefcbf,stroke:#d69e2e style F fill:#fefcbf,stroke:#d69e2e
The first two sections (blue) establish identity -- who the agent is and what it is scoped to do. The middle two (teal) define operations -- how the agent acts in the world. The last two (yellow) set guardrails -- what keeps the agent safe and efficient. In the upcoming lesson on System Prompt Design, we will dive much deeper into each of these layers and explore advanced patterns like dynamic prompt assembly and context-dependent instructions.
From Prompting to Reasoning
The prompts we have built so far tell the agent what to do and how to do it. But they do not explicitly tell it how to think. Consider a complex request like "Find the most cost-effective cloud provider for a startup running ML workloads." An agent with a good prompt will know to search the web and compare options. But will it think through the comparison systematically, or just grab the first answer it finds?
This is where reasoning techniques come in. In the next lesson, we will explore Chain-of-Thought reasoning -- a prompting approach that instructs the model to break complex problems into explicit intermediate steps before deciding on an action. Combined with the structured prompt patterns from this lesson, Chain-of-Thought transforms an agent from a simple tool-caller into a genuine problem-solver.
Summary
Agent prompting is a distinct discipline from chatbot or completion prompting. The key differences stem from the fact that agents operate in loops, making chains of decisions where each step builds on the last:
- Chatbot prompts shape a single response. Agent prompts shape an entire decision process.
- A well-structured agent prompt has six sections: role definition, capability boundaries, tool instructions, output format, behavioral guidelines, and error handling with completion criteria.
- The most common mistakes are missing stopping conditions, vague tool instructions, and no error recovery path.
- Good agent prompts balance structure (clear procedures for common cases) with flexibility (clear principles for novel situations).
- Think of the six-section prompt as a design pattern -- a reusable template you adapt for each new agent you build.
The prompt is the most important lever you have over agent behavior. In the lessons ahead, we will build on this foundation with Chain-of-Thought reasoning, structured outputs, and advanced system prompt design to give you a complete toolkit for steering agents through complex tasks.