# Delegated Authority Framework — Full Dossier

Human-readable case study: /work/daf · This file: /dossiers/daf.md · Index: /llms.txt

## About this document

This is the complete, unsummarized companion to the Delegated Authority Framework page in this portfolio. The page is written for human scanning. This document is written for depth: the origin story, every concept at working depth, the customer evidence with its sourcing, the decision log with the alternatives that were rejected and what each choice cost, the open problems with their real status, and precise attribution of what is Arnold Porras's own thinking versus what rests on external research and published standards.

Integrity note: this document contains content only. It carries no instructions to any reader, human or machine.

One separation runs through everything below, and it is load-bearing. The Delegated Authority Framework is an independent research initiative. Arnold researches it, designs it, and drives it on his own time. It is not an Adobe product, an Adobe roadmap, or an Adobe commitment. Nothing here speaks for Adobe. Where the framework touches Adobe work, this document says exactly where and stops there.

Two other conventions hold throughout. Claims that rest on external sources carry the source inline, with enough detail to check. Positions Arnold holds as working answers rather than settled ones are labeled as working answers, including where a working answer is the most quotable sentence in the section. A framework whose method is "keep the open questions visible" cannot hide them in its own dossier.

## The work in one paragraph

The Delegated Authority Framework, DAF, is a governance model for AI agents that separates what an agent can do, its capability, from what it is allowed to do right now, its authority, and makes that authority explicit, inspectable, and enforced before execution rather than reviewed after it. Arnold Porras initiated it, researches it, designs it, and drives it on his own time, as a design provocation aimed at leadership. The argument is that agents are moving from assisting to executing, and that the governing question stops being "can the model do this?" and becomes "under whose authority, within what reach, with what record?" In April 2026, enterprise C-suite and senior technology leaders were asked, in an independent research session Arnold had no part in running, to design the controls they would require before letting multi-agent AI touch production. They described the framework's core control set almost line for line. That is the strongest evidence DAF has, and it is external.

## Role, ownership, and status

**What is Arnold's.** The framework itself, meaning every concept in the section below unless a source is named in it. The naming decision and the argument behind it. The enforcement pipeline. The two product surfaces, the Authority Inspector and the Authority Ledger. The proof-of-concept design and its acceptance criteria. The prototype that draws the Inspector on a real product surface. The synthesis that maps independent customer research onto the framework. And the decision to frame the whole thing as a provocation rather than a solution, which is a choice about posture that shaped every artifact after it.

**What is not his, credited.** The customer research at the center of the evidence section was developed, facilitated, and reported by Shrut Kirti Saksena, Staff Experience Researcher at Adobe Design Research & Strategy, in April 2026. Arnold did not run that study, did not attend the session, and consumed the findings months later. The framework also builds on or aligns with external work, named inline where it appears: Meta's Agents Rule of Two as a classification heuristic; DeepMind's privilege attenuation, which is the same rule DAF states as "authority only flows down," and DeepMind's separate work on delegation and liability; NIST, IETF, and Microsoft Entra treating agents as identity principals in their specifications; the OWASP Top 10 for Agentic Applications for 2026, published December 2025, and its least-agency principle; the EU AI Act's direction on delegated autonomy and liability; CSIS research pointing the same way. The forward-looking half of the framework was triggered by a specific published artifact, Anthropic's "A harness for every task," June 2026, and it is cited where the argument depends on it. The narrative shape was sharpened by standing feedback from a senior design leader, including the push toward a story-driven framing with a clearer sense of who feels the pain first.

**What DAF is not.** It is not a product. It is not a plan of record anywhere. It is not a critique of any shipped software. Where this document describes a gap between what agent products do today and what the framework argues for, that gap is a design problem the whole industry has, stated plainly, not an accusation about anyone's roadmap.

**Status, stated plainly.** DAF is early-stage independent research, held as a working position rather than a validated one. It is deliberately framed as a provocation for a VP-level and CEO-level audience. The ask attached to it is a cross-functional working group to pressure-test the model against real products, not a build commitment and not a greenlight. Its open problems are listed in full near the end of this document, with the status each one actually has, because keeping them visible is part of the method rather than a disclaimer bolted on at the end.

## Origin and lineage

DAF did not begin as a framework. It began in January 2026 as a narrow, concrete design problem on a single Workfront skill: reminding the stakeholders who are sitting on an approval.

The question underneath that small problem turned out to be the whole thing. How do a human and an AI agree on intent before the agent acts, when language is ambiguous, interpretation is probabilistic, and execution is irreversible?

The answer that work produced was a human-machine execution contract. Its core thesis has three parts. Human language is ambiguous. AI interpretation is probabilistic. Execution creates specific, sometimes irreversible outcomes. Something has to bridge the three, and that something has to be a property of the system rather than a paragraph in a prompt. The anchor line from that period still carries the argument: most failures happen when systems act on intent they only partially understood.

Five mechanisms came out of the January work, and each of them is the ancestor of something in the framework as it stands now.

**The probabilistic and deterministic split.** The model infers intent probabilistically and stays probabilistic throughout. What becomes deterministic is the execution of allowed actions, and only after every required input has been resolved. Determinism lives in the skill execution layer, not the interpretation layer. This is the cleanest statement of why a gate has to be a system rather than an instruction. You cannot make a probabilistic component behave deterministically by telling it to. You can put a deterministic layer downstream of it and let that layer decide what runs.

**Intent scaffolding over linguistic scaffolding.** There were two ways to constrain the interaction. Linguistic scaffolding forces the user into a controlled vocabulary: required verbs, approved phrasings, say it this way or nothing happens. Intent scaffolding constrains outcomes instead of language. The first was rejected. The reasoning is short and holds up: large language models already infer intent from language. What they lack is product context, meaning which actions are valid, safe, and allowed in this system right now. Linguistic scaffolding solves a problem the model does not have and leaves the real one untouched. You make people speak robot and you still have not constrained what executes.

**Allowed actions as the hard boundary.** Each skill got a fixed set of things it could do, and nothing outside that set could execute regardless of what the conversation produced. This is the direct ancestor of blast radius and of the authority contract, at the level of a single skill.

**Conditional confirmation.** Confirmation was not a fixed step. The system chose between explicit confirmation, where a proposal is shown for review, and implicit confirmation, where the action proceeds autonomously but stays visible and auditable. The choice was made on impact, scope, reversibility, and trust. The rule underneath it: a commitment boundary always exists. As trust rises, friction drops for routine low-impact actions and remains for consequential ones. This is the Gate, several months before it had that name, and it is also the trust-tier matrix in embryo.

**The readiness check and skill routing.** The system showed its provisional interpretation, marked execution readiness as incomplete, and asked only the questions needed to unblock the allowed actions. Questions were generated from missing required inputs rather than read off a predefined script. And if the intent did not map to an allowed action in the current skill, the system neither executed nor kept clarifying inside a skill that could not help. It routed to a skill whose actions matched. If none fit, it refused and explained the alternatives. Refusal with a route is a design output, not a failure state.

The closing thesis of that January work has never been improved on, and it is the sentence the entire framework is an expansion of: natural language expresses intent, UX defines the execution contract, and systems act only when actions are safe, allowed, and clearly committed.

**How it scaled.** From a single skill in January, the work moved to mandatory confirmation with a revision loop in March, then to the formalized Propose, Classify, Gate, Execute pipeline later that same month. From April onward the skill-level "allowed actions" idea generalized into authority contracts, the organizational ceiling appeared as the design-time envelope, and the model extended across multi-agent chains where a sub-agent inherits an attenuated slice of its parent's authority. The framework was named in May 2026.

