The agent layer (darc → Reagent)

This is the layer the whole system exists for: a resident agent that acts on your behalf across your devices, under your inspection, bounded by capabilities you can fork and revoke. It is also — said plainly, up front — the mission and the least-built layer. Being precise about the line between what is real and what is positioning is the single most important thing this chapter does.

As-built truth. Runtime citations are repo-relative in agent54/xenon-runtime at main @b0cfc90; darc citations are from agent54/xe-darc design docs (docs/darc-cf-alpha.md, docs/injection-boundary-design.md); the capability substrate is xenon-cap / xenon-grant at the same runtime commit. Items marked PROPOSED are design, not code. The review carries the program headline and the gap register.

Primer: the words this chapter assumes

What is a resident agent? A process that lives on your computer and can see a page, decide, and act — click, type, navigate, call a tool — so you can delegate work rather than do it by hand. The sovereignty question is not “can it act” but “under whose authority, visible to whom, revocable how.”

What is a capability? A single unforgeable permission: this holder may do this verb on this resource, within these limits, until this expiry. Capability systems replace “who are you?” (identity + a big rulebook) with “what do you hold?” (a token that is the permission). See capability-based security.

What is UCAN? UCAN (User-Controlled Authorization Networks) is a capability-token format: a signed token whose issuer and audience are public keys, carrying attenuable abilities, an expiry, and a delegation proof chain — so authority can be handed onward, only ever narrowing. It is the natural external anchor for this layer’s grant/lease model.

What is the agency ladder? Our vocabulary for how much an agent is doing on a surface: observed → enhanced → mutated → controlled → driven, with shielded/permission rungs kept honest (d/082, d/091). It is a property of the agent’s action, distinct from the app install spectrum L0–L3 (d/076), which is a property of the app. The two move independently.

What is Reagent? The coming rename of darc into the productized resident agent (doctrine/vocab.md). Luke and Jan execute that rename; this chapter does not perform it and does not bake “darc” into user-facing product copy.

Zoom 1 — the honest big picture: three layers, one real, one preview, one paper

Read the agent layer as three horizontal bands, and keep them separate:

graph TB
  subgraph Future["Reagent - the resident, capability-bounded agent (PAPER)"]
    R["Reagent: lives where? sees what? acts how?<br/>enforced leases · agent://act family · BYO model"]
  end
  subgraph Preview["darc - research preview (REAL but UNBOUNDED)"]
    D["Controlled-Frame browser-as-IWA · agent sidebar<br/>only gate = human approves each tool call"]
  end
  subgraph Substrate["The capability & consent substrate (REAL, shipped)"]
    CAP["xenon-cap: Capability = resource x verb x constraints"]
    GRANT["xenon-grant: authority-signed Delegation bundles"]
    CONSENT["ConsentAttestation / ConsentStatement<br/>(used today by the companion)"]
    AUDIT["hash-chained audit ledger"]
  end
  R -.->|"stands on (not yet wired)"| Substrate
  D -.->|"will bind to"| Substrate

• The substrate is real. Signed capabilities, authority-signed grant bundles, consent attestations the companion already mints, and a hash-chained audit ledger all ship today.
• darc is real, but pre-boundary. It is a working research-preview browser that can drive pages — but the only live gate on its actions is a human approving each tool call.
• The resident, capability-bounded agent (Reagent) is paper. The design exists; the enforcement does not.

The rest of this chapter walks those bands bottom-up: the substrate that is real, the preview that is real-but-unbounded, and the delegation model (PROPOSED) that would join them.

Zoom 2 — subsystems

2.1 The capability & consent substrate (real, shipped)

This is the part of the agent layer that exists in enforced code today, and it is genuinely capability-shaped:

• xenon-cap::Capability = (resource URI × ability verb × typed constraints) with an audience, an expiry, and an onward-delegation flag, verified by verify_chain / authorize_invocation (xenon-cap/src/lib.rs:30-84). This is the atom of permission.
• xenon-grant issues runtime-authority-signed Delegation bundles to a per-install principal, grouped in a named, versioned bundle, with onward:false (xenon-grant/src/lib.rs:23-53,233-291). A grant is a long-lived, non-re-delegable permission handed to an installed app.
• Consent is not a mock. ConsentAttestation / ConsentStatement are shipped and used by the companion: the Android consent screen (devices §3.2) signs a real ConsentAttestation on approval.
• The ledger is the same hash-chained discipline the companion audit log uses — tamper-evident, per-device.

