Why coding-agent harnesses don’t fit RCA
Six things a coding-agent harness takes for granted, and how a production incident breaks every one of them. The model is not the problem.
Adapted from a talk by Omid Gosha at Signals Berlin 2026.
Coding agents got good fast. Point one at a repository, describe a change, and it reads the files, writes the patch, runs the tests, reads the failure and goes again. That loop works. It is most of why these tools feel like magic.
Then people point the same tool at a production incident. The agent is busy, the engineer is delighted, and production is quietly going under while both of them are looking the other way.
The model did not get worse. The model is the smaller half of this. What separates one agent from another is the harness, the loop that decides what it reads, what it is allowed to run, and when it may stop. There are six parts of that loop, and an incident wants different behaviour from every one of them.
01 Ending state
Write a function that sorts a list and a dozen implementations pass. Pick any of them and ship it. The harness can stop the moment one candidate survives the tests, because the set of acceptable endings is large and you only have to land somewhere inside it.
An incident does not work that way. Something specific broke for a specific reason. An agent that confidently reports a different cause has not partly succeeded. It has done damage, because somebody is now going to go and fix the wrong thing.
Coding agent
N ≥ 1 accepted ending state
Many implementations pass. Any of them can be the answer.
RCA agent
N = 1 accepted ending state
One root cause is true. Every other ending is wrong.
02 Budget
Both loops can burn tokens. Spend more on a coding task and you usually get a better patch, and nobody minds waiting another ninety seconds for it.
An incident has a clock on it and the clock belongs to the customer. There is a point past which the answer stops being worth anything no matter how good it is. So the time budget gets fixed before the work starts, and the harness has to return its best answer inside that window rather than its best answer eventually.
Coding agent
RCA agent
Both can spend tokens. Only one of them is allowed to spend time.
03 Discovery
A coding agent starts by exploring. It greps, opens files, follows imports, and assembles a picture of the codebase as it goes. That is fine when exploring is cheap and the clock is generous.
During an incident it is neither. Working out that this service talks to that queue, at the exact moment you need to know it, spends the budget you needed for the reasoning. The map has to already exist. That is why ewake builds and maintains a graph of production before anything breaks, so an investigation starts from the topology instead of from a blank prompt.
Coding agent
Incomplete topology. Connections get discovered on the fly, under the clock.
RCA agent
A complete map. Every connection is already made before the incident.
04 Ground truth
A repository is a fixed thing. Check out a commit and it will be the same commit tomorrow.
Production is not fixed, and what it emits is high cardinality. Every request carries a user, a region, a version, a customer. An answer that was right four minutes ago can be wrong now, and a harness built around a stable snapshot will keep reasoning carefully about a system that has already moved.
Coding agent
The code repository is static over a period of time.
RCA agent
Production moves, and it works with high-cardinality data.
05 Confidence
This is the one that hurts people. Somewhere in the chain the agent decides that service B is backed by repo A. Sometimes it knows that. Sometimes it inferred it from a naming convention and a coincidence.
A coding harness has nowhere to put that difference, so by the time the chain reaches a conclusion the guess and the fact read exactly alike. An RCA harness has to carry the uncertainty all the way through, so a verdict resting on a shaky hop says so instead of arriving in the same confident voice as one resting on a call graph.
Coding agent
Every hop reads as fact. Nothing tracks how much of the chain was guessed.
RCA agent
An inferred hop carries its own confidence, and the verdict inherits it.
06 Verification
Generate, test, read the failure, generate again. The test is the oracle, it is free to run, and it is honest. The loop can be sloppy and still converge, because something outside the agent keeps telling it whether it is done.
RCA has no oracle. You cannot run the incident again to find out whether your explanation was right. So the loop changes shape. You generate hypotheses, go and collect evidence for and against each one, score them, and keep going until one is far enough ahead of the rest to be worth a human's attention. The exit condition is not "it passed". It is "this one beats the alternatives by enough".
Coding agent
RCA agent
Exit condition
Functionality achieved, verified by tests.
Exit condition
Hypothesis score is higher than a threshold, among minimum N hypotheses.
Harness is just different
None of this makes coding agents bad, and none of it is about the model. Point the same model at both problems and it is the same model. What changes is everything wrapped around it. How many endings count as correct. What you are allowed to spend. What you already know when you start. Whether the ground moves under you. Whether a guess is marked as a guess. And what finally makes the loop stop.
Get those six wrong and you have built a very fast way to sound certain about the wrong service. That is why we build the harness separately, and why a tool that writes excellent code does not become a root cause tool just because you pointed it at your logs.
Once the cause is known and the fix is a code change, hand it to a coding agent. That handoff is worth building. It is just not the same loop.
See ewake on your own stack
The fastest way to understand ewake is to point it at something real.