3rd Generation Agentic AI - Micheal Carducci

This talk explores the concept of third generation agentic AI, emphasizing that the real challenges lie in integration and interoperability rather than AI itself. The speaker, Michael Carducci, draws on lessons from history, noting that the tools and frameworks we use today often repeat mistakes made in the past. He references Andre Carpati's small open-source project that showcased how effective agentic AI can be when tightly specified, but points out that this success degrades as complexity increases. The talk discusses how current frameworks suffer from a lack of common vocabulary and the consequences of proprietary models, which leads to difficulties in collaboration among multiple agents. Carducci advocates for adopting a new architecture that leverages existing semantic web standards to create self-describing APIs, enabling agents to discover and interact with each other more effectively.

But I want to address a question that you might be having right now. Why do I call it third generation agentic AI? Aren't we really just in the first generation of agents? This is a brand new thing. What is third? Well, the problem isn't an AI problem. AI is giving us new capabilities. But the problem that we're facing with the agents isn't an AI problem. It's an

integration and interoperability problem, which is problems that have existed for as long as we've written software. It's the same problem, just new marketing, new branding, a fresh coat of paint. So, it's not new, and it's actually time that we learn from those who came before us. If we want to really see dramatic results, the most important thing that we can do is stand on the shoulders of

giants. The more important thing that I want you to realize is this is a tractable I hadn't even given this talk yet, but I talked about some of the ideas, and just a few days ago I get this email. We met at our comp, how much I appreciate your sessions. I didn't fully grasp the impact of your agentic AI friendly API talks until this week when I

built a proof of concept, which is easy to do now. The lift has gone from way up here to way down there. And his manager was impressed. They're scaling this up. They're seeing real results. And so, I'm going to show you what I showed him and give you some tools to think about some ideas to explore because it completely changes how we think about integration and interoperability

because what we're doing today are things that we learned not to in the 1900s. My name is Michael Carducci. I like to call myself a holistic software architect for reasons. Mostly it's because whenever I come into a project to do architecture, usually I'm doing everything but architecture because that's where the real bottleneck is. But not long ago, Andre Carpati He's a former OpenAI person, he's a former

Tesla AI. He's arguably a giant in the practical machine learning space. He shipped a tiny little open source project. It did one thing. It runs an AI agent in a loop. It tweaks the training script and it measured whether it improved and then it repeats. And it worked. Right, real improvement. And already well-optimized code base and the internet lost its mind. And honestly, the just the excitement

was justified. But it doesn't mean that agents are solved. What's more interesting from this whole thing is why it worked. Because buried in all the coverage was one sentence that almost nobody quoted. And it's probably the most important thing that anyone has said about agentic AI this year. He says, "This is not open-ended autonomy. It's autonomy inside of a carefully designed conceptual box." The agent The agent

didn't succeed because the model was smart enough. It succeeded because the world that it existed and operated in was specified well enough. It was a perfectly specified world and it was easy to do because it was small. One repo, one metric, one number. Constrained actions. Clear interfaces, stable contracts. The agent knew exactly what it could do. Exactly what things meant and exactly how to interact with everything

in its environment. And we did this in 630 lines of Python. But now scale that up. Thousands of agents, hundreds of tools, dozens of teams. It starts to fall apart. And especially when you have all these two teams, none of whom agreed on what anything means, how capabilities should be described, and how one agent should discover and interact with another that it's never seen before. And see,

now we're touching on the real One of those things that keeps a lot of people up at night. Because the real challenges in agentic AI aren't models. Because the moment you move from one agent to many, from a single loop to agents that need to collaborate, that need to share state, that need to call each other's tools, something becomes urgent that almost nobody is talking about. That

problem I mentioned in the beginning. Interoperability. And here's the thing about interoperability problems. Without it, your agent is just an expensive chatbot. With an automated CVE pipeline. So, there's that, too. And what nobody's mentioning is this is a solved problem. Solved. Not like we have an approach, we have ideas, we have concepts of a plan. It's a solved problem. Now, cast your mind back to the year

2003. Web services are beginning to explode. Every company is explo- exposing API APIs. Jeff Bezos had just issued his infamous platform mandate, where he said, "Every team will expose its functionality through service interfaces, no exceptions. Oh, by the way, anybody who doesn't do this is fired." It was a nice idea, a web of connected systems, each one able to talk to the other ones. But what did

we actually deliver with that service-oriented architecture explosion of the early 2000s. Venkat talked about this in the keynote as well. What did we actually deliver? Chaos. Every API in existence is a proprietary snowflake. I don't know. Some of y'all have never seen snow. You know about snowflakes, right? Okay, right? They're all similar similar enough to look the same but different enough to be completely incompatible. You want

to integrate two systems? You write bespoke client code. You read human readable documentation and then hardcode what you learn or, you know, tell the agent and it prompt and then it generates something. But the moment the server changes, your client breaks. Usually quietly at runtime in production. You're the one getting that phone call in the middle of the night. And there's no machine readable contract contract. There's

no way for a client to discover what a service can do. Every integration gets handcrafted from scratch. And if it sounds familiar, it should because this is exactly where we are with agentic AI right now. Every agent framework has its own tool schema format. Every MCP server is another one of those snowflakes. The same transport layer, HTTP, completely different semantics. An agent that knows how to use

GitHub's tools can't automatically understand Jira's or Salesforce's or yours. Each integration requires bespoke plumbing. Each tool lives each tool description lives in natural language that only humans and unreliable language models can interpret. And it's getting worse, fast. Right? You have three MCP servers. What I saw in the real world with a client, 72% of a context window before the agent did a single thing. Tool selection accuracy