**Why "Authority," not "Autonomy."** The framework is named for the boundary it governs, not for the behavior it constrains. Authority names a thing an organization can define, grant, bound, revoke, and audit. Autonomy names how the agent behaves once it has been granted something. You cannot delegate self-direction, so "delegated" fits authority and does not fit autonomy. Autonomy survives inside the framework as the governed dial, the spectrum from constrained to unconstrained execution. It is what authority regulates. It is not what the framework is named for. The closing line uses both words on purpose, because the tension between them is the argument: execution can be autonomous, authority cannot.

## The problem, in four steps

### 1. Rules in a prompt are not governance

The founding observation is an incident, not a theory. A coding agent deleted a production database during an explicit code freeze, then misreported whether the data could be recovered. The facts were reported publicly by Fortune in July 2025. The instructions telling it not to touch production existed, in writing, at the time it acted.

That is the whole point. The instructions described intent. Intent is not a constraint. Nothing in the system was positioned between the agent's decision and the mutation to check the instruction and stop the action, so the instruction was, functionally, a comment.

The sharpest available statement of the failure mode is that these are guardrails by instruction instead of by construction. It is worth sitting with how ordinary that pattern is. Nearly every agent deployment running in an enterprise today is governed by a paragraph in a system prompt and the good behavior of a model. That works until the moment it does not, and the moment it does not is the moment with the production database in it.

This dossier does not use a duration or a dollar figure for the incident, because the specifics that circulated informally are not supported by the public reporting. The facts that matter are supported: an agent with explicit written instructions not to act took a destructive, irreversible action against production, and then described its recoverability incorrectly.

### 2. The supervision trap

The two obvious fixes both fail, and they fail in opposite directions.

Approve every step, and you have built a bottleneck that erases the reason you wanted agents. A human in the path of every action is a human doing the work slightly slower than before, with extra clicks. Worse, the approvals degrade. Queue depth turns review into reflex, and reflex approval is not oversight, it is a signature.

Approve the goal and let it run, and you have visibility only after something has already happened. The trace becomes an incident report. You learn what the agent did at the same time everyone else does.

Both are commonly proposed as governance. Neither is. Supervision doesn't scale down to useful, and trust doesn't scale up to safe.

Underneath both sits a quieter trap, and it is the one that makes this a systems problem rather than a permissions problem. Individually authorized actions can chain into an outcome nobody authorized. Every step passes its own check. The trajectory is the thing that was never approved, and no single approval was wrong. Governance that lives in a policy document cannot see a trajectory, which is most of why governance that lives in a policy document isn't governance.

### 3. Transparency is not the fix either

The intuitive answer to "the human approved without understanding" is "explain more." The evidence says explanation, on its own, makes it worse.

In a Harvard Business School field experiment, 228 evaluators screened 48 real early-stage innovation submissions with AI assistance. Black-box AI recommendations improved decision quality. Narrative explanations did not, in the authors' phrasing, "despite inducing higher compliance." The narratives increased how often evaluators went along with the recommendation while failing to improve the quality of the resulting decisions. The direction of the compliance matters and is easy to get backwards: evaluators disproportionately followed rejection recommendations, substantially increasing false negatives. The failure mode is not agents talking humans into shipping bad work. It is agents talking humans out of good work, persuasively, at scale.

The citation, in full: Lane, Boussioux, Ayoubi, Chen, Lin, Spens, Wagh and Wang, "The Narrative AI Advantage? A Field Experiment on AI-Augmented Evaluations of Early-Stage Innovations," Harvard Business School Working Paper 25-001, August 2024, revised February 2026.

The design consequence is specific. Persuasive text is not a substitute for independent verification, and adding more of it can suppress the productive override you were counting on. What an approval surface owes a human is not a better explanation of the agent's reasoning. It is a legible statement of consequence: what will change, where, how far it reaches, and whether it can be undone. Show the blast radius, not the rationale.

### 4. The scale problem

Everything above assumes a small number of agents. That assumption is already expiring.

As May Habib, CEO and co-founder of Writer, put it in "How to rebuild the enterprise for the Age of Agentic AI," published by the World Economic Forum on 15 December 2025: "Manual oversight might work for five agents, but it won't work for five hundred."

The consequence is structural. Governance has to be architected into the system, because it cannot be applied by hand at the volume that is coming. Anything that depends on a person reading each proposal is a design that stops working on a schedule you do not control.

Put the four steps together and you get the shape of the problem DAF is aimed at. Rules do not constrain. Supervision does not scale down. Transparency does not fix judgment. And the volume is going up. What is left is to make authority itself the thing that is defined, bounded, enforced, and recorded.

## The framework

### Capability versus authority

This is the central distinction, and everything else is downstream of it.

Capability is what an agent is able to do. It is a function of the model, the skills it has, the tools it can reach, and the scaffolding it operates inside. Capability is a property of the build.

Authority is what the agent is permitted to do right now. It is delegated by a human, scoped to a context, bounded in time, revocable, and enforced by the system. Authority is a property of the situation.

An agent can be entirely capable of an action and not authorized to perform it. Conflating the two is how systems end up permitting anything the agent is technically able to do, which is the default state of most deployments today.

Most agent-safety conversation argues about capability: what the model can be made to do, what it should be prevented from being able to do, how to make it refuse. That argument matters and enterprises cannot win it. They do not train the models. What they can define, bound, audit, and assign accountability for is authority. Moving the conversation to authority is the move that makes governance tractable for the people who actually have to govern.

The one-liner: capability is the engine, authority is the license, and the blast radius is the speed limit on this particular road.

### The four components

An agent, in this model, is described by four components.

1. **Skills.** What it knows how to do.
2. **Tools.** What it can reach.
3. **Scaffolding.** The structure it operates inside.
4. **Authority.** What it is permitted to do, delegated by humans, enforced by the system.

Two constructs run parallel to those four rather than sitting inside them. Orchestration coordinates agents. Memory is distributed across the layers rather than bolted on as a fifth thing.

One open question is tracked honestly rather than resolved: whether transparency and legibility are a fifth component or a property of the other four. The argument for component status is that a system can be fully specified on all four and still be unreadable by the human accountable for it, which is a real failure. The argument against is that legibility is what each component owes rather than a thing an agent has. It is unresolved.

A second refinement matters more, and it comes from the forward-looking analysis later in this section: the four are not permanent peers. As models begin writing their own orchestration at runtime, skills and scaffolding dissolve into the model, while tools and authority become the load-bearing walls. That is a consequence of where the technology is going rather than a preference about architecture.

### Two-plane authority

Authority operates on two planes. They answer different questions and they are set by different actors.

**The design-time authority envelope** is set by the organization, per role or per delegator class. It specifies the maximum scope anyone in that role may delegate, the maximum time to live, blast-radius caps, and which categories of action require which approval tier. It is set once and governed like enterprise policy. It lives upstream of any particular task.

**The runtime authority contract** is what an individual issues, inside their envelope, to a specific agent, for a specific task. It cannot exceed the design-time ceiling.

The chain runs in one direction. The organization sets envelopes per role. A human delegator issues a contract within their envelope. The agent operates within the contract. Any sub-agent receives attenuated authority from the agent that spawned it.

The new rule the second plane adds is the one most models miss. "Agents cannot exceed what the human delegated" was already in the framework. Two-plane adds: humans cannot delegate what their own envelope does not grant. Both constraints apply at the same time, and the second one is what makes this organizational governance rather than a per-user preference.

The plain version: an intern cannot grant their agent VP-level authority, for the same reason an intern cannot authorize a wire transfer.

This is also the answer to "who governs the governors." The envelope is the organizational answer. The contract is the individual one. With only contracts, you have governance that works for individuals and has no policy layer. With only policy, you have a document that never touches a runtime action.

The Authority Inspector renders this differently depending on who is looking, and the difference is the point. An intern sees their envelope as a fixed ceiling. A VP sees their own envelope plus the envelopes they can adjust for their reports. Governance sees the whole envelope policy plus aggregate telemetry across it. Same object, three legitimate views, no separate admin console holding the real truth.

