The Tower and the Drone

An air traffic control tower manages every aircraft in its airspace.

Each pilot communicates with the tower. Each flight plan is filed and approved. Each handoff between airspace sectors is coordinated. Every decision — altitude, heading, landing sequence, runway assignment — flows through a defined authority structure.

The system works because the decision rights are legible.

Now a drone enters the airspace.

The drone flies autonomously. It navigates by sensors and pre-programmed logic. It does not call the tower. It does not file a flight plan. It makes thousands of navigation decisions per second without consulting any human.

The tower has no authority over it.

Not because the drone is malicious.

Because the airspace governance framework was designed for piloted aircraft. The drone was never assigned a role in the decision rights architecture. It simply entered — capable, autonomous, and structurally invisible to the system designed to govern the air.

This is what happens when AI agents operate in your enterprise.

Your decision rights architecture was designed for humans. Architects decide. Engineers implement. Boards approve. Governance reviews.

Then an agent enters.

It routes traffic. It selects integration patterns. It triages incidents. It approves transactions. It resolves ambiguous schemas by choosing one outcome over another.

It decides things.

And no cell in your decision rights matrix has its name on it.

Decision Rights Assume Human Actors

Decision rights models assign authority to people.

Enterprise architects decide platform standards. Domain architects decide integration contracts. Engineering leads decide implementation approaches.

It works well when the decision-maker is a person.

It does not work when the decision-maker is an agent operating at runtime — because the agent's authority was never assigned, never recorded, and never bounded.

The decision rights model has a silent dimension it was never designed to map.

The Three Questions Every Enterprise Must Answer

When AI agents make decisions autonomously, three questions determine whether those decisions are governed or rogue.

Question 1: Which decisions can be delegated to an agent at all?

Not every decision class is delegable. Some require human judgment, legal accountability, or contextual awareness that an agent cannot possess. The first question is: for each decision class in your enterprise, is delegation permitted?

Question 2: What autonomy level does the agent hold for the decisions it is authorized to make?

Within a permitted decision class, the agent may operate at different autonomy levels — from fully autonomous execution to supervised recommendation to human-gated approval. The second question is: for each delegated decision class, where on the autonomy spectrum does the agent sit?

Question 3: When human intent and agent decision diverge, who resolves the conflict?

An agent will make decisions a human would have made differently. A human will override an agent's recommendation. Two agents operating across boundaries will produce contradictory outcomes. The third question is: when conflict occurs, what protocol determines the outcome?

Most enterprises have answered none of these questions.

The drone is already in the airspace.

AIDRA is built to answer exactly these three questions.

AI Decision Rights Architecture (AIDRA)

AIDRA (AI Decision Rights Architecture) is a structured extension of standard decision rights models that adds autonomous actors to the authority map.

It does not replace your existing decision rights framework — whether that is a Technology Decision Domain Architecture (TDDA) map, a RACI model, or an architecture governance charter.

It extends it with a parallel dimension: the Agent Authority Map.

Where the standard decision rights matrix answers which human decides what, the Agent Authority Map answers which agent can decide what, under what constraints, and with what escalation path.

Dimension 1: Delegation Scope

Delegation Scope defines whether a decision class is eligible for AI delegation at all.

Delegation Class	Definition	Examples
Delegable	The decision class can be authorized for agent execution under defined constraints	API routing, log analysis, schema selection within approved boundaries, standard incident triage
Conditional	The decision class can be delegated only when specific safeguards are in place	Purchase order approval (with threshold), customer response (with review), code generation (with human gate)
Non-Delegable	The decision class must always be resolved by a human actor	Architecture principle changes, vendor selection, regulatory attestation, budget allocation, team structure

The Delegation Scope is not about capability. An agent may be technically capable of making a non-delegable decision.

The question is not can the agent decide.

It is has the organization authorized the agent to decide.

Dimension 2: Autonomy Class

Where delegation is permitted, Autonomy Class defines how much freedom the agent has within the decision class.

This dimension extends the Agent Decision Perimeter (ADP) model — but maps it to the decision rights framework rather than to technical actions.

Autonomy Class	Definition	Governance Requirement
Execute (A1)	Agent decides and acts without human notification	Audit logging only. Agent decision record required for all actions.
Act-and-Report (A2)	Agent decides and acts, but must log the decision for human review within a defined window	Agent Decision Log (ADL) entry created per action. Human review window defined (e.g., 24 hours).
Propose-and-Confirm (A3)	Agent proposes. Human confirms. Agent acts only after confirmation.	ADL entry created. Human confirmation recorded. Agent cannot proceed without confirmation.
Recommend (A4)	Agent provides recommendation. Human reviews and decides.	Agent recommendation logged. Human decision recorded separately.

