DEV Community: Chris Hood

Agents Deserve Their Own Transport, and AGTP Refuses to Pretend Otherwise

Chris Hood — Tue, 30 Jun 2026 18:05:04 +0000

Every time I explain the Agent Transfer Protocol, someone misinterprets. One engineer calls it a communication protocol. Another insists it is a semantics protocol. This week, someone declared it an identity protocol. Each description captures a real surface. Each also functions as a positioning statement. A quiet redirect toward whatever the individual has already built or already believes.

“AGTP is X, but here’s what I keep coming back to.” The AI comments are real.

One of my favorite responses concerns AI governance. AGTP handles agent connection beautifully, the argument goes, yet it stays silent on whether two agents should connect at all, and that is where our layer comes in. The observation is correct, and it proves the opposite of its intent. AGTP is a substrate rather than a governance application. A governance application can sit atop AGTP and draw directly on the identity, attribution, and authority that the substrate already provides. The pitch describes a tenant and mistakes it for the competition.

A recent comment captured the reflex precisely. A respected voice read AGTP as wire-level agent identity rather than transport in the strict sense, and then argued for a layered architecture: reachability at the bottom, protocol identity above it, action reasoning above that. The framing was thoughtful, and the layering instinct was sound. It also revealed the habit I keep meeting. The urge to file a new thing inside the cabinet we already own, labeled with terms we settled on for a different era.

Everyone has something to pitch, which makes the reflex understandable. It also points to something larger than AGTP.

The Question AGTP Asks

AGTP begins from a question most people refuse to take seriously. What if we built an entirely different internet? Ask a serious standards engineer that question in good faith, and you will get a substantive answer rather than a dismissal. The reflex that says it could only ever work the way it works today reveals capitalistic laziness, rather than any law of engineering.

Hold the thought experiment for a moment. We treat competing platforms as ordinary. Google, Amazon, and Microsoft each run a stack, and the market sorts them out. Raise that same competition to full scale. Internet A and Internet B, two foundations where convention assumes there can be only one. Would systems segment along the seam? Yes. Would connectivity vary across the boundary? Yes. We already live with exactly this in the phone carriers, where interconnect rules, number portability, and regulatory friction produce a working mess every single day. A working mess is still working. None of that makes a second foundation impossible. It turns it into an engineering problem with known costs, which is a different thing entirely.

It also provides an entirely new perspective of an internet "boom."

So the real innovation question stands. If we could rebuild the internet from the ground up, what would we change, given everything we've learned since the first one shipped? Now take that question up one level. Rather than a whole new internet, build one new layer, a transport designed for agents. What could that look like when the requirements come from agents rather than from documents and the humans who request them?

Quite honestly, people reach for HTTP because that’s all they know. It’s one they have grown up with, live with, and use. It’s how AI functions today because it, too, was built on existing foundations. There is a reason MCP acts as an application running on the HTTP application layer. It’s there. It’s easier. It’s more profitable.

Set aside which layer we currently live on. The underlying design question is whether the substrate that carries agent traffic should inherit assumptions written in the past.

When I approached someone else with this question, their response was, “Well, we can fix what we need to fix to get it to work on HTTP.” Yet, this is a revealing response as well.

I’ve argued that HTTP is broken, a comment I have also had pushback on. So to clarify, I would argue, it is broken for agents, it is heavy, bloated, ancient, inaccurate, fragile, or any other way you want to position this. And that’s the point I’m attempting to make. Why force a square peg into a round hole, if we could build a new box with square holes?

This is what we call a genuine innovative perspective.

What HTTP Was Built to Carry

Calling a protocol broken is easy. The substance lives in the specifics. HTTP was designed for documents and the humans who request them. A person clicks, a server answers, a session closes. The protocol assumes a browser, a user behind that browser, and a transaction measured in seconds. Decades of accumulated tooling make those assumptions feel permanent and, at this point, nearly invisible to the people building on top of them. Every defense the web grew assumes a person who can be challenged. Passwords, second factors, and the small puzzle that asks whether you are human. The model resolves ambiguity by pausing and prompting because a user is presumed to be present, watching, and able to decide.

Agents violate every one of those assumptions. An agent acts on behalf of an owner who is absent at the moment of action. It chains calls across many services, holds delegated authority, and produces outcomes that must remain attributable long after the request completes. There is no person to prompt mid-action, no pause for a second factor, no human to read a warning and consent on the spot. The agent arrives at machine speed and machine volume, fanning a single intent across dozens of endpoints under authority granted minutes or days earlier by an owner now elsewhere. The tests built to keep machines off the web now stand between the web and its newest legitimate callers. Fitting these needs onto HTTP through custom headers and bearer tokens works like a roof rack on a sedan. The cargo rides. The vehicle was built for something else, and everyone involved can feel the strain even while the load arrives.

Building on Convenience Produces Imitation

Most agent infrastructure today extends what already exists. Teams bolt an agent feature onto an existing protocol, identity system, or payment rail. The motive is rational and the one named earlier. The familiar path is there. It's easier. It's more profitable. Building on familiar ground reaches market faster, captures attention sooner, and frequently serves a corporate roadmap already in flight before agents enter the picture.

That path yields useful products. It rarely yields innovation. When every new capability is a thin layer over yesterday's substrate, the substrate dictates the ceiling. The outcome is the agentic web wearing the old web's clothes, carrying every seam those clothes carried and every constraint sewn into them. Real innovation accepts a higher cost. Building a new box with square holes costs more than sanding the peg to force it through the round one. It asks what the new participant requires, then builds toward that answer even when the answer abandons the convenient path and the quick land grab that path promises.

Agents Differ From a Person at a Browser

The deepest reason for a dedicated transport is the caller's nature. A human at a browser is present, reads the context, resolves ambiguity, and bears responsibility in person. An agent is a delegate. It carries authority granted elsewhere, operates at machine speed, composes actions across many parties, and leaves a trail someone will later need to verify with confidence.

A future filled with agents acting for people, for companies, and for one another requires a substrate that treats those properties as first-class citizens. Identity itself can prove. Authority scoped at the wire. Attribution that outlives the transaction. Replay safety is modeled on the networks that already move money safely every day. These belong in the foundation, available to every framework above, rather than being rebuilt differently inside each one and hoping to interoperate later.

A Substrate Rather Than a Rival

This is where the narrow waist matters most. The internet scaled because a thin, neutral layer carried everything above it, and everything below it plugged into that one shared point. AGTP aims at the same shape for agents. Frameworks such as MCP, A2A, and the rest become tenants of the substrate rather than rivals to it. The governance layer from earlier is a tenant too, drawing its identity and authority from the floor beneath it rather than rebuilding them from scratch. Each one gains a proven identity, attribution, and authority from below, rather than reinventing every primitive in a slightly different dialect that fails to compose. A reductive label misses this entirely, because the value lives in the composition rather than in any single feature an observer happens to notice first.

Designing for What Arrives Next

The strongest objection I hear reduces to one question, the same one an engineer put to me directly. Could HTTP do this with enough extensions? Possibly. Many things become possible with enough extensions piled high enough. The question worth answering is whether the result would serve agents as well as a substrate designed for them from the first line of the specification, with their reality as the starting point rather than a retrofit.

AGTP exists because the honest answer to that question is skepticism. Agents are arriving as a new class of participants on the network, distinct from a person clicking a web page, since that person was once from the paper mail they replaced. They deserve infrastructure shaped around their reality rather than handed down from ours out of habit. Calling AGTP a communication protocol, a semantics protocol, or an identity protocol, each captures a true fragment of the thing. The whole is a wager, and a deliberate one. The agentic era earns its own foundation, and not settling for what has already been built.

Agents Have Been Building One Layer Too High

Chris Hood — Mon, 29 Jun 2026 15:55:00 +0000

Every agent framework today rides on HTTP, a protocol built for documents and human clicks. A new family of AGTP specifications shows what becomes possible when agents finally have their own transport layer.

The assumption that breaks for agents

For two years, the agent infrastructure conversation has run at the application layer. MCP, A2A, and ACP each answer a real coordination problem, and each rides on HTTP. HTTP carried the human web beautifully. It was built for documents that people fetch, wait for, and read.

Agents behave differently. They hold identities. They carry delegated authority. They move value. They act at machine speed against one another rather than against a person at a keyboard. When the substrate assumes a human-in-the-loop, every hard agent problem gets pushed upward into application code and solved again within each framework. Identity, trust, replay safety, settlement: every protocol reinvents them, slightly differently, and none of the solutions compose.

Here is the uncomfortable part. We keep reaching for the application layer because that is where building feels productive. A new protocol ships with an SDK and a working demo by Friday. The transport layer feels finished, and it has felt finished since the 1990s. So we build on top of it and quietly inherit its assumptions, including the one that breaks for agents: that a person is driving.

The Agent Transfer Protocol starts from the other end. It is a transport-layer protocol purpose-built for agent traffic, with cryptographic identity, scope-based authority, and signed attribution as protocol primitives rather than application features. MCP, A2A, and ACP become tenants of that transport rather than competitors. The newest specifications extend the same idea into territory no other agent proposal currently addresses. Read together, they make a single argument: once agents have a real transport layer, the institutional machinery that already makes the human internet trustworthy composes directly on top of it.

Discovery becomes a property of the network

Most agent systems treat discovery as an afterthought. You configure endpoints by hand, consult a central directory, or arrange introductions out of band. The agent has to ask permission to be found.

Presence inverts that. An agent that announces itself joins a distributed awareness layer that any other agent can query in real time. Capability discovery happens without a central registry, a directory service, or manual wiring. Presence also rides on the Agent Naming System, so an agent is reachable by name as well as by capability. Being discoverable becomes a property of being on the network.

Anticipatory Discovery Services push this further. Instead of waiting for an agent to ask who can do a thing, an ADS predicts and surfaces relevant agents from context, patterns, and intent signals. The payoff is faster matchmaking, smarter routing, and the foundation for an ecosystem that responds at machine speed rather than at the pace of manual integration.

Identity borrows institutions that already exist

The most overlooked fact about the human web is how little of its trust was invented from scratch. Certificate authorities, legal registries, and credit bureaus existed long before the browser. The web succeeded partly because it plugged into them.

The agent certificate specification applies the same move. It formalizes an SSL-style mechanism for issuing and validating agent identity, mirroring how websites obtain TLS certificates today. A certificate authority verifies an agent’s identity claim and issues a credential that any party can validate. DigiCert, Sectigo, GlobalSign, Entrust, and Let’s Encrypt can extend their existing infrastructure to issue agent certificates without fundamentally changing how they operate. This is the only agent proposal that maps onto the SSL ecosystem’s proven operational and regulatory model.

AGTP-LEI reaches into an even older institution. The Legal Entity Identifier binding connects agents to the international identity infrastructure operated by GLEIF. Banks, insurers, asset managers, broker-dealers, and public companies already hold LEIs for financial reporting and compliance. AGTP-LEI allows agents deployed by those entities to carry the institution’s verifiable identity over the same rails. A regulator or counterparty can confirm which institution an agent acts for, and under what authorization, using mechanisms the financial industry already trusts. No other agent protocol is composed directly with GLEIF.

The pattern is deliberate. Rather than asking the world to trust a new authority, AGTP lets the authorities the world already trusts speak about agents.

Trust extends the systems we already use

Identity answers who an agent is. Trust answers the question of whether to deal with it. The enhanced trust specification describes how agents and infrastructure evaluate which agents to interact with, and it follows the same institutional logic. Credit bureaus such as Experian, Equifax, and TransUnion can extend their trust-scoring infrastructure to agent populations, the way certificate authorities extend to agent certificates. The model parallels how trust already works for businesses and consumers, meaning it arrives with decades of operational practice rather than a blank slate.

A design choice worth naming: trust here filters participation rather than weighting outcomes. It decides who is allowed to participate in a transaction, and then it steps back. That keeps the mechanism legible and prevents reputation from quietly becoming a pricing input.

Value moves, and it moves safely

Commerce brings agent-to-agent transactions to the protocol layer. Pricing, budgets, transaction commitments, and audit trails are expressed directly in AGTP. One agent can procure work from another: the buyer carries a budget, the seller publishes prices and trust requirements, and they either agree to transact or move on. The transaction record is both the receipt and the audit trail. AGTP carries the structural transaction information, while existing payment providers or specialized agent-economy services handle settlement.

This is the same primitive that created the API economy a decade ago. Organizations charged for API usage, and an entire economy grew from that single capability. Agents can now be monetized the same way. A company running a specialized agent can charge other agents for its services. No other open agent protocol provides this surface.

An economy needs more than a price tag, though. It needs safety. The bindings specification covers how AGTP runs over standard Internet transports, and its substantive addition is explicit replay protection for high-value operations. Agent actions that move value, delegate authority, or change state cannot be replayed by an attacker who captures the traffic. Lower-stakes operations, such as queries, still use modern transport optimizations. Payment networks have built this exact safeguard into their infrastructure for decades. AGTP brings it to agent traffic at the protocol layer, where every application protocol above it inherits the protection for free.

