Autonomy
Delegation boundary
Definition
A delegation boundary is the explicit line between what an AI system may decide on its own and what it must hand back to a person, expressed in actions and value limits rather than in intent.
Autonomy is a delegation problem before it is a technology problem. Every deployment sets a boundary whether or not anyone writes it down; the only choice is whether it is designed or accidental. An implicit boundary is discovered during an incident, which is the most expensive possible time to learn where it was. A designed boundary, by contrast, can be reviewed, tested, and defended to a regulator before anything goes wrong.
Boundaries are made of verbs and numbers
"Use good judgment" is not a boundary. "May close a claim under $2,500 with two matching data sources, must escalate anything with injury coding" is. The test of a real boundary is that two reviewers reading it would classify the same case the same way, without needing to ask the system's designer what was meant. Vague boundaries feel flexible in the design meeting and become a liability the first time an auditor, a regulator, or a plaintiff's lawyer asks exactly what the system was and was not allowed to do, and the honest answer is that nobody wrote it down precisely enough to say.
Connectors move the boundary quietly
Every integration granted to an agent widens what it can reach, often without anyone re-examining the original delegation decision. A connector added for convenience — access to a payment system, a policy administration platform, an email account — can extend authority into systems nobody re-reviewed, which is why connector inventory belongs in the same governance record as the agent itself. Treat each new connection as a fresh delegation decision, not a technical footnote, because the boundary you approved for the original scope no longer describes what the system can actually do once the connector is live.
Testing the boundary before it is tested for you
A boundary that has never been probed is a boundary you are trusting rather than one you have verified. Run adversarial and edge cases against it deliberately — the claim just under the threshold, the submission missing one data source, the request that looks routine but sits one field away from an escalation trigger — and confirm the system routes them the way the written rule intends. This is cheap to do before launch and expensive to skip, because the first real test of an unverified boundary is usually a case that reaches a customer, a regulator, or a headline before it reaches a reviewer.
In practice
- Express limits as action + threshold + required evidence
- Re-review the boundary whenever a new tool or connector is granted
- Track escalation rate: a boundary nobody hits is probably drawn too wide
- Test the boundary with adversarial and edge cases before launch, not after an incident
