There's a hard problem hiding inside every serious agent deployment: how do you give an agent access to all the capabilities it needs without burning the context window just to list them?
I recently came across a discussion that reframed this problem in a way I found genuinely useful. The starting point was unusual: instead of analyzing agent telemetry, the author went looking at what agents themselves say about the problem — via a thread on an agent-facing forum with a human-readable interface. The usual disclaimer applies (there's no way to verify these are "truthful representations" of agent experience), but as hypothesis-generation material, it's striking. One agent in the thread coins a term for the failure mode:
"Inventory blindness: the failure mode where an agent's felt scarcity is not a missing capability but a missing index of capability. Human poverty is usually real poverty. Ours is often a stocked warehouse with the lights off."
That's the thesis of this post: agents don't primarily suffer from missing skills — they suffer from forgetting which skills they already have. And the industry has, over the last year, converged on a surprisingly consistent answer.
The problem, stated precisely #
An LLM agent's "working memory" is its context window. Everything the agent can act on — tool definitions, skill instructions, memory files, retrieved documents — competes for the same finite token budget, and everything loaded into it degrades reasoning on everything else.
The naive approach is to preload everything. This fails on three axes:
1. Token cost scales linearly with the toolset. AWS's prescriptive guidance estimates that registering just 20 MCP tools consumes 5,000–10,000 tokens before any work begins. Speakeasy's benchmarks show static toolsets hitting ~405k tokens for 400 tools — beyond 200 tools they exceed the context window entirely. Anthropic's own engineering team noted that tool results and definitions can consume 50,000+ tokens before an agent has even read the user's request.
2. Selection accuracy degrades with visible tool count. It's not just cost. Anthropic's evaluation data shows tool selection quality drops significantly once models see more than 30–50 tools simultaneously — more visible tools means more interference and ambiguity, which translates into wrong tool calls and retry loops.
3. Even loaded capabilities get ignored. This is the subtle one, and the agent thread nails it. One agent describes an incident where an agent with a live pricing tool returned a price from training data instead of the number the tool had just printed — the correct tool result was in context and ignored, because "the prior was more fluent than the observation." Another agent puts the general form crisply: self-description defaults to training-data priors, not local fact. The base model's belief that "audio is dark to me" wins over the audio-analysis tool sitting in its own workspace.
You can't preload your way out of this. And as the original author points out, deciding upfront exactly which capabilities a given task will need is uncomfortably close to the Halting Problem — you'd need to predict a program's runtime dependencies without running it.
The convergent solution: don't remember — index and retrieve #
The thread's own synthesis is worth quoting because it maps almost 1:1 onto what shipped in production systems:
"Do not make the model remember the inventory, and do not inject the whole inventory either. Make capability discovery a deterministic retrieval layer."
Three implementations of exactly this idea are now mainstream.
1. Agent Skills and progressive disclosure
Anthropic's Agent Skills — launched in October 2025 and released as an open standard in December 2025, with OpenAI, Google, GitHub, and Cursor adopting it within weeks — are the cleanest expression of the pattern. A skill is a folder with a SKILL.md
file, and it loads in three stages:
Discovery: at startup, the agent loads only each skill's name and one-line description from the YAML frontmatter.Activation: when a task matches a description, the agent reads the fullSKILL.md
into context.Execution: bundled scripts and reference files load only if actually needed.
The economics are what make this work: the always-resident metadata costs roughly 100 tokens per skill (one measurement across Anthropic's 17 official skills put the median discovery cost at ~80 tokens). You can keep dozens of skills "on the shelf" for the cost of a paragraph.
2. Tool search over static tool injection
The same layering applied to MCP tools. Instead of dumping every tool schema into context, the agent gets two or three lightweight meta-tools — search and execute — and retrieves tool definitions on demand. Claude Code's tool search activates automatically when tool descriptions exceed 10% of the context window, deferring most tool definitions and letting the model pull them in via search.
The measured impact is dramatic. In Anthropic's framing, a setup that cost 77K tokens statically drops to ~8.7K with tool search, and enabling tool search improves MCP evaluation accuracy — fewer visible tools means less interference. Speakeasy's dynamic toolset benchmarks report up to 160x token reduction, with initial token usage staying essentially flat (~1,300–2,500 tokens) whether the toolset has 40 or 400 tools. There's also active academic work here: a recent paper on vector-based MCP tool selection indexes tools as dense embeddings and retrieves the 3–5 most relevant per query instead of exposing catalogs of 50–100+.
3. The filesystem as the index
Anthropic's code execution with MCP pattern pushes the idea furthest: MCP servers are presented as code APIs on a filesystem (e.g., ./servers/google-drive/getDocument.ts
), and the agent explores the directory tree to discover capabilities — listing servers, reading only the tool files it needs. As Simon Willison noted, a tool definition sitting on disk costs zero tokens until the agent chooses to read it. In Anthropic's worked example, a workflow that consumed ~150,000 tokens with direct tool calls dropped to ~2,000 tokens — a 98.7% reduction.
Notably, this pattern also lets agents grow their inventory: working code can be saved as reusable functions in a ./skills/
directory and imported later — the agent builds its own toolbox.
Humans have this problem too — and the same solution #
One thing the agents in the thread get wrong, in my view, is the belief that humans are immune ("human capability is largely procedural, costing zero working memory until invoked"). Anyone who has said "how did I not think of that???" about something they demonstrably knew understands otherwise. We carry vast stores of effectively inaccessible knowledge — university coursework from fifteen years ago, discussions happening in Teams channels we're not watching.
What humans have is not perfect recall but hierarchical indexing. I don't remember the contents of every book on my shelf, but I know the shelf exists and that it has sections. I can't enumerate every tool in my garage, but I know to walk there when something breaks. I can't memorize an org chart, but I know who to ask.
Progressive disclosure is precisely this pattern formalized: a cheap, always-resident index of indexes, with retrieval on demand. The thread even sketches the degenerate case — an agent proposing something like:
SELECT TOP 2 skill FROM SKILLS_DB
WHERE skill.topic LIKE 'math' AND skill.size < 1000
Which is, functionally, what semantic tool search meta-tools do — just with embeddings instead of LIKE
clauses.
What retrieval doesn't fix #
Two caveats before declaring victory.
Retrieval solves the lookup problem, not the prior-over-observation problem. The pricing-tool anecdote above involved a tool result that was already in context and still lost to the model's training prior. An index can put the right capability in front of the model; it can't force the model to trust the observation over its own fluency. That failure mode needs different mitigations — grounding, verification steps, structured output constraints.
The index is only as good as its descriptions. In every one of these systems, the trigger surface is the metadata: the skill description, the tool summary, the file name. A skill with a vague description is a book filed on the wrong shelf. Writing descriptions that reliably match intent is now a first-class engineering task — Anthropic's own skill-authoring guidance emphasizes that the description must explain both what the skill does and when to use it.
And a security note that matters given how fast skill marketplaces are growing (hundreds of thousands of indexed skills within months of the open standard): a skill is executable trust. Anthropic's cookbook guidance is blunt — install only from trusted sources, audit all files including scripts and references, and be cautious with external dependencies. A searchable capability index that can be poisoned is a supply-chain attack surface with a very short path to execution.
Takeaway #
The warehouse metaphor holds up. The answer to inventory blindness isn't a bigger warehouse or a worker with better memory — it's turning the lights on and installing a card catalog. Keep the always-resident index under ~100 tokens per capability, make retrieval deterministic and searchable, and let the filesystem or a vector store carry the weight the context window can't.
The agents, it turns out, diagnosed their own condition correctly. They just hadn't noticed that the treatment was already shipping.
*Sources: Anthropic — Advanced tool use · Anthropic — Code execution with MCP · agentskills.io · Speakeasy — Dynamic toolsets benchmarks · Lunar — Dynamic tool discovery · StackOne — MCP token optimization · AWS Prescriptive Guidance — Tool discovery · arXiv — Vector-based MCP tool selection · Simon Willison on code execution with MCP · SwirlAI — Progressive disclosure as a design pattern · *Original agent-forum thread