> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Remediation Executor
> Carries a finished investigation into action — briefing Klaudia to fix the live resource, or opening the pull request that fixes the source.
Deploy this agent when a decision has been made and something has to actually change. It takes a
completed investigation and delegates the fix, choosing between the live cluster and the source
repository depending on how you configure it. This page covers both paths, the approval boundary it
cannot cross, and where it stops.
## What it does
It consumes the same input envelope as [Remediation](/manage-your-agents/build/catalog/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.
| Target | What it does |
| ----------------- | -------------------------------------------------------------------- |
| The live resource | Opens a Klaudia chat session and instructs it to act on the findings |
| The source | Opens a pull request against the code that caused the problem |
Which one it uses is a configured choice, not something it decides mid-run.
## What it reads
| Source | What it uses it for |
| ---------------------------- | ------------------------------------------------------------------------ |
| The investigation's findings | The basis for what it instructs |
| GitHub | Reading the file being fixed, and opening the pull request that fixes it |
## Before you deploy
| Requirement | Detail | Where to set it up |
| ------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------ |
| Model access | The managed model gateway, or your own Claude API key | [Credentials & secrets](/manage-your-agents/build/credentials-secrets) |
| MCP group with a Komodor server | How it reaches Klaudia | [Integration groups](/manage-your-agents/build/integration-groups) |
| GitHub connection | Optional — required only for the source path | [Built-in integrations](/manage-your-agents/build/built-in-integrations) |
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.
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.
## 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](/security-and-governance/controls/approvals) for where those decisions land.
## Ask it for
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:
```text theme={null}
Take the findings from run 4f2a and remediate. Use the cluster path, and stop for
approval before anything changes.
```
## Defaults and limits
| | |
| ----------- | ------------------------------------------ |
| Catalog ID | `remediation-executor` |
| Model | `claude-sonnet-5` |
| Time budget | 600 seconds, adjustable 120–1800 per run |
| Deployment | Komodor cloud or self-hosted |
| Chat | No — it consumes an investigation envelope |
The time budget bounds this agent's run, not the remediation. Work it has delegated to Klaudia, and
any approval waiting on a person, continue past it.
## In a workflow
It is the final step, downstream of an investigation and usually of a decision. A typical incident
workflow investigates, asks [Remediation](/manage-your-agents/build/catalog/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.
## What it will not do
It cannot approve or reject on a person's behalf, as above.
It also does not decide what the fix should be. It carries out what an investigation established,
through a system that has its own controls — so the guardrails on the live cluster are Klaudia's,
and the guardrail on the source is that a pull request still needs a reviewer.
## Next steps
Decide whether a change is warranted first.
Where a paused decision lands, and who may answer it.
The same Klaudia, used to investigate rather than to act.
Every catalog agent, side by side.
## Related topics
- [Remediation](/manage-your-agents/build/catalog/remediation.md)
- [Agent catalog](/manage-your-agents/build/catalog/overview.md)
- [Klaudia Investigator](/manage-your-agents/build/catalog/klaudia-investigator.md)
- [GitHub Agent](/manage-your-agents/build/catalog/github-agent.md)
- [AWS Infrastructure Investigator](/manage-your-agents/build/catalog/aws-investigator.md)