Tool Rot Paradox: Why installing 50+ agent skills in development breaks down in production

When you start building non trivial agent workflows, the instinct is to treat tools and skills like npm packages: if the agent needs to do something new, you install a new skill, write a wrapper, update the prompt/schema, and expose it to the context window. After building and maintaining agent stacks for a while, this pattern hits a hard wall. Tool bloat rots your context window Exposing dozens of tool schemas simultaneously degrades instruction_following performance. The model starts picking slightly wrong tools, misinterpreting JSON schemas, or getting confused when two skills have overlapping boundaries. The Maintenance & Security Debt Every static skill installed directly into an agent's runtime becomes immediate tech debt: Outdated API schemas break silently mid_execution. Unvetting third_party community skills introduces severe prompt injection and data-exfiltration attack vectors. Updating skill logic requires touching local codebases and re_deploying the harness. The Shift: Dynamic Discovery over Static Installation Instead of hardcoding a massive library of capabilities directly into the agent, the setup that scales much better in practice is a single routing/meta-skill coupled with a dynamic registry. Rather than loading 50+ tool schemas into the system prompt: The agent keeps one primary tool installed: discover_and_execute_capability. When a user request comes in, the agent passes the intent to the registry. The registry evaluates the task against a dynamically indexed, security vetted database of capabilities, fetches the exact schema needed, and executes or injects it just-in-time for that specific turn. The Takeaway Your agent harness(smth like lyzr control plane or google azure foundry) shouldn't be a giant bundle of installed dependencies, it should be a lightweight runtime that dynamically fetches tools on demand. It keeps system prompts lean, reduces hallucinated tool calls, and decouples capability updates from your local application logic.