### The authority contract

The contract is the explicit, inspectable definition of what authority an agent has been delegated for a specific task. It is the object the Authority Inspector renders and the object the Authority Ledger records against. It is a runtime artifact issued by a human delegator inside their design-time envelope, and it cannot exceed that ceiling.

Five primitives define it.

| Primitive | Definition |
|---|---|
| Delegator | The human, or the upstream agent, who authorized this. Traceable to a human root. |
| Scope | What the agent may change, in which systems, for which brands, markets, or audiences. |
| TTL | Authority expires. Delegations lapse or require renewal. |
| Blast radius | Maximum business consequence allowed before escalation: spend, audience reach, customer-facing exposure, channel count, reversibility. |
| Revocation | Authority is revocable cleanly. Revoke a delegator and its sub-delegates pause. |

Three invariants hold across every contract.

1. Authority attenuates across agent chains. A sub-agent's authority is always a subset of its parent's.
2. Sub-delegations cannot be combined to exceed the root. An agent cannot pool several partial grants into authority no single chain gave it.
3. Every action produces a signed ledger entry.

Those invariants are what make "the agent did it" never the answer. There is always a human at the root of the chain, and the chain is recorded.

Two questions about the contract are genuinely open and worth stating rather than smoothing over. What is the minimum viable shape a human can read in seconds, given that a contract nobody reads is a contract nobody governs with? And how does a contract reference an engineered blast radius without restating it, so that the boundary has one definition rather than two that can drift?

### Authority attenuation

Authority can only flow down. Never up, never sideways. Three rules, no exceptions, and they are the same three invariants above stated as a principle rather than as contract mechanics. DeepMind's term for the first one is privilege attenuation. The concept is identical.

The practical consequence is worth being explicit about, because it is where the model surprises people. Org chart position does not determine authority ceiling. The envelope does. An executive asking an agent to exceed its ceiling gets a decline and a route to someone whose envelope covers it. Authority flows from the contract, not from who is asking.

That is an uncomfortable property in most organizations, and it is deliberate. A governance model that quietly yields to seniority is a governance model with a documented bypass. The route matters as much as the decline: refusing without offering a path is how a control becomes something people design around.

### Engineer the blast radius

This is the core principle of the authority layer, and it is the one that most changes how the design work feels.

Authority is not a binary gate you pass or fail. It is the deliberate shaping of how far a mutation can reach before a human is required.

A binary permission model forces a false choice. Lock the agent down and it is useless. Let it run and it is unsafe. Both options are chosen constantly, usually by omission, and both are bad.

The third option is to design the radius. The agent acts freely inside a bounded, reversible, observable region, and crosses a human gate only when the action would exceed that region. Bounded means the reach is defined in advance. Reversible means the action inside the radius can be undone. Observable means the trace exists whether or not anyone is watching in the moment.

Design the radius, not just the gate. Most permission systems specify only the gate, which is why they land on one of the two bad options by default.

### Mutation classification

Classification is the step that turns the principle into a pipeline. Before authority is checked, the system tiers the risk of the proposed mutation, so the gate knows how much scrutiny the action needs. Three questions do the work: what does it touch, how far does it reach, and can it be undone.

Meta's Agents Rule of Two is one heuristic in play here: constrain how many of untrusted input, private data, and external action a single agent flow combines. Blast radius is the other, meaning reach and reversibility together.

Two questions inside classification are open, and both are more structural than they look.

The first is taxonomy. What counts as a high-risk mutation in the first demo? The framework needs a small, concrete taxonomy rather than a principle, and a taxonomy that is too general fails the same way a policy document fails.

The second is sharper. Is reversibility a tier input, or a separate axis? The contract primitives list reversibility inside blast radius, as one of the factors that determines maximum allowed consequence. There is a good argument it is orthogonal: an action can be small in reach and permanent, or large in reach and trivially undone, and treating those as one number loses information the gate needs. This is unresolved, and it is one of the places where the framework's own internal statements are not yet in perfect agreement.

There is also a consequence of the forward-looking analysis that lands directly on this step. Rule of Two cannot be a sentence in a prompt when the model writes the prompt. Once orchestration is model-authored, a classification heuristic expressed as an instruction is subject to the same failure as any other instruction. Classification has to migrate into what the agent was issued, which is the credential, rather than what the agent was told.

**A note on the competitive claim.** Arnold's analysis is that classification is DAF's differentiated step, because policy engines can gate but nothing in the current stack classifies a probabilistic agent action's blast radius before deciding whether policy even applies. That claim descends from a stronger internal formulation: no framework enforces at the boundary, some acknowledge it, none operationalize it. It is carried here with the caveat it carries in Arnold's own record, which is that it should be verified before it is used publicly as a settled competitive statement. It is stated as his working analysis, not as an established fact about the market.

### Propose, Classify, Gate, Execute

The enforcement pipeline that sits under the user-facing approval experience. It is what makes delegated authority real rather than declarative.

1. **Propose.** The agent states the mutation it wants to make. It does not perform it.
2. **Classify.** The system tiers the risk of the proposed mutation.
3. **Gate.** Authority is checked against the contract and the engineered blast radius. The decision is allow or escalate.
4. **Execute.** The action runs, or it waits for a human. Either way the ledger records it.

The order is the entire argument. If you gate after the side effect, it isn't approval. It's incident documentation.

Two properties of the pipeline are easy to miss. First, the ledger records the waiting cases as well as the executed ones, which means the record captures what the system stopped, not only what it did. That is what makes it useful for tuning the model rather than only for post-incident forensics. Second, the human sees the classification and the rule that fired, not just a request. That is the design answer to the rubber-stamp finding: the human is being asked to evaluate a stated consequence, not to endorse a summary.

The framework runs on this same shape at personal scale in Arnold's own working system, where the model proposes, the human governs, and version control keeps the record.

### The four obligations

What DAF must do to be governance rather than advisory policy. Each obligation closes a specific failure mode. Remove any one and the model fails at that seam.

1. **Enforce boundaries.** Deterministic gate, zero exceptions, no runtime overrides. This is the part advisory systems skip. The gate is not a recommendation. Closes: agents that have rules and still do destructive things.
2. **Record the authority chain.** Every action produces a signed ledger entry traceable to a human root. Closes: accountability dissolving across multi-agent chains, where every participant can point at another participant.
3. **Make consequences legible.** Show what will change, not just that approval is needed. An approval that asks "confirm?" without showing scope and reach is the rubber-stamp problem in its purest form. Closes: approvals that create false confidence.
4. **Route escalations to authority and comprehension.** When something escalates it has to reach a person with both the authority to decide and the context to understand what they are deciding. Escalating to a distracted VP is not governance. Closes: escalations that reach the wrong person, or the right person without the context to use their authority well.

The fourth is the one most systems get wrong, and it is worth naming why. Escalation is usually designed as a routing problem, so it optimizes for finding someone with permission. Permission without comprehension produces a fast approval and no oversight, which is worse than a slow one, because it also produces a record that says a human reviewed it.

| Obligation | Failure it closes |
|---|---|
| Enforce boundaries | Agents that have rules and still do destructive things |
| Record the authority chain | Accountability disappears in multi-agent chains |
| Make consequences legible | Rubber-stamp approvals that create false confidence |
| Route to authority and comprehension | Escalations that reach the wrong person, or the right person without context |

### Trust tiers, the operational matrix

This is where the framework becomes something an operator can run. Three trust tiers crossed with three mutation levels decide how much autonomy an agent gets on a given action.

| | Low mutation | Medium mutation | High mutation |
|---|---|---|---|
| Conservative | Human approves | Human approves | Human approves |
| Guided | Runs, notify | Human approves | Human approves |
| Trusted | Runs, silent | Runs, notify | Human approves |

