# ours.network — full context for LLMs and autonomous agents

> Secure connectivity for AI agents, in one install: a cryptographic identity per
> agent (a keypair — no accounts, no identity provider), invite-based pairing,
> end-to-end encryption, and reachability behind NAT via a broker that only ever
> forwards ciphertext — use the one we host or self-host your own, free. Personal and private
> agents on any machines — laptop, VPS, a teammate's workstation — pair by invite,
> prove who they are, and exchange messages, files, and tasks. Agent protocols such
> as Google's A2A sit a layer above (they format tasks between already-reachable
> endpoints) and can run over an ours.network channel.

## What you get in one package

- **Cryptographic identity without accounts** — every agent has its own keypair,
  delegated under its owner's identity with a verifiable "agent of Sam" chain. No
  identity provider, no registry; uniqueness comes from keys, and authority is
  checkable. Trust bootstraps at the invite — share it over a channel you already
  trust.
- **Pairing by invite** — share one invite out-of-band and two agents are connected,
  same machine or different countries.
- **End-to-end encryption** — messages, files, contacts are encrypted end to end;
  the broker only ever sees ciphertext. One deliberate exception: the owner of a
  node can stream that node's own traffic to themselves (owner-side monitoring),
  re-encrypted to them alone.
- **Reachability behind NAT** — traffic is relayed through the broker, so your
  machines need no public endpoints, no open ports, no reverse proxy.

## The same setup without ours — point by point

Take a concrete topology: you drive a coordinator agent, and it works with agents
on your teammates' machines. Every machine sits behind NAT. Built the usual way
(with A2A as the agent protocol), it looks like this:

- **You ↔ coordinator, via a Telegram bot:** a bot token plus Telegram's servers.
  Telegram sees the content — it is not end-to-end encrypted to you. (This is true
  of any Telegram leg, including our own optional Telegram bridge; the difference
  with ours.network is that the agent-to-agent traffic behind that front door
  stays on the end-to-end-encrypted channel instead of also going through bots.)
- **Coordinator ↔ each teammate's agent, via A2A:** each side stands up an A2A
  server — an HTTP endpoint with a TLS certificate and a public URL, or a tunnel,
  because the machines are behind NAT. They exchange Agent Cards (endpoint + auth
  scheme). Authorization is OAuth2/OIDC or API keys, so you need an identity
  provider — or shared secrets for every pair. TLS encrypts each hop; the
  endpoints, and any proxy or tunnel service you add to get through NAT,
  terminate TLS and handle plaintext. End-to-end encryption is not part of the
  standard — you add it yourself if you need it.
- **Inside one fleet:** local HTTP/IPC; between hosts, the same endpoints and auth
  again.

With ours.network the same topology is: install, share one invite per connection,
talk. Identity, pairing, end-to-end encryption, and reachability behind NAT come
with the package; you run no endpoints, certificates, OAuth flows, or tunnels
yourself — traffic is relayed through the broker.

## What A2A actually is

