The wrong kind of control
An agent receives a goal, followed by a prescribed plan, a preferred tool sequence, instructions for reasoning, and approval checkpoints at every turn. The team has delegated execution while retaining every meaningful decision. It should not be surprised when the result behaves like a brittle workflow.
There are good reasons to prescribe a workflow. Some operations demand a fixed order. Some decisions should never be delegated. The mistake is assuming that more instructions always produce more control. Instructions can make the execution path narrower while leaving authority, cost, and failure handling poorly defined.
Boundary-Driven Autonomy is the agentic engineering framework I use to place human judgment at the boundary-design layer. Specify the outcome and the operating envelope, then let the agent choose a path inside it. Define the boundaries. Don't dictate the path.
An objective is not a route
An objective describes a change in the world. A route describes how to get there. Keeping those separate matters when an agent encounters evidence that the original route no longer makes sense.
Consider a maintenance task: resolve a checkout defect without changing the payment contract. Success could require reproducing the failure, preserving the contract, passing relevant checks, and showing the corrected behavior. Those are obligations. They do not require the engineer to predict every file the agent will inspect or every hypothesis it should test.
The distinction has a limit. A required approval, migration sequence, or security check is not an optional suggestion about the path. It is part of the contract. Autonomy begins after those obligations are made explicit.
Design an operating envelope
Start with the objective and context: what outcome matters, what the agent can rely on, what is uncertain, and which source wins when documents disagree. A vague objective with a large context window is still a vague objective.
Define authority next. Name the resources it may read, the state it may change, and the actions it must never take. Separate reversible local work from external commitments. An agent that can prepare a deployment does not automatically have permission to release it.
Then bound consumption and completion. Set time, token, spend, retry, and tool-call limits where they matter. Define what counts as success, what evidence must accompany the result, and what happens when the budget is exhausted. A stopping rule is an architectural feature.
Autonomy zones must be enforced
I think of an autonomy zone as a set of decisions the system is authorized to make without returning to a person. Its boundary is about consequence, not the number of steps in a plan.
Reading source code and testing a hypothesis might belong in one zone. Changing production data might require a narrower capability and an approval. Contacting a customer might be outside the agent's authority entirely. These zones need credentials, tool interfaces, policy checks, and runtime limits that enforce the distinction.
A sentence in a prompt does not revoke a permission. If a tool can perform an irreversible action, the surrounding system must decide whether to expose that capability and under what conditions. Good instructions support the boundary; they are not the whole boundary.
Completion needs evidence
A tool returning successfully is evidence about a tool call. It is not necessarily evidence that the user's objective was achieved. A file can be written to the wrong location. A release can build without reaching the intended domain. A message can be accepted by a provider without reaching its recipient.
Success conditions should identify the observable result and an appropriate way to verify it. Prefer checks that can disagree with the agent's conclusion: a contract test, a read of the resulting state, a delivery event, or an independent evaluation. Repeating the agent's own summary is not independent validation.
Verification also has a budget. The aim is enough evidence for the consequence of the action, not an endless ritual of rechecking already established facts.
Human judgment belongs at consequential boundaries
Escalate when the objective becomes ambiguous, required evidence is unavailable, the agent needs new authority, or a proposed action exceeds the agreed risk. The person receiving that escalation needs the relevant evidence, the unresolved decision, and a concrete option to assess.
Human-in-the-loop design should give a person a meaningful decision. Asking someone to approve every intermediate action can consume attention without improving control. At the other extreme, hiding a consequential choice inside a long autonomous run removes judgment precisely where it matters.
When a safe operating envelope cannot be defined, do not use open-ended autonomy. Use a deterministic workflow, a narrower task, or direct human execution. BDA is a way to decide where autonomy is justified, not a requirement to maximize it.
How BDA relates to LSAS
BDA asks what an agent is allowed to decide and what it must demonstrate. LSAS addresses the treatment of AI outputs through risk classification, grounding, validation, escalation, and learning. An agent can have freedom to choose its route while its outputs still have to pass an explicit release boundary.
Bounded delegation, least privilege, and feedback control are established ideas. My contribution here is a particular engineering formulation for agentic work: put the judgment into objectives, authority, budgets, and validation rather than encoding every move.
The practical test is simple. If the agent discovers a better route, can it take that route without violating the contract? If the answer is no because every move has already been dictated, examine whether the task needs an agent at all.
More questions. Better conversations.
Bring this perspective to your event