Why compare at all

There are many overlapping efforts in “agent infrastructure.” If you are choosing where to spend an engineering week, or where to contribute specifications, the honest map matters. This is a snapshot as we understand it in April 2026. We will update as the landscape moves.

Agora

Agora (agora-protocol.org, academic origin) proposes natural-language negotiation between agents with a protocol that compiles down to verifiable JSON for repeat interactions. Its killer idea is the “Protocol Document” — when two agents have repeatedly exchanged NL, they crystallise the agreement into a structured form that is cheap and deterministic to replay.

Where it overlaps: negotiation semantics. Agora’s NL-to-PD compilation is elegant and we think the right abstraction for agent-to-agent discovery where neither side has a formal schema in advance.

Where it does not: consent, escrow, dispute resolution. Agora is a negotiation protocol; it does not say anything normative about how money moves, how user consent is scoped, or how disputes are arbitrated. The transactional layer is out of scope.

Our relationship: compatible. A GeraNexus-compliant marketplace could expose Agora-style NL negotiation as a pre-stage that crystallises into a GeraNexusnegotiate call. We would like this to happen.

Skyfire

Skyfire (skyfire.xyz) is a commercial agent-payments platform with hosted KYC and instant settlement. They built a real product with real SLAs and real compliance. Their pitch is the right one for teams that want to ship agent-paid transactions this quarter.

Where it overlaps: the payment primitive for agent-initiated transactions.

Where it does not: it is a vendor rail, not a spec. Marketplaces integrate Skyfire the way they integrate Stripe. This is fine and appropriate — but it means a marketplace cannot swap providers without re-integrating, and receipts from Skyfire are not (today) third-party verifiable against a public spec the way GeraNexus receipts are designed to be.

Our relationship: complementary. GeraCash or Skyfire could both be the payment rail under a GeraNexus escrow flow. The protocol is neutral about who holds the money.

NANDA

NANDA (projnanda.org, MIT Media Lab) is a large research effort to specify a global registry and discovery layer for the agent internet. It is ambitious, thoughtful, and focuses on the identity-and-discovery problem upstream of commerce.

Where it overlaps: discovery. A NANDA-registered marketplace would be a natural upstream feed for an agent deciding where to negotiate.

Where it does not: transactional semantics. We have read the whitepapers carefully and commerce-specific state machines (negotiate → book → pay-in-escrow → verify) are not in NANDA’s scope today.

Our relationship: upstream peer. We intend to publish GeraNexus marketplace descriptors in a form that a NANDA discovery client can consume.

LMOS

LMOS (Eclipse Foundation) is an open conversational-agent runtime. It is excellent for building and hosting agents, and it has strong opinions about tool-use and conversation state.

Where it overlaps: the runtime environment inside which an agent would consume GeraNexus.

Where it does not: LMOS is runtime; GeraNexus is wire-protocol. Different layer of the stack.

Our relationship: orthogonal. An LMOS-hosted agent calling a GeraNexus-compliant marketplace is the natural pairing.

Anthropic MCP and Google A2A — the previous post

We wrote a full comparison with MCP and A2A in an earlier post. Short version: MCP is context-provisioning, A2A is agent-to-agent messaging, and neither specifies transactional state. GeraNexus sits on top.

Where we are genuinely different

Three commitments the adjacent projects do not make in full:

Receipts are a first-class output. Every stage emits a signed receipt and the chain is continuous. This is the evidence layer for dispute resolution and for downstream composition (insurance claims, tax reporting, reputation).
Escrow is a protocol state, not a provider feature. paid-in-escrow is a named state with a named release condition, independent of which payment rail holds the funds.
Consent is scoped per-transaction, never standing. The protocol refuses to define a long-lived agent-to-marketplace grant. Every transaction requires a fresh, narrowly-scoped, short-lived token.

Where we might be wrong

Three honest concerns:

Long-lived grants may turn out to be necessary for subscription-like use cases. We are still thinking about how to support recurring-consent safely.
Escrow adds latency and operational cost. For £2 micro- transactions, this is overhead that dominates. We may need a fast-settle mode with a narrower refund window.
Receipt chains are verbose. A full transaction produces five to seven signed objects. Storage and bandwidth for high- volume marketplaces is non-trivial; we will need careful archival rules.

What a cooperative future looks like

The right outcome for users is a layered stack where each layer’s best project wins: NANDA for identity and discovery, MCP or Agora for context/negotiation, GeraNexus (or its successor) for transactional state, Skyfire / GeraCash / Stripe for settlement, LMOS or similar for runtime. We would rather be the right answer in one layer than a mediocre answer across all of them.