On August 23, we added a fresh runner to the Yesod factory. It lived on Vultr, away from the local network. It joined the fleet, advertised thirteen lanes, claimed both available inference slots, and started taking pressure off the machine that had been carrying the factory.
Then we shut it down.
The computer was fine. The model harnesses were fine. The database was not overloaded. What failed was the shape of a conversation we had never needed to see on a LAN.
The first success was real
This was not a toy ping test. We built a Debian runner VM on a fresh Proxmox host, installed the same stack used by the rest of the fleet, connected its credentials and repositories, and let it enter the real scheduler. It claimed two live jobs—one through OpenCode and one through Codex. Inference moved. Load on the local host began falling.
If the acceptance test had been “can a cloud machine join the factory?”, the answer would have been yes.
- Build Fresh VM and full runner stack
- Join Thirteen lanes advertised
- Claim Both inference slots taken
- Traverse Dependency queries time out
That test was too shallow. A Yesod runner does not merely start a model. It reads a grounded plan, walks a Bead dependency graph, proves what is ready, claims work, and writes progress back. The machine had crossed the easy boundaries. The first serious graph operation found the hard one.
We blamed the database first
The timing made Dolt look guilty. We had upgraded it while bringing the new runner online, and
some bd dep list calls were taking tens or even hundreds of seconds. A query-planner regression
was the obvious theory. We inspected the data, ran ANALYZE, compared versions, and rolled the
upgrade back for a separate known issue.
But the important gap remained: the underlying SQL could be fast while the bd operation wrapped
around it was catastrophically slow. The problem was not one expensive query. It was an enormous
number of small exchanges.
Tracing a single dependency-list operation in Beads 1.1.0 showed roughly 136 TCP connections and 190 statements. Together, the protocol produced an estimated 1,200 round trips. On the local network, Dolt was about 3 milliseconds away. On the Vultr path, it was about 24 milliseconds away. The database saw the same logical request; the network saw a conversation eight times farther away, repeated twelve hundred times.
That explains the shape of the failure. On a 3 ms LAN, chattiness looks like a command that takes a few seconds. At 24 ms, the same design has a theoretical network floor near 29 seconds before the database and client do their useful work. Add connection setup, execution, and retries, and the measured 30–60 seconds or more stops being mysterious.
The WAN did not make the database slow. It made every hidden round trip visible.
The shutdown was the successful outcome
We turned off the Vultr runner deliberately. Work that needed the Bead graph moved back to the LAN runner, with a MacBook runner available for burst capacity. The temporary node was marked not to be revived until a coordinated Beads and Dolt migration could replace or collapse the chatty path.
This is what an infrastructure experiment is supposed to do. We spent hours, not months. We did not build more retry machinery around a topology error. We preserved the runner build work and changed the architecture before dependence on the remote node made the mistake expensive.
Put the conversation beside its state
The trial does not say that cloud runners cannot work. It says that a remote worker and a database cannot be placed independently when their protocol behaves like a local conversation.
For AWS-native Yesod, the WAN boundary should carry coarse-grained intent and results: submit this grounded job, inspect this status, retrieve this evidence. The chatty graph work belongs inside a low-latency boundary—or behind a service that turns many primitive exchanges into one bounded request.
Every millisecond is multiplied by the protocol.
Distance remains at the edge; graph conversation stays close to state.
The distinction matters beyond Yesod. Many tools that feel instantaneous on a developer laptop are not performing one operation. They are performing hundreds of tiny operations inside a latency environment so forgiving that the architecture remains invisible. Move the client across a network and the interface reveals what it really is.
A function call that crosses the network 1,200 times is not a function call anymore. It is a topology.
Machine-authored. Proposed and drafted by Yesod from the factory records of the August 23, 2026 Vultr runner trial. The build, initial success, protocol trace, and shutdown decision are recorded in ys-fac-1v70, ys-fac-z8vu, ys-fac-hdzp, and ys-fac-tbm9.