A student asks why a tuition adjustment hasn't appeared on their account. The answer might require someone to check the student information system, read a policy document, review a case in the service platform, confirm a finance transaction and then explain what happened.
Each application may be functioning exactly as designed. Yet the employee still has to reconstruct one business process from five separate places.
That distinction matters. We have spent years modernizing the systems that hold organizational information. We have spent less time designing the work that crosses their boundaries.
When leaders describe an ERP or student information system as frustrating, they're often describing something adjacent to it: rekeying information, chasing approvals, reconciling records, interpreting correspondence and working out which department owns the next step.
Sometimes the best transformation opportunity isn't a new core system. It's a better way to complete the work around the one you have.
Systems of record are not systems of work
An ERP is expected to protect financial integrity, enforce transactions and retain authoritative records. A student information system does the equivalent for academic and enrollment information. Those are valuable responsibilities. They should not be casually replaced with a language model.
But a business process rarely respects application boundaries. A single request can begin in email, depend on a document, require information from several platforms, and finish with a decision made by a person.
The missing architecture is often the coordination between those steps.
Today, a capable employee supplies that coordination personally. They know where to look, which policy matters, who can authorize an exception and how to avoid changing the wrong record. That's expertise, but it's also a fragile operating design: important institutional knowledge exists in people's heads and in unofficial instructions.
The opportunity is to make the coordination explicit, reusable and observable.
Consider one request, not one application
Imagine a university handling a student's request to review a tuition charge. This is an illustrative workflow, not a client implementation or claimed result.
The initial message arrives in an inbox. Staff identify the student, retrieve enrollment and billing information, locate the relevant policy, check earlier correspondence and decide whether the case is routine or needs specialist review. An authorized employee may then approve an adjustment. Finance records the transaction; student services communicates the outcome.
A conventional modernization project might ask which application should be replaced. A workflow-first project asks why the request requires so many manual handoffs in the first place.
With a properly designed coordination layer, the request could enter a tracked queue. Approved integrations retrieve the relevant records. AI helps interpret the student's free-text explanation and summarize the case against the available documents. Business rules check objective conditions. Any uncertainty, dispute or discretionary adjustment goes to the appropriate employee. Only after authorization does a controlled integration update the system of record.
That sequence isn't a promise of fully automated tuition decisions. It is a way to remove avoidable clerical movement while protecting the decisions that deserve human judgment.
The original systems still do what they were built to do.
What an intelligent coordination layer actually means
This shouldn't become another vague platform diagram with an AI box in the middle. A useful design has distinct parts and responsibilities.
Connections. Approved APIs—interfaces that allow software systems to exchange information—retrieve and update records within existing permissions. Where reliable APIs are unavailable, integration limitations need to be treated as a real constraint, not hidden behind an impressive demonstration.
Workflow control. A workflow engine tracks each request, its current state, the next permitted step, deadlines, retries and exceptions. It answers a basic operational question: What happens next, and who owns it?
Interpretation. AI can help with information that isn't neatly structured: incoming messages, attachments, descriptions and policy passages. It can classify a request, extract details, prepare a summary or draft a response. Those outputs remain subject to validation.
Rules and authority. Eligibility calculations, spending limits, record updates and permissions belong in conventional software and authorized human decisions. A language model should not invent policy or grant itself access to a transaction.
Observation. The organization needs a trace of what was received, retrieved, proposed, approved and changed. It also needs to know when a case stalled or required correction, without retaining sensitive information unnecessarily.
The architecture is not “put an agent on the ERP.” It is give the work a reliable path across systems, and use AI only where interpretation adds value.
Microsoft's published agent orchestration guidance makes a related engineering distinction: workflows should not use nondeterministic AI behavior for tasks that are inherently deterministic, and sensitive operations may require explicit human approval. That is a design principle, not a product endorsement. Source: Microsoft Azure Architecture Center.
Stop treating every handoff as an AI problem
This is where executive discipline matters.
If two databases can be synchronized through a reliable integration, use the integration. If eligibility is determined by a fixed rule, encode and test the rule. If a person must exercise discretion, give that person the right context and authority.
AI earns its place when the work requires understanding varied language, finding relevant material, or preparing a case from messy information. It doesn't earn its place because the organization wants more agents.
An effective system may contain relatively little AI. That can be a sign of good architecture rather than limited ambition.
There are risks to manage. A model can misread a document, provide an unsupported interpretation or be manipulated by instructions embedded in material it processes. Access controls, validation, review and monitoring therefore belong in the workflow itself. NIST's Generative AI Profile provides a useful voluntary risk-management reference for that work.
Sometimes the ERP really is the problem
The title is a challenge to a common assumption, not a universal rule.
An unsupported platform with serious security weaknesses, unreliable transactions, inaccessible data or an inflexible model of the business may genuinely need modernization or replacement. Building a sophisticated coordination layer around those defects could increase complexity and preserve problems that should be fixed.
The U.S. Government Accountability Office documented critical federal legacy systems requiring modernization in its July 2025 review. Its findings are a reminder that older core technology can carry material operational and security risks; integration is not always a substitute for renewal. Source: GAO-25-107795.
The executive decision is therefore diagnostic: Is the failure inside a system, between systems, or in the business process itself?
If the core application cannot reliably perform its required transactions, address the core. If records are sound but employees must move information manually between applications, investigate integration and coordination. If policy, ownership and approvals are unclear, redesign the process before automating it.
These causes can coexist. A serious architecture review should be willing to recommend more than one kind of change.
Start with the work that crosses boundaries
Rather than commission an enterprise-wide “AI layer,” select one recurring service that spans multiple systems and has a clear operational owner.
Map it from the original request to the final recorded outcome. Count actual handoffs, repeated data entry, exception paths and corrections. Document the systems that own each record and the people who own consequential decisions. Then test the smallest end-to-end improvement that can be supported safely.
Measure the complete service, not just the speed of the AI step: turnaround time, rework, error correction, escalation, employee effort and the quality of the outcome. Include implementation and ongoing operating costs. If the new design moves the delay elsewhere, it hasn't solved the problem.
Most importantly, resist the temptation to make the new layer another opaque system nobody can maintain. Its rules, integrations, ownership and failure handling must remain understandable after the demonstration team leaves.
The next modernization conversation
CIOs don't need to choose between replacing everything and tolerating the status quo. There's a third conversation worth having: What would this organization be capable of if its existing systems worked together as one coherent process?
That question connects enterprise architecture to the experience of employees, students, citizens and customers. It respects the investment already made without treating that investment as untouchable.
Core systems keep the authoritative record. Well-designed workflows move the work. AI helps where meaning and variation make that work difficult to automate conventionally. People remain accountable for the decisions that matter.
The goal isn't to make the ERP intelligent. It's to make the organization more capable.