Executive Summary
An application is ready for AI agents when it spells out five things a machine can’t guess: what actions exist, what rules apply, who is allowed to act, where each task stands, and how to prove the task is done. Connecting an agent to it isn’t the same as being ready for one.
Companies are rolling out AI agents faster than their applications can safely support them. This article explains what to change in your applications, and in what order, so agents can do real work while your core systems stay in charge.
- Your core systems stay in charge. Modernizing for agents adds a controlled action layer around your ERP, CRM, and other systems of record. It replaces nothing.
- Agent-ready applications share five properties. Explicit, permissioned, stateful, rule-enforced at execution, and verifiable.
- The AI never enforces the rules. Agents plan within your policies. Your application decides, commits, and checks the result.
- Start with one workflow, not the whole estate. Let the agent watch, then recommend, then take small, reversible actions. Widen its freedom only as measured intervention and failure rates fall.
Most enterprise applications were built for a person to operate. Screens, forms, and reports assume someone will read the data, decide what to do, and click to make it happen.
AI agents work differently. They need to call actions directly: place an order, update a record, finish a multi-step process, and confirm it worked, without a person driving every click.
Large companies are moving fast. McKinsey’s State of AI in 2026 survey finds that 40% of respondents at companies with more than $1 billion in revenue report scaling AI agents in at least one function, up from 27% a year earlier. The value is not keeping pace. Across the full survey, 37% of respondents attribute any EBIT impact to AI, essentially unchanged from a year earlier.
The Business Problem
An agent pilot only has to prove the AI can make a good decision. Production asks far more of your applications. They have to accept that decision as real work: check it against your rules, carry it out, track it for days if needed, and prove it happened.
Most legacy applications can’t do that:
- Their rules are hidden in screens, old code, and spreadsheets.
- Their workflows depend on people remembering what comes next.
- Their core systems were never designed to take instructions from software.
So agents get stuck. They recommend but can’t act, or they act through fragile workarounds nobody can audit.
Modernizing for agents fixes this. It turns hidden, people-dependent workflows into clearly defined actions that software can run, pause, resume, and check. Your systems of record stay exactly what they are: the official source of business data. The agent never becomes the system. The principle is simple:
The model proposes. Deterministic services authorize, execute, record, and verify.
The rest of this article covers what to change in your applications to make that possible, and the order to make the changes.
Why Legacy Applications Stall AI Agents
Your ERP, CRM, core banking, and inventory platforms do exactly what they were built to do: store the official record and keep transactions consistent. Nothing here argues for replacing them. But they were never built for software that plans and acts on its own.
Connect an agent to an unmodernized estate, and it hits the same four walls every time:
- Built for screens, not software. The agent is left scraping web pages or reading batch exports. A decade of screen-driving bots has already taught this lesson: automation built on screens made for people breaks easily.
- Hidden business rules. The rules that make a process correct live in old code, approval chains, spreadsheets, and the heads of long-serving staff. The agent can’t follow rules nobody wrote down, so it breaks them.
- No definition of the job. Nothing tells the agent what an action needs, what it changes, what can go wrong, or what “done” looks like. Without that, it guesses.
- Data without context. A record tells the agent what is true, not what is allowed. Without the rules and the history behind the data, the agent fills the gaps with assumptions, and assumptions fail on exceptions.
The result is familiar. Either the agent stays a read-only assistant that stops at suggestions, or the team wires up one-off scripts that nobody governs and everybody has to reconcile by hand.
What Agent-ready Looks Like
An agent-ready application layer, which we call a system of action, is more than something an agent can connect to. It has five properties:
- Explicit. Every business action has a clear name and limits, such as “submit purchase order” or “escalate claim.” Agents never get raw database access or a generic admin login.
- Permissioned. Each action checks who is asking, which agent is acting, why, and on which transaction. No shared login with permanent access.
- Stateful. Work that takes days, such as waiting for an approval, can pause, resume, fail partway, and recover. The application tracks where things stand, not the AI.
- Rule-enforced at execution. The agent asks. Your application’s own rule-based services decide and commit. No AI model writes directly to your ledger.
- Verifiable. The system can prove which agent acted, for whom, under which policy, and whether the intended business result actually happened.
| System of record | System of action | |
|---|---|---|
| Its job | Holds the official business data | Offers controlled actions that change that data |
| Examples | ERP, CRM, core banking, inventory | Named actions, policy checks, approval routing, workflow tracking, outcome checks |
| What changes it | Transactions entered through screens and integrations | Agents and people, through governed actions only |
| Replaced? | No | It is an addition, not a replacement |
One Workflow, Before and After
Take a workflow every distributor and manufacturer runs: a purchase order that hits an exception, such as a new supplier or an over-budget line.
Today, a coordinator chases the answer across email, the ERP, a finance spreadsheet, a policy document, and a chat thread. The cost shows up in four places:
- Slow. Every step waits on a person knowing where to look.
- Inconsistent. Two coordinators read the same approval threshold two different ways.
- Unprovable. Sign-off is a thumbs-up in chat, attached to no record.
- Error-prone. The budget on screen and the budget in finance already disagree, and nobody checks the goods receipt until days later.
In the modernized version, the agent pulls the supplier and budget from the official systems. A policy check flags the exception, and the right manager receives it with the evidence attached. Once approved, the order posts to the ERP and the system confirms it landed correctly. When the goods arrive days later, the workflow resumes, matches the receipt to the order, and either closes it or flags the mismatch.
What the business gets:
- Exceptions routed to the right approver automatically, with the evidence attached.
- The same policy applied the same way every time.
- A complete record of who asked, which rule allowed it, what changed, and what was confirmed.
- People followed the policy exactly where it says they should be, and nowhere else.
Same ERP. Same policy. What changed is that the rules, actions, status, and checks became clear enough for a machine to follow safely.
What this means for your business: the modernization target is not a bigger AI budget. It is a workflow whose rules, approvals, and outcomes exist somewhere a machine can read, follow, and prove.
Six Moves To Make Your Applications Agent-Ready
Getting from the first version of that workflow to the second is application modernization work. It breaks into six moves.
| Move | What it fixes | Business result |
|---|---|---|
| 1. Separate business actions from screens | Agents driving screens | Actions that run reliably |
| 2. Write down the hidden rules | Rules buried in code and people | Consistent policy, fewer errors |
| 3. Define every action | No definition of "done" | Bad requests stopped, good ones confirmed |
| 4. Track workflow status in the application | Work lost mid-process | Long-running work that survives failures |
| 5. Control access to core systems | Unchecked agent access | Autonomy where it is safe, approval where it is not |
| 6. Verify every outcome | "Done" on the agent's word | An audit trail, not a liability |
1. Separate Business Actions From Screens
The problem: In most legacy applications, the only way to do something is through a screen. Agents forced to drive screens break whenever the screen changes.
What needs to change: Pull the actions behind those screens into services an agent can call by name, such as “create purchase order” or “approve claim.” Agents need actions, not just data access.
Why it matters to the business: If an action only exists as a screen or a database table, there is nothing you can govern. Named actions are what you can secure, audit, and trust.
2. Write Down the Hidden Rules
The problem: The rules that decide whether an action is valid sit in old code, spreadsheets, approval chains, and tribal knowledge.
What needs to change: Move those rules into rule-based policy services, or wrap the existing rule behind one where moving it is not yet safe. The services enforce the rules. The agent receives them as context so it can plan within them, but it never decides whether a rule is satisfied.
Why it matters to the business: This step uncovers the undocumented approvals and exceptions your teams work around today. Surfacing them is half the value of the exercise, with or without an agent.
3. Define Every Action
The problem: Nothing tells the agent what an action requires, what it changes, what can go wrong, or what “done” means.
What needs to change: Give every action a short specification, an action contract: required inputs, preconditions, who can authorize it, what it changes, how it can fail, whether it can be undone, and what result proves it succeeded.
Why it matters to the business: The contract lets your systems reject a bad request before it runs and confirm a good one after. An action without a defined success condition is an action you cannot trust an agent with.
4. Track Workflow Status In the Application, Not the AI
The problem: A supplier onboarding that waits three days for a compliance approval cannot live in an AI model’s short-term memory. When the model restarts or is swapped out, the work is lost.
What needs to change: Store the status of each workflow, including completed steps, pending approvals, and deadlines, in the application itself, with one clear owner: a workflow engine or a business service. Record common exceptions, such as a missing field, a denied policy, or an escalation, as clear statuses rather than vague errors, so the agent knows whether to ask a person, fetch more information, or stop. Agents can hand work to each other. They should never be the ones holding the official status of a transaction.
Why it matters to the business: Long-running work survives outages, restarts, and model changes, and nothing falls through the cracks between steps.
5. Control Access to Your Core Systems
The problem: Giving an agent direct access to your ERP or core banking system turns a model’s bad guess into a bad transaction.
What needs to change: Put a controlled layer between agents and your core systems, with one checkpoint for every request. Standards such as the Model Context Protocol (MCP) make tools easier to connect, but they don’t supply your business rules or approval policy. That control model is yours to design. Within it:
- Give agents broad read access for context and narrow write access for changes.
- Let low-risk actions run on their own. Require human approval for high-impact or irreversible ones.
- Give each agent its own identity, not a shared service account, and record which user it is acting for.
Why it matters to the business: You get speed where the risk is low and human control where the stakes are high. Every transaction shows which agent acted, for which user, under which rule.
6. Verify Every Outcome
The problem: An agent reporting “done” is not proof the work is done.
What needs to change: Design actions so a retry never causes a duplicate. After every action, check the result, record it, and keep the full chain: who asked, which policy allowed it, what changed, and what was confirmed.
Why it matters to the business: This record is what turns agent activity from a compliance liability into an audit trail.
What It Costs To Skip The Groundwork
Teams that connect agents before modernizing run into four predictable problems:
- No evidence chain. Logs may show that a call happened, but not who requested it, what authority allowed it, what changed, or whether the intended result was reached. That is exactly what an auditor or regulator will ask for.
- Tool sprawl. One-off connections between agents and systems become the next generation of integration debt: duplicated rules, inconsistent controls, and nothing stable to modernize behind.
- Over-autonomy. Unchecked writes to a core ERP turn a model’s bad guess into a financial error or corrupted data, discovered at month-end.
- Context gaps. When the agent never sees the policy, it submits invalid requests, hits avoidable denials, and escalates work it should have handled. If your systems don’t enforce the same rules, those bad requests can become unauthorized actions.
Our Recommendation: Modernize One Workflow, Not the Whole Estate
None of this requires a rewrite. Treating it as one is how modernization programs die. The sequence we recommend is deliberately narrow:
- Pick one high-friction workflow where manual coordination visibly costs you.
- Give its workflow status one clear owner.
- Put controlled actions in front of the systems that workflow touches.
- Extract only the rules that workflow needs, and instrument it.
- Run the agent in observation mode, then recommendation mode.
- Enable narrow, reversible actions under tight authority.
- Widen autonomy as intervention and failure rates fall, and modernize the legacy components behind the same stable contracts as you go.
Each pass through that loop leaves the estate more agent-capable and less legacy-bound than the one before. The fastest route to agentic value is rarely replacing a core platform, and it is never wiring an agent into everything at once. It is one valuable workflow, modernized until every action in it is explicit, governed, recoverable, and verifiable.
What To Do Next
Better models and bigger AI budgets don’t get an agent from pilot to production. The application layer does, one workflow at a time.
Start with the workflow where manual coordination costs you the most, and test it against the five properties:
- Are its actions named?
- Are its permissions specific to each user and agent?
- Is its status tracked by the application?
- Do your systems enforce its rules?
- Can it prove each outcome?
Every “no” points to one of the six moves above, and together those answers become your modernization backlog. Work through that backlog, and agent pilots start doing real, governed work inside the business.
FAQs
No. Systems of record stay the official source of business data. Modernizing for agents adds a controlled action layer around them: clearly defined actions, enforced policy, tracked workflow status, and verified outcomes. The core’s role as the source of truth does not change.
No. MCP standardizes how agents find and connect to tools. It does not enforce business rules, approval policies, or transaction safety. You still need to move hidden logic into clear, rule-based services that an MCP connection can then safely expose to agents.
No. Work one workflow at a time: put controlled actions in front of the systems that workflow touches, extract or wrap only the rules it needs, and modernize legacy components behind those stable actions over time. A full rewrite is neither required nor advisable.
Nothing that changes data. Run it in observation mode, then let it recommend, then enable narrow, reversible, low-risk actions, with high-impact transactions gated behind human approval. Widen autonomy only as measured intervention and failure rates fall.
Find Where Your Platform will Block Production
The assessment scores visibility, data foundation, application readiness, and agentic capability, and shows which technical constraints are most likely to stop an AI system from scaling.