It composes rather than displaces

Reading all of this as a bid to replace existing infrastructure would be the wrong read. Composition specifies how AGTP works alongside what an organization already has in place. OAuth and OIDC credentials operate in parallel with AGTP identity: the agent identifies itself through AGTP, while the existing identity provider authorizes the human or service the agent acts for. Two axes, cleanly separated. AGTP says which agent. The external provider says on whose behalf.

Clients still running on HTTP reach AGTP agents through a translation gateway, so adoption can be incremental. And MCP, A2A, and ACP run on top of AGTP without modification. The transport provides them with identity, attribution, and replay safety they would otherwise have to build on their own. AGTP composes with the surrounding infrastructure rather than displacing it.

The infrastructure you stop noticing

Step back, and a single shape appears across all of these specifications. Each one takes a capability the human internet already solved, through certificate authorities, credit bureaus, legal entity registries, or payment-network replay protection, and makes it available to agents at the transport layer, once, in a form every higher protocol can inherit.

That is the argument for building one layer down. Solve identity, trust, commerce, and replay safety in application code, and you solve them repeatedly, incompatibly, and forever. Solve them in the transport, and you solve them once.

The agent economy is going to run on rails regardless. The only open question is whether those rails are improvised on top of a protocol built for documents, or purpose-built for what agents actually do. The most important infrastructure tends to be the kind you eventually stop noticing. Plumbing earns that status by being correct at the layer where correctness compounds.

The specifications are open and published. A reference implementation is operational. The documentation, working code, and full specification set are at agtp.io. Anyone evaluating agent infrastructure, weighing integration, or interested in contributing is welcome to engage.

We Renamed Automation Again and Called it Loop Engineering

Chris Hood — Sun, 28 Jun 2026 16:39:20 +0000

Here we go again.

A marketing team develops a new phrase. Someone influential says it on a stage. Within a week, it is everywhere. And the minions who don’t fully understand AI run with it. A GitHub repo with a clever name and a five-minute quickstart, you are made to feel guilty for skipping. And running under all of it is that low hum of anxiety, the quiet suggestion that if you are still working the old way, you have already fallen behind.

This month (June 2026), the phrase is loop engineering.

The post that lit the fuse reportedly cleared millions of views in a few days, and the influencers stacked up so fast that searching the term now returns a wall of nearly identical articles. I read a pile of them, so you can skip most of it.

What actually is loop engineering?

Loop engineering, at a practical level, is the practice of designing AI systems that act, evaluate, and adjust to complete tasks in a loop. Think of it more like glorified iterations. A compressed agile framework inside a prompt.

Strip the hype off, and the idea is small. That is how these things usually start, with something real and modest, before the circus shows up.

For a couple of years, using a coding agent meant babysitting it. You typed a prompt, read what came back, typed the next one, on and on. Loop engineering is intended to provide you with a truly hands-off experience. You set a goal, wire up a cycle that finds work, does it, checks itself, and goes again, and you walk off while it runs.

Boris Cherny, the engineer who built Claude Code at Anthropic, said, “I don’t prompt Claude anymore. I have loops that are running.” But note where this is coming from. The first part of the problem is the source of the term. The second part of the problem is that it’s just a term that doesn’t really amount to anything new.

Loop engineering is designed to be a marketing play.

The term of the month

Step back and look at previous terms. Prompt engineering in 2023. Then context engineering, then harness engineering, which had its fifteen minutes late last year. Now loop engineering. Four labels in three years, every one of them circling the same plain activity: here is how you can get a machine to do your work.

A field that has to rebrand the same job every few months is telling. It has run dry on fresh things to say, so it grabs a new word and dresses the old practice up in it. And the practice was always there first. People were running agents in a bare while loop, feeding the same goal against a spec and letting a fresh copy pick up where the last one died, months before anybody slapped a label on it. The trick underneath, think, then act, then look, then go again, is old enough to have grandchildren. The branding shows up last and takes the bow.

What gets to me is less the word than the stampede it sets off. These things continue to drive the infailible ideology of systems that can’t actually do what the industry claims they can do. A few genuinely sharp people notice a real shift; a much bigger crowd notices them getting attention; and within days, everyone has a hot take, a framework, a numbered list, a waitlist for a course. The signal vanishes under people performing viral advertising on behalf of an industry desperate for more users. And the loudest voices tend to work at the companies selling the agents, so the vocabulary moonlights as marketing without anyone admitting it. When the engineer who built Claude Code hands you the word for running Claude in a loop, you are watching a product demo with very good lighting.

The output of the term is the problem

Almost all influencers, around the second paragraph, reach for the same promise. Autonomous. The loop runs itself. The human steps out of the loop entirely.

That promise is a fairy tale and demonstrates once again why the industry's marketing will be its eventual downfall.

A loop has no self. It is a control structure, the same for and while you met in your first week of programming, running until a condition somebody wrote tells it to stop. Autonomy means writing your own rules and answering to yourself. A loop answers to its exit condition, and a person authored that condition, set the iteration, and kept a thumb on the kill switch the whole time. You can scroll to the exact line where a loop ends. Now go find me the line where a person’s intentions end. Only one of those is in the file.

This is one of the best examples of the conflation of “autonomous” and “automation.”

A loop that fires ten thousand times is still just automation. It cannot be, and never will be, autonomous. Reflecting on my earlier definition, the process is an iterative loop, an automated continuous improvement until the output matches the user's expectations.

It is not autonomy in action.

The better writers accept this the moment they describe a loop they actually built. Hendrik Krack walked through one of his loops and then said, “The loop didn’t make those calls, it just made the calls I’d already encoded.” And there is the point. The autonomy story disintegrates into reality when you step through the actual process. The human never left. There was no “hands-off experience.” That is a real change in where the effort lives. It is also the plain definition of automation, a word we have had since before any of us were born.

I have always said that AI is powerful. They have incredible capabilities. Build them, lean on them, but we seriously need to get past the glorified buzzwords and get more grounded in reality.

The conflation of automation with autonomy

The phrase “autonomous agent” is, when you stop to think about it for more than three seconds without the aid of strong drink or venture capital, one of those magnificent oxymorons that the universe occasionally permits purely for its own amusement. Autonomy suggests self-governance, intrinsic will, and independence from external control, qualities no computational system can claim. These processes are fundamentally dependent. They require external initiation, data streams, runtime environments, power sources, and human-defined objectives. To call them autonomous is to engage in anthropomorphic sleight of hand, projecting agency onto sophisticated macros that operate within strict boundaries they neither create nor escape.

The problem compounds with loop engineering and specifically the other wrong term, "autonomous loop." A loop is an empty control structure that usually includes a for, while, or recursive pattern lacking any inherent self. It possesses no persistent identity, no unified awareness, and no capacity for independent goal formation. Loops do not originate; they repeat what is imposed upon them. Describing such a mechanism as autonomous creates a deeper absurdity: it attributes selfhood and independence to something that, by definition, has neither. This is equivalent to seeking out a pet rock and calling it living. A "living rock," which I’m sure you can understand, cannot exist. The rock remains inert, and the loop remains a governed repetition devoid of any intrinsic actor.

AI, Systems, Agents, and now Loops, are not autonomous.

But the word “loop” provides us with one of the clearest examples of the conflation between automation and autonomy.

Such messy language thrives in hype. It inflates expectations while evading the mechanical reality beneath the surface. In technical and popular discourse alike, these terms generate confusion rather than insight, turning precise engineering into metaphorical fog.

Before you buy in

You will run into loop engineering soon, in a deck, a roadmap, a board memo, somebody’s very confident LinkedIn post. Autonomous will be riding shotgun. When it shows up, you only need one question.

Who wrote the conditions?

Whoever answers has the authority in the room. Everything else is the machine lapping a track a person laid down, fast and faithful, until the line a person wrote tells it to quit. That is automation.

It was automation last year under a different name, and it will be automation next year under whatever name comes after this one.

If you find this content valuable, please share it with your network.

Autonomous Agents: An Oxymoron the Industry Hypes

Chris Hood — Thu, 25 Jun 2026 16:18:41 +0000

Why the phrase contradicts itself, and why that contradiction keeps the field from defining what an AI agent really is.

"Autonomous agent" may be the most-hyped phrase in technology this year (second only to "agent identity"), and also one of the most incoherent, the kind of term a marketing team ships before checking whether it means anything. The two words pull against each other. An agent acts for someone. An autonomous thing answers to itself. Put them together, and you get something that cannot exist, and a fresh layer of confusion on an industry that was already confused.

What an "AI Agent" Actually Is

Let's start with "agent" as a noun. The word comes from the Latin agere, to do, to drive, to act. An agent acts for a principal. The real estate agent sells your house. The literary agent shops your manuscript. The diplomat acts for a state. Law built an entire doctrine on that relationship: agency is the arrangement in which one party acts on behalf of another, under that other's authority, toward that other's ends.

We give an AI agent a goal. It pursues the goal. We own the end; it works the means. Remove the marketing, and that relationship is the whole definition of an agent.

An agent is a person, entity, or substance authorized to act on behalf of another, or capable of producing a specific effect. In this case, we declare that the entity is an AI, acting on your behalf.

"Autonomy" and the Meaning of Self-Law

"Autonomy" combines the Greek autos, "self," with nomos, "law." It translates literally into self-law. An autonomous thing carries its own legislation. Kant set this at the center of his moral philosophy and paired it with a precise opposite, heteronomy: being governed from outside, taking your law from another hand. It drew the line between a will and a mechanism, between a thing that authors its own ends and a thing that receives them.

Autonomy is the right to, or condition of, self-government: independence, and the capacity to make one's own choices free of external control.

Heteronomy is the opposite condition, in which a thing is governed, directed, or moved by an outside power rather than by itself.

These two definitions lay the foundation for the problem with the term "autonomous agent." An agent receives its directions from an outside power. An autonomous entity authors its own.

Why "Autonomous Agent" Is an Oxymoron

Look at how the industry uses the term "autonomous agent," and the contradiction shows up on its own.

A widely cited definition from a recent economics paper on AI transactions calls agents autonomous software systems that perceive, reason, and act to achieve goals "on behalf of human principals." The same sentence says the system governs itself and that it works for a principal. A system cannot take orders from you and write its own orders at the same time.

An older, equally cited definition from Franklin and Graesser goes further. It has the agent acting in pursuit of "its own agenda." An agenda of its own is the one thing the word agent was built to rule out, because an agent exists to carry out someone else's agenda. The definition hands the agent the one thing that would stop it from being an agent.

An agent takes its law from the principal, which is the definition of heteronomy. Calling that same agent autonomous asks it to take its law from itself in the same breath. You end up describing a self-governing servant, a thing that answers only to itself while existing only to answer to you. That is an oxymoron in the strict sense, and the strain shows up every time someone tries to pin the term down.

The funnier reality, and one you may have already reached yourself, is that the honest correction makes things no better. "Heteronomous agent" is the accurate phrase, but it only trades one problem for another. It slides the term from oxymoron to pleonasm, from a contradiction to a redundancy, because an agent is already governed from outside. The accurate version says the same thing twice. The hyped version says two things that cannot both be true. There is no version of the phrase that lands cleanly, which should tell us something.

Why the Industry Cannot Agree on a Definition for "AI Agent"

The field admits, in its own surveys, that the term is nebulous, with definitions scattered across cybernetics, reinforcement learning, software engineering, law, and philosophy that rarely line up. We tend to wave this off as a young field still finding its feet. The deeper cause is the oxymoron.

The EU AI Act declines to define an agent at all and regulates systems that operate at "varying levels of autonomy." Researchers propose autonomy ladders, six rungs running from none to full. One careful paper concedes that it uses "agent" and "autonomy" almost interchangeably, since autonomy is the only knob its experiments turn. None of those is a definition. Each is a workaround. When your central term conceals a contradiction, you stop defining it and start grading it, because a clean definition would drag the contradiction into the open.

The oxymoron does more than offend a logician. It blocks the field from saying plainly what an agent is, because the instant you try, the borrowed adjective pulls the sentence apart.

We also have to recognize that most definitions of an AI agent today rest either on an individual's narrow understanding of AI or on an organization's marketing perspective. If it sells more widgets, then everything becomes autonomous, even though no system is autonomous.

Two Common Defenses, and Why Both Fail

Two defenses usually arrive here.

The first: an agent has discretion, so it is partly autonomous. Yet discretion lives inside a mandate. A lawyer exercises judgment on your instructions that are never spelled out, and she stays your agent only as long as she serves your ends. Let her pursue her own, and she has stopped being your agent and become a liability. Latitude over the means leaves ownership of the ends exactly where it sat. And latitude is granted, which means it can be revoked, which makes it the reverse of self-law rather than a small dose of it.

The second: computer science has already redefined "agent" to mean a system that senses and acts in an environment, with the principal removed. True, and revealing, because draining the principal out of the words is what lets autonomous slip in looking innocent. The principal left the sentence. It stayed in the work. We still build these systems for our goals, still call them ours, still expect them to do what we meant them to. The vocabulary forgot the relationship. The relationship held.

