Designing for Bounded Autonomy
A new leadership design challenge for organisations when rethinking how authority flows.
Delegation has never been easy. It requires judgement, trust, and an acceptance that someone else may approach a task differently. Good leaders don’t simply hand work away - they think carefully about what should be delegated, to whom, under what constraints, and when they want to be involved again. Over time, people earn greater responsibility as they demonstrate competence, judgement, and reliability.
Oddly enough, much of that thinking and staging seems to disappear when the recipient isn’t another person, but an AI.
Tasks that we’d hesitate to hand to a new employee are routinely handed to AI assistants with little more than a well-crafted prompt. Draft the strategy, analyse the data, review the contract, respond to the customer, or make the recommendation. Limited context and only minor rework.
A new graduate might spend months earning greater responsibility, and yet we hand an AI assistant the same power in a day.
Perhaps that’s because organisations don’t yet have the mechanisms. We know how to observe a graduate, coach them, expand their responsibilities and reduce them again when necessary. We don’t yet have equivalent operating models for AI. Those skills could form part of the next generation of management systems.
We’ve started treating AI as a technology problem when it’s equally a management problem. The challenge we face is re-designing our preconceived notions of delegation, with new tests for effectiveness.
Autonomy Is a Delegation Problem, Not a Technology One
Many conversations around agentic AI treat autonomy as though it’s a property of the technology. As models become more capable, the assumption goes, they become more autonomous - as if greater capability naturally earns greater authority.
But autonomy isn’t the ability to act independently. It’s the authority to make decisions on someone else’s behalf. And authority doesn’t originate with the AI - it originates with the organisation. Every workflow an agent executes, every customer it interacts with, every decision it can make has been deliberately entrusted to it by someone. That’s exactly how organisations have always delegated work to people, too: not by defining an outcome, but by defining boundaries. What decisions can be made independently? What budget can be approved? When should someone ask for help? What falls outside their authority?
Good delegation has never meant removing control. It has meant deciding where control should sit. If that’s true for people, it’s not obvious why AI should require an entirely different set of principles - which raises the real question: how do you design good delegation when one of your colleagues isn’t human?
Designing Delegation, Not Just Capability
Organisations have already solved a version of this challenge. Every day, managers decide which decisions they should make themselves, which can be delegated, and which still need another level of approval. Those decisions are rarely written down as grand theories - they’re embedded in job descriptions, approval limits, governance processes, budgets, team norms, and years of accumulated organisational experience.
Discussions about agentic AI tend to start somewhere else entirely: how capable is the model, can it complete this workflow, could it operate without human intervention? Sensible questions - but arguably the wrong place to begin, because capability and authority aren’t the same thing.
An AI might be perfectly capable of reviewing a contract, approving an invoice, or drafting a board paper. That doesn’t automatically mean it should. Organisations have never treated capability as the sole criterion for delegation - accountability, organisational risk, regulatory obligation, and the consequences of getting something wrong all factor in too. Once the question shifts from how much autonomy is this agent technically capable of to how much authority are we comfortable delegating in the first place, the technology becomes much easier to reason about. The model, the workflow, the prompts and the guardrails all follow from a decision that was fundamentally organisational, not technical.
Why Organisations Deliberately Bound Autonomy
Authority isn’t distributed evenly across an organisation. Some decisions are pushed to the edge, where speed matters most. Others stay centralised because they shape strategy, involve significant financial commitment, or carry legal and ethical consequences. Many sit somewhere in between, combining local judgement with periodic oversight - a healthy dose of organisational design as much as governance.
A customer service team needs the freedom to resolve problems quickly. A finance function may optimise for control and auditability. Product development often benefits from experimentation and distributed decision-making, while safety-critical engineering deliberately introduces additional review and challenge. Organisations don’t delegate authority according to what people are capable of doing - they delegate according to what helps the whole system perform effectively. Perhaps AI should be no different.
Where the human/AI analogy strains
People and AI fail in different ways, and those differences matter for how much of this analogy actually holds. A human employee who oversteps their authority can be asked why, and their answer becomes part of the evidence used to recalibrate trust. An AI system that produces a confident but fabricated figure, or that behaves inconsistently between two functionally identical requests, doesn’t have a “why” in the same sense - there’s no judgement to interrogate, only a pattern to audit. That changes what oversight has to look for. With a person, you’re mostly watching for bad judgement under pressure. With an AI, you’re also watching for a different failure mode entirely: confident, fluent error with no internal signal that anything went wrong.
There’s also the question of accountability. When a person exceeds their authority, the organisation has someone to hold responsible, coach, or in the last resort remove. When an AI does the same, accountability doesn’t transfer to the system - it stays with whoever configured its authority in the first place. That’s not a reason to abandon the delegation framing. If anything, it’s a reason to take it more seriously: the discipline of bounding authority matters more with AI, not less, precisely because the AI itself can’t be held to account the way a person can. But it does mean the analogy is a starting point for design, not a literal equivalence - and any operating model built on it needs to build in more auditing and less reliance on “asking what happened” than the human version would.
How to Start Creating Authority-by-Design
Imagine introducing a capable new colleague to your team - someone who learns fast, works at remarkable speed, and is happy to take on almost any task you give them. Before handing over meaningful responsibility, what would you want to establish?
The first question isn’t what can they do? It’s what should they be doing? Just because an agent can draft strategy documents doesn’t mean that’s the best use of it - delegation begins with the scope of the work, not the capability of the worker.
Next comes authority itself. A capable colleague doesn’t automatically gain the right to approve expenditure, sign contracts, or make commitments on the organisation’s behalf. Those rights are delegated deliberately, and recommending a course of action is very different from executing it.
Then come the boundaries: policies, budgets, regulations, ethical expectations, and organisational norms. The aim isn’t to constrain initiative, but to make good judgement easier and poor judgement harder. Good delegation also makes clear when someone should stop and ask for help - novel situations, uncertainty, conflicting evidence, or unusually high stakes should trigger a conversation rather than an independent decision. Escalation isn’t a sign delegation has failed. It’s part of good delegation.
A practical place to start is an audit, not a policy. Before designing any new framework, list every place AI is currently making a judgement call inside your organisation without anyone having explicitly decided it should - the summary that gets sent without review, the draft that goes out with only a glance, the analysis that quietly becomes the basis for a decision. Most of what you find won’t have been delegated at all. It will have drifted there, one convenient shortcut at a time. That list is the real starting point for authority-by-design, because it shows you where authority already sits, rather than where you assumed you’d placed it.
Authority Should Move in Both Directions
Most of the conversation about AI and trust focuses on how authority expands - an assistant proves reliable, so it’s given a wider brief. Less attention goes to the reverse: how authority contracts when something goes wrong.
With people, this is second nature. A manager who spots a lapse in judgement doesn’t need a formal process to quietly narrow what someone is trusted with while confidence is rebuilt. We don’t yet have an equivalent instinct for AI. Today, when an AI system makes a poor call, the typical response is a prompt tweak or a one-off correction, rather than a genuine reduction in scope - the system is rarely the problem, we’re often the ones adjusting it.
To my knowledge there isn’t yet a well-documented example of an organisation systematically revoking or narrowing an AI’s delegated authority the way it would with a person - probationary tightening, a formal review that reduces scope, a graduated path back to full trust after an incident. This piece isn’t claiming that model exists yet. It’s aspirational: the same discipline organisations apply when a person’s judgement is in question - narrow the brief, increase the checkpoints, rebuild the evidence - is the discipline AI delegation will eventually need too. Building that muscle now, before an incident forces the issue, seems like better practice than reaching for it only after something has gone wrong.
The Best Organisations Are Becoming More Deliberate, Not More Autonomous
This pattern already shows up in a handful of the most closely watched enterprise deployments, even if none of them frame it explicitly as “authority design.” Read on to learn more.
