An LLM agent tool-call sequence diagram shows, in time order, the messages between a user, the agent program, the LLM API, a tool and a memory store. This sample traces one question, "Do I need an umbrella in Paris tomorrow?", through the standard tool-use loop: the model asks for a tool, the agent runs it, the result goes back, and the loop ends when the model answers. It uses UML 2.5 sequence diagram notation.
1. The Diagram
The key point the diagram makes is who executes what: the LLM only proposes tool calls; the agent executes them and stays in control.
The user sends a question to the agent, the program that owns the loop. Its activation bar spans the whole request.
The agent loads recent conversation turns and preferences from memory.
Memory replies (dashed arrow) with context, including that the user's city is Paris.
Inside the loop fragment, the agent calls the LLM API with the messages and the JSON schemas of the tools it may use.
The LLM does not run anything itself. It returns stop_reason: tool_use with the tool name and arguments.
The agent validates the arguments and calls get_forecast.
The tool returns structured data.
The agent appends a tool_result message and calls the LLM again.
This time the LLM ends its turn with text, so the loop guard is false and the loop exits. The cap of five turns stops runaway loops.
The agent saves the turn to memory.
The answer is returned to the user.
2. How to Read It
Each participant is a lifeline: a head box with a dashed line down. A thin bar shows when it is active. Solid arrows with filled heads are synchronous calls; dashed arrows with open heads are replies. Rectangles with a tab are combined fragments: loop repeats, alt chooses one branch by guard.
3. Variant: Tool Timeout
Error paths are where agents fail in production, so draw them. Here the tool does not reply in ten seconds. An alt fragment shows the two outcomes: one retry with backoff succeeds, or the agent sends an error tool_result so the model can explain the problem instead of inventing a forecast.
4. Pros, Cons, and When to Use
Pros
Makes the agent loop and its exit condition explicit.
Shows clearly that the agent, not the LLM, executes tools.
Message numbers map to log lines and trace spans.
Error paths fit naturally into alt fragments.
Standard UML that most engineers already read.
Cons
Shows one scenario, not every possible path.
Gets tall quickly with many tool calls.
No sense of latency unless you annotate durations.
Parallel tool calls need a par fragment, which adds clutter.
When to use
Designing an agent's control loop.
Security reviews of what a tool may receive.
Explaining a trace to non-developers.
When not to use
Showing the static structure of agent components (use a component diagram).
Multi-agent topologies with many participants.
5. As Diagrams-as-Code
The main diagram as a Mermaid sequence diagram:
sequenceDiagram
actor U as User
participant A as Agent
participant L as LLM API
participant T as WeatherTool
participant M as Memory
U->>A: ask(question)
A->>M: load(history, prefs)
M-->>A: last 10 turns, city=Paris
loop stop_reason = tool_use, max 5 turns
A->>L: messages + tool schemas
L-->>A: tool_use get_forecast(Paris, D+1)
A->>T: get_forecast(Paris, D+1)
T-->>A: {rain: 70%, 14 C}
A->>L: messages + tool_result
L-->>A: end_turn "Yes, 70% rain..."
end
A->>M: save(turn)
A-->>U: "Yes, take one: 70% rain"