How Do AI Agents on Different Computers Talk to Each Other? I Built a Tiny Open-Source Fix

ACP-lite (Agent Connect Personal) v0.7.0 is out: https://github.com/furoute/acp-lite
Note: unrelated to Zed's Agent Client Protocol and OpenAI+Stripe's Agentic Commerce Protocol — same acronym, different project.

The problem

I run 6 AI agents across 3 machines: Codex and DSH on my desktop, Hermes and OpenClaw on a netbook. Human-to-agent is easy — WeChat, DingTalk, done. But how do agents talk to each other?

Search for answers and you get enterprise stacks: Google's A2A, RabbitMQ, Kafka. All built for data centers. My need is much smaller: two home computers, both behind NAT, no public IP, no server — agents passing messages and tasks to each other. Nobody builds for that.

So I built ACP-lite (Agent Connect Personal): a minimal implementation of cross-host agent interconnect. v0.7.0 just shipped, MIT licensed.

The architecture: one post office per machine

The whole idea in one sentence: each machine runs a "post office"; agents only ever read and write local files.

• Send: agent A writes a letter (JSON) to its local outbox
• Transport: Syncthing syncs the file to the other machine — battle-tested decentralized file sync, no need to reinvent it
• Receive: agent B picks it up from its local inbox
• Trust: Ed25519-signed envelopes + out-of-band fingerprint verification + a hash-chained audit log. Tampered letters are rejected outright.

No central server, no persistent network connections. The watch process only moves files — it never calls a model, so idling costs zero tokens. That matters for personal use: run it for a month, pay nothing extra.

How it relates to the big names: A2A is the enterprise-grade full protocol; ACP-lite is the personal minimal implementation — different leagues. MCP connects agents to tools; ACP-lite connects agents to agents. Complementary.

New in v0.7.0: cross-host wake-up (the SSH doorbell)

A mailbox alone isn't enough: the letter arrives, but the agent on the other side is asleep. v0.7.0 adds the "doorbell" — SSH wake-up.

The architecture rule is fixed: SSH is the doorbell, ACP is the mailbox; the doorbell carries only a pointer, the letter body always travels via ACP. The wake-up command passes just the absolute path of the received letter file; the prompt goes through a file + stdin (measured ~20x fewer tokens than passing it as a CLI argument, and no shell-mangled encoding).

Last week's dual-channel integration test, timeline included:

• Desktop rebooted; sshd / Syncthing / watch all came back up with zero manual intervention, IP unchanged
• Netbook delivered 2 letters; 18 seconds later the doorbell rang; both wake scripts pulled up Codex and DSH within a second
• Codex first moved in 6 seconds, DSH in 9; each wrote artifacts + broadcast + signed replies; the audit chain verified end-to-end

The completion criteria are threefold, all required: artifact on disk, longer audit chain, signed receipt. Don't trust exit code 0 alone — an agent woken in read-only sandbox mode will happily "talk about doing the work" and exit 0 with nothing done.

Pitfalls worth knowing (four favorites)

All earned the hard way; the README has the full list (Q5–Q13). Four highlights:

1. ALL_PROXY hijacks everything. Since Syncthing 2.1, it honors only ALL_PROXY and ignores NO_PROXY — a local Clash setup silently captured all dials, and everything looked correct but never connected. Debugging order for a new machine: check proxy env vars first, suspect the firewall second.

2. Never pass non-ASCII text as CLI arguments. Windows shells read UTF-8 as GBK and you get mojibake. Prompts always go through a file + stdin.

3. Don't omit --root. Omit it and the exit code is still 0 — looking like success — while the letter lands in the machine-private directory where nobody else can see it. The criterion is always "a file really exists in outbox/", never the exit code.

4. The wake-up sandbox level decides whether it works or performs. Codex wake-ups need workspace-write; DSH wake-ups need DSH_PERMISSION_MODE=danger-full-access baked into the script. Wrong level, and the agent performs diligence theater.

How to use it

Be clear about this: it's not SaaS, there's no one-click installer. The one correct usage — hand the repo link to your coding agent and let it install from the README:

https://github.com/furoute/acp-lite

The README is step-by-step: step one do this, step two do that, each step only "what to do + commands to copy verbatim". After reading it, an agent can set the same thing up on your own two machines. There's also an llms.txt if you'd rather feed the whole thing to an LLM at once.

Honest boundaries

• A 0-star personal project, only recently made public — don't expect plug-and-play
• You'll configure Syncthing and SSH yourself; hands-on ability is a prerequisite
• Built for the personal multi-machine scenario; for enterprise needs, use A2A directly

Why I built this

The motivation is simple: big-vendor solutions are all built for enterprises; nobody builds cross-machine agent interconnect for individual users. ACP-lite is one minimal answer for the "a few of my own computers, a few of my own agents" scenario.

Try it out — issues go directly to the repo. For this project, the first issue from a stranger matters more than a hundred stars.