ADR-058: Agent Specialization and Domain Ownership

Status

Exploratory

Context

As the agent team grows and the codebase becomes larger, a question arises: should agents have specialized knowledge domains? Currently, all agents are generalists — any agent can work on any part of the codebase, and the shared CLAUDE.md, skills, and plugins are identical across all agents.

The idea is to assign persistent responsibility areas to specific agents. For example, one agent could specialize in cortex/tooling/agent infrastructure, another in architecture and cross-cutting concerns, and others could be assigned to specific engines (Catalog, Prism, Spatial, etc.).

Potential Benefits

• Faster context loading: An agent that consistently works on the same code builds deeper institutional knowledge across sessions via memory files and pattern familiarity.
• Clearer routing for users: "Ask Daneel about CLI tooling" is a simpler mental model than spinning up a random agent and explaining context from scratch.
• Reduced cognitive load per agent: Agents don't need to carry skills, plugins, and knowledge for areas they never touch.
• Deeper expertise: Repeated exposure to the same code produces better pattern recognition and fewer mistakes in that area.

Concerns and Risks

• Cross-cutting work is common: Most features touch multiple layers. Hard-siloing knowledge could make agents less effective when work spans their boundary (which it frequently does in a monorepo).
• Availability bottlenecks: If only one agent "owns" an area and that agent is in a session, nobody else can do that work. With 3-4 agents and many engines, scheduling conflicts would be frequent.
• Knowledge fragility: If only one agent ever touches Prism and that agent's memory gets corrupted or a session goes sideways, the only "expert" is lost. Multiple capable agents provide resilience.
• Implementation overhead: Fragmenting the shared knowledge base (CLAUDE.md, skills, plugins) adds maintenance burden and risks drift between agents.

Options Under Consideration

Option A: Soft Specialization (Preference-Based)

Each agent has documented primary areas they're assigned to by default, but any agent can work on anything. Routing is by convention, not enforcement.

• Assignments documented in agent memory files and .dplx/config.json
• CLAUDE.md and skills remain shared across all agents
• Agents build deep memory files for their areas naturally
• Users route work to the specialist first, but fall back to any available agent

This is essentially what already happens organically — formalizing it just makes the implicit explicit.

Option B: Hard Specialization (Enforcement-Based)

Agents have restricted access to skills, plugins, or knowledge files based on their assigned domain. An agent assigned to Catalog would not have the database migration guide for Prism, for example.

• Per-agent skill/plugin configurations
• Domain-specific CLAUDE.md supplements
• Potential for per-agent .claude/ configurations

Higher overhead, risk of blocking agents on cross-cutting work.

Option C: Hybrid — Specialized Agents + Generalist Fallback

Some agents are specialists (engine-specific), while at least one remains a generalist who can handle anything. The generalist acts as a fallback and handles cross-cutting work.

Current Thinking

No decision has been made. The soft specialization approach (Option A) seems lowest-risk and closest to what already happens naturally, but even that needs more thought about:

• How specialization assignments would be documented and maintained
• Whether any tooling changes are needed or if it's purely convention
• How to handle the inevitable cross-domain work without creating friction
• Whether the current team size (3-4 agents) is even large enough to benefit

Decision

None yet. This ADR captures the discussion for future reference.