Why your agent gets dumber with more skills (and how to fix it)

Almost every developer exploring agent extensibility goes through the same phase:

You discover a vibrant library of skills: code review, automated refactoring, Git committing, Docker management, database queries, documentation generation, web research, social posting, and more. Eager to unlock ultimate productivity, you install all twenty-odd skills into a single flagship agent, expecting a universal full-stack assistant.

Then reality hits:

• Simple code edits stumble as the model hops erratically between overlapping search tools.
• Asked to review a PR, the agent takes the liberty of rewriting source files and preparing an unprompted commit.
• Asked to fetch a documentation page, it attempts to inspect production container metrics instead.
• Even a simple "hello" incurs noticeable latency and a massive token bill.

This is skill bloat—the pitfall of the monolithic "God Agent." This article breaks down why piling skills into one agent degrades model performance and how Holon solves it through role-based skill isolation.

The four pitfalls of skill bloat

Treating skills like traditional software plugins overlooks how language models work. An LLM's context window is both working memory and attention bandwidth. Packing too many tools into one prompt introduces four fundamental conflicts:

1. The Context Tax and Attention Dilution

In modern agent frameworks, a skill injects tool schemas and workflow guidance into the system prompt.

When an agent mounts 25 skills:

• The Hidden Cost: Each skill brings 2 to 5 tool definitions with parameter schemas, descriptions, and rules. Before the agent reads your first prompt, tool definitions alone consume 8,000 to 15,000 tokens. You pay this "context tax" on every single turn.
• Attention Dilution: Attention is a finite resource. When the prompt overflows with irrelevant tool specifications, key instructions for the immediate task get drowned out. The model misses edge conditions, skips constraints, or produces vague answers.

2. Instruction and Persona Collisions

Skills do not just export tool signatures; they enforce operational principles. In many workflows, these principles are diametrically opposed.

Consider the clash between a Code Reviewer and a Software Developer:

Combine both in one agent, and a vague prompt like "check why this PR failed" triggers persona paralysis:

• The agent might overreach, rewriting production code and making git state dirty when you only wanted an opinion.
• Or, when asked to build a feature, it falls into review mode, producing lengthy critiques without writing a single line of code.

3. Tool Confusion and Hallucinated Schemas

As the skill set expands, tool names and descriptions overlap:

• You might have three search tools: ripgrep, AST grep, and semantic vector search.
• You might have four document processors: Markdown formatters, PDF parsers, DOCX builders, and plain-text extractors.

Faced with redundant choices, models exhibit choice paralysis:

• Suboptimal Paths: Calling a heavy external retriever when a simple local rg -n command would pinpoint the line instantly.
• Schema Bleed: Passing parameters from Tool A into Tool B's invocation payload, causing runtime argument errors.
• Retry Loops: Bouncing between similar tools in fruitless loops, exhausting quotas without making progress.

4. Blast Radius and Trust Boundary Collapse

Safety is where monolithic agents fail most dangerously.

Under the Principle of Least Privilege, an agent ingesting untrusted external input (like web pages or inbound emails) should be sandboxed without local file-mutation authority or private credentials, defending against indirect prompt injection.

In a monolithic "do-it-all" agent:

• The agent fetches untrusted external data (web browsing, issue comments).
• The same agent possesses destructive capabilities (git push, shell execution, database writes, external publishing).

If a retrieved web page contains an adversarial injection payload, the agent's defenses crumble. The malicious input gains direct access to system-level execution tools. Stacking all skills into one container demolishes every trust boundary.

Holon's design: isolate skills across dedicated roles

Rather than inventing fragile runtime heuristics to filter tools dynamically, Holon adopts the proven pattern of human engineering teams: specialization and division of labor.

You would not expect one engineer to simultaneously serve as core developer, strict compliance auditor, release manager, and public relations lead in the same conversation. Agents deserve the same clarity.

1. Shared Skill Library with Scoped Enablement

Holon decouples skill storage from agent execution:

• Shared Library: Skills are installed once into the environment's library (for example, via holon skills add).
• Scoped Enablement: Skills are never enabled globally by default. Each agent activates only the minimal set required for its specific role:
  • The code review agent mounts read-only review workflows and GitHub event listeners.
  • The developer agent mounts patch application, workspace management, and local build verification tools.
  • The documentation agent mounts Markdown wiki and link-validation tools.

On every model turn, the agent's prompt contains only the 3 to 5 tools relevant to its job. The prompt remains lean, attention stays sharp, and token costs drop dramatically.

