Agentic AI makes software useful in places where clean APIs do not exist, but it also gives that software room to take actions nobody explicitly approved. Kelsey Hightower and Dan Moore examine where agents genuinely improve automation, where ordinary code remains the safer choice, and how identity, scoped credentials, intent-based APIs, policy engines, and hard operational guardrails keep unpredictable software under control.
.png)
.png)
Hi, everyone, and welcome to today's webinar, Beyond the Hype: Practical and Responsible Use Cases for Agentic AI. I am happy to introduce our speakers and agenda today.
Really quick, let's run through what we'll be doing. I'll do some quick introductions, then we'll get discussion between our speakers, and we'll dive right into submitted questions. Some are presubmitted, some will be submitted live. There is a Q&A function that we encourage you to use.
So without further ado, let me introduce today's speakers. First, we have Kelsey Hightower, former distinguished engineer at Google Cloud, author, OSS contributor, and technical advisor. Next, we have Dan Moore, senior director of CIAM strategy and industry standards at FusionAuth.
Today, we'll be discussing agentic AI, auth, and all submitted questions. Again, you can ask questions the whole time, and we encourage you to use the Q&A function. That being said, Dan, I'm gonna hand it to you to kick off the discussion with Kelsey.
Great. Thanks, everyone, for joining us. And, Ben, I gotta call you out a little bit — we're not gonna get to all the questions. I would love if we got to all the questions, we probably won't, but there are so many interesting things to talk about.
I wanted to kind of set the stage. We'll talk for five or ten minutes about agentic AI and some use cases, and then we'll move right to those questions as Ben mentioned. So the first question I had for you, Kelsey, is: in March 2025, you had a nice Bluesky post that talked about — and my quote — "most of what we call tech is about getting the right information into a database and trying to prevent the wrong person from reading or updating that database." When you think about agentic AI systems, is it really a new problem, or is it kind of an old problem in a new scope?
Yeah, I think the fundamentals are the same. That particular post gets at the fundamentals of computing. A lot of people probably skipped all of that — just got into industry, maybe learned a web framework, maybe went to a code school. Nothing wrong with those options, by the way. I think most people just dove into existing frameworks and skipped all the fundamentals, which is: most computing is meant to manage data. No data, no computing required. And I think a lot of people have gotten confused by that.
The next thing — AI agents, and this concept of automation specifically — if you've ever tried to automate anything, it becomes much easier when there's good documentation, libraries, and APIs. If you have those things, you can literally write a bash script, use cURL, and a lot of this stuff will be super easy. But I remember at the dawn of the web, most information was hidden behind a web page with no API — you may have had to log in first — and in many ways the HTML, the CSS, the stylesheet, the whole layout of the page became this pseudo API. Super rigid, could change any day. And at that point, most people started to do things like screen scrape. A lot of this agentic AI stuff reminds me of that world.
We have a lot of surfaces, we have a lot of information trapped in these systems with no clean APIs, but the fundamentals are roughly the same. Your goal is to try to get some set of steps completed. And I think the reason why people are super excited right now — and I do think it deserves some attention — is that most of the things we're interacting with that are useful don't have APIs. So this agentic world gives us a new framework for trying to automate things that we thought were previously either too hard, impossible, or locked behind a black box.
So when you say we really just all want clean APIs — is the solution for us there? Are there incentives for people who want to get on the AI train, or want to get some of the benefits of this? Are there incentives for those libraries, APIs, and docs that are different from the incentives before the kind of dawn of the agentic AI world?
I think so. Some of the incentives right now are that it's cool to have an MCP server — this Model Context Protocol that says, hey, if you want an AI agent to be able to do anything without a human in the loop, then you're going to have to have really, really good APIs. Bonus if you have some additional tooling to make this work.
Ten years ago, it was like, no, you can do it — you can log in, you can click around, you're the API, you're the agent. We just had people doing all these manual tasks. There was already an incentive to give people an API so we could automate those tasks. Let's just talk about a task that is hard to automate: a customer emails you a purchase order. It can come in any format. It could be the tool of their choice, with a purchase number hidden in that invoice, and then you have to extract that particular purchase order. There is no standard for how people will send you an invoice or some contract to do business. So in those cases, since there's no clean API, maybe you can consider SMTP — the email — as an API. But once you get the artifact, the actual document, good luck parsing that. You could try to make a hard-coded parser, but then it wouldn't be flexible enough. So I understand why people want to use tools like OCR or maybe even an AI agent that can actually parse these things using classical ML techniques.
But the problem is, since you don't have an API, we usually just left those tasks to be manual. If you were to have an API — let's say there was a universal standard called "invoice" and there was an invoice library — then what you could do is receive an invoice, you don't care where it came from, you would just call the invoice library and extract the purchase order. Downstream would be easy.
There was an incentive then. Now I think, given the AI hype, if we're gonna make this thing work, we're really going to have to have APIs, because relying on screen scraping just burns a bunch of tokens. And I think there's actually an incentive to have people burning tokens to just brute force things — to build an AI agent that can parse any web page, any web app. It's like we're missing the point. Give me an API so that the agent can be more efficient, and those that choose not to use an AI agent can also be more efficient. So that's where I hope the incentives actually end up.
I love the idea of a world where more APIs are delivered by products everywhere because of the AI hype, and then we all benefit. APIs are deterministic. In your example of the purchase order, you were dealing with a nondeterministic system, but the end output is hopefully that you get that purchase order — you get the number, you get the amount.
Where do you think there's a — and obviously this is the biggest question — when do you reach for a nondeterministic system versus a deterministic system? We're in the auth space. We think that portions of authentication should be 100% deterministic because it's security. But what's the litmus test an engineer should use to decide, hey, this is a deterministic, API-focused task versus actually an agent or a nondeterministic system?
The rigorous people listening are probably like, Kelsey, nothing is deterministic. You're right. The concept of time in computing says nothing could be deterministic. The concept of a network means behavior could be unpredictable. You have no idea if the network's going to be down. You have no idea if something may get lost in transit. This is why we add checksums — to make sure we're receiving the right thing. And you have no idea if you're under attack, so the checksum you're verifying could be the hacked version of the thing you're about to parse.
In many ways, look, that stuff is still hard, but at least it was somewhat predictable. If I wrote code that said if this, then that — and if it didn't do that, just give me an error, don't do anything else — in this new world, now we have these Swiss army knives. You can call it an LLM, you can call it an agent, you can call it whatever you want, but you have this new Swiss army knife of a framework that is not necessarily limited to the things and instructions you give it. You're almost giving it agency.
Calling them agents may be the appropriate term, but in that agency, you're making a trade-off. This thing says, hey, I'm gonna go and try to parse this invoice, but if that doesn't work, I might go to the internet and try to find another tool that could parse it. And in the meanwhile, I might upload your data to some random website that I found as a tool. You had no idea it was going to do that, and now you have a data leak on your hands.
Could a human do that? Absolutely. But a human tends to have consequences — they have a model of the world, which is maybe I shouldn't post this invoice to this random website. Most people have been tuned for that behavior over time. The model is going to try to do exactly what you've asked, which is parse this invoice, usually by any means necessary. And I think that's the new thing in software that we're not used to — having software exhibit these kinds of side effects. The last time we had software that did this, we called it malware. Any software that was busy doing random things on your machine, you'd want to shut that down. Your virus scanner would detect it and say, yeah, this thing is doing abnormal behavior. Let's lock it down.
I love the idea that the last time we had nondeterministic software that acted on its own, we called it malware. That tells you something about both the excitement and the dangers of agents.
I want to kind of wrap up this discussion and get to the questions. So the first question: Google Drive's permission model doesn't seem to be designed with agents in mind. You can't easily say, write to this folder but you can't delete for only 24 hours. You can't scope things down to that extent. Service accounts get you part of the way there, but it's not totally standardized. And Google — you know as well as I do — has been pushing the boundary of security forward for a long time. If they can't get this kind of permissioning right, what happens? Are other developers able to do so? The broader question is: what patterns or primitives should platform and API builders — who are hopefully on this call — be implementing today? And what would an agentic authorization layer that dealt with these issues look like?
I think people are asking for something they don't actually want, but it may be necessary — so I have empathy there.
Let's talk about authn versus authz. Authn is like who you are. I think we've kind of dialed that in. It could be a JWT token, it could be username and password, it could be biometrics, or a combination of those things. And then we're gonna say, if you have these things, then you're Kelsey — or we're gonna assume you're Kelsey.
But the authz side is tricky because I think most people were happy with the basics of RBAC — role-based access control. Like, hey, Kelsey is the admin, so he can do anything he wants on this platform. And the reason why we have admin is that there's going to come a time where you don't know what permissions Kelsey needs if you expect him to be able to recover the system if it crashes. So we have the admin role. And I know a lot of people fantasize about getting rid of admin — don't be delusional. There's gonna come a time where you need a permission you don't even understand you need. And once you're done fighting errors, you're gonna do what we always do: make him admin. Hopefully you don't leave them admin forever, but that's why we still have things like admin. So that's the extreme.
The other extreme is fine-grained authorization. The problem with that is there's no limit to it. Read, write, update — the CRUD operations sound like there's enough there. But then you're gonna have things like, it can edit this paragraph but not this paragraph. As a software developer, think about someone who had to implement authz for just a Google Doc. If you told me you could have fine-grained permissions at the paragraph level — like, this header can't be touched by anyone except the document owner, anyone in this group, but this paragraph can be edited by an agent, but not more than 140 characters — think about the logic there. You're gonna need a rules engine. A developer would have to say, here's what a paragraph is, here's what the second paragraph is, and here's how you deal with character counts.
Once you put all that logic in Google Docs, now you're going to have the biggest performance issue you've ever seen. Because every time an edit happens, I have to say: who is editing this paragraph? Is this the second paragraph? Let me look at the time — because you just mentioned you can only have this access for 24 hours. So I have to check the timestamp — this is almost an intractable problem. You can try, but I still don't think customer demand will ever allow you to just build a solution that fits every customer's needs.
So what's the next thing we're going to get? Things like authorization frameworks where people can make their own policy engines. Open Policy Agent comes to mind, where you can start to describe all of these activities. So a tool like Google Docs would then say, hey, there's an agent trying to edit this paragraph — almost like a Vim plugin. It's like, hey, here's what's being manipulated in this buffer. You're a plugin, do you want to do anything here? Format that code. I think we're probably gonna end up with those policy engine frameworks before we get all of these tools to have a trillion permission combinations. You're going to end up with a situation where your enterprise gets a chance to authorize an action before Google Docs gives you the permissions you're dreaming of.
At that point, you're just basically moving the problem upstream. And I totally get the spectrum from super fine-grained built into an app versus admin. I love your characterization that an admin role is for permissions you don't even know you need when it's granted.
But with these auth frameworks — OpenFGA is one, Permify is one, there are a number of them out there — you've just pushed the problem upstream. You're saying, hey, developers, Google Docs, use this authorization engine.
They have done that. So I guess the white paper we're looking for here is Zanzibar. If you go read that white paper, it'll tell you what happens when you get beyond basic CRUD operations and you have millions and millions of users. You almost need a permission graph at this point. You're gonna have to take all the permission sets and try to put them in a database — with something like the open source SpiceDB — where you try to calculate this graph so that everything we talked about earlier becomes a lookup. You say, hey, this thing is trying to perform these actions — can they do it or not? And ideally something that implements Zanzibar would say, yes, that principal, which you've classified as an agent, can totally edit that paragraph at this particular time.
So now you have to maintain all these permissions. But on the flip side of that architecture — will it scale? For the average enterprise, possibly. But for the user, what does the settings box look like? Let's get to real-world application. You're the user now, you asked Google for this feature, their engineering team goes off and does it. Now you log into the permissions platform, and there's a trillion rows. Hey, what would you like this agent to be able to do? Can it edit anything that starts with a capital T? What about things in English versus Spanish? How far do you wanna go with this?
Well, most people will just click "edit all." That's what we've seen with OAuth stuff. So that's not a great answer. How do we solve this problem without giving users a billion checkboxes, or one checkbox that 99% of people click that says "edit all"?
I think what you're gonna end up with is handling the things that are actually important. If it's super important, what you're going to do — and I think we did this with software — is go backwards. Let's see what the agent does to get the desired result. Let's record everything it seems to do. Do we like that? Then you kind of go backwards and say, well, what did the agent do? It did this, it did this at this time frame.
And then sometimes what we do in a sandbox: we say, you know what, that is the right thing to do, and I'm going to say, system, can you generate a permission set that allows it to do only the things we just recorded it doing? I think this is how these systems are gonna make something as complex as the Zanzibar paper actually work — just record it, turn off all the permissions, go into observe mode, and then ask: now that this thing has completed the task, what permissions were required? And that's where when you fall short and it says admin, you say, whoa. Admin should not be required to do this. That's way too big. Then you work with the vendor or the software developer and say, we need something more fine-grained than admin, and then you can go look and say, oh, this is what it was trying to do, there should be a subset of permissions that allow it to do that.
We saw that evolution with GitHub — it has way more fine-grained permissions than it used to. I think that might be the path forward. Observe in the sandbox, figure out the right set of permissions. That way you can tune the agent, or you can tune the app, and then you make those happen.
Just to put a fine point on this — in the Google Docs example, is this Google's responsibility to do this kind of heuristic work, or is it the user's responsibility? Is it my responsibility as a user of Google Docs to go into observation mode and generate that permissions list, or who owns that activity?
We can already see from history how this is gonna play out, and we see this with some of the startups out there. I'm actually an investor as well. As part of the due diligence we do, a lot of the AI security tools and authorization tools we see are allowing the customer to do this at multiple levels. It would be great if the Google team did this in a way that makes everyone satisfied. But most people probably won't be happy with that because you have another problem — the ability to just log in and change it.
Then the other factor we see is the man in the middle — whether that's a proxy or some kind of gateway that is minting credentials on behalf of the agent in real time. The agent goes off to do something, and what you end up doing is giving it a scoped set of credentials. You say, our company is only comfortable with these eight permissions, and if that doesn't work for your agent, then we need to have a discussion.
What you're seeing now, where there's a system like Vault or any other thing that can do dynamic credentials, is that it issues credentials in a way that limits scope. So the whole concept of IAM and federated identity and permissioning systems allows you to have this at multiple layers. Maybe we can trust people to configure the endpoint system right based on history — that doesn't always go well. And sometimes the vendor makes a mistake where the permissions don't actually get upheld, and then you have other kinds of problems.
What we're seeing in real life today is people leveraging networking tools and credential tools that issue credentials that have scopes applied to them. And let's just be honest — that right now still isn't enough, because there just aren't enough upstream, fine-grained permissions to make these even work.
Yep, a lot of work to be done there. And I 100% agree that it's gonna take some time, but I think it needs to happen.
You mentioned MCP earlier, and we had a question come in about that. MCP is converging on OAuth for remote server authentication and authorization, but there's still a lot of hand-waving about how consent scopes and token scoping work across a client, an MCP server, and the downstream API or data source that the MCP server wraps. In your opinion, what does a mature MCP auth story look like in two to three years, and where do you see the biggest gaps right now?
It looks exactly like the web. It looks exactly like what we already have. I think people really do think we're going to invent something new — we're not. Mainly because it needs adoption. If I call an API, if you're advanced, you're going to exchange that token on the edge anyway. A client shows up, you exchange that token for a very scoped token based on the API that was called. And then downstream you don't know where that's gonna go, but you know it's gonna go somewhere with a scoped token, without the ability to impersonate the original caller. We've done this before.
The challenge is we have no idea what the agent wants to do. But people want these agents to work, and they want them to work right now. So a lot of people are just like, look, let it do whatever it needs to do, give it all the access it needs. Until we tighten that up, that's a discipline problem. I have never seen people wanting so badly to unleash software to production that they have no idea what it does and expect that we can figure out how to limit its scope later. You're just gonna have to know ahead of time and mint those permissions.
I think another thing that is important for people to think about with MCP servers is that a lot of the APIs that exist today are not intent-based. I don't see how MCP is all that innovative. From my studying of what it's trying to do, it's a plugin system that wraps other APIs and tools, and its goal is to create an API that has intention. What do I mean by intention? If you were trying to create a virtual machine in the cloud, you're gonna have to call like seven API endpoints — you gotta create a network, a disk, attach it to a machine, pick an operating system, maybe an IP address and bind them all. But your intent was to create a VM. Your intent wasn't to call seven APIs and hope you did it right, because then the permission scheme for that is way too big.
So when you look at MCP, its job is to say, let's wrap all seven of those things into a new endpoint called "create VM." When an agent shows up to create a virtual machine, ideally you're giving it the permission to call that particular MCP for the sole purpose of creating a VM, not giving it the ability to create random networks and random IP addresses. We've seen this with Terraform and classic configuration management — a lot of people create Terraform modules to wrap cloud behavior into something that's approved by the company, and then you give permission to people to use those particular modules. So I think we're just seeing the same thing with MCP. We probably also need better intent-based APIs so we're not granting so many permissions to do basic things.
Yeah. And it's not just the permissions — it's like you said, it's not any random IP address you can create or any random network. It's only in the scope of the task that the agent is trying to do. How do you even start to think about that? Is it use-case-driven? Do you go look at your Terraform modules if you're a cloud provider and say, our customers have asked for these kinds of intents or these kinds of actions, so we're gonna wrap it all in an MCP server at the level of this Terraform module? How would you approach that?
The good news is people have already seen this. About twelve to fourteen years ago, this thing called Kubernetes came out. And if you look at its design, a lot of Kubernetes just wraps things into intentions — this desired state concept. Take the ingress controller as a great example. When you create an ingress in Kubernetes, which gives you a load balancer pointed at your app, all you do is create one object: I want an ingress, point it to this service. Under the hood, that ingress controller — depending on whether you're Azure, AWS, GCP, or your own integration — will then call the same seven or eight APIs required to create a load balancer and map it to your containers running in your cluster. So we've already seen this. That is an intent-based API.
If you're a cloud provider or a vendor, these are the common things people want to do. You can imagine a world where you say, look, we're gonna keep those same fine-grained APIs for people who wanna compose infrastructure, but we've looked at it over time and most people are just calling these APIs just to get a load balancer. So we're gonna introduce a load balancer API that is an aggregate of the most important components. You just say, give me a load balancer, I don't care what IP address — just get one, and once you get it, put it in DNS to this name. That's it. Now you have an intent-based API.
Why don't cloud providers or vendors do this? Mainly because it's too opinionated. And if you've ever had to maintain APIs for a long period of time, it is so hard to deprecate an API that lots of people use. So whenever you build these intent APIs, you're kind of stuck with them. This is why people tend to build composable fine-grained APIs — they can be composed into anything. But I think the agent world is telling us we're gonna have to do both. You're gonna have to have the rigid, low-level assembly of your API, and then you're gonna have to have the high-level functions and libraries that just make jobs easier for people.
I remember in the earliest MCP days — probably about fourteen or fifteen months ago — everyone was doing MCPs that mapped directly to their API endpoints, and people found that to be pretty useless.
We had a question from Daniel — thank you for bringing it. Basically the question was, if I understood correctly: an authz protocol should be created or at least leveraged for agentic AI. How do you see the governance of that kind of protocol happening?
That's a great question. I don't think you're gonna create a new protocol, because the problem is these systems are designed to integrate with existing systems. They're gonna have to authorize and authenticate to existing systems. Unless you can get every other company in the world to agree on new auth protocols, this is gonna be very hard.
But where does the auth protocol meet the agent? That's the key question. The agent should not be responsible for giving itself permissions — we would all probably agree on that, just like we don't let people give themselves their own permissions because it defeats the point.
We already have a mechanism. It could be a JWT token, it could be an SSL certificate. We have a way to give an agent something to identify itself. That's the authn piece. Now that it has those credentials, how do we scope what the agent can do?
If you write a shell script, you're typically writing it to do one thing. We actually have this same problem with Terraform. If you think about Terraform as an infrastructure agent — and I know it doesn't have the fancy word, but it has exactly the same problem — Terraform ships with things like the GCP provider, and what does that thing do? It allows you to create BigQuery instances, database instances, VMs, you name it. But in order to do that, you have to give Terraform a credential that is so big that it can do anything you may ask Terraform to do.
You could give it 50 credentials and put them all in a safe place, and then based on what module you're going to run, you can give it a credential for that task. So in the Terraform world, you could have 50 scoped credentials: this one can only create S3 buckets, this one can only create VMs, this one can only allow VMs to talk to S3 buckets. You see how this gets out of control. You could do that, and then you could map each of those credentials to that particular Terraform run. But you can imagine: if that gets too cumbersome, you're probably going to make a third credential that wraps all three — and now that credential allows the entire Terraform module to work. So maybe you do one credential per module.
Now let's get to the agentic piece. This is why fundamentals are so important. You've already been dealing with this problem for ten years. The thing about Terraform was it was somewhat predictable — you could look at the module and see what credentials you'd need, and you could mint those ahead of time. Agentic AI changes all of this. I can't tell by looking at your prompt what permissions the agent's going to need. This is the big challenge.
So I say, hey, I would like you to clean up my inbox. We have no idea what that means. It could mean organize everything by folders, or it could be delete everything. We don't know. So once it tries to do something, depending on its permission set, you might say, you know what, this thing is gonna interact with email — I'm only comfortable with creating folders and moving email into those folders. That's all I'm comfortable with.
If you think about that as an auth protocol, how we behave may change our mindset to say, you know what, this agent can do a lot of stuff, but here's what I'm comfortable with it doing, and then you use that to mint your credentials. And then you give them to the agent. Anything beyond that — any surprises — either you're like, wow, I didn't know I was giving you those permissions, let me scope this down even further. So I don't think we need a new protocol, but I do think we need a better way to express what we would like the agent to be able to do and not do, and maybe that replaces all those checkboxes you see in those permission tools.
Right, and this gets back to the heuristic question. There's gonna be some human responsibility for determining the scope, which also gets back to the intent-based APIs you mentioned.
Another question, from a Rootly AI software developer: we've spent decades building deterministic systems, as you kind of mentioned with Terraform and whatnot. AI gives us powerful new capabilities but introduces nondeterminism. Practitioners keep pointing to the need for an intermediary layer — some kind of gateway or some of those other things you've talked about — that enforces a contract between the two worlds of deterministic and nondeterministic behavior. Granting that determinism exists to some extent with software, what does that intermediate layer that sits between determinism and nondeterminism actually look like in practice?
One thing that I admire about the early computer scientists is that they would go out into nature to answer questions like these. This is how we got some consensus algorithms — the classic two generals problem. These are real-world constructs and contracts, things that have been studied for a very long time. People are thinking that AI requires a whole new set of thinking. Remember, AI is designed to mimic what we already do. It's been trained on the past.
When we think about a question like this: a human is somewhat nondeterministic. I have no idea what you're going to do. I don't know if you had a bad day. So we have frameworks in place — things like speed limits and traffic lights. You can ignore them, but we at least put them in place to say, hey, this is about how fast you should go. And what happens when you do something you're not supposed to? In society, we have things like cameras that will record your license plate if you run a red light, and then you will get a ticket. If it's really dangerous, we'll put in a speed bump so that your car gets damaged instead of you hitting a kid trying to go to school. At a car lot, they'll have those spikes in the ground that you can't drive out on. These are safeguards.
These safeguards will always be required, especially when you have a system that is designed to do things you may not expect it to do. That's kind of where the power comes from, because if it didn't have that flexibility, we should just all be using bash scripts. It does have value, and part of the value is the fact that it is flexible, that it is nondeterministic, and it may find new routes to solve a problem. This is the nice thing about Google Maps versus a static map — Google Maps will reroute you if there's a problem, whereas a static map is like, good luck, you gotta draw your own new routes.
So I really do think we need to figure out a way to say: these safeguards will be required even more so now. Before, you were able to get away without them. If you want to unleash an AI agent into production, you are guaranteed to need speed bumps and traffic lights and a cop on the beat to issue those speeding citations when these things start to get out of hand.
I love that analogy. It feels like there's a lot of work to be done to build all those speed bumps and traffic lights and speed cameras.
Another question, again from the Rootly AI folks: the homegrown trap for human auth is well understood. Teams underestimate token rotation, session validation, and edge cases until they're breached, and then they discover that these are important things to think about. For agent-to-agent communication, we're starting to see teams reinvent this from scratch — custom agent identity schemes, bespoke delegation chains, homegrown tool permission models. What are one or two mistakes you're already seeing engineering teams make when they roll their own agent authorization? And is there an equivalent of "just use OIDC" or "just use RBAC" emerging for agent identity and authorization, or is the standards layer still kind of too immature right now?
I think the standards layers are fine. What you talked about has always been the case even for microservices. There is no standard for very fine-grained authorization. There are frameworks, like SpiceDB, but there's no way to do it perfectly. If you have a microservice that needs fine-grained permissions, that's on you, the developer — you're gonna have to have some code that says, if this principal tries to do this thing, you go look in your permission database and figure out whether it can do it. We've been rolling that part forever. No one's ever going to agree on what all of these things should be. But we are starting to get frameworks — we talked about the Zanzibar approach and all of these things. That's always going to be there.
The other thing I think people have to realize is, specifically when it comes to AI agents, there is no reason why you have to run an agent doing inference in production every single time. What I like that I see some people do: they'll use an agent to figure out what steps need to be run. An agent goes out and figures out the best path to complete a task. And maybe you're like, wow, I never thought to call those five tools in that order, and it totally works. What you can then do is, quote-unquote, cache the result. It's almost like SSH'ing into a server and running a bunch of commands until it works, then looking back at your command history and turning the right set of commands into a bash script that you can just run.
Nothing's stopping you from doing that — remember, the agent is still calling the same tools you were calling before. So one solution might be: use an agent to get you the perfect set of steps that work, take the output of that, and just put it in a classic program. That way it's not doing inference anymore. It's gonna be way more predictable.
We did this with databases. If you run a SQL query, you have no idea if it's going to cause a full table scan or run into some weird conflict. And if your only goal was to get a particular result, we've cached those things. Not only will you save a bunch of money by caching things and not doing inference for something you already know how to do, there are also a lot of security side effects — once you've compiled down this particular agent or set of routines, you can almost treat it a little closer to normal software and put a bigger sandbox around it.
What does cache invalidation look like in that scenario? I love that idea of software as an artifact that gets cached, but what does cache invalidation look like?
I love that question. Why did you create the agent in the first place? If you created the agent to parse these five particular PDFs, then that cache — that script — will work. Cache invalidation looks like: hey, number six just showed up and the script doesn't work. Okay, now we need to validate the cache. We need to update that particular script or task, and we may use the agent again to run through the thing and say, hey, let's pick up where we left off. We also want to support anything that looks like this as potential input, and then you kind of tune that until it works. Then you say, cache it again.
We have this thing called versioning. You can literally version software. If that was version one, you can ship version two. That's how we did cache invalidation for software for a very long time.
Great. Final question: Josh Richards asks, do you think AI agents are here to stay, and what impact do you think it's going to have on the open source community? I guess those are the final two questions, and then we'll wrap things up.
I think it would be very helpful if we stopped saying "AI agents." It's cool now because we're all confused — burning tokens is in fashion. But at some point, thinking will come back. And when thinking comes back, we're just going to ask: do you think automation is here to stay? The answer is yes. That's kind of the point of having a computer. A computer allows you to automate things. These new agent frameworks, these large language models, domain-specific models — they allow us to automate even more things, especially unstructured inputs and things that don't have a clean API. So those agents help us do those kinds of things. I love it. I think it's amazing. I remember discovering screen scraping libraries that allowed me to deal with random web pages I'd never encountered before, and I was able to extract data from them. So that component was amazing. Automation is here to stay.
Whether we use AI agents for everything is a different question. From a pure computer science and software engineering mindset, we always optimize. Today, agents allow us to brute-force a lot of things. What you're going to see are frameworks that just have it built in, into a more symbolic style of programming, and they'll be able to handle way more things. We're definitely going to cache these results. In fact, I guarantee you that in ten years, there's gonna be a whole conference about reducing inference burn by going back to logical things — using classical programming with the help of an AI tool to reduce workflows.
What impact is this going to have on the open source community? This is another area where we're going to ask ourselves: what is an open source community? A lot of people have confused open source with being a bunch of software you get for free. And this is why they think AI is the end-all-be-all for open source.
The way I've always thought about open source is that it's a group of people who come together to solve a particular problem. Guido van Rossum created Python because he just thought the tools that came before — maybe the syntax, maybe other things — just didn't work for him. You curate a certain thing, and it's closer to fashion to me. I have been a maintainer of an open source project where I had to say no to some features, because I was trying to have that library or tool work a certain way. I didn't want all the features in the world. There's nothing wrong with ls being done. There's nothing wrong with cp being a dedicated tool.
So I think when it comes to the open source community, it's still going to rely on stewardship — people working together on a common problem, choosing to share their solution. And if that doesn't work for you, I think it's okay to create another project even if it rhymes with the other one.
Wow, thank you. Thanks to everyone for submitting their questions — sorry if we didn't get to everyone's. I want to bring Ben back on to close things out.
Had to find my mute button there. Thank you, everyone, that joined the webinar. As a special quick gift, we recommend you download our agentic AI white paper — super relevant regarding non-human identity and a lot of the discussion today — or visit fusionauth.io to browse the resources there. Thanks again to Kelsey, Dan, and everyone that submitted questions previously and during the webinar. Have a great rest of your day.
