AI agents are in real production use in four of the nine phases of an ERP program: requirements capture, configuration, test design and execution, and training content. In the other five (fit-to-standard workshops, data cleanup, integration, cutover, the first weeks after go-live) they draft, flag, or triage, and people still do the work. McKinsey put the potential effort saving at 50% or more in May 2026, with testing effort down about 80%. The best published accuracy figure for an agent that builds configuration is 85%, and it is the vendor's own benchmark. That is why every agent output still carries a named human signature before it reaches a production client. This article lists, phase by phase, what agents do, who checks them, how they fail, and what to write into the SI contract.
The saving is real in hours and unproven in program months
The published numbers come in two kinds, and a PMO lead should keep them apart. The first kind is a measured saving on a single task. SAP reported in December 2025 that early pilots of Joule for Consultants ran up to 14% faster and saved as much as 1.5 hours per consultant per day.
Opkey told CIO in February 2025 that its platform cuts testing time by as much as 85% and ERP management cost by up to 50%. Both are vendor claims with no published method. The second kind is a projection for the whole program, which is where the McKinsey figure of at least 50% sits.
As of November 2026, no vendor, SI, or analyst has published a finished tier 1 program that came in at half the planned duration because of agents. ERP Today's own survey, run as partner content with Opkey, found that 31% of implementations took longer than expected and 12% had significant delays. Those numbers are from programs that already had test automation.
The gap between a task-level saving and a program-level saving is change management, approvals, and data cleanup, which agents do not shorten much. McKinsey says as much: in its model, change management becomes the main constraint once design and testing speed up.
The place to expect the saving first is the design phase, which is 10% to 20% of implementation hours according to ERP Research, and test execution. Consider what that looks like on one test cycle. Suppose a test lead hands an agent 400 regression scripts for a finance release. It returns 340 passes, 40 fails, and 20 it could not run because a screen had changed. The agent did in a night what two testers would do in about two weeks, which is the 80% McKinsey describes.
The test lead's work starts there. She samples 30 of the 340 passes and finds two that could not fail, because the expected result was generated from the same configuration under test. She triages the 40 fails and finds 28 are real defects and 12 are script problems. She hands the 20 unrunnable scripts back to the agent to repair and reruns them.
The cycle still took five working days instead of ten. Nobody signed off on a pass rate the agent reported; they signed off on the 30-script sample and the 28 defects. The saving in hours is real. The program plan did not move, because the next cycle waited on defect fixes and a configuration decision, not on testing. The 36-month planning number for a tier 1 program, from decision to go-live, is one of the few things we have seen hold across programs. Agents have not changed it yet.
Agents are in real use in four of nine phases
The table below sorts the program lifecycle by how far agents have actually got. "In use" means a named vendor, SI, or product has agents doing the task for paying clients. "Drafting" means agents produce a first version that a person finishes. "Announced" means a product exists on a slide and not yet in a program anyone can point to.
| Phase | Status | What the agent does today (named example) | Human checkpoint | Failure mode |
|---|---|---|---|---|
| Requirements capture | In use | Generates questionnaires, captures requirements, and keeps traceability from requirement to design decision (Opkey Design Studio, Feb 2026) | Business process owner confirms each requirement; PMO owns the traceability matrix | Agent records what people said, not what they need. Volume of captured requirements rises, scope control weakens |
| Fit-to-standard workshops | Drafting | Prepares the standard process description and suggests the gap list; SAP's Joule for Consultants answers configuration questions from SAP's knowledge base | Workshop lead decides fit versus gap in the room; a global process owner signs the decision log | Agent proposes a workaround that is technically possible and breaks clean core; nobody notices until the upgrade |
| Configuration | In use | Maps legacy structures to target settings and builds configuration after approval (Opkey, 85% accuracy; Sage and PwC on Intacct dimensions and role models) | Solution architect reviews every setting the agent proposes; functional lead approves before transport or activation | Confident wrong answers on local rules. Opkey's CEO says the agent cannot yet reliably handle UK versus US tax and supplier terms |
| Data migration and cleanup | Drafting | Proposes field mappings and spots duplicates; NetSuite SuiteExpress covers migration for US and Canadian software customers | Data owner approves each mapping rule; reconciliation counts signed by finance before each mock load | Mapping looks complete, cleanup rules fix the symptom not the source, and the same dirty records come back on the next extract |
| Integration | Announced | Agents create reports and interfaces from natural-language prompts; vendor agent-builder platforms call other systems, but for operations, not for program integration work | Integration lead reviews interface specification; security reviews every credential the agent uses | Interface works in a demo tenant and fails on volume or on the error path nobody prompted for |
| Testing | In use | Generates test cases from historical transactions, runs them, and repairs scripts when screens change (Opkey; PwC on Intacct) | Test lead approves the test design before execution; business signs user acceptance results, not the agent's pass rate | Tests generated from the same configuration they test pass by definition. Coverage looks high, the untested business rule ships |
| Training content | In use | Produces user guides, job aids, and videos from test scripts and recorded user journeys (Opkey Training Agent) | Change lead reviews content for role accuracy; a real user walks it once before release | Content describes the system as configured on the day it was generated, then drifts after the next change |
| Cutover | Drafting | Drafts the cutover runbook and dependency list from the plan | Cutover manager owns the runbook; every go/no-go criterion has a named signer | Runbook step order is plausible and wrong on a dependency the agent never saw, such as a bank file cut-off |
| First weeks after go-live | In use (vendor side) | Support agents give in-app help and triage tickets; Opkey pilots cut average ticket resolution from 13 days to 5.5 days (vendor figure) | Support lead reviews any fix the agent proposes to configuration; nothing moves to production without a change record | Agent resolves the ticket by teaching the user a workaround, and the defect is never logged |
Two patterns stand out. The phases where agents are in use all have a large body of prior examples to learn from: past requirements, past configurations, past test scripts, past training guides. The phases where they only draft are the ones where the hard part is a judgment about this client, not a pattern from the last hundred. Fit-to-standard and cutover are the clearest cases.
Vendor agents mostly run the business, not the program
A program manager will hear from the software vendor that the product "has agents." That is true and mostly beside the point for delivery. The table below names each vendor's agent offering once and says which side of go-live it sits on.
| Vendor | Agent offering | What it is for | Program-delivery use |
|---|---|---|---|
| SAP | Joule Studio Agent Builder (GA Jan 2026) and Joule agents; Joule for Consultants | Agents that act across SAP and non-SAP systems in operations; Joule for Consultants explains ABAP and answers implementation questions from SAP's own content | Joule for Consultants only; it is an assistant, not an agent that configures |
| Oracle | AI Agent Studio and 50-plus agents in Oracle Fusion (Mar 2025), at no added cost | Finance, HR, supply chain process automation | None for the program itself; third parties such as Opkey fill the gap on Oracle |
| Microsoft | Copilot and agents in Dynamics 365, such as the Account Reconciliation Agent and Supplier Communications Agent (Oct 2025) | Finance close and procurement operations; custom agents via Copilot Studio | None announced for implementation |
| Workday | Illuminate agents (seven added May 2025), sold separately | Contracts, accounting from documents, self-service, frontline | None for implementation |
| Oracle NetSuite | NetSuite Next with SuiteAgents, SuiteAgent Studio, and SuiteExpress (Oct 2026) | Industry agents for operations; SuiteExpress is an AI implementation toolset for migration, requirements, and configuration | SuiteExpress, limited at launch to software companies in the US and Canada |
The practical consequence is that the agents in your program will come from the SI or a third party, and the vendor's governance features will not cover them. Oracle's configurable approval step governs an Oracle agent paying an invoice. It does nothing about a third-party agent writing your chart of accounts. Those controls have to come from the program.
Each of these vendors is the right answer in a specific case. Oracle's included agents matter most for a customer whose business case depends on finance automation from day one. Workday's agent registry is the strongest answer for a services firm that expects to run third-party agents alongside its own. NetSuite's SuiteExpress is the one place a vendor has put implementation itself in scope, and it fits a US software company of the size NetSuite serves. SAP's offer suits a program with heavy custom ABAP to understand before a move to S/4HANA. Microsoft's reconciliation agent is a good fit where the close is the pain and the Dynamics 365 program is already live.
Three failure modes show up before go-live
The first is the confident wrong answer on a local rule. Opkey's CEO told diginomica the agent cannot yet reliably tell UK supplier terms and tax from US ones, and that process maps must be approved by a business consultant. A multi-country program multiplies this risk by the number of legal entities. The agent's 85% is an average across settings, and the missed 15% clusters on the settings that differ by country.
The second is circular testing. When the same tool generates the configuration and the test cases, the tests check that the system does what the configuration says. They do not check that the configuration matches the business. Sage and PwC avoid part of this by generating test scenarios from historical transaction data rather than from the configuration. A test lead should insist on that source. User acceptance testing should stay in the hands of users who did not see the agent's test plan.
The third is artifact drift. Agents are good at producing documents: training guides, runbooks, process descriptions, requirement lists. The volume of drafted material rises faster than the approval capacity, and approved documents fall behind the current configuration. The control is simple: an artifact without a dated approval is a draft, and drafts do not ship.
Five controls to write down before an agent touches the build
ERP Today's recommendation after the Sage and PwC announcement was governance covering data access, decision validation, and audit trails during the project. That is the right list, and it needs two more items. Here are the five, in the order a PMO should set them up.
- Data access scope. An agent reading production data to build test cases is reading customer, supplier, and payroll records. Write down which environments and which tables the agent can see, and whether data is masked before it reaches a model hosted outside the client. The question for the SI is who hosts the model and where the prompts and outputs are stored.
- Decision validation. Every agent output lands in one of three bins: accept, edit, reject. Someone with a role title must put each output into a bin, and the program should record the rate. If the SI reports that 95% of agent configuration proposals were accepted without edit, either the agent is very good or nobody is reading them. A reviewer who can tell which is the case is the whole point of the checkpoint.
- Audit trail. For every setting, test result, mapping rule, and document the agent produced, the program needs a record of the prompt or input, the model and version, the output, the reviewer, and the decision. Vendors with agent registries cover agents in production. For program agents this is a spreadsheet or a column in the existing configuration and test management tools.
- Sign-off. Agent-produced configuration is signed by the solution architect, and agent-produced test results are signed by the test lead and, for user acceptance, by the business process owner. The agent does not sign anything. This is the same rule as for a junior consultant, and the comparison is useful: the SI would not let a first-year analyst transport a configuration without review, and the agent gets the same treatment.
- Model and version control. An agent that passed review in March and was swapped for a new model version in June is a different reviewer input. The SI should disclose model changes the way it discloses staffing changes, and the test lead should rerun a sample of earlier reviewed outputs when the model changes.
The control most likely to be skipped is the third one, the audit trail, and the reason is that it has no natural owner. Data access is owned by security, sign-off by the architect and test lead, and model version by the SI. The record of prompt, output, reviewer, and decision belongs to nobody until the PMO assigns it. It looks like paperwork while the build is moving.
Suppose a program skips it. Ten months later an auditor asks why the tax code on 60 supplier records in one country posts to the wrong account. The configuration was agent-proposed and a consultant approved it. The consultant has rolled off, and there is no record of what the agent was asked or what it was shown. The program now has to treat every agent-proposed tax setting as unreviewed and re-test all of them. On a 20-country build that is several hundred settings and two to three weeks of a tax specialist's time. The spreadsheet column that would have prevented it costs a few minutes per approval.
Put it in the SI contract
An SI contract written before agents were in use will not mention them. A standard services agreement usually does not oblige the SI to say which tools produced the work. The first production implementation agents date to 2025, so any contract drafted on an older template needs to be read with that in mind.
Under such a contract the SI can use agents on your program and has no duty to tell you. The fixes are short clauses, and the table below gives the shape of each.
| Clause | What it says | Why |
|---|---|---|
| Disclosure | SI lists every AI tool or agent used on the program, by phase, and updates the list when it changes | You cannot govern what you do not know is there |
| Data handling | Client data used by agents stays within named environments; no client data trains a model that serves other clients; masking rules named | Separate, isolated instances per client are technically normal for these tools. Make it contractual |
| Accountability | Agent output is SI work product. Defects in agent-produced configuration, code, or tests are SI defects, with the same warranty and fix obligations | Removes the "the tool did it" defense before it is tried |
| Review record | SI delivers the audit trail from control 3 above as a signed record at each phase gate | Makes the checkpoint visible to the client and to any independent assurance review |
| Rate card and effort | Where the SI uses agents on a time-and-materials phase, the estimate shows the assumed agent effect, and actuals are reported against it | If the agent saves 80% of test design effort, the hours should show it |
| Model change notice | SI gives notice before changing the model or tool version used on reviewed work, and re-validates a sample | Reviewed output is only as good as the version that produced it |
A fixed-price program needs the same clauses with one change: the rate card line becomes a statement of which outputs the SI will produce with agent help, so the client knows where to concentrate review.