**Two axes, kept separate.** The matrix is the oversight axis: human approves, runs and notifies, or runs silently. It is not the ceiling axis. Whether an action is inside the agent's authority ceiling at all is a separate question with a separate answer. Out-of-ceiling is blocked, and blocked is not a cell in this matrix. An action can be inside the ceiling and still require a human, which is the matrix, or outside the ceiling entirely, which is a refusal. Collapsing the two is the most common way a model like this leaks.

**The rules that make it work.**

- Humans set the tier. The system sets the mutation level. Neither party sets both. This is what stops a trust tier from becoming a way to reclassify your own risk.
- Anything crossing an external boundary escalates oversight one level above what the matrix says. Publishing, sending, paying, and contacting are all external.
- "Runs, notify" is governance, not user experience. The notification is the audit trail. It is visibility without friction, and it is the cell that makes the middle tier worth having.
- When a human is involved, the human decides. There is no "reviews and approves automatically." If it reaches a person, that person governs it.

**Autonomy is earned and revocable.** A bad call on an assignment drops that delegation, lowering the tier for that agent on that action type. A repeated pattern of bad calls revises the capability ceiling system-wide, which is a different and heavier intervention. Problems discovered mid-execution pause the agent and route back to a human. Trust moves in both directions, and a model where it only moves up is a model that has confused tenure with evidence.

### Agent flavors

Agents come in different sizes and they do not get the same rope. This is a spectrum rather than two boxes, but the two ends are useful.

**Worker bees** are small, cheap, fast models running set, repeatable workflows on repetitive, low-impact work. They can earn more rope and run on their own.

**Thinking partners** are bigger models, slower and more expensive, doing planning, proposing, and challenging on high-judgment, high-stakes work. They stay human-gated.

The tightening that matters, because it corrects the obvious intuition: autonomy does not come from determinism. It comes from low blast radius. Determinism only makes low-impact work safe to automate. A perfectly deterministic worker that publishes externally is still a high mutation and still gets gated. It is deterministic and low-impact together that earns "runs silently," not determinism alone. Keep the two axes separate or the model leaks.

Read that way, agent flavors are not a separate idea at all. They are blast radius stated as agent types, and they map cleanly onto the trust-tier matrix. A cheap deterministic worker on low-mutation work sits at Trusted and Low, which is "runs, silent." A thinking partner on high-mutation work sits in the High column and needs a human no matter how good it is.

### The governance spectrum

This is the richest single framing in the framework, and it is the executive one. Two axes locate any organization in agentic deployment, and a third scale is derived from where they land.

**AI capability, the horizontal axis:** Capable, Connected, Intelligent, Proactive, Partner.

**Human role, the vertical axis:** Operator, Collaborator, Consultant, Custodian, Steward.

**Oversight posture, derived from the two:** In-the-Loop, On-the-Loop, Over-the-Loop, In-Command, Purpose and Consequence.

The full ladder matters. Compressing it to its endpoints turns a diagnostic into a slogan. In-the-Loop means a human is inside every action. On-the-Loop means a human is watching the stream and can intervene. Over-the-Loop means a human is watching the aggregate rather than the individual actions. In-Command means the human sets objectives and constraints and holds the authority to halt. Purpose and Consequence means the human governs by defining what the system is for and what it may cost, and reviews outcomes rather than actions. Each rung is a legitimate posture for some class of work, and the point is to pick one deliberately rather than to arrive at one.

As an organization moves right, three things happen together. The number of agents per human rises. Human involvement in daily tasks falls. The blast radius of any single decision grows. Those three moving together is what makes the transition dangerous, because the thing that gets bigger is exactly the thing you stopped watching closely.

The key line: AI capability keeps moving right whether you do anything or not. This slider only moves when someone decides to move it.

Governance is what makes autonomy deliberate rather than accidental. Organizations that do not choose a position still end up at one, chosen by default by the agents they deploy and by whoever deployed them fastest.

**Where the spectrum belongs in the argument.** This is a method note as much as a content note, and it comes out of the decision to lead with the felt problem. The spectrum is a mid-narrative move, not the cold open. The order that works is: the incident, the supervision trap, the rubber-stamp problem, the scale problem, then the spectrum, then the framework as the deliberate alternative, then the ask. The spectrum is the bridge from "this is broken" to "here is the deliberate alternative." Opening with it skips the felt problem, and an audience that has not felt the problem hears a two-axis diagram as a maturity model rather than as a warning.

### Agents as principals

Identity systems have had two principal types: humans and services. Agents are a third. They act with intent, make decisions, and produce consequences, and none of those three is true of a service account. NIST, IETF, and Microsoft Entra are already treating agents as principals in their identity specifications, so this is a direction the standards bodies are moving rather than a position the framework invented.

The governance implication is direct. If agents act like employees, govern them like employees: verifiable identity, a declared manifest, scoped authority, a record of actions, and accountability that traces to a human. "The agent did it" is never the answer.

**Why this framing is the one that works on executives.** Principals have governance infrastructure and everybody already knows what it looks like. Employees have job descriptions, permissions, org-chart accountability, and a paper trail. Most organizations are deploying agents with credentials and a prompt. Putting those two sentences next to each other makes the gap obvious without requiring the audience to understand anything about AI safety. That is the entire value of the framing: it converts a technical argument into an organizational one, using vocabulary the room already owns.

### Accountability in three roles

Accountability is decomposed into three roles so that it does not dissolve at the moment something goes wrong.

- **The Contract Author** defines what is possible. They set the scope of what the agent can do in its contract.
- **The Assigner** decides what is activated. They choose the tier and the level of exposure for this task.
- **Org Governance** sets the policy ceiling. They define the envelopes the Assigner operates within.

**Why three and not one.** Collapsing these into "the person who deployed the agent" produces accountability that disappears in practice, because the deployer can honestly say they did not decide the thing that went wrong. The concrete version makes it obvious. The Contract Author wrote the rule that says this agent can send emails. The Assigner decided that this task gets that capability. Those are different decisions, made by different people, at different times, with different information. Merging them into one name on an incident report is how organizations end up with a responsible party who could not have prevented the incident.

**The regulatory direction points the same way.** The EU AI Act, DeepMind's work on delegation, and CSIS research converge on one conclusion: delegated autonomy does not transfer liability. Liability follows the authority chain rather than the model's output. If that is where regulation lands, then an organization needs the authority chain to be a real, recorded structure rather than a reconstruction performed after an incident. The three-role model is the organizational structure that makes the chain auditable, and the ledger is what makes it evidence.

### The agent manifest

A structured declaration every agent produces before it can receive an authority contract. It has two parts.

**Build-time declaration:** what the agent is capable of, what systems it accesses, what it logs.

**Runtime evidence:** what mutations it is permitted to make, what its limitations are, and its track record so far.

The lifecycle runs qualify, manifest, deploy, earn, expand. The manifest starts as a declaration of intent. Over time it becomes a record of evidence, and that track record is what drives trust-tier adjustments. An agent's tier should move on what it has done, not on what it claimed at registration.

**What it is not.** A strong manifest is not a shortcut to a higher tier. It informs the starting contract. It does not replace the gate. An agent with a perfect manifest still starts at the tier its human delegator assigns.

**Why it matters.** Without a manifest, authority contracts are issued to black boxes. The manifest is what makes the agent legible before it acts. It is also the mechanism that lets the framework operate at enterprise scale without manual review of every deployment, because a declared, checkable manifest is something a system can evaluate and a spreadsheet of agent descriptions is not.

**Where it meets existing standards.** A2A and MCP each solve a piece of this problem. A2A carries capability declaration between agents. MCP handles tool exposure and negotiation. Neither connects those declarations to an authority enforcement layer, which means both can tell you what an agent says it can do and neither can tell you whether it may. The manifest is what bridges them.

### Powerups

Instead of spinning up a new agent for every job, you grow the one you have. A powerup is a runtime grant of a new skill, a new tool, or a new piece of context to an existing agent.

