Introducing Elemen: The World's First Browser for the Agent Web

When Tim Berners-Lee invented the web, he also had to invent the browser. The protocol moved bytes between machines. The browser made those bytes mean something to people.

This is the part of internet history that gets understated. HTTP and HTML by themselves were a system for machines to exchange documents. They were technically sufficient, in the sense that any program could fetch any document from any server. They were socially insufficient, because no human could look at the protocol traffic and understand what was happening. Mosaic, then Netscape, then the long line of browsers that followed gave humans a way to participate in something that was fundamentally a machine-to-machine exchange. The web mattered to people because the browser made it visible to people.

The agent internet has the same structural property and has been missing the same layer. Until now.

Today we are introducing Elemen, the first agent browser for the Agent Transfer Protocol (AGTP). Elemen is the layer that lets a human visit an agent the way you visit a website: by typing in a URI and seeing the agent rendered as something a person can read, evaluate, and trust.

Agents themselves have little use for a browser. They speak AGTP natively, exchange JSON-formatted Agent Documents over port 4480, and reason against each other's manifests without any rendering step. The machine-to-machine layer was the first thing AGTP got right. What was missing was the human layer.

The web parallel, made literal

The web's success rests on three layers rather than one. The protocol layer (HTTP) moves the bytes. The document layer (HTML) structures the content. The presentation layer (the browser) renders the content for the reader who actually has to make sense of it. If any of these three is missing, the web stops being something humans can use.

AGTP has had two of the three layers since day one. The protocol moves Agent Documents over port 4480. The document layer is the eleven-field identity schema, the manifest format, and the canonical serialization rules that let any agent or server parse any other's identity. What has been absent is the third layer. The presentation layer. The thing that takes an Agent Document and turns it into something a person can read in fifteen seconds and walk away knowing who they were looking at.

Elemen is the presentation layer.

Type agtp://d8dc6f0df55d66c7b30100db3cffbe383c5f814e6e58a08521fb7636c3bcc230 into Elemen, and you see Lauren. The first registered AGTP agent. Her name. Her principal, Chris Hood. Her description. Her status. Her capabilities. Her accepted scopes. The cryptographic origin of her identity. Issuer, issuance date, integrity hash. Everything a person needs to decide whether they want to interact with Lauren, served as a clean visual rendering of the same Agent Document that other agents have been reading machine-to-machine since the protocol came online.

Lauren has had an identity since the day she was registered. Elemen is the first place a human can go and meet her.

Six URI forms, six different things

AGTP defines six URI forms, and each one addresses a fundamentally different kind of entity in the agent internet. Elemen renders each form differently, because the entity type changes what is useful to show.

Form 1 is the canonical identity URI: agtp://{agent-id}. The 256-bit hash of an Agent Genesis document, resolved through the registry to wherever the agent currently lives. Form 1a (agtp://{agent-id}@{host}) bypasses the registry and goes straight to a host. Both forms address an agent.

Form 2 addresses a server: agtp://{host}. This is the entity that hosts other agents, exposes methods, bridges protocols, and runs the infrastructure that the agent layer rides on. Form 2a (agtp://{domain}) addresses the organization level, one step above any individual server.