What is not wired yet, even in the substrate: the pipeline capabilities[] → plan table → minted grant is parsed but not connected to grant minting (capability-model-design.md §1), and the agent family (agent://act) is declared and audited only, not enforced. So the substrate can express agent authority; it does not yet gate agent actions on it. That is the frontier (review G-2).

2.2 darc today — the research preview (real but unbounded)

darc (Jan’s xe-darc) is a working research-preview browser built as an Isolated Web App: Controlled Frame with per-tab partitions (ControlledFrame.svelte:2057), an agent sidebar (Claude models, voice, a task queue), one-shot executeScript plus persistent addContentScripts injection, a CDP proxy, and a console.log('iwa:…') IPC channel (docs/darc-cf-alpha.md). It is the demo, and it is real.

It is also, honestly, unbounded — the capability boundary the mission requires is not there yet:

• The agent sidebar and the untrusted page share one IWA shell with no capability check between them (injection-boundary-design.md §1).
• The only live gate is a human approving each tool call in the sidebar UI (§1.3). That is a real safety property, but it is a person, not a capability.
• The CDP proxy forwards '*', so Runtime.evaluate passes unconditionally (§1.1).
• daemon/main.js is 0 bytes (§1.1, Path C) — there is no separate agent daemon yet; the agent lives in the shell.

None of the shipped runtime or companion code contains a resident AI agent at all: every “agent” in xenon-runtime is host-agent (the app-hosting substrate daemon) — a different sense of the word. Nothing there reads a page, decides, or acts on your behalf.

2.3 darc → Reagent (the coming rename + productization)

Reagent is the productized resident agent that darc becomes — the rename is Luke-and-Jan’s to execute (doctrine/vocab.md). The design that would give it a real boundary, injection-boundary-design.md, is paper only (“No code changed”). So the resident agent layer is largely future: the substrate is real, the agent that will stand on it is not. The chapter names that rather than letting the vocabulary imply a bounded resident agent exists today.

2.4 The agency ladder — rungs in vocabulary, zero in code

The ladder — observed → enhanced → mutated → controlled → driven (d/082, d/091) — is settled vocabulary. In code, zero rungs exist. The closest code-shaped mapping is the injection-boundary capability enum (read.text / read.dom / read.field / mutate.node / mutate.form / navigate.tab / inject.persistent / execute.script, injection §3.2) — and that too is paper. The ladder is a language waiting for an agent to exercise it; it is the ability-verb axis the delegation model (below) would put under agent://act.

Zoom 3 — the module that would join them: grant/lease delegation (PROPOSED)

The delegation model is where the substrate (real) meets the agent (future), and where UCAN maps almost exactly. It is PROPOSED — an outline built from the shipped xenon-cap / xenon-grant primitives, not yet a wired pipeline.

Naming note. The product delegation model is capability-model-design.md

• injection-boundary-design.md. It is not docs/delegation-interfaces.md, which is about an unrelated broker; a reader should not conflate them.

Two kinds of delegation, cleanly separated:

• A grant is a long-lived delegation — runtime-authority-signed, handed to an install principal, onward:false (no re-delegation). It says “this app may, standing, do these verbs on these resources.” This is xenon-grant today.
• A lease is a short-lived, attenuated invocation minted under a grant for one agent action — nonce, a use-binding (single-use / count / session), a not-before/not-after window, a signer, and an audit reference (injection §3.1). It says “for this action, right now, the agent may do this much and no more.”

sequenceDiagram
  participant U as You (authority root)
  participant G as Grant (long-lived delegation)
  participant A as Agent (Reagent)
  participant L as Lease (attenuated invocation)
  participant S as Surface (page / app / net)
  participant Led as Audit ledger
  U->>G: sign grant → install principal (onward:false, expiry)
  Note over G: standing permission: verbs x resources
  A->>G: request to act on a surface
  G->>L: mint lease UNDER grant (nonce, use-binding, notBefore/After)
  A->>S: invoke action bounded by lease
  S-->>A: result
  A->>Led: append {leaseId, nonce, before, after, cause, prevHash}
  Note over U,Led: you can inspect every lease-use, and revoke the grant to end them all

The UCAN mapping, made explicit (and recommended as a product decision, not an implementation detail):

The full field outline is a Part V candidate: Grant / Lease delegation model (UCAN-aligned).

Honest edges

Named here, argued in the review:

• The resident agent does not exist as a bounded process. darc is real but unbounded (human-in-the-loop is the only gate); Reagent is paper; the daemon/ is 0 bytes.
• Agent authority is declared, not enforced. agent://act is audited only; the capabilities[] → grant pipeline is unwired.
• BYO model is litmus debt. Model IDs are hardcoded in darc; sovereign model choice is a mission requirement not yet met.
• The ladder is vocabulary. No rung is enforced in code.

Links

• UCAN: spec · delegation · invocation
• Object-capability prior art: SPKI/SDSI RFC 2693 · Macaroons · capability-based security
• Agent-boundary threat framing: the lethal trifecta
• Related chapters: Devices · App model & packaging · Review