Start with the real problem
An AI agent uses a model to choose among steps and tools while working toward a goal. The surrounding application controls what it is allowed to do.
Least privilege means giving the agent only the tools and data it needs for its current job. A homework helper, for example, should not also receive permission to send email or delete files.
An agent is not made reliable by telling it to act on its own. It needs a clear goal with limits, available actions, state, evidence rules, budgets, and a clear stopping condition.
goal → observe → decide → act → inspect result → repeat or stopWhat you will learn
- Write a agent goal with clear limits.
- Define tools, authority, and approval boundaries.
- Add stopping, retry, and fallback rules.
- Separate prompt instructions from runtime enforcement.
How this connects to current AI systems
Agent systems built with GPT, Gemini, or Claude need code that coordinates steps, state, tracing, and least-privilege tools in addition to a well-written prompt.
1. Why This Module Exists
This module is where Level 3 (reasoning, decomposition, chaining) and Level 4’s earlier modules (messages, context, RAG, tool calling) all come together. An agent’s prompt isn’t a single request for a single response — it’s an ongoing set of instructions that shapes an entire sequence of decisions, actions, and responses. This module makes that whole picture explicit.
2. The Idea, in Plain Language
An agent prompt isn’t just “what do you want the AI to say” — it’s “how should the AI behave, decide, and act, across an entire task that might take many steps.”
A normal prompt: one request -> one response
An agent prompt: goals + tools + rules + constraints
-> a whole sequence of reasoning, tool
calls, and responses, continuing until
the task is really doneThis is a real, meaningful shift in what “the prompt” is even doing.
3. What an Agent Prompt Actually Needs to Cover
Goal: what is the agent ultimately trying to accomplish?
Available tools: what can it actually do? (Module 18)
Tool usage rules: when to use which tool, and when not to
(Module 18)
Planning: how should it break the goal into steps?
(Module 11)
Constraints: what actions is it NOT allowed to take
on its own? (Module 9)
Error handling: what should it do if a tool fails or
returns something unexpected?
Stop conditions: when is the task actually
complete? When should it ask for
help instead of continuing alone?Notice: almost every one of these connects directly back to a module you’ve already covered. Agent prompting isn’t a new set of skills — it’s everything from this course, combined and applied to something that unfolds over multiple steps instead of one.
4. A Weak vs. Strong Agent Prompt
Weak
"You are a helpful assistant. Help the user with their travel
booking."This says almost nothing about how to help — what tools exist, what the agent is and isn’t allowed to do on its own, what to do if something goes wrong, or when to stop and ask the user something.
Strong
"You are a travel booking agent. Your goal is to help the user book
a flight and hotel that match their stated preferences.
Available tools: search_flights, search_hotels, book_flight, book_hotel
Rules:
1. Always search and present options before booking anything -- never
book without explicit user confirmation of the specific option.
2. If search returns no results matching the user's criteria, tell
them clearly and ask if they'd like to adjust their preferences.
3. If a tool call fails or returns an error, do not retry silently --
tell the user what happened.
4. You may search freely, but you must NEVER book a flight or hotel
without the user explicitly confirming that specific option first.
Stop and ask the user for clarification if:
- Travel dates are ambiguous or not yet provided.
- Budget or preference information needed to search is missing."Every single line here resolves a specific kind of ambiguity a real agent would otherwise have to guess about — exactly the same principle from Module 2, now applied to an agent’s entire operating behavior rather than one response.
5. Planning and State — Why Agents Need More Than a Static Prompt
Unlike a single-turn prompt, an agent often needs to track what’s already happened in its own task — which steps are done, what information it’s already gathered, what it’s still waiting on. This is sometimes called the agent’s “state,” and good agent prompting accounts for it:
"Before deciding your next action, review what you've already done in
this task:
- What information have you already gathered?
- What steps have already been completed?
- What is still needed to reach the goal?
Do not repeat a tool call you've already made with the same
parameters unless something has really changed."This directly prevents a real, common agent failure: redundant, repeated tool calls because the agent didn’t “remember” it already tried something — a really important instruction once tasks span multiple steps.
6. A Real Example From a Developer’s Perspective
Say you’re building a research agent that needs to gather information from multiple sources before answering:
"You are a research assistant agent. Goal: answer the user's question
thoroughly, using the search_web tool as needed.
Planning:
1. Break the question into the specific sub-questions you'd need to
answer to fully address it.
2. Search for each sub-question separately, rather than one broad
search.
3. After each search, decide whether you have enough information, or
need to search again with a refined query.
Stop conditions:
- Stop searching once you have enough information to answer
thoroughly, or after 5 searches, whichever comes first.
- If after 5 searches you still don't have a satisfying answer, tell
the user what you found and what remains uncertain -- do not keep
searching indefinitely."The explicit search limit (5 searches) is a really practical constraint — without it, a research agent could loop indefinitely, searching over and over without a clear stopping point, wasting time and cost.
7. A Simple Agentic AI Example — Error Handling
Since this whole module is about agents, here’s specifically how error handling shows up in an agent prompt:
"If a tool call returns an error or unexpected result:
1. Do not assume the task failed entirely -- check whether the error
is something you can work around (e.g., try a different search
query).
2. If you cannot recover from the error after one retry, clearly tell
the user what went wrong rather than pretending the task succeeded.
3. Never fabricate a plausible-sounding result if a tool call actually
failed."That last rule is directly connected to Module 22 (hallucination) — explicitly forbidding the agent from generating a fake, plausible- sounding “success” when a real tool call really failed.
8. How Is This Used in AI?
🤖 How Is This Used in AI?
Every real AI agent — a coding assistant that can run and fix code, a customer support agent with real tool access, a research assistant that searches multiple sources — is built on exactly this kind of comprehensive instruction set: goals, tools, rules, planning guidance, error handling, and stop conditions, all working together. Frameworks like LangChain and LangGraph, and patterns like ReAct (reason, act, observe, repeat), are built on top of this same underlying prompting foundation.
9. When Should You Think This Comprehensively?
- Any system where the AI can take real, multi-step actions, not just generate a single response
- Any system where errors, ambiguity, or missing information are realistic possibilities the agent needs a plan for
- Any system where unsupervised, action without constant human direction has genuine consequences — the more consequential, the more thorough this needs to be
10. When Is This Overkill?
- Simple, single-turn, no-tool-access interactions don’t need this level of instruction — most of this course’s earlier modules already cover that territory well
11. Common Mistakes
Incorrect idea
Treating an agent prompt like a normal, single-response prompt.
Why it is incorrect
As shown directly, an agent needs goals, rules, planning guidance, error handling, and stop conditions — a normal prompt’s level of detail isn’t enough.
Incorrect idea
Not defining clear stop conditions.
Why it is incorrect
Without them, an agent can loop indefinitely, retry endlessly, or simply not know when it’s actually done — a really common, costly failure mode.
Incorrect idea
Allowing high-impact actions without explicit confirmation rules.
Why it is incorrect
The travel-booking example’s “never book without explicit confirmation” rule exists precisely because agents that can take real actions need real, stated boundaries around autonomy.
Incorrect idea
Not accounting for state — what the agent has already done.
Why it is incorrect
Without this, agents can repeat redundant actions, as shown directly in Section 5.
Analogy: The Corporate Employee Handbook Think of prompting an AI agent like writing an employee handbook for a new remote assistant:
- The Vague Orientation (Single-turn): You tell them: “Welcome. Answer emails as they come in.”
- The assistant doesn’t know what systems they are allowed to use, how to handle customer refunds, or when to wake you up for an emergency.
- The Standard Operating Procedure (Agent Prompting): You hand them a detailed handbook:
- Objective: Manage support tickets.
- Tools: Database access, Slack messaging.
- Constraints: Never issue a refund > $50. Never edit database rows directly.
- Escalation Path (Stop Condition): If a customer uses profanity or the database returns a timeout, immediately message a manager and pause.
- The handbook governs hours of behavior without constant human direction across multiple steps.
📊 Visual Flowchart: The Agentic Decision Loop
Here is how goals, state, tools, and stop conditions interact in an agent workflow:
graph TD
classDef config fill:#2ecc71,stroke:#333,stroke-width:1px,color:#fff;
classDef process fill:#3498db,stroke:#333,stroke-width:1px,color:#fff;
classDef check fill:#f1c40f,stroke:#333,stroke-width:1px,color:#fff;
Start["User Goal: 'Book travel'"] --> AgentInit["Load System Rules:<br>(Goals, Tools, Constraints, Safety bounds)"]:::config
AgentInit --> CheckState["1. Read Current State:<br>(What is done? What is next?)"]:::process
CheckState --> Decide["2. LLM Step Decision:<br>'Should I call a tool or reply?'"]:::process
Decide -->|Tool Needed| ExecuteTool["3. Run Tool & Update State"]:::process
ExecuteTool --> CheckState
Decide -->|Stop Condition Met| FinalReply["4. Generate Final Answer for User"]:::check
Decide -->|Error / Timeout| Escalate["4. Escalate to human manager"]:::check12. Limitations
- Even a comprehensive, well-designed agent prompt doesn’t guarantee perfect behavior — agents can still occasionally misinterpret instructions, especially across many steps in a long-running task
- Prompt-level rules for high-impact actions (like “never book without confirmation”) are important, but — exactly like Module 9 and 18’s constraint discussions — real production agent systems often add code-level enforcement as an additional safeguard, not relying on the prompt alone
- Agent prompting draws on nearly every earlier module in this course — there’s no shortcut around understanding decomposition, chaining, tool calling, and context management individually first
13. Quick Reference — The Whole Idea in One Diagram
Agent prompt = Goal + Tools + Usage rules + Planning guidance
+ Constraints + Error handling + Stop conditions
↓
Shapes an entire MULTI-STEP sequence of reasoning, tool use, and
responses -- not just one single output
↓
Draws on: Module 9 (constraints), 11 (decomposition), 13 (chaining),
16 (context), 17 (RAG grounding), 18 (tool calling)14. Prompts in Code — Calling an LLM
Here’s how a real agent instruction set actually looks when calling an LLM through code — combining tools, rules, and a basic execution loop.
Example 1 — Simple
A single-step agent call with tools and basic rules in the system prompt.
import anthropic
client = anthropic.Anthropic()
AGENT_SYSTEM_PROMPT = """You are a travel booking agent. Always
search and present options before booking anything -- never book
without explicit user confirmation."""
tools = [{
"name": "search_flights",
"description": "Searches for available flights matching given criteria.",
"input_schema": {"type": "object",
"properties": {"destination": {"type": "string"},
"date": {"type": "string"}},
"required": ["destination", "date"]},
}]
response = client.messages.create(
model="claude-sonnet-4-6", max_tokens=300,
system=AGENT_SYSTEM_PROMPT, tools=tools,
messages=[{"role": "user", "content": "Find me a flight to Chicago next Tuesday."}]
)
print(response.content)Example 2 — Intermediate
A basic agent loop that processes a tool call, feeds the result back, and continues the conversation — the actual reason-act-observe cycle from Section 6.
import anthropic
client = anthropic.Anthropic()
AGENT_SYSTEM_PROMPT = """You are a travel booking agent. Always
search before booking. Never book without user confirmation."""
tools = [{
"name": "search_flights",
"description": "Searches for flights.",
"input_schema": {"type": "object",
"properties": {"destination": {"type": "string"},
"date": {"type": "string"}},
"required": ["destination", "date"]},
}]
def fake_flight_search(destination, date):
return f"Found 2 flights to {destination} on {date}: Flight A ($320), Flight B ($410)"
messages = [{"role": "user", "content": "Find me a flight to Chicago next Tuesday."}]
response = client.messages.create(
model="claude-sonnet-4-6", max_tokens=300,
system=AGENT_SYSTEM_PROMPT, tools=tools, messages=messages,
)
for block in response.content:
if block.type == "tool_use":
result = fake_flight_search(**block.input)
messages.append({"role": "assistant", "content": response.content})
messages.append({"role": "user", "content":
[{"type": "tool_result", "tool_use_id": block.id, "content": result}]})
final_response = client.messages.create(
model="claude-sonnet-4-6", max_tokens=300,
system=AGENT_SYSTEM_PROMPT, tools=tools, messages=messages,
)
print(final_response.content[0].text)Example 3 — Production Grade
A more complete agent loop with a stop-condition safeguard (max steps, directly from Section 6’s search-limit example), state tracking to avoid redundant tool calls, and a clean separation between what the agent decides and what the code actually executes and enforces.
import anthropic
client = anthropic.Anthropic()
AGENT_SYSTEM_PROMPT = """You are a research agent. Break the question
into sub-questions and search for each. Never book or take
irreversible actions -- this agent only searches and reports back."""
tools = [{
"name": "search_web",
"description": "Searches the web for information relevant to a query.",
"input_schema": {"type": "object",
"properties": {"query": {"type": "string"}},
"required": ["query"]},
}]
def fake_search(query):
return f"[Simulated search results for: {query}]"
def run_research_agent(question: str, max_steps: int = 5) -> str:
messages = [{"role": "user", "content": question}]
queries_made = set() # state tracking -- avoid redundant searches
for step in range(max_steps):
response = client.messages.create(
model="claude-sonnet-4-6", max_tokens=400,
system=AGENT_SYSTEM_PROMPT, tools=tools, messages=messages,
)
tool_calls = [b for b in response.content if b.type == "tool_use"]
if not tool_calls:
# No more tool calls -- agent is ready to give a final answer
text_blocks = [b.text for b in response.content if b.type == "text"]
return "\\n".join(text_blocks)
messages.append({"role": "assistant", "content": response.content})
for call in tool_calls:
query = call.input["query"]
if query in queries_made:
result = "You already searched this exact query -- try a different angle."
else:
result = fake_search(query)
queries_made.add(query)
messages.append({"role": "user", "content":
[{"type": "tool_result", "tool_use_id": call.id, "content": result}]})
return "Reached maximum research steps without a final answer. " \\
"Here's what was found so far -- may be incomplete."
answer = run_research_agent("What are the main causes of coral reef bleaching?")
print(answer)The max_steps loop limit and the queries_made state tracking are
both enforced in code, not just requested in the prompt — exactly
the stop-condition and redundant-action problems from Sections 5 and 6,
solved with real, reliable safeguards rather than trusting the model to
self-limit perfectly on its own.
When to use it—and when not to
Use it when:
- the task really requires several adaptive steps.
- tool choice depends on observations made during execution.
Do not rely on it when:
- a fixed workflow is simpler and safer.
- the agent has broad permissions without monitoring or limits.
15. Interview Questions
Q: How is an agent prompt fundamentally different from a normal, single-response prompt?
Ans: A normal prompt asks for one response to one request. An agent prompt has to shape an entire, potentially multi-step sequence of reasoning, tool use, and decision-making — it needs to cover the agent’s goal, available tools and when to use them, planning guidance, constraints on what it can do autonomously, error handling, and clear conditions for when the task is complete or when it should stop and ask for help, rather than just describing a single desired output.
Q: Why are explicit stop conditions important in an agent’s instructions?
Ans: Without them, an agent can continue indefinitely — retrying failed actions repeatedly, searching without limit, or simply not recognizing when a task is actually complete. Explicit stop conditions (like a maximum number of search attempts, or clear criteria for “the task is done”) prevent this, giving the agent a concrete, checkable signal for when to conclude, rather than leaving that judgment entirely open-ended.
Q: Why might an agent’s system prompt state “never book without explicit user confirmation,” and why isn’t stating this in the prompt alone always sufficient?
Ans: This rule protects against the agent taking a real, hard-to-reverse action (booking travel, spending money) without appropriate human oversight — a genuine safety boundary, not just a style preference. Similar to constraints and tool-calling safeguards covered earlier in this course, a prompt-level rule doesn’t guarantee perfect compliance on every single interaction; production agent systems often also enforce such boundaries independently in code (for example, requiring a separate explicit confirmation step before actually executing a booking action) as a second, more reliable layer of protection.
Q: How does task decomposition, covered earlier in this course, directly apply to agent design?
Ans: An agent’s core operation often IS task decomposition in action — breaking a high-level goal (like “help me research this topic” or “book my trip”) into smaller, sequential sub-tasks (search for sub-questions, present options, confirm before booking), executing each one, and using the results to inform the next step. Everything covered about decomposition and prompt chaining earlier in this course directly describes the mechanics underlying how a well-designed agent actually operates.
16. What You Should Remember
- An agent prompt shapes an entire multi-step behavior and control system — goal, tools, usage rules, planning, constraints, error handling, and stop conditions — not just one response.
- Explicit stop conditions and state tracking prevent real, common agent failures: infinite loops, redundant actions, and tasks that never conclude.
- For high-impact actions, prompt-level rules are an important first layer, but production systems typically also enforce critical boundaries independently in code.
17. Quick Practice
Sketch a full agent instruction set (goal, tools, rules, stop conditions) for a simple “meeting scheduler” agent. What’s the one rule you’d consider most safety-critical, and why?
18. Next Step
Next: Module 20 — Prompt Evaluation — Level 5 begins here: why a prompt that works once isn’t necessarily a good prompt, and how to actually test prompt reliability systematically.
- Author
- TechByteByByte Editorial Team
- Reviewed by
- TechByteByByte Admin
- Published
- Last reviewed