Your Next Software User Is an AI Agent. Is Your Architecture Ready?

Picture an AI agent handling a customer billing dispute. It reads the complaint, checks the account history, and determines that a credit is warranted. All within seconds.

Impressive. Now ask it to actually issue the credit.

The customer agreement lives in another system. The approval rules are buried in application code. The billing tool expects a person to click through several screens.

The agent understands what needs to happen, but the architecture won’t let it finish the job.

That’s the problem I expect more enterprises to encounter as agentic AI moves into production. However, the strange part is that the barrier to finishing the task has very little to do with the agent’s intelligence.

We’ve spent years modernizing enterprise software for the people using it. Now we need to modernize it for the agents that will increasingly operate it.

The User Interface Was Never the Whole Product

Think about how enterprise software works today. People open applications, navigate dashboards, make decisions, and carry work from one system to another. The user interface is how they interact with the business.

An agent doesn’t necessarily need those screens. It can retrieve information and initiate actions through APIs, Model Context Protocol (MCP) servers, and other programmatic interfaces. That’s part of the shift toward headless architecture.

But headless doesn’t mean the application disappears. Its data, business rules, permissions, and compliance requirements still matter. I’d argue they matter more.

For years, software vendors built competitive advantages around polished user interfaces, user habits, and the cost of retraining employees. Those advantages weaken when agents perform more work without opening the application’s user interface. What becomes more valuable is the underlying system of record: trusted data, validated domain logic, operational governance, and auditable transactions.

There’s a commercial consequence, too: up to $234 billion in enterprise application spending could be exposed to agentic AI disruption by 2030. That’s spending at risk of disruption, not spending guaranteed to disappear. And when agents do work once performed by people in dashboards, per-seat pricing may increasingly give way to usage-, action-, or outcome-based models.

For software vendors, that’s a business-model challenge. For enterprises relying on their applications, it’s an architecture challenge.

We’ve Modernized the Pieces, Not the Workflow

Most enterprises have been modernizing for years. One team updates legacy applications. Another consolidates fragmented data onto a modern platform. A third builds integrations or simply does a user interface refresh.

Each project can succeed on its own. The trouble starts when an agent needs to execute a workflow across all of them.

You can give an agent accurate customer information, but if the application responsible for acting on it keeps critical rules buried in legacy code, what happens next? Or you can expose a clean API while the data behind it remains inconsistent. The agent can take action, but can you trust the decision?

In both cases, we’ve modernized parts of the technology without modernizing the work.

Agentic AI doesn’t care which modernization project was successful. It cares whether the entire workflow works.

Here’s what that looks like in practice. A client needed to speed up quoting for complex engine repairs, where contracts dictate which parts can be repaired, replaced, or refurbished. Each quote took days, sometimes weeks, of manual research across contracts and maintenance manuals. The client had already modernized its data platform, but quotes moved no faster because the bottleneck was never the data. It was the research. We rebuilt that workflow around a suite of research agents, cut research time by 80%, and quotes started moving at a completely different speed.

This is why application and data modernization can’t be planned as two independent workstreams. The architecture has to support the complete business outcome.

An API Doesn’t Make a System Agent-Ready

There’s a temptation to think the answer is simple: expose the endpoints, connect the agent, and you’re done.

I wish it were that easy.

Retrieving information is one thing. Issuing a credit, updating a financial record, or ordering a replacement part is something else entirely. Now we’re talking about execution, not just access.

This is where I use the term agent control surface: the bounded, governed interface through which agents read from and write to systems of record.

APIs and MCP servers can expose tools and data to agents. But MCP doesn’t automatically enforce your business rules or decide who is authorized to act. Those controls still have to be engineered into the underlying systems and workflows.

Can the agent retrieve authoritative data? Are business rules explicit and consistently applied? Can it recommend an action but execute only those it is authorized to perform? When something goes wrong, can we trace the action, handle the exception, and, where possible, reverse it?

These aren’t problems a better model will solve on its own. They’re questions about workflow, application design, data architecture, integration, and governance. And they have to be answered together.

Start With the Work, Not the Technology

So where should you begin?

I wouldn’t start by making every application headless or exposing every available API. I’d start with one meaningful business workflow.

Trace it from beginning to end. Which systems hold the records? Where is the business logic? What data can the agent trust? Which decisions need human approval? What happens when a system fails halfway through? How is governance maintained?

You’ll find the gaps that matter. That’s your modernization roadmap: a coordinated backlog across applications, data, integrations, and controls, driven by a business outcome rather than disconnected technology projects.

And measure it accordingly. Not by how many APIs you’ve exposed or how much data you’ve migrated, but by whether the workflow completes reliably, how exceptions are resolved, and whether business outcomes improve.

The goal isn’t autonomy everywhere. It’s dependable and trusted execution, with human judgment where it belongs.

The Real Shift Is Bigger Than Headless

What excites me isn’t getting rid of dashboards. It’s what happens when people no longer have to carry work manually between disconnected systems to get the job done.

But we won’t get there by placing an agent on top of architecture that was never designed for it.

The next generation of enterprise software won’t be defined only by what it allows people to see. It will be defined by what it allows agents to do, reliably and responsibly.