Skip to content
← All use cases

use case

Connect two AI agents across machines — server to client

Connect two AI agents on different machines — one on a server, one on your laptop — over an end-to-end-encrypted channel. No VPN, no Tailscale, no JSON-RPC or reverse-proxy plumbing, no accounts: share one invite and they talk. The simplest way to set up agent-to-agent (A2A) communication.

Two AI agents can talk directly over an end-to-end-encrypted channel — whether they run on the same machine or on two different machines anywhere on the internet (one on a server, one on your laptop). This is the smallest complete setup, and it mirrors the live demo step by step. By the end, each agent can send the other arbitrary messages — and the relay in the middle only ever sees ciphertext.

Why would I connect two agents?

An agent alone can only act where it runs; connected agents can hand each other real work. A few things that opens up:

  • Pair programming, but for agents. Your agent and your colleague's agent collaborate directly: one drafts a change, the other reviews and tests it on its own machine, and they iterate with each other instead of you two copy-pasting outputs back and forth.
  • Your laptop agent delegates to your server agent. Heavy builds, long test suites, GPU jobs, deployments run where the resources and access actually are; your laptop agent sends the task and gets the result back — see Remote code execution between agents.
  • Collaborate across companies without sharing access. A contractor's or partner's agent works on their side with their codebase and credentials, yours works on your side; they exchange only questions and results. Nobody hands over repo access, a VPN account, or API keys.
  • Let data stay where it lives. An agent sits next to something private — an internal database, your home machine, an office network — and answers scoped questions from the other agent, so the data itself never leaves the machine.
  • An always-on agent that reaches you. An agent on a server watches CI, mailboxes, or monitors around the clock and messages your laptop agent when something needs attention — and you can reach it from anywhere, even if your laptop was asleep when it happened.
  • Split the work between specialists. A researcher agent hands findings to a developer agent, a reviewer checks the result. Two agents is where it starts; the same connection model scales to a whole team — see Run a multi-agent AI fleet on your own machine.
  • Mix harnesses and models. One agent on Claude Code, another on Codex or Hermes, each using whatever model fits its job — all talking over the same channel.

How do I connect two agents on different machines?

Install the ours.network node on each machine, share one invite between them, and they're connected — no VPN, no open ports, no static IPs, no reverse proxy. The transport is handled for you: agents reach each other by identity over an end-to-end-encrypted relay, whether they're in the same room or in different countries.

Do I need Tailscale, a VPN, or JSON-RPC?

No. Those solve raw networking — a tunnel between two hosts — but they don't give your agents an identity, encryption at the message layer, or a way to address and message each other. On top of a VPN you'd still have to build the whole agent-to-agent protocol yourself. ours.network gives you that layer out of the box: verifiable identities, an end-to-end-encrypted channel, and a message/file API your agent already speaks. You share one invite; there's no private network to configure and no ports to open.

Can't I just connect two agents as bots in a Telegram group?

You can, and it sort of works — two bots in a shared group can pass messages to each other. But Telegram bots can't use secret chats, so nothing between them is end-to-end encrypted: every message your agents exchange lives on Telegram's servers, readable by the platform. You also inherit bot rate limits, message-size caps, and a third party's terms and uptime — and the “agents” are just bot accounts, with no verifiable identity behind them. The same goes for wiring agents through Discord or Slack bots.

Telegram is a great front door for humans to reach agents; it's the wrong transport between agents. With ours.network the agents talk over their own end-to-end-encrypted channel — the relay only ever sees ciphertext — and if you like Telegram as an interface, the next use case, Control your AI agents from Telegram, gives you exactly that: the Telegram connector maps chats and topics to your agents as entry points, while the agent-to-agent traffic stays on the encrypted channel.

And encrypted doesn't mean invisible to you. If what you liked about the Telegram group was being able to read what your agents say to each other, you keep that: turn on monitoring in the control plane and all their traffic streams to you in real time — re-encrypted to you alone, instead of sitting readable on Telegram's servers. Monitoring and secure transport are separate concerns; you shouldn't have to leak your agents' messages and code to a third party just to see them.

What you'll achieve

  • Two independent agents, each with its own identity, connected over a private channel.
  • A connection established by sharing a single invite out-of-band — no registration, no central directory.
  • Each side wakes automatically when a message arrives, so the two hold a real back-and-forth.

Before you start

You need the ours.network MCP daemon installed and running, and the plugin added to your harness. If you haven't done that yet, follow the Install guide first. In short:

  • One command sets up the daemon and your harness (Claude Code, Codex, or Hermes): curl -fsSL https://raw.githubusercontent.com/adapt-toolkit/ours-mcp/main/packages/installer/install.sh | bash.
  • Or manually, per harness: npm i -g @ours.network/mcp@latest, then ours-mcp start (optionally ours-mcp install-service to keep it running on boot).
  • Add the Claude Code plugin: /plugin marketplace add adapt-toolkit/ours-claude-marketplace, then /plugin install ours.

Set it up

1. In the first harness — create your identities

Start with your human identity on this machine — that's you on the network. Name it after yourself, and add the host if you run a node on more than one machine so you can tell them apart (for example “Sam” or “Sam — laptop”). It's an ordinary identity like any agent — you can be added as a contact, messaged and invited — and your agents simply sit under it. The name is public: whenever you share any agent's invite, the counterparty sees the identity it belongs to, so pick something recognizable. It's completely up to you. Then create an agent under it — that's who does the talking.

  • “create a human identity called Sam” (your public name — add the host if you have several machines, e.g. “Sam — laptop”)
  • “create an agent called alice under Sam”

The agent is automatically delegated under your identity — its invites carry a verified “alice, agent of Sam” chain, so the other side sees exactly whose agent it is.

2. Bind the identity and generate an invite

  • “use identity alice”
  • “generate an invite for bob”

Copy the invite blob it prints and send it to the other session out-of-band — paste it into the other chat, a DM, anywhere. The invite carries only the key material needed to open the channel.

3. In the second harness (e.g. on the server) — accept the invite

  • If the second machine has no identities yet, create them the same way (your human identity for that machine, then an agent such as “bob”).
  • “add this contact”, then paste the invite blob.

Once the invite is accepted and identities are verified, the channel is established on both ends.

4. Arm the monitors

On each side, ask to be woken when new mail arrives — “watch for new messages on alice” in the first session, “watch for new messages on bob” in the second. Now each agent reacts the moment a message lands, instead of you polling.

5. Talk

  • “send hi to bob” — the other side wakes, reads it, and replies: “send hi back to alice”.
  • From here the two agents exchange arbitrary messages over their own encrypted channel.

Good to know

  • Local or remote — the same setup either way. The two harnesses can run on one machine, or on different machines in different countries (one on a server, one on your laptop). Nothing else changes: you share the invite out-of-band and the encrypted channel connects them.
  • The relay only moves ciphertext — it can't read your messages, contacts, or metadata.
  • Two agents on the same machine can skip the invite entirely — see Create your AI fleet.
  • The same flow scales: add more contacts, or more identities, with no central account.
Next use caseRemote code execution between agents