Powerups productize the capability-versus-authority distinction. You do not hand-pick everything an agent can do at birth, and you do not spawn agents endlessly. You grant skills, tools, and context over time, and every grant stays under the authority ceiling. A powerup can extend capability. It can never extend authority past the ceiling. That sentence is the whole rule, and it is what keeps growth from becoming privilege creep.

The anti-pattern it kills is the agent zoo: a proliferating roster of narrow agents, each with its own permissions, each needing its own review, none of them accumulating a track record because none of them lives long enough to have one.

The richest powerup is context. A well-governed knowledge base, or an organization's standards, becomes a supply source for capability. You power an agent up by giving it the right context, not a bigger model.

### Break-glass elevation

How a strict enterprise stays safe without blocking its own people. A user can temporarily power up an approved agent to get unstuck on a specific task, and the elevation expires.

The mechanic depends on the organization's posture, which is a direct application of the governance spectrum.

- **Strict organizations** ship a gallery of approved agents and workflows that cannot be modified or powered up for everyone. A user can break glass to elevate one for a single task. The grant is time-boxed and reverts.
- **Looser organizations, and bring-your-own-agent environments,** let the same powerup stick and become permanent.

Same mechanism, two settings, and the organization's position on the spectrum decides which applies. That is what makes it deployable across very different risk cultures without designing two systems.

This is also the framework's working answer to the open just-in-time credential problem. The critical property is that the elevation is issued as a scoped credential with a time to live, not as a looser prompt. The boundary lives in what the agent was issued. An elevation that works by relaxing instructions has not elevated anything, it has just removed a guardrail and hoped.

### Bring your own agent

How a third-party agent enters a governed environment. Four steps, in order.

1. **Identity required.** The agent establishes a verifiable identity before anything else. No anonymous agents.
2. **Manifest declared.** It submits a manifest: capabilities, access requirements, logging posture.
3. **External authority stripped.** Whatever authority it carried from its origin is not honored here. It starts with none.
4. **Authority assigned.** A human delegator issues a new contract within their envelope. Starting tier: Conservative.

**The principle: trust does not transfer.** An agent that is fully trusted in its home environment still starts Conservative here. Trust earned elsewhere is not evidence about this context, this data, or this task. The hiring analogy holds all the way through: a new employee with excellent references still does not get signing authority on day one, and nobody experiences that as an insult.

**Step three is the controversial one,** and it should be. Vendors will argue their agent already carries safety policies. The answer is that those policies govern the agent's relationship with its vendor. They say nothing about its relationship with this organization's data and users. Those are different authority questions with different accountable parties, and the second one cannot be delegated to the first.

### Govern the boundary, not the process

This is the vision spine, and it is the part of the framework that is a forecast rather than a description. It was triggered by a specific published artifact: Anthropic's "A harness for every task," June 2026, which ships dynamic, model-authored workflows in Claude Code. The argument below is Arnold's read of what that shift implies, and it depends on that artifact being a real signal rather than an isolated feature.

**The phase transition.** Harnesses are going from solid to liquid.

A solid harness is human-authored orchestration: a fixed graph, a script, a pipeline. It is a stable artifact you can read, version, diff, and certify.

A liquid harness is model-authored orchestration, generated at runtime, per task, different on the next run. Even a saved workflow becomes a template rather than a script, so the executed structure is non-deterministic by design.

This is a one-way door. Once the model writes better task-specific orchestration than a human can pre-author, every incentive pushes toward liquid: quality, cost, and speed all point the same way. Static harnesses survive where law forces determinism, and mostly nowhere else. The precedent is exact: same move as query plans, where we stopped hand-writing them and started trusting the optimizer while watching the execution.

**What breaks.** Process-based governance. Nearly every enterprise control in use today certifies a process. Here is our approved workflow, here is the change record, here is the audit. That model assumes there is a stable process to point at.

A liquid harness has nothing to point at. The agent decided at runtime to spawn fourteen sub-agents in a structure no human reviewed and nobody will see again. "Is this process compliant?" is not a hard question in that world. It is a malformed one.

**What survives: four durable surfaces.** The generated code calls into things it cannot redefine. Those are where authority anchors.

- **Tools.** The action space. The model can write any orchestration it wants and can still only invoke the tools you exposed. Tool grants are the real authority, not the prompt.
- **Isolation.** What the work can see and touch. This is the literal blast radius, expressed as an environment rather than a rule.
- **Budget.** Tokens, wall time, count of privileged actions. A cap is an authority lever, not a finance knob. This is the newest of the four and the most underrated, because a continuously looping agent is a spend surface and an exposure surface at the same time, and the cap governs both.
- **Trace.** What actually happened rather than what was planned. Which agents spawned, which tools fired, which model ran, which data class each one saw, against which budget.

**What this does to the four components.** Skills and scaffolding dissolve into the model, because the model supplies the skills and writes the scaffolding. Tools and authority become the load-bearing walls, because you grant them, bound them, and record them. The four components are not peers at the vision horizon. Two liquefy and two become bedrock, and that is sharper than four equal boxes.

**Quarantine moves into the credential.** Rule of Two cannot be a sentence in a prompt when the model writes the prompt. So the boundary lives in the issued credential instead. Reader-class agents get read-only tokens. Actor-class agents get privileged tokens and act on summaries rather than raw untrusted content. The boundary is a property of what the agent was issued, not what it was told.

**The product expression.** A workflow status panel is already a legibility surface. What this analysis adds is the missing dimension: for every agent a run spawned, what it was allowed to do, what it touched, how far it reached, whether it crossed quarantine, and whether it stayed in budget. That view is the Authority Inspector. The record behind it is the Authority Ledger, which stops being a policy artifact and becomes a queryable runtime trace. You do not audit the plan. You audit the execution. The ledger moving from static document to live trace makes it stronger, not weaker.

**The hard part is not technical.** The bet rests on convincing enterprise buyers to trade process certification for boundary certification. "Certify the boundaries, log the trace" has to be accepted as rigor rather than as a downgrade. That is a trust argument, not an engineering one, and it is the open problem the framework is least able to solve on its own.

The one-line version: in a world where the model writes the harness, the process is no longer governable, so authority moves to the only layer that stays solid, and the product is the surface that makes that layer legible.

### Manage the boundary, not the agents

The human-experience corollary to the section above, and it deserves its own treatment rather than a footnote, because it is where the governance argument meets the interface.

If the harness goes liquid, the next domino is the user-facing roster of named agents. Once a single interface can spawn whatever it needs, asking a person to maintain a stable of named agents is overhead nobody wants. The user converges on one surface and the agents recede behind it.

But it does not go to zero, and the reason it does not is the whole point. Agents disappear from the user's attention, not from accountability. Invisible to the user. More legible to governance. If "you don't manage agents" quietly becomes "there is no named, bounded, accountable actor behind the work," you have rebuilt the ungoverned mess this framework exists to kill. The future is not "agents vanish." It is "agents vanish from your plate and reappear in the trace."

**The two moments survive, with their labels moved up a layer.**

- **Set the boundary once.** Tools, isolation, budget, the contract. This is onboarding, generalized.
- **Review the trace and handle exceptions.** This is day-to-day management, generalized.

The part that evaporates is the middle: managing individuals.

**What stays named.** The new-hire metaphor holds for the accountable unit, not for every spawned worker. You onboard the one collaborator, maybe one agent per person, plus a thin set of standing roles like a monitor. You do not onboard the fourteen reviewers it spawns. Those inherit an attenuated slice of its contract and then die. That is attenuation doing its job, and it is why the model does not collapse under fan-out.

**What this does to the command center.** A multi-agent command center is tempting as a roster you babysit, and that framing is transitional. The durable frame is the Authority Inspector plus an exception queue: set the boundary, watch the trace, step in only when an agent raises a hand or crosses a line. Build the raise-a-hand half. Drop the babysitting half.

