Fix runs
A fix run is the agent working one issue. Each issue gets at most one: a thread of type fix_run that reaches the verdict and, on a confirmed problem, keeps working it to a fix in the same conversation.
What it does
The thread is where you read the whole story: the work as it happens, the evidence one click away in its lineage, and the outcome at the end. The run reads the alert or finding, the query behind it, recent metrics and logs around the firing, recent changes and your code. Before it acts, it writes the causal chain in the thread: the signal, the mechanism, the component and code path that produce it, the trigger and the blast radius, each link backed by named evidence or marked as unknown.
How it works
- A run starts when a check or a connected alert produces a finding, when an agent in a chat thread opens an issue from the problem you are discussing, or when you choose Investigate on an issue.
- The agent reads the evidence and reaches one of two verdicts,
confirmedordismissed. A finding that matches an existing issue joins it instead of starting a second run. - On a confirmed problem, the same agent traces the cause and writes the causal chain.
- When a code change fixes the cause in a connected repository, the run opens the pull request through autofix. When no pull request can fix it, the run raises an escalation that names what a person has to do.
- Every step lands on the issue's activity timeline, next to detections, re-detections and your own notes.
Outcomes
After each agent turn, Polylane classifies the run.
| Outcome | Description |
|---|---|
resolved | Root cause found and the problem is fixed or has recovered. |
diagnosed | Root cause found, but the fix has not landed. |
inconclusive | The agent could not settle on a cause. |
false_positive | The finding did not point at a real problem. |
failed | The run ended on an error. |
A run can also park, which stops monitoring from nudging it to re-investigate until the issue resolves.
| Parked state | Description |
|---|---|
needs_human_action | The fix requires something only you can do. |
needs_decision | The agent needs a call from you before continuing. |
awaiting_change | The agent is waiting for a fix to ship, for example a pull request awaiting review. This state parks quietly. |
failed | The run hit an error it could not work around. |
The three states that need a person are recorded as escalations, shown on the outcome card in the thread and listed under the Needs you preset, so the same ask never notifies you twice.
Where to find it
Fix runs appear under Threads alongside chat threads, and the Needs you preset lists the ones waiting on a person. The Lineage in the thread's sidebar holds the record behind the run: Issue opens the evidence and the issue's timeline, Escalation opens what the agent asked of you with Mark as handled, and Check opens the evaluation that detected the problem. The issue's menu carries Investigate, Investigate again, View investigation and View triggering check.
Configure
Under Settings > Workspace, the Investigations card sets Investigate automatically from: the lowest severity that starts a fix run on its own. Issues below it keep their verdict and are held, and their thread offers Start investigation so someone on your team can pick them up. Verdicts are never held: every confirmed issue is visibly confirmed, and the floor only defers the work that follows.
Related
- Issues for the record every fix run works.
- Threads for reading, stopping and sharing the run.
- Escalations for the asks a parked run raises.
- Autofix for the pull request a run opens.