The Tower and the Drone, Again
An air traffic control tower manages every aircraft in its airspace. Each pilot communicates with the tower. Each flight plan is filed and approved. Every decision — altitude, heading, runway assignment — flows through a defined authority structure.
Then a drone enters the airspace. It navigates by sensors and pre-programmed logic. It never calls the tower. It makes thousands of decisions per second without consulting a human. The tower has no authority over it — not because the drone is malicious, but because the governance framework was designed for piloted aircraft. The drone was never assigned a role in the system.
Most "AI-native team" redesigns are making the same mistake, one level up. They add a new title to the org chart — Agentic Engineer, AI Governance Lead — and treat that as the redesign. The title is the pilot. Nobody has built the tower.
The Redesign That Isn't a Redesign
Walk into most of these reorgs and the pattern repeats. A new title appears. Headcount shrinks, because that is the easy, visible, announceable change. What doesn't change is the thing that actually determines whether the new structure holds up under pressure: who owns the decision boundary when an agent's output crosses from "fine to ship" into "needs a human."
That gap shows up in three predictable places.
Code review becomes the bottleneck, because no one has actually decided which risk tier a given change belongs to — so everything gets the same scrutiny, or none. A title like "Agentic Engineer" exists on the chart, but no one owns designing the escalation path it's supposed to sit inside. And because agent-generated and human-generated work aren't distinguished by ownership, accountability spreads out at exactly the moment a production incident needs someone to own the fix.
The cost isn't subtle. The team ships faster in the demo and slower in production, because the velocity gained in generation gets lost to unowned review queues and after-the-fact blame-finding.
Three Questions Every Team Redesign Skips
Before any title gets assigned, three questions determine whether an AI-native team is actually governed or just relabeled.
Question 1: Who decides what an agent on this team is allowed to touch — and is that decision written down anywhere?
Not every workflow is a candidate for delegation. Some require judgment, legal accountability, or context an agent cannot possess. The question isn't whether the agent is capable. It's whether someone with the authority to say so has actually ruled on it, and recorded the answer.
Question 2: Who sets and revisits the autonomy tier once delegation is granted?
Being delegable isn't binary. A workflow can sit anywhere from fully autonomous execution to a human-gated recommendation. Someone has to own that tier, and — because trust and tooling both keep moving — someone has to own revisiting it.
Question 3: Who is the named human the moment an agent crosses its boundary — and do they know it's their job?
An agent will eventually make a call a human would have made differently, or hit a case its tier doesn't cover. When that happens, is there a person whose job it is to catch it — or does it just land wherever the on-call rotation happens to route it that week?
Most AI-native team redesigns have answered none of these. The drone is already in the airspace.
Applying AIDRA to Team Design
This isn't a call for a new framework. AIDRA already named the three boundaries that matter for an individual agent decision: Delegation Scope, Autonomy Class, and Escalation Protocol. What changes here is the unit of analysis — instead of asking who owns one agent's decision, the question becomes who owns that boundary for the team.
An AI-native team, in this framing, isn't a team with new titles. It's a team where each of AIDRA's three boundaries has a named human owner.
This also isn't happening in a vacuum. It sits directly on top of what Team Topologies already established about designing teams around clear ownership and interaction modes, rather than around a static org chart. AIDRA-for-teams narrows that lens onto one specific boundary Team Topologies wasn't built to name: who owns an AI decision, specifically, as opposed to a human one.
Role 1: Delegation Scope Owner
The Delegation Scope Owner decides what an agent on the team is authorized to touch, and where the line sits.
| Delegation Class | Definition | Who Rules |
|---|---|---|
| Delegable | The workflow can be authorized for agent execution under defined constraints | Delegation Scope Owner rules it in |
| Conditional | The workflow can be delegated only when specific safeguards are in place | Delegation Scope Owner rules it in, with named conditions |
| Non-Delegable | The workflow must always be resolved by a human on the team | Delegation Scope Owner rules it out |
This isn't about capability. An agent may be technically able to make a non-delegable call. The question the Delegation Scope Owner answers isn't can the agent do this — it's has the team actually authorized the agent to do this, in writing.
Role 2: Autonomy Class Owner
Where delegation is permitted, the Autonomy Class Owner sets how much freedom the agent has within that workflow — and revisits it as trust and tooling change.
| Autonomy Class | Definition | Owner's Job |
|---|---|---|
| Execute (A1) | Agent decides and acts without notification | Confirm audit logging is on; review the tier quarterly |
| Act-and-Report (A2) | Agent acts, logs the decision for review within a window | Define the review window; check the log is actually reviewed |
| Propose-and-Confirm (A3) | Agent proposes, a human confirms before it acts | Be — or name — the confirmer; make sure confirmation isn't a rubber stamp |
| Recommend (A4) | Agent recommends, a human decides separately | Own the decision; the agent's output is an input, not an answer |
The autonomy tier isn't a property of the agent. It's a property of the workflow, under current conditions — which is exactly why it needs an owner who revisits it, not a setting configured once at rollout and forgotten.
Role 3: Escalation Protocol Owner
The Escalation Protocol Owner is the named human the moment a threshold is breached, and the one who keeps the Agent Decision Log current once it is.
Pattern 1: Agent-to-Human Escalation
The agent reaches its autonomy boundary and needs to hand off. This requires a named target — a specific person, not "whoever is around." If no owner is named, the agent either stalls or acts outside its authority. Both are governance failures, and both are more expensive than naming the owner up front.
Pattern 2: Cross-Agent Conflict
Two agents on the same team — or on adjacent teams — produce incompatible outcomes. One approves a change; another flags the same change as a risk. Neither has authority over the other. The Escalation Protocol Owner is who both defer to, using either a priority rule (one domain's decision outranks the other by design) or an escalation to a shared human when priority rules don't resolve it.
The Team Ownership Matrix
| Workflow | Delegation Scope | Autonomy Class | Escalation Owner |
|---|---|---|---|
| Routine code review (low-risk, non-customer-facing) | Delegable | A1 — Execute | — |
| Customer-facing code review | Conditional | A3 — Propose + Confirm | Tech Lead |
| Incident triage (low severity) | Delegable | A2 — Act + Report | On-call Engineer |
| Incident triage (high severity) | Conditional | A3 — Propose + Confirm | Engineering Manager |
| Architecture pattern selection | Non-Delegable | A4 — Recommend | Staff Engineer |
Every cell names who's accountable, at what tier, before the workflow ever runs — not after something breaks and someone has to reconstruct who should have been watching.
How These Three Roles Work Together
flowchart TD
W[Workflow Proposed] --> D{Delegation Scope Owner}
D -- "Non-Delegable" --> H[Human Handles It\nNot Delegated]
D -- "Delegable / Conditional" --> A{Autonomy Class Owner}
A -- "A1: Execute" --> E1[Agent Acts\nAudit Log Only]
A -- "A2: Act + Report" --> E2[Agent Acts\nLogged, Reviewed Later]
A -- "A3: Propose + Confirm" --> E3[Agent Proposes\nHuman Confirms]
A -- "A4: Recommend" --> E4[Agent Recommends\nHuman Decides]
E1 --> C{Threshold Breached\nor Conflict?}
E2 --> C
E3 --> C
E4 --> C
C -- "No" --> G[Done\nLogged in ADL]
C -- "Yes" --> P{Escalation Protocol Owner}
P -- "Named Target" --> R[Owner Resolves It\nLogs the Outcome]
P -- "No Target Named" --> S[Stall or Unauthorized Action\nGovernance Failure]
R --> G
What Breaks When This Is Ignored
When a team runs agents without assigning these three roles:
Delegation happens by default rather than by design. An agent starts handling a workflow with no documented boundary, because nobody explicitly ruled it in or out. The team discovers the boundary was exceeded when the consequence arrives — not during rollout.
Autonomy expands without anyone noticing. Agents rarely start at full autonomy. Constraints loosen informally as trust grows. Without a named Autonomy Class Owner revisiting the tier, there's no baseline to measure the drift against — and no one whose job it was to catch it.
Escalations land wherever the rotation happens to route them. Without a named Escalation Protocol Owner, an agent's edge case becomes whoever's on call that week — someone with no context on the workflow, making a call under time pressure that should have had a name attached long before the pager went off.
Review becomes the bottleneck. Every change gets the same scrutiny, because nobody owns the call on which risk tier it belongs to. Reviewers either rubber-stamp everything or block everything — both are what happens when the tiering decision was never actually made.
When the three roles are assigned instead: delegation is decided before deployment, autonomy tiers are explicit and revisited on a cadence, escalations resolve through a named person instead of whoever's nearest, and review scales with risk instead of treating every change identically.
Implementation Guide (30–60 Days)
This doesn't require a reorg. It requires naming three responsibilities that already exist informally and making them explicit.
Phase 1: Map the Team's Delegation Inventory (Weeks 1–2)
Objective: List every workflow the team's agents currently touch, or are about to.
For each one: is it currently delegated, and to what degree? Was that decision made deliberately, or did it just happen? Document what's actually true today — not the target state.
Deliverable: A workflow inventory with current (informal or formal) delegation status for each.
Success Metric: At least three workflows identified where agent behavior has no documented authorization behind it.
Phase 2: Assign the Three Owners (Weeks 3–4)
Objective: For each workflow in the inventory, name a Delegation Scope Owner, an Autonomy Class Owner, and an Escalation Protocol Owner. On a small pod, the same person may hold more than one role — what matters is that each role has exactly one name attached, not zero.
Deliverable: The Team Ownership Matrix for the team's real workflows, filled in with names, not placeholders.
Success Metric: Every workflow in the inventory has all three roles named, and at least one workflow's actual behavior is flagged as inconsistent with its assigned tier.
Phase 3: Operationalize and Govern (Weeks 5–8)
Objective: Make the matrix a condition of shipping, not a document that gets filed away.
New workflows don't get agent access until they've been through Phase 1 and 2. Existing assignments get reviewed on the cadence the Autonomy Class Owner set. Escalations get logged, not just resolved — so the pattern is visible the next time the tier gets reviewed.
Deliverable: The ownership matrix embedded in how the team ships work, not a one-time exercise.
Success Metric: At least one escalation resolved through a named owner and logged, rather than absorbed informally by whoever happened to notice.
What This Looks Like in Practice
This pattern hasn't been run with a client yet under this exact name — so rather than invent a story, here's where pieces of it are already visible in how a handful of AI-forward engineering orgs operate publicly today, even where nobody is calling it AIDRA.
Small pods with end-to-end ownership. OpenAI's Codex organization runs lean: the Codex app itself has fewer than three core contributors, and Sora shipped from first code to public release in 28 days with a four-person team. The structural choice underneath that speed isn't more headcount — it's that ownership stays end-to-end inside a small pod instead of being spread across a large functional org. That's Delegation Scope and Autonomy Class ownership living inside the same small group that ships the work, not in a separate governance layer three teams away. (source)
Risk-tiered escalation, stated plainly. In an industry panel covering AI-forward teams at Browserbase and Fireworks AI, the operating rule was blunt: strict scrutiny for anything customer-facing and in the critical path, looser rules everywhere else — paired with an explicit accountability line: "it doesn't matter if you typed it or prompted it, you own it." That's an Escalation Protocol and an ownership rule stated out loud, even without the AIDRA vocabulary attached to it. (source)
Runbooks instead of heroics. Proposed AI-native operating models are also pushing teams toward documented, repeatable procedures — staged-rollout runbooks, incident response for AI-specific failures — and pairing ML engineers directly with SREs for joint production ownership, closing the handoff gap between "built it" and "runs it." That's the Escalation Protocol Owner's Agent Decision Log responsibility, distributed across a documented process rather than one person's memory. (source)
None of these organizations describe what they're doing in AIDRA's terms. But the pattern underneath all three is the same one: the teams that are actually working aren't the ones with the most new titles. They're the ones where nobody can point to a decision boundary and ask, "wait, whose call was that?"
Action Plan
This Week
Ask three questions about the agents your team already runs:
- For every workflow an agent touches, is there a documented answer for who authorized the delegation and at what tier?
- If two agents on your team — or on adjacent teams — produced conflicting outcomes tomorrow, is there a named person both would defer to?
- Who is the Escalation Protocol Owner for your highest-risk delegated workflow — and do they know it's their job?
If the third question produces silence, the drone is already in your airspace.
Next 30 Days
Pick the three workflows with the highest consequence if the agent gets it wrong. For each, name the Delegation Scope Owner, the Autonomy Class Owner, and the Escalation Protocol Owner. Write the assignments down somewhere the team actually looks — not a slide that gets filed after the meeting.
3–6 Months
Extend the matrix to every workflow the team delegates to an agent. Make a completed ownership assignment a condition of any new agent workflow entering production. Review the matrix on the same cadence as the rest of your architecture governance — not as a separate, easily-skipped exercise.
Final Thought
The tower could not see the drone. Not because the drone was invisible — because the governance framework was designed for aircraft that communicated with the tower.
Most AI-native team redesigns have the same blind spot. They assign titles to people. They don't assign ownership to boundaries.
Autonomy Class will keep shifting — agents will keep earning more scope as trust and tooling mature. The instinct in a lot of organizations is to treat that as a reason to redraw the org chart every time it happens.
It isn't. The org chart is not what needs revisiting on that cadence. The boundary ownership is.
Name the three owners once — Delegation Scope, Autonomy Class, Escalation Protocol — and the team can absorb a more capable agent without a reorg. What can't absorb that shift is a team that never named the owners in the first place, no matter how many new titles it hands out trying to compensate.
Name the Owners Before the Next Agent Ships
If your team is running agents without a documented answer to who owns delegation, who owns the autonomy tier, and who owns escalation — that's not a hiring problem. It's three unassigned boundaries waiting to surface as an incident.
or
The drone is already in the airspace. The question is whether your team's decision rights know it's there.
