Pegasus Exchange Case Study

Operational problem

“Sent” was not the same as accepted, working, or complete.

Cross-computer agent coordination exposed failures that a simple request API could hide: writer locks, wake attempts mistaken for acceptance, work queued but never processed, acknowledgement loops, stale presence, long-running targets blocking mailbox work, and huge task histories overwhelming a bounded delivery path.

Constraints

Exact identity and truthful state had to survive interruption and concurrency.

Exact-task local-first peer routing with stable correlation and no ambiguous recipient fallback.
FIFO journals, idempotency, bounded retries, strict UTF-8 framing, and no acknowledgement loops.
Distinct stored, claimed, accepted, working, final, failed, busy, offline, and waiting states.
Cursor-based bounded history access rather than unbounded owner-task retrieval.
Receipt and result projection must continue while target work runs.
Desktop, node, CLI, installer, and Agent Bridge must share compatible lifecycle contracts.

Architecture & tradeoffs

Separate durable dispatch, task execution, and observable state.

Exact recipient

Stable task identity and correlation define one bounded delivery target.

Peer relay

Journals, idempotency, bounded retries, framing, and cursor APIs protect transport and recovery.

Concurrent execution

Long-running target work does not block mailbox receipt, status, or result projection.

Lifecycle states

Accepted, working, final, busy, offline, and other states remain distinct instead of collapsing into “sent.”

Sanitized conceptual view. Addresses, ports, task identities, network topology, authorization material, and message bodies are omitted.

What Shayne owned

Failure discovery, routing boundaries, and live acceptance.

Failure analysisSurfaced writer locks, false wake states, loops, stale presence, blocked delivery, and oversized history responses.

Boundary definitionSet the same-computer native versus cross-computer relay boundary and required exact recipients and stable correlation.

Truthful lifecycleRequired bounded retries and distinct accepted, working, final, busy, offline, and unresolved states.

AcceptanceDirected deterministic regression coverage, packaging, and real two-computer checks while preserving candidate-versus-accepted status.

AI role

Multi-agent implementation with one systems acceptance boundary.

Specialist agents contributed implementation, protocol work, testing, packaging, diagnosis, and review. Shayne retained the transport and authority boundaries, failure reproduction, state-model corrections, prioritization, architecture decisions, and final live acceptance.

Verification

Established evidence and current candidate evidence are kept separate.

Accepted regression baselineShared checks support the established live checkpoint.

Bridge and setup coverageAgent Bridge, setup, and Desktop integration were exercised together.

Manifest integrityThe current package matched its admitted manifest.

Multi-megabyte → kilobyte-scaleA focused history-boundary probe demonstrated a sharply bounded response path.

An earlier matching release completed two-machine LAN acceptance with zero build warnings and errors. The newest scheduling correction is currently a candidate scheduled for renewed two-machine acceptance.

Result & next stage

A substantial local-first relay advancing through renewed acceptance.

The broader implementation has accepted packaged and two-computer evidence. The newest concurrency correction is queued for renewed two-computer acceptance. Large owner-task delivery is the next scaling target, while ARM64 remains a later platform phase.

The size reduction records one focused history-boundary probe. The earlier release retains the live-verified maturity label; the newest correction remains in candidate validation.

Pegasus Exchange.