Bounded Autonomy: Defining What an Agent Can Decide

The central design decision in deploying an AI agent is not what it can do, but what it is allowed to decide on its own. An agent with agency will pursue its goal across systems, taking actions and making choices; the question that determines whether that is an asset or a liability is where the boundary sits between what the agent may do alone and what requires a human. Getting that boundary right — bounded autonomy — is the difference between an agent that is genuinely useful and one that is a standing risk.

Why “let it run” and “check everything” both fail

Two instincts dominate early agent deployments, and both are wrong. The first is to give the agent broad latitude because that is what makes it powerful — which produces an actor with standing permissions and no meaningful checkpoints, exactly the profile that turns a mistake or a compromise into a serious incident. The second, in reaction, is to require human confirmation for everything — which removes the point of the agent, since a human is back in the loop for every step. Neither is a real answer. The useful design is deliberate about which decisions the agent owns and which it escalates, based on the consequences of getting them wrong.

Drawing the boundary by consequence

The principle that works is to scope autonomy by the reversibility and impact of the decision.

• Let the agent own low-consequence, reversible actions. Reading, drafting, retrieving, proposing — things that are easily undone or reviewed cost little to delegate fully and capture most of the value.
• Require a human for high-consequence or irreversible actions. Moving money, deleting data, sending external commitments, taking actions that cannot be cleanly undone — these are where a checkpoint earns its cost.
• Define hard limits the agent cannot cross regardless. Some actions should be outside the agent’s reach entirely, enforced by the systems around it, not by the agent’s own judgement.
• Make the boundary explicit and enforced. Bounded autonomy is only real if the limits are implemented in the agent’s permissions and the surrounding controls — not written in a design doc the agent has no knowledge of.

Why this is a governance decision

The reason bounded autonomy belongs at governance level, not just engineering, is that the boundary encodes the organisation’s risk appetite. Deciding what an agent may do alone is deciding how much consequence the firm will let an autonomous system carry without a human — which is a decision about accountability, not just capability. The firms that deploy agents well make that decision deliberately, scope permissions to match it, and can point to a named owner for each agent’s boundary. The ones that do not discover their risk appetite after the fact, when an agent does something nobody decided it should be allowed to do.

Who this is for

This reading is for:

• CTOs and architects deploying autonomous agents into workflows
• Boards worried about what agents can do without a human
• Risk leads designing guardrails for agentic AI
• Product teams building agents into customer-facing processes

Sixteen Pillars helps you scope agent autonomy by reversibility and impact, enforce the boundary in permissions and controls, and put a named owner behind it. Pricing is published at /pricing/. If this is live for your organisation and you would like an independent reading, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.