Autonomous diagnostic agent

Support engineers open a ticket and start opening tabs. The log viewer. The billing record. The status page. The customer's account in the admin console. A diagnostic agent does that gathering first, then hands over what it found. The output is a short structured record: the symptom as reported, the facts pulled from each system, and a stated cause with the calls that support it.

What the agent does not produce is a fix. It does not issue the refund, flip the flag, or reset the account. It reports what it found and stops. Keeping that line clean matters, because a system that both diagnoses and acts will eventually act on a bad reading. Execution belongs to an agent with its own approvals and audit trail.

The record separates two kinds of statement. A finding is something a system returned: the API call, the timestamp, the value. A hypothesis is the agent's reading of those findings. Both go on the ticket, in different fields, with the hypothesis clearly marked as unconfirmed. Collapsing them into one paragraph of prose is how a guess becomes a fact by the time it reaches engineering.

An investigation agent is defined by its tool list. Each entry needs four things: the system, the specific read operation, the credential it uses, and the data it is allowed to see. Vague access such as "the admin API" is not a tool definition. It is a standing permission that nobody reviews. Write the list down before the first run, and review it when someone adds a system.

Read-only is the default and should be enforced by the credential, not by the prompt. An agent told to avoid writes will still write when a tool exposes one. Give it a service account that cannot mutate anything. Scope that account per customer, so a diagnosis of one tenant never touches another tenant's records. Every call it makes should land in an access log an auditor can read.

The agent also needs a stopping rule. Define how many calls it may make, how long it may run, and what it does when a system times out. A missing answer is a result worth reporting. Filling the gap with a plausible sentence is not. When a required system is unreachable, the honest output is a partial record naming the system it could not reach.

The useful pattern runs in two passes. The first pass collects account state, plan and entitlements, and recent configuration changes. It also pulls error events in a bounded window and the status of every dependency involved. Nothing is interpreted yet. Each fact carries its source and the time it was read, because a value pulled an hour ago may already be stale.

The second pass proposes causes and ranks them. A good ranking is not a single answer. It is two or three candidates, each with the facts that support it and the facts that argue against it. The agent should say what would settle the question. That last field is the most valuable one, since it tells the engineer which check to run next. Ties happen. When two candidates rest on the same evidence, the agent should say so rather than pick one.

Confidence has to come from the evidence, not from the model's tone. Tie it to what was actually retrieved. A cause supported by a matching error event and a matching config change is stronger than one inferred from the ticket text alone. Sometimes the deciding evidence sits inside an attached log. Reading that file is its own compression step, not a line to fold into the summary.

The following case is made up. A company sells virtual corporate cards to other businesses. A customer writes that a vendor payment was declined twice this morning, and that the card should have plenty of room on it. The agent has five read tools. They cover authorization events, spend controls, the ledger balance, the issuer status feed, and recent audit entries for the account.

The first pass returns facts. Two declines at 9:14 and 9:31, both with the reason code for a merchant category block. The card sits in a spend control group that allows four categories. The vendor's merchant category is not one of them. The ledger balance is $8,400, well above the $620 attempt. The issuer feed shows no incident. An audit entry from Tuesday shows an admin edited that control group.

The ranked output puts the category block first. It is supported by the reason code, the group membership, and the Tuesday edit. It puts a balance problem second and marks it as contradicted by the ledger. The settling check is written out: confirm with the customer whether Tuesday's edit was intended. The write-up runs to nine lines and links every fact to its call. The agent stops there. It does not change the control group, and it does not tell the customer the card is fine.

Four failures show up repeatedly, and each one is quiet. Stale reads look current. A dashboard cached ten minutes ago and an event stream read now can disagree. Timestamp every fact and show the read time next to the value.

Missing tools turn into invented reasoning. When the agent cannot see a system, it will fill the hole with the most common cause it has seen. Require it to name the systems it could not reach and to lower confidence accordingly.

Correlation gets written as causation. A config change on the same day as a failure is a lead, not a cause. Keep the two words apart in the template, so nobody has to infer which one the agent meant.

Long ticket text pulls the agent away from the systems. A detailed customer story reads as evidence, and the model weighs it like a log line. Treat the customer's account as a report and the systems as the record.

Volume hides a shared defect. An agent diagnosing tickets one at a time will write the same cause forty times and never notice the pattern. That view comes from grouping tickets that share an underlying defect, which runs across the queue rather than inside one ticket.

A suspected cause becomes a recorded cause only when a person accepts it. The reviewing engineer opens the linked evidence, checks that the calls returned what the summary says, and either confirms, edits, or rejects. Rejections matter more than confirmations. They name the cases where the agent's reasoning outran its facts, and they are the only reliable input for tightening the tool list.

Confirmation sometimes needs an actual attempt, not a second reading of the same data. Running the failing operation against a test account is a separate probe with its own safeguards. Use it when the evidence is thin, and skip it when the reason code already says everything. The choice between the two belongs to the engineer, not to a rule.

Escalation is a decision, not an output field. When the agent's top cause points at a product defect, filing it is a judgment about severity and reach. That handoff has its own path into engineering and a named owner on both sides.

Customer-facing wording stays with the human as well. The internal record can say merchant category block and cite the control group. What the customer reads should be checked by whoever owns the account relationship. The step after diagnosis is a reply, and that draft has its own grounding and review path.