Decision Architecture

Six weeks into an agent-assisted rewrite, a staff engineer sits down to draw the system’s architecture for a new hire and realizes she cannot cleanly explain why the service layer shards its cache the way it does. Nobody remembers deciding to shard by tenant rather than by resource type — it just showed up that way, in a session three weeks earlier, when an agent was fixing a slow endpoint and picked the sharding scheme that made the immediate fix work. The choice was reasonable on its own terms. It was also never proposed to anyone, never checked against the two other services already assuming resource-type sharding, and by the time anyone noticed, four more sessions had built on top of it.

Nothing about the fix itself was wrong. The endpoint got faster, the tests passed, the session ended cleanly and merged. What made it a problem was scale: reversing the sharding scheme now meant touching every session that had since depended on it, none of which had been told the choice was provisional. The team had not lost control of a bad decision. It had never established who was supposed to own a decision of that shape in the first place, so the answer defaulted to whichever actor happened to be in the editor when the question came up.

What got decided without anyone deciding to decide it

This is not a story about an agent behaving badly. Every individual step an agent takes inside a repository is small, locally reasonable, and usually correct on its own terms — which is exactly what makes the aggregate effect easy to miss until it is expensive to undo. DORA’s 2025 research on AI-assisted software delivery frames AI’s primary organizational effect as amplification: it magnifies whatever strengths and weaknesses a team already had, rather than introducing new ones of its own. A team with clear decision rights before adopting agents tends to keep them. A team where decision rights were already informal — resolved by whoever spoke last in standup, or simply never named — finds that informality amplified into something faster and considerably less visible: an agent that can produce a plausible, mergeable architectural artifact in less time than it takes a senior reviewer to finish reading the ticket that prompted it.

The industry caught up to a version of this problem in 2026, from two different directions. Forrester’s review of enterprise agentic AI deployments argues that policy documents alone cannot govern a system that invokes tools and takes actions between the moments anyone is watching — the firms managing this well treat governance as something enforced while the agent runs, with a named human accountable for each agent’s actions, rather than something written down once and revisited at a quarterly review. Singapore’s Infocomm Media Development Authority reached a related conclusion from the regulatory side in its Model AI Governance Framework for Agentic AI, published that January: organizations are asked to define, in advance, which checkpoints or action boundaries require a human to approve before an agent proceeds, rather than discovering the boundary after the agent has already crossed it. Both are pointing at the same missing layer — not what an agent is permitted to touch, which this Library’s Permission Architecture chapter already covers, but which category of decision a given actor is even in the room to make.

The bottleneck nobody built

Every organization already has an answer, whether or not anyone wrote it down, to the question of who decides what. Before agents, the answer was implicitly rationed by how long it took a human to produce a plausible proposal — a design doc, an RFC, an architecture sketch took long enough to write that the decisions requiring one naturally routed to whoever had the seniority and the calendar space to do that work carefully. Slowness was a de facto filter, and nobody had to design it; it came bundled with the medium. An agent collapses the medium. It can produce a plausible proposal, and often a plausible implementation of that proposal already sitting in a branch, faster than the person who should have been consulted can finish reading the prompt that started it. Speed was never meant to be the mechanism that allocated decision authority. It was a convenient, load-bearing accident of how slow proposal-writing used to be — and removing the slowness does not remove the accident’s grip on the org chart. It just hands the vacancy to whoever is fastest.

Decision altitude

Call the missing design axis decision altitude: how far up an organization a given category of decision needs to travel before someone commits the organization to it — set deliberately, rather than left to whichever actor happens to be fastest or most confident in the moment. Altitude is a function of two things that should sound familiar under other names from elsewhere in engineering practice. The first is reversibility, in the sense Amazon founder Jeff Bezos described in the company’s 2015 shareholder letter: some decisions are consequential and difficult or impossible to walk back once made — one-way doors — and deserve slow, deliberate, senior review; most decisions are cheaply reopened if wrong — two-way doors — and deserve fast resolution by whoever is closest to the work. The second is blast radius: how much of the system, and how many other decisions already resting on this one, would have to change if it turned out to be wrong. A choice that is both hard to reverse and wide in its blast radius — which database to standardize on, whether to accept a known security tradeoff for speed, whether to ship a breaking API change — sits at high altitude and belongs with a human sponsor, regardless of how quickly an agent could generate a plausible answer. A choice that is cheap to reverse and narrow in its blast radius — which of two equivalent approaches to take inside one file, what to name a variable, how to phrase a log message — sits at low altitude, and an agent operating inside its granted scope should be trusted to make it without waiting on anyone.