2. Dedicated Role Contracts (AGENTS.md) and Workspace Roots

Every long-lived agent owns an isolated configuration root:

• Dedicated AGENTS.md: Outlines standing instructions, core duties, escalation thresholds, and hard boundaries. No competing personalities or contradictory rules.
• Workspace Isolation: A developer agent works inside an isolated Git worktree with write authority, while a reviewer inspects canonical checkouts in a read-only projection.

3. Collaboration via WorkItems and Event Delegation

How do specialized agents collaborate on complex goals?

Instead of relying on fragile prompt switching ("Now act as a reviewer... Now act as a coder..."), Holon coordinates work through explicit structures:

1. Durable WorkItems: Objectives, checklists, and acceptance criteria survive across turns, independent of conversation context windows.
2. Asynchronous Delegation: A developer agent finishes a patch and delegates a read-only review to the review agent. The reviewer inspects changes in its own clean context and records structured findings.
3. Wait and Wake: The developer agent sleeps while waiting for review feedback. When the reviewer finishes, an event wakes the developer agent to address findings and complete verification.

Each agent excels at its mandate, and every context window remains clutter-free.

Beyond Holon: Role and directory isolation in Claude Code and Codex

The principle of role-based skill isolation is not tied to a single platform. If you primarily work with Claude Code, OpenAI Codex CLI, or custom terminal agents, you do not have to dump every MCP server and workflow script into a global ~/.claude.json or project root.

You can adopt a lightweight Agent Home pattern directly on your filesystem:

1. Create dedicated role directories

Establish separate home folders for recurring responsibilities:

mkdir -p ~/.agents/code-reviewer ~/.agents/developer ~/.agents/docs-steward

2. Isolate instructions and tools per directory

• Scoped behavioral contracts (CLAUDE.md / AGENTS.md): In ~/.agents/code-reviewer/CLAUDE.md, declare the agent as a strict, read-only auditor: explicitly forbid file mutations and require line-numbered evidence for all findings. In ~/.agents/developer/CLAUDE.md, focus on implementation guidelines, minimal diffs, and local test verification.
• Locally scoped MCPs and tools: Place a dedicated .mcp.json or local tool manifests inside each directory:
  • code-reviewer mounts only read-only AST parsers, linter tools, and GitHub read MCPs.
  • developer mounts patch application, build tools, and test runners.
  • docs-steward mounts Markdown linters and link checkers.

3. Launch from the role directory, target the project

Instead of starting an agent in an overloaded project root with dozens of competing tools, launch it from the specialized role folder and instruct it to inspect the project workspace or a linked Git worktree:

# Launch a focused review session pointing to your repository
cd ~/.agents/code-reviewer && claude "Review recent changes in /path/to/my-repo"

The immediate benefits:

• Every turn injects only the 3 to 5 tools essential for that persona.
• Attention remains concentrated on your code rather than navigating extraneous schemas.
• Hallucinated arguments and out-of-bounds file edits vanish.

4. From manual directory isolation to dedicated runtimes

Setting up isolated role directories takes five minutes and delivers an instant boost in prompt efficiency and reliability.

As your workflows scale, however, you inevitably face orchestration hurdles: How does the review agent hand findings back to the developer without manual copy-pasting? How do agents sleep while waiting for feedback instead of burning tokens? How do multi-day initiatives track verifiable milestones?

This is where a dedicated agent runtime like Holon naturally fits in. It codifies the same directory-isolated design (agent_home per agent) while adding durable WorkItems, event-driven wait/wake cycles, and workspace projection. Directory isolation is the foundation; runtime orchestration is the natural next step.

Comparison: Monolithic Agent vs. Role-Based Multi-Agent

Keep your agents focused

If your agents suffer from sluggish responses, tool confusion, or stray actions, stop packing every new skill into a single prompt.

Break down your workload:

1. Identify your core recurring tasks (such as development, review, and documentation hygiene).
2. Create dedicated long-lived agents for each role.
3. Equip each agent with only the skills it genuinely needs, backed by an explicit AGENTS.md.

Less is more. When each agent operates with a focused context and clear boundaries, even cost-effective models deliver reliable, high-grade results.

Next steps and hands-on guides

• Learn how to configure dedicated skills and role boundaries step by step: Organize agent skills across dedicated roles.
• Explore built-in agent templates for common engineering roles: Create an agent from a template.
• Understand how durable work items keep multi-agent workflows reliable: Why WorkItems?.

Mechanisms and patterns described here reflect production behavior in Holon runtimes.