Claude Haiku 5.5 subagents: a lead-worker pattern worth testing

TL;DR

• Anthropic announced Claude Haiku 5.5 on October 7, 2026, and positions it for focused coding subagent work beside Opus 5.5 and Sonnet 5.5.
• A useful pattern gives a stronger lead the plan, architecture decisions and final review.
• Haiku workers get narrow tasks, clear output formats and a requirement to cite evidence.
• This is a workflow proposal. It is not a measured savings claim or an Agent benchmark.

The new AI coding meta might be a strong lead with focused, lower-cost workers. Anthropic says Haiku 5.5 pairs with Opus 5.5 and Sonnet 5.5 as a coding subagent. The API list price is lower than the larger models, but an API price is not the same thing as a subscription allowance. The useful question is what work a small worker can finish without creating more review than it saves.

Give the lead the decisions

The lead should own the task contract. It reads the request, identifies the acceptance check and decides which work can happen in parallel. It also owns final integration. The lead can reject a report that is incomplete, stale or outside the task.

I would give the lead four jobs:

1. State the goal in one sentence.
2. Name the files, records or sources that can answer it.
3. Split the work into bounded questions with one output shape each.
4. Review every result against the acceptance check before it changes the main task.

This keeps the lead's context focused on judgment. It also makes a handoff legible. A later agent can see the assignment, result and acceptance decision.

Give workers small jobs with a proof attached

A worker should not receive “understand the repository.” That request has no finish line. A better assignment is “find every caller of this function, list the file basenames and line numbers, and state whether each caller expects a nullable value.” The worker returns facts, not a new plan.

Other good worker jobs include:

• extract the constraints from a contract or API schema;
• inspect the test output and group failures by symptom;
• compare two configuration files and list only meaningful differences;
• check documentation links and mark each source current or stale;
• summarize a log window with timestamps and error classes.

Each result needs a source pointer, a confidence boundary and an explicit unknown. If the worker cannot access a file, it should say that. A short report with evidence is more valuable than a confident paragraph with no trail.

The Claude Code sub-agent documentation describes the capability. It does not promise that every split is useful. Worker calls still consume shared usage limits, and parallelism can increase review work.

Escalate ambiguity instead of smoothing it away

The lead should escalate a worker result when the task has conflicting sources, an untested assumption or a failed check. An escalation is a normal state in the workflow. It is not a model failure that the system should hide.

A useful escalation packet contains:

• the disputed statement;
• the two pieces of evidence;
• the decision that is blocked;
• the smallest question a person or stronger model can answer;
• the work that can continue safely in parallel.

This preserves retained context without forcing the next model to reread every log. It also gives a provider change a clear boundary. If the lead moves from Claude to another route, the next model receives the task state and unresolved question, not a vague request to “take over.”

Review the finished change outside the worker

The final review should use a check the worker did not invent. Run the repository's declared tests, inspect the changed files and compare the result with the original acceptance check. Keep failed attempts and timeouts visible. A green sentence in the worker report is not proof that the finished change is correct.

For an API workload, I would measure cost and time per accepted change, including retries and review. For a subscription workflow, I would track allowance use and reset windows separately. Lower-cost calls only help if the finished work holds up.

Agent's shipped evidence model follows the same direction: a task can leave a receipt with its output, checks, route and qualified cost, while missing or stale proof remains Unverified. That is the useful boundary for a lead-worker design. The worker can suggest; the lead can integrate; the check can decide.

What to test first

Start with one repository task that has a deterministic validator. Compare a single lead with a lead plus two focused workers. Count accepted changes, retries, review minutes, failed handoffs and allowance use. Declare the protocol before the first run. Keep the first result as a baseline, even if the worker split feels obviously better.

Haiku 5.5 gives this pattern a plausible new worker. The evidence still has to come from the task you care about.

Sources and related reading

The source event is my October 7 LinkedIn post. Anthropic's Claude Haiku 5.5 announcement supplies the model positioning and pricing context.

• Your AI agent says it is done. Is it?
• Harness vs model: where the gains come from
• Claude Haiku 4.5 vs Sonnet 5.5: every measured row
• SASID service companion: Claude Haiku 5.5 subagents

See the Agent overview if you want to try a retained task with an explicit handoff and a reviewable result.