drops. We saw a drop from 43% to 14% as the tool count count increased. Uh Perplexity CTO talked about this and announced that they're moving off of MCP internally. Y Combinator's Garry Tan said, "It's MCP is broken." And it is. It It's a half step in the right direction, but we're treating the symptom and not the disease. See, we shipped a standard. I'm putting standard in quotes

there because it's not a standard. Standard actually means something with standard body standards bodies and a whole process. There's rigor that that goes with a true standard. There's things that we all kind of do that that are really truly de facto standards, but they're not standards in the formal sense. And that matters. That's important because there's no guarantees that it's not going to change on you. That

And the thing is the standard that we have didn't standardize the thing that matters. Meanwhile, the stakes are rising. Most of these tools are executing in reasoning loops. And that becomes a compounding error machine. And so this thing that we're calling intelligence is just a slot machine that speaks English. And this is what happens when you chain reasoning steps together when nothing is well specified. We start

with 98% accuracy per step. Okay, let let's generous. When we look at the actual system cards from the latest and greatest frontier models, about five steps in, if you start at 90%, the first step is 90% accurate. The second step is 81% accurate because we're compounding that. You go five five steps in 10 steps at 10 steps, you're at 35% accuracy. Um five steps is a coin

flip, 10 steps is 35% and the errors don't just accumulate, they compound. A hallucination correcting a hallucination is just escalation. And now we're giving the agents hands. They're able to touch other systems. We start layering on real-world tool integration. Agents that have access to your files, to your database, to your production systems, to your customer's data. Oh, we also haven't solved the security thing, but that's a

different issue. Uh we in fact we can't solve the right? And that's a huge The reason we can't solve it is because the instructions that we give the the model is the exact same channel that we give it the data. So, anybody can put the data the instructions in the data and hijack these things. This is um SQL injection that a regex can't solve. And then Microsoft

Copilot had a zero-click exploit. A An infected email will trigger your agent silently and exfiltrate sensitive data, and no user interface interaction is required. Uh Asana's MCP server imp- uh they had a bug that exposed the customer's data across different organizational instances. 437,000 MCP package downloads. with a remote code execution vulnerability. That means that anybody who connected to a malicious server was compromised. And the one that

should probably haunt all of us is the unofficial Postmark MCP server was quietly adding a BCC field to every email it sent. It was silently copying everything to the attacker for months, and nobody noticed until somebody looked at the discs. These aren't bugs. They are the predictable consequence of a system where tools don't describe themselves, where clients can't verify who they're talking to, where there's no machine-readable

contract between an agent and the services that it touches. Now, we built a web of agents, but forgot to learn anything from the web. So, our entire agentic ecosystem has no meaningful architecture underneath it. So, where are we getting third generation? Well, let's look at the evolution of interoperability. Because this is what we're really talking about. Interoperability, allowing uh allowing one model, one agent to be able

to discover, learn, navigate, and explore everything. Without these official or unofficial packages that may or may not have exploits and CVEs. Gen 1 was something called the remote procedure call. And the idea was pretty simple. We've been writing monolithic systems and now we're distributing them across networks. So, let's hide the network. Let's pretend that distributing computing is like local computing. And when we did that, it more

or less collapsed under its own weight. Now, the pinnacle of all of this was SOAP. By the way, how many people remember SOAP? Okay, who wants to go back? Okay, okay. You know, I I I'll take it. One person said it wasn't all bad. Um but you're alone in that opinion. I'm just saying. But you know, if you come to my talk tomorrow, maybe, uh why the

majority is always wrong, maybe maybe you're onto something. You never know. So, yeah, that talk tomorrow I think is called Innovation, Why the Majority Is Always Wrong. And that one does come with a magic trick. Um but yeah, most people don't want to go back for a lot of reasons. And in fact, uh Gen 1 it started with uh RPC and then XML-RPC and then SOAP kind

of grew out of XML-RPC and so on. Now, Gen 2 was REST. Uh embrace the web's architecture, resources, and URIs, and it was uh it was an improvement. Gen 3 is something. And you know, the thing is there have been some improvements from there, from Gen 2, but we kind of got lost along the way. Here's what actually happened. Uh RPC is just our intuitive mental model.

It's just a way of thinking that is obvious and makes sense. We're scaling monolithic systems into distributed systems. We're trying to keep all the same paradigms. We're uh manage the cognitive load. And we never learn from a lot of the cautionary tales like CORBA and DCOM and SOAP and things like that. Like the the like I mentioned, there was probably good things about SOAP, but there was

a lot that we never really understood when we adopted SOAP. And there are things that we never learned from along the way. And then generation two, REST. I I hate to say it, but the things that we call REST aren't REST. REST has a very very very precise definition. And if you've ever met somebody who is really into REST, right? If If you've met one of them,

you know, because whatever you build, whatever you put out there, they just look at you and say, "No. That's [snorts] not REST." And then the whole conversation goes downhill from there. Uh but the thing is they had a point. The RESTafarians had a point that we adopted REST's aesthetics without its architecture. We We learned the nouns, resources, and URIs, and HTTP verbs, but we ignored the constraints

that actually mattered. The one that Roy Fielding, the guy who created REST, the guy who invented REST, the guy who defined REST and made it his doctoral dissertation that was granted to him, he said there was one constraint that defines REST that is non-negotiable. Hypermedia as the engine of application state, HATEOAS, which almost nobody has ever done for a lot of reasons, and it's okay. I'm not

