Haiku 5.5 subagents

Haiku 5.5 subagents are most useful when the delegated task has a clear boundary and a result the parent can verify. Sending a vague instruction to several workers does not create a reliable team. Begin by deciding what information each worker needs, what it may do and what evidence it must return.

Anthropic positions Haiku for bounded subagent work, and Claude Code documents its own subagent configuration. Those are different layers: the model supplies capabilities, while the application supplies delegation, tools and permissions. This site's text workspace can test a work packet, but it does not launch autonomous repository workers.

Choose a task that can return a checkable artifact

Good initial candidates include locating a function, extracting fields from supplied text or reviewing a bounded diff. The parent can inspect the returned file references, values or findings. A task such as "make the product successful" has no comparable local acceptance condition and is difficult to delegate responsibly.

For Haiku 5.5 subagents, separate discovery from decision-making when possible. A worker can identify candidate call sites and explain their behavior without deciding the final architecture. The parent retains the broader context needed to choose among those findings and coordinate any subsequent change.

Avoid splitting work merely to increase worker count. If every task depends on the same unresolved design choice, parallel execution can produce incompatible answers. Resolve the shared question first, then delegate genuinely independent pieces with stable interfaces and explicit owners.

Build the work packet

An effective packet includes the objective, relevant source material, constraints, output format and completion test. Do not assume the worker inherits every important instruction from the parent conversation. Verify what the chosen application actually passes into a subagent's context.

Haiku 5.5 subagents should receive only the context needed for that job. A full transcript can contain stale decisions and unrelated private material. A tiny packet can omit critical constraints. Review the packet as an interface: sufficient to act correctly, but not an accidental copy of everything the parent knows.

Specify the return contract before dispatch

Ask the worker to separate verified observations from hypotheses and unperformed checks. This prevents a polished summary from turning a proposed action into an apparently completed one. The parent needs to know whether a test ran, failed to start or was merely suggested.

Inspect the supplied repository area without editing files.
Locate the validator and direct callers relevant to empty titles.
Return file references and the behavior supported by each reference.
List missing context and unverified assumptions separately.
Do not install packages, execute production operations, commit or push.
Stop when the requested evidence is complete; do not broaden the task.

For Haiku 5.5 subagents, the return contract should also bound output size. Ask for the evidence needed to make the next decision, not a transcript of every search. The parent should be able to inspect the original source when necessary rather than receiving an enormous unverifiable paraphrase.

Verify the actual model and permissions

Do not infer a worker's model from its name or from the parent's selected model. Applications can have inherited defaults, explicit subagent settings and provider-specific aliases. Inspect the active configuration and retain the actual model identity when evaluating the workflow.

Claude Code's documentation describes model selection and tool restrictions for its own workers. Use those documented controls rather than copying an old configuration snippet from an unrelated client. A Haiku 5.5 subagents experiment in another application needs that application's equivalent configuration evidence.

Give a read-only worker read-only tools. A sentence prohibiting edits is helpful, but a restricted tool surface is a stronger boundary. Keep credentials and external actions scoped to the authorized task; a worker should not gain deployment access merely because its parent has it.

Decide who owns shared files

When workers may edit, assign non-overlapping ownership or a deliberate integration process. Two agents changing the same shared module can invalidate each other's assumptions even if each local patch looks correct. A common workspace is not a substitute for coordination.

For Haiku 5.5 subagents doing implementation, provide the module contract and acceptance tests before dispatch. Require each worker to report changed files and tests actually run. The integrator should inspect the combined diff and run cross-module checks after the individual results return.

Do not let a worker revert unfamiliar changes simply to make its tests pass. Those changes may belong to another worker or the user. Conflicts should be surfaced with evidence and resolved by the task owner, not silently erased as though the worker owned the entire repository.

Handle failure without endless redispatch

Set a deadline and an attempt policy for the delegated job. Distinguish a blocked tool, missing context and an incorrect result. Sending the identical packet again will not resolve a missing credential or an ambiguous requirement, and can repeat the same failure at additional cost.

If Haiku 5.5 subagents return uncertain evidence, the parent can ask a focused follow-up or inspect the source directly. Escalate when the job requires judgment beyond the packet's scope. Preserve what was already verified so a stronger worker does not restart the entire investigation unnecessarily.

Keep worker status tied to a stable task identifier. A late result from an earlier attempt must not overwrite a newer accepted result. Cancellation should mean the application stops or safely ignores the work according to its lifecycle, not merely that the parent stops looking at the message.

Test Haiku 5.5 subagents with a deliberately delayed result after cancellation. The parent should recognize the task as closed and avoid applying the stale recommendation automatically. This checks the orchestration boundary independently of whether the worker's text happens to be correct for the earlier task state.

Count the parent's work as well

Delegation adds briefing, result reading and integration effort. A worker's low token cost does not establish that the complete workflow is cheaper. Compare the total task, including parent calls, retries, review and any duplicated context sent to several workers.

A Haiku 5.5 subagents evaluation should use the same acceptance condition as a single-agent baseline. Record completion time and accepted outcome quality, not just how quickly workers return messages. Several fast partial answers can still require a slow integration step that dominates the actual job.

Use repeated representative tasks before deciding which roles to delegate. Repository search, writing and code repair have different verification costs. The best split may use a small worker for evidence collection and keep implementation or final review with a model chosen for those harder decisions.

Test the handoff itself

Create a case where the worker's evidence is incomplete and another where it contradicts the parent's initial assumption. The parent should preserve the uncertainty and inspect the conflict, not automatically accept whichever statement is newer or more confidently phrased.

For Haiku 5.5 subagents, evaluate whether important constraints survive both directions of the handoff. A no-write rule must reach the worker, and a failed test must reach the parent. Losing either fact can make a seemingly successful delegation unsafe or misleading.

Begin with one bounded worker and a verified return before adding concurrency. The routing guide explains choosing a destination, while compaction explains preserving task state when context is shortened. Neither mechanism removes the need for an owner who checks the final result.