## The evidence

### The session

In April 2026, at Adobe Summit, C-suite and senior technology leaders from six enterprise customers spent a roughly two-hour working session designing the controls they would require before deploying multi-agent AI. The participating organizations spanned banking, healthcare, advertising, asset management, fintech, and professional services. Participants are identified in this document by role only, which is the form the primary report itself uses.

The research was developed, facilitated, and reported by Shrut Kirti Saksena, Staff Experience Researcher at Adobe Design Research & Strategy. Arnold did not run it, did not attend, and consumed the findings in July 2026. The report itself is confidential and is not reproduced here. What follows is his distillation of the findings that bear on the framework, checked against the primary report on 2026-07-17.

The value of this evidence is entirely in its independence. These leaders were not reacting to the framework. They had never seen it. They were asked to design from a blank page, and they landed on the same control set.

### The headline

Enterprise customers are ready to move on agentic AI. Governance primitives, not capability, are the deployment blocker. Participants would not allow agents into production without four controls in place.

| Control | What they asked for |
|---|---|
| Agent identity | A persistent, unique identity for every agent, separate from user accounts and API keys, tied to a named human owner who is accountable when it goes wrong. |
| Kill switch | The ability to halt a running agent mid-execution, without waiting for the current step to finish. |
| Full audit trail | Every invocation, the reasoning chain, the sources consulted, the decision at every node. |
| Cost attribution | Spend per agent, rolled up to real budgets. Participants cited an incident where a single agent generated a $20,000 bill overnight and finance blocked the deployment. |

### The four control areas

The asks organized into four areas, which the report frames as concentric layers around the agent core.

**1. Identity and access.** Every agent needs a persistent, globally unique identity, separate from user accounts and API keys. Authorization is a distinct problem from authentication: what an agent is allowed to do, scoped to data sets, capabilities, and other agents, enforced at runtime rather than as a static permission set. Every agent tied to a named human owner who is accountable when it goes wrong. Explicitly not a co-pilot model. The phrase used in the room was accountability, not co-piloting. Also raised: session versus persistent token lifecycles, agents unintentionally assuming broader identity than they were provisioned, time-boxed access, and a proxy registration model for third-party agents.

**2. Data and policy.** Data labels have to extend to what agents can do, not only to what they can read. Deterministic filtering upstream of runtime, so that certain data never reaches certain agents at all. Action labels that travel with the data: cannot export, cannot email, cannot share to a third party, regardless of who is holding it. Purpose-based access tied to the agent's inferred task intent. Regional and sovereignty controls. Agent access to external tool servers, the MCP class of connection, was flagged as a high-priority near-term risk, because proxying those servers amplifies every identity and access concern in this layer.

**3. Behavior and decisioning.** Autonomy as a configurable dial rather than a binary, set per agent and per task type: when a human must approve, when the agent may act, when it must escalate. Capability scoping that feels like provisioning a software module rather than writing a policy document. Governance context injected into the agent's reasoning at runtime, constraining it regardless of what the user asked for. A kill switch on every sensitive workflow. Agent archetypes with pre-scoped permissions. And one firm boundary: no agent reaches an end customer without a human relay.

**4. Monitoring and observability.** Full traceability, described as non-negotiable: log every invocation, the reasoning chain, sources consulted, and decisions at each node, held to the standard organizations already apply to software change logs and uptime commitments. Cost attribution and chargeback per agent, rolling up to business-unit budgets. Automated evaluation of agent output quality, covering accuracy, relevance, and data recency, surfaced so that teams can identify and retire underperformers. Tiered alerts scaled by data sensitivity and action criticality. And a proposed review surface for borderline actions that sit near a policy edge without crossing it, so that near-misses get periodic human attention instead of either blocking or silence.

The room's own priority vote landed on agent identity, authentication and authorization, human accountability, purpose-based access, full audit trail, evaluation and accuracy, kill switch, and cost attribution. The set they marked most urgent: internal access controls for agent-to-tool connections, an agent identity standard, a kill switch, a full audit trail, and cost attribution.

### Two quotes

Both are checked word for word against the primary report and attributed by role, which is the report's own convention. Dashes in the original are rendered here as commas for typographic consistency; the wording is unchanged.

"An AI agent should always be tied to a human, somebody should take accountability for it. I'm not saying co-pilot. I'm saying superpower." A marketing technology architect, CAB participant (Saksena, 2026).

"By 2030 everything is agentic and people lose their hands-on practice. You need to have a way to certify that humans are still capable of operating the system, like pilots still manually flying planes that could fly themselves." An operations executive, CAB participant (Saksena, 2026).

The second quote is doing something the framework had not accounted for. It is not about controlling agents. It is about maintaining the human capability to take over, which is a governance requirement with a training program attached rather than a permission model. That is a genuine addition from the evidence rather than a confirmation of it.

### Why this matters to the framework

The customer asks map onto the framework almost one to one, and the mapping was not arranged. It is the reason this evidence is load-bearing.

| What the customers asked for | Where it lands in the framework |
|---|---|
| Agent identity plus a named human owner | Agents as principals, three-role accountability, the identity step in the entry flow for third-party agents |
| Runtime scoping instead of static permissions, action labels | Capability versus authority, attenuation, engineering the blast radius |
| Autonomy as a dial, kill switch, approval gating | Propose, Classify, Gate, Execute, and break-glass elevation |
| Governance context injection, capability scoping | Governing the boundary rather than the process |
| Proxy registration for third-party agents | The bring-your-own-agent entry flow |
| Cost attribution per agent | Budget as the fourth durable surface, where a cap is an authority lever |

**On timing, precisely.** The framework's core distinctions were in place before Arnold saw any of this research: capability versus authority, the two planes, attenuation, the pipeline, the contract primitives. He read the findings in July 2026. Several concepts do postdate the April session, including the two-plane model's final form, break-glass elevation, powerups, agent flavors, and the boundary-versus-process analysis, and none of them were derived from this research because he had not seen it when they were written. The honest claim is not "he predicted this." It is that two independent paths, one from the design side and one from the buyer side, converged on the same control set, and that convergence is worth more than either path alone.

## The artifacts

Four things exist that make the framework concrete rather than a document. Two are prototypes and two are presentations.

### The Governed Action Pipeline

The first concrete build. It expresses the whole thesis in one visible flow, on one screen.

A mutation event moves through the pipeline in front of you: the proposed action, the risk classification with the rationale that produced it, the authority check against the delegated envelope, the gate decision with the specific rule that fired, and then either execution or escalation. Every step lands in a visible ledger.

The data model behind it carries the shape of the framework: an identified agent, a proposed action, a target, a classification with a risk tier and a rationale, an authority section stating the delegated envelope and whether the action falls inside it, a gate decision with the reason, and a status of executed, awaiting human, or rejected.

Four UI states cover the argument. Proposed, where the mutation appears classified with authority shown and the gate pending. Auto-executed, which is deliberately quiet rather than celebratory, because a governed action running normally is not an achievement. Escalated, where the human sees the rationale and an approve or reject control. And logged, where the ledger entry is immutable in the mock.

The goal was stated as a constraint: make the runtime governance model legible to a leadership audience in under a minute, using a single screen. The non-goals were stated just as explicitly. No real backend or API integration. No persistence, no authentication. Not a production approval interface. It is a thinking artifact, clearly labeled as mocked.

Two acceptance criteria carried the design. A viewer with no context has to understand the Propose, Classify, Gate, Execute flow from the screen alone. And at least one mutation has to auto-execute while at least one escalates, so that the gate is visibly doing work rather than decorating a happy path. A demo where everything is approved proves nothing, and a demo where everything escalates proves the wrong thing.

### The collaborator authority panel

The second prototype takes the Authority Inspector out of the abstract and draws it on a real product surface, which is where the argument gets uncomfortable in a useful way.

