Enterprise software must prepare for AI agents to act

By James Calloway

Up to $234 billion in enterprise application spending could be exposed to agentic AI disruption by 2030, according to James Calloway. That means spending at risk of disruption, not spending guaranteed to disappear; the article gives no methodology or market breakdown behind the estimate.

Can an agent issue the credit?

In Calloway’s opening example, an AI agent handles a customer billing dispute. It reads the complaint, checks the account history, determines that a credit is warranted, and does so within seconds.

The agent still cannot issue the credit. The customer agreement lives in another system, approval rules remain buried in application code, and the billing tool expects a person to click through several screens.

Calloway says: “However, the strange part is that the barrier to finishing the task has very little to do with the agent’s intelligence.” His diagnosis points to a gap between deciding what to do and completing a workflow across software that was not designed for agent execution.

For years, enterprises have modernized software around the people using it. As agentic AI moves into production, they must also modernize the workflow beneath those screens. Takeaway: the decisive constraint is operational architecture, not model intelligence.

What changes when agents become users?

Calloway describes the current model as people opening applications, navigating dashboards, making decisions, and carrying work between systems. An agent does not necessarily need those screens. Agentic AI can retrieve information and initiate actions through application programming interfaces (APIs), Model Context Protocol (MCP) servers, and other programmatic interfaces.

MCP servers expose tools and data, while APIs let software expose functions to other programs. This approach supports headless architecture, in which software remains accessible to machines without requiring a screen. Calloway says the application does not disappear.

Data, business rules, permissions, and compliance requirements still matter; in his view, they matter more. For years, vendors built advantages around polished interfaces, user habits, and the cost of retraining employees. Those advantages weaken when agents perform work without opening the interface.

What grows more valuable is the system of record, the authoritative source for business data. Calloway also prioritizes validated domain logic, operational governance, and auditable transactions: rules tested against known outcomes, controls over actions, and records that support later review.

Calloway expects per-seat pricing (one license per user) to give way increasingly to usage-, action-, or outcome-based models as agents perform work once handled through dashboards. He provides no rates, vendor examples, or transition timetable, so that shift remains a forecast.

For software vendors, this is a business-model challenge; for enterprises, it is an architecture challenge. Takeaway: agent-ready software will compete on trusted execution, not merely polished dashboards.

Why do modernized components still fail?

Most enterprises have modernized in pieces. One team updates legacy applications, another consolidates fragmented data on a modern platform, and a third builds integrations or refreshes a user interface. Each project can succeed on its own, but an agent still fails when it must execute a workflow across all three.

Agentic AI does not distinguish between successful projects; the full workflow must work. An agent can have accurate customer information while the application responsible for acting on it hides critical rules in legacy code. It can also receive a clean API while underlying data remains inconsistent, allowing action without a trustworthy decision.

Calloway calls this modernizing the parts without modernizing the work. His client example shows why.

Calloway describes an unnamed client that needed faster quoting for complex engine repairs, where contracts dictated whether parts could be repaired, replaced, or refurbished. Each quote took days and sometimes weeks of manual research across contracts and maintenance manuals. The client had modernized its data platform, but research remained the bottleneck.

Calloway says the team rebuilt the workflow around a suite of research agents, cutting research time by 80%. He reports that quotes then moved at a completely different speed. The 80% reduction applies to research time, not the full quote cycle.

The account names no client, quote volume, or calculation method. It therefore illustrates a workflow pattern rather than establishing a broad benchmark.

Calloway rejects planning application and data modernization as independent workstreams. Takeaway: the unit of modernization must be the complete business workflow, not an application, API, or data platform in isolation.

Does an API make a system agent-ready?

The tempting shortcut is to expose endpoints, connect an agent, and declare the system ready. Calloway rejects that shortcut because retrieving information differs from executing an action. Issuing a credit, updating a financial record, or ordering a replacement part requires more than read access.

His proposed answer is the agent control surface, a bounded, governed interface through which agents read from and write to systems of record. APIs and MCP servers can expose tools and data, but MCP does not automatically enforce business rules or decide who may act. Those controls still require engineering in the underlying systems and workflows.

Calloway’s operational checks cover four areas:

• Authoritative data: Confirm that agents can retrieve authoritative records from the system of record.
• Rule consistency: Make business rules explicit and apply them consistently to relevant actions.
• Authority boundaries: Allow agents to recommend actions while restricting execution to what they may perform.
• Audit and recovery: Trace actions, handle exceptions, and reverse operations where possible.

These are not problems a better model will solve alone. They concern workflow, application design, data architecture, integration, and governance, and must be answered together. Takeaway: API access enables an agent’s reach, but governance determines whether its writes are safe.

Where should modernization begin?

Calloway says not to begin by making every application headless or exposing every API. Start with one meaningful business workflow and trace it from beginning to end. The goal is to find the gaps that matter.

Calloway’s trace covers six operational questions:

• Records: Identify every system that holds relevant records.
• Logic: Locate the business rules that govern decisions.
• Trust: Determine which data the agent can rely on.
• Approval: Identify decisions that require human approval.
• Failure: Define what happens if a system fails halfway through.
• Governance: Specify how oversight and controls remain in place.

The gaps become a modernization roadmap: a coordinated backlog across applications, data, integrations, and controls, driven by a business outcome rather than disconnected technology projects. Measure success by reliable workflow completion, exception resolution, and improved business outcomes, not by API count or data migrated.

The goal is not autonomy everywhere. It is dependable, trusted execution, with human judgment where it belongs. Takeaway: measure the whole workflow, then modernize only what blocks a verifiable business result.

What must change beyond headless architecture?

Calloway says the larger aim is not removing dashboards. It is ending the manual work of carrying jobs between disconnected systems. That outcome will not arrive by placing an agent on top of architecture never designed for it.

Calloway writes: “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.” He supplies a design argument, but no reference architecture, implementation benchmark, or broad adoption study.

For enterprises evaluating agentic AI, the next test is not whether an agent can call an API. It is whether one meaningful workflow completes reliably under explicit rules, bounded authority, traceable actions, and human approval where judgment is required.