Reducing Orchestrator Context Load with Sub-Agent Output Design

1.Why the orchestrator saturates first

On Databricks, a multi-agent system puts one coordinator in front of several specialists. That coordinator might be a Supervisor Agent built through Agent Bricks, or a custom orchestrator on Databricks Apps built from the OpenAI Agents SDK template. The specialists can be Genie Agents, knowledge assistants, serving endpoints or other app agents. Users get a single entry point, and each specialist works its own domain.

The mechanism is simple. In the Databricks Apps orchestrator, each configured sub-agent becomes a tool. The design-patterns guide describes an agent's loop as calling tools and then integrating tool outputs into the conversation. Put those together and every sub-agent reply becomes part of the orchestrator's working context. The orchestrator keeps it there, re-reads it on every later reasoning step, and reasons over it alongside everything else.

That is why saturation shows up at the orchestrator before anywhere else. Each sub-agent has its own context and only sees its own slice of the work. The orchestrator sees all the slices. If a Genie sub-agent returns a hundred result rows, a RAG sub-agent returns five full retrieved passages, and a custom agent returns its whole reasoning trace, the orchestrator holds all of that at once. A Databricks blog post on supervisor architecture names this pressure as a reason to split work into agents in the first place: otherwise the context grows too complex for a single agent to keep track of. Verbose sub-agent output brings the same problem back, this time inside the orchestrator.

Sources123

2.The design change: return conclusions, not evidence

Start with what the orchestrator actually does. The Supervisor Agent documentation describes its job as managing agent interactions, task delegation, and result synthesis. Routing needs to know what has been done and what is still open. Synthesis needs each specialist's conclusion. Neither needs the evidence each specialist went through to reach its conclusion: every SQL row it scanned, every passage it retrieved, every intermediate thought.

That difference points to the change the exam is looking for. Have each sub-agent return a compact, decision-relevant result, and keep the detail on the sub-agent's side. A well-designed return usually contains:

- The answer or finding for the sub-task, stated directly. - A status: done, partial, or blocked, plus any open question the orchestrator has to act on. - Key figures or entities the orchestrator will need to combine with other sub-agents' results. - Provenance: which table, document or source backs the finding, so the detail can be fetched later if needed.

What stays out: raw transcripts, raw tool payloads, full retrieved documents, and chain-of-thought.

This is the only family of fixes that fits both halves of the objective. It reduces load because the orchestrator stops holding evidence. It keeps coherence because the orchestrator still gets every conclusion it needs to synthesize. Now compare the options that fail one half or the other. Truncating or dropping the orchestrator's older turns reduces load, but it throws away conclusions the orchestrator still needs, which breaks coherence. Passing full transcripts up "to be safe" keeps everything and makes saturation worse. Moving to a larger model or adding more sub-agents changes neither what each reply contains nor where it ends up.

Sources4

3.Shaping sub-agent output with structured outputs

A compact result is easier to rely on when its shape is fixed. Databricks structured outputs let a chat model return JSON that follows a schema you supply through response_format. That works the same way across supported model providers. For sub-agent design, a schema with fields such as finding, status, and sources stops a sub-agent from drifting back into long free text. It also gives the orchestrator a predictable shape to combine. The documented example below extracts a small, fixed set of fields from a long input, which is exactly the move a sub-agent's final reply needs to make.

response_format = {
      "type": "json_schema",
      "json_schema": {
        "name": "research_paper_extraction",
        "schema": {
          "type": "object",
          "properties": {
            "title": { "type": "string" },
            "authors": {
              "type": "array",
              "items": { "type": "string" }
            },
            "abstract": { "type": "string" },

The documented limitations matter for this design, and one of them catches people out. A schema fixes the shape of the output, not its size. Foundation Model APIs do not enforce length or size constraints, so a maxLength on a summary field will not stop a long reply. Brevity has to come from the sub-agent's instructions, such as "state the finding in two sentences". Keep the schema flat too: the docs say heavily nested schemas lower generation quality.

Sources5

4.Keeping the task coherent, and measuring the effect

The usual worry about compact returns is that the detail is "gone". It does not have to be. Detail can live on the sub-agent's side and be fetched when needed. On Databricks, managed agent sessions are one place for an agent's full history. The docs describe using them to rebuild full context, tool calls and reasoning included, on a follow-up. The details of sessions and memory belong to their own lesson. The point here is the contrast. A compact return with provenance is lossless for what the orchestrator needs, and the full detail can still be retrieved. Truncating the orchestrator's history is lossy: whatever falls off the end is gone, conclusions included.

You can draw an analogy with how Databricks describes memory. As a session builds up, the agent distills the durable facts out of it. A good sub-agent return does the same thing for the orchestrator: it keeps what matters for the next decision and leaves the bulk behind.

Diagnose before you redesign. MLflow Tracing records multi-agent runs with visibility into which agent was called on each turn and the messages passed between agents. From version 3.2.0, it also records token usage per call. Reading token usage span by span shows which sub-agent's replies make the orchestrator's input tokens jump. That sub-agent's output is the one to redesign first. The snippet below comes from the AG2 tracing integration page, but it uses the general MLflow trace API.

last_trace_id = mlflow.get_last_active_trace_id()
trace = mlflow.get_trace(trace_id=last_trace_id)

total = trace.info.token_usage
print("Input:", total["input_tokens"], "Output:", total["output_tokens"], "Total:", total["total_tokens"])

for span in trace.data.spans:
    usage = span.get_attribute("mlflow.chat.tokenUsage")
    if usage:
        print(span.name, usage)

for span in trace.data.spans:
    usage = span.get_attribute(" ? ")
    if usage:
        print(span.name, usage)

Sources678

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Passing each sub-agent's full transcript up to the orchestrator is the safest way to keep the task coherent.Why is that wrong?

   The orchestrator needs conclusions to synthesize, not the evidence behind them. Full transcripts make saturation worse. Compact results with provenance keep coherence, and the full detail can be stored and rebuilt elsewhere if a later step needs it.

   Covered in The design change: return conclusions, not evidence

2. 2.Adding maxLength to a sub-agent's structured-output schema will cap how much it returns to the orchestrator.Why is that wrong?

   Foundation Model APIs do not enforce length or size keywords. The schema fixes the shape of the output, and brevity has to come from the sub-agent's instructions.

   Covered in Shaping sub-agent output with structured outputs

3. 3.Orchestrator saturation comes mainly from the orchestrator's own prompt, so the fix is to trim or truncate the orchestrator's history.Why is that wrong?

   Each sub-agent is a tool whose output is added to the orchestrator's conversation, so sub-agent replies are usually the main source of load. Truncation discards conclusions. Shrinking what sub-agents return deals with the cause.

   Covered in Why the orchestrator saturates first