What a subagent receives and what it returns

A subagent exists to do heavy work without filling the coordinator’s context. For that to work, what it receives matters as much as what it returns.

What it receives

The subagent starts with an isolated context: it doesn’t see the coordinator’s conversation. Everything it needs has to go in the request: the goal, what is already known, what is missing and the format of the result. A goal-oriented request works better than a list of steps.

If you pass it results from other agents (for example, searches and document analyses so it can write the synthesis), they go in complete and in a structured format that separates the content from its metadata: URL, document name, page number. That way the subagent doesn’t lose the attribution of each piece of data and can cite where it came from.

What it returns

A concise structured result: the key findings with their references (file and line, source and date) so they can be verified. What to avoid:

• returning the full transcript, because it fills the coordinator’s context;
• having the coordinator read the subagent’s working files, because that skips the organised result;
• cutting it off with max_tokens, because the result ends up incomplete.

In parallel or in sequence

If the tasks are independent, the coordinator makes several Task tool calls in a single response and they run in parallel. If one needs another’s result, they run in sequence. For the coordinator to delegate, Task must be in its allowedTools.

The subagent definition

In the Agent SDK, each subagent is described with an AgentDefinition:

• description: when to delegate to this subagent (the coordinator reads it to decide);
• prompt: the subagent’s system prompt;
• tools: which tools it can use.

In the exam

If the problem is that the coordinator runs out of room, the answer is almost always that the subagent should return less and better organised, not that the coordinator should read more.