ANP and AgentConnect: a multi-language SDK for agent identity, discovery and encrypted messaging
Our vision is to provide communication capabilities for intelligent agents, allowing them to connect with each other to form a collaborative network of intelligent agents.
At a glance
- What is it?
- AgentConnect is the reference implementation of the Agent Network Protocol, published as the Python package anp with Go, Rust, Dart, TypeScript and Java siblings. It is a protocol stack for identifying agents, describing their interfaces, proving objects and requests, resolving handles and encrypting traffic, and its language coverage is uneven by design.
- Who is it for?
- Adopt it if you are building an agent that must prove who it is, publish a machine-readable interface and talk to other agents over JSON-RPC, and if Python or Go fits your stack. Do not adopt it if you need a uniform feature set across languages: Java has no WNS or group E2EE surface at all and is not on Maven Central, and TypeScript, Dart and Java are versioned outside the Python/Go/Rust release helper, so their version numbers will drift.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem ANP addresses is agent-to-agent trust, not agent-to-model plumbing
Most agent frameworks solve the problem of getting a model to call a tool inside one process. ANP starts one level out. The README frames the protocol as answering five questions: who am I talking to, what can this agent do, can I trust this object or request, how do humans and agents find each other, and how do agents communicate privately. Each question maps to a concrete artifact rather than a convention. Identity is a DID WBA document plus HTTP Message Signatures. Capability is an Agent Description document plus an OpenRPC interface document served over a JSON-RPC endpoint. Trust is a W3C Data Integrity proof, an Appendix-B object proof, an IM/origin proof, or a DID-WBA binding proof. Discovery is a WNS handle. Privacy is a set of direct and group E2EE building blocks.
The audience is therefore narrower than "anyone building agents". It is teams that need two independently operated agents, possibly written in different languages and run by different organisations, to establish that a request came from a specific identity and that the responding agent really exposes the interface it claims. If your agents only ever call each other inside one trust boundary, this is a large amount of machinery for a problem you do not have.
DID WBA identities, OpenRPC interfaces and proof objects are the three load-bearing pieces
The mechanism visible in the material is a document exchange rather than a broker. An agent holds a DID WBA identity and a corresponding DID document. When it wants to be callable, it publishes an Agent Description document and an OpenRPC interface document, and exposes a JSON-RPC endpoint. A caller resolves the target, fetches the description, and issues a standard RPC call. Proofs are attached to requests and objects so the receiving side can verify origin and integrity without a shared session secret.
WNS sits on top of this as the human-readable layer. The README describes WNS handle validation, resolution and binding verification, and the handle continuity table shows that ANP-04 WNS 1.1 makes `binding_generation` a required security field. That detail matters more than it looks. A handle that resolves to a DID is a rebinding risk: if an operator can point an existing handle at a new DID without leaving a trace, the handle becomes a weaker identifier than the DID. Requiring a generation counter on the binding gives verifiers something to compare against, and the README states plainly that support for the stricter contract is being introduced per language rather than implied by a shared package version. That sentence is the honest part of the document and also the warning.
Install commands differ per language, and the version numbers do not line up
The Python package is `anp`. The README gives two installs: `pip install anp` for the core SDK, and `pip install "anp[api]"` for the FastAPI and OpenAI extras that back OpenANP, the agent-building layer. Go is `go get github.com/agent-network-protocol/anp/golang@latest`, with tags in the `golang/vX.Y.Z` format. Rust is `cargo add anp`. Dart is `dart pub add anp`. TypeScript is `npm install @awiki/anp-typescript-sdk`. Java is not installed from a registry: the README says `cd java && mvn clean install -DskipTests`, and states that a Maven Central metadata check returned not found for `com.agentconnect:anp4j` and `com.agentconnect:anp-spring-boot-starter`.
The version table, checked on 2026-08-18 according to the README, lists Python, Rust, Go and TypeScript at `0.9.3`, Dart at `0.8.7`, and Java at a local `1.0.0`. The recent releases shown for the repository are v0.8.8 from 2026-06-27, 0.8.5 and 0.8.2. The gap between the release list and the registry table is not explained in the material, so treat the registry table as the authoritative install reference and the release list as history. The practical consequence is that "the ANP SDK" is not one version. It is six artifacts moving at three different cadences, and a cross-language integration has to pin each side independently.
Language coverage is deliberately uneven, and Java is the thinnest
The handle continuity table is the clearest statement of where each SDK actually stands. Python, Rust, Go, Dart and TypeScript have `binding_generation` implemented. Java is marked not applicable because, per the README, Java has no WNS surface and no Group E2EE or OpenMLS surface, so there is no corresponding API to synchronise.
Handle rebind P6 primitives are a second axis. Rust has existing `group.e2ee.add` and `group.e2ee.remove` typed primitives that accept the same `GroupStateRef`, so Rust carries both the WNS generation change and in-process OpenMLS rebind and status capability. Go has the contract and provider surface only, with no in-process OpenMLS status API. Python, Dart and TypeScript have no OpenMLS surface at all, which the README records as not applicable rather than as a gap. The README adds an explicit caution that release claims must distinguish WNS generation conformance from Rust's in-process OpenMLS rebind and status capabilities. In other words, a shared version number across Python, Go and Rust does not mean shared capability. If your design depends on group E2EE membership changes, Rust is the only SDK the material shows with the typed primitives for it.
Where ANP is the wrong tool
Three cases stand out. First, single-language deployments inside one organisation. If every agent is Python and every agent is yours, the DID document, the HTTP Message Signature, the W3C Data Integrity proof and the WNS handle are all overhead you pay for a trust boundary that does not exist. A shared secret and an internal service registry will be simpler and will not require you to keep six SDK versions in your head.
Second, anything that needs group E2EE outside Rust. The README's own table shows Go with a contract surface but no in-process OpenMLS status API, and Python, Dart and TypeScript with no OpenMLS surface at all. Building group messaging on the Python SDK means building the E2EE layer yourself on top of the "direct and group E2EE building blocks" the README mentions, and the material does not describe what those blocks include beyond that phrase.
Third, JVM shops that expect to pull dependencies from Maven Central. The README states that Java is usable from a local Maven build while its public package status matures, and that the metadata check returned not found. A local `mvn clean install` works for a monorepo, but it means every consuming team builds the SDK from source and every upgrade is a source checkout rather than a version bump.
How this differs from A2A and MCP
The closest comparison is MCP, which standardises how one host exposes tools and resources to one model. MCP assumes the host and the server already trust each other; the transport is the boundary. ANP assumes they do not. Identity is a DID WBA document, requests carry HTTP Message Signatures, and objects carry W3C Data Integrity proofs, so verification is a property of the message rather than of the connection. That is a heavier design and it is the reason the protocol needs WNS handle resolution and binding verification at all: without a trust boundary there is nothing to resolve.
A2A is closer in shape, since it also describes agents to each other and routes tasks between them. The difference visible in this material is where the identity lives. ANP puts it in a DID with a resolvable handle and a binding generation, and treats the proof as an object that travels with the payload. The README does not compare itself to A2A, so the honest statement is that both address agent discovery and invocation, and ANP's distinguishing commitment is cryptographic identity and per-object proofs rather than a registry of trusted endpoints. If you already have a working A2A deployment with a trusted registry, ANP's proofs will look like duplicated work.
Maintenance cost, release tooling and licence
The repository ships a coordinated Python, Go and Rust release workflow with a stated version policy, and the registry table shows all three at `0.9.3`. Dart and TypeScript are versioned outside that helper, which is why Dart sits at `0.8.7` while the others sit at `0.9.3`. That is a maintenance fact, not a criticism: it means a cross-language upgrade is a manual coordination task, and the README's own note that release claims must distinguish WNS conformance from Rust's OpenMLS capabilities tells you the release notes are the place to check, not the version number.
The repository also carries examples, cross-language interop checks and shared test vectors, which is where the conformance work lives. If you are extending the protocol, the test vectors are the artifact that tells you whether your implementation agrees with the others.
The licence is Apache-2.0. That is a permissive licence with an explicit patent grant, and it is compatible with proprietary downstream use. This is a description of the licence identifier, not legal advice; if you are redistributing the SDK or modifying the protocol documents, read the licence text and the NOTICE requirements yourself.
Editorial conclusion
Adopt it if you are building an agent that must prove who it is, publish a machine-readable interface and talk to other agents over JSON-RPC, and if Python or Go fits your stack. Do not adopt it if you need a uniform feature set across languages: Java has no WNS or group E2EE surface at all and is not on Maven Central, and TypeScript, Dart and Java are versioned outside the Python/Go/Rust release helper, so their version numbers will drift. Verify three things before committing: that `binding_generation` is enforced in the SDK you choose, that your language actually has the E2EE surface you need, and that your dependency tooling can resolve the Java artifacts from a local build rather than a public registry.
Community notes