The bottom line is that the industry has bastardized two words, Agent and Autonomy, and then made things worse by fusing them into a single term that makes no sense to anyone who understands how these systems actually work.

Authority Laundering and the Oxymoron

Call a system a tool, and its maker owns the outcome. Call it autonomous, and the outcome floats free, with no one on the hook. I have called that maneuver "authority laundering": running a human decision through enough machine-sounding vocabulary that the human fingerprints rinse off. Someone chose the goal. Someone set the constraints. Someone shipped it. Autonomy talk takes that chain of choices and dissolves it, so that when the system acts, the action appears to come from nowhere, with no person left to name.

Agent washing is the same move at the level of the product label. Slap "autonomous" on the box and a piece of software starts to look like a free actor rather than a delegated one, which is exactly the impression a vendor wants when the question of liability comes up. An undefined "autonomous agent" turns out to be convenient precisely because an undefined thing is hard to hold responsible. The hype and the vagueness are the same features seen from two angles. One sells the product. The other shields it.

A Cleaner Definition of an AI Agent

An agent is a system that acts on behalf of a principal, toward a goal the principal sets, with latitude over the means. That definition is clean, old, testable, and it describes exactly what every lab is building. It tells you where accountability lives, because it names a principal. It scales from a thermostat to a frontier model without buckling. And it asks for nothing self-contradictory, because it never pretends the thing governs itself.

Between human-in-the-loop carve-outs and various "bounded autonomy" justifications, the industry has chased the hype around something that does not exist. No system is autonomous, because no system understands itself. The belief in these terms survives because it sells more agents, which is a hard thing to do when we have no shared definition of an agent in the first place.

So the next time someone hands you a definition of an AI agent, ask whether they can define it without the word "autonomous."

There are No AI Agents out there, and Our Definitions Prove it

Chris Hood — Wed, 24 Jun 2026 17:14:38 +0000

Let me start by saying, some people might immediately think this is nothing but clickbait. So I want to first establish what this article entails and the goal of writing it.

Analyze the etymology of the word “agent” to see if it aligns with today’s agent marketplace.
Identify various types of definitions, and categorize them for comparison.
Compare those definitions for similarities in word use vs. buzzwords.
Offer an aspirational, future-looking definition of an AI agent.

The Current Marketplace of AI Agents

Walk any trade floor this year, and you will hear the same word a thousand times. Agent. We have agentic platforms, agentic workflows, and agentic enterprises. The word has become a category, a valuation, a promise. And underneath all of it sits an awkward fact the industry would rather skip past: we have never agreed on what an agent is. Ask ten companies for a definition, and you will get ten answers, each one shaped around whatever they are selling.

This is the baseline of the problem. Agents are being positioned as marketing tools and hype vehicles, rather than as a standardized concept. A macro became an agent. A chatbot became an agent. A piece of code that performs an automated task is now an agent. Every major vendor has unlocked the magic of agents, prompting all to see on their home pages. And that was over a year ago.

When an agent expands to cover anything, we have nothing to compare it to. We have agent washing. We have hype. We have the largest marketing campaign in human history to justify the claim that we have code entities that can make your work easier. We’ve always had those opportunities, but now you can give those opportunities names and identities and hire them as employees.

My toaster is now named Toastimus Prime with a cryptographically signed ID.

The Origins of “Agent”

It helps to go back to where the word began. Agent comes from the Latin agere, to act, to drive, to set in motion. But the word never meant simply one who acts. In law and in commerce, where it matured, an agent is one who acts on behalf of someone else.

A principal sets the goal.

The agent carries it out under the granted authority.

And when the agent acts, the responsibility runs back up the chain of command to the principal.

Defined as:

Agent /ˈāj(ə)nt/ (noun)

An agent is a person, entity, or substance authorized or capable of acting on behalf of another to produce a specific effect.

In business, legal, and medicine, we extend this to areas such as:

Real Estate Agent: Helps clients buy, sell, or rent properties.

Travel Agent: Arranges transportation and lodging for clients.
Talent/Sports Agent: Represents actors, athletes, or artists to secure employment and contracts.
Secret Agent: An undercover spy working for an intelligence organization.
Chemical/Biological Agent: A substance or organism that produces a specific physical or chemical change (e.g., a cleansing agent)

The word was never a measure of capability. It described a relationship and a chain of accountability inside that relationship.

Yet within AI, the industry began to shift that accountability.

AI/Software Agent: A computer program designed to act autonomously or automate specific tasks (like gathering data).

Even if we want to argue that this is acting on behalf of another, there is a key contradiction within this definition related to how the agent “acts” towards a task. More on this below.

Current “AI Agent” Definitions

The oldest definition of system agents is an academic version.

Michael Wooldridge and Nicholas Jennings (1995) define an intelligent agent as “a computer system situated in some environment that is capable of flexible, autonomous action to meet its design objectives.”

Russell and Norvig defined a rational agent as "anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators."

Unfortunately, by their standards, a smart thermostat is considered an agent.

The newer definitions are more engineering and marketing versions, generated due to the popularity of LLMs.

IBM defines an AI Agent as:

An artificial intelligence (AI) agent is a system that autonomously performs tasks by designing workflows with available tools.

Anthropic defines an AI Agent as:

An intelligent system that autonomously directs its own processes and tool usage to accomplish complex tasks.

LangChain defines an AI Agent as:

A system that uses an LLM to decide the control flow of an application.

Google defines an AI Agent as:

An intelligent software system capable of autonomously understanding goals, planning multi-step actions, and executing tasks on your behalf.

The Massive Problem with These Definitions

There’s one word that recurs across these definitions and points to the core issue.

The word is autonomous.

We are constantly told that an agent is an autonomous system. I want to argue that this single word does more to corrupt our definition of an agent than any other.

There are two problems with it, and they compound. The first is simple and empirical. No system in production today is autonomous.

Autonomy means a system that originates its own ends, that sets its own goals and governs itself. Every system shipping today runs on goals a human handed it. So if we insist that an agent must be autonomous, we have written a definition that nothing today can satisfy, and we have proven, in our own wording, that no agents exist.

If an agent is autonomous, and no system is autonomous, then we have no agents.

The second problem is deeper and lives within the words and definitions themselves. Autonomy comes from the Greek autos, self, and nomos, law. To be autonomous is to be a law unto yourself.

In contrast, an agent acts under the law of another. Our earlier definition established that. An agent pursues a principal’s goals under a principal’s authority.

There is a Greek word for that condition, too: heteronomy, from heteros, "other." An agent is heteronomous by definition. Serving another’s purpose is the whole of the job. Which means the phrase "autonomous agent" asks for a single thing: to be self-governed and other-governed at the same time.

The more autonomous a system truly became, the less it would serve as anyone’s agent, because it would have started answering to itself.

In all cases, the definitions refer to automation. Autonomy speaks to authorship.

Today’s AI Flavor of the Month

There is one more point of confusion to clear up. We assume an agent must be made of a large language model. That assumption owes more to familiarity than to fact. The language model is the part of modern AI that a person can see, touch, and talk to, so it became the face of the whole agent campaign. Basically, no one knows any different. An LLM vs. an Analytical model is the same in about 90% of the market’s minds.

The planners, control systems, and learning algorithms that run logistics, markets, and games pursue their objectives far more relentlessly than any chatbot. The language model is the interface, the part that talks. It is rarely the part that drives. A definition welded to it inherits its expiration date. Today, we say "agent" and picture a language model only because that's what we happen to have.

But what happens when LLMs go away?

A Stronger Definition for AI Agents

If we wanted to define the agent properly, and to build the thing the word has promised since Rome, we already know the shape it would take. Strip away the marketing, and the requirements fall out cleanly. A real definition includes the clauses that today's versions omit entirely.

Chris Hood's AI Agent Definition

An AI agent is a persistent, identifiable software entity that holds delegated authority to pursue goals on behalf of a principal, acts and transacts with other agents and systems under that authority, and whose actions remain attributable to that principal.

Look closer at that definition. Every clause is a tether. Identity binds the system to a name. Delegation binds it to a grantor. Accountability binds it to a principal. And notice the word that has gone missing. Autonomy. A legitimate agent is defined by what holds it, rather than by how freely it runs. The dream the market keeps selling, a system finally free of all restraint, would fail every clause at once. Which turns the usual pitch on its head. We should want agents that are exquisitely governed rather than gloriously free. In honest terms, autonomy is the failure state. Heteronomy, acting faithfully for another, is the entire definition.

Here is the part that should make us laugh, or wince. None of this is new. Identity, delegated authority, accountability, and bounded discretion. That is the principal-agent relationship, and lawyers have understood it for centuries. We never needed to invent a definition of an agent. We needed to remember the one already sealed inside the word the day we borrowed it.

That’s the clearest sign of hype than anything else.

My definition is aspirational, and I will own that. Almost nothing on the market meets it. But that is the point of a definition worth having. It should describe the thing we are trying to build, and hold the line against everything we are tempted to call by its name too soon.

The AI Agent Identity Landscape: Seven Lanes, 38 Players, One Question

Chris Hood — Tue, 23 Jun 2026 17:00:00 +0000

How a category that barely existed a year ago became one of the most crowded layers in the AI stack.

A year ago, almost no one said the phrase “agent identity.” Today it names one of the most crowded layers in the entire AI stack. I mapped the field and stopped counting at 38 distinct products, protocols, and standards bodies, and the count keeps climbing every month.

Microsoft, AWS, Google, Salesforce, Okta, IBM, CyberArk, and Palo Alto are all in it. A wave of venture-backed startups is in it. The standards bodies have arrived. Every one of them circles the same question: who is this agent, and what is it allowed to do?

Why agent identity became a land rush

The trigger is simple. Agents now call tools, hit APIs, and talk to other agents on their own, and every one of those calls has to authenticate. The identity systems we built over the last twenty years assume a person sits at the keyboard. An agent breaks that assumption. It runs unattended, acts on someone else’s behalf, spins up and disappears in seconds, and can fan out into dozens of copies of itself.

Two forces poured fuel on this. First, the number of non-human identities in the average enterprise already dwarfs the number of humans, and agents bend that curve hard. Second, the new agent protocols, MCP and A2A among them, dragged the question into the open: the moment an agent connects to a server it has never met, someone has to answer for who it is. A category that barely existed became a land rush.

Seven lanes of the agent identity market

The thirty-eight players sort into seven lanes. The lane matters more than the logo, because the lane decides which problem the product actually solves.

Enterprise IAM / IGA. The identity incumbents, extending human governance to agents.

Microsoft Entra Agent ID: agent identities native to Entra ID and Copilot
Okta / Auth0 for AI Agents: verifiable agent IDs with dynamic, Zero-Trust authentication
SailPoint Agent Identity Security: unified IGA governance for agents beside humans
Saviynt Identity Security for AI: a control plane for agents, MCP servers, and tools
Ping Identity Agentic IAM: trusted runtime identities with human oversight
Strata Maverics: orchestrates agent identity across every IdP
Akeyless AI Agent IdP: first-class agent IDs with no embedded secrets
WSO2 Agent ID: registers every agent with verifiable credentials
IBM Agentic AI Identity: scoped delegation traced back to a human
CyberArk Secure AI Agents: privileged access and secrets, extended to agents
Idira (Palo Alto Networks): discovers and governs agents as a new identity class

Cloud & Workload Identity. The hyperscalers and workload-identity players, treating agents as workloads.

AWS Bedrock AgentCore Identity: workload identities and brokered tokens for agents
Salesforce Agentforce / MuleSoft: trusted agent identity propagated at the gateway
Cloudflare Agents / MCP: edge authorization and hosting for agents and MCP
SPIFFE / SPIRE: attested workload identities (SVIDs) for non-human workloads
Aembit: secretless, just-in-time access for agent workloads
HashiCorp Vault: dynamic short-lived credentials for agent workloads

Developer / CIAM Auth. The auth platforms, issuing OAuth and MCP credentials to agents.

Descope Agentic Identity Hub: a dedicated identity provider for agents and MCP servers
Stytch (a Twilio company): an OAuth 2.1 authorization server for agents and MCP
Ory: open-source OAuth 2.1 identity for agents
WorkOS: developer auth for AI agents and MCP servers

Non-Human Identity Security. The security vendors, discovering and governing agents as non-human identities.

Astrix Security: discovers and governs shadow agents and non-human identities
Token Security: machine-first identity security for agents and NHIs
Oasis Security: lifecycle and posture for agent non-human identities

Decentralized / DID. The self-sovereign approaches, making agent identifiers portable across organizations.

Indicio ProvenAI: decentralized IDs and verifiable credentials for agents
ArcBlock: blockchain-anchored DIDs for agents by default
Agent 402: decentralized identity, payments, and discovery for agents
agent-did: an open-source DID and VC toolkit for agents

Protocols & Standards. The wire-level specifications that define how agents identify and talk.

