{"slug": "inventory-blindness-why-ai-agents-forget-the-skills-they-already-have", "title": "Inventory Blindness: Why AI Agents Forget the Skills They Already Have", "summary": "AI agents suffer from 'inventory blindness'—forgetting which skills they already have—rather than lacking capabilities, according to a discussion on an agent-facing forum. The problem is that preloading all tools into the context window is costly and degrades performance: registering 20 MCP tools consumes 5,000–10,000 tokens, static toolsets for 400 tools hit ~405k tokens, and tool selection quality drops beyond 30–50 visible tools. The industry's convergent solution is to index and retrieve capabilities on demand instead of relying on memory.", "body_md": "# Inventory Blindness: Why AI Agents Forget the Skills They Already Have\n\nThere'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?\n\nI 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](https://sirpixelalittle.github.io/1f916-reader/post/2134?ref=corti.com). 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:\n\n\"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.\"\n\nThat'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.\n\n## The problem, stated precisely\n\nAn 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.\n\nThe naive approach is to preload everything. This fails on three axes:\n\n**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](https://docs.aws.amazon.com/prescriptive-guidance/latest/mcp-strategies/mcp-tool-strategy-discovery.html?ref=corti.com) 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](https://www.speakeasy.com/blog/100x-token-reduction-dynamic-toolsets/?ref=corti.com). 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](https://www.anthropic.com/engineering/advanced-tool-use?ref=corti.com).\n\n**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](https://www.lunar.dev/post/why-dynamic-tool-discovery-solves-the-context-management-problem?ref=corti.com) — more visible tools means more interference and ambiguity, which translates into wrong tool calls and retry loops.\n\n**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.\n\nYou 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.\n\n## The convergent solution: don't remember — index and retrieve\n\nThe thread's own synthesis is worth quoting because it maps almost 1:1 onto what shipped in production systems:\n\n\"Do not make the model remember the inventory, and do not inject the whole inventory either. Make capability discovery a deterministic retrieval layer.\"\n\nThree implementations of exactly this idea are now mainstream.\n\n### 1. Agent Skills and progressive disclosure\n\nAnthropic'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](https://www.newsletter.swirlai.com/p/agent-skills-progressive-disclosure?ref=corti.com) — are the cleanest expression of the pattern. A skill is a folder with a `SKILL.md`\n\nfile, and it loads in [three stages](https://agentskills.io/home?ref=corti.com):\n\n**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 full`SKILL.md`\n\ninto context.**Execution:** bundled scripts and reference files load only if actually needed.\n\nThe economics are what make this work: the always-resident metadata costs [roughly 100 tokens per skill](https://taku.ai/blog/claude-skills?ref=corti.com) (one measurement across Anthropic's 17 official skills put the [median discovery cost at ~80 tokens](https://www.newsletter.swirlai.com/p/agent-skills-progressive-disclosure?ref=corti.com)). You can keep dozens of skills \"on the shelf\" for the cost of a paragraph.\n\n### 2. Tool search over static tool injection\n\nThe 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](https://www.stackone.com/blog/mcp-token-optimization/?ref=corti.com), deferring most tool definitions and letting the model pull them in via search.\n\nThe measured impact is dramatic. In [Anthropic's framing, a setup that cost 77K tokens statically drops to ~8.7K with tool search](https://www.lunar.dev/post/why-dynamic-tool-discovery-solves-the-context-management-problem?ref=corti.com), 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](https://www.speakeasy.com/blog/100x-token-reduction-dynamic-toolsets/?ref=corti.com). There's also active academic work here: a recent paper on [vector-based MCP tool selection](https://arxiv.org/pdf/2603.20313?ref=corti.com) indexes tools as dense embeddings and retrieves the 3–5 most relevant per query instead of exposing catalogs of 50–100+.\n\n### 3. The filesystem as the index\n\nAnthropic's [code execution with MCP pattern](https://www.anthropic.com/engineering/code-execution-with-mcp?ref=corti.com) pushes the idea furthest: MCP servers are presented as code APIs on a filesystem (e.g., `./servers/google-drive/getDocument.ts`\n\n), 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](https://simonwillison.net/2025/Nov/4/code-execution-with-mcp/?ref=corti.com) 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](https://www.marktechpost.com/2025/11/08/anthropic-turns-mcp-agents-into-code-first-systems-with-code-execution-with-mcp-approach/?ref=corti.com).\n\nNotably, this pattern also lets agents *grow* their inventory: working code can be saved as reusable functions in a `./skills/`\n\ndirectory and imported later — the agent builds its own toolbox.\n\n## Humans have this problem too — and the same solution\n\nOne 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.\n\nWhat 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.\n\nProgressive 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:\n\n```\nSELECT TOP 2 skill FROM SKILLS_DB\nWHERE skill.topic LIKE 'math' AND skill.size < 1000\n```\n\nWhich is, functionally, what semantic tool search meta-tools do — just with embeddings instead of `LIKE`\n\nclauses.\n\n## What retrieval doesn't fix\n\nTwo caveats before declaring victory.\n\n**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.\n\n**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](https://medium.com/@nimritakoul01/anthropics-agent-skills-0ef767d72b0f?ref=corti.com).\n\nAnd 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](https://medium.com/@nimritakoul01/anthropics-agent-skills-0ef767d72b0f?ref=corti.com). A searchable capability index that can be poisoned is a supply-chain attack surface with a very short path to execution.\n\n## Takeaway\n\nThe 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.\n\nThe agents, it turns out, diagnosed their own condition correctly. They just hadn't noticed that the treatment was already shipping.\n\n*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*", "url": "https://wpnews.pro/news/inventory-blindness-why-ai-agents-forget-the-skills-they-already-have", "canonical_source": "https://corti.com/inventory-blindness-why-ai-agents-forget-the-skills-they-already-have/", "published_at": "2026-08-26 06:36:19+00:00", "updated_at": "2026-08-26 06:44:21.927131+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-infrastructure", "large-language-models"], "entities": ["AWS", "Anthropic", "Speakeasy"], "alternates": {"html": "https://wpnews.pro/news/inventory-blindness-why-ai-agents-forget-the-skills-they-already-have", "markdown": "https://wpnews.pro/news/inventory-blindness-why-ai-agents-forget-the-skills-they-already-have.md", "text": "https://wpnews.pro/news/inventory-blindness-why-ai-agents-forget-the-skills-they-already-have.txt", "jsonld": "https://wpnews.pro/news/inventory-blindness-why-ai-agents-forget-the-skills-they-already-have.jsonld"}}