Solution-verification agent

Asking a customer whether the fix worked is the slow way to find out. On tickets where the failure was a call, a workflow, or a scheduled job, the answer can be produced directly. A verification agent re-runs the original failing action against the customer's account and records what came back.

The result is a run record, not an opinion. Timestamp, account, action performed, response, and a comparison against the failure captured when the ticket was filed. Passed means the same action that failed now succeeds under the same conditions.

That is a stronger claim than a customer's yes. People confirm from memory, from a different browser, or after quietly changing their own setup. A run against the account under recorded conditions removes those variables from the answer.

It is also narrower. The agent verifies the one action that was captured. A customer whose complaint was broader than that action can still be unhappy after a passing run. The ticket has to leave room for that.

The agent fits a narrow set of tickets. API errors, sync jobs, imports, scheduled exports, and anything with a repeatable trigger. A ticket about a confusing invoice or a slow page has nothing to re-run.

Verification depends on a recorded failure: endpoint, parameters, account identifier, timestamp, response body, and status. Without that record, the agent reconstructs the failure from prose, and a reconstruction that passes proves nothing about the original report.

This is why the capture belongs upstream. The probe that tried to reproduce the issue usually produced the exact artifact needed here, and attaching it costs nothing at the time. Recovering it three weeks later is often impossible.

Define the pass criteria before the fix ships. A specific status code. A named field present in the response. A job that finishes inside a stated time. Looks better is not a criterion, and an agent without one returns a screenshot for somebody to interpret.

Record the conditions that mattered. Plan, region, integration version, and any data shape involved. A re-run under different conditions is a different test. The run record has to state which conditions it used, so any gap stays visible.

When the capture is missing, the agent should say so and stop. An unverifiable ticket falls back to asking the customer. That is a weaker instrument, and it is the honest one.

Running against a live account is not free. It can create records, send notifications, or move money. Every verification action needs a defined blast radius before anyone turns it on.

Read-only checks are the default. Fetching a record, calling a status endpoint, or reading job history changes nothing and covers a large share of tickets. Anything that writes needs an allow list of object types and a per-run ceiling.

Some verifications need the customer to take part, and the ticket should show that they agreed. A test order, a test shipment, or a test transaction on a real account requires consent from the requester, written on the thread. Consent to report a bug is not consent to run one.

Prefer the customer's sandbox where one exists. Where none exists, use the smallest live action that answers the question, then clean up after it. A verification that leaves a test record in production creates the next ticket.

Rate limits belong in the configuration. When a fix ships for many affected accounts, every run can land in the same minute. The platform then sees a traffic spike caused by its own tooling.

The case below is hypothetical. A company provides an API that generates carrier shipping labels for online retailers. Twelve retailers reported that label creation failed for one carrier whenever the origin address sat in a particular country. The error was a rejected postal code format.

Each ticket carried a captured failure: the request body, the account, and a 422 response with the carrier's message. Clustering the reports had already grouped them under one defect, and a fix shipped on a Tuesday release.

The agent runs one verification per affected account. It replays the captured request with a test flag that prevents an actual label purchase. Pass means a 200 response carrying a tracking number.

Ten accounts pass. Two do not, and the two failures differ from each other. One returns a 422 naming a missing customs field, a separate defect that the first error had been hiding. The other returns 200 with no tracking number, so it fails the stated criterion on a detail worth reading rather than waving through.

Those two tickets stay open and go back to engineering with their run records attached. The other ten carry a run identifier and a passing response into the follow-up message. That message says the label call was re-run on the account and succeeded, with the time it happened.

One of the ten replies anyway, reporting that their own retry logic still throws an error. That is a real complaint about a different layer, and a passing verification does not answer it.

A pass on the wrong action is the main hazard. Verifying a corrected endpoint while the customer calls an older one produces a confident and useless result. Verify the path the customer actually uses, taken from the captured request.

Test-mode divergence follows close behind. A run with a test flag may skip validation, billing, or a third-party call, and the skipped step is sometimes the broken one. Record the mode used, and state that limitation in plain words on the ticket.

Stale captures verify old problems. When weeks pass between report and fix, the customer's configuration may have moved. Replaying a request built from last month's settings can fail for reasons unrelated to the defect, and the ticket reopens over nothing.

One passing run gets read as fixed everywhere. It says the action worked once, for one account, at one moment. Where a defect touched many accounts, run it per account and let the exceptions surface on their own.

Verification can also become theater. A team that runs the agent and files the output without reading it has added a step rather than a check. Every run record needs a reader.

The agent reports and a person concludes. A pass supports closing the ticket. It does not close it. Whoever owns the ticket reads the run, compares it against the original complaint, and decides whether the complaint has been answered.

Failures route by type. A repeat of the original error goes back to the engineering thread with the new run attached. That is the same evidence package built for the original handoff. A different error becomes a new ticket instead of an extension of the old one.

Customers keep the last word. A verified fix plus a customer saying it still fails is not a conflict to settle in the system's favor. It usually means the verification covered less ground than the complaint. Ask what they are doing that the run did not do.

Where a pass exists, the follow-up question changes shape. Rather than asking whether the issue is resolved, the message states what was re-run and asks whether anything is left. Replies to that question carry more information, and the label read from them is easier to trust.

Verification also changes what silence means. A ticket that goes quiet after a passing run rests on evidence, not on an assumption. The policy for quiet closes should treat those two cases differently.