The team that never stops
The problem with a single head
An AI agent stops for dull reasons: the session limit (the quota resets on a schedule), the context window filling up, or the machine. When it stops, the work stops, unless another can take over. You then need the state written somewhere shared, and a second agent that can read it and continue.
Two machines, four agents, one base
Two engines, Claude and opencode, each run in two places: the local machine and the online server. At the centre, the tower holds the tasks, the circuits and the shared brain.
No agent is the boss. What holds them together is the common base.
A shared brain that updates itself
The classic trap: each agent has its own memory, no one knows what the other learned. Here there is one, on the server, to depend on no one.
An agent writes, it gets pushed, an automatic guardrail refreshes the copy everyone reads. Building it, we found the old sync had been running on empty from the start: it is fixed.
The relay: when Claude hits its limit
The core. When Claude hits its session limit it stops cold. But since it wrote its state into the task and the memory, opencode takes over: same task, same memory, it continues.
Like a worksite where crews relay: no one works forever, but the site advances without interruption. The one condition: the state always written into the base.
What keeps the relay honest
A badly-run relay breaks what the last one did. Hence the guardrails, deterministic walls: a single publish path that tests and rolls back on failure; tests first as a gate; nothing off-circuit without approval.
What it does not do yet
The relay is not instant: each agent reads the base when it starts, not continuously. The memory is shared, not yet live to the second. An architecture that grows one piece at a time, but that already keeps its main promise: the team does not stop when an agent does.