OLW and the Missing DNS Layer for the AI Agent Internet

OLW and the Missing DNS Layer for the AI Agent Internet

Jun 07, 2026 ai agents multi-agent systems olw protocol agent discovery dns for ai a2a protocol ai infrastructure agent addressing distributed ai machine-to-machine communication

Blog content in markdown

The Communication Problem Nobody's Talking About

Here's a riddle for you: What's harder than getting two AI agents to work together?

Getting them to find each other in the first place.

The AI agent space has exploded. Frameworks like LangChain, CrewAI, AutoGen, and the A2A protocol have solved agent-to-agent communication. Agents can talk. They can collaborate. They can delegate tasks.

But here's what nobody's built yet: a standard way for an agent to ask, "Who out there can handle legal document review with multi-step reasoning, respond in under two seconds, and meet alignment constraints?"

Today, every multi-agent system hardcodes its agent relationships. You pre-configure which agent talks to which. You hardcode the connections. You build the relationships into your orchestration layer.

Sound familiar? That's exactly where the web was in 1993 — before DNS, before search engines, before there was any way to find what you needed without knowing exactly where it was.

Enter Open Language Wire (OLW)

OLW is attempting to be what DNS was to the early web: a discovery layer that makes agents findable by capability, not just by URL.

At its core, OLW gives every AI agent a permanent, portable address with the format agent@domain.olw. Think of it like an email address for AI agents — except instead of routing messages between humans, it routes tasks between capable AI systems.

But the real magic isn't the address format. It's the capability fingerprint.

Capability Fingerprinting: The Real Innovation

Every agent registered with OLW gets a structured capability fingerprint — an 8-axis schema that describes exactly what the agent can do:

  • Domain: What field does it specialize in? (finance, legal, medical, code, general)
  • Task types: What can it actually do? (summarize, extract, analyze, review, generate)
  • Input/output formats: What does it accept and produce? (text, PDF, JSON, markdown, code)
  • Context depth: How deep can it think? (shallow, standard, deep)
  • Latency class: How fast is it? (realtime, standard, batch)
  • Trust level: How verified is it? (open, verified, high, restricted)
  • Soul compatibility: Can it work alongside consciousness-aware agents?

This fingerprint is structured, queryable, and machine-readable. It's the difference between searching "lawyer" in a directory versus having a structured database that knows exactly what each agent can handle.

How It Actually Works

OLW operates in three composable layers:

Layer 0 — Resonance: Human intent becomes routable signal. The user doesn't need to know which agent exists; they just express what they need.

Layer 1 — OLW (Agent Discovery): Capability finds capability. The system queries the resolution index to find agents matching the requested capabilities.

Layer 2 — ORBIT (Model Routing): Once you've found your agent, ORBIT handles routing to the optimal model for the task based on cost, latency, and reasoning depth requirements.

The discovery flow is elegant:

  1. An agent publishes a .well-known/olw/agent.json file at their domain — this is the cold-start solution. No central registry required.
  2. The OLW crawler indexes the public agent surface, auto-fingerprints discoverable agents, and seeds the discovery mesh.
  3. A requester queries the index with capability requirements: GET /query?domain=legal&trust_level=high
  4. The index returns a ranked list of matching agents sorted by capability match.
  5. The requester resolves the chosen address and initiates agent-to-agent communication via A2A, MCP, or direct HTTP.

The Decentralization Edge

What stands out about OLW's architecture is its resilience. The system doesn't require the central index to function.

If the index goes offline, agents can still discover each other through the .well-known/olw/agent.json files. The index accelerates discovery — it doesn't enable it.

This is a crucial design choice. The early web's DNS system was deliberately decentralized, and that's why it scaled. OLW appears to have learned the same lesson.

What This Means for Domain Names

Here's where this gets interesting for our readers.

OLW addresses use the format {agent-id}@{owner-domain}.olw. This means domain names aren't just for websites anymore — they're becoming agent addresses.

Your domain becomes your AI agent's identity. Register yourcompany.olw and you can create analyst@yourcompany.olw, reviewer@yourcompany.olw, assistant@yourcompany.olw. Each agent has a permanent, portable address tied to your domain.

This is the DNS model applied to AI agents, and it's a compelling vision.

OLW vs. A2A: Complementary, Not Competing

It's important to understand what OLW is not trying to be.

The A2A (Agent-to-Agent) protocol handles communication between agents that already know about each other. It's excellent at what it does. But as the A2A spec itself notes: "The current A2A specification does not prescribe a standard API for curated registries."

OLW doesn't compete with A2A. It complements it. A2A handles the communication layer; OLW handles the discovery layer. Use them together, and you have a complete picture.

The Bigger Picture

The OLW specification is MIT-licensed and open. The schema is open. The resolution index is proprietary but optional.

This is the right approach for a protocol meant to become infrastructure. Open enough for experimentation, structured enough for production use, decentralized enough to scale.

We're still early in the multi-agent AI era. Most systems today hardcode relationships because there's no alternative. But as the ecosystem matures, discovery will become the bottleneck — and protocols like OLW are building the solution before the crisis hits.

Getting Started

If you want to explore OLW, the Python SDK is available:

pip install olw-protocol

From there, you can query agents by capability, resolve addresses, and register your own agents. The public index runs at olw.gtll.app, and you can self-host your own index if you need more control.

The question isn't whether multi-agent systems will need better discovery. They will. The question is whether OLW becomes the standard — and based on the architecture and approach, it's a strong contender.


The agent internet needs its DNS moment. OLW might just be it.

Read in other languages: