The supplier called, saying this batch of materials will be 20 days late.
The buyer's actions follow a fixed sequence: first check how many days' worth of this material is still available, then look at work-in-progress orders to see whether it is included, then ask planning which finished products will be stopped, and finally go through customer orders to see which customers' delivery deadlines are going to be missed. By the time these four steps are done, usually two hours have passed, and three or four phone calls have to be made in between—because inventory, work-in-progress, and customer orders each sit in three different people's computers.
In materials released by Infor on November 12, these four steps were written as a chain: Claude follows the delayed component, passes through production orders, sub-components, and finished goods, all the way to affected customer deliveries; then gives two options, one is to place an expedited purchase order for the urgently needed quantity, while keeping the original order to cover the remaining demand, and the other is to find another supplier or substitute material. The buyer reviews it, approves one of them, and the transaction is executed under his own M3 identity.
Many people read this news as “Claude can operate ERP now.” I think the key point is elsewhere: it first works out who this order will affect, and only then does it allow action.
1. Three workflows, one common action
Infor’s collaboration with Anthropic is called Infor Industry AI for Claude, and it is currently open only to some Velocity Suite customers; the public configuration guide says M3. Only three roles were released in the first batch: production planner, buyer, and customer service representative. This restraint is worth noting—it is not “the whole company can use it,” but “three roles, three tasks.”
| Role | What will be asked? | The chain to pursue first | What is allowed to be changed? |
|---|---|---|---|
| Production Planner | Which production orders are at risk? Is it material shortage, capacity, or manpower | Whether issued materials, available inventory, and in-transit procurement can arrive in time; whether the capacity-switching plan is feasible | Reschedule production order dates, create planned purchase orders |
| Purchasing agent | This one is 20 days late; which customers will be affected? | Delayed parts → Production order → Sub-components → Finished goods → Customer delivery | Issue an urgent purchase order (keep the original order), adjust the purchase order |
| Customer Service Representative | The customer wants it earlier—is that actually feasible? | Finished goods inventory at each warehouse, quantities already occupied, and whether production can fill the gap | Update planned order date, reallocate inventory |
Three workflows look different on the surface, but underneath they are the same action: first lay out the entanglement relationships, then choose the path with the smallest change. The customer service one illustrates the problem best—the customer wants it one day earlier, and the warehouse does have stock, but the stock has already been claimed by another order. What the system needs to do is not 'whether there is stock,' but 'who will be hurt if the stock is moved over,' and then put that affected order on the table as well, letting customer service decide in front of the customer.
This is the dividing line between ERP agents and chatbots.A chatbot answers "Do we have stock?"; an ERP agent answers "We have stock, but moving it will affect Customer A's order on Thursday—do you want to move it?" The former's error is one number; the latter's error is a chain reaction.
2. What needs to be designed is not prompts, but character scripts
Infor's architecture is split into two halves: a connector that uses MCP and exposes selected M3 transactions through the Infor ION API Gateway; and a plugin that provides instructions and dashboards by role. Tool calls run as the logged-in user, and single sign-on and existing role permissions determine which records this person can see and which transactions they can perform.
What truly demonstrates design skill is the administrator layer. Administrators can trim the fields returned to Claude and can turn off transaction tools one by one; omitting or disabling tools that modify records amounts to configuring read-only. When write permissions are enabled, every change requires explicit approval. Actions executed through connectors leave their records in Infor.
Translated into implementation language, these four things are: customizable fields, tools that can be turned off, mandatory confirmations, and auditable records. Only when all four are in place can a role be put into production.
Here is a question that is easy to skip over: who writes this role script? Not IT—the business. The three questions a planner has to answer every day, the four rules of thumb a buyer uses to judge substitute materials, the two bottom lines a customer service rep holds to when committing to a delivery date—none of these things are in any requirements document; they exist only in people's habits. Writing them down is far harder than tuning a model, and far more valuable.
How much can be changed depends on how much can be clearly assessed. Giving write permissions to an agent that cannot clearly assess its scope of impact is just expanding the scope of incidents.
III. There are no numbers in this release
After scouring Infor's announcements, I couldn't find a single results figure. Jessica Vincent, vice president at Oldcastle APG, stopped at 'making it easier for employees to find relevant business data while also meeting the company's governance requirements.' The announcement also explicitly states that there are no measured results following this customer's deployment. The public demonstrations of the three workflows are scheduled for December 3.
This is not a black mark; rather, it is exactly what this stage should look like. In the second half of 2026, ERP vendors' agents will move en masse from "preview" to "available to some customers," but very few will be able to provide measured figures, for a simple reason: there are not yet enough samples that have actually been running, and even fewer that have run long enough—three months—to produce accountable numbers. Whenever a launch event directly cites a "40% efficiency improvement," it can basically always be traced back to an internal pilot or a carefully selected scenario.
For Party A, this means the due diligence approach needs to change. Do not ask "How effective is it?" Ask three things: in which interface this action is approved, which fields are displayed on the approval page, and what records are left in the system after approval. For any vendor that cannot answer these three questions, no matter how smooth the feature demo is, do not rush to sign.
IV. Back to Odoo: The impact scope can actually be determined
There is no button called “impact scope” in Odoo, but the data structures that support it are already in place. People doing manufacturing implementation are no strangers to these chains:
- Upstream/downstream traceability:
stock.movehasmove_orig_idsandmove_dest_ids; linked layer by layer, they form the complete chain of "this purchase order → this operation → this finished product → this sales order." In subcontracting business, the segment where components are sent to the subcontractor location is also on this chain. - Supply-Demand Gap: The product's forecast report (Forecasted) lays out on-hand, in-transit, allocated, and pending-outbound quantities all in one place, which is much more useful than the single field "inventory quantity".
- Date linkage: When confirming a sales order, Odoo generates purchasing or production suggestions according to the route, and the planned dates shift accordingly. Changing one date affects multiple dates across the entire chain.
- Audit trail: Turn on
tracking=Trueon a field, and every change is written to the chatter—who changed it and what it was before and after can be looked up.
So to add an "impact scope query" capability to Odoo, you don’t need to rewrite the ERP; what you need is three things built up in order:
| Hierarchy | What can intelligent agents do | Actions that must be left to humans |
|---|---|---|
| Read-only | Query upstream and downstream links by order number, customer, and material, and output the list of affected documents | Determine whether this checklist is complete (whether any parts that do not go through the system were missed) |
| Draft | Generate expedited purchase order drafts and rescheduling suggestions, and list the differences before and after the changes | Look at the differences item by item, especially quantities and dates |
| Execute | Directly confirm documents, change promised dates, transfer allocated inventory | Every time, you must click confirm and record the approver. |
The third layer is the most accident-prone place, because it looks the most effortless. An agent that directly calls a confirmation action will not report an error when something goes wrong; it will only quietly reserve inventory, change the delivery date, and then be discovered a week later in a customer complaint. Infor's approach is "explicit approval for each transaction"; this practice is not new, but it is worth copying: make the confirmation button the only part of the agent workflow that cannot be automated.
V. Three things you can do starting next week
First, treat "impact scope query" as the first deliverable, not the last. First let the agent only query and only list affected documents, run it for two weeks, and let business colleagues spot mistakes. The mistakes they spot are the source material for writing role scripts later.
Second, write a three-column table for each role: what they will ask, what they should pursue, and what they are allowed to change. For roles with the third column left blank, do not grant write permissions yet. This table constrains project scope better than any AI plan.
Third, treat the approval page as a product. The approval page must show: which order is being changed, what differs before and after the change, which orders will be affected, and who approved the last similar change. These four lines of information determine whether the person dares to click.
Let's go back to the phone call at the beginning. What is truly headache-inducing has never been the fact that "the materials were 20 days late," but that this fact has to travel between four systems and three people for two hours, and no one dares guarantee it gets passed on complete. The value of an agent here is not to make decisions for the buyer, but to lay out in one place everything that should be looked at during those two hours, so that the decision can be made within ten minutes, and afterward it is clear who made it.
As for whether it can amend orders, that is something for later. First, let it learn to calculate the knock-on effects.
Source: ERP News (2026-11-12, compiled from the Infor and Anthropic partnership announcement and M3 configuration guide), Infor official release materials. The technical descriptions involving Odoo in this article are based on public documentation and implementation experience; specific implementation depends on the version and business configuration.
Guangzhou Zhongdi Information · Enterprise Digitalization Insights · 2026-11-13
