Domain-Specific Agents Over General-Purpose
The Idea
Is Claude Code the ultimate agentic system? Not necessarily. Claude Code's power comes from code being the fundamental language of computers - it can do basically everything. But we don't always need one agent doing everything.
The insight: specialized tools for specific environments can outperform general-purpose agents.
Example: For a personal knowledge base, I really only need:
- Read/write files
- Web search/fetch
- Search my own context (list files, search knowledge space)
That's it. No bash commands, no code execution, no complex file operations. A purpose-built agent with 5 well-designed tools could be more effective than a general agent with 20+ tools, because:
- Simpler tool selection = fewer errors
- Tools can be optimized for the exact use case
- Less capability surface = less risk of unintended actions
- Faster, cheaper (fewer tokens reasoning about irrelevant tools)
Why This Matters
This challenges the "maximize capabilities" approach to agent design. The question isn't "what CAN an agent do?" but "what SHOULD this agent do for this specific context?"
Relates to the inference-bridged workflows idea - sometimes the constraint is what makes the system useful, not the capability.
Extension: Hooks enable deterministic workflows within agent systems. Instead of relying on the LLM to decide "what next," hooks can enforce specific sequences, validations, or transformations. Hybrid architecture: agent for inference-heavy steps, hooks for predictable/critical steps.
Further Observations (from discussion)
The general-purpose trap: Having 20+ tools means decision complexity at every step. For most tasks, 3-4 tools suffice. The overhead isn't just tokens - it's branching points where the agent might choose wrong.
Tool design > tool count: A well-designed "save thought" tool that understands templates, auto-links related entries, and updates indexes would outperform an agent manually doing 4-5 file operations.
The cost of generality: The agent reasons about tools it'll never use in context. A purpose-built agent could be faster, cheaper, and more reliable.
Counter-argument: The value of general-purpose is handling edge cases gracefully. Suddenly need to debug a script or fetch a complex webpage? A general agent can. A narrow agent fails.
The sweet spot: narrow tools + general fallback. Purpose-built tools for 90% of operations, with ability to escalate to general capabilities for edge cases.
Connection to Inference-Bridged Workflows
Same underlying principle applied to different dimensions:
| Inference-Bridged | Domain-Specific Agents | |
|---|---|---|
| Constraint | Goals & criteria | Tool surface |
| Freedom | Exploration & reasoning | Inference within tools |
| Sweet spot | Constrain the what, free the how | Narrow tools + general fallback |
In inference-bridged workflows, scaffolding (data sources, workflow structure) lets AI focus on the inference bridge. Domain-specific tools are scaffolding for the agent itself - a well-designed save_thought tool lets the agent focus on inference (understanding the idea, linking concepts) rather than mechanics (which files to edit, in what order).
Both are about reducing decision surface to amplify inference quality.
- Too many tools → agent reasons about irrelevant options (same as "too vague")
- Too few tools → agent can't handle edge cases (same as "too prescriptive" becoming brittle)
Related
- Claude Agent SDK Study - Agent loop architecture this thought builds on
- Inference-Bridged Workflows - The guidance paradox: constrain the what, free the how
- The Builder's Curse - Making AI systems understandable
- Agent.md as the Future of Software - Takes this further: what if the .md file IS the software?