Why Agent First Architecture Matters

SPEAKER_00 0:00

Welcome back to Inspire AI, the podcast where we make sense of the shifts in artificial intelligence that matter. Not so we can chase every new technology, but so we can make better decisions about the future we're building together. Today we're kicking off a new series called Architecting for the Agent First Future. And I want to start with a thought that I believe every technology leader, software engineer, and enterprise architect should be thinking about the next architectural transition isn't just adding AI to today's software, it's redesigning software for a world in which autonomous software become first-class actors. Think about that for a moment. Because for decades, enterprise architecture has quietly been built around one fundamental assumption, and that is somewhere at the end of the interaction is a human being. A human clicks the button, a human interprets the error, a human decides whether to retry, and a human even notices when something doesn't make sense. We've built entire platforms, workflows, security models, and user experiences around that assumption. And for the most part it worked. But autonomous AI agents challenge that assumption. Because what happens when the primary actor interacting with the software isn't a person sitting behind a screen? Suddenly, some of the most fundamental decisions we've made about how software should work deserve to be reconsidered. And that's what this series is about. Over the coming episodes, we're going to explore what it actually means to architect an agent-first world. We'll challenge how we design APIs, how we establish identity and authorization, how we manage long-running autonomous workflows, and how we observe systems that make decisions we didn't explicitly program. We'll then explore what happens when customers' agents start interacting directly with their company's agent. And we'll ask ourselves bigger questions like what happens to user experience or enterprise platforms and even business models when software increasingly interacts with software on our behalf. This is going to be more than a series about human interactions with AI. It's going to be primarily preparing our architecture for a world where humans and autonomous agents coexist and where the responsibilities of each begin to change. Because I believe the organizations that get this right won't simply have better features. They'll have fundamentally better platforms for the next era of computing. And that brings us to our episode, when humans stop being the primary user.

When Customers Send Agents Instead

SPEAKER_00 2:44

I want you to imagine it's Monday morning. Your company has a large enterprise platform used by thousands or even millions of customers. Historically, those customers interact with it exactly as you'd expect. They'll log in, they open dashboards, they search, they fill out forms, they configure workflows, and all of this calls APIs through applications the developers have built. Now imagine that over the next few years, half of those interactions stop coming from humans. Not because you've lost customers, but because the customers have agents. Their agents investigate problems. Their agents retrieve information. Their agents monitor changes and initiate the workflows and communicate with your agents. And those software actors might make hundreds or thousands of decisions in the time it once took a human to navigate three screens. So there's a deeper architectural question to start asking. And the question to now ask ourselves is what breaks? I think that may define one of the most important architectural transitions of the next decade. The assumption hiding inside our software is that most enterprise software is human first. Even the APIs are often human first indirectly. We like to think about APIs designed for machines, and technically they are. But the developers using those APIs are humans. And when an API has ambiguous documentation, a developer figures it out. When an operation returns confusing error, somebody opens Stack Overflow or Slack or whatever your internal chat social media channels are, and they check the docs or they'll contact support. When two API calls need to happen in a particular sequence, a developer has to learn that sequence. When an action might be dangerous, we frequently rely on a user interface to insert friction. You ask yourself, are you sure? Should I confirm deletion here? Am I supposed to review this before I submit it? And those are the human safety mechanisms that we think about that the systems tell us to process before clicking the OK button or the delete button. An autonomous agent doesn't necessarily have any of that. As a matter of fact, it doesn't have to click those buttons. It can operate continuously and it can retry over and over and over again. It can branch, it can delegate, it can discover new tools, and definitely it can interact with other agents. And it can potentially perform actions at breakneck speed, which means we're introducing a fundamentally different actor into systems originally designed around human behavior. It's much bigger than chatbots, right? Because a chatbot is primarily an interface. You ask something and it responds. But an autonomous agent is an actor, has a goal. It can decide what actions to take. It can use tools and it can maintain state. It can wafer events. It might even hand work to another agent. I've spoken recently about this with more than one

Machine Speed Changes Costs And Risk

SPEAKER_00 5:53

