Your finance team deploys an AI agent to help close the monthly books. The agent reads invoices, matches them to purchase orders, and flags mismatches. So far, so good. Then it needs to check whether the goods receipt has been posted, whether the vendor is still active, or whether the invoice has entered a dispute workflow. Suddenly, the agent stalls.
This isn't a story about a weak AI model. It's a story about architecture.
ERP, CRM, HRIS, and other core systems are not just big databases you can query at will. They are the official record of business state — orders, invoices, customer data, employee status — all validated and controlled. Agents cannot operate well without understanding that state. But most enterprises discover their core systems were built for standardization and transaction control, not for dynamic, semi-autonomous interaction.
The result? Promising agent pilots hit a wall. CIOs see an architecture problem. COOs see a process design problem. CFOs and CHROs see a control and accountability problem. Everyone is right.
The practical path from read-only insight to bounded action in enterprise core systems.
The Real Bottleneck Isn't the AI
Before you blame the model, look at what happens when an agent tries to do real work.
Real-time access is often unavailable. Many systems still rely on batch processing or slow point-to-point integrations. APIs may exist, but they were designed for structured, human-driven applications — not for agents that need to call multiple endpoints in sequence, pause for policy validation, or resume after approval.
Access control is another hidden trap. Core systems define permissions for human roles, not for digital workers with narrow, specific scopes. Companies end up either giving agents too much access or none at all.
Then there's the semantic layer. Real business rules don't live only in ERP or CRM. They live in spreadsheets, local SOPs, emails, knowledge bases, and undocumented operational habits. An agent connected only to the core system will constantly misinterpret context.
The mistake is assuming the systems are ready. They almost never are.
The Only Maturity Model You Need: Read, Recommend, Act
The most common error is rushing to let agents execute transactions directly. A far healthier approach is staged. The Read, Recommend, Act model isn't just a technical roadmap — it's a way to manage risk, build trust, and mature your operating model.
Stage 1: Read — Understand without touching
Start with read-only access. The agent's job is to understand transaction context, detect exceptions, summarize status, and provide insights or priorities. This stage delivers value quickly because the risk is low.
Finance teams can use agents to read ledger data, reconciliation status, and exception history to flag accounts at risk of a late close. Procurement agents can read intake requests, vendor status, contracts, and purchase history to guide requesters toward the right purchasing path. Customer operations can prepare case summaries before a human agent picks up the call. HR can send proactive notifications about stalled onboarding.
The business value comes from reduced data search time, prioritized exceptions, and fewer manual handoffs. But read-only alone won't transform your cost structure. Humans still need to move decisions into systems, create transactions, send follow-ups, and close loops.
Stage 2: Recommend — Prepare, then get approval
Now the agent doesn't just read. It drafts transactions, creates workflow requests, composes action recommendations, or triggers next steps — all requiring human approval. This is often the sweet spot for enterprise functions.
In accounts payable, an agent detects an invoice mismatch, prepares a root-cause analysis, and drafts a resolution case for review. In sales, it prepares next-best actions for account managers or drafts opportunity updates. In HRIS, it drafts employee data changes but leaves approval to HR or the line manager. In IT operations, it gathers telemetry, suggests root causes, and prepares runbook actions — but the engineer still approves remediation.
Humans retain the control point. Recommendation quality can be evaluated. The organization learns where the agent truly helps versus where it still gets things wrong.
Beware: if approval workflows are poorly designed, you've simply moved the bottleneck from finding data to approving agent drafts. Approvals must be disciplined — only for actions that genuinely need them, with sufficient context and clear SLAs.
Stage 3: Act — Bounded autonomy
The most mature stage is when agents can act directly in core systems. The keyword is bounded. Not free-for-all transaction creation, but limited autonomy:
- Specific scenarios and clear policies
- Defined thresholds and limits
- Full logging and audit trails
- Rollback or compensating actions
- Kill switches if behavior drifts
Customer service agents might update ticket status, send standard communications, or process non-material order changes that meet policy. Collections agents might send automated follow-ups or create promise-to-pay reminders. IT operations agents might run low-risk remediation like restarting a specific service. Procurement agents might draft purchase orders for highly standardized categories.
Do not force Stage 3 for domains involving material financial control, high legal or regulatory impact, unstable data, or unclear rollback mechanisms. Material journal postings, sensitive vendor master changes, employee compensation decisions, credit approvals, and high-value customer policy changes should keep a human in the loop for much longer.
Don't Wait for Your Agent to Be Asked
Most early agent implementations are passive — they only work when someone asks a question or pushes a button. That's fine for a copilot. But for an agentic operating model, the more powerful pattern is agents that respond to business changes as they happen.
Agents work far better when they receive signals: order changed, ticket escalated, invoice overdue, payment failed, inventory exception, employee onboarding delayed, shipment at risk. With events like these, agents don't need to poll systems constantly or wait for humans to notice a problem.
Two patterns matter here:
- Event bus: Enterprise systems publish operational events to a shared platform, and agents subscribe to what's relevant.
- Change Data Capture (CDC): Captures changes in transaction data when native events aren't available.
Event-driven design also improves observability. Every trigger, decision, and action becomes a traceable chain of events: event occurs, agent is triggered, additional data is fetched, policy is checked, action is taken or escalated. For operations, risk, and audit teams, this is far healthier than agents working silently in the background.
Start Before Your Systems Are Perfect
One reason companies move slowly is the assumption that all core systems must be modernized before agents can be used. That's unrealistic. The better approach is selective modernization based on what your priority use cases actually need.
For legacy systems that are hard to touch, build an API facade or service layer in front of them. This simplifies complexity, normalizes schemas, limits what agents can do, and avoids dependence on screen scraping or direct database access. Agents should never depend on clicking through UIs, querying core tables directly, or relying on hidden logic that only a few people understand.
The API facade also helps governance: you can decide that agents may only interact through validated, policy-enforced, fully logged services that can be turned off if needed.
What This Means in Practice
Connecting agents to core systems is not a middleware project. Once agents touch ERP, CRM, or HRIS, governance implications surface immediately.
- Every connection needs a business owner and a technical owner.
- The boundaries between Read, Recommend, and Act must be formal — don't let each team decide autonomy levels independently.
- Audit trails must span systems.
- Workforce impact must be considered from the start: when agents read and act in core systems, human work shifts from data entry and status-chasing to exception handling, approvals, and policy improvement.
For the CIO: Is your digital core ready to be an agent execution platform, or is it still just a hard-to-access record-keeping system?
For the COO: In which processes is the real bottleneck not people, but delayed access to business state from core systems?
For the CHRO: If agents start reading and triggering workflows in HRIS, which roles will shift from administration to oversight and exception management?
For the transformation leader: Does your roadmap start with high-value use cases and realistic integration capabilities, or are you stuck between impressive AI demos and core systems that aren't ready to be touched?
If the answers are still unclear, your next priority isn't adding more agents. It's clarifying the safe path between agents and your core systems. That's where the agentic enterprise truly begins.
This article was originally published on ariefwara.github.io.
Top comments (0)