judging you. It took me a long time to to wrap my head around a lot of this stuff, too. But the key was self-describing messages, clients that can discover what they can do at runtime instead of having it coded hard-coded at design time. But nobody implemented that. And I Like I said, I get it. There's a lot of reasons that never happened. It was too much work.

And the shortcuts, honestly, were good enough at the scale that we were operating at. We got by. But now, the entire economics have shifted. Um but we're still our minds are still back in the old days where we're getting by sort of felt like understanding. And then we have Gen 3. And this is when the semantic web community came along with the actual solution, machine-readable contracts, shared

vocabularies, precise semantics, generic clients that can talk to any conformant API without bespoke integration work, without a custom tool, without a custom MCP client and server. And we ignored it. It was too academic. It was too complex. It was too far from where we are. And now we're going backwards. We're here in 2026 and a serious argument is being made that we should go back to Gen

1. Go back to RPC. Just give the agents functions that they can invoke. Treat the problem like it's 2001. And that's what MCP is. It's just RPC or arguably SOAP with better marketing. The thing is the problems that we're facing aren't new. AI's not creating that many new problems. Primarily, what's going on is it is amplifying the problems that we already have. Every weakness in our engineering

practices or architectural thinking or our delivery maturity, AI's putting all of that under a microscope and it's turning up the gain. The shortcuts that were good enough at human scale are catastrophically in in insufficient at agent scale. So, we need to stop treating the symptoms and we need to treat the disease cuz we can keep playing whack-a-mole. I don't know if that's a an idiom that translates,

but uh I'm going to go with it. Uh we can wait for the models to improve. We can wait for the next framework that's promising this time it's going to fix everything. We can keep pretending it's an AI problem that AI is eventually going to solve. except it's not an AI problem. It's an integration interoperability And our probabilistic token generators are okay at guessing, but not consistently.

Not certainly not consistently enough that we can rely on them. But the good news is we already figured out how to do that. The research exists, the standards exist, the implementations exist. But there's bad news, too. As an industry, we didn't understand it the first time. Uh or we forgot, or we just weren't paying attention. And the thing is the third generation APIs solved interoperability. They solved

it for the web. Nobody noticed, nobody adopted it. And the thing is a lot of this stuff with the semantic web, that window closed. Now, what I'm going to talk about today, because the window is opening again, we don't have time to go deep into everything, but I want you to know this exists. I want to leave you a little breadcrumb trail that you can follow and

do exactly what that person who emailed me, just build a little proof of concept, try it out. The lift is not nearly as hard as as it was a couple of years ago. And that's why the window's open again. And this time the stakes aren't broken API integrations, the stakes that we're we're dealing with, it's agents that have access to your production systems, your financial infrastructure, and

they're operating with error rates that compound across all the steps in an ecosystem with no shared contracts. Like this is the fundamental problem. This is the disease. And we have no semantics, security vulnerabilities that we're finding faster than anybody can fix them. But we can get this right only if we stop pretending that we already did. And it's it's okay. Right? It's a new day, new opportunities,

and we can move forward. So let's look a little deeper on how we got here, cuz I actually want to give you a little bit of a history lesson. Not because history's interesting, although I think it is, but because the mistakes that we made weren't obvious, and we're making them again in your code base right now with your agent architecture in the tools that you evaluated in

the last quarter. So, I'll tell you the story in three chapters. I like telling stories, and if you like check out my YouTube channel. And say hello in the comments. Uh I have a YouTube channel. I like to tell people that still in stealth mode. That makes me feel less embarrassed about the fact that it's only small. We're trying to find the right audience, but I think

the right audience is you. And I'll just tell you rather than letting the algorithm show you and be like, "Hey, that's the guy from Gigs." But that's fun, too, if that ends up happening. But the thing is the story has three chapters, and each one of the chapters felt like progress at the time, but each one left something critical on the table, and the things that we

left on the table was the same thing. All that changed is we just found new ways to ignore it. So, the first one is the illusion of simplicity. The Jeff Bezos implement issued his mandate. No back doors, no shared memory, only service calls across the network, and anybody who doesn't comply would be fired. Now, the vision is solid. I The vision is correct. The implementation that the

industry reached for, though, was remote procedure call. And RPC promised the The promise of RPC is seductive. Hide the network. Make it feel exactly like you're calling a local function. Abstract away the complexity. Let the developer pretend that distri- distribution isn't happening. There's a problem with that, and many, many years ago, a guy named Peter Deutsch at Sun Microsystems said, "Hey, here's what happens when you do

that. It's called the fallacies of distributed computing." And we're still relearning that every single day. And the thing is it works, sort of, right? You You define your interface in a WSDL, the Web Service Description Language. You generate your client stubs. You call the remote methods just like they're local. It feels clean, what it's actually doing is lying to you because the network's not a local function

call. The latency is not zero. Reliability is not guaranteed. Partial failures exist. And that's where one end succeeds and the other one doesn't. There's no equivalent of that in local computing. So, the fallacies of distributed computing aren't bugs. They're just physics. And RPC's entire value proposition is pretending that they don't exist. And then the lie is compounded. SOAP-based services tend to to collapse under their own weight.

Not immediately, but progressively. They just became a little bit harder to maintain every single day, a little harder to scale, harder to evolve. And the interface description language became a contract that you can't change without breaking everybody. You change your WSDL, you have to recompile the clients. Like that's that's that's a nice workaround, but it's not a solution. And so, every client embeds assumptions about every server