of my podcast guests here. So this merge is a very different architectural object. There's an easy mistake to make here. Take today's application, put a language model in front of its APIs, and call the result agentic. That might produce some impressive demos, but it doesn't necessarily produce a safe and reliable platform. And it's not about giving the model access to the tools. It's really about what happens after you do. When you have machine speed consumers, that changes your economics entirely. Suppose your software exposes a search capability. A human might perform 10 searches. That's excessive, but let's just give it a number during a session. And an agent could perform hundreds while investigating one question. And suppose your system exposes an expensive analytics operation. A human sees a button and it clicks twice, but an agent sees a callable capability and invokes it recursively across 20 dimensions. Nothing is actually malfunctioning here. It's the agent is simply behaving like software. That changes capacity planning. Think about rate limiting. How about cost controls and abuse prevention? Those are real product economics. And the question we need to ask is how often should we allow this to run? For what purpose? For how long? And at what cost? And whose dime is it? And maybe even what authority, which we'll get in later in the series. Those are very different questions. Let's break this down at a

Tasks Replace Sessions In Real Systems

SPEAKER_00 7:26

session level. Humans get in, get out, call that a session. Agents don't have sessions. They have tasks. At a session level, a human might log into a website, do a search, click on some reviews, drop something in their cart, check out their cart, click make a payment, and then they're done. They're out. That interaction has a natural boundary. But agents don't necessarily behave that way. Imagine an agent investigating a customer issue. It retrieves information, it analyzes several records, and it discovers that another system hasn't finished processing something. So it waits. Three hours later, an event arrives. The agent resumes. It determines that an action requires approval. Now it waits overnight. A manager approves the action next morning. The workflow continues. By the time the task finishes, the model invocation that started it may have maybe long gone. The server that originally processed it may have been restarted. The software version may have even changed. So what is the durable object here? It's not a chat and it's not an HTTP call. It's not even one model call. It's the task. And that's a critical mental model for agent first systems.

Identity And Audit Trails Get Messy

SPEAKER_00 8:40

Now consider identity. When I log into software and click a button, the answer of who did this? It's pretty straightforward. I've logged in with my username and my password. It's going to be able to trace me throughout that session. It was me, no doubt about it. But suppose I tell my personal enterprise agent, investigate these accounts and escalate anything that appears at risk. My agent contacts another company's agent. That agent invokes several internal tools. A specialized subagent performs analysis. Another system creates a case. Who performed the action? There may be several correct answers. The human principle authorized the goal. A particular software agent initiated the task. Then a workload executed the operation. And a delegation grant established its authority. And there's a specific task that explains why that authority has been exercised. And those concepts have to remain separate. Otherwise, the audit trail eventually says something wonderfully unhelpful like, I don't know, service account 42 changed the record. And that's not accountability. That's basically archaeology.

Five Assumptions To Scrutinize

SPEAKER_00 9:48

So if agents become first class users, I think five assumptions deserve immediate scrutiny. First is the interfaces, where the capabilities need to become machine understandable, not merely machine callable. Second is identity. We need to understand and know both which software actor is operating and whose authority it carries. And third, the state, long-running autonomous work, needs durable execution outside the model's conversation context. Fourth, control. Permissions need to become bounded by purpose, task, time, resource, and sometimes money. And fifth, observability. We need to understand not only whether the service was healthy, but what the agent actually did. And throughout this series, we're going to talk about those five themes. So to think about where we're going with this, I'd like you to ask this question. First, pick an important capability in your platform and ask, could an autonomous actor safely discover this capability? Could it understand what the capability does? Could it determine what permissions are required? Could it invoke it safely? And could it retry without accidentally duplicating the effort? There are many other questions to ask, but we're not going to get into all those details. But at the end of all those questions, six months later, could you actually reconstruct what happened? If the answer is no, that's seriously useful information. It doesn't mean that you need to rebuild the system tomorrow. It just means you've discovered where the architecture still depends on

Inventory Hidden Human Assumptions

SPEAKER_00 11:22

a human being in the loop. Even if that dependency was never written down, there's a practical recommendation from this episode. That's pretty simple. Start inventorying your hidden human assumptions. Where does your UI contain business logic that your APIs don't? Where do people compensate for ambiguous system behavior? Where does authorization assume that one login equals one actor? Where would you struggle to explain an autonomous action after the fact? And those are the architectural signals that will be important in the transition from software without AI to software with AI. And of course, from software where humans are the default actors to software where humans and autonomous actors coexist. And as we explore how platforms are designed intentionally for that world, it will look different from platforms that simply bolt agents on to what already exists. And as we dive into the next episode, we're going directly into one of those differences, the API, the application programming interface. Because giving an agent an API designed for a developer is like giving a self-driving car a steering wheel and saying, good luck, it might have access to the controls, but that doesn't mean the system was designed for autonomy. So until next time, stay curious, keep innovating, and keep questioning the assumptions your architecture was built on.