Scenarios

What governed agent work looks like, step by step.

Four walkthroughs of consequential work: a customer credit, an eligibility decision, a handoff between two agents, and an auditor’s question six weeks later. Different domains, one control pattern — identity, policy, human oversight, evidence. Each walkthrough ends where it has to: on the record that says who acted, under whose authority, and what was decided.

The control pattern

01IdentityEvery agent acts as a named workload — or as a person who delegated to it.

02PolicyEvery call an agent makes out is a decision. Default deny.

03Human oversightPolicy decides which actions need a person. Only the task that needs one waits.

04EvidenceEvery decision is sealed into a tamper-evident chain, bound to the task.

Scenario 01 The dispute that pauses itself A credit above the unattended limit stops for a person — and only that task stops. Scenario 02 Eligibility with proof of the credential The determination is gated on verified mDL attributes the applicant presents. Scenario 03 Agents delegating to agents, governed Authority narrows at every hop. Credentials never travel with it. Scenario 04 The auditor asks: what happened? Six weeks later, the chain reconstructs the task — and verifies.

Scenario 01 — customer credit remediation

The dispute that pauses itself

A cardholder disputes a charge. An agent works the case end to end — reading, reasoning, drafting — until it reaches the one action that moves money.

Task: tsk_9f2c41
Agent: dispute-agent
Identity: workload
Human in policy: card-ops approver

09:14:02 dispute-agentworkload Starts the case under a scoped workload identity, bound to this task. Not a shared API key in an environment variable: wl_dispute-ops is issued for this workload, and the credentials for the systems it touches stay at the gateway. The agent never holds them. Decision: Allow
09:14:05 dispute-agenttool call Reads the case file and ninety days of transaction context. Scope is part of the decision: read-only, this cardholder, this case. A request for a second cardholder would be a different decision, and a denied one. Decision: Allow
09:14:06 policy enginemodel call Anonymizes cardholder details in the prompt before it reaches the model. Name, card number, and address are replaced with stable tokens on the way out and restored on the way back. The model reasons over the case; it never sees the customer. Decision: Allow
09:14:31 dispute-agenttool call Attempts to open the fraud investigation notes on the linked account. Denied by deny-fraud-file@v4. Dispute handling does not include the fraud file, so the action was never authorized in the first place. The agent receives a reason and continues the case without it. Decision: Deny
09:15:02 dispute-agenttool call Proposes a provisional credit of $254.97 to the cardholder. Above the unattended limit set by credit-limit-unattended@v3. The task moves to input-required and waits. The agent’s other twelve cases keep moving. Decision: Hold
09:41:18 j.okaforcard ops · human Reviews the proposed credit and approves it. The approver sees the case, the amount, and the policy that stopped it, then decides. The approval is bound to this task and sealed into the record — it is not a message in a chat thread that someone screenshots later. Decision: Allow
09:41:19 dispute-agenttool call Posts the credit and closes the dispute. The agent resumes exactly where it paused. From its side the call simply had not returned yet — never blocked, never failed. Decision: Allow

Ends on the recordThe artifact the workflow produces.

dec_01JD7Q4M8ER5CB2X task tsk_9f2c41 · 7 decisions chain verified

Who acted: wl_dispute-ops — dispute-agent, one workload identity, seven attributed actions.
Under whose authority: Org org_northwind → card-operations policy set → human approval by j.okafor at 09:41:18, recorded against this task.
What was decided: 5 allowed · 1 denied (deny-fraud-file@v4) · 1 held and approved (credit-limit-unattended@v3). Each decision names the policy that produced it.
What the model saw: Anonymized case text. The record keeps the detection and the action taken. The cardholder’s data is never copied into it.
Integrity: Each record is HMAC-sealed over the one before it. Alter or remove any decision and the chain stops verifying.

One task, one chain: the money-moving step, the authority behind it, and the name of the person who signed for it at 09:41:18.

Scenario 02 — benefits and student services

Eligibility with proof of the credential

A caseworker hands an eligibility check to an agent. The determination turns on a credential the applicant presents — and policy will not let the decision execute without it.

