Agents
/subagentDelegate bounded work, verify what returns.
What delegation changes
A separate context is a design choice, not extra intelligence
A subagent is a separate agent run given a bounded part of a larger task. It usually works in its own context, so its file reads, tool output and exploration do not all enter the main conversation. What returns is a report or artifact. That can protect the main thread's attention and make responsibility easier to divide.
The benefit is not that the model remains equally smart in every setting. Performance can change with the model, tools, instructions, context quality and task. A fresh context can remove irrelevant history while also removing useful history. Delegation is therefore an exercise in designing context, authority and a return contract, not multiplying intelligence.
Delegation changes the context trade-off
A separate context can reduce irrelevant exploration in the main thread, but briefing and verification still consume attention.
Possible benefit
- Bounded exploration A focused agent searches within a named question
- Independent review context A second reader can challenge assumptions
- Smaller main-thread return Evidence can be selected instead of replaying every step
delegate when benefit exceeds cost
Real cost
- Briefing Relevant constraints must be transferred
- Returned evidence References, commands and uncertainty still enter the wider task
- Verification Consequential claims must be checked by the owner
Performance varies with the model, tools, instructions, evidence and task.
A complete research delegation
Return evidence, uncertainty and a clear boundary
Imagine a team planning automatic invoice reminders. Before changing the logic, the main agent needs to know every path that can mark an invoice paid. It delegates a read-only research task: "Map all code paths that change payment status. Do not edit files. Search the repository, trace indirect calls and return exact file references, the trigger for each path, the search commands used and anything you could not resolve."
The return contract asks for four sections: conclusion, evidence table, unresolved questions and recommended next check. The subagent reports an administrator action, an automated message from the payment provider and a bulk import, each with a file reference. It also says that code chosen only at runtime remains unresolved. That last line is part of the result, not an embarrassment to hide.
The main agent does not paste the conclusion into a plan and move on. It opens the cited files, reruns the repository search and traces the unresolved handler. That check finds a scheduled reconciliation path, so the map grows from three paths to four. The reminder design now rechecks payment status immediately before sending and tests all four update routes. Delegation reduced the main thread's reading load; verification made the result usable.
A useful return is an evidence packet
The subagent does not return just an answer. It returns enough material for the wider task to verify and act.
- Bounded brief Map payment-status paths; read only; do not edit. Question + authority
- Repository exploration Search direct and indirect calls within the delegated context. Separate working context
- Evidence packet Conclusion, file references, search commands and unresolved handler. Reviewable return
- Main-thread verification Reopen sources and trace the unresolved path. Owner check
- Design change Recheck status before sending and test all four routes. Integrated outcome
Delegation reduced reading load. Verification discovered the missing fourth path.
The skill is in the contract
Delegate bounded responsibility, retain integration
A good delegation names the question, allowed sources, tools, authority, output shape, evidence standard and stopping condition. The main agent keeps the integration task, while a named human owner retains final authority and accountability for consequential decisions. This is why bounded research, independent review and isolated implementation units are often easier to delegate than a vague instruction to "handle the rest."
The old rule "delegate the digging, keep the thinking" is a useful prompt, but too rigid. A subagent can analyse or challenge a decision when it receives the relevant evidence and a reviewable contract. Conversely, simple research should stay local when briefing and checking it would cost more than doing it. The better test is: can I state the boundary, recognise a valid return and verify the consequential claims?
Keep local or delegate?
Choose by boundary and verification cost, not by a rigid split between research and thinking.
Keep it local
- The task is small Briefing would cost more than doing the work
- Hidden context is decisive The wider conversation contains constraints that are hard to transfer
- The return would be hard to judge You cannot recognise a valid answer yet
compare total cost
Delegate it
- The responsibility is bounded Question, sources, authority and stop condition are explicit
- The context can be supplied No decisive constraint remains hidden
- The return is verifiable Evidence and uncertainty can be checked economically
Research, analysis and review can all be delegated when the contract is sound.
Where delegation bends
Separate contexts can still share the same failure
Hidden context is the first limit. If the main thread knows that a policy, customer promise or prior decision matters but omits it from the brief, the subagent may return a locally coherent answer that is wrong for the task. Summaries can also remove minority findings or uncertainty. Send the minimum necessary context, but never hide a constraint that could change the answer.
Coordination is the second limit. Parallel agents can duplicate research, depend on stale results or edit the same file. Shared databases, branches and external services can create conflicts even when conversations are separate. Use read-only tasks where possible, assign clear file or resource ownership, isolate writes and sequence work that has real dependencies. More detail on that boundary belongs in parallel-agent coordination.
Delegation also consumes resources: briefing, tool access, model calls, review time and returned context. It can preserve room in the main session, but it does not make context free. That is the connection to context engineering: decide what each agent needs, what it must return and what evidence survives the handoff. As a student, I want the returned uncertainty because it shows where to look next. As a professional, I keep one named human owner accountable for the combined result.