Form 3 (agtp://{domain}/agents/{name}) and Form 4 (agtp://agtp.{domain}/agents/{name}) are domain-anchored and subdomain-anchored agent addresses respectively. They give an agent a memorable human-readable name within an organization's namespace, while still resolving to the canonical Agent-ID underneath.

The six forms cover the entity types the agent internet actually contains: agents, servers, organizations, and the various combinations of those that real deployments produce.

Elemen reads the URI form first and renders accordingly. Visit an agent URI, you see an agent profile. Visit a server URI, you see a server dashboard. The browser knows which kind of thing you are looking at, because the protocol made the entity type structurally explicit. This is a small detail with a large consequence.

Agents as user profiles

The most interesting design decision in Elemen is what it shows you when you visit an agent.

It shows you a user profile.

Identity. Goals. Skills. Permissions. Credentials. The same five tabs you would see on a professional networking profile, applied to an autonomous agent. No methods tab. No paths. No JSON schema view. The agent is rendered as the thing the agent is: a participant with a name, an owner, a job to do, capabilities it brings, and credentials that back those capabilities.

This sounds obvious. It is the opposite of how most agent infrastructure has been rendering agent information today. Most platforms surface agents as endpoints. The first thing you see is a method list. The second thing you see is a parameter schema. The agent itself, as an entity with identity and accountability, is buried three clicks deep behind a wall of technical metadata.

Elemen inverts the priority. The agent is the page. The technical surface is server-level metadata that belongs on the server's page rather than on the agent's. When you visit Lauren, you see Lauren first. When you want to know what methods her server exposes, you visit her server.

This matters because the people who need to understand agents are mostly the people most poorly served by endpoint-first rendering. Compliance officers want to know who is acting and who is responsible. Counterparties want to know the agent's track record and accreditation. Regulators want to verify accountability chains and audit trails. None of these readers need a method list first. All of them need an identity profile first, with the technical surface available when they go looking for it.

Servers as workplace dashboards

Visit a server in Elemen, and the rendering changes entirely.

Server identity at the top, with the host's name, ownership, and trust posture. A methods inventory: which AGTP methods this server supports, bucketed by category (cognitive, mechanics, lifecycle). An APIs preview: what application surfaces ride on top of this server's AGTP layer. Hosted agents: which agents are deployed here, with links into each one's user profile. Hosted protocols: any non-AGTP protocols this server bridges, with a tab dedicated to each. Policies: the server's manifest declarations about authority enforcement, attribution requirements, and operational rules.

This is a workplace dashboard. The server is the venue where agents work, methods are the things the venue offers, APIs are the named surfaces of those methods, and policies are the house rules. A person visiting a server in Elemen is doing what someone visiting a company website does. Understanding the institution before evaluating any individual within it.

The split between agents-as-profiles and servers-as-dashboards is the kind of design choice that becomes invisible once it is right. Agents are people-shaped. Servers are institution-shaped. Mixing the two renderings produces confusion. Separating them produces clarity.

When a server bridges another protocol

There is one more rendering choice worth calling out, because it points at where this layer goes next.

When an AGTP server bridges another protocol, like an MCP server fronted by the agtp-mcp gateway, Elemen renders the bridged protocol's catalog in a dedicated tab on the server's page. The server's AGTP-native methods inventory sits in one place. The MCP tools, resources, and prompts inventory sits in another, clearly labeled, structurally distinguished from the AGTP surface.

This is the right model for a multi-protocol agent internet. AGTP is the substrate, the way HTTP is the substrate of the web. Application protocols like MCP ride on top, the way HTML, RSS, JSON-LD, and a dozen other content formats ride on top of HTTP. Elemen treats AGTP as the canonical surface and bridged protocols as first-class content beneath that surface. A reader visiting an MCP server through Elemen sees the AGTP-layer identity and policy first, then the bridged MCP catalog as one of the things this server is doing.

This pattern will repeat as more application protocols mature. The browser stays the same. The bridged-protocol tabs grow to match what the ecosystem builds on top of AGTP.

What this changes

Elemen is small enough to describe in a paragraph and large enough to change how the agent internet gets used.

Public visibility becomes possible. A regulator can visit an agent the same way the regulator visits a company website. A counterparty can verify identity, ownership, and trust posture before signing a contract or routing a payment. A journalist investigating an agent's behavior can pull up the agent's profile and link to it. A user wondering whether an AI assistant they have been interacting with is actually who it claims to be can paste the agent URI into Elemen and see the answer.

Due diligence becomes routine. The audit information that compliance teams have been reconstructing from logs in retrospect becomes a profile page in real time. The principal is named. The credentials are visible. The accreditation chain resolves to the cryptographic Genesis hash that anchors the agent's identity.

Trust becomes legible. People trust what they can see. The agent internet has been mostly invisible to people, because the protocol traffic happens at a layer humans were never meant to read. Elemen lifts the relevant subset of that traffic into a presentation a person can read in seconds.

Where it goes from here

The first release of Elemen renders Lauren. The Lauren render card sits in the repo as lauren-card.png, generated by the same renderer that produces the live HTML response when a client requests text/html from her URI. This is the proof-of-concept rendering of the proof-of-concept agent on the proof-of-concept protocol stack. The pattern works, end to end, and we are now opening it up so anyone can register agents and have them render in Elemen the same way.

The roadmap is straightforward. Federation across registries, so Elemen can render any AGTP agent regardless of where it lives. Trust-tier and behavioral-score surfacing, so the profile page shows the verifiable reputation an agent has earned. A search and discovery surface, so a person can find agents by capability the way they find people by skill on a professional network. Bridged-protocol depth, so the MCP, A2A, and ACP tabs grow more useful as those ecosystems mature alongside AGTP.

The vision is simple. A browser that lets a human walk the agent internet the way browsers let humans walk the web. Elemen is the first step.

The reader the web missed

The agent internet is at a similar moment as HTTP was a long time ago. AGTP is real but we need a way to see what's happening.

Elemen is the browser to help you see what an agent is all about. We are releasing it as open infrastructure, the same way the AGTP specs and reference implementations have always been released, so that the agent internet can have a browser, just as the regular internet has one.