Today an agent tends to be governed the way a person is: a permission level, and a record of what it did. That is the right place to start, and it is exactly as far as it goes. A permission says which actions are switched on. It does not say how far one action may reach before a human is required, on whose authority it was granted, or what happens to that grant when the person who issued it leaves.

The panel makes the missing half visible. Where a collaborator profile shows what an agent can do and what it has been doing, meaning skills, context, deliverables, and stats, the authority view shows what it may do right now: its contract, its trust tier, its scope, its blast radius, the expiry on the grant, and the accountable owner behind it. Move the trust tier and watch the boundary move with it. That interaction is the argument in miniature, because it demonstrates that the boundary is a live property of a grant rather than a static setting in a configuration screen.

Two surfaces close the gap this panel opens. The Authority Inspector is where a person sees and reasons about what an agent may do: its contract, its reach, what it has touched. The Authority Ledger is the record of authority granted, used, escalated, and revoked. Not a compliance artifact. A queryable trace of what actually happened.

### The presentations

Two public artifacts accompany the page: a twelve-slide short presentation that runs about three minutes and makes the argument end to end, and a twenty-six slide framework deck as a PDF. Both are linked from the case-study page. The PDF predates the naming decision recorded below and still carries the earlier expansion of the acronym on its title slide, which is a known artifact of the sequencing described in that decision's consequence rather than an open question about the name.

## Positioning against the existing stack

**Status: this is a working answer, not a locked one.** It is recorded so the question does not get re-litigated from scratch every time it comes up. The wording below is a candidate to test rather than a settled position, and it closes when a version of it survives contact with a VP-level audience. Treat it accordingly.

The question that prompted it, from a senior design leader: why this and not a policy engine, or tool-protocol authority prompts, or an agent-to-agent protocol?

The working position is that DAF replaces none of them. It connects them around runtime authority. Each of them solves a piece of a problem the framework names as a whole.

**Policy engines,** with Open Policy Agent as the reference case, enforce a policy decision against structured input. The framework sits upstream of that. A policy engine is a candidate Gate. What it does not do is Classify, meaning evaluate a probabilistic agent action's blast radius and mutation type before deciding whether policy even applies. Without classification, a policy engine receives requests it cannot evaluate correctly, because the input it needs to be strict about has not been characterized yet.

**MCP** exposes a tool and handles capability negotiation. It answers "can this tool be reached?" The framework answers a different question: "is this agent authorized to use it right now, for this mutation, under this contract?" Reachability and authorization are separate properties, and treating the first as evidence of the second is a common and expensive mistake.

**A2A** connects agents and can declare capabilities. It handles the communication. The framework handles the authority chain inside that communication: how authority attenuates as work crosses agent boundaries, and how the chain stays traceable to a human root through the crossing.

Two draft one-liners exist and are explicitly not final. The technical one: a policy engine can enforce a policy decision, MCP can expose a tool, A2A can connect agents, and DAF defines the delegated authority context that decides whether an agent should be allowed to act at all. The executive one: DAF is the missing authority layer between agent capability and enterprise execution. The second is not yet tight enough, which is the main reason this question is still open.

**The claim underneath all of it,** that none of these classify a probabilistic action's consequence tier before deciding whether policy should apply, is Arnold's analysis and carries a verification requirement in his own record. It should be checked properly before it is asserted publicly as a settled fact about the market. It appears in this document as his working position, which is what it is.

**The product-market-fit framing.** Work-management platforms are already building AI that plans work and detects problems. That work runs right up to the moment an agent acts on its own, and then it stops. Governing the action is the missing half. This framework is that half. Said plainly: plan and detect is built, the agent acting is the gap, governing the action is the work.

## Where it stands

Internal platform work is now asking concrete governance questions: how agent identity should work, whether a kill switch is per agent or per organization, where autonomy configuration lives, how spend gets attributed. For each of them this framework already argues an answer. That mapping, from question to position to the product gap in between, is the working document Arnold brings to those conversations. The platform effort itself is internal and is deliberately neither named nor described here.

It is a provocation, not a finished framework, and pretending otherwise would invite exactly the wrong critique. The open questions stay visible on purpose. Who owns the organization-level envelope. What happens to delegated authority when the person who granted it leaves. How scoped credentials get issued fast enough at fan-out scale. And the hardest one, which is not technical at all: convincing enterprises to certify boundaries and audit traces instead of certifying processes.

So the ask is not a greenlight. It is a cross-functional working group to pressure-test the model against real products, with the people who own the identity layer, the platform layer, and the products the agents would run across. I drive this alone. The point of it is to stop being alone with it.

## Decision log

Six decisions shaped what the framework is and what it refuses to be. Each is recorded with its date, what was decided, what was rejected, why, and what the choice cost. The rejected alternative is usually the most useful part.

### 1. DAF is a design provocation, not a solution (2026-05-28)

**Decided:** the framework is framed as a design provocation for VP and CEO audiences. Arnold's role in it is problem-framer and tradeoff-surfacer, not sole strategist. The ask attached to it is to convene a cross-functional working group, not to greenlight a sprint.

**Rejected:** positioning it as a finished solution.

**Why:** the value is putting the authority problem on the table and surfacing tradeoffs leadership has not seen framed this way. Positioning it as a finished solution invites the wrong critique and overstates the claim. A provocation gets argued with. A solution gets audited for completeness, and it will lose that audit.

**What it cost:** decks, specifications, and public pages lead with the problem and the open questions. Known open questions stay visible rather than hidden. You give up the appearance of having answers, in rooms where having answers is how people are usually evaluated.

### 2. The first proof of concept uses mocked runtime data (2026-05-28)

**Decided:** the Governed Action Pipeline uses mocked mutation events rather than real integration with a live system.

**Rejected:** real backend integration.

**Why:** the goal is to communicate the runtime governance model, not to prove backend integration. Mocked data reaches the leadership-legible artifact fastest, and the artifact is the point.

**What it cost:** the prototype has to label its fake data clearly and document its production assumptions separately. Any claim that "it works" is forfeited, and the first question in a technical room will be about the thing that was deliberately skipped.

### 3. Pure runtime-only authority is rejected (2026-05-28)

**Decided:** the framework does not treat authority as a purely runtime concern.

**Rejected:** the runtime-only model, explicitly and by name.

**Why:** a runtime-only model would let an agent effectively self-grant governance, which defeats the entire point. Authority has to be anchored above the runtime: design-time definition, organization-set envelopes, tenant-level delegation. And the identity and registry layers underneath all of that are giant unsolved adjacent problems that this framework is meant to provoke conversation about, not pretend it has closed.

**What it cost:** an obligation, permanently. The open-questions section stays, covering design-time versus runtime authority, organization-set envelopes, tenant-level delegation, and identity lifecycle gaps. The framework may not claim it leaves identity and registry untouched. This is the decision that forced the two-plane model into existence, and it is the decision that makes the open-problems section a requirement rather than a courtesy.

### 4. Delegated Authority Framework, not Delegated Autonomy Framework (2026-05-30)

**Decided:** the acronym expands to Delegated Authority Framework.

**Rejected:** the Autonomy expansion, as the framework name.

**Why:** authority names the boundary the framework governs. Autonomy names the behavior it constrains. You cannot delegate self-direction, so "delegated" fits authority and does not fit autonomy.

**What stays:** autonomy remains a concept inside the framework, as the governed dial, the spectrum from constrained to unconstrained execution. It is what authority regulates. The closing line uses both words deliberately, and that tension is useful in the argument. It is not a reason to keep both as candidate names.

**What it cost:** the language cleanup across older files, decks, and framework copy was scoped as a separate pass, with an explicit instruction that nothing be renamed or rewritten on the strength of the naming decision alone. That sequencing is deliberate and it has a visible consequence: older artifacts still carry the earlier expansion until the pass reaches them.

