Bounded Autonomy: How to control AI agents

Full AI autonomy looks great on a slide. In production, someone ends up putting out fires. Success with AI comes down to the balance between freedom and control. I call it Bounded Autonomy.

What is Bounded Autonomy?

Bounded Autonomy is a framework built on the principles of the NIST AI Risk Management Framework. An AI agent gets clearly drawn boundaries. Inside them it has full freedom. Outside them it stops and hands the case to a human (human-in-the-loop).

It's like giving your teenage son the car keys. You tell him: "You can drive around town, but not on the highway. Be home before 10."

The 4 pillars of Bounded Autonomy

An audit trail only means something when every quiet retry and fallback leaves a countable trace. Otherwise the logs show nothing but successes. I wrote about silent failures separately.

Operational Limits in practice

Example for a customer service agent:

Escalation Matrix

Not all escalations are equal. Build a matrix:

• Level 1 (Soft Escalation): The agent keeps going but flags it for review later
• Level 2 (Human Review): The agent waits for approval before it acts
• Level 3 (Full Handoff): A human takes over completely
• Level 4 (Emergency Stop): The agent is halted and an incident is reported

Level 3 ends with the handoff, but it says nothing about what the human does with the case next. That division of work is what the four hybrid patterns describe, from a full handoff to AI that only suggests.

"Bounded Autonomy builds trust, and trust is what lets you scale. Give an agent clear boundaries and you can give it more freedom. You know it won't step over the line."

Governance Agents

The most advanced companies take it a step further. They run AI agents that watch other agents. A Governance Agent checks:

• • Are decisions aligned with company policy?
• • Are there any anomalies in behavior?
• • Is performance degrading?
• • Are escalations being handled on time?

Agents watching agents are the technical layer. I covered the organizational one, meaning a system inventory, risk classification and clear ownership, under AI governance.

Bounded, constrained, controlled or governed autonomy: how they differ

The industry uses these names interchangeably. Nobody has standardised them. Below is the split I use with clients, built on the mechanisms described above.

• Bounded autonomy: the boundaries sit inside the agent itself. The agent knows what it must not do, and decides freely within that. You design this one agent at a time.
• Constrained autonomy: the restriction acts on the action space and gets checked at every decision, which puts it closer to a rule in code than to a line in a policy. You reach for it when an agent must not be able to take a given action even by mistake.
• Governed autonomy: the Governance Agents from the previous section, at organisation scale. Policies, an owner, audit, reporting. It covers the whole fleet.
• Controlled autonomy: the honest answer here is "nothing specific". The phrase circulates in vendor material and nobody has defined it apart from the two above. When you hear it, ask which mechanism they mean.

The practical difference is simple. You design bounded one agent at a time, you roll governed out once for all of them. Companies that start from governance end up with finished policies and zero agents in production.

AI autonomy controls is the umbrella name for the four pillars from the start of this post. An allowed-actions list, escalation triggers, an audit log and a kill switch. When somebody asks about control over an agent, this is what they are asking about.

That leaves bounded automation. The industry never settled that term, people type it anyway, so let us be blunt: automation runs a fixed flow and chooses nothing. An agent chooses an action inside the limits you drew. If your process chooses nothing, this framework gives you nothing. You need a good workflow.

Implementation: step by step

1. 1. List every action the agent can take
2. 2. For each action, decide: auto, review, or forbidden
3. 3. Define escalation triggers (value, risk, sentiment)
4. 4. Build an audit log for every decision
5. 5. Test the edge-case scenarios
6. 6. Set up alerting for anomalies