Skip to main content
Deploy this agent when an incident is in AWS and the answer is somewhere in the control plane — a permission that changed, a resource that was modified, a dependency that went away. It reads AWS directly and returns structured findings with the evidence attached. This page covers what it reaches, what to connect first, and where it stops.

What it does

You give it an incident description and the questions you want answered. It traces root causes through configuration changes, access-control layers and resource dependencies, then returns findings that cite the CloudTrail event, metric or policy behind each claim. Findings come back structured, so an orchestrator can synthesize them with other specialists’ work rather than re-reading prose. Run it on its own and you get the same report in the run’s output.

What it reads

All of it read-only. The investigator has no mutating tool, in any deployment.

Before you deploy

The AWS connection offers two authentication modes, and which ones you see depends on where the agent runs:
The AWS connection is listed as optional because IRSA replaces it. If you deploy self-hosted with a ServiceAccount that already carries the role, the agent needs no connection at all.
A connection is validated as configuration, not as working AWS access. A well-formed role ARN with insufficient permissions deploys cleanly and fails on the first run, so read that run rather than treating a successful deploy as proof.

Ask it for

In chat, or as a run’s prompt:
When a workflow drives it instead of a person, it takes a structured envelope:

Defaults and limits

The time budget degrades rather than fails. At 70% the agent is told how long is left and nudged to close the chain it is on instead of opening another. At 100% further tool calls are refused and it reports what it has — so a long investigation returns a partial report rather than nothing.

In a workflow

This is a specialist, not a lead. In an incident workflow it takes a scoped sub-task from an orchestrator, investigates the AWS slice of the problem, and hands its findings back to be synthesized with the other specialists’ work. Add a second investigator for another system when an incident spans both — they run independently and their findings are combined. See Orchestration for how a step delivers work to it, and Incidents for the module that drives it.

What it will not do

It never changes anything in AWS. There is no mutating tool in its surface, in either deployment mode, so it cannot stop an instance, edit a policy or roll back a change — it can only tell you which one it thinks is responsible. Turning a finding into an action is Remediation Executor’s job. It also sees only what its credentials reach. An investigation scoped to one account cannot observe a cause that lives in another, and it reports the gap rather than inferring across it.

Next steps

Use specialized agents

Browse the catalog and walk the deploy wizard.

AWS Cost Analyzer

The same account, read for waste rather than incidents.

Runs & evidence

Read the tool calls behind a finding.

Agent catalog

Every catalog agent, side by side.