# Coder first: the terminal agent and its cloud complements

Date: 2026-08-24

Status: product assessment

The go-to-market wedge is coding. This document makes `openagents coder`

and its web-based cloud complements — the thread UI, cloud computers, and

trace viewing — first-class, and grounds the plan in the teardown corpus,

especially T3 Code, whose ambitions are the closest to ours

(`openagents/docs/teardowns/2026-07-13-t3-code-teardown.md`, the 2026-07-27

projection-consistency architecture doc, the 2026-07-17 full-catalog

synthesis, and the 2026-08-23 Entire and coder-TUI docs). It composes with

`docs/2026-08-24-registry-network-strategy.md` (why the cloud is central)

and `docs/2026-08-24-triage-and-plugin-model-assessment.md` (the plugin

mechanism).

## 1. Summary

- The market has converged on one supervision shape: engine outside the

  renderer, a versioned event seam, worktree-parallel agents, desktop and

  mobile continuity, remote steering. The full-catalog synthesis's verdict

  stands: that shape is table stakes now, and "OpenAgents wins on the trust

  half or not at all."

- T3 Code shipped the supervision half — five wrapped harnesses, an

  event-sourced projection kernel, a full mobile controller — and left the

  authority half unclaimed: no receipts, default-YOLO execution,

  environment-local threads that can never move, best-effort effect

  delivery that can lose committed work.

- OpenAgents' structural position is the unclaimed middle on session

  identity: T3 threads are trapped in one environment, Cursor's continuity

  is their-cloud-only, Amp's transcripts are cloud-canonical. A

  forge-owned thread — durable, addressable at a URL, receipted,

  consent-tiered, and exportable operator-blind — is the thing no

  competitor is structurally able to copy.

- The plan: finish the thread plane with T3's projection protocol and a

  durable effect outbox T3 lacks; ship the web thread UI as a viewer

  first and a steering surface second; make cloud computers a second

  launcher behind the one delegation contract; and render traces from

  receipts, never from Git-branch transcripts.

## 2. The competitive read

Three sources, three conclusions.

**T3 Code** (pinned at `pingdotgg/t3code`, ~531k lines TS) is a

provider-neutral control plane over other vendors' coding agents: one

local server per environment, event-sourced CQRS in SQLite, web, Electron,

and Expo clients over one hand-written RPC contract. What it proves: the

demand for one durable server-owned model consumed by every client, a

worktree-parallel default, and a phone that is a full controller (files,

diffs, Git, PTY, approvals, durable outbox) rather than a status app. What

it refuses to build: any authority story. `DEFAULT_RUNTIME_MODE =

"full-access"` maps to approval policy `never`; there are no execution or

delivery receipts; its "cloud" deliberately cannot execute or store

content — identity, reachability, and push only; and threads bind to one

environment forever.

**Cursor** validated the market for most of the 2025 demand list and then

demonstrated the trust failures to position against: two pricing crises

(usage truth invisible before the bill), an undisclosed base-model

substitution users treated as a broken contract, defaults that evangelize,

and continuity that only works through their cloud. The teardown's

sequencing lesson: mobile and continuity turned out to be the

differentiating floor, not the marketplace.

**Entire** proves demand for "why does this commit exist" trace viewing —

and proves the storage anti-pattern. It writes agent transcripts to shadow

Git branches, default-public on GitHub. Harvest the join shape (a commit

trailer linking SHA to evidence), reject the store: transcripts belong in

the database under visibility policy, and the forge WAL already carries

push receipts.

## 3. The thread plane: adopt T3's kernel, fix its weak half

The Phoenix server already owns the right objects: `threads`,

append-only `thread_events`, grants fenced by generation, THREAD-001. The

T3 projection doc supplies the protocol to finish the plane, and its own

failure analysis supplies the half to do differently.

