The most surprising thing about prompt engineering for agents is that the "prompt" isn’t just a static string of text; it’s a dynamic, multi-turn conversation where the agent’s ability to act is paramount.
Let’s see this in action. Imagine an agent designed to manage a user’s calendar. We want it to be able to add events, but also to ask clarifying questions if it doesn’t have enough information.
Here’s a simplified tool definition an agent might use:
{
"name": "add_calendar_event",
"description": "Adds an event to the user's calendar. Requires 'title', 'start_time', and 'end_time'. 'location' is optional.",
"parameters": {
"type": "object",
"properties": {
"title": {"type": "string", "description": "The title or subject of the event."},
"start_time": {"type": "string", "description": "The start date and time of the event in ISO 8601 format (e.g., '2023-10-27T10:00:00Z')."},
"end_time": {"type": "string", "description": "The end date and time of the event in ISO 8601 format (e.g., '2023-10-27T11:00:00Z')."},
"location": {"type": "string", "description": "The physical location of the event (optional)."}
},
"required": ["title", "start_time", "end_time"]
}
}
Now, consider a user request: "Schedule a meeting with Sarah tomorrow at 3 PM."
The agent, upon receiving this, doesn’t just try to call add_calendar_event. It recognizes that end_time is missing. Instead of failing or guessing, it generates a response that includes a tool call.
User: Schedule a meeting with Sarah tomorrow at 3 PM.
Agent’s Internal Thought Process (Simplified):
- User wants to schedule a meeting.
- The
add_calendar_eventtool seems appropriate. - Required parameters:
title,start_time,end_time. - From the user’s prompt:
title: "Meeting with Sarah" (inferred)start_time: "tomorrow at 3 PM" (needs to be resolved to ISO 8601, e.g.,2023-10-27T15:00:00Zif today is 2023-10-26)
- Missing parameter:
end_time. - Action: Ask for clarification.
Agent’s Output:
{
"tool_calls": [
{
"id": "call_abc123",
"type": "function",
"function": {
"name": "add_calendar_event",
"arguments": "{\"title\": \"Meeting with Sarah\", \"start_time\": \"2023-10-27T15:00:00Z\"}"
}
}
],
"thought": "I need to know when the meeting with Sarah should end. I have the title and start time.",
"response": "What time should the meeting with Sarah end tomorrow?"
}
Notice how the tool_calls field includes the partial call, and the response field is a natural language question. The agent is simultaneously preparing to act and asking for more information.
The user then replies: "Make it last an hour."
User: Make it last an hour.
Agent’s Internal Thought Process (Simplified):
- User’s previous request was about the "Meeting with Sarah" at
2023-10-27T15:00:00Z. - The current request "Make it last an hour" refers to the duration of that meeting.
- The
add_calendar_eventtool requiresend_time. - Calculate
end_time:2023-10-27T15:00:00Z+ 1 hour =2023-10-27T16:00:00Z. - Now all required parameters are available.
- Action: Call the tool with all parameters.
Agent’s Output:
{
"tool_calls": [
{
"id": "call_def456",
"type": "function",
"function": {
"name": "add_calendar_event",
"arguments": "{\"title\": \"Meeting with Sarah\", \"start_time\": \"2023-10-27T15:00:00Z\", \"end_time\": \"2023-10-27T16:00:00Z\"}"
}
}
],
"thought": "I have all the necessary information to schedule the meeting. The user wants the meeting to last one hour, so the end time is one hour after the start time.",
"response": "Okay, I've scheduled 'Meeting with Sarah' for tomorrow from 3:00 PM to 4:00 PM."
}
This multi-turn interaction, where the agent uses tool definitions to guide its understanding and generation of both questions and tool calls, is the core of agentic prompting. The "prompt" evolves with each turn, becoming a collaborative problem-solving session.
The crucial element here is how the agent’s prompt to the LLM includes not just the user’s latest message but also the history of the conversation and the available tools. The LLM’s task is to decide: should I ask a clarifying question, call a tool, or respond directly? The structure of the tool definition (especially description and required fields) is what enables the LLM to make these decisions intelligently.
The true power emerges when you chain these actions. An agent might first use a search_web tool to find information, then use an analyze_text tool on the search results, and finally use add_calendar_event to schedule a follow-up based on the analysis. Each step feeds into the next, guided by the LLM’s ability to interpret the results of previous actions and the definitions of subsequent tools.
What many overlook is the subtle interplay between the description of a tool and the LLM’s ability to infer intent. If your add_calendar_event description was simply "Adds an event," the agent would struggle to know what parameters are needed. But by adding "Requires 'title', 'start_time', and 'end_time'," you’re explicitly guiding the LLM’s reasoning about missing information. The LLM isn’t just matching keywords; it’s performing a quasi-logical deduction based on the tool’s contract.
The next step is handling complex dependencies between tool calls and managing asynchronous operations.