Website of Peter Westerman

By the time fifteen products had been built, a pattern in session quality was unmistakable. General sessions — bringing a mix of task types to one AI conversation and working through them in sequence — produced acceptable results. Specialist sessions — bringing one specific type of complex task to an AI configured with deep, pre-loaded context for exactly that task type — produced measurably better results. The difference was not subtle, and it was consistent across every specialist task type that had enough complexity to benefit from deep domain context.

This is not a surprising finding if you apply the same logic to human professionals. A general-purpose business analyst and a specialized healthcare regulatory attorney will both give you an answer to a question about FDA approval timelines for a new medical device. The regulatory attorney will give you a significantly better answer — not because they are smarter, but because their entire context is calibrated for that domain. They know the exceptions, the edge cases, the recent enforcement changes, and the practical implications of each option. General competence supplemented by domain-specific knowledge produces better outputs than general competence alone.

The AI equivalent is not a different AI system with more capability. It is the same AI system with different context, role definition, and task scope. The context is what makes the difference.

How the ITI Agent System Is Structured

The system uses a tiered structure that parallels how effective professional services organizations work.

The Orchestrator is the entry point for any significant task. Its role is to understand what is being asked, determine which specialist should handle it, and route the task with the relevant context. It functions like a senior engagement manager who understands the full portfolio well enough to route work appropriately without needing to be a deep expert in any individual area. For straightforward tasks, the Orchestrator handles them directly. For specialist tasks, it routes to the appropriate agent and frames the handoff.

The Architecture Agent handles system design: what structure should a new product have? How should component A interact with component B? What is the trade-off between these two approaches given our specific constraints? Its context is loaded with every architectural pattern used in the portfolio, the decisions made in each product, and the reasoning behind each major structural choice. When a new product raises a design question that a previous product resolved differently, the Architecture Agent knows both approaches and the reasoning that led to each choice. That institutional memory, systematically captured and accessible, is the core of what makes the Architecture Agent more valuable than a general session on the same question.

The API Integration Agent handles all external service connections: Claude API integrations, Tavily search integrations, Pinecone vector database connections, WordPress REST API extensions. Its context includes the full Shared Library API client documentation, every integration pattern from every previous product, and the specific error scenarios and their resolutions encountered across the portfolio. When a new product needs a Claude integration, this agent applies the Shared Library correctly from the first response — there is no re-discovery of the pattern, no inconsistency with how other products handle the same integration.

The Database Agent handles data modeling, query design, migration planning, and WordPress database conventions. The QA Agent handles debugging, test planning, error analysis, and code review. The Documentation Agent handles context file updates, README generation, user documentation, and Playbook maintenance.

The Mechanics of Quality Improvement

The mechanism of quality improvement through specialist routing is straightforward: better input context produces better output. A general session asked to debug a slow database query must read the relevant files, understand the data structure and query patterns in use, and then reason about the performance issue. A Database Agent asked the same question has stable context about the data structure and query patterns already loaded, and can engage immediately with the performance reasoning at an expert level.

The ten-to-fifteen-minute orientation overhead that the general session spends reconstructing context is zero for the specialist session. More importantly, the specialist session produces recommendations that are consistent with the established patterns of the portfolio, because those patterns are part of the specialist context. A general session might recommend a technically valid but stylistically inconsistent approach to a problem that the specialist session would not — because the specialist context includes the established conventions that the general session would need the context file to learn.

For simple tasks, the overhead of specialist routing is not worth the quality gain — a general session is faster for straightforward requests. The specialist routing adds value when the task is complex enough that depth of specialist context produces meaningfully better output than shallow general context. Knowing which side of that threshold a given task falls on is a judgment call that develops with experience. A rough heuristic: if the task involves a decision that depends on the history of decisions in that domain, route to the specialist who has that history loaded.

Building Specialist Profiles for Non-Technical Work

The specialist agent model does not require software development context. The underlying pattern — build dedicated context profiles for recurring specialist task types — applies in any knowledge work domain where specific tasks recur with sufficient frequency to justify the profile investment.

A marketing director might develop a Campaign Brief Specialist with brand guidelines, audience definitions, channel characteristics, competitive positioning, and historical campaign learnings loaded as context. A Content Strategy Specialist with editorial calendar, content pillars, audience personas, and content performance data. A Competitive Intelligence Specialist with competitor landscape information, positioning frameworks, and market data maintained as context.