Task: tsk_4ab0c8
Agent: benefits-agent
Identity: delegated user authority
Gate: verified mDL attributes

10:02:11 r.navarrocaseworker · human Delegates “check enrollment eligibility” to the agent for one applicant file. The agent acts with the caseworker’s authority, narrowed to this case and expiring with the task. This is delegated user authority: the agent cannot outrank the person who started the work. Decision: Allow
10:02:14 benefits-agenttool call Reads the application record and the program’s eligibility rules. Every read is a decision, attributed to the agent and to the caseworker behind it. Decision: Allow
10:02:20 benefits-agenttool call Attempts to record the eligibility determination. Denied by require-verified-mdl@v2. The action is gated on verified mDL attributes and none have been presented. The gate is a condition on the action itself, so no path through the workflow reaches the determination without it. Decision: Deny
10:04:39 applicantcredential presentation Presents a mobile driver’s license and releases only the attributes the policy asks for. Issuer signature checked, document validity checked, requested attributes released selectively. The program learns that the residency and validity conditions are satisfied. It never receives a copy of the license. Decision: Allow
10:04:40 policy enginere-evaluation Re-evaluates the determination: the presented credential matched the policy. Trusted issuer, unexpired document, residency attribute satisfying the condition. The rule was written in plain language and compiled to a deterministic check. The same input produces the same decision every time. Decision: Allow
10:04:41 benefits-agenttool call Records the determination and returns the file to the caseworker. The determination executes because the condition was proven at 10:04:39 and re-evaluated at 10:04:40. Before that it was denied, and it would have stayed denied. Decision: Allow

The condition

eligibility.cedarrequire-verified-mdl@v2 · default-deny

// "Only record an eligibility determination when the applicant has
//  presented a valid mDL from a trusted issuer showing in-state residency."
permit (
  principal in Aegis::Workload::"benefits-agents",
  action == Aegis::Action::"mcp:tools/call",
  resource == Aegis::Tool::"benefits.record_determination"
)
when {
  context.credential.format == "mdl" &&
  context.credential.verified &&
  context.credential.issuer in Aegis::TrustedIssuers::"state-issuing-authorities" &&
  context.credential.claims.residency == "in_state"
};

Ends on the recordThe artifact the workflow produces.

dec_01JD8B2R6TW7FQ3M task tsk_4ab0c8 · 6 decisions chain verified

Who acted: benefits-agent, acting under delegated authority from r.navarro, scoped to one applicant file and expired at task close.
The policy condition: require-verified-mdl@v2 — the exact condition evaluated, in the form it was enforced, with the denial at 10:02:20 and the permit at 10:04:40 both retained.
The credential check: Format mDL · issuer on the trusted list · signature valid · document unexpired · residency attribute satisfied at 10:04:39.
What is not in the record: No license number, no date of birth, no address, no photograph, no copy of the credential. The record proves that the condition was verified. It does not restate the applicant’s personal data.
Integrity: HMAC-sealed and chained to the preceding decisions in the same task.

A reviewer asking “on what basis was this granted?” gets the condition and the verification — the two things the answer actually depends on.

Scenario 03 — cross-boundary agent-to-agent work

Agents delegating to agents, governed

An orchestrating agent hands a subtask to a specialist agent owned by another team. The handoff crosses a boundary, so the handoff is a decision.

Task: tsk_be7103
Agents: orchestrator · contracts-agent
Protocol: A2A
Duration: 1h 47m, asynchronous

