Your ERP Is Not Becoming Autonomous. Your Operating Model Is Changing.

Adding an AI agent to your ERP does not make the business autonomous.

It changes who prepares the work, who decides, who approves, and who carries the consequences.

That is an operating-model decision, not a software feature.

SAP’s latest announcement presents Joule Work and Joule Assistants across sourcing, supply chain, collections, and billing. The customer examples quoted by SAP connect useful agent work to consistent processes, trusted data, and people staying above the technology—not disappearing from the process.[1]

The practical lesson is simpler than the “autonomous enterprise” label: do not start by asking how much of your ERP an agent can run. Start with one workflow and define exactly what authority you are prepared to give it.

Start with one bounded workflow

Take accounts-receivable collections.

A collections process looks repetitive from a distance. There are overdue invoices, customer records, payment histories, credit terms, dispute notes, and follow-up messages. That makes it tempting to tell an agent: “Manage overdue accounts.”

That instruction is too broad.

A useful first deployment would split the work into five levels:

1. Read: access approved customer, invoice, payment, and dispute records.
2. Recommend: rank accounts by urgency and suggest the next action.
3. Prepare: assemble evidence and draft a follow-up message.
4. Communicate: send only low-risk reminders that meet an approved rule.
5. Commit: change payment terms, place an account on hold, approve a write-off, or make another financial commitment.

The agent may be ready for the first three. The fourth may require a narrow rule and sampled review. The fifth should remain with an accountable person unless the organization has a very strong reason, tested controls, and an explicit approval design.

That is not a failure of autonomy. It is good operating design.

Trusted data is not a slogan

An agent cannot repair an operating model built on conflicting records.

Before the agent touches the collections queue, define the authoritative source for each fact:

• Which record holds the approved payment terms?
• Where is the current invoice status?
• Which field marks an active dispute?
• How fresh must bank-receipt data be?
• Which customer contacts are approved for collection messages?
• What happens when the CRM and ERP disagree?

“Use trusted data” is too vague. Name the source, required fields, freshness threshold, access permission, and fallback behavior.

If the payment status is stale, the agent should not guess. If a dispute note conflicts with the invoice status, it should not send. It should create an exception with the evidence attached.

The quality of the agent’s answer matters. The quality of its refusal matters more.

Give exceptions to a named owner

“Human in the loop” sounds responsible, but it is incomplete.

Which human?

For a collections agent, the exception owner might be the credit controller or finance manager. That person should receive cases when:

• customer records conflict;
• the amount exceeds an approval threshold;
• the customer disputes the invoice;
• a request falls outside standard payment policy;
• the agent’s confidence is low;
• the recommended action could damage a strategic customer relationship.

The escalation also needs a response expectation. A queue that nobody owns is not a control. It is delayed failure.

Define the owner, the trigger, the authority, the response time, and the fallback when the owner is unavailable.

Approval must sit before the consequential action

Approval is useful only when it can still prevent the action.

A manager reviewing a report after an account was placed on hold is not approving. They are auditing the damage.

Put approval before any action that changes money, customer obligations, access, production, or policy. For collections, that could include:

• changing payment terms;
• approving a discount or write-off;
• placing or removing a credit hold;
• sending a legal escalation;
• committing the company to a repayment arrangement.

Riverbed’s vendor-reported survey of 1,200 respondents across seven countries is useful context here. Riverbed says 90% expect to pursue human-supervised or highly autonomous IT operations, while 77% are hesitant to let AI make operational decisions without human approval. It also reports that only 19% of IT operations are automated today.[2]

Those figures are not a universal law. They do show the tension operators are trying to resolve: they want more execution, but they are not prepared to surrender accountability.

The answer is not an approval button on everything. It is a smaller, sharper approval surface around consequential actions.

Keep evidence, not just activity logs

A log saying “agent completed task” is not enough.

For every consequential step, retain:

• the source records used;
• the recommendation produced;
• the rule or policy applied;
• the identity of the approver;
• the action taken;
• the timestamp;
• the final exception outcome.

This evidence serves three purposes. It lets the operator reconstruct a decision. It gives reviewers material to improve the workflow. And it prevents the agent from becoming a black box that everyone trusts until the first serious error.

This is different from yesterday’s problem

Yesterday’s article focused on a workforce question: if AI removes junior work, how will people develop the judgment needed for senior roles?

Today’s question is operational: when an agent enters an ERP workflow, who has authority to read, recommend, communicate, and commit?

Both matter, but they need different designs. One protects the path through which people learn. The other defines how work moves safely through a live system.

Do not blend them into a vague transformation programme.

Write the operating contract before enabling live writes

Choose one proposed ERP agent and create a one-page operating contract.

Document:

1. Data: the approved sources, required fields, freshness rules, and access boundaries.
2. Allowed actions: what the agent may read, recommend, prepare, communicate, and commit.
3. Prohibited actions: what it must never do without human approval.
4. Approval triggers: the exact thresholds and conditions that stop execution.
5. Exception owner: the named role, authority, and response expectation.
6. Evidence: what must be retained for each consequential decision.

Then test the contract against normal cases, missing data, conflicting records, policy exceptions, and a deliberately unsafe request.

Only after it passes should the agent receive live write access.

Your ERP is not becoming autonomous. Your company is deciding how authority will move between people and digital coworkers.

Make that decision deliberately.

Sources

[1] https://news.sap.com/2026/10/sap-connect-sap-puts-autonomous-enterprise-to-work — SAP Puts the Autonomous Enterprise to Work [2] https://www.riverbed.com/press-releases/global-survey-finds-agentic-ai-reshaping-it — Riverbed Global Survey 2026: Autonomous IT