Let AI Help Diagnose Incidents - Without Giving It the Keys

Question

Practical lessons from building Esapay, a prototype exploring safer recovery for payment infrastructure.

Payment systems can fail in ways that look deceptively similar. Slow checkouts might point to an overloaded service, a growing backlog, or trouble somewhere further downstream. Responding to every spike in the same way can make an incident worse: a change that helps one bottleneck may increase pressure on another.

I started building Esapay to explore a question that matters beyond payments: how can AI help engineers make sense of an incident while keeping important system changes controlled, reviewable, and reversible?

Esapay is an experimental project, not a production payment processor. Its recovery demonstrations use simulated workloads, and its results should not be read as guarantees about live payment traffic.

The Principle: Recommendations and Authority Are Different Things

AI can be useful when an incident has several possible explanations, when signals are noisy, or when an engineer needs a concise summary of what may be happening. But a model's recommendation should not automatically become an infrastructure change.

A safer design keeps three responsibilities conceptually separate:

• Interpretation: Use telemetry and contextual reasoning to form a hypothesis.
• Decision control: Check a proposed response against current conditions, operational limits, and applicable policy.
• Execution and verification: Make only an authorized change, then inspect whether the outcome matched expectations.

This separation makes it possible to benefit from AI without requiring the system to trust every output it generates. It also makes the overall system easier to reason about when a model is unavailable or returns an answer that cannot be used safely.

1. Keep Automated Actions Deliberately Narrow

A free-form instruction is difficult to validate. A bounded operation is easier to inspect before it is allowed to run.

One lesson from Esapay is to define the kinds of changes a system is permitted to consider, rather than allowing a reasoning component to invent arbitrary operational commands. The enforcement layer should independently check a proposed change and remain responsible for whether it is accepted.

This does not make automation safe by itself. The permitted operations still need clear limits, appropriate authorization, and tests for invalid inputs and unexpected conditions.

A useful design question is: Could the system explain why this change was allowed, and could a separate part of the application reject it? If the answer is no, the authority boundary may be too vague.

2. Plan for Missing, Slow, or Malformed AI Responses

A system that depends on an AI service should define what happens when that service is unavailable. Network problems, timeouts, model errors, and unexpected output are ordinary failure modes—not exceptional situations that can be ignored until deployment.

For critical workflows, the fallback should be intentionally limited. Depending on the system, that might mean using established deterministic checks, asking for human review, or declining to take an automated action. The correct choice depends on the risk; continuing automatically is not always the safest option.

The broader lesson is to design the failure path at the same time as the success path. If a workflow only behaves safely when the model responds perfectly, its reliability depends on an assumption that will eventually be tested.

3. Treat Decisions as Snapshots of a Changing World

A recommendation can be reasonable when it is created and unsafe a moment later. Other requests may have changed the resource, its limits, or the surrounding conditions while the system was preparing a response.

Before applying a change, a robust system should establish that the information behind the decision is still current. Where concurrent changes are possible, that check should be coordinated with the mutation itself; checking a version and changing state as two unrelated operations can leave a race between them.

This is a general backend engineering problem, not something unique to AI. AI can make it more visible because reasoning may take long enough for the world to change before the recommendation is ready.

Tests should deliberately create competing updates and verify that outdated decisions are rejected or reconsidered. Happy-path tests alone will not reveal these timing problems.

4. Verify Effects Instead of Assuming Success

A successful function call or accepted command does not necessarily mean an incident has been resolved. A change may be applied but fail to improve the symptom, improve one metric while worsening another, or fail to reach the external system it was intended to affect.

That is why recovery should include an outcome check. Before acting, define what improvement is expected. Afterward, compare the observed state with that expectation and retain enough context to understand what happened.

Reversibility also deserves care. A rollback that restores an application's local view does not automatically restore an external service, cluster, or payment provider. Systems that cross those boundaries need a way to verify the external result and handle partial failure.

The aim is not to claim that every action can always be undone. It is to make uncertainty explicit and avoid declaring success before there is evidence for it.

5. Make Decisions Explainable After the Incident

When an automated response succeeds, engineers need to know what changed and why. When it fails, they need to reconstruct the path to that outcome.

Useful operational records can include:

• The observed symptoms.
• The rationale for a recommendation.
• The decision outcome.
• The change that was attempted.
• The result that followed.

Such records should avoid storing credentials or unnecessary personal and payment data. Access controls and retention rules matter just as much as the record format.

Integrity checks can help reveal whether recorded events have been altered, but they are not a substitute for durable storage, restricted access, backups, or a clear operational process. An audit trail is only as useful as its coverage and the trustworthiness of the environment that stores it.

These details are easy to underestimate when building a prototype. They become central when someone must explain an incident to a teammate, an operator, or an auditor later.

6. Evaluate the Trade-offs Honestly

AI-assisted recovery introduces costs as well as potential benefits. Additional reasoning can improve a recommendation in some cases, but it can also add latency, complexity, operational dependencies, and new failure modes. A simpler baseline may be preferable for predictable incidents.

For Esapay, I use a local simulation and benchmark harness to explore these trade-offs. Such experiments are valuable for comparing approaches under controlled conditions, reproducing scenarios, and identifying regressions. They do not establish how a system will behave under every real-world workload.

A useful evaluation should state what was simulated, what was measured, what baseline was used, and what remains untested. It should also consider more than one headline number:

• Recovery quality.
• Time spent in a degraded condition.
• Unintended changes.
• Resource overhead.
• Behavior when the reasoning service fails.

The goal of a benchmark is not to make a project look fast. It is to help answer a specific engineering question and show the limits of the evidence.

Questions I Ask When Designing AI-Assisted Automation

Before trusting an automated recovery workflow, I want clear answers to questions like these:

1. What is the smallest set of actions the system genuinely needs?
2. Which independent checks can veto a recommendation?
3. What happens if the model is unavailable, uncertain, or returns unusable output?
4. How do we know the state has not changed since the recommendation was prepared?
5. What evidence tells us the action helped—and what happens if it did not?
6. Can we reconstruct the decision without exposing secrets or unnecessary user data?
7. Which results come from controlled simulation, and which have been validated in a real environment?

These questions are useful even when the final design does not use multiple agents or a language model. They force the system's authority, failure behavior, and evidence to be discussed explicitly.

Closing Thought

The most interesting part of applying AI to infrastructure is not giving a model more power. It is deciding where reasoning adds value, where deterministic controls are necessary, and how to tell whether the final outcome was actually good.

Esapay remains a prototype, and there is more work to do before its ideas could support production-critical workloads. Building it has reinforced one principle for me:

AI can help inform an operational decision, but the system should retain clear control over authorization, execution, and verification.

For engineers exploring similar ideas, I would start with narrow permissions, explicit failure paths, deliberate concurrency tests, careful outcome measurement, and honest reporting of limitations. Those foundations matter more than making an architecture sound autonomous.

Explore Esapay

Interested in exploring the project or discussing potential contributions? Visit the repository:

GitHub repository: https://github.com/sujithputta02/Esapay

If you have ideas for improving reliable AI-assisted systems, I'd be interested in hearing your thoughts and learning from the developer community.