KIVENTIS · B2B KI-Enablement DACH & APAC
Between an RPA script, a workflow engine and an autonomous agent lie fundamental differences in architecture, operational risk and cost. A technical assessment for IT leadership and managing directors on which ERP-adjacent processes are worth automating agentically today.
An AI agent is not a new model but an architecture built around a language model. Three properties distinguish it from a classical automation script: it receives tools (tool calls) rather than fixed function calls, it maintains state across multiple steps, and it decides for itself which step makes sense next. An agent is given a goal, not a procedure.
That openness is both its strength and its risk. The strength is handling unstructured input: an agent can process a PDF purchase order, an email with an attachment and an ERP record with inconsistent field mapping without a bespoke parser for every variant. The risk is non-determinism: the same input can lead to different step sequences.
For mid-sized companies the decisive question is therefore not whether agents are "better", but whether the process in question remains cleanly describable and monitorable under an outcome-oriented rather than procedure-oriented approach.
Classical workflow engines inside ERP systems (approval processes, document chains, pricing and discount logic in SAP S/4HANA, Microsoft Dynamics 365, proALPHA, abas or Infor) are deterministic, testable and have been in production for years. They are the right answer for clearly rule-based, high-volume tasks.
RPA extends that layer by operating user interfaces that expose no API. The approach is technically robust but maintenance-heavy: any UI change can break scripts, and exceptions typically result in manual rework.
Agents operate one level above. They combine existing APIs, databases and knowledge sources and make intermediate decisions. In practice this is almost never a replacement but an addition: the agent handles case-by-case preparation while the rule-based path stays in the ERP.
Three patterns cover most realistic use cases. First, the agent as recommender: it prepares a decision (such as an account assignment suggestion or an invoice reconciliation) while approval stays with a human in the ERP. Second, the agent as exception handler: it processes cases that stall in the standard flow and documents its reasoning. Third, the agent as a research and reporting layer over internal data, typically as a RAG architecture with a vector index over approved documents.
For tool integration, the Model Context Protocol (MCP) is emerging as an open standard. Its practical benefit in day-to-day projects: integration into line-of-business systems is not rebuilt for every model, and you retain freedom of action when switching models.
For regulated data, the established two-track approach still applies: enterprise models with contractually guaranteed zero data retention, or fully self-hosted on-premise models with a local vector database behind the corporate firewall.
The most expensive part of an agent project is not model integration but defining process boundaries. At minimum, four questions need answers: which systems may the agent write to and which are read-only? Above which threshold is human approval mandatory? How are failures detected and rolled back? And how is every agent step logged so that it can be explained to an auditor?
That last point has a regulatory dimension that is frequently underestimated. Article 4 of Regulation (EU) 2024/1689 has required demonstrable AI literacy among staff since 2 February 2025. A team supervising agentic systems must be able to judge when an agent is plausible and when it is wrong - that is a qualification question, not a purely technical one.
Risk-based classification under Art. 6 is a separate matter but must be factored into process selection: agents in HR (candidate screening, performance monitoring) regularly fall into the high-risk category under Annex III and trigger significantly stricter obligations than agents in accounting or logistics.
A sound assessment compares three quantities. First, the volume of exception cases: as long as exceptions are rare, better rules deliver more than an agent. Second, today’s effort per exception: a case that costs an experienced specialist twenty minutes of research across three systems is a good candidate. Third, change risk: processes whose interfaces change frequently make an agent solution disproportionately expensive.
A pragmatic entry point has proven effective: scope the agent initially to clarification and research tasks only. That delivers value quickly without risking write access to core systems, and it establishes the logging routine that later write scenarios require anyway.
Anyone who runs this assessment against their own process data typically arrives at a small number of viable candidates rather than a company-wide rollout - and that is precisely the difference between a defensible business case and a technology demo.