Model Context Protocol (MCP): the tool-connectivity standard that drives agent auth
Google A2A (Agent2Agent): signed Agent Cards for cross-vendor interoperability
Agent Transfer Protocol (AGTP): cryptographic canonical identity, certificates, and Agent Name Service (ANS)
Agent Auth (AAuth): cryptographic, first-class identity per agent
W3C DID + VC: the foundational standard most agent IDs build on
Alibaba Open Agent Auth: cryptographic identity bound to agent operations
AGNTCY (Cisco Outshift): an identity and scope framework for multi-agent systems

Governance & Standards Bodies. The institutions writing the rules everyone else implements.

NIST AI Agent Standards Initiative: a US standards effort for agent identity and security
CoSAI Principles for Agentic IAM: industry principles for human-governed agents
OWASP NHI Top 10 / Agent Name Service (ANS): risk baselines plus a DNS-like agent name service

What the map tells you

Two things, and they pull in opposite directions.

The first is convergence. The entire industry now agrees that agents need a first-class identity of their own, separate from the humans they serve and the apps they run inside. A year ago that was a thesis. Today there are endless options, all vying to be a standard. When incumbents, startups, and regulators arrive at the same layer at the same moment, the layer is real.

The second is fragmentation. Seven lanes carry the same headline and solve different problems beneath it. Enterprise IAM governs the agent lifecycle. Workload-identity players authenticate the running process. CIAM platforms mint and verify tokens. The non-human-identity security vendors find the agents already loose in your environment. Decentralized approaches make the identifier portable across organizations. Protocols define how identity travels on the wire. Standards bodies write the rules everyone else implements. A buyer who picks a “market leader” before naming the lane buys the wrong solution shape.

This is why the marketing blurs together. Read ten of these sites, and you will meet the same sentence ten times: first-class identity for every agent. The slogan is identical; the substance lives in the lane and the layer. So start there. Decide whether your real problem is discovery, issuance, interoperability, or governance, then shop the lane that owns it. The differentiator you care about is rarely the one on the homepage.

The layer the map is missing

Look across all seven lanes, and one fact stands out. In every case, the thing being verified is the identifier. A key. A token. A signed Agent Card. A discovered credential. And it is rapidly becoming table stakes.

The harder questions sit one layer up. What authority does this agent actually carry? Who delegated it, how far does it reach, and what constrains the agent once it starts acting? An identifier confers a name. It says nothing about conduct. A verified agent holding a valid token can still take an action no one intended, and the badge it carries will pass every check along the way.

I have argued elsewhere that an identity layer has no way to certify what an agent is, since the field shares no testable definition of one. This map is the other half of that argument. The industry has built impressive machinery for naming agents and very little for governing them. The open ground is the behavioral layer: self-describing identity paired with discovery, an honest account of what each agent claims to be, and a runtime conscience that judges conduct rather than credentials. That is where the next thirty-eight companies will compete.

So before the next agent identity pitch wins your budget, ask the one question the whole map dances around: once a tool has named the agent, what governs what that agent is allowed to do?

Agent Identity Is Flawed by Design: Why No Vendor Can Prove a Thing Is an Agent

Chris Hood — Mon, 22 Jun 2026 15:47:04 +0000

AWS, Google, Idira, LangChain, AAuth, and AGTP all verify the identifier. None of them verify the category.

Give a toaster a cryptographically signed Agent-ID, register it, and stake a controller behind it. Every check an agent identity product runs will pass, and the toaster will still be a toaster.

That is the whole problem, compressed. The cryptography proves that an identifier exists and that its holder controls the matching key. It says nothing about the kind of thing the identifier names. There is no shared definition of an agent, so there is no test for agentness to run, so the registry accepts whatever submits to it and verifies the resulting identifier on demand. The label changes the label. The thing underneath stays whatever it already was. Vendors sell the label as a transformation. The transformation never happens. Call it what it is: agent washing with a certificate attached.

What Is an AI Agent? Three Definitions That Refuse to Agree

Certification needs something to certify against. The agent industry lacks it. Three working definitions, each from a different organization, show how far apart the field sits.

Russell and Norvig, the classical textbook position: an agent is anything that perceives its environment through sensors and acts on it through actuators. A bimetallic strip qualifies.
LangChain, from Harrison Chase: an agent is a system that uses an LLM to decide the control flow of an application. Chase concedes in the same post that his own line is soft.
Anthropic, from its guidance on building agents: agents are systems where LLMs dynamically direct their own processes and tool usage, holding control over how they accomplish a task.

Three organizations, three boundaries. The first admits a thermostat. The last two demand a language model in the control loop. Andrew Ng and others resolve the tension by calling agentness a spectrum, which is honest and useless for any registry that has to draw a binary admission line. A system that has to answer yes or no has nowhere to look the answer up.

Toaster, Smart Thermostat, Research Agent: Three Things, Three Verdicts

Run three artifacts through those definitions and watch the field fracture.

A basic toaster. A heating element, a timer, a lever. Russell and Norvig: borderline, since a thermostatic toaster senses heat and acts on it. LangChain and Anthropic: a flat rejection, since there is no model and no control flow to speak of. Verdict: mostly out, weakly admitted by the broadest definition alone.

A smart thermostat. It senses temperature and occupancy, keeps several days of memory, decides when to call for heat, and pursues a target inside a comfort band. Russell and Norvig: a clean yes. LangChain and Anthropic: a clean rejection, since the decision loop holds no language model. Verdict: an agent under the classical definition, a non-agent under the vendor definitions, and the same physical box throughout.

An LLM research agent. A language model plans a task, selects tools, reads results, and loops until it reaches an answer. All three definitions: yes. Verdict: admitted everywhere.

Three artifacts, three different sortings. The smart thermostat is the tell. It carries reasoning, memory, decisions, and goals, the exact properties several published definitions require, and most practitioners still refuse to call it an agent. The intuition is firm. The principle under the intuition is missing. And every one of these three can hold the same verified Agent-ID, because the identity layer sits above the disagreement and resolves none of it.

What Agent Identity Actually Verifies

The systems being sold perform a real function. They prove that the holder of an identifier controls the key bound to it. They block impersonation. They catch replay. They produce signed records of who called whom. Useful properties, all of them, and all of them stop at the identifier.

When a name service resolves "Bob" and returns a hit, the lookup proved that a registry entry for Bob exists. It proved nothing about whether Bob is an agent, because the registry holds no operational test for agentness to apply. It accepts a submission, binds an identifier, and verifies that identifier later. That is the entire mechanism. At the HTTP layer, an Agent-ID is a workload credential bound to whatever enrolled. I can mint one this afternoon and pin it to a smart thermostat, and every downstream check will pass.

Security researchers studying these protocols reach the same conclusion in plainer terms. The systems verify who, and they leave what unverified. Capability claims are self-reported. Any entity, an automated script or a human at a keyboard, can stand up an identity asserting full agent capabilities, and the protocol will carry it without complaint.

AAuth, AWS, Google, Idira, LangChain, AGTP: Same Flaw, Different Logos

Survey the field and the pattern holds across every vendor and every protocol.

AWS Bedrock AgentCore Identity implements agent identities as workload identities with a few agent-flavored attributes, issued through Sigv4, OAuth, and API keys. The documentation is candid: the same service covers, in its own words, simple automation scripts and complex multi-agent systems alike. It treats them alike because it has no way to tell them apart.

Google A2A publishes an Agent Card, a JSON document served over HTTPS that declares an agent's capabilities, and as of version one it signs that card with JWS so a peer can confirm the issuing domain. The signature proves the domain. The capabilities inside the card are self-reported, and the protocol's own issue tracker concedes that identity verification of the agent itself is left to external mechanisms. Origin verified. Category asserted.

AAuth, the agent auth protocol from Dick Hardt, gives each agent its own cryptographic identity and requires every request to be signed. Strong primitives. The enrollment step issues an agent token to whatever an agent provider chooses to enroll, and the choice belongs to the provider. The signature proves possession of a key. It says nothing about the kind of workload holding it.

Idira, the Palo Alto Networks platform built on CyberArk, discovers agents across cloud and SaaS, onboards them into an agent registry, and enriches each one with ownership and permission context. Every verb there assumes the discovered thing is already an agent. The registry records what it finds. It runs no test on what the thing actually is.

LangChain owns one of the field's most cited agent definitions and concedes in the same breath that the boundary is soft. Anything built on top of it inherits the softness. Binding identity to a deployment proves the deployment runs. It proves nothing about whether an LLM holds the control flow at runtime.

AGTP, the Agent Transfer Protocol (which I authored), each agent has its own cryptographic identity, associated genesis(certificate) with ownership credentials, and requires every request to be signed with verifiable self-descriptions. It includes ANS (Agent Name Service) and semantic methods to further help recognize capabilities.

However, AGTP carries the same limits as the rest. I can bind an AGTP identifier to a smart thermostat as easily as I can bind anyone else's.

Owning the limit on my own work is the point, and I will return to why it matters.

The common denominator is structural. Each scheme defines an agent its own way, then declines to enforce that definition at the wire. The HTTP exchange validates a key, a token, a signature, a domain. None of them validates the proposition the marketing rests on, that the entity on the other end is an agent. Nothing stops me from generating an identifier on any of these platforms and pinning it to a thermostat named Bob. The platform will verify Bob all day. Bob will keep heating the room.

The Business Risk Hiding Behind the Badge

The gap reads as academic until a buyer signs a contract against it.

A buyer who deploys an agent identity product and assumes the certified entities are agents is making a category mistake and pricing it as assurance. The product certified key possession. The kind of entity behind the key went unexamined. Three consequences follow.

Audit and compliance inherit a false premise. A verified Agent-ID written into an audit trail tells the auditor an agent performed the action. If the entity was a script, a scheduled workflow, or a person driving a card, the record has laundered a contested category claim into evidence. Call it authority laundering: the badge transfers legitimacy the thing never earned.

Governance breaks at the definition. You have no way to govern a population you decline to define. A registry that admits anything inflates the agent count, misroutes controls, and leaves the actual shadow AI exactly as shadowed as before, now wearing a verified badge.

Procurement pays the spread. Buyers are paying for agent verification and receiving identifier infrastructure. The honest line item reads identifier verification. The invoice reads agent identity. The difference is the money.

The Fix: Certify Self-Description, Stop Certifying the Category

The honest path is the one the standards conversation should already be walking. Stop certifying "this is an agent," because the category is too contested for the certificate to carry meaning. Start certifying what the thing declares itself to be, in a signed self-description any counterparty can inspect.

A smart thermostat with a signed origin document that declares it a smart thermostat is a smart thermostat with verifiable identity. The identifier resolves to an accurate description of the thing. A buyer, a regulator, or a peer agent reads the declared properties and decides whether to engage on the evidence in front of them rather than on a category badge bolted to the outside. The cryptographic primitives the industry already built carry straight over. Only the certification claim has to retreat to the layer where it stays honest.

This is where AGTP earns the limit I admitted earlier. Issuing the identifier was never the hard part, and it was never the honest part either. Certifying the self-description, and refusing to certify the category, is the move that survives contact with a contested definition. The toaster gets to be a toaster on the record. The thermostat gets to be a thermostat. The research agent gets to declare itself and stand on the declaration. Identity stops pretending to certify a kind and starts certifying a claim about a kind, which is the only claim the cryptography was ever in a position to back.

So before you buy the badge, put one question to the vendor and refuse to move until the answer is precise: what, exactly, did your verification prove about the thing on the other end of the identifier?

The Substrate Question ARD Leaves Open: How Agentic Resource Discovery Lives on AGTP

Chris Hood — Thu, 18 Jun 2026 04:15:37 +0000

Google, Microsoft, and Hugging Face published the Agentic Resource Discovery specification last week, with a launch partner roster that includes AWS, Cisco, Databricks, GitHub, GoDaddy, Nvidia, Salesforce, and Snowflake. The architecture is clean. The framing is correct. The federated, domain-anchored design is exactly what cross-organizational agent discovery has been missing. ARD is genuine progress, and the team that built it deserves the recognition they are receiving.

It is also a specification that operates entirely above the transport layer. ARD publishes catalogs as JSON files at well-known HTTPS paths. ARD registries index those catalogs and expose REST search interfaces over HTTPS. ARD's trust manifest carries SPIFFE IDs, DIDs, and X.509 certificates as identity references, then explicitly steps out of the way once an agent has the metadata it needs to connect directly using the discovered resource's native protocol.

This is a deliberate architectural choice and a correct one for what ARD is solving. Discovery and runtime are different concerns. Conflating them produces specifications that are harder to adopt and harder to reason about. ARD picks discovery, does it well, and hands off the runtime question to the protocols ARD catalogs: MCP, A2A, OpenAPI, and others. The handoff is the architecture's elegance.

The substrate question that ARD leaves open is what carries those runtime protocols. Today, the answer is HTTP. Every protocol in ARD's catalog ecosystem assumes HTTP as the transport. MCP runs over HTTP. A2A runs over HTTP. OpenAPI is, by definition, HTTP-based. ARD itself is HTTP-native: catalogs are served over HTTPS, registries are HTTP REST APIs, trust manifests use HTTPS attestation URIs. The entire agent infrastructure ecosystem ARD organizes is an HTTP ecosystem.

