Build Lean Specialist Pipelines with Fresh Review Contexts

Specialized agents, reusable skills, and sequential pipelines are different ways of organizing context and responsibility. Their value comes from giving each stage a narrow task, an appropriate tool set, and a clean information boundary. The strongest designs are usually lean. They use only enough specialization to improve quality without recreating a large human organization chart in software.

Two practical patterns are especially useful:

• Parent, researchers, and quality assurance.
• Developer and quality assurance.

A reusable skill is a compact operating procedure. It stores a name, description, instructions, permitted tools, and the process for completing a recurring function. A specialized subagent can receive similar information, but it also starts with a separate context window and performs the work behind a clearer execution boundary.

This makes skills and subagents closely related. Both package task-specific knowledge and tool use. The main difference is that a subagent usually gets a fresh context, while a skill often runs inside the current agent's context. A skill reduces context by compressing a procedure. A subagent reduces context by isolating the procedure in a new thread.

In the parent-researcher-QA pattern, a strong parent agent acts as orchestrator. It decides what needs to be done and delegates broad information collection to several research agents. The researchers return concise findings. The parent uses those findings to design or implement the solution. A fresh QA agent then inspects the result, reports defects or weaknesses, and sends feedback to the parent. The parent revises the work and repeats the QA loop until no material issues remain or a stop condition is reached.

In the developer-QA pattern, the system is even simpler. One capable agent performs the work. A newly spawned reviewer with no development history inspects the output. The developer receives the review, corrects the issues, and submits the result again.

The fresh QA context is important. The developer has seen the assumptions, compromises, and reasoning that produced the implementation. That history can bias its self-review. A separate reviewer sees the artifact rather than the development story and is therefore more likely to challenge what the builder accepted.

Sequential specialist pipelines use the same principle. Agent A completes one stage and hands a defined artifact to agent B, which performs a different stage, then passes its output to agent C. Development, bug review, and testing are natural examples because building quickly and looking aggressively for faults reward different behaviors.

One long-running agent accumulates context and carries the same assumptions through planning, implementation, and review. This can reduce both focus and independence. Specialization keeps each stage closer to a clean context and aligns the agent's prompt with one objective.

A lean pipeline also improves maintainability. Rather than creating many artificial executive roles and layers of delegation, it separates only the functions that benefit from different contexts, tools, or incentives.

Define each specialist in a compact, reusable form:

A clear identifier for the specialist or skill.

The function it performs and the situations that should trigger it.

The focused instructions and workflow it should follow.

The tools it is allowed to use.

The model selected for the stage when the harness supports that choice.

The concise findings, artifact, or review that it returns to the parent or next specialist.

For a parent-researcher-QA system, the parent should not send vague requests such as "research this." It should assign distinct research axes and require concise findings. The QA agent should receive the completed artifact and explicit review criteria, but not the full development conversation unless that context is necessary to judge a requirement.

For recurring workflows, store the specialist procedure as a compact skill. When isolation is important, instantiate it as a subagent with a fresh context. These approaches can be combined: a subagent can load a reusable skill and execute it independently.

Keep the hierarchy shallow. Add another specialist only when it offers a clear benefit such as a fresh review perspective, a different tool set, a distinct cost profile, or a genuinely separate stage.

These patterns can be combined without adding a deep hierarchy. Independent agents can first generate and compare possible directions, parallel researchers can investigate the selected options, a parent can implement the result, and a fresh QA agent can review the finished artifact. Each pattern should solve a distinct problem rather than exist as an extra layer for its own sake.

Every handoff creates loss. The upstream agent may omit context, the downstream agent may misinterpret the artifact, and the parent may misunderstand the review. Delegation also compounds uncertainty because each step is farther from the original human instruction.

Subagents have startup and coordination costs. Too many roles can make the workflow slower, more expensive, and harder to inspect. Human organizational labels do not guarantee useful specialization; agents do not need a deep hierarchy merely because companies use one.

Fresh reviewers can also miss intent that was never written down. The solution is not to give them the entire development history, but to provide clear requirements and acceptance criteria with the artifact.

Specialize by function, not by theatrical job title. Use fresh contexts where independence matters, keep handoffs explicit, and favor a shallow builder-reviewer or parent-researcher-reviewer structure over a bloated agent organization.