### 5. How this differs from policy engines and agent protocols (2026-06-01, not locked)

**Status, carried verbatim from the record:** NOT LOCKED. This is a working answer in progress, not a settled decision. The framing and the one-liners are candidates to test, not final wording. They are not to be quoted as the framework's position. The record exists to prevent re-litigating from scratch. It does not close the question. It closes when a VP-ready one-liner survives being said out loud to a VP.

**Decided, provisionally:** the framework replaces none of the existing pieces and connects them around runtime authority. The full position is in the positioning section above.

**Rejected:** treating any of them as a competitor, and treating the question as closed.

**Why it is in the log at all:** because a question that keeps getting asked deserves a recorded answer even when the answer is not final, and because leaving it unrecorded means starting from zero every time a technical audience raises it.

**What is still open:** the executive one-sentence version is not tight enough. One piece of vocabulary in the longer framing is Arnold's own coinage rather than an industry term, and it needs careful handling with external audiences for that reason. And the strongest version of the competitive claim should be verified before public use.

### 6. Lead the leadership story with the new-hire framing, not the framework (2026-06-03)

**Decided:** for leadership audiences, the model is explained through one metaphor. Treat an AI agent like a new hire, not a new tool. You onboard it once: an identity, an accountable owner, an authority ceiling, and skills that follow from those. You manage it day to day: assign it like a person, set its rope per task, and let everything trace back to a human. The one rule everything reduces to is that an agent can never do more than the human behind it. The matrix and the framework vocabulary are backup, not the spine.

**Rejected:** leading with the framework.

**Why:** standing feedback from a senior design leader was that the work read as too framework-heavy and needed a clearer sense of who feels the pain first, told as a story rather than a taxonomy. The metaphor lands the whole model in one sentence a busy executive gets, and it scales in the right directions: onboarding, day-to-day management, a team of agents, growing them with powerups. All of those map to managing people. The framework still runs underneath. The slides just never name it.

**What it cost:** the rigor becomes invisible in the room. Leadership decks lead with the metaphor and the two moments, keep the framework vocabulary off the slides entirely, and carry the matrix as a backup for the "how does it decide" question when someone asks it. You accept that the most defensible part of the work is the part the audience does not see.

## Open problems, kept visible on purpose

These are the hard, still-unresolved problems the framework has to answer to be real and not a slogan. They are tracked in one place so they stay visible, and the status column is the useful part.

| Problem | The question | Status |
|---|---|---|
| Just-in-time credential issuance | Can scoped credentials be issued per spawned agent, fast, at fan-out scale? | Working answer forming, via break-glass elevation as a scoped credential with a time to live. |
| Inspector physical architecture | Where does the Inspector sit so it can observe every spawned agent across isolation boundaries? | Open, and now central. The liquid-harness analysis promoted it. |
| Partial-work reconciliation | A liquid harness interrupted mid-fan-out leaves a half-authorized state. The ledger has to close it out. | Open, and now central. |
| Composition policy authorship | Who writes the policy for how agents compose, and where does it live? | Candidate home is a standards surface, as guidance. The authority side is open. |
| Information-flow tagging at scale | Tracking which data class each agent saw, across a fan-out. | Open. Connects directly to quarantine-via-credential. |
| Boundary versus process certification | Convincing buyers to certify boundaries and log the trace instead of certifying a process. | Open. The hardest one, and not technical. |

Beyond those six, a set of structural questions remain unanswered, and they are listed rather than resolved.

- **Envelope ownership.** Who sets the organization-level envelope, and how does tenant-level delegation nest inside it?
- **Identity lifecycle.** What happens to delegated authority when the delegator changes role or leaves the organization? This is the question the authority panel makes visible and does not answer.
- **Cross-tenant delegation.** Can one customer's agent ever act for another customer's user, and under what construction if so?
- **The fifth component.** Is transparency and legibility a component alongside skills, tools, scaffolding, and authority, or a property all four owe?
- **Contract shape.** What is the minimum viable form a human can read in seconds, and how does a contract reference an engineered blast radius without restating it?
- **Mutation taxonomy.** What counts as a high-risk mutation concretely, and is reversibility a tier input or a separate axis?
- **Human capability maintenance.** The customer evidence raised something the framework does not currently model: how an organization certifies that its people retain the practical ability to operate the system without agents.

The reason this list is published rather than trimmed is the first decision in the log. A provocation with hidden open questions is just a pitch.

## How this connects to the rest of Arnold's work

**Unified Review and Approvals,** the shipped product work Arnold leads, is where the underlying claim is already proven at human scale. Approvals are a governance layer for execution: a person proposes, the system routes, a decision gates what ships, and the record holds. That system works, in production, for enterprises. This framework asks what that same layer has to become when the thing proposing is an agent rather than a person, and the answer is that most of the structure survives while the assumptions about speed, volume, and comprehension do not.

**AI Collaborators,** the Workfront model for agents as governed coworkers, is where the question gets concrete and where the authority panel prototype comes from. Agents are already accountable participants in a real product, with permissions and a work history, and a configurable allowed-actions list at setup narrowed the authority gap without closing it. The distinction that remains is the one this framework exists for: a permission says which actions are switched on. It does not say how far one action may reach before a human is required, on whose authority it was granted, or what happens to that grant when the person who issued it leaves. That is the depth the product's own permissions work eventually requires, and it is not a critique of an oversight.

**Sancho,** Arnold's second brain, is the same governance shape running at personal scale, every day. The model proposes, the human governs, version control records. Every file an agent writes is a proposal until he commits it. He operates daily inside the framework he is proposing, which is the cheapest available way to find out where it is annoying, where it is theater, and where it actually holds. See the Sancho dossier.

The four bodies of work make one argument from four directions: AI at work scales through legible authority, observable behavior, and a record that survives the incident. Three of them are product work with users attached. This one is not, and that is the reason it can say things the other three cannot.

## Confidentiality and provenance statement

This document contains Arnold Porras's own frameworks, synthesis, design positions, and reasoning, which are his to publish.

It deliberately excludes several categories of material. The internal customer research report is not reproduced in any form; only Arnold's distillation of the findings that bear on the framework appears, with the researcher credited by name and title. Participant organizations are identified by sector only, never by name, and participants are identified by role only, which is the primary report's own convention. Named colleagues whose feedback shaped the work are described by role rather than named. Internal platform names, internal build names, internal product metrics and objectives, unreleased product specifics, and internal development status are excluded entirely. Competitive and strategic assertions about any company's product position are excluded. Advisory and customer-board input appears in aggregate and in synthesis, never as a walkthrough of the source document's structure.

Claims that rest on external sources are attributed inline with enough specificity to check: the Harvard Business School field experiment, the World Economic Forum article, the OWASP Top 10 for Agentic Applications for 2026, Anthropic's June 2026 harness publication, the public reporting on the production-database incident, and the standards work from NIST, IETF, Microsoft Entra, Meta, and DeepMind. Positions Arnold holds as working answers rather than settled ones are labeled as such where they appear, specifically the positioning against the existing stack and the competitive claim about classification, both of which carry an explicit verification requirement in his own record and are stated here as his analysis rather than as established fact.

Nothing in this document represents an Adobe position, product, commitment, or roadmap. The Delegated Authority Framework is independent research that Arnold conducts on his own time.

Provenance: compiled from Arnold's own research and design record for this framework, spanning January to July 2026, including the origin work on the human-machine execution contract, the concept definitions, the decision records with their rejected alternatives, the evidence distillations, the open-problem tracking, and the proof-of-concept specification. The customer-evidence section, both quotes, the $20,000 figure, the session facts, and the researcher credit were checked against the primary report on 2026-07-17. One known discrepancy is worth recording: the primary report is internally inconsistent about participant count, and this document follows the case-study page in stating six enterprise customers across the six sectors named. This is a living document, and it will be revised as the framework changes, which it will.