Prompt Patterns for AI Agents: Tool Calling, Planning, and Error Handling

Building autonomous AI agents requires a completely different approach than traditional system prompts for static chatbots. Where a standard LLM primarily responds to a single input, an agent must reason iteratively, call external tools, interpret results, and decide when a task is completed. Without tight prompt patterns, an agent quickly derails into infinite loops, makes suboptimal tool choices, or gets stuck at the very first error.

In this article, we cover the most important patterns to make agents function reliably. We base these on proven techniques from the practice of prompt engineering and agent architecture.

1. Describing Tools: Clarity Above All

An agent is only as smart as the tools it has at its disposal and the way these tools are presented to it. Many developers underestimate the importance of semantic precision in tool definitions. If a model does not understand exactly what a tool does, when it should be used, and what the expected input is, the agent will exhibit unpredictable behavior.

When designing tool descriptions in your prompt or schemas, you should pay attention to:

• Function name and domain: Use action-oriented names like search_customer_database instead of vague names like tool_1 or db_query.
• Explicit constraints: Indicate in the description when you should and explicitly should not use the tool.
• Typing and formats: Define field types strictly. Always specify the expected format for dates (e.g., YYYY-MM-DD).

For broader concepts on how to guide models in complex workflows, you can also consult our guide on prompt techniques.

# Example of a robust tool description within a system prompt
TOOLS:
1. `calculate_shipping_costs`: 
   - Description: Calculates shipping costs based on weight and destination. Use this ONLY after the weight is known via the order API.
   - Arguments: 
     - weight_kg (float): The weight in kilograms.
     - country_code (string): ISO 3166-1 alpha-2 country code (e.g., 'NL', 'BE').
   - Warning: Do not use this tool for international shipments outside the EU.

2. Separating Planning and Execution

A common mistake in agent prompts is asking for immediate action without prior reflection. The model then tries to plan and execute simultaneously, resulting in chaotic behavior as soon as a step fails.

The ReAct (Reason + Act) pattern or explicit planning forces the agent to first draw up a step-by-step plan in a separate thinking block before proceeding to a tool call. This closely aligns with advanced methods such as prompt chaining.

Always use the following structure in your response throughout the process:
[PLAN]: What is your next logical step and why?
[ACTION]: Which tool do you call with which parameters? (Leave blank if you provide a direct answer)
[REASONING]: Brief motivation for the choice.

Do not deviate from this. If you have all the information, skip [ACTION] and provide the final answer directly.

3. Returning Error Handling to the Model

When a tool returns an error message (for example, a 404 Not Found or an invalid API parameter), poorly configured agents often stop abruptly or panic. A robust agent should not view an error message as an end point, but as new input to adjust its strategy.

Explicitly instruct the agent in the system prompt on how to handle exceptions:

ERROR HANDLING:
Do you receive an error message from a tool? Then perform the following steps:
1. Analyze the error message in your [PLAN] section.
2. Determine if the error was caused by an incorrect parameter (e.g., typo in country code).
3. Correct the parameter and try to call the tool again a maximum of 1 time.
4. Does the error persist? Then fall back on an alternative tool or ask the user for clarification. Never return a raw stack trace to the end user.

4. Limiting Steps and Explicit Stop Conditions

LLMs tend to keep going as long as they think there is still room for improvement. Without strict limits, this leads to infinite loops where the agent keeps calling the same tool with minimal variations in parameters. This costs unnecessary tokens and time.

You can counter this by building in two mechanisms:

• Hard limit on steps: Specify in the prompt the maximum number of iterations allowed (e.g., "You may make a maximum of 5 tool calls for this task").
• Explicit stop conditions: Define crystal clear when the goal has been achieved.

STOP CONDITIONS:
You stop calling tools immediately as soon as:
- You have found the final answer that directly answers the user's question.
- You have reached the maximum limit of 5 steps. In that case, display the best attempt so far with a warning that the process has been aborted.
- A tool gives the same error message twice in a row.

5. Why Less Autonomy Often Performs Better

There is a persistent misconception that an agent is better the more freedom it is given. In practice, we often see the opposite: over-autonomized agents perform worse. If you give a model too many tools and too vague goals ("Just solve this problem"), the model becomes paralyzed by choice overload or hallucinates irrelevant workflows.

The principle of minimum necessary autonomy means keeping an agent's scope of action as small as possible:

• Only provide access to the tools that are absolutely necessary for the specific subtask.
• Use predictable paths where possible, and only deploy agents for dynamic branching.
• Limit the complexity of the prompt by breaking tasks down into smaller, sequential chains.

For in-depth background on structuring complex information flows, we also recommend reading about RAG for beginners, where filtering irrelevant context goes hand in hand with effectively guiding language models.

Summary

Building production-ready agents requires discipline in prompt design. By describing tools extremely specifically, separating planning and execution, capturing errors as feedback, and setting hard limits on the number of steps, you transform an erratic language model into a predictable, powerful software component.