Architecture

How a message becomes handled work.

Five stages sit between an inbound signal and a finished task — channels, triage, a human gate, a swappable execution engine, and the two surfaces that show the result. Every hop is inspectable; nothing moves in the dark.

The pipeline

One spine, five stages

Channels feed a triage stage, triage feeds a human gate, the gate hands approved work to a swappable execution engine, and the engine writes to the two surfaces you actually look at. The lane colors are the same grammar used everywhere else in this system.

Channels iMessage Email SMS Webhooks one adapter interface Intake & Triage Classifier Entity extraction Tickets skillsets register watch-rules here Switchboard the human 5-second gate done · snooze · kill · escalate Execution Engine Work packets Gates — shape · scope · tests one contract pi Claude Codex The Board queue · full history every packet, every run The Desk verbs · the short human list five-second decisions only
Vermilion — the inbound path, before a human touches it Brass — the Switchboard gate, and the Desk it feeds Teal — the machine path, out to Board, Desk, and runners
Subsumption-resistance

State lives one layer down

Every ticket, packet, receipt, and piece of run history lives in the platform's state layer — not inside whichever agent happens to be running it. Runners are stateless executors that read and write against that shared state; pi, Claude, and Codex all speak the same contract, so none of them owns the record.

Swap the runner mid-run, close a laptop, kill a session — the work and its history survive untouched, because none of it was ever stored in the runner to begin with.

pi Claude Codex State tickets · packets · receipts · history

Swap the runner mid-run — the ticket, its history, and its receipts don't move.

The pipeline, three stages

Inbound, processed, verified by a person

Collapse the spine above to the three moments that actually matter: a signal arrives, the system does the reading no one wants to do, and a person makes the one call that's genuinely theirs to make.

01 · Inbound

Every channel, one door

iMessage and email land in the same event stream through one adapter interface. Adding a channel never means rebuilding the pipeline behind it.

02 · Processing

The reading nobody wants to do

A classifier scores the signal, pulls out people, dates, and amounts, and assembles a ticket. Skillsets hang their own watch-rules on this stage without touching the pipeline itself.

03 · Human verification

The one call that's actually yours

Work that genuinely needs a person lands on the Desk as a short, prioritized list — a five-second verb, not another inbox. Everything else moves on without waiting for anyone.

Receipts

What a hop leaves behind

Architecture isn't a diagram you have to trust — every stage above writes something down. Three examples of what that looks like in practice.

Ledger
TP-424 email intake → triage UI · running · step 2/4
commit a91f3c2 · attributed · shape ✓ scope ✓
Delivery
message → mac-node · delivery ack
read_by confirmed · receipt logged both directions
Gate
packet gate: shape ✓ · scope ✓ · tests claimed ✓
a completion without this trio reopens, it doesn't count
Nothing moves in the dark

The evidence stack

"Evidence or it didn't happen" isn't a policy — it's a gate. A six-section pre-commit hook rejects any commit that closes work without shape, scope, and test evidence. A packet verifier blocks fake-done. An evidence ledger audits every claim. The system enforces its own receipts.

Gate 1

Pre-commit: six checks

Tests, proliferation scan, secret scan, template validation, agent/skill count parity, and cross-device path guard — all before git commit returns. A bulk scope review catches accidental peer-file scoops in shared worktrees.

Gate 2

Packet evidence gate

A work packet can't close without linked evidence — commit SHA, test output, or review verdict. The verifier rejects packets that would mark done without that trio. Closing a ticket is not the same as finishing the work.

Ledger

Evidence ledger

Every durable claim — in audit docs, decision records, or architecture pages like this one — is backed by a recent tool capture. The ledger records the source reads; writes without a recent capture trigger a warning.

Subsumption-resistance in practice

The patch ledger

When a frontier lab ships a better harness, a monolithic wrapper gets absorbed. Moneypenny carries a different posture: a classified patch ledger of deliberate vendored modifications, each tagged with its upstream status. When the harness improves, we delete our patch. When it structurally can't, we fork deliberately — and the ledger proves which is which.

Mechanism

Each patch is classified into one of five labels: structural-keep (the harness will never ship this), upstream-PR (submitted, waiting), upstream-shipped (delete on next upgrade), fork-pressure (we need it, they don't want it), and retired (superseded).

An apply script runs on every deploy. It probes each patch with sentinel strings — if the target already has the behavior (upstreamed), the patch is silently skipped. If hunks fail, a diagnostic names the exact file and suggests a regeneration path. No silent failures.

The resilience ladder underneath — degrades away from any single provider: codex → pi → foundry → local models. A provider outage degrades the reasoning step down the ladder, never to a no-op.

Vendored Patch structural-keep upstream-PR upstream-shipped fork-pressure retired Apply Script sentinel check → forward/reverse → diagnostic

Every deploy probes every patch. Upstreamed patches are auto-skipped; failures produce exact regeneration instructions.

Go deeper

Two more angles, one demo

Honest about what's not here yet: iMessage and email are the two live channels — SMS and webhooks are drawn because skillsets register against the same adapter interface, not because either is wired in. The email importer (TP-424) is still red. Board and Desk records on this page are illustrative, not a live feed of your system.