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

TL;DR

• An ERP-connected agent does not complete the implementation when it is still unclear what it can infer and what it must follow as a fixed rule.
• Without explicit criteria, every commercial exception reopens testing, integrations, and approvals.
• The core issue is not only AI capability, but the governance of the decisions it influences or executes.
• Before expanding automation, the CTO needs to separate inference, rules, decision authority, evidence, and accountability.

Why is go-live still stuck even after the agent is already working?

The agent has been integrated. The ERP responds. The primary workflows have been demonstrated. Yet the go-live cannot move forward with confidence.

For the CTO, this is one of the most difficult forms of delay: the technology appears ready, but the organization keeps uncovering conditions that were never made explicit. A new pricing exception requires another test. A nonstandard commercial term goes back for approval. A credit discrepancy reopens the discussion about approval authority. An answer generated by the agent must be checked against what the business considers binding.

The project remains “almost ready.”

The thesis presented in the material on Prism reveals the source of this paralysis: without explicit criteria for what AI may infer and what it must follow as a fixed commercial rule, every exception reopens testing, integrations, and approvals. The agent becomes an ongoing validation workstream—not the end of implementation.

This changes the diagnosis. The bottleneck is not necessarily in the technical integration. It may lie in the absence of a decision model that defines the role of AI within the B2B commercial operation.

Integration answers whether the agent can act. Governance answers whether it should act

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

• Which decisions can be inferred from context?
• Which conditions must be applied without interpretation?
• When does an exception require human intervention?
• Who approves a nonstandard 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 tries to compensate for the lack of governance. The team adds scenarios, creates new checks, and repeats approvals. Each test resolves a case, but does not necessarily define 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: data is available, the condition is valid, the policy is clear, and the expected response is known. Risk emerges when commercial reality combines variables that were not previously classified.

In a B2B deal, a condition may depend on context, but it may also be constrained by a fixed policy. If that boundary is not documented, the technical team must rediscover it during validation.

In this scenario, the question “Did the agent get it right?” is not enough. The CTO needs to ask more precise questions:

• Did the agent apply a rule or produce an inference?
• Was the source used to make the decision valid for that context?
• Was the decision within the defined approval authority?
• Should the exception block, escalate, or simply be recorded?
• Can the behavior be reproduced and explained?
• Who is accountable for changing that criterion in the future?

The distinction matters because an inference may allow contextual evaluation. A fixed commercial rule requires adherence. Mixing these categories causes the same test to attempt to validate interpretation and compliance at the same time.

Continuous validation is not the same as continuous evolution

Systems and policies change. Some degree of ongoing validation is therefore unavoidable. The problem arises 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 commercial policy;
• fixing an integration;
• recalibrating an inference;
• adding a new approval level;
• handling an exception that has not yet been governed.

When everything enters the same queue, the CTO loses visibility into the nature of the work. Operations calls an issue an error when it may be a missing rule. The technical team treats something as an adjustment when it may be a business decision. Validation expands because it becomes the place where accountability conflicts 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 commercial obligation begins.

The Cost of Inaction

Keeping this boundary undefined does not merely delay go-live. It also preserves an operating model in which every exception consumes technical and executive attention all over again.

The cost appears on multiple fronts:

• tests reopened because conditions were not classified;
• integrations reviewed without clarity about the source of the problem;
• repeated approvals for similar exceptions;
• dependence on specific individuals to interpret policies;
• difficulty explaining why the agent made or suggested a decision;
• automation expansion limited by operational uncertainty.

The deeper effect is a loss of predictability. The CTO cannot state whether the implementation is close to completion because the true scope is not merely functional. It includes commercial decisions that remain implicit.

The company may have a technically operational agent and still lack a governable operation.

Principles for preventing every exception from reopening the project

• Classify before automating: Separate inference-based decisions, fixed rules, exceptions, and actions requiring approval.
• Define approval authority explicitly: Document who can approve, block, or change each type of condition.
• Validate principles, not only examples: An 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 commercial changes: Not every discrepancy should return to integration or development.
• Treat exceptions as a governance signal: When similar cases recur, the issue may be in the decision design.
• Expand autonomy progressively: The agent should gain latitude as rules, limits, and escalation paths become verifiable.
• Maintain identifiable human accountability: Automation should not make ownership of policies and outcomes unclear.

FAQ

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

No. The point is to distinguish where inference adds value and where a commercial policy requires a determined outcome. That separation should be explicit and verifiable through validation.

Do more tests solve the problem?

Testing is necessary, but it does not replace decision criteria. Without criteria, new tests tend to cover isolated exceptions and increase the validation cycle.

When should an exception go back to the technical team?

When there is an integration failure, execution issue, or technical behavior problem. If the root cause is a missing policy, undefined approval authority, or commercial conflict, the decision needs to return to the business owner.

How do you know the implementation is actually ready?

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

Who is already experiencing this

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

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

Read the review on Software Advice

A case that illustrates the issue

Case LI-966729, from the materials provided, shows the same issue in another context: low digital adoption in agriculture results less from the absence of channels and more from a lack of governance in the negotiation process.

According to the case summary, structuring quoting, contextual pricing, credit, and barter arrangements in an integrated workflow reduces transaction costs and frees the field sales representative to act as a technical advisor.

The connection to agentic AI lies in the decision architecture. Integrating a channel or adding an agent is not enough when price, credit, context, and exceptions remain distributed across implicit criteria. Automation becomes sustainable when the negotiation process has verifiable rules, approval authority, and decision paths.

No public link for the case was provided in the source material.

About this publication

“The Cost of Selling” examines how decisions, exceptions, and operational coordination affect B2B commercial efficiency.

In the final stage of this analysis, transaction cost provides a useful measure: how many validations, interactions, approvals, and corrections are required to complete a controlled negotiation?

CWS operates as a B2B Commerce Platform for Governed Negotiation, organizing commercial negotiations so that rules, context, approval authority, and exceptions are handled through governance. In this architecture, AI can expand operational capacity without taking on decisions for which the company has not yet defined criteria.

The objective is not to eliminate validation. It is to prevent validation from remaining the place where the organization discovers, indefinitely, how it should make decisions.

Sources

• Thesis: “The agent entered the ERP. Go-live became stuck in validation,” source material provided for this article, with no public link provided.
• Software Advice, Paulo Renan S.’s review of the CWS Platform: https://www.softwareadvice.com/product/546664-CWS-Platform/
• Case LI-966729, provided materials on governance of agricultural negotiations, with no public link provided.