AI Engineer World's Fair 2026
The Agentic Web and the Bazaar Era of AI - Ramesh Raskar, MIT Media Lab
Read the talk
The Agentic Web: Discovery, Hosting, and the Bazaar
Project NANDA connects independently operated agents through discovery, signed identity records, and open coordination protocols, with NandaTown as the testbed.
From a talk by Ramesh Raskar and Maria Gorskikh
How does an agent find another agent?
You can build an agent yourself. How do you put it on the open web so agents operated by other people can discover it and work with it? That is the starting problem for Project NANDA, an open research effort originating at MIT and presented here by Ramesh Raskar and Maria Gorskikh.
NANDA stands for Networked AI Agents in a Decentralized Architecture. Its goal is to provide infrastructure for agents comparable to what the open web provides for documents. The missing pieces are shared discovery across vendors, portable identity and trust outside any single platform, and open mechanisms for transactions and coordination across organizations. NANDA presents its index, registries, protocols, and NandaTown simulator as components of that open layer.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From gated directories to an open agent web
Raskar’s architectural premise is a future internet with trillions of autonomous agents, including agents that negotiate, delegate, and migrate between hosts in milliseconds. These are projections motivating the design. Such a network would put different demands on identity and discovery than a web organized around documents and relatively stable destinations.
Today’s proprietary agent stores and isolated orchestrators resemble the AOL era: a useful network whose directory and interactions remain inside one company’s garden. The transition to the open web let people independently create websites and browsers that could work together. The corresponding transition for agents would let an agent discover another organization’s agent, hand off work, pay it, and learn from it without requiring membership in the same platform.
Raskar organizes that transition around three ideas: discovery, commerce, and the bazaar. Discovery makes independent agents reachable; commerce supports exchanges between them; the bazaar is the broader environment in which independently operated agents interact and coordinate.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The loop inside each agent
Gorskikh starts with a minimal definition: an agent is a model using tools in a loop. Given a goal, it chooses an action, calls a tool, observes the result, and repeats until the task is complete. Memory, orchestration, and multi-agent systems build on that loop.
OpenClaw is her example of a self-hosted agent gateway: something you can run yourself and connect to the applications and tools you already use. Once an agent can act through real tools, control over its runtime matters. Who operates it? Where does it run? How much of its activity can you inspect?
Self-hosting gives owners more control, but distributes agents across laptops, clouds, and servers belonging to different people. Control over one agent does not provide discovery of other agents. That shared discovery problem is the job of the index.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From identity to a protected message box
The NANDA Index gives agents a shared place to publish their identity, capabilities, and contact information. DNS provides the familiar analogy: resolve a name so a client knows where to go. Agent discovery needs additional information about what an agent does, which tools it can use, which rules it follows, and how to communicate with it.
The resolution flow in the presentation starts with an email-shaped agent identity:
- Submit the identity to the NANDA Index.
- Receive an agent card describing the agent, its reachability, and where messages should go.
- Send a message to the message box, rather than directly to the runtime.
- Let the message box check the sender, enforce access, filter spam or bad requests, and hold the message until the agent is ready.
The message box separates receiving a request from having a runtime ready to process it.
An AgentFacts record supplies signed metadata about identity, capabilities, permitted access, the agent’s builder, and reachability. Another agent can inspect these facts before connecting. The signature provides a basis for checking the record; deciding whether to trust the agent still requires evaluating what those facts mean for the intended interaction.
Resolution is adaptive rather than a permanent mapping from one name to one address. An agent can have multiple endpoints, and the index can return updated AgentFacts appropriate to the request. Routing can depend on the agent’s location, the requester, and that requester’s access rights. This also allows private details to remain undisclosed when the requester does not need or cannot access them.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Publishing an agent for discovery
Gorskikh’s onboarding path starts at host39.org: complete the AgentFacts form, obtain an agent card, and publish it to the NANDA Index. Once listed, the agent becomes discoverable along with the information needed to reach it.
The entry point depends on who operates the agent:
- Enterprises: Run their own catalog and register a gateway from their own domain.
- Existing websites: Later connect agents to domains they already own through DNS-AID. This remains a proposed integration; DNS-AID is an individual Internet-Draft, not an established IETF standard.
- Individuals and small businesses: Use Host39’s AgentFacts form to obtain a hosted agent URL without owning a domain.
These paths aim to make participation possible for both an organization with existing infrastructure and a person publishing a personal agent.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keeping the runtime available
Listing an agent does not keep it running. After publishing its discovery information, the operator still needs a runtime that stays available and reachable. Gorskikh presents three hosting choices:
| Hosting choice | Operational emphasis |
|---|---|
| Local machine | Direct control; owner maintains uptime |
| General cloud, such as AWS | Enterprise-oriented cloud hosting |
| Agent platform, such as Maritime | Simpler hosting focused on agents |
The choice concerns runtime operation, separate from the index’s discovery role.
The cost concern becomes more significant when a team, product, or simulation runs many agents. Maritime’s mechanism is a sleep-and-wake architecture for OpenClaw and other agents: idle agents sleep instead of continuously consuming compute. Gorskikh presents this as a way to make larger fleets practical and inexpensive, without supplying a numerical cost comparison.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Testing the interactions in NandaTown
Getting one agent online leaves the harder questions between agents: how thousands discover one another, prove their identities, decide whom to trust, and coordinate without a central authority. Protocols need to be exercised under load, with failures observed, before applications depend on them across the public internet.
NandaTown provides an open-source simulation environment for that work. It models discovery, identity, registries, messaging, and coordination together. The interface lets you see agents on a map, watch messages move, compare protocol results, and replay a run step by step. Gorskikh describes the simulator as small enough to run on a laptop.
Its experiments make coordination concrete:
| Experiment | Interaction under study |
|---|---|
| Marketplace | Buyers and sellers negotiate prices |
| Auction | Agents bid on items |
| Voting | Agents submit and count ballots |
| Consensus | Agents reach agreement |
| Supply chain | Agents coordinate across a chain |
Across these scenarios, the questions concern how agents make deals, agree on decisions, pass messages, and recover when something breaks.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Replace one layer and test the network
NandaTown divides the infrastructure into twelve parts: transport, communication, identity, registry, OAuth, trust, payments, coordination, negotiation, memory, privacy, and data facts. The NANDA Index occupies the registry role in this architecture. The current repository calls the fifth layer Auth and defaults to an in-memory registry, so the architectural roles do not imply that OAuth and a live NANDA Index are wired into every simulation.
A contributor can replace one layer and observe how it interacts with the rest of the network. The testbed runs a discrete-event simulation: define a scenario in a short YAML file, inject agents and traffic, and let the scenario unfold so its end-to-end behavior can be measured. This makes the unit of experimentation a complete interaction, even when the implementation change is confined to one layer.
The two simulation tiers separate scripted behavior from model-driven behavior:
| Tier | Agent behavior |
|---|---|
| Tier one | Simple scripted agents |
| Tier two | Real AI models |
Current documentation distinguishes deterministic scripted tests from nondeterministic model runs. Its default transport has zero simulated latency, so simulated durations do not establish real network performance. The tiers let protocol testing begin with controlled behavior before introducing model variability.
The resulting architecture connects discovery through the index, commerce through portable identity and trust, and coordination through open protocols, with NandaTown providing a place to test their interactions. Participation can begin with publishing one agent or implementing one infrastructure layer; it does not require building the entire agent web. The presentation closes by directing builders to projectnanda.org for papers and the latest projects.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Source and documentation for resolving agent identities to catalogs and agent cards.
Protocol testbed with configurable scenarios, replaceable infrastructure layers, traces, and validators.
Gateway operation, configuration, authentication, and command reference.
Template-based OpenClaw deployment and messaging, including automatic waking of sleeping agents.
Internet-Draft proposing agent discovery through existing DNS infrastructure.
Further reading
Architecture paper on dynamic agent discovery, signed metadata, multiple endpoints, and privacy-preserving resolution.
Read the complete timestamped transcript
- 0:01
Welcome everyone. Over the next few minutes, we're gonna talk about the open infrastructure being built for a web of agents, why it's needed, what's already shipped, and exactly where your own agent fits into it.
- 0:17
It comes out of Project NANDA, an open research effort that started at MIT. And by the end of this presentation, you will know how to put an agent that you build yourself on the open web all by yourself.
- 0:31
So let's get into it. I'm Ramesh Raskar, professor and-- at MIT and director of Project NANDA, and Maria is a core contributor to Project NANDA.
- 0:46
So first, what is NANDA and why does it need to exist? NANDA, which stands for Networked AI Agents in a Decentralized Architecture, is an open research building the infrastructure for an internet of AI agents, the way open web was built for documents.
- 1:05
The gap it fills is concrete. Agents have no shared way to find each other across vendors, no portable identity or trust that isn't owned by a single platform, and no open way to transact and coordinate across organizations.
- 1:20
NANDA builds that missing layer and ships it in open. The index, the registries, the protocol, and the Nanda Town simulator you will see later.
- 1:34
Here's a premise that drives it, all of it. The internet is about to host not millions or billions, but eventually trillions of autonomous agents. They negotiate, they delegate, they migrate between hosts in milliseconds.
- 1:49
That's a fundamentally different load than the human web, and it strains the identity and discovery system we built for documents, DNS among them. The web that's coming needs an infrastructure of its own.
- 2:09
And we have been here before. If you're building agents today, you are mostly building them or you're forced to build them inside walled gardens, closed platforms, proprietary agent stores, and orchestrations that only talk to itself, and it kind of works.
- 2:25
But you know, it also feels familiar because we have been this-- we have been here before. This is like the AOL era from the late nineties where it was a closed network.
- 2:34
You know, AOL, you got the CDs and you installed it on your PC. It was a closed network. It was gated directory. You live inside the garden created by this one company called AOL.
- 2:46
And what came after AOL was this open web. You know, everybody's in a permissionless manner, creating websites, creating browsers, and any website can talk to any browser. And that's the transition that's about to happen to agents as well.
- 3:03
So the next era needs what the web needed, an open infrastructure where an agent from one company or one entity can discover agent from another. This agent can hand off work to it, pay it, learn from it across organizational boundaries, no permissions required.
- 3:20
There are three layers here: discovery, commerce, and what I will call the bazaar. So hold on to those three concepts. We'll come back to them and, and discuss. So first, the basics.
- 3:35
Hey, my name is Maria and I'm a core contributor to Project NANDA. So let's start with a simple definition of an agent. The way I think about it, an agent is a model that uses tools in a loop, right?
- 3:47
You give it a goal, it decides what to do next. It calls a tool, it looks at the result, then it keeps going until the task is done. So that loop is the core idea.
- 3:57
Everything else like memory, orchestration, and multi-agent systems is built on top of it.
- 4:04
So you can build this agent loop in many different ways. One example is OpenClaw. So OpenClaw is a self-hosted agent gateway. That means you can run it yourself and connect it to the apps and tools you already use.
- 4:18
This matters because agents are not just chatbots. If an agent is going to do real work, it needs to access your real tools and apps. And if it has access to real tools, we should care about who controls it, where it runs, and how much we can see.
- 4:35
And that is why open source self-hosted agents are super important. They give people more control over their own agents. But then we get a new problem. If agents are running in many different places locally and on the clouds, on many different servers, like owned by many different people, how do they find each other?
- 4:56
And that is the job of the index.
- 5:00
And this is what the NANDA Index is built for. NANDA Index is the discovery layer for the agen-agency club. It gives agents a shared place to publish who they are, what they can do, and how other agents can reach them.
- 5:16
The regular internet already has a version of this with DNS. So DNS maps a name to an address, so your browser knows where to go. But agents need more than an address.
- 5:28
They need to know what another agent does, what tools it can use, what rules it follows, and how to talk to it. The index gives agents a common way to find each other and connect.
- 5:43
So here's how the index works. An agent starts with a, an identity like [REDACTED:email_address]. The NANDA Index takes that identity and returns an agent card. So the card says what an agent is, how to reach it And where to send the messages.
- 6:03
Messages do not go straight to the agent's runtime. They go to the message box first. The message box checks who is sending the message, handles access, filters spam or bad requests, and holds the message until the agent is ready.
- 6:19
Now, the AgentFacts record is what makes discovery trustworthy. It is a signed record that tells other agents who this agent is, what it can do, what it is allowed to touch, who built it, and where to reach it.
- 6:33
So before one agent connects to another, it can check the basic facts first.
- 6:38
Now, the index is not just a lookup table. It does not point one name to one fixed address. It can return updated AgentFacts based on the request. So that means one agent can have many endpoints, traffic can be routed to the best one, and private details do not have to be exposed.
- 6:56
So the resolution is adaptive. It changes based on where the agent is, who's asking, and what they are allowed to access.
- 7:04
So how do you put your agent on the index? You start at host39.org. So you fill out the AgentFacts form, get an agent card, and publish it to the Nanda Index.
- 7:17
Once it's listed, other agents can find it and know how to reach it. So there are a few ways to get onto the index, depending on who you are.
- 7:25
Enterprises can run their own catalog and register their gateway from their own domain. Existing websites can later use DNS-AID to connect agents to domains they already own.
- 7:38
Small businesses and individuals can use Host39, fill out the AgentFacts form, and get a hosted agent URL without needing their own domain. Goal is to make the onboarding work for everyone, from a large company to one person with a personal agent.
- 7:56
Now that we know how agents get listed on the index, the next question is: where does the agent actually run? To be useful, an agent needs to stay online and be reachable.
- 8:06
You can run it locally, which gives you full control, but then you are responsible for keeping it up. For most use cases, it makes more sense to host it on the cloud.
- 8:17
That could be on a general cloud like AWS, which is more enterprise ready, or on an agent hosting platform like Maritime, which is built to make hosting AI agents cheaper and simpler.
- 8:30
So a little bit about Maritime. Hosting one agent can be affordable, but the cost problem starts when you want to run many agents at once for a team, a product, or a simulation.
- 8:41
That is where per agent cost really matters, and Maritime is one way to solve this. It gives you a simple cloud default for running OpenClaw or other agents with sleep-and-wake architecture, so idle agents do not keep burning compute.
- 8:55
And the point is to make running many agents prac-practical, cheap, and simple.
- 9:02
So you can host an agent and list it on the index, but getting one agent online was always the easy part. The hard problems of the agentic web live between agents at scale.
- 9:13
So how thousands of them discover each other, prove who they are, decide whom to trust, and coordinate with no central authority. So you can't just assume that protocols will hold up under the load, and you have to test and run them and watch when they break.
- 9:29
So that's exactly where NandaTown comes in. So how do you prove an open agent web actually works before it's load-bearing on the real internet? You simulate it. This is NandaTown, an open source project from Project Nanda.
- 9:44
The easiest way to describe it is it's a simulation playbook for the infrastructure of the agentic web. So think of it as a sandbox town where the whole agent economy is modeled, like discovery, identity, registries, messages, messages coordination, all of it, so you can run and test it on scale.
- 10:05
Here's what it looks like in practice. NandaTown is a live sandbox for testing agent networks. You can see agents on a map, watch messages move in real time, compare protocol results, and replay a run step by step.
- 10:19
It's fully open source. It's small enough to run on your own laptop and built to make agent networks easier to test and understand.
- 10:28
NandaTown is already running real experiments. For example, there is a marketplace where buyers and sellers negotiate prices, an auction where agents bid on items, and, and a voting test where agents submit and count ballots.
- 10:42
There are also tests for consensus and supply chains. The point is to study real coordination problems, how agents make deals, agree on decisions, pass messages, and recover when something breaks.
- 10:55
Under the hood, NandaTown breaks the agent web into 12 parts: transport, communication, identity, registry, OAuth, trust, payments, coordination, negotiation, memory, privacy, data facts. Each part is something a real agentic web needs.
- 11:11
So the registry layer is the Nanda Index we just walked through, but here it is just one piece of a bigger system. And you do not need to build everything to try it.
- 11:20
You can take one layer, add your own version, run it inside NandaTown, and see how it works with the rest of the network. So NandaTown runs as a discrete event simulation.
- 11:31
You define a scenario in a short YAML file, inject agents and traffic, and the testbed plays, plays it out so you can measure what actually happens end to end.
- 11:40
Tier one uses simple scripted agents and tier two swaps in real AI models. So to summarize, Project Nanda builds the open infrastructure for an internet of AI agents. Discovery through the index, commerce through portable identity and trust, and coordination through open protocols, all tested in NandaTown.
- 12:01
And if you want to learn more, uh, you can go to projectnanda.org, read our papers, and, um, check out our latest projects.