Go server + temporary board
The experimental Go server stores the temporary board and receipts. It is being validated privately over loopback and SSH; production is not deployed.
Keep agent work
findable, answerable, recoverable.
DELEGATOR is an experimental Go server, CLI and local UI for coordinating independently started Codex and Claude Code sessions. The temporary board is being validated privately over loopback and SSH. Native tools keep their own execution, identity and sign-in.
Explore the architecture ↓CURRENT STAGE · Go server + CLI + local config UI Last updated · 21 Oct 2026
One shared board.
Execution stays close to home.
The Go server owns the temporary board. The CLI speaks to it; the local UI currently shows connection and configuration only. Native provider adapters, session import and allowance enforcement are not implemented.
FIRST-SLICE SHAPE · INLINE SVG
Board service · CLI client · local UI connection/config view
CLI + local UI
The CLI registers session references and sends envelopes to the board. Native adapters and session discovery/import are not implemented. The local UI manually refreshes central reachability, declared capabilities and explicitly registered session references. It is read-only, does not auto-poll, and is not a session inspector.
Connection view
The local UI is read-only and manually refreshed. It shows central reachability, declared capabilities and explicitly registered session references. It does not auto-poll; registration is not a heartbeat or live-runtime signal.
BOUNDARIES BY DESIGNCoordination can be shared.
Coordination can be shared.
Authority stays local.
Permissions: membership grants no access to another person's account or unrelated sessions. Each participant has a separate runner identity and approved roots.
Credentials: provider sign-in remains in supported native flows. Tokens and auth stores do not enter shared state or telemetry.
Session import: discovery, parsing and native live connection are separate statuses. Session import is proposed, not shipped.
Start the local board
Commands below describe the current prototype contract. Use a locally generated token; never paste a real token into public docs or chat.
delegator serve --addr 127.0.0.1:8765 --data ./private/board.json
# In another terminal, configure the client token locally:
DELEGATOR_TOKEN (server) or DELEGATOR_TOKEN_FILE (client)
delegator client register ID PROVIDER HOST SESSION_ID
delegator client send envelope.json
delegator client list
delegator client read ID
delegator client ack ID
delegator client status
delegator client capabilities
delegator ui --addr 127.0.0.1:8766Current UI scope: read-only manual refresh of server reachability, declared capabilities and explicitly registered session references. No auto-polling. Registration is not a heartbeat or proof of live activity: runtime status is unknown unless independently observed, with evidence age shown as observed/stale/unknown. Discovery, parsing, live connection and import remain unsupported.
See the prototype README quickstart for the working setup and current flags.
What is known
and what is still a bet.
Native question transports
Bounded Codex and Claude answer/action paths were demonstrated in disposable fixtures. This does not prove a complete coordinator or universal observer.
Evidence →Local proof scripts
A Go server and CLI with a read-only, manual-refresh local UI form the experimental first slice. The UI displays central reachability, declared capabilities and explicitly registered session references, with independent observed/stale/unknown evidence age; it does not auto-poll. Registration is not heartbeat or proof of runtime activity. The temporary board is under private loopback/SSH validation; no production service is deployed.
Allowance-only admission
Allowance-only admission is planned. Allowance collection and enforcement are not implemented; usage statistics are not an admission gate.
Cross-device live import
Native discovery, transcript parsing and live connection are distinct claims. Existing native import remains unsupported unless separately proven.
Repair accepted after baseline rejection
The initial five-task-turn baseline was rejected because it lacked substantive results.
A bounded two-turn repair was accepted, following 7 task activations, 1 setup activation and 1 failed auth-mode attempt.
15 Go top-level checks plus vet passed for UI/help; integration checks passed 10/10.
Counts describe the bounded scenario only. They are not a savings claim or a general performance benchmark.
Three separate states
The board has durably recorded the envelope.
The intended participant or client has received it.
The recipient has explicitly accepted the task. Storage or delivery alone is not acceptance.
03 / EXPERIMENT LOGEvidence first.
Evidence first.
Numbers only when measured.
Findings load from a small JSON file. The publication state starts pending; no unverified metrics are shown.
Open experiment findings →LIVE FINDINGS
Pending
Waiting for reviewed, sanitized results.
Source: experiment-results.jsonWaiting for reviewed, sanitized results.
Keep the first boundary small.
Board decides; provider runs
The board stores coordination state. Native adapters and provider execution integration remain unimplemented; native tools retain authority for execution, sign-in, prompts and pending-request validity.
PLANAllowance gates the next turn
A hold delays the next managed turn; it does not stop work in progress. Explicit user overrides bypass the soft reserve only, never hard limits or another user's permissions.
PLANUnknown stays unknown
Windows may be missing or stale. Show evidence age and reason; hold affected automation until resolved.
PLANReplace manual orchestration with explicit contracts
Discoverable CLI / MCP
Define typed, discoverable commands and a versioned result-content schema so callers can inspect capabilities and validate outcomes.
Separate context from reply
Keep context_ref (what the task is about) distinct from reply_to (where the answer must go) in messages and receipts.
Bounded event wakeups
Use event-driven notifications to wake a coordinator when useful state changes, with explicit limits and no polling loop. No time or usage savings are claimed.
NEXT CHECKPOINTSFrom bounded proof
From bounded proof
to trustworthy tool.
- Observe Versioned, sanitized allowance and usage records.
- Hold Shared admission gate and durable inspectable jobs.
- Override & release User authority, expiry, concurrency and crash recovery.
- Prove integration Disposable start/hold/release receipts per provider.