A tier structure, not a rank order

The table below names four altitudes by what is at stake if the call is wrong, not by who happens to be available. It is deliberately shaped like this Library’s Permission Architecture tiers, because the two axes are close cousins — one governs what an actor may touch, this one governs which actor is entitled to choose the direction in the first place.

Naming the altitude is only half the job; the other half is naming who actually holds authority at each one, and organizational-design literature had already worked this out before agentic coding existed. Paul Rogers and Marcia Blenko’s RAPID framework, published in Harvard Business Review in 2006 after a study of decision-making across dozens of companies, argues that most decision paralysis traces not to a lack of input but to an unclear answer to a narrower question: who, specifically, brings a decision to closure and commits the organization to it. RAPID assigns that role — Decide — to exactly one person, distinct from whoever recommends a course of action, whoever must agree before it proceeds, and whoever merely has useful input. The mapping onto altitude is direct. At low altitude, the same actor can recommend, decide, and perform in one motion, because the cost of a wrong call is small enough that collapsing the roles is the efficient choice. At high altitude, collapsing those roles into one fast actor — even a capable one — is exactly the failure this chapter opened with: an agent holding Recommend, Decide, and Perform simultaneously on a call nobody meant to hand it.

Not the same axis as the gate, the pause, or the trust score

Three chapters elsewhere in this Library already answer closely related questions at a different grain, and it is worth being precise about how decision altitude differs from each — the four axes are easy to blur into one vague sense of "how careful should we be." Permission Architecture, in Volume IV, tiers actions by risk — read versus write versus irreversible operation — and asks which of those a harness should auto-approve; it governs what an agent is allowed to touch once a direction has already been chosen. Checkpoint Thinking, in Volume V, asks how often a session should pause between plan steps and how to score confidence in a step already taken; it governs when to look at work in flight, not who was entitled to choose that work’s direction. Trust Calibration, in Volume VII, asks how much a specific piece of AI output deserves to be believed once it exists — trust it, spot-check it, or re-derive it. Decision altitude asks something upstream of all three: before any action is gated, any checkpoint is scored, or any diff is trusted, who was the right actor to be deciding this at all?

The permission architecture asks what an agent may touch. The checkpoint asks whether a step already taken still looks right. The trust score asks how much to believe a diff that already exists. Decision altitude asks the question underneath all three — who was supposed to be deciding this in the first place?

An organization can have an excellent permission architecture, a well-tuned checkpoint cadence, and a calibrated trust posture, and still let an agent make de facto architectural calls every week — because none of those three mechanisms was ever built to ask the altitude question. Each assumes the decision has already been routed to the right level and answers only how carefully to execute it once it is there. A 2026 study of oversight interfaces for autonomous agents, from a team at Microsoft Research, found current verification practices for agent actions "cumbersome" even when the human reviewing them was paying close attention and had the reasoning trace in front of them — a reminder that even a well-designed review step only works on decisions that were actually routed to a reviewer. A step nobody thought to route never reaches the interface built to check it, however good that interface is.

What a decision log would need to show

Naming altitude before code depends on it

1. Write down the four altitudes in your own words, for your own codebase, before the next session starts — a one-page list of which specific kinds of decisions belong at which level, not an abstract policy.
2. Name a Decider for the top tier, by name, the way RAPID insists on exactly one — a title on an org chart is not the same as a specific person who knows they are expected to be consulted before a breaking API change ships.
3. Treat "the agent picked an approach that later became load-bearing" as a near-miss worth a retro, the same way a team already treats a reverted production incident, even when the immediate fix worked.
4. Give agents explicit low-altitude latitude in writing. This is not only a restriction — a team that never names what an agent is trusted to decide alone ends up gating everything, which Volume IV already showed degrades into ceremony nobody reads.
5. Revisit the altitude map when it stops matching reality. A choice that looked tactical eighteen months ago — which caching library — can quietly become strategic once three services depend on its exact semantics, without anyone updating who owns it.

None of this requires slowing an agent down inside the altitude it has actually earned — naming the low tier explicitly is what lets it keep moving there at full speed, unreviewed, exactly as before. What decision altitude asks a team to give up is the comfortable assumption that speed and authority are the same thing, an assumption nobody stated out loud and every workflow quietly encoded anyway. The staff engineer redrawing her architecture diagram did not need her agent to move slower. She needed the sharding decision routed to someone before it was three sessions deep and load-bearing — which is a question about design, not about diligence.