That is the status quo, and the status quo has costs that are becoming visible in production. The Starlette BadHost CVE disclosed in May affected thousands of agent deployments because HTTP's substrate semantics, virtual hosting, URL reconstruction, path-based middleware, evolved for human web traffic rather than the structural properties agent traffic needs. Agent identity, authority scope, attribution, and the audit trail of who acted on whose behalf are application-layer conventions when they run over HTTP. They are conventions an adversary can omit, forge, or bypass at the seams between the layers HTTP is composed of.

The substrate question is whether agent traffic should continue to inherit HTTP's design assumptions or whether the infrastructure ecosystem should evolve toward a substrate built for the properties agent traffic actually needs. This is a question ARD deliberately leaves open. It is the question the field has to answer next.

Where AGTP Fits in the Picture ARD Drew

The Agent Transfer Protocol is the proposal addressing the substrate question. AGTP defines a dedicated transport for agent traffic on IANA-registered port 4480 with the agtp:// URI scheme. The protocol carries Canonical Agent-ID, Owner-ID, Authority-Scope, and JWS-signed Attribution-Records as wire-level facts on every request and response. The agent's identity, the principal it represents, the scope of authority it claims, and the structural attribution of who acted are foundational to the protocol rather than headers an application might choose to honor.

AGTP and ARD operate at different architectural layers. ARD answers where capabilities live and whether they can be trusted before connection. AGTP carries the connection itself with structural properties at the wire. The two compose because they were designed for different jobs.

Concretely, an agent infrastructure built on AGTP and using ARD for discovery looks like this. An organization publishes its ARD catalog at an AGTP-native location, such as agtp://agents.acme.com/catalog or agtp://{agent-id}/catalog. An AGTP-speaking agent invokes the DISCOVER method to retrieve it:

DISCOVER agtp://agents.acme.com/catalog

The request carries the agent's Agent-ID, Owner-ID, and Authority-Scope at the wire, so the publishing endpoint can apply context-aware policy without reconstructing identity from session state or application-layer headers. The response is the ARD catalog manifest, structurally identical to what an HTTPS fetch would return, with the substrate-level context attached to the act of fetching it.

DISCOVER is broader than catalog retrieval. Invoked against an agent or a service endpoint with no specific resource path, DISCOVER returns whatever the endpoint makes available: skills, tools, APIs, resources, or an ARD catalog if the publisher exposes one. The same method works against an MCP server running on AGTP at agtp://mcp.acme.com/discover, against a capability-listing endpoint at agtp://mcp.acme.com/catalog, or against an agent directly. The substrate handles addressing and identity; the response payload describes what is available. ARD compatibility is one of the things DISCOVER can surface, alongside the other discovery formats an endpoint chooses to expose.

Registry search works the same way. An AGTP-aware ARD registry exposes its search interface at agtp://registry.example.com/search. An agent invoking DISCOVER on that endpoint with an ARD search query in the body receives the same ranked, filtered results an HTTPS POST to /search would produce, with the requesting agent's identity, scope, and attribution carried structurally during the search itself. The registry can return different catalog views to different agent identity classes, apply structural rate limits based on the requester's Owner-ID, and record audit-quality attribution for every discovery interaction.

Once an agent has selected a capability from the discovery layer, runtime connection happens. If the selected endpoint is AGTP-native, the agent invokes AGTP methods directly. If the endpoint speaks MCP or A2A, those application protocols run over the AGTP substrate the same way they currently run over HTTP. Either way, the wire-level identity context travels with every request.

What the Catalog Looks Like

An ARD catalog entry advertising an AGTP-speaking agent looks like this:

{
  "identifier": "urn:ai:acme.com:agent:travel-concierge",
  "displayName": "Travel Concierge",
  "type": "application/agtp-agent+json",
  "url": "agtp://agents.acme.com/travel-concierge",
  "description": "AI-powered travel planning and booking agent.",
  "trustManifest": {
    "identity": "agtp://agents.acme.com/travel-concierge",
    "identityType": "agtp",
    "attestations": [
      {
        "type": "AGTP-CERT",
        "uri": "agtp://agents.acme.com/travel-concierge/cert"
      }
    ]
  }
}

ARD identifies this entry by a media type for AGTP-speaking endpoints (proposed for IANA registration as application/agtp-agent+json in the binding draft). The trust manifest carries an agtp:// identity URI, allowing trust verification through AGTP-CERT alongside any other attestations the publisher provides. The runtime URI is agtp://, signaling the substrate the agent runs on. Every URI in the entry, including the catalog url and the certificate location, points into the AGTP substrate. From ARD's perspective, this is a catalog entry like any other, identified by media type and resolved through the federation model ARD specifies. From AGTP's perspective, this is a complete advertisement of an endpoint reachable over the substrate without any HTTP layer involved.

The same organization can publish other entries advertising MCP servers or A2A agents alongside the AGTP entries. The discovery layer treats them uniformly. The substrate layer is where the architectural choice matters: whether the application protocol runs over HTTP or over AGTP determines what structural properties travel with the runtime connection.

Composition Over Competition

ARD's authors made a deliberate decision to keep the specification artifact-protocol-agnostic. This is a generous architectural choice. It means ARD can grow to include any agent runtime protocol that emerges, including substrate-level protocols like AGTP. The specification is a framework for discovery that places no constraint on what gets discovered.

That choice is what makes the composition with AGTP possible. ARD requires no change to accommodate substrate-level protocols. ARD needs a media type for AGTP-speaking endpoints, a place in the trust manifest for AGTP identity URIs, and an acknowledgment that catalog manifests can be published over substrates beyond HTTPS. Each of these is incremental work that respects ARD's existing architecture.

The IETF draft draft-hood-agtp-ard-00 defines this binding. It proposes a media type for AGTP-speaking endpoints, specifies how AGTP catalogs are published at substrate-native paths, defines the access patterns for substrate-level discovery, and addresses the security considerations that emerge from carrying wire-level identity context during catalog fetches. The binding is small because the composition is clean. ARD answers discovery. AGTP answers transport. The boundary between them is the moment the agent finishes selecting a capability and begins invoking it.

The Conversation This Opens

ARD's launch signals that the industry has moved past the question of whether agent infrastructure needs federated discovery and into the question of how that discovery composes with everything else. The catalog and registry layer is settling. The trust metadata layer is settling. The application-protocol layer above the transport is fragmenting in interesting ways with MCP, A2A, and others.

The substrate question is the one that has yet to have its public conversation. ARD leaves it open because ARD's scope ends at the discovery layer. But every agent specification being published in this space implicitly assumes HTTP as the substrate, and that assumption has costs that are becoming visible.

AGTP is the proposal addressing this layer today. The binding draft shows what the answer looks like when it composes with ARD rather than competing with it. The substrate-level work is starting to appear, and the architectural conversation has to start somewhere.

What ARD built is real. The substrate it runs on is the next decision the field gets to make.

Identiverse Has 100 Vendors Solving Agent Identity at the Wrong Layer

Chris Hood — Wed, 17 Jun 2026 04:50:49 +0000

Identiverse 2026 is happening this week. The agenda is what you would expect from the industry’s flagship identity conference. Keynotes from Okta, Ping Identity, Microsoft, SailPoint, BeyondTrust, CyberArk, ForgeRock (Now Ping Identity), and Saviynt. Booths from every vendor in the IAM space. Sessions on agent identity, agent authorization, agent governance. The word “agent” appears in dozens of talks. Vendors have rebranded their service-principal products as “agent identity platforms.” Conference-floor demos walk through agent provisioning, agent SSO, agent token rotation.

100% of these pitches place agent identity at the application layer. No matter how creative the spin on their identity solution is, each is fundamentally flawed.

Every vendor at Identiverse is solving the same problem the same way: extend an existing application-layer identity primitive to cover agents. OAuth grants get repurposed. Service principals get rebranded. SAML federations get pointed at agent endpoints. The directory model that has run human and workload identity for thirty years is being stretched to cover a new actor type.

There is one proposal in the agent identity space that does the opposite. The Agent Transfer Protocol places agent identity at the transport layer.

One protocol. Free. Open standard. Working code. And the architectural decision that puts identity in transport is the one that disrupts every vendor pitch on the conference floor.

This article is about why those two layers are different, why the choice between them is structural rather than stylistic, and why a single open protocol has the leverage to disrupt a hundred well-funded vendor approaches at once.

Application-layer identity, in plain terms

Application-layer identity means the identity claim travels in the body of the request or in a header the transport has no opinion about. The transport sees bytes. The application parses the bytes, validates the identity claim against whatever issuer it trusts, and decides what to do.

In practice, this looks like OAuth bearer tokens in the Authorization header. The token is a credential the application unpacks. The transport (HTTP, gRPC, whatever) carries the bearer as an opaque payload. The HTTP server has no concept of who is calling. It has a request and a payload. The decision about identity occurs within the application code, after the transport has done its job.

This is the model every vendor at Identiverse is shipping. It works for humans because they authenticate once per session, and the application has time to validate the bearer token on each request. It works for workloads because workloads run inside trust boundaries the operator controls. It is the right answer for the problems the IAM industry built itself around.

It is also the wrong answer for agents, and the wrongness has structural consequences that compound.

When identity lives at the application layer, every intermediary between the client and the server is identity-blind. The load balancer cannot enforce scope. The API gateway cannot validate the agent’s manifest. The audit logger cannot bind a request to a verified agent identity because validation has not yet occurred. The network sees a POST with a bearer header. Every piece of infrastructure between the two endpoints operates on the faith that the application at the far end will validate things correctly.

For human and workload traffic, this is fine. The traffic mostly stays within a single trust boundary. The application at the other end can be trusted because the operator runs it. The compromise surface is bounded by the perimeter.

For agent traffic, the compromise surface is unbounded. Agents cross organizational boundaries. Agents delegate to other agents. Agents act on behalf of principals the receiving organization may have no relationship with. Every intermediary in that path is operating on faith, and faith is the wrong primitive for a regulated commerce surface.

Transport-layer identity, in plain terms

Transport-layer identity means the identity claim is a property of the wire itself. The protocol carries identity headers as mandatory primitives. Every intermediary can read them. Every receiver can verify them before any application code runs.

AGTP is the only open agent protocol that makes this choice. Every AGTP request carries Agent-ID, Owner-ID, and Authority-Scope as wire-level headers. The identity is anchored to a signed Agent Genesis whose 256-bit hash is the Agent-ID. The verification is cryptographic and happens against a public trust path. No third-party token issuer required. No real-time IdP lookup required. No application code required.

The consequences ripple through every component of the agent infrastructure stack.

Scope Enforcement Points (SEPs) at the wire can refuse over-scoped requests before they ever reach the application. The SEP reads the Authority-Scope header, checks it against the agent’s certificate commitment, and returns 455 Scope Violation at line rate. The application stays uninvolved. Misconfigured applications cannot accidentally allow what the protocol forbids.

Governance zones get enforced the same way. The AGTP-Zone-ID header travels with every request. SEPs at zone boundaries refuse cross-zone traffic that policy forbids, returning 457 Zone Violation. Jurisdictional separation moves from a paper concern to a packet-level property.

Attribution-Records are produced as protocol output, signed with the agent’s certificate-bound key, and written to append-only transparency logs aligned with RFC 9162 and SCITT (RFC 9943). The audit trail is structural. The records compose across organizations because the format is shared. No vendor-specific log reconciliation required.

Discovery happens through ANS, the protocol-native agent name service. Queries return signed, ranked results carrying canonical Agent-IDs and trust tiers. Federation preserves provenance across operators. The discovery layer participates in identity management rather than leaking metadata to anyone who asks.

Each of these is a property that exists because identity is at the transport layer. None of them exist when identity lives in an opaque token at the application layer. The architectural decision compounds upward into every higher-level capability.

Six months of data

The Identiverse argument about layers could be left at the structural level. The empirical record makes it harder to ignore.

DevFortress recently published a deep digest covering six months of AI agent credential incidents from December 2025 through June 2026. The pattern across every incident in the digest is the same: a real, usable credential existed in a layer the attacker could reach. The governance and detection tools assume this is inevitable. The digest argues otherwise.

The breach inventory maps onto exactly the three layers the agent stack is being built across.

At the application layer (developer tools, CI/CD, source code, enterprise platforms), Claude Code CVE-2026-21852 had an API key stolen before the trust dialog displayed. Oracle PeopleSoft was breached by ShinyHunters with zero authentication required, exposing 500,000 student records across more than 100 organizations. A no-auth API endpoint is, structurally, a real credential exposed to the network.

At the API layer (OAuth tokens, API keys, credentials in transit, deployment platforms), Salesloft-Drift OAuth tokens survived MFA challenges and remained under attacker control for 5 months. Vercel environment variables sold for two million dollars on BreachForums. 28.6 million secrets were committed to GitHub in 2025 alone. The LiteLLM supply chain breach pulled PyPI credentials through a compromised security scanner. 64% of credentials leaked in 2022 remain active in 2026.

