Multi-Agent and Long-Horizon Task Design · Topic 2 of 2
Sub-Agent Outputs, Agent Boundaries and Long-Horizon Strategies
Context Engineer exam: condensed sub-agent outputs, agent boundaries drawn too fine or too coarse, and the long-horizon strategy that fits the task.
- 5 min
- Sub-agents should return condensed structured results, not full traces or raw outputs.
- Keep decisions, assumptions and open issues in the return so the orchestrator stays coherent.
- Excessive handoff compression overhead means boundaries are too fine; runaway window growth means too coarse.
What it is
This page covers the structural choices that keep context manageable in long and multi-agent work. They are what sub-agents send back, where the boundaries between agents fall, and which long-horizon strategy carries a task across many steps.
Each choice moves context somewhere: into the orchestrator, across a handoff, or out of the window into storage.
How it works
Sub-agent output design and orchestrator saturation
An orchestrator saturates when every sub-agent returns its full trace, raw tool results or long prose. The orchestrator then holds all the detail the sub-agents were created to absorb.
The fix is a condensed, structured return: the findings, the decisions taken, assumptions, open issues and a pointer to full detail stored elsewhere, such as a Delta table. Coherence is kept because the orchestrator still sees every conclusion and every decision it must reconcile.
| Sub-agent returns | Orchestrator load | Coherence |
|---|---|---|
| Full trace | Very high | Complete but buried |
| Raw tool output | High | Orchestrator must redo the analysis |
| One line answer | Very low | Loses assumptions and caveats |
| Structured summary: findings, decisions, assumptions, open issues, reference to full output | Low | Kept |
A worked number: six sub-agents each produce 25,000 tokens of trace. Returning full traces puts 150,000 tokens into the orchestrator, while 800 token structured summaries put in 4,800.
Boundary placement failures
Where you draw agent boundaries decides which context must cross a handoff and which grows inside one agent.
| Symptom | Boundary failure | Why it happens | Fix |
|---|---|---|---|
| Excessive handoff compression overhead, details lost between agents | Too fine: a boundary cuts through tightly coupled work | Agents need the same context, so it is summarized and passed back and forth | Merge the coupled work into one agent |
| Unmanageable context growth within an agent | Too coarse: one agent owns several independent workloads | Unrelated subtasks pile into one window | Split along the independent parts |
Good boundaries follow the task's dependency structure. Work that needs the same context stays in one agent; work that is independent becomes separate agents that return short findings.
Long-horizon strategies and their fit
A long-horizon task runs past what one window holds. Three strategies handle that.
| Strategy | How it works | Fits | Insufficient when |
|---|---|---|---|
| Compaction | Summarize the history, continue with summary plus recent items | Sequential work with continuous flow where a summary preserves what matters | Later steps need exact earlier values or the full record of progress, which summaries lose |
| Structured notes outside the window | Agent writes progress, decisions and results to a persistent store, such as a Delta table or Lakebase, and reads them back | Iterative work with milestones, tasks that must survive restarts, exact values reused later | Branches are independent and broad, so one agent's window still grows |
| Parallel sub-agents | Independent branches run in clean windows and return condensed findings | Breadth-first research, many independent items | Steps are tightly dependent, forcing lossy handoffs |
An in-context scratchpad is lost on restart or compaction, so durable task state belongs in a Delta table when later runs and people read it, or in Lakebase for low-latency state lookups.
Diagnosing a strategy mismatch
Read the documented failure, find the characteristic of the task the strategy cannot handle, and swap to the strategy built for it.
| Documented failure | Mismatch | Replacement and justification |
|---|---|---|
| After several compactions the agent uses wrong totals from early batches | Compaction for a task that reuses exact earlier values | Structured notes, because exact values must persist without summarization |
| Agent restarts and repeats finished work | State held only in context | Persisted notes, because progress must survive the end of a session |
| Sub-agents keep re-asking for each other's results, handoffs lose detail | Parallel sub-agents for tightly sequential steps | One agent with compaction and notes, because each step depends on the last |
| One agent researching 40 independent vendors keeps hitting window limits | Single agent for independent breadth work | Parallel sub-agents, because branches share no context |
How the exam asks about this
- "The orchestrator's window saturates as sub-agents report back." Change sub-agents to return structured condensed summaries with decisions and open issues.
- "Two agents exchange large summaries at every step and details get lost." The boundary is too fine and cuts through coupled work; merge them.
- "A long task loses exact figures after repeated compaction." Replace with structured notes stored outside the window, because the task reuses exact values.
What to remember for the exam
- Sub-agents should return condensed structured results, not full traces or raw outputs.
- Keep decisions, assumptions and open issues in the return so the orchestrator stays coherent.
- Excessive handoff compression overhead means boundaries are too fine; runaway window growth means too coarse.
- Draw boundaries along the dependency structure: coupled work together, independent work apart.
- Compaction, structured notes and parallel sub-agents each fit a different dependency structure.
- Justify a replacement by the task characteristic the original strategy cannot handle.
A one line answer from each sub-agent cuts orchestrator load the most, but it drops the assumptions and decisions the orchestrator must reconcile. The exam asks for the change that reduces load without compromising coherence.
Common mistakes
Adding more agents to fix every context problem. Splitting tightly coupled work creates handoffs that must compress shared context, which loses detail.
Relying on compaction for exact values. Summaries keep meaning, not every number. When later steps reuse exact figures, write them to persistent notes instead.
Naming the replacement without the reason. These questions ask why the original strategy failed. The answer names the characteristic, such as tight step dependency or reuse of exact values, that the original strategy cannot support.
Check yourself
What sub-agent output change most reduces orchestrator load while keeping coherence?
Return a structured summary of findings, decisions, assumptions and open issues, with full detail stored elsewhere, instead of full traces or raw output.
Agents constantly summarize shared context for each other and lose details; what is wrong?
The boundary is too fine and cuts through work that needs the same context. Merge that work into one agent.
Why replace compaction with structured notes for a task that reuses early batch totals?
Compaction summaries can lose exact values, while notes stored outside the window keep them unchanged for later steps and across restarts.
Topic 2 of 2 in Multi-Agent and Long-Horizon Task Design
Test yourself on Multi-Agent and Long-Horizon Task Design
The full Databricks Context Engineer Associate question bank has 600 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Databricks. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.