The AI Agent Is in the ERP, but the Implementation Never Ends

TL;DR

• An AI agent connected to the ERP will not bring the implementation to a close if it is still unclear what the agent may infer and what it must follow as a fixed business rule.
• Without explicit decision criteria, every sales exception reopens testing, integrations, and approvals.
• The core problem is not just AI capability. It is the governance of the decisions the AI influences or executes.
• Before expanding automation, the CTO must separate inference, rules, approval authority, evidence, and accountability.

Why Is Go-Live Still Stalled Even After the Agent Works?

The agent has been integrated. The ERP responds. The primary workflows have been demonstrated. Even so, the organization cannot move forward with a safe go-live.

For a CTO, this is one of the most difficult kinds of delay: the technology appears ready, but the organization keeps discovering conditions that were never made explicit. A new pricing exception requires another test. A nonstandard deal term goes back for approval. A credit discrepancy reopens the discussion about approval authority. A response generated by the agent must be compared with what the business considers binding.

The project remains “almost ready.”

The thesis presented in the Prism material exposes the source of this gridlock: without explicit criteria defining what AI may infer and what it must follow as a fixed business rule, every exception reopens testing, integrations, and approvals. The agent becomes a source of continuous user acceptance testing rather than the final step in the implementation.

That changes the diagnosis. The bottleneck is not necessarily the technical integration. It may be the absence of a decision model that clearly defines AI’s role within the B2B sales operation.

Integration Determines Whether the Agent Can Act. Governance Determines Whether It Should

A successful integration demonstrates that systems can exchange data and trigger processes. By itself, however, it does not answer questions such as:

• Which decisions may be inferred from context?
• Which terms must be applied without interpretation?
• When does an exception require human intervention?
• Who approves an out-of-policy decision?
• What evidence must be retained to explain the outcome?
• Does a policy change require an update to a rule, an integration, or the agent’s behavior?

Without these answers, user acceptance testing attempts to compensate for missing governance. The team adds scenarios, creates new checks, and repeats approval cycles. Each test resolves one case, but it does not necessarily establish a reusable principle.

The result is an implementation that accumulates exceptions without stabilizing its decision logic.

The Problem Appears at the Boundaries, Not in the Ideal Workflow

Ideal workflows are usually easier to demonstrate: the data is available, the terms are valid, the policy is clear, and the expected response is known. Risk emerges when an actual sales process combines variables that were never classified in advance.

In a B2B negotiation, a term may depend on context while also being constrained by a fixed policy. If that boundary is not documented, the technical team must rediscover it during user acceptance testing.

In this environment, asking “Did the agent get it right?” is not enough. The CTO must ask more precise questions:

• Did the agent apply a rule or make an inference?
• Was the source used for the decision valid in that context?
• Was the decision within the established authority threshold?
• Should the exception block the transaction, trigger an escalation, or simply be logged?
• Can the behavior be reproduced and explained?
• Who is responsible for changing this criterion in the future?

The distinction matters because an inference may allow for contextual evaluation. A fixed business rule requires compliance. Combining the two categories forces the same test to validate interpretation and policy adherence at the same time.

Continuous User Acceptance Testing Is Not the Same as Continuous Improvement

Systems and policies change, so some degree of ongoing validation is inevitable. The problem begins when the organization cannot distinguish planned evolution from the permanent reopening of the implementation.

There is a difference between:

• validating a new capability;
• changing a sales policy;
• fixing an integration;
• recalibrating an inference;
• adding a new approval threshold;
• handling an exception that is not yet governed.

When everything enters the same backlog, the CTO loses visibility into the nature of the work. Operations labels something an error when it may actually be a missing rule. The technical team treats something as a configuration change when it may require a business decision. User acceptance testing expands because it becomes the place where conflicts over ownership and accountability are resolved.

AI intensifies this tension. The agent can interpret context and propose actions, but that capability does not eliminate the need to define where interpretation ends and binding business policy begins.

The Cost of Inaction

Leaving this boundary undefined does more than delay go-live. It also preserves an operating model in which every exception once again consumes technical and executive attention.

The costs appear in several areas:

• tests reopened because certain conditions were never classified;
• integrations reviewed without clarity about the source of the problem;
• repeated approvals for similar exceptions;
• dependence on specific employees to interpret policies;
• difficulty explaining why the agent made or recommended a decision;
• limited expansion of automation because the business does not trust the operating model.

The deeper consequence is a loss of predictability. The CTO cannot confidently say whether implementation is close to completion because the true scope is not merely functional. It also includes business decisions that remain implicit.

A company can have a technically operational agent and still lack a governable operation.

Principles That Prevent Every Exception From Reopening the Project

• Classify before automating: Separate inferential decisions, fixed rules, exceptions, and actions that require approval.
• Define approval authority explicitly: Document who may approve, block, or change each type of condition.
• Validate principles, not just examples: Every approved scenario should be tied to a criterion that can be reused.
• Preserve evidence: Retain the context, the rule applied, the inference made, and the final decision.
• Separate technical changes from business changes: Not every discrepancy should be sent back to integration or development.
• Treat exceptions as a governance signal: When similar cases keep recurring, the problem may be the decision framework.
• Expand autonomy gradually: The agent should gain autonomy as its rules, limits, and escalation paths become verifiable.
• Keep human accountability identifiable: Automation should not obscure ownership of policies and outcomes.

FAQ

Does the agent need to follow fixed rules for every decision?

No. The goal is to distinguish where inference creates value from where a business policy requires a predetermined action. That distinction must be explicit and testable.

Will more testing solve the problem?

Testing is necessary, but it does not replace decision criteria. Without those criteria, new tests tend to cover isolated exceptions and extend the user acceptance testing cycle.

When should an exception go back to the technical team?

When there is a failure in integration, execution, or technical behavior. If the root cause is a missing policy, undefined approval authority, or business conflict, the decision must go back to the appropriate business owner.

How do you know when the implementation is truly ready?

When the relevant workflows—including their boundaries—have defined rules, approval authority, evidence requirements, and exception paths. A functioning agent is one part of that state, not the whole of it.

What Customers Are Saying

In a review published on Software Advice, Paulo Renan S. describes a capability that matters for organizations that need to evolve without losing control:

“Delivering consistent, scalable improvements with agile course corrections.”

Read the review on Software Advice

A Case That Illustrates the Issue

Case LI-966729, from the provided case library, shows the same issue in a different setting: low digital adoption in agriculture results less from a lack of channels and more from insufficient governance in the sales process.

According to the case summary, structuring quoting, context-based pricing, credit, and barter within an integrated workflow reduces transaction costs and allows field sales representatives to spend more time serving as technical advisors.

The connection to agentic AI lies in the decision architecture. Integrating a channel or adding an agent is not enough when pricing, credit, context, and exceptions remain distributed across implicit criteria. Automation becomes sustainable when the sales process has explicit rules and clearly defined decision authority.