This article is a translation of the original Polish text.
Over the past thirty years, implementing an ERP system meant, in practice, digitizing work performed by people: training on the procurement module, instructions for approving documents, dozens of mandatory fields, and the ritual of month-end close. Today another stage is beginning — ERP agentization, meaning handing AI agents clearly defined goals, tools and responsibility for executing processes.
That earlier era is now coming to an end, for three independent reasons at once. First, inputs are no longer paper: the mandatory National e-Invoicing System means an invoice arrives at a company as a structured file. Second, outputs have long been digital — tax reporting in Poland consists of JPK files submitted electronically. Third, a standard has emerged that lets an AI agent talk to a business system without clicking through a screen: the Model Context Protocol (MCP).
If the input is digital, the output is digital, and the middle can be handled programmatically, then an ERP system can become an environment where multiple specialized agents collaborate. The question is no longer "can an agent help the user," but which processes it can run independently, within what boundaries, and under what oversight.
1. Why now — and why this is personal for me
I encountered ERP systems long before banking. At the start of 2001 I took part in building Gecos, a company whose goal was to transform and digitize SMEs in the Łódź region by implementing ERP systems. We were in a world where the biggest challenge of an implementation project was convincing the owner of a trading or manufacturing company that it was worth entering warehouse documents into a computer instead of keeping a notebook.
Today Gecos is a reputable provider of comprehensive ERP solutions for companies across various industries (gecos.pl), and among the topics its clients care about most is preparing their ERP system for KSeF (gecos.pl). I'm proud to have taken part in building a company that has travelled this entire road — from computerizing records to becoming a partner in document-flow digitization.
This twenty-five-year perspective matters for this article, because it reveals a recurring pattern: every wave of digitization first supports a human with a tool, and then hands the machine an ever-larger share of the process. Banking went through a similar path — from a branch with a computer, through a mobile app, to processes launched automatically and handled by a human only when an exception arises. ERP is now entering the agentization stage.
2. Inputs: KSeF turns an invoice into a record
The National e-Invoicing System is an IT system for issuing, sending and storing structured invoices (Ministry of Finance, ksef.podatki.gov.pl). For the discussion of AI agents, one technical detail matters — a detail usually lost in KSeF communications behind talk of deadlines: a structured invoice is not a document that needs to be read — it is a record that only needs to be accepted.
What disappears from the process once an invoice is structured
- Scanning and OCR — the entire image-recognition layer, along with its errors and correction cost, is no longer needed.
- Manual line-item entry — counterparty data, amounts, rates and line items arrive in fields with a defined meaning.
- Disputes over document versions — there is one invoice in one repository, with an unambiguous identification number.
- The risk of an "invoice in a drawer" — the document is available immediately upon issue, not once delivered by mail.
The consequence runs deeper than it appears. Until now, the first step of the purchasing process was understanding the document — an inherently human activity. After KSeF, the first step is validating the record — an inherently machine activity. From a process-design perspective, this is not an improvement. It is a total change.
3. Outputs: reporting that was already machine-based
The other side of the flow has been digitized for years, and we have grown so used to it that we no longer notice how radical the change is. VAT declarations and records are submitted as JPK_VAT files with a declaration, and further JPK structures cover accounting books and other reporting areas. A company doesn't "fill in a form" — a company generates a file from data it already holds.
This means that in a typical Polish company we already have a closed loop today:
A fully digital data flow within a company
- External input — purchase and sales invoices in the structured KSeF format, bank statements in exchange formats, customer orders via EDI, API or e-commerce.
- Internal processing — the ERP core: orders, warehouse, production, payables, costs, HR. All in a relational database, in tables with a known schema.
- External output — JPK files and declarations to the tax administration, transfers to the bank, confirmations and invoices to counterparties, reports to the owner or the group.
Every element of this loop is machine-based. The only element that isn't machine-based is the person sitting in the middle, copying data from one screen to another. That is precisely the element that is changing — and AI agents are the ones changing it.
4. MCP: the missing link between the agent and the system
Over the past two years, the problem with AI agents in a corporate environment has not been model intelligence. It has been access. A model could reason about a purchase order, but had no way to see it in the system, let alone create one.
The Model Context Protocol is an open standard for connecting AI applications with external systems — data sources, tools and workflows (modelcontextprotocol.io). Anthropic released it as an open standard in November 2024, with the goal of connecting AI assistants to the systems where a company's data lives (Anthropic, 25 Nov 2024). The key difference from the previous approach is spelled out explicitly: connecting agents to tools and data traditionally required a dedicated integration for every system–agent pair (Anthropic Engineering, 04 Nov 2025).
Why does this matter specifically for ERP? Because previous attempts at ERP automation followed two paths, and both had a structural flaw.
Three generations of ERP automation
- Point-to-point integration — solid and fast, but every new scenario is a new IT project. The cost of change grows faster than the value.
- RPA at the GUI layer — a robot clicks the screen like a human. Deployable without the system vendor's consent, but brittle: a change in window layout breaks the process, and the robot doesn't understand context — it only replays a sequence.
- Agent via MCP — the system exposes a set of operations with clearly described meaning and permissions, and the agent decides for itself which to use to achieve the goal. The screen stops being the access channel.
I lived through the full cycle of RPA enthusiasm in banking, and I know where its value ends: a robot scales work, but it does not scale the decisions that need to be made. An agent with protocol-based access is a different class of tool — it does not replay steps, it pursues a goal that is described within the agent's scope of work and the precision of its competency description. A good comparison, from the perspective of a process owner, is the difference between a seasonal worker who must be shown every action and an analyst who only needs the outcome and the boundaries defined.
5. The target vision: an ERP managed by specialized agents
Here I move from facts to a thesis — and I want to flag this clearly: the vision below is my opinion, not an announcement from any software vendor. However, I believe it is the most likely direction for the coming decade.
In the target model, the ERP system becomes a platform on which specialized AI agents operate: procurement, warehouse, payables, tax and control. Each is given a separate goal, a scope of data, a set of permitted operations, and decision limits. The human remains the process owner: setting goals, approving exceptions, and being accountable for outcomes.
Shifting roles: who handles ERP today, and who will in the future
- Registering a purchase invoice — today: an accounting clerk in the payables module. In the future: a payables agent pulls the document from KSeF, matches it to the order and the goods receipt, and posts it; the human sees only mismatches.
- Ordering from a supplier — today: a procurement specialist analyzes an inventory report and issues an order. In the future: a procurement agent computes demand forecast and lead time and places an order within a limit; the human approves limit overruns and supplier changes.
- Stocktaking and inventory adjustments — today: periodic counts and manual reconciliation of discrepancies. In the future: a warehouse agent monitors discrepancies continuously and flags anomalies as they arise.
- Tax reporting — today: preparing the file, checking it, submitting it, archiving it. In the future: a tax agent runs consistency checks throughout the month, and closing the period is a confirmation, not a project.
- Internal control — today: after-the-fact sampling. In the future: a control agent operates on the full population of documents in real time, and its role is to challenge the decisions of the other agents.
The last point deserves attention, because it is the most often overlooked in automation discussions. An agent architecture needs an agent whose only job is to disagree. The banking analogy is direct: we never built a credit-decision engine without an independent risk-control layer. A procurement agent optimizing for stock availability will systematically over-order if no one holds it accountable for working capital.
A side effect: less work inside the ERP interface
Reducing the role of the GUI is not the goal of agentization, but its consequence. If agents perform the greater share of the work, the graphical interface increasingly serves as a supervision panel: it shows the queue of exceptions requiring a human decision, goals and limits, a log of agent actions, and results. Forms may still exist as a manual, fallback mode, but they stop organizing the main flow of work.
The most important change in business-software design, then, will not be the absence of screens, but a new way of exposing the system's capabilities. An ERP vendor stops competing solely on the number of features in the menu and starts competing on the quality of how it describes its operations for an agent — that is, how precisely it defines what a given operation does, its accounting effects, and when it must not be performed.
6. Orders and inventory: where value will appear fastest
The nearest money lies in procurement and inventory management, because this is an area where decisions are frequent, repeatable and measurable, and historical data is complete.
This is not a hypothesis — the market already offers ready-made models. C3 AI offers an inventory-optimization application that uses machine learning and optimization algorithms to reduce excess inventory while maintaining safety stock sufficient to cover demand (C3 AI documentation). In a deployment described by the vendor at a global manufacturer of welding equipment, the potential inventory reduction is stated at around 26%, with savings measured in tens of millions of dollars globally (C3 AI, deployment description). This is vendor-communicated data and should be treated as such — but the order of magnitude matches what I have observed in optimization projects in other industries.
What matters is how such an application works: the system generates recommendations, and a manager accepts or rejects them, prioritizing the critical ones (C3 AI Inventory Optimization). This is exactly the transitional model I describe below in the roadmap: first the agent proposes and the human decides; only once trust has been built does the agent decide and the human oversee exceptions.
Why an agent does this better than a report
- Frequency — a human reviews inventory once a week; an agent does so after every warehouse event.
- Breadth — a human tracks a few dozen key SKUs; an agent covers the full assortment, including the "long tail" where working capital usually gets frozen.
- External context — an agent can factor in lead times drawn from a specific supplier's history, seasonality, and signals from customer orders in a single calculation.
- Consistency — the decision doesn't depend on who happens to be at work and how much time they have before month-end close.
7. Risks that need to be stated out loud
I would be dishonest in my assessment if I presented this vision without boundary conditions — especially since we are talking about a system that records economic events with tax consequences.
Six conditions without which this won't work
- Agent permissions — an agent must have its own identity in the system, its own scope of permissions, and its own value limits. Working "under the administrator account" is disqualifying.
- Segregation of duties — an agent that creates an order cannot approve the payment for it. Classic internal-control rules apply to agents exactly as they apply to humans.
- Audit trail — every operation must record which agent performed it, on what basis and for what purpose, in a form understandable to an auditor, not just to an engineer.
- Accountability — responsibility for a wrong decision remains with management. Automation transfers the work; it does not transfer the accountability.
- Data quality — an agent operating on a neglected master-data catalogue will make wrong decisions faster and more consistently than a human would. Clean master data is a precondition, not a byproduct.
- Fallback mode — there must be a way to stop all agents with a single command and take over the process manually. A company must not lose the ability to operate without the model.
I would add one more risk that, in the Polish reality, is practical rather than theoretical: loss of competence. If an agent runs payables for two years, the accounting team stops knowing what the process looks like without it. That is why periodic "manual drills" and maintaining process documentation are not bureaucracy — they are an insurance policy.
8. A 12–24 month roadmap
For a company that wants to prepare for this without turning its operations upside down, sequencing matters more than pace.
Four stages
- Stage 1: cleaning up data (0–6 months) — counterparty and SKU master records, uniform units of measure, complete lead-time data, cleared historical open documents. This is the least glamorous and the most important stage.
- Stage 2: full support for the digital flow (0–9 months) — treating KSeF not as a box-ticking obligation but as a process change: automatic matching of an invoice to the order and the goods receipt, with no intermediate manual step.
- Stage 3: agents in proposal mode (6–15 months) — the agent calculates, recommends and justifies; the human approves. We measure two things: the share of recommendations accepted unchanged, and the financial impact of the decisions.
- Stage 4: autonomy in narrow areas (12–24 months) — wherever the recommendation-acceptance rate is high, the agent acts independently within a limit, and the human handles exceptions. The scope of autonomy is expanded based on data, not on a vendor's claims.
A practical tip from the implementations I have led: don't start with the most expensive process — start with the best-measured one. Automating an area where you cannot prove the effect ends up in a dispute over whether anything improved at all — and such a dispute kills a transformation program faster than a technical failure.
Summary
Digitizing invoices and tax reporting in Poland has done something no internal project ever could: it forced the entire market to move to machine-readable data on both sides of the flow. Inputs are structured, outputs are files, and internal data has always lived in a database. This has created the infrastructure on which AI agents can operate without a human intermediary — and MCP has provided the standard way to connect them to systems.
In this world, the advantage will be built not by the companies that buy the most AI licenses, but by those that clean up their data, describe their processes in a way a machine can understand, and define the boundaries of autonomy before chance does it for them. A diminished role for the ERP interface will be one consequence of this shift, but its essence will remain the transition from a tool operated step by step to a system in which agents pursue goals independently, under human oversight.
A quarter of a century ago we were persuading entrepreneurs in the Łódź region that it was worth entering their data into a system. Today the conversation is about who should operate that data. The answer, increasingly, is: not a human.
English summary
Poland has quietly built the infrastructure for fully autonomous ERP operations. Inbound data is now structured: the National e-Invoicing System (KSeF) turns every invoice into a machine-readable record rather than a document to be read (Ministry of Finance). Outbound data has been digital for years through the JPK reporting files. Internal data has always lived in the ERP database.
What was missing was a standard way for AI agents to reach those systems. The Model Context Protocol, open-sourced by Anthropic in November 2024, is an open standard for connecting AI applications to external data sources, tools and workflows (Anthropic), replacing the per-system custom integrations that previously made agent deployment expensive (Anthropic Engineering).
My thesis: the defining change of the next decade will be the agentization of ERP. Humans will set goals, approve exceptions and review outcomes, while procurement, warehouse, payables, tax and control agents perform work within explicit permissions and limits. A reduced role for the graphical interface will be a consequence, not the objective. The fastest return will come from procurement and inventory, where AI-driven optimization already reports inventory reduction potential in the region of 26% in vendor-published deployments (C3 AI).
The conditions are non-negotiable: distinct agent identities with scoped permissions, segregation of duties between agents, auditable reasoning, human accountability, clean master data, and a kill switch. Start with the best-measured process, not the most expensive one — run agents in recommendation mode first, and grant autonomy only where the acceptance rate proves it.