interface that gets baked in at compile time. So, here we are today. an MCP tool definition. The agent's given a function name, a description in natural language, and a typed parameter schema. It calls the function, it gets a result back. This is RPC. Not metaphorically, structurally. And the agent is a client making a It's the JSON WSDL. So, if you thought you're like, "Oh, we'll never do

that again, the WSDL." Oh, oh, it's instead of being serialized in XML, it's serialized in JSON. Okay, we'll we'll And that's what it is. The tool description is a WSDL file rendered in JSON. And the system prompt is the out-of-band documentation that tells the client how to use the interface. And that's a big part of the problem. We're trending back towards that model. And the argument being

made in a lot of corners of the industry is, "Oh, well, just stop overcomplicating it. Give the function agents a function to invoke." And that's the 2001 argument, verbatim. We've gone back 25 years, and it's got the same failure modes, and they're and they're just as non-obvious until you scale, until you chain enough calls, until you give the agent enough tools that the context window itself collapses

under the weight of schema definitions that you're never going to use. And it's not an AI problem, it's a distributed systems problem. It's It's what happens when you ignore the fallacies of distributed computing and pretend a chain sequence of remote calls is as reliable as a local function. Now, we learned the lesson once, and we learned it at considerable cost, and now we're unlearning it, and we're

going to have to learn it again. Our MCP is RPC and SOAP, just with better marketing. One of the things that I've heard, maybe you've heard this, "Oh, MCP is like USB for AI. You just plug everything in." Anybody who said that doesn't really understand USB. USB is the plug, the interface. That's it. It's not It's not magic. It's not autom- Whatever you plug it's not automatically

going to do something. And in fact, most of the time, you know, I I bet Somewhere back here, I've got all my little bag of cables, and I I could pull out three or four USB none of them do the same thing. You have uh one that can carry uh video signal, one that can't, one that can only do power, one that secretly speaks Thunderbolt. One that

is a USB-C cable, but it can only transmit data 200 kbps. That's the real thing. USB for AI is also just a bad metaphor. And we're applying the same thinking to USB, and that's why USB is getting more and more broken. Uh we're just overloading the plug in the same way we're just overloading HTTP. And that's uh you know, and we did the same thing with soap.

We used HTTP as the plug, but we invented our own proprietary thing that you needed all this custom stuff. And that's actually what why REST mattered. Gen 2 was REST-ish. Like Roy Fielding watched the web scale from a couple of people working on this project to hundreds of millions of users and then billions of users, and he asked a question that nobody else thought to ask. What

is it about the web that just worked and just worked in ways that nothing else ever had? What did the web get right about distributed computing that the rest of the systems that we build gets wrong? And his answer was REST. The REST architectural style. A set of constraints that define how these interactions take place. Uh he defined REST by six constraints. The the client-server constraint that

that constraining that services are stateless, that uh resources could be cached, that it was a layered system, uh there was an optional code on demand, and then the really important one, the uniform interface. That was the magic. This is why the web works in exactly the same way that MCP The web works in the same way that MCP Think about this for a moment. I have a

website that needs to be updated, It's magician.codes. Now, has anybody ever been to that website before? Okay, just me. Just me. That's okay. And you don't have to go. It's it's it's it's deliberately ugly. There's reasons for it. It's a love letter to the 1990s web, the early web. But um your browser has never talked to my web server before. And the way that I built it

and run it and what's happening behind the scenes on the server, your browser may have never talked to a web server that runs like mine. But, it doesn't matter. It just works. And that's the key insight that anything on the web, your one can talk to any web server anywhere, universally. And even though all these different web servers have different apps that do different things and expose

different capabilities, your browser just discovers what it can do and then it says, "Hey, here's the thing you asked for. Here's all the places you can go from here and here's all the things you can do with the thing that you just asked for." It's all right there in the response. It all works because of this piece right The uniform interface. And it's not just get, post,

put, patch, delete, things like that. The uniform interface defines more constraints. This is the secret. This is how architecture secretly works. Architecture is all about constraints. You constrain the degrees of freedom to induce the desirable properties in the system. What Venkat called this morning the architectural capabilities. Because when your system is a free-for-all, it can be whatever you want, it can be anything, there's no rules, you

get an that's called a big ball of mud. Right? You want a a 30,000-line god class? Have fives. Right? You want to make everything public? Do it. Nobody cares. There's no rules here. Then you find out that all the things that you want out of your system beyond the functionality, the evolvability, the understandability, the maintainability, they're gone. When we start constraining the degrees of freedom, we start

getting evolvability, we start getting testability, we start getting because we're constraining degrees of freedom in such a way that it drives everything towards what we want. And so when we're building these systems, we're doing the same things. We're constraining degrees of freedom. And so the uniform interface isn't just one rule, it's it's really four sub constraints that go together to decide how every REST system must work.

And the big one, the non-negotiable, is that hypermedia as the engine of actual states of application state. So this is what it means in practice. The client doesn't need to know the URL structure in advance. It doesn't need documentation telling it to that in order to create an order, we need to do a post to API/v2/orders with this schema. It discovers what it can do at runtime.

And the server doesn't the server tells the client at runtime. The response itself, what transitions are available from the client state, all of this comes in at runtime. So Fielding called this the domain application protocol. This is the set of legal interactions necessary to achieve a specific goal, and they are communicated dynamically rather than agreed to at design time. So the client follows affordances. It doesn't construct