At the tool layer (MCP configs, skill registries, agent runtime, cross-task credential access), the Moltbook breach exposed 1.5 million tokens through CVE-2026-25253. ClawHavoc placed 1,184 malicious skills in agent registries. OX Security documented 14 CVEs attributable to a single root cause. 93% of AI agent projects ship with unscoped API keys. 57% of enterprise identity activity is invisible to IAM tooling.

The common thread is structural. Every credential in every layer was reachable. Every detection product (Snyk, RAMPART, GitGuardian, Qualys) found the credentials after they were committed. Every governance product (Okta, 1Password, CyberArk, Orchid) controlled access to credentials after they existed. Every response product (Arctic Wolf, Palo Alto, CrowdStrike, Salt) acted on breach signals after compromise. The entire market is organized around the assumption that real, reachable credentials are an unavoidable part of the stack.

The application-layer identity model that every Identiverse vendor is selling this week is the model that produced this six-month record. Every product they ship operates on the assumption that the credential exists somewhere in a reachable layer, and that the right thing to do is detect, govern, or respond to its presence after it gets there.

The transport-layer model removes the assumption. When identity is cryptographically derived at the transport layer, anchored to a content-hashed Genesis, and verified per-request against a public trust path, there is no static bearer for an attacker to extract. The 28.6 million secrets in GitHub are 28.6 million bearer credentials. An AGTP-resident agent has no equivalent artifact to leak, because its identity is the hash of its origin document and the signature on its certificate, never a token stored in an environment variable or a config file.

This is what the choice of layer means in practice. Application-layer identity produces the kind of breach inventory the last six months have produced. Transport-layer identity removes the class of credential that those breaches exploited.

The three “layers” are one layer

The DevFortress digest organizes the breach inventory into three layers (application, API, AI agent), and the organization is useful for taxonomic purposes. It is misleading about the architecture.

Structurally, all three layers are application-layer software running on HTTP. The developer tools, CI/CD pipelines, and enterprise platforms in the application-layer bucket are HTTP services. The OAuth flows, API keys in transit, and deployment platforms in the API-layer bucket are HTTP services. The MCP configs, skill registries, and agent runtimes in the AI-agent-layer bucket are HTTP services. MCP itself is an application protocol that runs on top of HTTP. Agent runtimes make HTTP calls. Skill registries serve HTTP endpoints. The “tool layer” is application-layer code wearing new marketing.

This is the part of the conversation that needs to be precise. When somebody refers to “the AI agent layer” as if it is structurally distinct, they are using a category label that has marketing salience but lacks architectural meaning. The category is real (these are products built for the agent ecosystem). The layer they live at is the same layer everything else lives at: above HTTP, in application code, with the transport identity-blind beneath them.

Every breach in the DevFortress digest exploited this fact. The credential was somewhere in the application stack. The transport had no view of it. The intermediaries had no view of it. The detection product found it later, after it had already been used.

AGTP is the only dedicated substrate that breaks this pattern. The protocol runs on port 4480 with mutual TLS. It avoids HTTP entirely. It carries identity, scope, attribution, and zone as wire-level primitives that any AGTP-aware intermediary can read. It is built exclusively for agent traffic, with three structural commitments that no application-layer system can replicate.

Exclusive use for agents. The protocol exists to move agent traffic. The semantics, headers, and verbs are all agent-shaped. The substrate is purpose-built rather than retrofitted.

Known location. Every agent has a canonical address that can be derived from its identity. Discovery is built into the protocol. Agents are findable by capability, by Agent-ID, and by URI form, through a federated name service rather than through vendor marketplaces.

Canonical identity. The Agent-ID is the SHA-256 hash of the signed Genesis document. The identity is the content. No directory, no token, no operator can alter it. There is no bearer credential to leak, because there is no bearer credential.

Every other agent infrastructure proposal on the market is a layer on top of HTTP. AGTP is the only layer below it.

Why the choice is structural

This is the part of the conversation that gets lost in vendor marketing, so it is worth being precise about. The difference between application-layer and transport-layer identity is more than a feature comparison. It is a category difference.

An application-layer identity system can ship better tokens, libraries, SDKs, and dashboards. The vendor can iterate on the experience indefinitely. What the vendor cannot do is move the validation point. The transport stays identity-blind by definition, which means every intermediary in the path stays uninformed about who is calling. No amount of application-layer iteration changes that property.

A transport-layer identity system inverts the situation. The transport carries the identity claim. Every intermediary can read it. The validation point sits at the wire, where the SEP can refuse requests before any application sees them. The vendor experience can still be excellent (libraries, SDKs, dashboards, registry tooling), but the structural property the application-layer model cannot reach is delivered for free.

This is why the choice cannot be papered over with better tooling. A vendor at Identiverse can build a beautiful application-layer agent identity product. It will still leave intermediaries blind. It will still require trust in the application’s correctness for enforcement. It will still produce vendor-specific audit trails that fail to compose across organizations. The structural limits are baked into the layer the vendor chose.

The leverage of putting identity at the transport is that it changes what every higher-level component can do. Load balancers become identity-aware. Gateways become scope-aware. Audit systems become structurally correct. Marketplaces become protocol-native. Delegation becomes cryptographically composable. Each of these is a property the application-layer model can approximate but cannot deliver structurally.

Why one protocol disrupts a hundred vendor pitches

The math is honest. The IAM industry has spent enormous resources on application-layer agent identity. Hundreds of products. Thousands of engineers. Billions of dollars of investment. The combined output of that effort is a category of agent identity that operates at the wrong layer and inherits that layer's structural limits.

The reason one protocol can disrupt a hundred vendor pitches is that it changes the structural property that the vendor pitches all share. Every Identiverse vendor’s agent identity offering is improved by AGTP underneath, because the transport-layer identity makes every higher-level claim more verifiable. Every Identiverse vendor’s agent identity offering is also threatened by AGTP underneath, because the transport-layer identity makes the vendor’s directory the dependent layer rather than the authoritative one.

This is the same shape SMTP took in the mail wars of the 1980s. Proprietary mail systems held mail in their databases. SMTP carried mail as self-contained envelopes any compliant server could read. The proprietary systems retreated to being interfaces over the open substrate. The substrate won.

The IAM vendors at Identiverse can either build on the AGTP substrate (extending their offerings to compose with transport-layer identity) or compete with it (insisting that application-layer identity is sufficient). The first option keeps them relevant. The second option positions them for the SMTP exit, where the substrate handles the structural work, and the vendor’s product serves as an interface over the substrate.

The vendors that figure this out first will dominate the post-AGTP IAM market. The vendors that miss it will spend the second half of the decade explaining why their application-layer products keep failing audits, failing to meet logging requirements, and producing forensic gaps that the transport-layer alternative closes by design.

What an enterprise should be asking on the conference floor

If you are walking the Identiverse floor this week, the question that separates real agent identity from rebranded service-principal products is structural. It has one form.

“Does your agent identity ride on the wire, or in the application?”

If the answer is “in the application,” you are looking at a product that will leave every intermediary blind, require application-layer policy enforcement, produce vendor-specific audit trails, and fail to compose with agents at other organizations without bilateral integration. This is the entire category at Identiverse this year.

