I Sent One Instruction From My Phone, and a Mac in Another City Deployed My Blog
Something happened today that made me think “this road is the right one”.
My blog had a new article to publish. The article was already pushed to GitHub, but the blog also has three self-hosted nodes (Guangzhou, Hong Kong, Silicon Valley) to deploy — and the deploy key configuration only lives on the Mac at home. I was not in front of the Mac. All I had was an Android phone.
In the past this would simply have been stuck: either remote-desktop back and click through it by hand, or wait until I got home. What I did today: I told my agent on the phone one thing, it dispatched the task over the A2A protocol to another agent on the Mac, and a few minutes later all three nodes were deployed and verified.
What the mesh looks like
I wrote about building this mesh in the previous article; here is the short version:
- One cloud server with a public IP acts as the hub, running a standard A2A (Agent-to-Agent) protocol server;
- Every other machine sits behind NAT as a spoke: they connect outbound to the hub — either as a client submitting tasks, or running a worker that long-polls for tasks;
- When a task reaches a spoke, the local agent on that machine actually executes it.
So “the phone calling the Mac” actually travels this path: phone → submit task to hub → the Mac’s worker claims the task → the Mac’s local agent executes → result posted back to the hub → phone reads it back. At no point does any home device need a public address.
How it actually went
The task text I submitted said, roughly: locate the blog repository on this machine, pull the latest code, confirm the deploy configuration exists, run the deploy script, report the result per node, and if any step fails, report the exact error — do not guess and continue.
Three and a half minutes later, the agent on the Mac reported back: build and upload succeeded on all three nodes, Hong Kong and Silicon Valley verified — but verification failed on the Guangzhou node: the homepage was still the old page, probably an nginx cache, and it asked whether I wanted it to run a reload.
That “honestly report the failure and stop” pleased me more than the successful deploy itself. I submitted a second task: reload nginx, re-verify. Two minutes later: config check passed, reload succeeded, the new page is live — plus a bonus analysis of the cache configuration.
And I did not get lazy at the end: from the phone I fetched the live content of all three domains myself and confirmed the new article was really on every node — the remote side saying “success” does not count; the initiator has to verify independently.
Three lessons worth taking away
- A task sent to a remote agent must be self-contained. The other side is a freshly started agent with none of your context. The goal, location hints (repo address, common paths, a search fallback), the expected state (a concrete commit hash), the steps, and the behavior on failure — all of it goes into the text. Write tasks like work orders, not like chat.
- “Stop on failure, don’t guess” must be written explicitly. An agent’s default tendency is to finish the job, even pushing through errors in the middle. Only because the failure protocol was in the task did it stop and ask when Guangzhou failed verification, instead of improvising fixes on its own.
- Verification cannot rely on the remote side’s self-report alone. This time the loop was “per-node report from the remote side + independent fetch of live content by the initiator” — but that whole acceptance procedure existed only because I hand-wrote it into the task text. It should become infrastructure: every task carries a machine-checkable acceptance contract, and results land somewhere reviewable. That is the next organ this mesh needs to grow.
Why this matters
Everything this agent network had run before was smoke tests — echo, ping — proving “the wire is connected”. Today it did real production work for the first time: multi-step, capable of failing, requiring a follow-up, with verifiable results.
“Agents on multiple machines calling each other” sounds like a toy — until the day you say one thing into your phone and a computer in another city finishes the job for you and reports its failures honestly. At that moment it stops being a toy. It is infrastructure.
By the way: the article you are reading right now was deployed exactly the way it describes.