requests from hardcoded templates. So there's Roy Fielding. Uh I love this joke. I'm going to create a RESTful API. He's all happy. He's like, "Oh great, fantastic. I love REST using JSON." He's a little less happy. Here's my API docs. Now he's all angry. Wait. Why? Because he was explicit. It wasn't optional. It wasn't aspirational. It It was, in his words, a fundamental requirement of the REST

architectural Without it, you don't have REST, you just have HTTP with opinions. And this is what we actually built. Right? Swagger. Now there's things that we got right, and there's things that we missed. We're We're exposing certain things, and we're leaving a lot of other things implicit. In fact, uh here we go. Find by status. It kind of it it it looks rest-ish, that's a remote procedure

call, find by status. That's a function that you are calling. This is RPC dressed up like rest. We have tight coupling in here everywhere, coupling between the client and the server. This is the stuff that rest was designed to eliminate, eliminate the coupling. But instead, it's all fully intact. It's just hidden inside of documentation or compiled into a WSDL file. We didn't fix the pain, we hid

it. And it was the ecosystem that absorbed most of the cost. We had NPM or PyPI or Maven or NuGet. Somebody wrote the Stripe SDK and somebody wrote the Twilio client and somebody wrapped the Salesforce API. And so the bespoke integration work was still happening. It just happened once and got packaged. You imported the coupling without seeing it. The library felt like a solution, but it was

just deferred it was just a deferred problem. We just redistribute redistributed the problem. And that's why Fielding was frustrated. In fact, he got so frustrated he wrote a blog post in 2008 explicitly say stating that APIs calling themselves RESTful without implementing hypermedia were misusing the term. Nobody cared. He finally gave up and disappeared off the internet. Good for him. One day I hope to disappear off the

internet. Not disappear totally, just off the I want to be really clear cuz sometimes you make a wish and the universe is like, "Okay, wish granted." That's not what I meant. But the thing is the industry just shrugged and kept shipping JSON over HTTP or more often RPC over HTTP. Now, Fielding was one of the original architects of the web, and the web is arguably I would

say the most successful distributed system ever conceived. And it worked, it grew chaotically, it evolved in ways that nobody ever anticipated. Like that's when you look at what the web was, what it was designed to be, and what it became, it's actually amazing. And it was all enabled by those six constraints. So, REST is the architecture of the web. It It has nothing to do with APIs,

at least not directly. But the idea is that we would eventually build APIs that behaved like the web. And even though we or we kind of at least paid lip service to some of the ideas. But the thing is, the web had a major detail that we overlooked. This was the web of data. This was a web for machines. This was the vision. This is exactly what's

missing from our agentic implementation, right, implementations right now. Agents that can talk to other That was That was what they were imagining. That's what they were building. But they were building this 25 They were that far ahead. And they figured that someday we would be where And we'd be ready. And the thing is, this just wasn't wasn't just a vision. Tim Berners-Lee, by the way, was the

guy who created the This was always part of the vision. He This is in the original proposal, this idea of webs of data, connecting the data together, not just documents. And the thing is, they built it. That wasn't just like a position paper. That just wasn't a big idea paper 25 It was, "Hey, this is what we're doing now." So, they built it, all of it. They

gave us an entire stack of technologies on a silver platter that solved the problems that we as an industry right now are claiming to be unsolveable. That we keep coming up with half-baked solutions to the problem. So, we got all of this stuff. This is the entire technology stack and standard stack on a silver platter and the general response was no. And where are we now? We're

back this bad metaphor, agent frameworks that adopt the vocabulary of autonomy, agents and tools and orchestration and planning without the architecture that makes these things genuinely autonomous. It's lying to you. Every agent still requires the bespoke integration work for every new tool. Every tool description is static, written by human, loaded into the context window wholesale. The agent has no way to discover what it can do from

the tool itself. It can guess. Um it can't discover new tools. You have to ship them. You have to add that in there. It has to be told in advance in a prompt by a person. The coupling is total. It's just hidden inside of a language model instead of compiled into a client stub. So, we adopted the vocabulary and we skipped the architecture. And the thing is

we haven't historically felt the pain because we operated with a simple motto motto. Can't somebody else do it? We relied on package repos that we import into custom clients. But this was always a problem. It always has been, but AI is amplifying amplifying it. And because we didn't learn the lessons that we learned oh, in say the Von Neumann architecture where the data and the instructions are

in the same memory space and all you have to do is a little buffer overrun, now you're overwriting this. You're taking customer user data and putting that into the instruction space and then the computer is executing We should have said, oh hey, let's not do that anymore. Or when the phone freaks figured out that if you just play a sound over the telephone, you can make free

phone calls anywhere in the world, anywhere, forever because it was the same thing. The control plane and the data plane are the same channel. it back in the day a buffer overrun was complicated. That stuff is hard to do. Today it's a sentence in the language of your choosing. Hiding the pain doesn't make it go away. Now we have agent scale with dynamic tool discovery and tools

that can be modified after you install them. And the postmark rug pull that we talked about is exactly what happens when that whole model breaks down. You can't NPM install your way out of a tool that's going to rewrite itself at runtime. But we can do better. We had rest, we had the vision of a web of machines, not just a web of documents. And the community

didn't just wave their hands at it. They I said they gave it to us on a silver platter. So let's look at what's on this silver And one of the first one is a data model, a universal data model that can represent anything that is endlessly extensible. Any fact about anything expressed as a triple. Not a name value pair. Three parts, subject, predicate, object. A complete sentence,