Each of these is the same AI system accessed with a different context document loaded at the start of the session. Building the context document takes two to four hours of focused work to document the relevant knowledge, conventions, and constraints for that domain. The return is ten to fifteen minutes of saved orientation per session, plus consistently better-calibrated outputs that require fewer corrective iterations. For professionals doing ten or more sessions per month on a given specialist task type, the investment pays back within the first month.

Maintaining Specialist Context Over Time

Specialist agent profiles require maintenance. An agent whose context was written six months ago and never updated will give advice calibrated to the state of the world six months ago — which may be significantly out of date as the project has evolved and the market has changed.

The discipline: update specialist profiles when the relevant context changes substantively. For a code-focused specialist, that means updating when architectural decisions change, when new patterns are established, or when new components are added to the shared library. For a marketing specialist, it means updating when the competitive landscape shifts, when brand guidelines change, or when significant campaign learnings accumulate.

A profile update typically takes fifteen to thirty minutes when triggered by a substantive change. The cadence does not need to be on a fixed schedule — it should be triggered by “something changed that this specialist needs to know.” The discipline to make those updates promptly, rather than deferring until the staleness becomes a problem, is what keeps specialist profiles valuable over time. Stale specialist context degrades the quality benefit of routing to the specialist in proportion to how much the underlying context has changed without being reflected in the profile.

The Routing Decision in Practice

The practical question that the specialist model raises: how do you decide when to route to a specialist versus handling something in a general session? The decision framework that worked across the portfolio:

Route to a specialist when the task has meaningful depth in a specific domain — when the quality of the answer depends on accumulated knowledge about that domain that a general session would have to reconstruct. Debug a complex database performance problem: route to the Database Agent, which has the schema knowledge and performance pattern knowledge already loaded. Design a new product’s architecture: route to the Architecture Agent, which has the portfolio’s architectural history and decision framework already loaded. Write context file documentation: route to the Documentation Agent, which has the documentation standards and templates already loaded.

Handle in a general session when the task is straightforward enough that depth of specialist context does not materially affect quality. Simple configuration changes. Straightforward bug fixes where the failure mode is obvious. One-time tasks that do not recur often enough to justify building a specialist profile for them.

The threshold is not precise. It develops through experience. The rough heuristic: if you find yourself re-explaining the same background context in multiple sessions of the same task type, you need a specialist profile for that task type.

What Happens When Specialist Context Goes Stale

A real example from the portfolio: the API Integration Agent had been operating for two months without a profile update when the Shared Library was substantially refactored to add a new Claude model version. The agent’s profile still documented the old API client interface. A session routed to the API Integration Agent produced integration code using the old interface rather than the new one — because the specialist profile was accurate as of two months ago but not today.

The session produced output that required correction. The correction revealed the stale profile. The profile was updated. The updated profile produced correct output from the next session. The total cost: one correction cycle. The lesson: specialist profiles require maintenance triggered by changes to the underlying context, not on a fixed schedule. When the Architecture Agent’s knowledge base changes — because a new pattern was established or an old one was deprecated — update the profile. When the API Integration Agent’s reference implementation changes — because the Shared Library was refactored — update the profile. Trigger-based updates keep profiles current without the overhead of fixed-schedule review of profiles that may not have changed.

How Recent AI Innovations Change This Picture

The multi-agent model described in this post — specialized AI agents for distinct task types, each with focused context and clear scope — was implemented manually using multiple Claude sessions with distinct system prompts and context files. Anthropic has since formalized this pattern into native platform features that make it substantially more powerful and easier to manage.

Agent Teams, now experimentally available with Opus 4.6, are the direct platform implementation of what this post describes. Multiple Claude Code instances working simultaneously, with direct peer-to-peer communication and shared task lists, enable the specialist model with full native coordination support. The manual coordination overhead that was required in the original methodology — human-mediated handoffs between specialized sessions — is replaced by built-in inter-agent messaging.

The architecture described in this post — Orchestrator Agent, Pattern Agent, API Integration Agent, QA Agent, Documentation Agent — maps directly onto the Agent Teams framework. The Orchestrator becomes the team lead; the specialists become teammates. The human’s role shifts from coordinating handoffs between manual sessions to directing the team lead and reviewing consolidated outputs. The span of oversight increases without a corresponding increase in coordination overhead.

Running 10+ Claude instances in parallel — demonstrated by developers rebuilding entire frontends overnight — shows where this pattern leads at scale. The multi-agent model described in this post, which required careful manual orchestration, is becoming a standard deployment pattern. The lesson about specialists outperforming generalists on complex tasks is validated by the platform’s own architectural choices: Agent Teams are designed around specialization and parallel execution, not around a single generalist session.