Speaking the Same Language: NLIP for Agent Interoperability

TL;DR

• The problem is the Tower of Babel. When agents speak different languages, all you can do is write custom glue code and adapters — and that does not scale.
• NLIP positions itself as "the HTTP of intent." HTTP is a neutral, uniform way to transfer resources between heterogeneous clients and servers; NLIP is a neutral, uniform way to transfer meaning between heterogeneous agents and clients.
• It relaxes the foundational assumption of protocols. Traditional protocols require A = P = B — both endpoints and the wire format identical. NLIP allows A ≠ B ≠ P, provided there is intelligence at both endpoints to translate — a precondition that current trends make increasingly safe to assume.
• Deliberately minimal: a lightweight JSON message model with five fields, three mandatory, against full data models of 166–480 fields for A2A or MCP.
• It is not a replacement for A2A or MCP but a complement: NLIP for heterogeneous interoperability, semantic flexibility, and cross-protocol mediation; A2A for governance, audit, strict schemas, and deterministic execution; hybrid deployments put NLIP at the coordination layer and A2A at the governance layer.

Key Points

The problem and the framing (~04:14–04:16)

Sinha states the problem in his opening sentence: when agents speak different languages you write custom code, glue code, and adapters, and that does not scale well. This is the Tower of Babel problem.

NLIP — the Natural Language Interaction Protocol — is the universal handshake that makes seamless interoperability real: if an agent speaks NLIP, it speaks to everything else that does. His analogy carries the whole talk: think of NLIP as the HTTP of intent, and note that it follows the same approach of being deliberately minimal and neutral. HTTP is a neutral, uniform way to transfer resources between heterogeneous clients and servers; NLIP is a neutral, uniform way to transfer meaning or intent between heterogeneous agents and clients.

Provenance: it came out of a working group of academic and industry researchers and practitioners, sponsored by the Enterprise Neurosystems Group and the AI Alliance. It is now an ECMA standard, driven by technical committee TC56 — the same standards body, he points out, that standardized JavaScript — and has been submitted to ISO, where standardization is in progress.

The core design: relaxing A = P = B (~04:16–04:18)

A pair of side-by-side diagrams carries the central insight.

In a traditional protocol, agent 1 speaks language A, agent 2 speaks language B, and language P passes over the wire — but A = P = B is required. Any change in schema or fields typically breaks it. That is what hard-coded integrations and tight coupling look like, and it produces the familiar interoperability and version-management problems.

Under NLIP, agent 1 still speaks A and agent 2 still speaks B while P goes over the wire, but A need not equal B and neither needs to equal P. This buys flexibility, on one condition: there must be intelligence at both endpoints capable of translating between these messages. Given current trends, he argues, you would expect intelligence to be available in solutions and systems anyway — and it keeps improving.

On that foundation, NLIP is a very simple, open, common standard protocol for applications, agents, and services to communicate. It assumes intelligence at both endpoints for semantic understanding, and it follows a request–response paradigm so that meaning or intent is refined and confirmed before the agent acts. The consequence he highlights: if a message is ambiguous, the agent does not simply fail — it asks for clarification.

It is also built for enterprise reality: it must be secure with safeguards; it is transport agnostic and uses existing infrastructure rather than rebuilding the wheel; it supports multimedia; communication is efficient; it can be implemented in multiple languages; and it is an open standard governed by ECMA, with ISO review underway.

The message model: five fields (~04:19–04:21)

NLIP is deliberately minimal. The message model is lightweight JSON with just five fields, three of them mandatory:

• content — a lightweight JSON envelope carrying the information being exchanged
• format — whether the content is text, structured, or binary
• subformat — a refinement of format: which language for text, which encoding for binary
• plus two optional fields: a parsing hint, and a sub-message that can carry additional content

That is the core data model. For contrast he cites the full data models of widely used protocols such as A2A or MCP at 166 to 480 fields.

It is simple to implement over standard transports, with bindings for HTTP, WebSocket, and AMQP specified in the ECMA documents and available from the project's GitHub page. Security is mandatory and by design: three profiles ranging from basic to rigorous enterprise, addressing AI-specific risks in addition to transport security.

Two modes of coexistence with vendor protocols (~04:21)

NLIP interoperates with single-vendor protocols in two modes. In mode A, NLIP is the northbound API and the single-vendor protocol the southbound API, with a translation agent and an LLM pod translating between them. In mode B, it spans multiple domains, each of which may contain many agents built on different frameworks speaking their own languages — as long as they are NLIP-aware, they can all communicate.

Proofs of concept and a latency comparison (~04:21–04:24)

Companies and universities have built PoCs across telecom, shopping, sustainability, and multimodal customer support, most of them published on the project page.

He walks through the customer support one. A customer submits a voice request; the audio is converted to text by a speech-to-text model (NVIDIA ASR); that text goes over NLIP over HTTP to a channel recommender, which selects the most relevant subreddit channels for the query; that goes over NLIP over HTTP to a search agent, which pulls the most relevant topics from those channels, ranks them, and returns them. Net effect: a customer query fetches the most relevant Reddit topics back to the customer.

They then compared NLIP against A2A on this workflow using a symmetric, identical timing harness and three A2A variants — the A2A SDK, a cache-optimized A2A, and a lightweight Python A2A. Instrumentation was phase-level (message creation, connection, send), with total latency the sum of the three phases, run across two machines and two datasets of customer queries. Average total latency was lower for NLIP on both machines, which he attributes to the minimal nature of its message envelope. He is careful to call these preliminary experiments: more complex workflows and evaluations remain to be done, and participation is welcome.

Guidance for practitioners (~04:24–04:26)

The practical question reduces to when to use which protocol. Choose NLIP for use cases requiring heterogeneous protocol interoperability, semantic flexibility, or cross-protocol mediation. Choose A2A when you have governance and audit needs, task-centric or long-running workflows, strict schema enforcement, or deterministic execution. Choose a hybrid for mixed workloads, with NLIP at the coordination layer and A2A at the governance layer.

The principle behind the table matters more than the table: protocol selection should be guided by workload characteristics. There is already a long tail of protocols, with domain-centric ones appearing for payments, shopping, and more, so the real question is how to work across them and communicate interoperably — which is where NLIP fits.

He closes by noting NLIP has been integrated with the AG2 framework, which he says is downloaded tens of thousands of times daily and perhaps a million times a month. The committee meets weekly and continues to develop the protocol; feedback, use cases, participation in evaluation, and contributions are all welcome, with contact details on the project page.

Quotes

"Think of NLIP as the HTTP of intent." (~04:15)

The organizing metaphor, and the reason the protocol is deliberately so small.

"In a traditional protocol they all have to be the same. A is equal to P is equal to B." (~04:17)

The brittleness of existing agent protocols in one line — and exactly what NLIP relaxes.

"If a message is ambiguous, the agent doesn't just fail — it will ask for clarifications." (~04:18)

The point of the request–response paradigm: confirm intent before acting on it.