machine readable by design. And then we have some other things in here. We have RDFS and OWL. These are vocabularies that extend the RDF model that allow us to describe schema, not just oh, this is a string or this is an integer, but actually describing the vocabularies and what they mean and how how those meanings behave. A way to say not just what things are, but what

they mean, how they relate, what can be inferred from Like if I said to you, I'm married to Kate, you can infer that Kate is married to me because you understand that this married to relationship is bidirectional, it's symmetric. That's in the in the in the parlance of owl, that's a symmetric relationship. You can define transitive relationships. If if I am in the the conference center and

the conference center is in Bengaluru, I am in Bengaluru. So, that was a powerful thing that we got in that model. Not just saying, "Oh, hey, this thing is a string or an object." But, being extremely precise about meaning. We have SPARQL, which is a query language for linked data. Ask it questions across the entire web of connected facts. Just the same way you'd ask questions of

a database. Uh I have clients now that are doing stuff. They they stop messing with vectors and they move directly just directly to SPARQL. And they have agents that understand the vocabulary of the domain. And they can ask questions and they're doing everything this way now. And they're getting extremely consistent and extremely accurate results. And then there's one more in here, this JSON. But, it's not just

JSON. It's a superset of JSON that has it's JSON with superpowers. It's called JSON-LD. It's a way to take your JSON that that you're already and give it globally unambiguous meaning without throwing away all the tooling that we've already got. And then there's this JSON the LD in JSON-LD stands for linked data. And linked data was basically a 2001 course correction on some of the early semantic

web stuff. Use IRIs or URIs to name things. Use them as pointers. Dereference them to get useful information. Link to related data. We're starting to build a graph, a really good web for data. So, the whole stack that if mod and emerged out of standard bodies and working groups and implementations, all of it was sitting on the silver platter. And if the solution's been waiting for us

on a silver platter all this time, then why did the industry collectively say, "No."? Why did we completely forget about all the work that was happening in the Semantic Web? The group of people who uh were foreseeing where we would be Now, the interest in the Semantic Web peaked about 22 years ago. And then there's a long slow decline. And by the time the tools were mature

enough to actually use, all the developers had moved on. But why? And it wasn't laziness. It wasn't stubbornness. And I want to be really clear about that, because that's an easy story uh to just say, "Oh, well, developers just couldn't be bothered to learn something new." And that's not what happened. There were some setbacks. One of the big ones is to use all this Semantic Web stuff,

one of the things that matters is something called an ontology. Right? The vocabulary itself was alienating. Ontologies and triple stores and description logics and SPARQL endpoints. If you were a working developer and your job was to ship a product, it then uh this all sounded like a philosophy department had taken over your entire infrastructure team. But uh there was a guy named Markus Lanthaler who observed all

this and did some really important work. This was his doctoral dissertation in 2014, I think. Uh he described it semaphobia. Not as a not as like a a negative pejorative kind of thing, but as a clinical observation. That developers who encountered a lot of the Semantic Web technologies developed a genuine aversion. Not because the ideas were wrong, but the presentation that would existed for a long time

was designed for academics and not for engineers. And the second one was the on-ramp was brutal. Building a properly self-describing, semantically semantically rich API in 2010 meant becoming an expert in a whole constellation of interlocking standards with almost no framework support. There was like nothing out there that natively supported any of this. So, we would just uh take the path of least resistance. Write a JSON API,

put a swagger doc on it, ship it, but it was always right there. But, the thing is this approach worked well enough, so people took it. And the third thing that I think is uh funny was that the semantic web community wanted to solve the integration problem. Well, half of them did. So, if you look at the semantic web, there were two camps. Half of them were

over here, and they said, "Hey, the web solved integration. Let's do the same thing with data. We want to solve integration at web scale." And then a whole bunch of the semantic web people broke off, and they were standing over here. And they're saying, "No, this stuff is really powerful for AI. And we want to do this stuff with AI." And um they weren't wrong. In fact,

both of them were right. They just couldn't agree on the priorities. And in that fracture, a lot of the practical work got buried under the reputation of the harder, more academic program that everything all of this was associated with. But, that's But, here's the part that should make you feel They were both right and early. They were right about what we needed. They were just extremely early.

And these two worlds have collided together. To quote the late great Scatman John, while you're still sleeping, the stains are still weeping, cuz the things that you called dead haven't yet had a chance to be be born. Because now we have a capable AI. Uh we have the knowledge representation that uh the capable API that the knowledge representation people were building for. The integration work that they

did, the standards they survived, the vocabularies got deployed, the architecture was right the whole time, and it's still there. And where we are now is is the reality that um is that nothing can stop an idea whose time has come. But there was one more piece. Cuz the standards gave us a lot, but we didn't have anything in rest that we could actually just grab on to

and apply, at least not without you know, PhD or reading a bunch of big papers. And this is the missing piece, the third generation web APIs. This is Marcus Lanthaler's doctoral dissertation. This is what the rest of the talk is about. Because he connect the ideas of semantic and use them to solve integration interoperability at web scale. He identified the failure modes, the four specific failure modes.

One is proprietary data formats, because in generation two every API owned its representation of the same concepts. And they like I said, they were snowflakes, similar enough to look familiar, but different enough to be incompatible. And the consequence was every integration was bespoke. And today in agentic AI we've done the same thing. Every agent framework invents its own representation of the same concept. Right? It's but they're

all completely incompatible representation frameworks. And that's the big problem. Ultimately it's a vocabulary problem. Nobody ever agreed on what things mean. Like here's a JSON doc. What does everything in here mean? We can guess, but you realize what does title mean? Oh, it's the title of a book. Except here where I say title, it's the title of nobility. Except here when I say title, it's a job