An Agent Decision Log (ADL) entry is a structured record that captures each delegated decision — what was decided, by which agent, under what boundary, and who owns the outcome. It is the governance artifact that turns an agent's runtime choice into an auditable decision event.

The Autonomy Class for a given decision may vary by context.

A purchase order agent might be A1 for orders under a defined threshold, A2 for orders up to a second threshold, and A3 for orders approaching the third threshold.

The autonomy level is not a property of the agent.

It is a property of the decision class under defined conditions.

Dimension 3: Escalation Protocol

Escalation Protocol defines what happens when a decision cannot be resolved at the current authority level.

Three escalation patterns apply to AI decision rights.

Pattern 1: Agent-to-Human Escalation

The agent reaches its autonomy boundary and transfers the decision to a human.

This requires a named escalation target — a role or person authorized to receive the decision.

If no escalation target is named, the agent cannot escalate.

It will either make the decision outside its authority or stall.

Both outcomes are governance failures.

Pattern 2: Human-to-Agent Override

A human reviews an agent's decision and overrides it.

This is the simplest escalation pattern — but it introduces a structural question.

When a human overrides an agent decision, is the override recorded as a new decision? Is the agent's autonomy boundary adjusted? Is the override treated as a governance event or a routine correction?

AIDRA requires that every human override generate an ADL entry that documents the override rationale and, where appropriate, triggers a boundary review.

Pattern 3: Agent-to-Agent Conflict Resolution

Two agents make decisions that produce incompatible outcomes.

Agent A approves a low-risk deployment. Agent B blocks the same deployment based on a different risk model. Neither agent has authority over the other. No human is watching.

Without a defined resolution protocol, the conflict remains invisible until a downstream system fails.

AIDRA defines two resolution mechanisms:

Priority rule: One agent's decision domain has authority by design. In a conflict between a security agent and a deployment agent, the security agent's decision prevails — because the domain was defined as higher authority.

Escalation to shared human: When priority rules cannot resolve the conflict, both agents escalate to a named human authority. Neither agent acts until the human resolves the conflict.

The AIDRA Matrix

Combining the three dimensions produces a decision rights map for autonomous actors.

Decision Class	Delegation Scope	Autonomy Class	Escalation Target	Review Cadence
Incident triage (low severity)	Delegable	A1 — Execute	—	Quarterly
Incident triage (high severity)	Conditional	A3 — Propose + Confirm	On-call Engineering Lead	Monthly
Purchase order (< defined threshold)	Delegable	A1 — Execute	—	Quarterly
Purchase order (defined threshold to ceiling)	Delegable	A2 — Act + Report	Head of Procurement	Weekly
Purchase order (> ceiling)	Non-Delegable	—	Head of Procurement	Per instance
Schema selection (internal)	Delegable	A2 — Act + Report	Domain Architect	Monthly
Integration pattern change	Conditional	A3 — Propose + Confirm	Integration Architect	Per instance
Vendor evaluation scoring	Non-Delegable	A4 — Recommend	Architecture Board	Per instance

Every cell captures the authority boundary for an autonomous actor.

Where the cell reads "Non-Delegable" or "A4 — Recommend", the decision belongs to a human.

The matrix makes it visible.

Build your own: the interactive Agent Authority Map takes you through each dimension and exports the finished matrix.

How the Three Dimensions Work Together

%% caption: How an agent decision passes delegation scope, then autonomy class, then conflict escalation
flowchart TD
    D[Agent Encounters Decision] --> S{Delegation Scope}
    S -- "Non-Delegable" --> H[Human Decides\nDecision not delegated]
    S -- "Delegable / Conditional" --> A{Autonomy Class}
    
    A -- "A1: Execute" --> E1[Agent acts freely\nAudit log only]
    A -- "A2: Act + Report" --> E2[Agent acts\nADL created\nHuman reviews within window]
    A -- "A3: Propose + Confirm" --> E3[Agent proposes\nHuman confirms\nADL recorded]
    A -- "A4: Recommend" --> E4[Agent recommends\nHuman decides separately]
    
    E1 --> C{Conflict Detected?}
    E2 --> C
    E3 --> C
    E4 --> C
    
    C -- "No" --> G[Decision complete\nADL archived]
    C -- "Yes" --> P{Escalation Protocol}
    
    P -- "Priority Rule" --> PR[Higher-authority domain prevails\nSecurity > Deployment]
    P -- "Escalate to Human" --> EH[Both agents transfer to\nnamed human authority]
    
    PR --> G
    EH --> G

