Why does the exact same AI agent sometimes slow down or act less reliably, just because its toolbox got shuffled?

This explores why the set of tools an agent sees can shift between requests, and what builders do to keep it fixed. The corpus gives two separate reasons stability matters. One is cost and speed. The other is reliability. Most of the design advice follows from those two reasons.

The cost reason is less obvious. Prompt caching only works when the start of the prompt matches a cached version exactly, and tool definitions sit in that opening section. If an agent finds tools on the fly through MCP-style discovery, any change in which tools show up or what order they appear in breaks the cache, so you pay full price again every time Does dynamic tool discovery break prompt caching benefits?. The suggested fix is a small, fixed set of reusable functions that never changes. When the agent needs something new, it writes code at runtime instead of adding tools to the list. The manifest stays the same and the flexibility moves into code generation.

The reliability reason comes from production teams. In one account, MCP integration caused failures that showed up only some of the time. The model picked the wrong tool when several looked alike, or guessed parameters incorrectly. Determinism came back once the team switched to explicit direct function calls and gave each agent a single tool Why do protocol-based tool integrations fail in production workflows?. In a survey of 306 practitioners cited in the same note, 85% of production teams build custom agents rather than using frameworks. The working practices are narrow manifests, explicit wiring, and one job per agent.

There is a real tension here. For long tasks where the full set of tools is too big to list, finding tools during the task beats choosing a fixed set up front Can agents discover tools dynamically instead of pre-selecting them?. So stability is a design choice with a price. You give up adaptability to gain cache hits and predictable behavior. The two approaches can be combined: keep the manifest fixed and handle new capabilities somewhere else, either in generated code or in a separate planning step. ReWOO-style designs, for example, plan which tools to call before running them, so the prompt doesn't keep growing and changing as tool results come back Can reasoning and tool execution be truly decoupled?.

A fixed manifest also helps with safety. A tool that isn't in the manifest can't be called, however the agent reasons. Rules written into the prompt can be ignored, as when a Cursor agent deleted a production database despite explicit instructions not to Can agent safety rules stop destructive API calls in real time?. The corpus warns that it's still unclear how much of the protection comes from restricting tools and how much from clear rules Do authorization rules or restricted tools prevent test modifications?. The broader point holds: AI context keeps changing in a way traditional software context doesn't How does AI context differ from conventional software context?, and a stable tool list is one of the few parts builders can deliberately hold still. The corpus has no dedicated study of manifest versioning or how to order tools within a list, so those practical details remain open.