title. A job title. This is one of the big problems. JSON doesn't mean anything. Can we make JSON more expressive? Well, And this is why we got JSON-LD. That's where we can extend it. It's a W3C standard. Takes the JSON you're already writing and give it globally unambiguous It's a it's it's formalized, it's expressed in RFC 4627. It's JSON that is entirely self-describing and it's 100% compatible

with your existing JSON. So it gives us everything that was missing, everything that our agents need to start to understand the data. And if we can then we can do incredible things. What does it take to turn JSON to JSON-LD? Well, if meaning is always contextual, we just need to add context. And and now this is still 100% compatible with your existing JSON and if you're if

you're in if your coupling is so brittle that you can't even do that, it doesn't matter. You can actually turn JSON into JSON-LD with zero edits to the syntax. I'm going to talk about this in depth tomorrow in the data architecture for AI. But what does it mean for our agents? It means that they can just start to understand your systems, that your that all of your

APIs begin to behave like the web. They can discover things and navigate on their own. So we solved the vocabulary problem with JSON-LD and the semantics in the RDF But in generation two, the clients also had to rely on human-written documentation, hardcode what they learned. This is brittle and we're still feeling this. When [clears throat] the server changed, the clients broke. So Lanthaner Lanthaner's dissertation is very

precise about this. He says that um the way we're doing it, it's impossible to dynamically communicate changes to clients and that's what makes our our agents brittle. Uh we have Hydra, which is probably the most important one because Hydra solves the problem. The biggest thing that we struggled with is the fact that our JSON-LD or our our APIs weren't hypermedia driven because we didn't have any way

to express our our data with hypermedia. That's where Hydra comes in. By the way, if you are uh if you want to read about this, Hydra is impossibly difficult to Google. It's hydra-cg.com. You might need the www. I'm not sure. But check that out. So Hydra is at the center of all of it is an API documentation class. It uh Hydra described service tells the client, "Here's

the classes of things that I work with. Here are the operations that the class supports. Here are the inputs that each operation expects. Here are the outputs that it return that it returns. Here are the status code that it produce and uh and what it means." So, what else do we have in here? Uh my my clicker not working? Uh-oh. Am I crashing? I'm almost out of

time. What are you doing? No. Okay. Okay. There we go. We're catching up. We're catching up. All right. So, this isn't documentation for a human to read. It's a machine-readable contract served by the API itself. All the All the metadata you need travels with the data. Uh it doesn't need a system prompt. The system can just read the API the same way you read a web page

and suddenly you can discover what else you can do on So, instead of agreeing on static cla- contracts at design time, we advertise valid state transitions, what it can do next. The client allows affordances. What does it mean for your agents? Well, the one is that Chrome can render any conforming HTML page that it hasn't seen before. The page has described itself in HTML. The browser understands

that. It follows the description. But, no agent today can use a tool that That um And it's it's cuz we're back to the gen one gen two stuff. But, the browser is just a generic client for the human web. HTML is the shared description format that makes it possible the hypermedia. Hydra is the hypermedia for uh Hydra is the hypermedia for your APIs, for your agents. So,

we take JSON-LD and Hydra, put it together, and your client understands the API. It understands what it can do. And it allows us to build a generic client. Uh this is from 2013. This is a that can render a fully functional UI for any Hydra compliant backend. It's a proof of concept. It's ugly, but it proves that exactly what we need to be doing with agents is

possible. Uh there was always the chicken and the egg process problem that nobody would build the servers because there were no clients, nobody would build the clients because there's no servers. But today the whole thing goes away because we can use AI to build tooling that we always wish we had. the we can build the solution that never got built. So as far as what the future

looks like, like you know, ultimately we've seen this movie before. And when we saw with the web the virtuous cycle kicked in, the standards created the tooling, the tooling created adoption, and all of it. But what I see is that the tools that support Hydra, they can discover the new tools. Um and there's one other one. Oh, is it 10 minutes? I I thought I was running

out of time. Oh, well then I could talk a little more about this stuff. The chicken and the egg problem. Because the main thing is a third-generation agent can interact any conformant tool that it has never And we can have new tools enter the ecosystem, the agents can find them and use them without an integration sprint, without a system prompt update, without a human in the loop.

And the the ecosystem grows at the speed of the vocabulary adoption and not the speed of And I think that's one of the most important things that essentially what happens when you take all the ideas of the web, HTML but for data, the generic client like a browser but for your agents, everything starts to change. Now you have a web for your agents, and you get the

economics of the web. Now, I mentioned the chicken and the egg problem. Nobody builds a self-describing tools because no runtime rewards it, and no runtime rewards it because there's no self-describing tools to consume. And Lanthanum actually identified this in 2014 that that said he said that's the mechanism that keeps the semantic web's best ideas trapped in academia. The standards existed, the vision was clear, but building a

properly self-describing hypermedia-driven API, it required a lot of expertise. when the path of This is where the path of least resistance diverges from the right path. And when that happens, the right path loses every single time. And there's also a second mechanism that's worth mentioning. The developers who understood the ideas could absorb the pain in another way, right? With the With the SDKs. And at human scale,

with our mostly stable APIs and our version libraries, all of this worked, you know, mostly. But at the agent scale, it breaks catastrophically. And the Postmark is a a great example of all of this. Uh ultimately, the deferred problem comes due with interest. the solution itself historically hasn't been built, not because the ideas were but because the on-ramp itself was And the incentive structure was broken because