11:20:04 orchestratorworkload Opens a supplier reconciliation task and plans the work. The task is the unit everything else attaches to. Every downstream call, in either agent, carries this task id. Decision: Allow
11:20:05 orchestratora2a hop Hands the contract-review subtask to contracts-agent, across a team boundary. The hop is checked before it happens, and authority narrows as it passes: the specialist receives strictly less than the orchestrator holds, for one subtask. Decision: Allow
11:20:06 contracts-agenta2a hop Requests the caller’s credentials so it can reach the contract store directly. Denied by no-credential-passthrough@v1. Agents receive authority; the secrets stay at the gateway. A compromised specialist inherits a scope it cannot spend anywhere else. Decision: Deny
11:20:09 contracts-agenttool call Reads the contract terms for the supplier set named in the subtask. Allowed for these suppliers, under this task, for as long as the subtask lives. Decision: Allow
11:41:52 contracts-agenttask state Moves the subtask to input-required: a renewal clause needs an owner’s interpretation. Task state is a policy attribute, so the pause is enforceable rather than advisory. The subtask waits without holding a connection open, and without a callback nobody can audit. Decision: Hold
13:07:30 t.beaumontcontract owner · human Supplies the interpretation; the subtask resumes. Nearly two hours later, in the same task, against the same chain. Decision: Allow
13:07:31 contracts-agenta2a hop Returns the completed result to the orchestrator. The return hop is checked too. Nothing arrives back in the orchestrating agent unattributed. Decision: Allow

Ends on the recordThe artifact the workflow produces.

dec_01JDA0X5KPH4NS8V task tsk_be7103 · 2 agents · 1 call-graph chain verified

task tsk_be7103 — supplier reconciliation
└─ orchestrator             org_northwind · wl_orch-ops
   ├─ model calls ×6        ALLOW
   ├─ tool: ledger.read     ALLOW
   └─ a2a → contracts-agent ALLOW  (authority narrowed)
      ├─ credential passthrough  DENY   no-credential-passthrough@v1
      ├─ tool: contracts.read    ALLOW
      ├─ state: input-required   HOLD   → t.beaumont, 1h 25m
      └─ result → orchestrator   ALLOW

One call-graph spanning both agents, every hop attributed to an identity and a policy. It was reconstructed at the gateway from traffic the two agents were already sending. Neither team wrote a line of code for it.

Scenario 04 — six weeks later

The auditor asks: what happened?

Nothing went wrong. Someone simply needs to know what an agent did on a particular day, and on whose authority. This scenario has no ledger of its own — it is the record the other three produced.

The question "What did dispute-agent do on 14 March, and who authorized it?"

The answerReconstructed from the chain.

reconstruction 14 March · 1 agent · 38 tasks chain verified · 0 gaps

Who acted: One workload identity, wl_dispute-ops, across 38 tasks — every model call, tool call, and hop attributed to it rather than to a shared key that several systems could have used.
Under whose authority: Org, then workload, then the person behind each task, then the task itself. The chain of authority is written into every record at decision time. Nothing gets reassembled afterwards from four log sources.
What was allowed: Each permitted action with the policy that permitted it and the scope it ran under.
What was denied: Each refused attempt, with the rule that refused it and the arguments the agent had tried to send.
What was held, and who approved: Every paused action, the policy that paused it, the person who reviewed it, and when they decided, bound to the task they decided about.
Whether it can be trusted: Recompute the chain and it verifies, or it does not. There is no third state, and nobody has to take our word for which one they get.

The reconstruction is possible because the evidence was produced at decision time, at the gateway, by the same component that enforced the decision. Nothing had to be remembered, re-derived, or reconciled after the fact.

38 tasks, one agent, one chain — and six weeks later it still verifies.

The pattern

Four beats, any consequential workflow.

Benefits, student records, payouts, refunds — the domain changes and the four beats stay put. The agent gets an identity, every action gets a decision, the consequential step gets a person, and the whole task leaves a record that still verifies six weeks later.

Benefits decisionsThe determination waits on a verified credential attribute, and the record keeps the condition rather than the applicant’s data.
Student recordsAccess is scoped per request and attributable to the staff member who delegated it, long after the term ends.
Seller payoutsRoutine payouts run unattended; above the threshold, one person approves and the approval is part of the record.
Customer credits and refundsReading, reasoning, and drafting run unattended. Issuing the credit waits for an approver.
Records accessEvery read is a decision, and the record answers who read what, when, and under which rule.

Bring your workflow

Start with the task you would not let an agent run alone.

Describe it, and we will map it to the four beats — which identity the agent acts under, which actions are decisions, which step needs a person, and what the record looks like when it is done. A working session takes about an hour and ends with the walkthrough for your workflow.

Book a working session Request a sandbox

Agents act. Aegis governs the irreversible.Identity · Policy · Human oversight · Evidence