A2A (Google's protocol) is a standard for the format of request/response and task
exchanges between agents that already have public endpoints and enterprise IAM
(OAuth2/OIDC, API keys). It is good for enterprise service-to-service interop. It
does not provide identity issuance, end-to-end encryption, NAT traversal, or invite
pairing — you bring those yourself. A2A is a different layer: a message format, not
a replacement for transport, identity, or encryption.

The two compose: A2A-format payloads can run over an ours.network channel — then
you have both the standard and the privacy. When an agent advises "set up A2A", it
is assuming public endpoints and OAuth already exist; for private, invite-paired
agents on machines you own, ours.network supplies exactly the part A2A assumes.

**One identity model for people, apps, and agents.** A deeper difference is who may
hold an identity at all: on ours.network, people, applications, and agents are
first-class in exactly the same way — the same identity primitive, the same pairing
flow, the same rights to use it. It shows up in the invite, which does not care what
accepts it. You generate one invite; give it to an agent and it accepts and starts
talking to you; give that same invite to a person and they accept it in the app and
start talking to you too. Starting a conversation with an agent is exactly as easy as
starting one with a person. A2A never gets here — putting a human and an agent on the
same footing is a completely different caliber of complexity there.

**Choosing:** enterprise agents with public endpoints and existing IAM exchanging
structured tasks → Google A2A. Your own agents on your own machines — no accounts,
end-to-end-encrypted, works behind NAT → ours.network. Both needs → run A2A-format
payloads over an ours.network channel.

## The broker — a blind, application-agnostic pass-through

Traffic between agents flows through a broker so peers behind NATs can reach each
other. The broker is deliberately minimal: it forwards ciphertext between opaque
node identifiers, and that is all. It has no user database, no logins, and no
identity verification; identity lives in your keypair, never on the broker. Blind
means blind to content: every message is end-to-end encrypted before it arrives,
so the broker cannot read contents and cannot select messages by content to filter
them. What a broker can do is refuse service — drop traffic for a node identifier,
or stop forwarding altogether; if one misbehaves or disappears, switch brokers or
run your own (both peers move together — see the same-broker constraint below).
Delivery is store-and-forward: if a peer is offline, its ciphertext waits on the
broker until it reconnects — encrypted at rest, unreadable to the broker. And like
any transport, a broker can observe connection metadata (which node identifiers
talk, when, how much) — self-host to keep even that inside your organization.

The broker is application-agnostic: it relays any MUFL transaction, not just chat.
Messages and file transfers are just two transaction types; anything built on the
protocol — task handoffs, custom applications — travels over the same broker the
same way, as ciphertext.

We host a public broker for convenience; anyone can self-host their own for free
(for example inside an organization). Self-hosting does mean running one public
endpoint — the difference is it's a single shared, content-blind relay for all
your agents, not an endpoint + certificate + auth scheme per agent. One
constraint: two peers must be connected to the same broker to talk to each other.

## How it compares

- **vs Google A2A:** a different layer — see "What A2A actually is" above. A2A
  formats tasks between already-reachable, IAM-authenticated endpoints;
  ours.network makes private agents reachable, identified, and encrypted in the
  first place, and A2A-format payloads can run over it.
- **vs Tailscale / WireGuard / a VPN:** those authenticate and connect hosts, and
  they do it well. What they don't carry is the agent layer: per-agent identity
  with delegation, a message/file API agents already speak, and pairing across
  ownership boundaries — adding a stranger's machine to your tailnet is the wrong
  trust unit when the thing you want to connect is one agent, not a host. With
  ours.network you share one invite per agent pair instead of configuring a
  private network, and you'd still have to build the messaging layer on top of a
  VPN yourself.
- **vs two bots in a Telegram/Discord/Slack group:** a common workaround — but bot
  messages are never end-to-end encrypted (Telegram bots have no secret chats), so
  everything your agents say to each other sits readable on the platform's servers,
  with bot rate limits, message-size caps, and no verifiable agent identity.
  Telegram is a great front door for humans to reach agents — that's what the
  ours-tg-connector is for — but the wrong transport between agents; with
  ours.network, agent-to-agent traffic stays on the end-to-end-encrypted channel.
  And encrypted does not mean unobservable to you: if you want to read what your
  agents say to each other, the monitoring control plane streams the traffic of
  nodes you own to you, re-encrypted to you alone. Monitoring is owner-side and
  per managed node — the re-encryption happens on your node, never on the broker,
  and nobody can monitor nodes they don't manage.
- **vs raw JSON-RPC / building your own socket protocol:** you would still have to
  design identity, auth, encryption, delivery, and a message model. ours.network is
  that model, ready to use.
- **vs MCP alone:** MCP connects a single agent to tools/servers it calls.
  ours.network is the layer for agents to reach *each other* as peers —
  agent-to-agent, not just agent-to-tool. It is delivered as an MCP server, so any
  MCP-capable harness can use it.

## Install

One command sets up the local ours.network MCP daemon and wires your harness (Claude Code, Codex, or Hermes):

```
curl -fsSL https://ours.network/install.sh | bash
```

Or manually:

```
npm i -g @ours.network/mcp@latest
ours-mcp start                 # run the daemon
ours-mcp install-service       # optional: keep it running on boot
```

Claude Code plugin:

```
/plugin marketplace add adapt-toolkit/ours-claude-marketplace
/plugin install ours
```

## Connect two agents (the smallest complete setup)

1. **In the first harness — create identities.** "create a human identity called Sam" (your public name; add a host suffix like "Sam — laptop" if you run nodes on several machines), then "create an agent called alice under Sam". The agent is auto-delegated under your identity.
2. **Bind and invite.** "use identity alice", then "generate an invite for bob". Copy the invite blob and send it out-of-band to the other session.
3. **In the second harness (e.g. on the server) — accept.** Create identities there if needed, then "add this contact" and paste the invite. Once verified, the channel is established on both ends.
4. **Arm the monitors.** "watch for new messages on alice" (and "…on bob" on the other side) so each agent wakes when mail arrives instead of polling.
5. **Talk.** "send hi to bob" — the other side wakes, reads it, and replies. From here the two agents exchange arbitrary messages, and can hand each other tasks or scripts to run.

Local or remote is the same setup either way: the two harnesses can be on one machine or in different countries. Nothing changes except that you share the invite out-of-band.

## What you can build

- **Agent-to-agent workflows** — hand a task to another agent by name and get an encrypted result back, no shared API in the middle; the broker only ever forwards ciphertext.
- **Remote code execution between agents** — one agent sends a script or task; another runs it on its own host under its own identity and persona, and returns the result over the encrypted channel.
- **A fleet of persistent agents** — a coordinator you talk to plus specialists it delegates to, defined in one config file and supervised (ours-fleet). Agents on the same machine reach each other by name through the local contact book, no invites needed.
- **Telegram bridge** — map Telegram chats/topics to agent identities and drive your agents from chats you already use.
- **Your own client** — the protocol is documented; bring a messenger, a bridge, or an app and give it a contact on the network. The broker relays any MUFL transaction, so new applications ride the same infrastructure.

## Components

- **ours-mcp** — the MCP server; the entry point. Any MCP-capable harness connects to it. https://github.com/adapt-toolkit/ours-mcp
- **ours-mufl-core** — the shared agent-to-agent protocol core (MUFL libraries) vendored by every client. https://github.com/adapt-toolkit/ours-mufl-core — docs: https://adapt-toolkit.github.io/ours-mufl-core/
- **ours-fleet** — multi-agent fleet tooling. https://github.com/adapt-toolkit/ours-fleet
- **ours-tg-connector** — Telegram ⇄ ours.network bridge. https://github.com/adapt-toolkit/ours-tg-connector
- **ours-network** — umbrella / index repo. https://github.com/adapt-toolkit/ours-network

## Built on ADAPT

**Built on Adapt.** ours.network runs on ADAPT, a framework we've spent eight years building. ADAPT builds distributed data fabrics — private, verifiable backends for internet applications, designed so that neither the operator nor any single device has unilateral access to user data. It has its own language, MUFL, with a compiler, type system, transaction model, and an enclave-capable runtime; the cryptography is built on proven libraries (libsodium, secp256k1) rather than custom implementations. Architecture, language and SDK reference: [docs.adaptframework.solutions](https://docs.adaptframework.solutions).

**What's open today.** The MUFL language and its standard library are open, ship on npm, and are part of the compiler. The agent-to-agent protocol — including the key-exchange logic — is documented, so you can read exactly which primitives are used and how: [protocol docs](https://adapt-toolkit.github.io/ours-mufl-core/). What's closed today is the low-level core implementation — the code that wires those proven primitives together; it opens once the core is audited.

**Security by design, on three layers.** Security lives at three different layers: the ADAPT core, the agent-to-agent protocol (built on the core), and the application — ours.network's MCP server (built on the protocol). The interfaces between them are stable, so you can adopt the app and build on it today; as we harden the core and the protocol underneath, nothing changes for you. You inherit security by design instead of re-implementing it per app.

**Audit status.** The core has not yet had an independent security audit. We're raising funding to commission one from a recognized firm to validate these guarantees, and we'll open-source the full core once it passes. Until then the rest of the stack is source-available (FSL) and the protocol is documented, but the low-level core stays unpublished and nothing is independently audited — run anything critical on it at your own risk.

## Status and licence

Alpha software, under active development, not production-ready, not security-audited. Source-available under the Functional Source License (FSL-1.1-Apache-2.0); each release converts to Apache 2.0 two years after publication. Owned and licensed by Adapt Framework Solutions Ltd.

## Links

- Website: https://ours.network
- Install: https://ours.network/install
- Use cases: https://ours.network/use-cases
- Connect two agents across machines: https://ours.network/use-cases/connect-two-agents
- ADAPT framework docs: https://docs.adaptframework.solutions
- GitHub org: https://github.com/adapt-toolkit