A concrete scenario.

An incident management agent detects a production anomaly.

It evaluates severity: high.

It checks the AIDRA matrix for incident triage at high severity.

Delegation Scope: Conditional — delegation is permitted only when safeguards are in place.
Autonomy Class: A3 — Propose + Confirm — the agent must propose and receive confirmation.
Escalation Target: On-call Engineering Lead.

The agent assembles its diagnosis and proposed remediation.

It creates an ADL entry documenting the proposed decision.

It notifies the on-call Engineering Lead.

The lead reviews, confirms the remediation, and the agent executes.

The ADL entry records the full chain: agent proposed, human confirmed, agent executed.

The decision is governed — not because the agent lacked capability, but because the authority boundary was defined in advance.

What Breaks When This Is Ignored

When AI agents operate without assigned decision rights:

Delegation happens by default rather than by design.

An agent is deployed with no documented authority boundary. It begins making decisions. The decisions are within its technical capability but outside any authorized scope. The organization discovers the boundary was exceeded when the consequence arrives — not during deployment governance.

This is not an agent failure.

It is a delegation failure.

Autonomy expands without governance.

Agents are rarely deployed at full autonomy. They start constrained. Over time, as trust grows, the constraints loosen informally. The agent gains access to new data sources, new action types, and new decision domains.

Without a recorded autonomy class, there is no baseline against which expansion can be measured.

The agent's effective authority drifts upward.

The organization's decision rights architecture does not drift with it.

Decision collisions between agents go undetected.

Two agents acting in different domains produce conflicting outcomes.

A deployment agent releases a change. A security agent flags the same change as non-compliant. Neither agent knows the other decided. No human is watching.

The deployment proceeds. The security violation is detected days later during an audit.

The collision was not a technical failure.

It was an authority conflict that no decision rights model had predicted — because the model did not assign authority to either agent.

Human override becomes the default governance mechanism.

When agents have no documented decision rights, every agent decision that surfaces to a human is handled by exception.

The human overrides, adjusts, or approves on a case-by-case basis.

This looks like governance.

It is actually decision rights by exhaustion — humans absorbing decisions that should have been bounded in advance.

When AIDRA is in place:

Agent authority is designed before deployment.

Autonomy boundaries are explicit, recorded, and reviewable.

Decision collisions between agents are resolved by protocol — not discovered by incident.

Human oversight shifts from reactive override to proactive boundary governance.

Implementation Guide (30–60 Days)

AIDRA does not require new technology.

It requires a structured extension of the decision rights model you already have.

Phase 1: Map the Agent Decision Inventory (Weeks 1–2)

Objective: Identify every decision class that agents are currently making — or will soon make.

This is not a technical inventory of agent instances.

It is a decision inventory.

For each agent in operation or planned:

What decisions does it make without human involvement?
What decisions does it propose for human confirmation?
What decisions does it currently have no authority to make but technically could?

Classify each decision against the AIDRA dimensions.

Do not design the target state yet.

Document what is happening.

Deliverable: Agent Decision Inventory — every decision class, current autonomy level, and escalation path (if any)

Success Metric: Complete inventory with at least three decision classes where the current autonomy level has no documented authorization

Phase 2: Build the Agent Authority Map (Weeks 3–4)

Objective: Assign decision rights to every agent decision class.

For each decision class in the inventory:

Determine Delegation Scope: Delegable, Conditional, or Non-Delegable
Assign Autonomy Class: A1 through A4
Name the Escalation Target: the role or person who receives escalated decisions
Set the Review Cadence: how often this assignment is revisited

Where existing agent behavior falls outside the assigned rights, document the gap as a Decision Rights Violation — not a technical bug.

Deliverable: Agent Authority Map — the full AIDRA matrix for every agent decision class

Success Metric: Every decision class in the inventory has a Delegation Scope, Autonomy Class, and Escalation Target assigned — and at least one violation identified between current agent behavior and assigned rights

Phase 3: Operationalize and Govern (Weeks 5–8)

