Overview
Between a decision and a change sits the part nobody wants to automate carelessly: something has to touch production, or open the pull request that will. The risk is not the action itself but who gets to approve it. Deploy it when a decision has been made and something has to actually change. It consumes the same input envelope as Remediation — a completed investigation’s findings — and hands the work to a system that can carry it out. It does not re-investigate; it instructs, and relays a typed outcome back.
Which one it uses is a configured choice, not something it decides mid-run.
For: the last step of an incident workflow, once a decision and an approval are behind it.
Not for: deciding whether to change something, and never for answering the approval that
guards the change.
The approval boundary
This is the part worth understanding before deploying it. When Klaudia pauses for an approval, this agent cannot answer it. The tool that would respond is denied to it in its own code, so a gate Klaudia raises comes back to a human every time. That holds regardless of how the agent is configured or what its instructions say — it is not a setting that can be relaxed. See Approvals for where those decisions land.Tools supported
The wizard’s tool checklist has no effect here: the agent fixes its own tool surface in the
implementation, so what it can do is decided there rather than by what you tick.
Scenario examples
It takes a completed investigation rather than a free-text instruction, so it is normally driven by a workflow step. Where you invoke it directly, pass the investigation to act on: Execute with an approval stopPrerequisites
Catalog ID:
remediation-executor — what the deploy API takes.
GitHub is optional because the cluster path does not use it. If you only ever remediate through
Klaudia, there is nothing to connect. Configure the source path without a connection behind it and
the agent refuses at validation rather than failing mid-run.
As part of a workflow
It is the final step, downstream of an investigation and usually of a decision. A typical incident workflow investigates, asks Remediation whether a change is warranted, routes the proposal through an approval, and only then reaches here. Putting it directly after an investigation skips the step that decides whether anything should change at all — which is a choice, but worth making deliberately.Limitations
- It cannot approve or reject on a person’s behalf. The tool that would answer an approval is denied to it in its own code, and no configuration relaxes that.
- It does not decide what the fix should be. It carries out what an investigation established, through a system that has its own controls.
- Its guardrails are the target system’s. On the live cluster they are Klaudia’s; on the source, the pull request still needs a reviewer.
- The target is configured, not chosen. It does not switch between the cluster and the source mid-run.
Recommended model
claude-sonnet-5 — the shipped default. The work is judgement over evidence someone else gathered,
where a weaker model produces confident-sounding conclusions that do not hold.
Next steps
Remediation
Decide whether a change is warranted first.
Approvals
Where a paused decision lands, and who may answer it.
Klaudia Investigator
The same Klaudia, used to investigate rather than to act.
Agent catalog
Every catalog agent, side by side.