An AI Diagnosis Needs a Testable Repair Plan

A supplier's order files stop reaching the processing queue. An AI assistant notices that a connector update preceded the failures and recommends returning to the previous configuration. The explanation is plausible, and the proposed change looks straightforward.

But suppose the real cause is an expired certificate at the trading partner. Reversing the connector update would add another production change without restoring the exchange.

This hypothetical incident captures the business decision behind AI-assisted troubleshooting: how much evidence should a likely cause require before someone authorizes a repair?

Diagnosis is moving closer to execution

IBM announced general availability of Sterling Agent Hub on October 23. The release includes a B2B Integrator and File Gateway Agent for AI-assisted troubleshooting, root cause analysis, and diagnostic collection. IBM's product description describes analyzing logs, configuration, and runtime data to suggest likely causes and next steps.

On October 26, Oracle announced new Fusion agentic applications for customer experience. Its description of Service Health Check includes identifying likely causes of service-performance issues, preparing actions for review, and executing approved actions.

The products address different operational settings. These are vendor descriptions, and we have not independently tested their diagnostic accuracy or recovery results. Our recommendation for buyers is to evaluate the reasoning and the repair together. A convincing explanation is only the start of a useful incident response.

Require evidence that could change the diagnosis

Ask the assistant to separate observed events from its explanation. In the file-transfer example, the update time and failed transfer records are observations. The claim that the update caused the failure is a hypothesis.

Attach the relevant records to that hypothesis. Include the affected partner, time window, failure type, and configuration version. Show the specific evidence supporting the proposed cause and any evidence that conflicts with it.

Then define a check that could weaken or reject the explanation. If transfers to other partners continued after the update, the team should examine what differs about the affected connection. If the failure occurred before the update, the timeline needs correction before the rollback is considered.

The goal is to find the next useful investigation, without asking the model to defend its first answer. Let the assistant return an unresolved diagnosis when the available evidence cannot distinguish competing causes. The exception path should route that case to an operator with the access needed to investigate.

Separate diagnostic access from repair authority

An assistant that can inspect logs does not automatically need permission to change a production connector. Define those responsibilities separately, even when the product presents them in one conversation.

For the first deployment, give the assistant a bounded investigation task. It can assemble evidence and prepare a repair proposal for an authorized operator. Expand execution rights only after testing the specific actions the business intends to delegate.

Before collecting or sharing diagnostic packages, also define what they may contain and where they may go. Logs can include sensitive identifiers or transaction details. The convenience of assembling a support package should not decide who receives its contents.

Apply the same discipline to the agent's permission controls. A request to investigate an incident should have a clear scope, and a proposed repair should require the authority appropriate to its possible effects.

Make the repair proposal reviewable

The operator should see the exact target and change, the reason for it, and the expected result. Identify the affected connections or business processes. State whether the action could interrupt other work or trigger previously failed transactions to run again.

Specify how to return to the earlier configuration if the repair makes conditions worse. When a change cannot be reversed cleanly, say so before approval and define the recovery plan with the responsible owner.

Keep the proposal small enough to assess. Changing several settings at once may restore service while leaving the team unable to tell which explanation was correct. Where practical, test the suspected cause in an approved environment or use the least disruptive diagnostic check before changing production.

Urgency can justify a different sequence. An incident owner may choose containment before the cause is established. Record that decision as containment under uncertainty, with a later investigation still assigned.

Verify the business process recovered

A successful configuration change does not establish that the supplier's orders reached the processing queue. Define recovery evidence before the operator executes the repair.

In this example, that might include a successful exchange with the affected partner, confirmation that the expected files were processed, and reconciliation of the backlog. Check for missing or duplicate transactions when work is replayed. Use approved records and handling procedures for any recovery test.

Keep the incident open until the assigned owner accepts the recovery evidence. If the change completed but the business process still fails, the diagnosis must remain open to revision.

Buy against resolved cases

Evaluate the assistant on a set of approved historical or synthetic incidents with established outcomes. Include an obvious failure, two failures with similar symptoms but different causes, and a case where essential evidence is unavailable.

Measure time to a supported diagnosis, operator review effort, and time to verified recovery. Track incorrect repairs and reopened incidents alongside speed. An assistant that produces recommendations faster may still create more work if operators must repeatedly disprove them.

If your team is evaluating AI for integration support or service operations, talk with Revival Group about a bounded pilot that tests the diagnosis, approval process, and recovery evidence before granting repair authority.