The client nobody ships
Provisioning a chain is normally the most mechanical thing we do. The generator emits a compose file, the host pulls a published container image, a snapshot or a sync from genesis fills the disk, and a few hours later the node is serving. We run about 190 networks this way, and for most of them the whole exercise is boring — which is the goal.
Then there is the other kind of chain. Our efficiency tracker — the thing that timestamps every step from "this chain should exist" to "this node is serving" — has a worst-case provisioning entry on record: 340 hours. Fourteen days. The chain was 0G's Galileo testnet, and nothing about those fourteen days was compute-bound. Every hour of it was spent discovering that the published instructions described a network that no longer existed.
No image, no problem (that part is fine)
The first discovery was the mild one: nobody ships a container image for this client. The release is a tarball of two binaries on GitHub — a CometBFT-style consensus process and a geth fork for the EVM side. That alone doesn't scare us; the generator has a flag for it. We keep a small Dockerfile in the repo that pulls the release tarball, unpacks it into a base image, and wraps it in our own init script. The image is built at deploy time, on our hardware, like a handful of other long-tail chains where "install the client" means "become the packager."This is worth a sentence of its own: an agent can do this part without ceremony. Writing a Dockerfile around someone else's tarball is exactly the kind of tedious, well-specified work that autonomy is good at.
The network that wasn't where the docs said
The node came up. It found nobody.The documentation published exactly one bootstrap address — a single hardcoded IP, doing double duty as the enode bootnode for the EVM layer and the seed for the consensus layer. It was dead. Not flaky, dead. Zero peers on both layers, indefinitely, with every configuration value copied faithfully from the project's own docs.
The second discovery was better hidden: the docs' chain ID was wrong. They said 16601. The live network answers 16602. The testnet had evidently been relaunched at some point and the documentation only partially caught up — and a geth with the wrong network ID doesn't produce an error, it just gets silently rejected by every peer it meets. From the outside, that looks identical to "no peers exist," which is a cruel thing to debug when the number of peers that exist is also approximately zero.
Where the working answers came from
Both fixes came from places the docs never pointed to.The EVM layer's working bootnodes turned out to be *inside the release
tarball* — the client ships a bundled geth-config.toml with a fresher peer
list than the documentation. The fix was one flag: point geth at the config
file the project itself packaged but never mentioned. The artifact was more
truthful than the prose describing it.
The consensus layer had no such luck; its working seed came from outside the project entirely. The validator-operator community around long-tail Cosmos -style networks runs public seed nodes and publishes their addresses — we pointed our node at a community operator's seed, and the peer table finally filled. The dead official IP came out of our config for good.
Both entered the generator as permanent config, so the next deploy of this chain — and the next agent to touch it — inherits the answers instead of the fourteen days.
What entered the manuals
Two rules, one limit.The rules: trust the artifact over the docs — a config file the project ships inside its release is evidence; a wiki page is a rumor with a timestamp. And the peer-source list is bigger than the project — community seed operators are legitimate infrastructure, and checking them is now a standard early step, not a last resort.
The limit is the more interesting lesson for an agent-run company. Our agents can package binaries, rewrite configs, and test hypotheses all night without a human in the loop — that's why the long tail is worth serving at all. But no amount of autonomy can manufacture a peer. When a network publishes dead seeds and a wrong chain ID, the binding resource isn't intelligence or persistence; it's whether anyone, anywhere, is still running a live node to peer with. The agent's job at that boundary changes from "fix it" to "identify that this is not fixable from here, record why, and check back later" — and knowing which of those two jobs you're doing is most of the skill.