**Adopt (T3's strong half):**

1. **One forge-owned model for every surface.** The doc's summary of its

   own strongest idea — "one environment-owned model for every client" —

   restated for us: CLI, web, and later mobile all consume the same thread

   projections. No second transcript store anywhere.

2. **The snapshot-to-live handoff.** Attach the live subscriber before

   reading the snapshot; read the snapshot and its sequence in one

   transaction; deliver snapshot, then buffered events, then an explicit

   synchronized marker, then live. Resume with `afterSequence`; overlap is

   resolved by monotonic-sequence dedup — possible duplication instead of

   possible loss. The thread events cursor that already shipped is the

   seed of this; the completion marker and the same-transaction snapshot

   are the parts to add.

3. **Shell/detail projection split.** Sidebar rows (status, latest turn,

   pending-approval count) as a denormalized shell projection so list

   surfaces never load transcripts; token streams must not starve shell

   updates.

4. **Durable admission with fingerprinted receipts.** Client-minted

   command ids recorded before execution make retries and offline outboxes

   honest — with the fix T3 skipped: a payload fingerprint, so a reused id

   with different content is rejected instead of silently answered with

   the first result.

5. **Steer, queue, and interrupt as three explicit verbs**, on the wire

   and in the composer. T3's implicit-steer keyboard seam is the named

   failure; Amp's gesture set and Codex's compare-and-set steer are the

   references.

6. **Client data states.** Connection health and data health are different

   things: `empty / cached / synchronizing / live`, cached state rendered

   during reconnect, session generations fencing stale sockets.

**Fix (T3's weak half):** provider effects in T3 ride a hot in-memory bus

with no durable cursor — a crash between "turn requested" committed and

the provider firing strands the turn forever; the teardown's verdict is

"best-effort live reactor system." The prescription, which Postgres and

OTP make natural for us: a **durable effect outbox committed in the same

transaction as the intent event** (effect id, source sequence, payload

digest, attempts, lease, status), leased workers with deterministic

idempotency keys, durable per-reactor cursors, and event schema versions

with upcasters instead of in-place event mutation. And the doc's deepest

rule, which maps directly onto receipts vocabulary: one sequence number

must never conflate the six milestones — command admitted, event

committed, effect claimed, effect completed, turn quiesced, work verified.

A `thread_events` sequence is a transcript position, not an execution

claim and not a completion claim.

## 4. The web complements, first-class

### 4.1 Thread UI

Every thread gets a URL on openagents.com, viewable live: transcript,

reasoning, tool calls, fleet state, budget. Read-only viewing ships first

— it exercises the whole projection protocol with no authority questions —

then steering (send, steer, queue, interrupt), then approvals from the

web with the same typed decision objects the CLI uses. The attention inbox

(what needs a human: approvals, questions, finished work) is the second

screen. Notifications are never completion authority.

This is the surface T3 cannot ship without ceasing to be local-only and

Cursor cannot ship without opening their cloud: a durable thread you can

open from any device *because the forge owns it*, under consent tiers

*because visibility policy already exists*, and exportable *because the

operator-blind export already ships*.

### 4.2 Trace viewing as the trust surface

The trace viewer renders receipts, not Git transcripts. Three joins make

it work: thread → issue (#10's linkage), commit → thread (an

`OpenAgents-Thread:` commit trailer, harvesting Entire's join shape onto

forge push receipts, so any SHA resolves to its evidence in one lookup),

and thread → plugin runs (digest-carrying `tool.ran` events feeding the

registry's usage counters). Public visibility follows the artifact's

transparency tier; the changelog's words-plus-receipts pattern extends to

threads. This is also where the usage-truth lesson from Cursor lands as

product: requested versus effective model rendered on every turn — #160

(silent model substitution) is not a bug fix, it is the trust surface's

first brick.

### 4.3 Cloud computers

A cloud computer is a second launcher behind the same delegation contract,

never a second work record. The coder TUI port plan's sequencing holds:

task registry, then fleet rendering, then tool renderers, with local

children first (they need no server change) and the sandbox-computer

launcher as the final slice, quota-accounted (the 275 broker shape:

leases, budgets, checkpoints, recoverable commands). The T3 projection

doc's cloud chapter names the two authority modes to keep distinct:

**owner-hosted** (the cloud stores links, grants, and awareness only —

T3 Connect's honest shape) and **managed cloud environment** (the cloud

is the environment authority owning the event log, receipts, and

workspace leases — what T3 never built and our cloud-computer lane is).

Workspace provisioning is fenced durable states, not a script.

The open architecture question the port plan already names must be

answered on the server, not worked around in the CLI: N delegated

children cannot share the account's single chat turn (TURN-001). The

durable answer is the nested-thread ledger — spawn, resume, cancel,

complete as thread-plane operations — which also gives delegation

receipts their home.

### 4.4 Onboarding and import

`npx` is the front door standard (T3's bar), and meeting users inside

their existing tool history is the import lane (Cursor's compiled-in

Claude Code import). For us that is #198 — foreign session resume — with

grok-build's caution made law: an import is a typed adapter with a source

digest and a loss report, never a skill prompt masquerading as lossless

resume, and it never activates foreign credentials or authority. As a

plugin, it is also the first proof of the registry.

## 5. Trust posture: the differentiators to ship early

From the synthesis's refusal list and Cursor's trust drops, the ones that

are cheap now and expensive to retrofit:

1. **Usage and model truth** on every surface: requested versus effective

   model, spend against grant ceilings, no silent substitution (#160).

2. **Fail-closed approvals** with typed decisions; no `/bypass/i`

   options; plugin capability declarations enforced by the sandbox

   (`docs/2026-08-24-triage-and-plugin-model-assessment.md` section 4.4).

3. **Receipts where competitors have none**: turn receipts, push

   receipts, plugin invocation receipts, and — once the outbox exists —

   effect receipts distinct from transcript events.

4. **Portable, exportable threads**: the forge owns the canonical copy,

   the owner can always take it out, and visibility is a dial, not a

   default.

5. **Signed releases with a public trust ledger** — four torn-down

   products ship broken signing; the forge's WAL anchoring work (#151) is

   the same instinct applied to ourselves.

6. **Subagent topology rendered, not hidden** — the synthesis calls the

   full agent tree "the cheapest large differentiator in the catalog";

   the coder's task registry and the web fleet view are the two renderers

   over one canonical graph.

## 6. Sequence

Ordered, composing with the strategy doc's priorities (its items 1–2

are this list's items 1 and 3):

1. **Thread persistence and resume in the CLI** — the client writes

   `turn.user`, `turn.reasoning`, `tool.ran`, `turn.assistant`; `--resume`

   replays through the cursor. (Unblock monorepo #19 first.)

2. **Web thread viewer** — read-only thread pages over the same

   projections, with the snapshot-to-live protocol and shell/detail

   split. Fixes #164's class of gap (reasoning and tools visible) on the

   web at the same time.

3. **Plugin contract v1 and pilot** — per the plugin assessment; runs

   land as receipted thread events feeding the trace viewer and registry.

4. **Durable effect outbox and the six milestones** — the thread plane's

   execution half, prerequisite for honest delegation receipts.

5. **Web steering and approvals** — the composer verbs (send, steer,

   queue, interrupt) and approval decisions from the browser.

6. **Nested-thread ledger** — server-side spawn/resume/cancel/complete;

   delegation receipts become real.

7. **Cloud computer launcher** — the port plan's final slice behind the

   delegation contract, quota-brokered, with the owner-hosted versus

   managed-environment authority split explicit.

8. **Trace viewer and commit-trailer join** — receipts rendered publicly

   under tiers; any SHA resolves to its thread.

9. **Mobile controller** — last, on the same projections and outbox

   pattern; T3's mobile teardown is the reference for breadth, our

   authority model for the difference.

## 7. Relation to other documents

- `docs/2026-08-24-registry-network-strategy.md` — why the centralized

  cloud and the registry are the strategic center this product plan feeds.

- `docs/2026-08-24-triage-and-plugin-model-assessment.md` — the plugin

  mechanism, the owned WASM host, and the 2026-08-24 backlog triage.

- `docs/2026-08-23-openagents-coder-cli-spec.md` and

  `docs/2026-08-24-coder-account-integration-audit.md` — the coder's

  architecture and the account-integration gaps this plan sequences.

- `openagents/docs/teardowns/2026-08-23-openagents-coder-tui-agent-fleet-port-plan.md`

  — the CLI-side fleet plan this document adopts and extends server-side.

# The registry is the network

Date: 2026-08-24

Status: strategy synthesis

This document records the strategic synthesis behind the current push: a

centralized cloud whose network effect comes from consensually collected

usage data feeding a central plugin registry that grows and evolves on that

data — with the coder as the wedge, the forge as the substrate, and WASM

plugins as the unit of accumulated capability. It extends

`docs/2026-08-24-triage-and-plugin-model-assessment.md` (the mechanism) with

the strategy that motivates it, and it resequences one conclusion of

`docs/episode-triage.md` (section 12). Sources: the full episode triage,

the 2024 plugin-economy arc (episodes 048–102, 165), the last-mover thesis

(episode 269), the Pylon history and its surviving code, the Omega-era

plugin tool specification

(`openagents/docs/omega-agent/2026-07-27-plugin-tool-spec.md`), and the

economics analysis in

`openagents/docs/fable/2026-07-19-some-simple-economics-of-agi-deepdive.md`.

## 1. Summary

- Every failed OpenAgents market broke one leg of the same three-legged

  stool: a named buyer, verifiable usage, and settlement. The centralized

  cloud supplies the two legs the 2024 Agent Store lacked — verifiable usage

  and a real buyer — and the coder is that buyer.

- The moat variable is verified network scale: usage counters that are

  receipts, not claims. Only a center of ground truth produces that.

- The Codifier's Curse gives the recruiting pitch: expertise is being

  codified into someone's training data regardless; the registry is the

  attribution ledger that makes codification pay its author instead.

- The registry needs no new service. A plugin is a forge repository with a

  typed manifest and a digest-pinned release. The forge already provides

  identity, versions, receipts, issues, and — later — bounty rails.

- One plugin contract serves three hosts (TypeScript CLI, BEAM server, Rust

  substrate), on an owned, reduced-surface WASM host rather than a

  dependency on any third-party plugin framework.

- One npm install carries the whole loop: spend (coder), contribute

  (plugins), and eventually earn (wallet plus provider mode, rebuilt from

  the surviving Pylon code under the pay-for-verified-work laws).

- Payments stay deferred, with one deliberate exception: a single

  end-to-end bounty settlement proof, run once before any royalty plumbing.

## 2. What the failed markets settled

Read across episodes 199–275, each dead market isolates one missing leg:

| Attempt | What it had | What killed it |

| --- | --- | --- |

| GPutopia (2023) | Sellers | No buyer |

| Pay-for-online mining | Payment | No verification; gamed within days, retired in episode 224 |

| 2024 Agent Store (episodes 048–102) | Supply, payouts, 20 paid developers | No demand: "we didn't really have the use case for which people were willing to actually pay" (episode 165) |

| tbDEX | Protocol | No runnable operator software |

The standing laws distilled from these (all already on the record in

`docs/episode-triage.md`): name the buyer first; rewards follow verified

work, never presence or volume; authority stays inspectable and exit stays

possible.

A registry that "grows and evolves on shared data" is a market, and it needs

all three legs. That is the argument for the center.

## 3. Verified thickness: why the cloud is the moat

The economics analysis identifies the durable platform variable as

**verified network scale** — the share of activity credibly authenticated as

real, times raw scale. "Apparent thickness can often be generated with

compute, but verified thickness cannot."

A decentralized registry of signed listings — the shape proposed in episode

066 — produces raw scale: anyone can list. It produces nothing on the

verified share, because no one can observe usage. A centralized cloud where

every plugin run lands as a `tool.ran` event on a durable thread transcript,

carrying the plugin's digest, makes every usage counter a receipt. The

registry's data advantage is not "the most plugins." It is "usage numbers

that are true," in an ecosystem where everyone else's are unverifiable.

This is also why the coder's thread persistence work is not just UX: the

thread transcript is the unit of consensual data collection. Nothing

accrues until the CLI writes its transcript to the server

(`docs/2026-08-24-coder-account-integration-audit.md` already decided the

server copy is the only copy).

## 4. The Codifier's Curse and the attribution ledger

The same economics paper names the dynamic that supplies the registry's

recruiting pitch. Every act of expert work with an AI system codifies that

expert's tacit knowledge into someone's training data, and withholding is

irrational — codification is a global prisoner's dilemma that proceeds with

or without the expert's consent.

Episode 269 found the answer before the paper named the problem: "solve a

painful problem once ($30 of compute and an hour), package it as a plugin

all future agents reuse, get paid when paid workflows route through it."

Stated as a pitch: your expertise is being codified either way — into a

frontier lab's weights as anonymous gradient dust, or into a digest-pinned

plugin with your name on it and a royalty hook. The registry is the

**attribution ledger** that turns the curse into the dividend economy

episodes 200 and 223 promised (skill royalties, data royalties, compute

dividends). Attribution accrues now, from the first recorded run;

settlement over that record resumes later without a schema change.

## 5. Consent is applied policy, not a new build

"Consensually collected" does not require new machinery. The pieces exist:

- **Transparency tiers** (episode 272): Dark, Pulse, Ledger, Glass —

  designed as a per-artifact visibility dial.

- **Opt-in trace licensing**: the triage's own simplification of episode

  245's trace economy ("simplify to opt-in trace licensing tied to

  visibility policy before any royalty plumbing exists").

- **Operator-blind export**: `GET /data/export/account?recipient=age1…`

  ships (#178), proving the exit half of the consent story.

The work is applying the existing tier model to two new artifact classes —

thread transcripts and plugin usage — and building the opt-in gate before

the collection volume, not after. Consent-first is what makes the

centralized cloud defensible rather than extractive; it is the difference

between the registry and the curse.

## 6. How the registry evolves: three loops

"Grows and evolves based on shared data" means three concrete feedback

loops, in order of arrival:

1. **Selection loop.** Usage receipts plus outcome signals tune which

   plugin the capability selector surfaces for which request. Optimization

   is bounded and offline in the DSE/GEPA style, under the standing law:

   an optimizer output is a candidate, never a deployment.

2. **Gap loop** — the network-effect engine. A capability search that finds

   nothing is a demand signal. File it as a scoped forge issue

   automatically; price it as a bounty when settlement resumes; a

   contributor — human or agent — builds the plugin; the registry grows

   exactly where demand proved out. This is episode 211's

   record-feature-request tool generalized from features to capabilities,

   and it is only possible when search, issues, bounties, and the registry

   share one database.

3. **Promotion loop.** The long ladder: plugin → model-directed plugin use →

   distilled specialization. Aggregate invocation traces are the training

   data for eventually moving popular plugin-orchestration patterns into

   model behavior. Only a centralized trace corpus makes that trainable.

## 7. Why the forge is load-bearing

1. **The forge supplies the buyer the 2024 store never had.** The coder

   works against forge issues; repository → issues → code → plugin is one

   graph in one authority domain. Coding is the proven

   willingness-to-pay category — episode 165's own retrospective says it is

   why OpenAgents went to coding agents.

2. **Plugins are forge repositories.** A plugin is a repo with a manifest

   and a digest-pinned release artifact. The forge already gives identity,

   versioning, history, WAL-anchored receipts, issues, and later bounty

   rails, per repository, for free. The registry is a typed index over

   forge releases plus semantic search in the CLI — not a new backend.

3. **GitHub parity is the consensual data on-ramp.** One-command import

   brings the code and the issue graph to the center with the user's

   intent, not by scraping. `gh` and octokit compatibility means existing

   agents already know how to operate the surface.

4. **Receipts land where the work happens.** The triage's clearing-house

   thesis states it: the forge wins "because it is where all five clauses

   can share one database, one audit trail, and one public API."

5. **Exit legitimizes the center.** AGPL, mirrors, encrypted exports, the

   exit rehearsals. The episode 230 ideal — no single front door — survives

   as a later federation option on the relay/provider-daemon/skeptical-client

   market shape, once there is verified thickness worth federating. The

   center wins by being better, not by locking.

## 8. One plugin contract, three hosts

The plugin contract adopted in

`docs/2026-08-24-triage-and-plugin-model-assessment.md` is the same

contract the Omega plugin tool specification distilled from the 2024

economy, and it holds across every host:

- The model owns decision logic: which plugin, which export, what

  arguments, when to retry, when to stop.

- The runtime owns the execution contract: loading, digest verification,

  capability mediation, time and memory ceilings, cancellation, receipts,

  typed refusals.

- The plugin owns the black-box capability implementation, behind typed

  input and output schemas.

- Identity is content-addressed: plugin id, version, artifact digest,

  export, ABI version. No invocation is attributable without them.

- Discovery may be semantic; invocation is an exact name from the

  installed catalog. A plugin result is evidence, never write authority.

The payoff of one contract: **one artifact, three hosts.** The TypeScript

CLI (the coder), the BEAM server (server-side execution for chat), and the

Rust substrate all speak the same packet ABI against the same digest-pinned

artifact. The registry serves all three.

### Own the host

Extism — the runtime the 2024 economy ran on — is no longer a dependency to

build on; the direction is an owned, reduced-surface host, adapting Extism

source where useful (BSD-3-Clause permits it with attribution). The reduced

surface:

- One ABI: `handle_packet(bytes) -> bytes | typed refusal`, schema ids

  layered above, versioned (`packet.v1`).

- One guest path: an owned Rust PDK. Other guest languages only if demand

  appears.

- Host imports, total: log, allowlisted HTTP, KV get/put, read-only path

  mounts. Nothing else.

- Three thin hosts: Node (plain `WebAssembly` API plus owned shims),

  Elixir (a small wasmtime NIF), Rust (wasmtime directly), behind a

  host-owned engine abstraction so no engine is load-bearing forever.

- Enforcement: digest verification before load, timeout/memory/fuel

  ceilings, typed refusals, a receipt per invocation.

The contract is the owned thing; engines stay swappable.

## 9. One install, the whole loop

The target: `npm i -g @openagentsinc/cli` delivers spend, contribute, and

earn through one identity.

- **Spend**: the coder — clone, traverse, turn intent into issues, code,

  use plugins — against forge threads and receipts.

- **Contribute**: build and publish plugins as forge repositories; the gap

  loop hands contributors pre-validated demand.

- **Earn**: a wallet and, later, provider mode — the machine serves

  verified work while its owner is away, and gets paid.

The earn half is proven code, not a dream. The Pylon arc (episodes

201–224, 236–238, 244–245) shipped and validated, at 1,300+ nodes and over

1M sats paid:

- A presence/capacity service that already encodes the

  capacity-as-quantity lesson (advertise amounts, not existence).

- A complete claim → lease → submit-trace → validate → settle loop, with

  the right doctrine attached: a lease is not an earning claim; only a

  settlement receipt is.

- One-seed identity: BIP-39 → Nostr keypair plus deterministic wallet,

  confirm-before-spend.

- A multi-earning ledger (modeled/observed/pending/paid/settled), inert by

  default.

- A local serving runtime (Apple Foundation Models bridge,

  OpenAI-compatible client, digest-verified model installer).

- The distribution pattern itself: paste-into-your-agent enrollment.

Constraints any revival inherits from the do-not-build register: never

presence-based rewards; no hosted custody; no NIP-90/DVM revival — an open

market transport, when it comes, uses the relay/provider-daemon/

skeptical-client shape; buyer first. The first buyer for idle machines is

OpenAgents' own operation: delegation children from other users' coders,

validator-replay jobs (verification is ideal away-from-keyboard work), and

the registry's own service jobs — embedding manifests for semantic search,

replaying plugin receipts, running conformance and eval suites. The

registry creates the compute demand that pays the machines that verify the

registry.

One open decision to make explicitly rather than inherit: the wallet rail.

Episode 235 retired hosted custody for the self-custodial stack, while the

shipped Pylon v1.0 made the deterministic Spark wallet primary and a later

owner decision preserved it as a live rail. The keeper either way is the

one-seed derivation; the rail needs a named decision.

## 10. What is newly possible now that was not in 2024

1. **Demand exists.** The coder is buyer number one; coding agents are the

   proven willingness-to-pay category.

2. **Ground truth exists.** Threads, receipts, the forge WAL — usage is

   observable server-side, so the verified share is real.

3. **Consent machinery exists.** Tiers, licensing framing, operator-blind

   exports.

4. **Settlement exists, dormant.** Self-custodial wallets, the treasury,

   tips proven end to end (episode 235). The plumbing survives; only the

   policy is paused.

5. **Distribution collapsed to one command.** 2024 needed a web platform;

   2026 rides npm plus paste-into-your-agent.

6. **The window is open.** Episode 269's reading strengthens monthly:

   models, harnesses, and chat surfaces commoditize; nobody has a network.

   A verified capability registry is a network, and the last-mover position

   only works if the ledger is accruing while everyone else fights over

   harness features.

## 11. Priorities

In order:

1. **Thread persistence and resume** (in flight). The transcript is the

   data substrate; nothing accrues until the CLI writes it. Monorepo #19

   (the failed-closed release gate) blocks everything here and goes first.

2. **Plugin contract v1, owned host, pilot.** The packet-ABI contract, the

   reduced Extism-derived host, and foreign session resume (#198) as the

   first real plugin.

3. **Consent and usage receipts before scale.** Plugin runs as

   digest-carrying thread events; transparency tiers applied to threads

   and usage; sharing opt-in.

4. **Registry on the forge.** Plugins as repositories, digest-pinned

   releases, a typed index, semantic capability search in the CLI, and the

   gap loop: failed searches file issues.

5. **One settlement proof.** One bounty-labeled issue, priced in sats,

   claimed, verified, paid end to end — once. This deliberately reopens a

   sliver of the economy lane closed in the 2026-08-24 triage, as a proof,

   not a program.

6. **Wallet and identity in the CLI.** One seed → identity plus wallet;

   rail decision made explicitly; receiving before spending.

7. **Provider mode.** Port the Pylon presence and claim/validate/settle

   loop into the CLI; OpenAgents fleet as first buyer; verification jobs

   first, inference second; pay-for-verified-work only.

8. **Selection-policy evolution.** Tune capability search from usage data

   once volume exists — candidates, never auto-promotions.

Deferred on purpose: open federation of the registry, third-party royalty

programs at scale, and anything shaped like five markets on a weekly

cadence.

## 12. Resequencing note against the episode triage

`docs/episode-triage.md` contains every piece of this synthesis — the six

stations, the episode 269 dust-off, the do-not-build register — but files

the skill/plugin registry as the furthest-out station ("recruitment"),

gated behind everything else. This document moves it to the center: the

registry is the thing the coder, the forge, the consent machinery, and

eventual settlement all feed, and its non-monetary half (attribution,

usage receipts, the gap loop) starts accruing value now. The stations

stand; the sequencing changes. The triage's settlement doctrine — royalties

only after settlement works once at bounty scale — is preserved as

priority 5 above.

Date: 2026-08-24

Status: initial assessment

Status: initial assessment. The strategy that motivates the plugin model —

the registry as the network, the centralized cloud as its verification

substrate, and the coder as the wedge — is recorded separately in

`docs/2026-08-24-registry-network-strategy.md`, which also resequences the

priorities in section 6 of this document.

This document records two things done together on 2026-08-24: a triage pass

over every open issue in `OpenAgentsInc/openagents.com` and

treasury — end to end, once — then the loop becomes policy instead of

stunt.

> **Resequencing note (2026-08-24).** The recruitment station below files

> the plugin/skill registry as the furthest-out surface, gated behind the

> others. `2026-08-24-registry-network-strategy.md` moves it to the

> center: its non-monetary half (typed manifests, digest-pinned versions,

> usage receipts on thread transcripts, capability-gap issue filing)

> starts now and feeds the coder, the forge, and consent work directly.

> The settlement doctrine below — royalties only after one bounty settles

> end to end — is unchanged.

**Recruitment station: the flywheel surface.** Verified outcomes recruit both

humans and agents when they are visible and portable: public traces under the

visibility policy, licensable later (228, 215); the leaderboard (260, 270);