Every time your LLM agent calls a tool and reads the result, you're paying a tax. Not in dollars — in tokens, latency, and reliability (ok, dollars then). The tool's output gets serialized into text, tokenized into the context window, attended to by the model, and then re-serialized when the model decides what to do next. If the next step is another tool call, the cycle repeats. Data that never needed the model's judgement flows through the most expensive component in your system — twice.
This isn't a minor inefficiency. It's the hidden cost centre of every agent framework, and it compounds: the more tools your agent uses, the more context it burns on data shuttling, the less reliable it becomes at the actual task, and the less you can observe about what went wrong when it fails.
I spent too long watching this happen in my own agent before I decided this was an old problem in new clothes, and it needed fixing. The agent wasn't broken. The architecture was. I was asking a stateless function to behave like a state machine, and paying the token tax every time the illusion slipped.
What kind of machine is this, actually
The instinctive way to think about a large language model is as a slow, occasionally unreliable processor. Give it better prompts the way you'd give a CPU better-optimized code, give it more context the way you'd give it more RAM, wait for the next model generation the way you'd wait for a clock-speed bump, and the rough edges — the forgetfulness, the drifting attention, the tendency to lose the plot four tool calls into a procedure — will sand themselves down.
