What happens between your prompt and a tool call

From the outside, an agent using a tool looks like a single event: you ask, something happens, you get an answer. Inside one turn there are four distinct phases, three of them made entirely of text, and only one of them involves the network.

Knowing the order is worth more than it sounds. Almost every complaint about agents — it is slow, it forgot, it called the wrong thing, it costs more than it should — lands on exactly one of these phases, and they have completely different fixes.

1 · Everything already in the window

Before your sentence there is a system prompt, whatever the client adds to it, whatever earlier turns left behind, and any skills that matched. None of it is free and none of it is visible in the interface. This is the part that grows quietly across a long session.

It is also the part people try to fix last, because nothing about it errors. A session with a heavy preamble does not fail — it just gets slightly worse at everything, in a way that reads as the model being unreliable rather than as a budget being spent.

2 · The tool list, in full, every turn

This is the phase that surprises people. The model does not remember your tools from the last turn. On every turn the client sends the list again: every name, every description, every argument schema, as text, into the same window the work has to happen in.

• A fifty-tool server is expensive before anybody calls anything. Its surface is in the window on every turn of every session it is installed in.
• Verbose descriptions are a recurring cost, not a one-off. The paragraph you wrote to be helpful is re-read every time.
• This is the honest argument for narrow servers — narrower than the security argument, and it applies even to tools that only read.

The practical consequence: if an agent is behaving worse in hour two than in hour one, look at what is being re-sent before you look at the model.

3 · The model decides, on the evidence in front of it

The choice of tool is made from names, descriptions and schemas — text supplied by whoever wrote the server. The model has no other way of knowing what a tool does. It cannot inspect the implementation, it cannot try one safely, and it will not ask unless something told it to.

Every tool description is an instruction to a system that follows instructions. That is not a flaw in the model; it is the interface working.

Which is why a vague description is not a documentation problem. It is a behaviour problem, and it shows up as unpredictability at the far end of a long chain of reasonable-looking steps.

4 · The result comes back, and it stays

The answer is not consumed. It becomes part of the conversation — which means a tool that returns a thousand lines of JSON has spent a thousand lines of your window, permanently, for a question whose answer was one field.

Servers that let you ask for a projection — fields, a page size, a summary — are worth more than their feature list suggests, and it is a fair thing to check for before installing one.

Where the usual complaints actually land

None of this is exotic and none of it requires a different model. It requires knowing which of the four phases you are actually unhappy with — and three of the four are things a publisher, not a model provider, decides.