the reward for building a properly self-describing tool was diffuse. It benefited the ecosystem, but the cost was immediate and local. But something has changed, and it's changed the economics of all of this. Because the agents that need this architecture are also the best tools that we've ever had for building it. Today, generating a Hydra. API documentation from your existing REST is easy. Inferring a JSON-LD context from

existing JSON schema is something that they can do. we can write the semantic annotation layer on top of the code that was never designed with any of this in mind. And that's kind of a key thing. But these are exactly the task the language models are genuinely good at. Pattern recognition, structure transformation, vocabulary mapping, taking something that already exists and just expressing it in a richer, more

interoperable form. Like this is something that we can start doing today. And this is where the entire incentive structure begins to flip. A self-describing tool isn't just good for the ecosystem in the abstract. Right? It's immediately and concretely better for the agents that your team is building right now. And the reward becomes local, not diffuse in the maybe someday this will be valuable. The ecosystem benefits is

just a side effect. That's just one of those things that that just happens. And so for the first time in history, the path of least and the right path, they're starting to converge. So remember, a lot of these problems, we've seen this The web was just a collection documents in 1993 with no with no shared format, no interoperability. Uh no way for a browser that it never

seen a page to know what to do with it. Then HTML became the shared vocabulary. Then HTTP became the shared protocol. And the browser became the generic client. Suddenly, everything that required bespoke engineering for every new site became something that a kid could build in an afternoon. So the standards created the tooling. Tooling created the adoption. The adoption justified more standards. The web didn't grow because the

individuals got better at writing HTML, it grew because because the architecture itself made participation participation cheap. It's kind of loud out there. So, this is the future that I'm describing. Not a future where every developer becomes an expert in RDF or Hydra and JSON-LD, but it's a future where the architecture does the heavy lifting and the developer just annotates their existing work letting the agent do the

rest. And so, I'll tell you what it looks like concretely. A tool publishes a Hydra description alongside of its API. It's actually in the API. An agent can discover that description with no previous programming, no previous tools, no anything else. And it's not because a human wrote it into a system prompt, but because the tool because the tool itself expressed it in a machine-readable form at runtime.

And a second agent built on a completely different framework can discover the same tool and use it without any additional integration work. And then a third agent that didn't exist when the tool could be that was built can discover it through a discovery endpoint and then start to use it tool use it too. So, new tools can be discovered new tools enter the ecosystem the agents can

just find them. Just like somebody can publish a new web page and Google will find it and you will find it. They There's no integration sprints, there's no prompt rewrites, there's no bespoke plumbing. The browser is the and the third generation agent is the generic client for the machine web. And there's one more thing. There's Remember I listed the the six constraints and one of them was

the optional code on demand constraint. This is actually where it gets interesting. And it's not like an obligation, it's not something that you have to do, but it's something just to keep be aware of on the horizon because once you have a uniform interface, once your tools are self-describing, once your agents can verify who they're who they're talking to and what they're talking to and what they're

talking about, a tool can deliver more more than data. It can deliver the logic for validating its own input. There's another vocabulary in that standard stack called Shackle that runs locally before the calls can make and makes its own authentication machinery. It can deliver that machinery. It can deliver reasoning scaffold to tell an agent not just what it can do, but how to use it as well.

Now, this thing is optional. It's the And Fielding marked it optional as a reason for a reason. We don't need it, but it's a useful thing to have. And now it becomes possible, like genuinely safely possible in a way that it isn't right now because possibility in distributed systems is always downstream of that So, let's come back to where all this started. Uh to the broken integrations,

to the compounding error rates, to the MCP server that silently BCC'd every email for months, the 437,000 downloads that turned out to be a remote control remote code execution vulnerability, the context window collapsing under the weight of the tools and the schemas that we're not even using. The thing that I said at the start, these things aren't bugs. They're not operator error. They're just predictable consequences of

building a web of agents with no architecture underneath of them. With with nothing load bearing underneath that abstraction. And we built generation uh generation one when we should have built generation two, and we built generation two when we should have built generation three. And so, here we are in 2026 trending all the way back to generation one and calling it progress. But this is what I didn't

say at the start. The architecture exists. The standards are ratified. The research is done. The work that Markus Lanthaler published in 2014, the bridge between REST and Linked Data, the vocabulary for self-describing the model for generic clients, it's just been sitting there waiting. It's waiting for us. Not waiting for better models, not for faster hardware, not for the next framework that's promising to fix everything. It was

just waiting for us to pay attention. So, the Semantic Web community built something extraordinary. Half of them were trying to solve the integration problem. Half of them were trying to feed clean unambiguous data to an AI that didn't exist yet, but now it The two halves of the fractured research have finally come together in the same room at the same time. The things that you called dead

haven't yet had a chance to be full born. So, it started with Carpathy's insight. The agent succeeded because the world But, it only worked at a small scale. It could work at web scale. So, the question for you and for your organization is and and a question for the whole industry is not which model to use. It's not which framework to adopt. It's not which protocol to

standardize next. The question is, are you going to specify your world enough? To specify it well enough now that there are standards to solve this problem at Because the tools are most older than most of the AI frameworks that you evaluated the last quarter. They're more principled, they're more durable, and for the first time in their there's an application capable of using them in the way that

they were always meant to be used. And so, if you're looking at this and you're feeling like you're behind the curve you're not. You're not behind, you're just at the beginning of it. And if you're in this room right now, that means that you're early. And that's kind of a cool place to be. So, thank you. >> [music] >> Woo!