Agent Boundary Placement: Diagnosing Over-Split and Under-Split Designs

1.Two symptoms, two opposite boundary errors

In this objective, someone has already decided where the agent boundaries go, and the system is now misbehaving. You won't be asked to design the system from scratch. You'll be asked to read the symptom and name the placement error behind it. There are two symptoms to recognise, and they point in opposite directions. In the first, the system spends too much of its effort on handoffs: agents keep summarising work for each other, details get lost along the way, and the next agent has to ask again or redo the work. In the second, one agent's context window keeps growing until it is hard to manage, and that agent's decisions get worse as it grows.

Databricks describes agent design as a continuum that runs from deterministic chains, through single-agent systems, to multi-agent architectures, and its advice is to start simple and add agentic complexity only when you truly need it. That advice is also the diagnostic tool. A boundary is worth its cost when the work on each side needs a genuinely different context. Where that isn't true, the boundary just adds a handoff. Where it is true and no boundary was drawn, one agent ends up holding everything. A coordinating layer such as Supervisor Agent manages delegation and then combines what comes back. That combining step is where handoffs are compressed, so every additional subagent adds another place where compression happens.

Sources12

2.Under-split: one agent carrying several domains' context

Start with context growth. If one agent owns a large or cross-functional scope, everything that scope needs lands in its context window: tool definitions for every domain, instructions for every domain, and every tool result from every domain. The Databricks design-patterns page names this limit of the single-agent pattern directly. When an application spans radically different sub-domains, such as finance, devops and marketing, a single agent can become unwieldy or overloaded with functionality requirements. The Databricks blog on supervisor architecture describes the same failure from experience in production. An agent with too many tools makes poor decisions about which one to call next, and its context grows too complex for a single agent to keep track of.

So the diagnostic signature of an under-split boundary looks like this: one agent's prompt grows with unrelated tools and instructions; its transcript fills with results from domains that have nothing to do with each other; and its tool choices degrade as its scope widens. The other agents may be fine. The failure sits inside one boundary that encloses too much. The fix moves in one direction, toward a split along the line where the context changes, so that each resulting agent holds the context of one coherent area.

Sources13

3.Over-split: handoffs cut through a cohesive task

Now the opposite failure. In the Databricks Apps orchestrator pattern, the orchestrator treats each subagent as a tool and routes requests to it. Whatever the subagent learned while working stays on its side of the boundary, and only its result comes back. That is exactly what you want when the subagent's working context is irrelevant to everyone else. It becomes a problem when the boundary falls between steps that depend on the same details. The downstream agent then gets a compressed summary of information it actually needed in full. It has to ask again, guess, or redo the work, and the system spends its token and latency budget writing and re-expanding handoffs.

Two clues from the Databricks material help you spot this. First, the single-agent pattern is presented as the right fit when queries vary but stay within a cohesive domain or product area. Variety on its own does not justify a split. Second, the concepts page separates tools from agents. Tools perform one well-defined operation and are generally stateless, while agents keep state as they work through open-ended tasks. A 'subagent' that only ever does one well-defined operation is really a tool behind an agent boundary. It adds a reasoning loop and a handoff and gives nothing back for them.

Sources451

4.Finding the faulty boundary in a trace

You don't have to diagnose from symptoms alone. MLflow Tracing on Databricks records multi-agent runs with per-agent detail. For frameworks such as AG2 it captures the messages passed between agents, along with each agent's LLM and tool calls, organised by agent and by turn. MLflow 3.2.0+ also records token usage per call on spans. Together these let you find where the tokens are going. Note that the trace only shows you where. It doesn't name the failure. Deciding which way the boundary should move is the reasoning you do after reading it.

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

Read the numbers in two directions. If one agent's input tokens climb turn after turn, and its tool calls cover unrelated domains, the boundary around it is too wide. If the agents stay small but much of the total goes into messages passed between them, with the same facts restated across several handoffs, the boundaries are too narrow.

Sources6

Exam traps

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

1. 1.Adding more specialised agents always reduces context and handoff problems.Why is that wrong?

   Every added agent brings orchestration cost and another handoff. When handoff overhead is the symptom, more agents make it worse.

   Covered in Two symptoms, two opposite boundary errors

2. 2.Every distinct operation in a workflow deserves its own subagent.Why is that wrong?

   Single well-defined operations are tools. Agents earn their boundary by handling open-ended, stateful work, and a single-operation subagent only adds a handoff.

   Covered in Over-split: handoffs cut through a cohesive task

3. 3.A wide variety of user queries means the system needs many agents.Why is that wrong?

   Varied queries within one cohesive domain are the single-agent sweet spot. The case for splitting is radically different sub-domains, not variety.

   Covered in Over-split: handoffs cut through a cohesive task