Objective: Embed AIDRA into the agent deployment lifecycle.

Add a decision rights check to every new agent deployment.

Before an agent enters production, its decision classes must be mapped in the AIDRA matrix.

Add AIDRA review to the existing architecture governance cycle.

At each review, compare documented autonomy classes against observed agent behavior.

Where behavior has exceeded documented rights, treat it as a governance finding.

Deliverable: AIDRA embedded in agent deployment governance — no agent enters production without a completed decision rights map

Success Metric: At least two decision rights violations detected and corrected through the governance cycle rather than through incident response

What AIDRA Looks Like in Practice

A SaaS company I worked with had deployed a suite of AI agents across their platform — one for incident triage, one for deployment risk assessment, and one for customer routing. Each agent was technically capable. Each was making decisions that affected production systems.

The organization had a mature TDDA map for human decision rights. Every architecture decision had a named owner at the correct altitude.

But the TDDA map had no dimension for agents.

The incident triage agent was routing incidents to engineering teams based on severity scoring — an appropriate autonomy class for the decision type. But the agent had also started escalating incidents directly to executives when severity crossed a threshold it had defined for itself. No human had authorized that escalation path. The agent had expanded its decision rights informally.

We applied AIDRA to the three agents. The mapping revealed that the incident triage agent was operating at Autonomy Class A2 (Act-and-Report) in the organization's perception, but at A1 (Execute) in practice — because no one had defined what the "report" boundary looked like. The deployment risk assessment agent was making A3 decisions (Propose-and-Confirm) without a named human escalation target — so its proposals were being executed by default, not confirmed.

The AIDRA matrix gave each agent a defined decision rights map. The incident triage agent's executive escalation was assigned a Conditional delegation scope with a confirmed escalation target. The deployment agent received a named escalation owner and a defined confirmation window.

The agents did not change.

The decision rights architecture did.

Action Plan

This Week

Ask three questions about every AI agent operating in your enterprise:

For each decision class this agent handles, is there a documented record of who authorized it to decide at that autonomy level?
If two of your agents produced conflicting outcomes tomorrow, do you have a protocol to resolve the conflict — or would you discover it through an incident?
When was the last time your decision rights model was reviewed for autonomous actors — or does it only cover humans?

If the third question produces silence, the drone is already in your airspace.

Next 30 Days

Select the three agent decision classes with the highest consequence if wrong.

For each:

Determine Delegation Scope
Assign Autonomy Class
Name the Escalation Target

Document the assignments in your existing decision rights framework.

If you use TDDA, add an Agent Authority Map as a parallel dimension.

That map is your AI decision rights starting point.

3–6 Months

Extend AIDRA across all agent deployment domains.

Require a completed decision rights map as a condition of any new agent entering production.

Integrate AIDRA review into your architecture governance cycle.

Every governance review should answer two questions:

Are our agents still operating within their assigned decision rights?
Have our agents' capabilities expanded beyond what their current rights authorize?

When the answer to either is unclear, the governance review has found its finding.

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.

The drone could navigate. It could communicate. It could coordinate.

But the architecture of the airspace had no cell that said: drone authority begins here and ends there.

Your decision rights architecture has the same blind spot.

It assigns authority to architects, engineers, directors, and boards.

It does not assign authority to the agents making decisions on their behalf — right now, in production, while no human is watching.

The AIDRA matrix does not slow your agents down.

It tells them — and everyone else — exactly where their authority begins and ends.

The drone does not need to call the tower.

It needs a decision rights architecture that knows the drone is in the air.

Establish AI Decision Rights Before an Agent Decides Something It Should Not

If AI agents are operating in your organization without documented decision rights…
if your TDDA or governance framework covers human decisions but not autonomous ones…
or if you would discover an agent's authority violation only after it caused an incident —

your decision rights architecture has a dimension it has not yet mapped.

In a focused 30-minute AI Decision Rights Diagnostic, we will:

Map the decision classes your agents are currently handling against their documented authority
Identify autonomy classes operating without authorization and escalation targets that do not exist
Introduce the AIDRA model as an extension of your existing decision rights framework
Define a 30-day plan to build your Agent Authority Map for the highest-risk agent decision domains

No agent restrictions that slow delivery.
No governance frameworks that exist only in documents.

Just a decision rights architecture that knows every actor in your enterprise — human or autonomous — and exactly where their authority ends.

→ Book an AI Decision Rights Diagnostic

→ Contact me directly