Tool calls are not function calls

Step through the same 3-call task in both models. The stack on the left pushes and pops; the transcript on the right only grows:

There's a line of code in every agentic app, and it looks like this:

const summary = await callTool("summarise", { text });

It reads like a function call. await gives it the same shape as a remote RPC. The variable summary holds a value. The stack frame around it holds locals. Control resumes where it left off. The mental model that comes with this syntax is a function call, and that mental model is wrong.

An LLM tool call is a transcript entry. No stack, no implicit locals, no place for the model to "resume from". Every turn is a fresh pass over the entire conversation. The model re-reads prior assistant turns, prior tool_result blocks, and prior user messages to figure out where it is. Miss that, and you ship agents that work fine under light load and collapse under long horizons.

This post reads the primary-source contract — Anthropic's tool-use documentation — and shows side-by-side what a classical function call preserves for you that a tool call does not.

The contract, restated

Anthropic's description of the agentic loop is unambiguous about where state lives:

Read step 4 twice. The new request contains the original messages. Not a continuation. Not a suspended thread. A fresh call, with the conversation so far re-materialised as input. The model on the other side doesn't "wake up where it stopped". It's re-run, from scratch, against a longer transcript.

The same page makes the statelessness explicit in description of server tools:

"Re-send the conversation." That sentence only makes sense if the state needed to continue the loop lives in the conversation, not around it. The API cannot keep an open process for you. The only way to let the model continue is to hand it back everything it has so far.

What a function call actually gives you

Compare that to a classical function. The runtime gives you, for free, a long list of invariants:

• A stack frame is allocated on call and deallocated on return. Its locals are addressable by name while the call is live.
• The return address is saved; the callee cannot forget to come back.
• Nested calls push new frames; the caller's locals are protected while the callee runs.
• Types are checked at the boundary; a number going in is a number coming out.
• Concurrency inside a function does not corrupt the caller's locals, because the caller's frame is untouched on the stack.

None of those invariants exist in a tool-call loop. You, the application developer, are the runtime. For the model to remember a value across turns, that value has to appear in the transcript — typically inside an assistant turn's text, a tool_use.input, or a tool_result.content. There's no other channel.

Back to the side-by-side

Advance the steps in the visualiser at the top. On the left: classical orchestrate() → fetchUser() → renderReport(). Frames push and pop; locals survive because the stack holds them. On the right: the equivalent LLM loop. Transcript grows monotonically; every new turn has to re-read the whole thing to know what came before.

Two things become visible after a few steps:

• The classical stack shrinks — fetchUser returns, its frame is popped, its locals destroyed. Anything orchestrate needed from it had to be returned explicitly.
• The LLM transcript only grows — there is no "pop". Every prior turn is potentially useful to the next assistant turn, so it all stays, until something outside the model (compaction, truncation, context-window overflow) evicts it.

Those are opposite state models. Tool-calling apps that treat the API like the left pane will debug symptoms like "the agent forgot which file it was editing" forever, because the bug isn't in the agent's reasoning — it's in the assumption that result = call_tool(...) keeps a latent variable somewhere the model can see.

The three failure modes this explains

Once you internalise the transcript model, several whole classes of agent bug compress into one-liners:

1. Compaction amnesia. Many agent frameworks compact or summarise old turns when the context window fills up. If a critical tool_result from turn 4 is summarised down to a single sentence by turn 40, the agent can no longer re-derive the specific fact — a file path, a foreign key, a transaction id — that lived in the raw result. The "agent forgot" isn't a reasoning failure; it's a transcript failure.

Toggle between the full transcript and the compacted one to see which details the model loses:

2. Tool result shape drift. A function's return type is stable across calls. A tool's result text is not. If your fetch_user tool returns JSON one turn and a pretty-printed summary the next, the model has to re-parse both — and may succeed at one and fail at the other, silently. A tool schema is not a function signature. Tool outputs are prose the next turn must reinterpret.

3. "Nested" tool calls aren't nested. If your render_report tool internally calls fetch_user, the parent model does not see that inner call. Its transcript only contains the outer tool_use/tool_result pair. Any state the inner call discovered that the outer tool discarded is lost to the parent. There is no call stack to inspect.

The cure for all three: treat the transcript as the only persistence layer. If a fact must survive to a later turn, it must land in a message the model will read on that turn. No framework magic replaces this.

Writing for the ABI

Once you accept the mismatch, the design guidance writes itself:

• Keep tool outputs small and explicitly named. {"user_id": 42, "plan": "pro"} survives re-reads; a 2,000-token JSON blob gets truncated or summarised, and anything relied-upon downstream vanishes.
• Include the plan in the assistant's text, not just in the tool sequence. The model re-reads its own prior turns. An assistant turn that says "I'll do A, then B, then C" is as load-bearing as the tools themselves.
• Don't treat pause_turn as a signal to "resume". Re-send the whole conversation — the response you got is part of it. That's all the resumption primitive you have.
• Don't assume parallel tool calls are independent. They're sent to a single model that must synthesise all their results on the next turn. If two tools return contradicting snapshots of external state, the model doesn't hold a mutex for you.
• Prefer prompts that reference prior turns by content, not by position. "The file you read two turns ago" works if the file is distinctive; "the previous tool's output" degrades to vibes.

The prize for getting this right is an agent that survives long horizons — 30+ tool calls, 50+ turns — without collapsing into "what was I doing?" The prize for missing it is a demo that ships, wows an exec, and falls over in the first real workload.

Primary sources

• Anthropic — Tool use with Claude (overview) — the stop_reason: "tool_use" signal and the tool_result block structure.
• Anthropic — How tool use works — the canonical agentic loop ("send a new request containing the original messages, the assistant's response, and a user message with the tool_result blocks").
• Anthropic — Handle tool calls — the mechanics of building tool_result blocks and formatting parallel tool calls.