// NOTE · destination-and-boundaries

If the destination and boundaries are known, the system should be able to drive.

Autonomy isn't giving an agent unlimited freedom. It's giving it enough context, authority, and boundaries that it doesn't need to ask at every step.

Think about the most autonomous person you’ve worked with — not the one who does whatever they want, but the one you’d actually call autonomous in a good sense. They don’t ask what to do at every step, and they don’t go rogue. What they have is specific: they understand the goal, know where their authority ends, know which calls are theirs alone, and know when to walk over and ask. Take any one of those away and the whole thing breaks. Lose the goal and they optimize for the wrong thing. Lose the boundaries and “autonomous” starts meaning “unsupervised.” Lose the judgment about when to escalate and you get someone who either bothers you constantly or blows through a limit they should have flagged.

That combination — not freedom, not obedience, but a working understanding of destination, boundaries, and when to ask — is what I mean when I say a person is autonomous at work. It’s also the only definition of autonomy I’ve found that transfers cleanly to a software agent.

Autonomy isn’t the absence of structure

There’s a version of “autonomy” that means “no rules” — the “just let it figure it out” version. It has never actually described how autonomous people work. Organizational research studies autonomy at work as discretion within a job — over scheduling, decisions, method — not as the absence of a job [S1]. Deci and Ryan’s self-determination theory puts autonomy alongside competence and relatedness as a basic psychological need [S2]: it matters to people, not that removing structure is what satisfies it. An autonomous employee still has a manager, a scope, consequences — the autonomy is in the discretion, not the absence of a frame.

Here’s the thesis, in the form I actually use it:

Autonomy isn’t giving an agent unlimited freedom. It’s giving it enough context, authority, and boundaries that it doesn’t need to ask you what to do at every step. If the destination and boundaries are known, the system should be able to drive.

That’s not a permission slip for less oversight. It’s closer to a job description — and like any job description, most of the work is in what it presupposes.

“Known” is a claim you have to earn

Notice the conditional: if the destination and boundaries are known. That word is doing more work than it looks like. A destination isn’t known just because someone typed a sentence describing it — it’s known when you can check whether you got there. A boundary isn’t known just because someone believes it exists — it’s known when it’s written down, checked, and can actually stop the system when it’s approached.

This isn’t a problem software introduced. Herbert Simon’s work on bounded rationality made the point about people decades before agents were a design question: decision-makers operate with limited information and cognitive capacity, reaching for a workable answer, not a provably optimal one [S10]. The person setting the boundaries is bounded too — they can’t enumerate every exception, every unwritten rule living in someone’s head and nowhere else. So “the destination and boundaries are known” is a claim you verify, not a premise you’re entitled to assume. Skip that step and the thesis stops arguing for delegation and starts excusing skipped specification work.

Permission is not the same as power

Giving someone a title doesn’t mean they can get the job done. Aghion and Tirole formalized this distinction in organizations thirty years ago: formal authority is the right to decide; real authority is the effective control over the decision — and the two routinely diverge [S3]. You can hand someone a role and still not give them what they need to exercise it: the information, the standing, the tools.

The same gap shows up the moment you hand an agent a permission it can’t use. It has the config-file right to act and none of the means to finish — the data, the credential, the context — and the result isn’t autonomy, it’s a bottleneck with an authorization label on it [S3, S4]. A person delegated to but starved of information isn’t autonomous either; they’re stuck, and eventually they stall or improvise badly. The fix in both cases is the same: don’t just grant the right to decide — make sure the capacity to decide is actually there.

Knowing when to ask is the whole skill

The part of this easiest to get wrong is the escalation instinct. An autonomous person on a team doesn’t ask about everything, and doesn’t go silent about everything either — they’ve built a working sense of which decisions are theirs and which need another person’s judgment. Psychological safety research found that teams where people feel able to flag a problem or admit uncertainty report and surface more of what’s actually going on [S9]. The mechanism is specifically about the cost of speaking up — which is exactly where the parallel to a software agent breaks.

An agent isn’t worried about how a mistake will look. It doesn’t need to feel safe to admit uncertainty — it needs to be built so surfacing uncertainty is just what happens, structurally, when the situation calls for it, with no cost attached to being right about needing help. That’s a design problem, not a culture problem. But the shape — knowing which decisions are yours, which aren’t, and building a path to hand off the second kind without penalty — is the same whether the “who” is a person or a system.

Where the philosophy meets the workflow

I didn’t want to open this account with tooling, so I’ve kept this post to the thesis. But the reason the thesis matters to me isn’t abstract — it’s what I’m actually trying to build.

In practice, that means treating human gates as exception management, not a rubber stamp on every step. A gate earns its cost where a person’s judgment would change the outcome — a real conflict, an unwritten constraint, a consequence you can’t undo — not on routine work the system has already shown it can do. It means each unit of work maps to a single accountable executor, so it’s always clear who — or what — was driving when a decision got made. It means authority expands the way trust does between people: from evidence, per domain, not a good week. And it means anything that can’t be walked back — deletions, external actions, consequences outside the system — gets a higher bar than everything else, regardless of how well the system has been performing.

None of that is exotic. It’s just taking the same conditions that make a person trustworthy with autonomy — a known destination, real boundaries, and a working sense of when to ask — and refusing to skip them because the thing doing the driving is software instead of a person.

The destination and boundaries are known. The system should be able to drive. Getting to say that honestly is most of the job.

Sources

Leer en español — Lee la versión en español.