Any agent can produce an answer. How do you know if it's right or wrong?
An agent worth putting in front of customers should be able to show its work.
Every AI support tool will tell you it resolved the ticket. Far fewer will show you how it got there. That gap matters, because a support engineer who cannot inspect the reasoning has no basis for trusting the answer, and a customer who receives a wrong answer confidently delivered is worse off than one who received no answer at all.
A trace closes that gap. It is the ordered record of everything the agent did on a single ticket: which tools it called, what came back, what it concluded from the results, and where a human stepped in. Here is what that record looks like as dekx works a ticket from arrival to reply.
Intake and routing
The ticket arrives from Zendesk or Jira or a GitHub issue and hits triage routing first. Routing rules live in YAML rather than in code, so the first entries in the trace are the ticket as received, the route it took, and the rule that sent it there. When a ticket lands in the wrong place, the trace points at a line of configuration an engineer can read and change, rather than at model behavior nobody can inspect.
Redaction
Before any customer text reaches an external model, the MCP server's PII guardrails strip it. The trace records that this happened, which is the entry a security reviewer will look for first and the one most systems cannot produce.
Retrieval
dekx runs two different paths depending on what it is looking for. Documentation, knowledge base articles, and past resolutions go through retrieval-augmented generation over BGE-M3 embeddings in pgvector, combined with lexical search. Source code goes through semantic search across the codebase instead, because matching a stack trace to the function that produced it is a different problem from matching a question to a paragraph. The trace records each query, what came back, and, just as importantly, what did not. An empty retrieval is a finding, not a failure to log.
Tool calls
From there the agent works through its MCP tools, gathering the context a human would otherwise gather by hand. Each call appends to a running evidence log as it completes, rather than the log being written once at the end. That ordering is deliberate. If the investigation fails partway through, the evidence gathered up to that point is still visible in the trace instead of being swallowed by the failure, and the engineer picking it up can see exactly how far the agent got.
Reproduction
Not every ticket needs one. When the documentation already answers the question, the trace records reproduction as skipped, and that is a complete outcome, not a shortcut. A run is reserved for cases where what the docs say and what the customer reports might diverge: a suspected defect, unexplained behavior, or a fix that has to be proven. Even then, the engineer approves the plan before anything runs. dekx doesn't execute code itself, so every run is guided. It takes the closest local sample on the latest release as the baseline, specifies the edits that apply the customer's configuration, and writes a runbook stating what to observe at each step. The engineer runs it, and the trace records exactly what they reported, nothing more. The verdict is reproduced, not reproduced, blocked, or skipped, and it always names who ran it. If a faithful attempt doesn't reproduce on the latest release, the resolution is an upgrade, unless the customer is already on it.
Investigation
By the time the agent starts, an engineer has already confirmed the triage. The agent's first move isn't a search. It consults a brief on the product: notes on its vocabulary, on gaps in its documentation, and on problem clusters that reliably end in escalation. The order matters, because customers describe symptoms in their own words, and the brief translates those words into the class and setting names the documentation actually uses. The brief is orientation, never evidence, so no note can be cited as the basis for an answer. The agent then dispatches four sub-agents in parallel, each scoped to a single source: documentation, known issues, similar past tickets, and local samples, which double as the search for a reproduction baseline. None of them sees the ticket itself. Each gets a few sentences of context on the product, version, platform, and symptom, and each flags whether its results point to a bug. That flag is a suspicion to test, not a verdict. When the results return, the trace answers one question before anything else: does what came back already resolve the ticket? A guide describing what the customer is trying to do counts as a resolution, quoted by its operative lines rather than merely cited. The agent also checks the changelog between the customer's version and the latest release for a matching fix, quoting any hit verbatim.
Verification audit
Before anything moves toward a plan, every API, class, method, and feature name the agent has referenced must appear in a search result or an attachment. Anything that doesn't is flagged and dropped. That catches a failure that is easy for a model and costly for a customer: a confident answer built on a setting or method that doesn't exist. The same discipline governs every claim that follows. Nothing in the trace is labeled reproduced, fixed, or verified without an actual run behind it, and the label always says who ran it. An honest "proposed" is worth more than a false "verified."
Root cause
Once an issue is reproduced, the agent works from the strongest evidence it has toward the code or configuration at fault. That evidence might be a stack trace, an exact error string, or the gap between expected and actual output. The agent searches the product source by symptom and symbol, reads the implicated implementation, and follows the code path far enough to explain the mechanism: what the code does, under which condition, and why that produces what the customer saw. When a run was blocked, the same tracing is driven by the customer's attachments instead. The fault is then classified as customer code, configuration, a product defect, the host platform, or undetermined, and that classification decides which fixes are on the table. The root cause lands in the trace as one or two sentences with its evidence chain attached. When the evidence won't support a conclusion, the trace says what is known, what has been ruled out, and what is still missing, instead of forcing one.
Fix
The fix path follows the fault:
- A question the documentation already answers gets the guide and its operative lines.
- A fault in customer code or configuration gets a customer-side fix.
- An issue that doesn't reproduce on the latest release gets an upgrade.
- A product defect gets a workaround, a patch when the engineer has the product source and build tooling, or a precise fix proposal carried into an escalation. The proposal names the file, the method, the change, and the reasoning.
Paths combine: a workaround for the customer today and an escalation for the underlying defect is a normal outcome. Whatever the path, the proof is a run. The engineer re-runs the exact reproduction that failed, and it has to pass, with output captured both times.
- A fix confirmed that way is verified, with the engineer named as the one who ran it.
- A resolution from a matching guide is documented, a complete outcome in its own right.
- A fix that rests on analysis alone stays proposed, and the trace says why.
If three fix attempts fail, the agent stops, records what each one revealed, and recommends escalation with that history attached. It never invents a fix for a problem nobody could confirm.
The human gates
The trace doesn't end with the model. It ends with a person, at every decision that matters. The pipeline stops for an engineer at three points:
- Triage, before the agent starts. The engineer confirms or corrects its first reading of the ticket: product, version, issue type, severity, and whether this looks like something the guides cover or something only a run can settle.
- Resolution plan. The first line states whether the ticket is already answered. The agent then recommends a depth, with alternatives beside it: a documented answer, a targeted run, a full guided reproduction, or blocked.
- Fix path. The agent states the root cause and recommends a path, again with alternatives.
Each gate is a real stop. The investigation is parked and the engineer is notified, rather than a question being buried at the end of a message. Escalation is always the engineer's decision and sits behind its own approval. The agent drafts the engineering ticket, and a person files it. The agent proposes, and the engineer decides. What the trace gives that engineer is the ability to decide quickly, because the reasoning is laid out in the order it happened, with each claim sitting next to the evidence behind it.
Read end to end, a trace serves three different readers. The engineer reviewing a draft uses it to approve in a minute rather than redoing the investigation. The team debugging a bad answer uses it to find the exact step that went wrong, whether that was a routing rule, a thin retrieval, or a conclusion that outran its evidence. And when a customer or an auditor asks how an answer was reached, the trace is the answer.