Your agent can write code, call tools, and reason about your infrastructure. Then it hits a wall: it cannot reach the machines. Every tool that would fix that asks it to open a browser and make an account. WireHop doesn't.
The same task, with a hosted tool and with WireHop. The difference isn't speed, it's whether the agent has to stop.
Four handoffs. The agent stops at step two and asks you to finish, which is the opposite of why you gave it the task.
No handoffs. Nothing to sign up for, nothing to click, nobody to wait on. The agent finishes the job it was given.
This isn't an accident of packaging. WireHop has no coordination server and no accounts by design: identity is a keypair written to disk on first run, and membership is a document your machines gossip among themselves. There is no console to click through because there is nothing to click through to.
Two machines, four commands, no human. Everything speaks JSON so an agent never has to scrape output.
Errors are structured too. A failure prints one JSON envelope with a code, a retryable flag, and a hint, so an agent can decide whether waiting will help instead of guessing from a string.
"An agent can set it up alone" is checkable, so it's a test that runs against every build.
Two bare Linux containers, no WireHop installed, no human reachable. A real language model gets exactly one tool, "run a shell command on machine X", and is asked for a working private network plus one command that runs across it. Then the harness throws away whatever the agent claimed and inspects the containers itself: is the binary really there, does a command issued on one machine really execute on the other, do both hold a virtual address, does a packet really cross between them, does a fleet-wide command really come back.
It scores by capability rather than by name, because the agent picks its own hostnames and roles. An agent that declares victory over a dead network scores zero.
The harness is tests/e2e/agent-coldstart.sh in the repository, so you can run it against your own model rather than take our word for the result.
Two pieces: one that teaches an agent when to reach for WireHop, one that lets it operate your machines once it has.
The skill is plain markdown: when to use WireHop, the bootstrap above, and how to scope an invite so an agent gets the least access that does the job. Works in any framework that reads a skill file.
A local tool server, running under your own identity. Nothing is hosted and nothing takes custody of your credentials. Add it to your agent's config and the fleet becomes callable.
The most useful tool it exposes is hop_exec: a sandbox that runs JavaScript with bindings for exec, fleet, transfer, and admin. For anything multi-step, an agent writes one small program instead of orchestrating twenty separate tool calls.