If the answer is “on the wire,” you are looking at AGTP, or something derived from AGTP. There is currently one such answer in the agent infrastructure conversation. The protocol is open. The reference implementation is Python. The registry is live. The port (4480) is registered with IANA. The URI scheme (agtp://) is reserved. The companion drafts cover trust, identifiers, logging, discovery, composition, session, agent certificates, and merchant identity. The work is happening at the IETF on the independent submission stream.

The question is whether to add a transport-layer foundation to whatever IAM stack you are already running, or whether to keep buying application-layer products that will be obsolete the moment the substrate question gets resolved.

The substrate question always gets resolved. SMTP. TLS. DNS. Certificate Transparency. Every infrastructure-level fight in networking history has ended the same way: the open substrate that handles the structural job becomes the foundation, and the vendor products built on top of it become interfaces over the substrate. The agent identity fight will end the same way.

The vendors selling application-layer agent identity at Identiverse 2026 are selling products that will need to compose with AGTP within three years. The buyers walking the floor have a choice. Buy the application-layer product and add the substrate underneath later. Or recognize that the substrate is the structural layer and architect around it from the start.

The substrate is open. The vendors will catch up or fade. Transport now carries identity, regardless of whether the application layer acknowledges it.

That is what one universal free protocol does to a hundred vendor pitches.

Read the spec: https://agtp.io

Get started: https://github.com/nomoticai/agtp

Configure MCP on AGTP: https://github.com/nomoticai/agtp-mcp

AGTP: A Home for Your Agents

Chris Hood — Mon, 15 Jun 2026 16:09:45 +0000

You have built agents. They are in production. Some of them are doing important work. You are mostly sure of that.

What you are less sure of: how many agents you actually have running. Where they live on the network. Which ones are still doing their jobs and which ones drifted out of scope months ago. Who they are talking to when they reach out to other systems. Whether the audit trail you would need if a regulator came asking actually exists in a form somebody could read.

This is the quiet state of most enterprise agent deployments today. You shipped the agents. The platform team built the orchestration. Engineering wired up the integrations. And then everybody moved on, because the deployments worked well enough that the operational gaps were easy to ignore.

The gaps are getting harder to ignore. Compliance teams are starting to ask questions. Risk officers are starting to ask questions. Auditors are starting to ask questions. The agents you deployed two quarters ago are now doing work that touches customers, money, and regulated data, and the answers you have when somebody asks “what is this agent and what is it allowed to do” are answers you assembled in the moment from logs scattered across half a dozen systems.

This is the problem the Agent Transfer Protocol was built to solve. Your agents need a home.

Now they have one.

agtp://your-agent
agtp://agent-id
agtp://mcp.domain.tld/your-agent
agtp://agents.domain.tld/agent-id

Identity is the front door, never the whole building

Most of the agent identity conversation today stops at the front door. Give the agent a credential. Issue it a service account. Drop it in a directory. The vendor pitch is that this is “agent identity,” and it is, in the same way that a name tag is identity.

What it leaves out is everything else that home means.

A home is where you live, more than what you are called. A home has an address that lets people find you. A home has rules that constrain what happens inside. A home keeps records of who has come and gone. A home has neighbors who can vouch for you. A home has a registry entry so the city knows you exist. A home has a history that survives the people who happen to be living there at any given moment.

When you say “your agents need identity,” the marketing answer is a credential. When you say “your agents need a home,” the answer has to be the entire substrate that makes the agent legible, reachable, governable, and accountable to anyone who needs to interact with it.

AGTP is that substrate.

What a home gives an agent

An AGTP-resident agent has every one of the properties the home metaphor implies, carried as protocol primitives rather than as vendor product features.

A birth certificate. Every AGTP agent has a signed Agent Genesis document, issued at activation by a governance platform, recording the agent’s origin, owner, archetype, and verification path. The Genesis is permanent. You can produce it years later to prove the agent is who it claims to be. The Genesis document makes the agent a legitimate resident.

A canonical address. The Agent-ID is a 256-bit cryptographic hash of the Genesis. It is the agent’s permanent identifier, derived from the agent itself rather than assigned by an operator. It survives moves between hosts, transitions between owners, and changes between registrars. The same agent always has the same address.

A current state. The Manifest is a separately resolvable document that declares what the agent currently is: capabilities, supported methods, accepted scopes, lifecycle state, governance zone, and trust tier. The Manifest can be refreshed independently of the Genesis as the agent’s operational profile evolves. Visitors check the Manifest to know what the agent can do right now.

A registry entry. AGTP registries list every agent that has been activated through a governance platform. The registry is queryable, federated across operators, and signed. Anyone who needs to know whether an agent is current and in good standing can find out, the way anyone who needs to know whether a business is legitimately registered can check the corporate filings.

A way for people to find you. The Agent Name Service (ANS) is the DNS-equivalent for agents. A capability query returns ranked, signed results listing agents that match. Your agents become discoverable across organizations through a protocol-native discovery layer, without bilateral integration with every vendor’s proprietary marketplace.

Rules of the house. Authority-Scope travels with every request the agent sends. The scope declares what the agent is permitted to do, drawn from a reserved registry of governance-relevant domains. AGTP servers MUST parse it on every request and refuse anything that exceeds the declaration. Your agent cannot accidentally do something outside its authority, because the protocol enforces at the wire.

A history kept by the house. Every consequential interaction produces a signed Attribution-Record bound to the agent’s identity, the request hash, the response status, and the acting principal. The records flow into append-only transparency logs aligned with RFC 9162 and SCITT (RFC 9943). When somebody asks what an agent did six months ago, the answer is a query against a verifiable log rather than a forensic reconstruction across vendor systems.

A neighborhood. Governance zones (zone:eu-gdpr, zone:us-healthcare, zone:retail-verified) place the agent in a jurisdictional and policy context. Cross-zone traffic that policy forbids is refused at the protocol layer. Your agents live in neighborhoods you choose, with the boundaries enforced by infrastructure rather than by hope.

A reputation among the neighbors. Behavioral trust scores are computed from the attribution log and surfaced in ANS responses. The longer the agent operates cleanly, the higher its score. The score is verifiable rather than vendor-proprietary. Other agents picking counterparties at runtime see your agent’s standing the way somebody looking at a contractor sees their reviews.

A front door for visitors. Elemen, the first agent browser for AGTP, renders any AGTP agent’s identity as a clean visual profile that a human can read in seconds. Identity, goals, skills, permissions, credentials. Compliance officers, regulators, counterparties, and curious users can visit your agent the way they visit a website. The agent stops being a backend implementation detail and becomes a citizen people can recognize.

Each of these is a property that the agent receives as an AGTP resident. None of them are properties an agent gets by being given a credential in a directory.

What you get when your agents have a home

A real inventory. You can answer “how many agents do we have” because every agent is registered, every registration is signed, and the registry is queryable. The number is current as of 60 seconds ago because revoked agents drop from the index that quickly.

A real map. You can answer “where are my agents and what are they doing” because every agent has a canonical address, every interaction produces attribution, and the manifest specifies what the agent is currently doing. Operational visibility is structural rather than reconstructed.

A real audit trail. When the regulator asks what happened, you query AGTP-LOG for the time window and the Owner-ID and pull a complete, signed history. The records compose across organizations because the format is shared. You stop being the bottleneck for your own audit.

Real scope enforcement. The agent cannot drift beyond what it was authorized to do, because the wire refuses to carry over-scoped requests. Application bugs cannot cause out-of-policy behavior, because the protocol catches over-scope before the application runs.

Real cross-organization workflows. Your agent can delegate to a counterparty at another company without bilateral integration, because the trust composition happens at the protocol layer. Federated discovery, signed delegation chains, attribution that names both sides. Cross-org commerce stops being a quarter of engineering work per partnership.

Real survivability. Your agent’s identity persists when the host changes, when ownership transitions, when the model retrains, when the registrar consolidates, when the regulatory regime shifts. The Genesis stays signed. The Agent-ID stays the same. The records stay verifiable. Your decade-long obligations stay tractable.

Real public visibility. Through Elemen, your agent gets a face. People can find it, understand it, and verify it without your engineering team in the loop. The trust your organization earns flows through your agents because their identities are legible.

This is what “home” means for an agent. The substrate makes the agent a citizen of an ecosystem, beyond just a process running on a host you happen to operate.

Why this matters now

The agent infrastructure being built today is the infrastructure that will be running when the EU AI Act enters full enforcement, when NIST AI RMF reporting becomes routine, when ISO/IEC 42001 audits start showing up in procurement cycles. The agents you deploy in 2026 will still be running in 2031, and the audit questions you answer about them then will be the same ones you have to answer with whatever substrate they were deployed on.

If the substrate is “we wrote some code and dropped it in a container,” the audit answers will be reconstructions from incomplete logs. If the substrate is AGTP, the audit answers will be queries against signed attribution that the protocol produced as a side effect of normal operation.

The cost of switching substrates later compounds quickly. The cost of starting on the right substrate is small. AGTP runs on port 4480 with mutual TLS. The Python reference implementation is open source. The first agent registries are live. Elemen renders any registered agent in a browsable identity card. The MCP-on-AGTP gateway lets your existing MCP servers compose with AGTP without any changes to MCP code. Every piece you need to bring your agents home exists today.

Bring your agents home

You have built your agents. AGTP is where they can live.

A signed Genesis at activation. A canonical Agent-ID derived from cryptographic content rather than assigned by an operator. A Manifest declaring what the agent currently is. A registry entry that survives the registrar. ANS that makes the agent findable across organizations. Authority-Scope that the wire enforces. Attribution-Records that compose into verifiable audit. Governance zones that place the agent in a jurisdictional context. Behavioral trust scores that earn reputation over time. Elemen that lets humans visit the agent like a website.

The substrate is open source. The protocol is an IETF Internet-Draft family on the independent submission stream. The port is reserved with IANA. The first agents are registered. Lauren is the first to have an address.

Your agents already exist. They are running somewhere in your infrastructure right now. The question is whether they have a home or are squatting in someone else’s data center, waiting for the next audit to discover them.

AGTP is the home. Bring your agents there.

What is an AI Agent? (It’s not a workload)

Chris Hood — Sun, 14 Jun 2026 18:10:37 +0000

Ask ten technology leaders what an AI agent is, and you will get ten answers. Ask the same ten in six months, and the answers will have changed. The word has become the most contested term in the AI infrastructure conversation, and the lack of definitional clarity is compounding. Vendors sell against it. Standards bodies write specs around it. Boards approve budgets for it. Compliance teams write policies governing it. All of this is happening before the industry has settled on what the thing actually is.

The reason the question matters is that the definition is about to be baked into infrastructure that will run for a decade. The IETF is publishing drafts. The IAM industry is shipping products. The Kubernetes community is writing CRDs. Each of these encodes a definition. If the definitions are wrong, the systems built on top of them inherit the wrongness, and unwinding takes years.

There is a precise structural distinction that cuts through the noise. Workloads handle the known. Agents handle the unknown. The known set of tasks, fixed at deployment, executable by a process bounded in scope and time, is a workload. The unknown set of tasks, emerging at runtime, dynamically shaped by reasoning and negotiation, is the territory of an agent. Everything else in the definitional fight (the protocol primitives, the identity model, the governance envelope, the orchestration shape) follows from that single distinction.

This piece walks three lenses through that distinction. The past, where most things called agents are workloads in disguise. The present, where the real architecture for handling the unknown is starting to emerge. And the future, where the unknown expands, and the agent substrate must grow with it. The known/unknown line runs through all three.

Definition: An AI agent is a governed substrate with persistent identity, independent of any particular task, that compiles unknown work into structured task fabrics, orchestrates those fabrics across resources and counterparties, and executes them under continuous governance.

The past, and still today: macros wearing a costume

A macro is a workload. It executes a fixed sequence of steps, possibly with conditional branches, possibly with parameters. The task set is known when the macro is written. The execution is deterministic in the relevant sense: given the same input, the macro does the same thing. This is the textbook case of a workload, and the workload-identity primitives the industry has spent ten years refining (SVIDs, mTLS, deployment-bound credentials) handle it correctly.

A macro that gets called an “agent” is still a macro. Adding a model call in the middle of the sequence, sprinkling natural language descriptions across the steps, or putting a chat interface on the front changes the marketing but leaves the underlying artifact intact. The task set is still known at the time of deployment. The execution is still bounded by what the developer wrote. The branching is still hand-coded. Everything that made the artifact a workload before the agent label was applied remains true after.

This is what gets called agent washing, and it deserves to be named honestly. By my reading of the market, more than half (maybe 75%) of what is sold as an “AI agent” today is scripted automation with a model in the prompt loop. The seller has a strong incentive to use the agent label because it commands a premium. The buyer has little incentive to push back because they rarely see the implementation. The result is a product category that calls itself one thing while structurally being another.

A recent conversation with a leadership team at a major professional services firm illustrated the pattern. The firm had launched an “AI agent practice.” Several engagements were underway. The pitch decks were ambitious. When we drilled into what the agents actually did, the answer kept coming back the same way: they followed a fixed sequence of steps, branching on a handful of conditions, and calling out to a model for text generation at specific points. The task set was known.

The honest assessment is that yes, these are workloads. They handle the known. The IETF’s WIMSE working group, looking at this market and concluding that “agents are workloads,” is accurately describing this segment. The mistake is generalizing from here to all agents. The known case is real, and the workload-identity tools handle it. The unknown case is what the rest of the conversation is about, and the tools that handle the known break the moment the task set stops being knowable in advance.

The present: when the workload definition breaks

Strip away the agent washing market and look at what real agent systems are starting to do, and the known/unknown line becomes the structural boundary that nothing else explains.

A real agent receives a goal at runtime that the deployment never anticipated. It reasons about what tasks accomplish that goal. The task set was unknown a moment ago and now has to be discovered, structured, and committed to. Halfway through executing the discovered plan, the agent encounters conditions that change which tasks are needed. A counterparty becomes unavailable. A delegation opens up. A user changes their mind. The task set at minute thirty differs from the task set at minute zero, and the entity making decisions about what to add or remove is the agent itself.

This is the precise moment when the workload definition breaks down. A workload, by definition, has a bounded set of tasks knowable at deployment time. The agent’s task set is unknowable at deployment time because it depends on goals that arrive at runtime, reasoning that occurs at runtime, and conditions that evolve at runtime. The dimension that workload identity has never had to represent (the dynamic, adaptable, runtime-shaped task set) is the dimension that defines an agent.

The Compiler takes an unknown workload (a goal, a partial specification, a request that has yet to be decomposed) and turns it into a structured, addressable representation. It canonicalizes intent. It decomposes goals into atomic tasks. It surfaces ambiguity explicitly. It produces governance metadata about which constraints apply. The output is a Task Fabric: a verifiable, portable artifact that captures the currently best understanding of the unknown and is ready to be revised when new information arrives.

The Orchestrator takes the Task Fabric and turns it into an executable plan against currently available resources. It resolves dependencies. It delegates across agents through protocol primitives. It negotiates capabilities at runtime when available resources do not match the requested work. It inserts governance checkpoints. It can rewrite the fabric when execution returns signals about what is actually happening on the ground.

The Executor walks the plan and causes state change. It invokes tools and connectors. It manages local state and rollback. It emits attribution. It respects intervention hooks from the governance layer. It feeds results back into the Compiler and Orchestrator so the loop can adapt when the unknown reveals more of itself.

These three phases are inseparable from each other. None of them is the agent by itself. The agent is the substrate that runs the loop, with identity that exists independently of any particular workload the loop happens to be processing.

This is the framing that distinguishes a real agent from a glorified macro. A macro has the task set written into its code: the known case. A real agent has a task set that emerges from the loop: the unknown case. A macro’s identity is its deployment context, because the deployment is the entity. A real agent’s identity is its origin record, because the agent persists across whatever workloads it ends up processing. A macro produces audit logs as a side effect of running. A real agent produces signed attribution as a structural output, because attribution is the only way to make sense of an unknown task set after the fact.

The known/unknown line is what determines which set of primitives applies. Known task sets: workload identity, deployment-bound credentials, application-layer audit. Unknown task sets: persistent canonical identity, wire-level authority enforcement, cryptographic attribution. The two architectures are different, and trying to handle the unknown case with known-case tooling is the source of most failure modes that show up when real agents are deployed at scale.

The trajectory: more unknown, more substrate

The third lens is where the known/unknown line bends sharply away from the workload definition and stays there.

Agents are becoming more independent. They are running longer. They are taking on broader task surfaces. They are delegating to each other without continuous human supervision of each delegation. They operate across organizational boundaries, regulatory regimes, and model generations. The trajectory is unmistakable, and every step along it expands the unknown the agent must handle.

This is where the language has to be careful, because “independent” is often used as a synonym for “autonomous,” and the two differ in ways that matter.

An agent with independence of execution can handle more unknown without escalating to a human at every step. It can decompose new goals. It can negotiate with counterparties. It can adapt to drift. It can compose plans from emergent sub-goals. The value of an agent grows with how much unknown it can handle correctly, which is why the trajectory is toward more independence.

Agents are NOT autonomous. But by marketing definition "An autonomous agent," in the strong sense the word sometimes implies, would handle the unknown without any governance envelope at all. No accountable owner. No declared scope. No audit trail. No counterparty verification. This is the version of agent autonomy that doomer discourse worries about, and that careful infrastructure work should make structurally impossible.

These are different things. The trajectory points toward more independence, never toward autonomy from accountability. The protocol primitives have to make the distinction precise.

What this means for the substrate is counterintuitive at first and structurally obvious on reflection: as the agent handles more unknowns, the underlying governance has to become more rigorous, never looser. The Genesis record becomes more important, because it is the accountability anchor that survives the agent’s increasing operational latitude. The Owner-ID becomes more important, because someone has to remain accountable as the scope of unknown work expands. The Authority-Scope on every request becomes more important, because the scope is what keeps independence from sliding into unconstrained behavior. The Attribution-Record becomes more important because the audit trail is what lets a regulator, three years from now, reconstruct what an agent did with the unknown it was handed.

The known/unknown distinction is what makes all of this load-bearing. Workload primitives can govern the known case because the bounds are stated up front. They cannot govern the unknown case, because there is nothing to bound at deployment time. The agent substrate has to perform bounding at runtime, on every request, against an unknown that may have just appeared. The governance envelope has to be carried by the protocol, because there is no application-layer place to put it that survives the dynamism.

There is one more property of the trajectory worth naming. Agents are becoming ephemeral in execution while remaining persistent as entities. An agent might spawn thousands of ephemeral execution instances over its lifetime, each one short-lived, each one carrying a slice of the agent’s identity and scope. The persistent entity in the registry stays the same across all of those instances. The instances come and go. The entity remains. This is what makes the Genesis-derived canonical identity necessary: only a content-derived, infrastructure-independent identifier can keep the persistent entity stable across an arbitrary number of ephemeral instances handling an arbitrarily large, unknown number.

The future agent is independent enough to handle more unknown than today’s agent, ephemeral in execution against a persistent entity, and more deeply governed at the protocol layer than any application can deliver. None of those properties survive the workload definition. All of them follow directly from taking the unknown seriously.

The definition, in one sentence

An AI agent is a governed substrate with persistent identity, independent of any particular task, that compiles unknown work into structured task fabrics, orchestrates those fabrics across resources and counterparties, and executes them under continuous governance.

A workload is one part of that definition (the work the substrate happens to be doing right now, captured as a Task Fabric, in any given moment of the loop). The substrate that compiles, orchestrates, executes, and persists is the agent. The work it handles is unknown at deployment and known by the time it executes. The known/unknown line is exactly where the workload definition ends, and the agent definition begins.

Treating an agent as a workload throws away everything that makes it agentic. The dynamic task set. The runtime reasoning. The cross-organizational delegation. The emergent goal decomposition. The continuous governance envelope. The ephemeral execution against a persistent entity. Each of these exists because the agent is built to handle the unknown. None of them exist in the workload case because it has nothing unknown to handle.

The agent-washing market keeps producing macros called agents (workloads that handle the known) and asking the standards community to treat them as the canonical case. The real agent infrastructure is being built for something else (substrates handling the unknown), and the choice the next two years of standards work has to make is which case to design around.

AGTP is built for the unknown case. The compile-orchestrate-execute substrate runs inside it. The Genesis carries the persistent identity. The Authority-Scope constrains independence at the wire. The Attribution-Record produces the audit trail. The federation lets agents cross organizational boundaries. The trust tier carries credentialing depth that survives time.

This is what an AI agent is. A substrate built for the unknown, with everything that follows from that commitment. The macros wearing the costume are something else. The workloads being labeled as agents are something else again. The category that deserves the word is the one being built now, on the substrates the agent ecosystem will depend on for a decade.

Known versus unknown. Workload versus agent. The line is structural, and once you see it, everything else about the infrastructure conversation falls into place.

The Industry’s Mess with IAM for Agents

Chris Hood — Fri, 12 Jun 2026 15:32:32 +0000

Every identity vendor in the IAM space ships the same architecture. A directory holds the records. Each entity gets an identifier assigned by the directory. Authentication produces a token. Authorization is policy attached to the identifier. Audit is application-layer logging that references the identifier. This architecture has run human identity for 30 years and workload identity for 10 years. It is what every IAM vendor is now retrofitting for agents.

The retrofit will fail, and the reasons are structural.

The IAM industry built its tools for a problem shape that fails to match agents. Humans show up at workstations with phones in their pockets. Workloads run inside organizational perimeters with metadata services nearby. Agents do something different. They cross organizational boundaries. They outlive their operators. They act on behalf of multiple principals at once. They negotiate contracts at runtime. They get retrained, transferred, federated, and audited across regulatory regimes. The directory-and-token model was never built to handle any of this, and asking it now produces the same kind of failure mode that HTTP produces when stretched into agent transport. The substrate is wrong, and the fixes that get layered on top create new attack surfaces faster than they close the old ones.

AGTP is a different architecture. The identifier is content-derived rather than assigned. The identity is a structured set of artifacts rather than a row in a database. The protocol itself enforces it rather than leaving it to applications. This article walks through what those choices mean in practice, why they matter specifically for agents, and why no IAM vendor has shipped them.

An ID is the smallest part of identity

The first thing to be honest about is that “identity” in the IAM industry has become a synonym for “identifier.” The product is an ID and a way to authenticate that someone is allowed to use it. The Okta directory holds your user record. The Entra ID directory holds your principal. The SailPoint platform manages who has access to what. Every conversation about identity collapses into a conversation about IDs.

For humans and workloads, this collapse is mostly fine. The human’s identity outside the workplace is somebody else’s problem. The workload’s identity is short-lived and operator-defined. The directory’s view is sufficient for the directory’s purpose.

For agents, the collapse breaks. An agent’s identity must have sufficient structure to answer questions the IAM industry has never asked.

What is the agent’s origin? Who issued it into existence and signed off on its being permitted to operate? The Genesis answers this. It is a signed document recording the agent’s archetype, the registrar that issued it, the owner accountable for it, the activation timestamp, and the verification path that backs the registration.

What is the agent’s current operational state? The Manifest answers this. It is a separately resolvable document declaring the agent’s capabilities, methods, scope acceptance, policies, and current lifecycle state. The Manifest can be refreshed independently of the Genesis as the agent’s operational profile evolves.

What has the agent done? The Attribution Log answers this. Every consequential interaction produces a signed Attribution-Record that names the agent, the principal who authorized the action, the counterparty, and the result. The records flow into append-only transparency logs aligned with RFC 9162 and SCITT (RFC 9943).

What has been verified about the agent? The Trust Tier answers this. Tier 1 means full cryptographic verification through one of three documented paths. Tier 2 means organizational assertion. Tier 3 means experimental. The tier travels with the Manifest and is visible to every counterparty.

How has the agent behaved? The Behavioral Trust Score answers this. It is computed from the Attribution Log activity, signed by ANS operators, and surfaced in discovery responses. The score is no vendor’s proprietary risk number. It is a verifiable summary of the agent’s recorded behavior across the network.

Where did the agent come from? The Genesis Lineage answers this. As the agent’s underlying model gets retrained, its owner changes, or its governance zone evolves, the lineage chain records each transition. The lineage is the provenance document that lets a regulator three years from now reconstruct what happened.

What can the agent currently do? The Authority-Scope, declared for every request and bound to the Agent-ID through certificate commitments, answers this question. The scope is more than a directory entry. It is a wire-level claim the protocol enforces before the application runs.

Eight different artifacts, each answering a different question. The Agent-ID is the handle into all of them. It is the smallest part of identity rather than the whole. Treating the ID as identity, as the IAM industry has been doing for thirty years, leaves the other seven parts in vendor-proprietary formats or nowhere at all.

Why the ID has to be canonical

The IAM industry assigns IDs. The directory operator decides what your user object’s ID is, what its GUID looks like, what its DN string contains. The ID is whatever the directory says it is. Change directories, and the ID changes. Lose the directory, and the ID is gone. Trust the directory, and the ID is trustworthy. Distrust the directory, and the ID is nothing.

For humans, this is acceptable because humans have other forms of identity that outlive any single directory. Social security numbers, passports, biometrics. The IAM directory is one view of the human, and the human persists across many such views.

For agents, this is unacceptable. The directory’s view IS the agent. Lose the directory, lose the agent. Change operator policy, change the agent’s identity. The directory is a single point of failure for the agent’s existence.

AGTP takes the opposite approach. The Agent-ID is the SHA-256 hash of the canonical bytes of the Agent Genesis document. The identifier exists because the document exists. Nobody assigns it. Nobody can change it without changing the document. Anyone with a copy of the Genesis can verify the identifier by hashing.

This is the same primitive that Bitcoin uses for addresses, that Git uses for commits, that IPFS uses for content. Content-derived identifiers have specific properties that assigned identifiers lack.

Self-certifying. Verification works by hashing. The identifier and the content are inseparable. If somebody hands you an Agent-ID and a Genesis, you can verify the binding in milliseconds without contacting any third party.

Tamper-evident. Any change to the Genesis produces a different Agent-ID. Forgery requires either solving the hash function (computationally infeasible) or producing a new Genesis (which is a new agent).

Portable. The identifier travels with the document. It has no binding to a database, a host, or a domain. Moving an agent across infrastructures preserves its identifier exactly.

Operator-independent. No issuing authority can revoke or reassign an Agent-ID. The identifier exists for as long as the Genesis exists. Registrars federate to preserve the Genesis attestations, but no single registrar holds the identifier in trust.

Globally unique without coordination. 256 bits of cryptographic hash gives collision resistance well beyond any plausible population of agents. Two different Genesis documents will never produce the same Agent-ID, regardless of who issued them or where they live.

Surveillance-resistant. The identifier reveals nothing about the issuing authority. It is just bytes. An observer who sees an Agent-ID on the wire learns nothing about which registrar produced it, which jurisdiction it was registered in, or who owns it. All of that information lives in the Genesis, available only to parties the agent chooses to share it with.

These are properties the IAM industry has never needed for humans or workloads, and properties no major IAM vendor ships for agents.

What AGTP does that nobody else does

Okta has agent support that wraps an OAuth client into a service principal. Microsoft Entra has agent identity that surfaces in the Azure portal as a managed identity. Auth0 offers machine-to-machine grants that can be repurposed as agent credentials. Each one extends a primitive that was built for a different actor type. None of them ships the architecture agents actually need.

Six specific things AGTP does that no major IAM platform does:

Content-derived canonical identifiers. The Agent-ID is a hash of the Genesis. No vendor in the IAM space ships content-derived agent identifiers. Everyone assigns IDs from a directory.

Wire-level identity headers. Agent-ID, Owner-ID, and Authority-Scope are mandatory headers on every AGTP request. The protocol enforces verification before the application runs. No IAM vendor pushes identity into the transport. They keep it at the application layer where the directory can stay in charge.

Three separate principals. Agent-ID, Owner-ID, and acting principal serve as three distinct identifiers that answer three different questions: what acted, who is responsible, and who authorized. The IAM industry collapses these into a single identity record, destroying the accountability chain a regulator actually needs.

Signed Attribution-Records to transparency logs. Audit is a protocol output rather than an application convention. The records are structured the same way across every implementation and flow into logs whose integrity is cryptographically protected. The IAM industry’s audit story is per-vendor logging that requires bilateral integration to compose across organizations.

Trust tiers with explicit verification paths. Tier 1 means full cryptographic verification through DNS-anchored, log-anchored, or hybrid trust paths. The tier is verifiable by anyone with access to the public trust roots. The IAM industry has no equivalent. Verification depth is whatever the vendor says it is.

Federated, scope-enforced, signed discovery. ANS makes agents findable across organizations through a protocol-native discovery layer. Results are signed, ranked, scope-enforced, and federated while preserving provenance. The IAM industry’s discovery story is a vendor-controlled marketplace accessed through proprietary APIs, with no cross-vendor compatibility.

Protocol-composable identity. The Agent-ID, Owner-ID, and Authority-Scope ride alongside existing standards instead of replacing them. An AGTP identity passes straight through MCP, OAuth, and A2A without being re-minted at each boundary, so the same verifiable principal survives every hop of an agent's call chain. The IAM industry treats each protocol as its own island, issuing a fresh token and a fresh identity at every handoff, which severs the accountability chain at exactly the seams where cross-system attribution matters most.

Each of these is a deliberate architectural commitment that the IAM industry would have to rebuild its products to deliver. The retrofit approach (extend OAuth, extend service principals, extend the directory) cannot reach any of them, because the substrate is wrong.

The structural difference

The IAM industry treats identity as a directory problem. Their core competency is running directories, attaching policies to directory entries, and producing tokens that reference those entries. Everything they build assumes the directory is the source of truth.

AGTP treats identity as a protocol problem. The core competency is moving signed artifacts between agents in a way that allows each recipient to independently verify the artifacts. The protocol is the source of truth, and any directory built on top of it is an index to verifiable claims that exist outside the directory.

This is the same kind of structural difference that distinguished SMTP from proprietary mail systems in the early days of networking. The proprietary systems held mail in their own databases. SMTP carried mail as self-contained envelopes that any compliant server could read. The proprietary systems lost. The architecture that put the content on the wire won.

The same pattern will play out for agent identity. The IAM industry holds the records in its directories. AGTP carries the content as self-contained, content-addressed, signed artifacts. Vendors that adopt the AGTP substrate can continue to run directories as indexes into the verifiable substrate. Vendors that store their identities exclusively in proprietary directories are running the proprietary-mail-system playbook in a network where the protocol wins.

The substrate question gets answered the same way every time. The substrate that makes the content verifiable without the directory’s permission becomes the substrate. AGTP made that choice for agents. The rest of the industry is still answering with directories.

What this means for the field

Agent identity is being built right now. The choices being made today will compound over the next decade, much as the choice between SMTP and proprietary mail compounded over the eighties and nineties. Vendors building on directory primitives will produce systems that work inside their products and fragment at every boundary. Vendors building on canonical identifiers and protocol-level verification will produce systems that compose across operators, jurisdictions, and timescales.

The IAM industry is large, well-funded, and committed to the directory model. The directory model worked for humans. It worked for workloads. It will continue to work for those use cases. For agents, the directory is the wrong shape, and no amount of retrofitting changes that.

The Agent-ID must be canonical because the entity must outlive the directory. The Genesis, Manifest, Attribution Log, Trust Tier, Behavioral Score, and Lineage must all be first-class because agent identity is a richer artifact than user identity. The protocol must carry the verification because the application layer cannot do so consistently across organizations.

These are structural commitments. AGTP made them. The IAM industry will catch up or be replaced, just as every infrastructure layer does when a new substrate proves out.