Use case

Alert fires. Agent investigates.

Connect PagerDuty or your monitoring stack. Agents trace errors, inspect logs and metrics, and post findings to Slack or open a fix PR.

Why this is hard

The first twenty minutes are always the same

Open the dashboard, find the error, check the deploy log, check the dependency status page. It is mechanical, and it happens at 3am.

Most pages are not incidents

A retry storm from one flaky third party looks identical to a real outage until someone reads the logs. That someone is currently asleep.

Context is gone by morning

The logs have rotated and the metric window has smoothed out. Whoever picks it up is investigating a memory of the problem.

What happens when a page fires

  1. The alert reaches an agent first

    It arrives with whatever the alert carries: service, error rate, trace, and the deploys that landed nearby.

  2. It gathers what a responder would

    Logs, metrics, recent commits, and dependency health, pulled through read-only gateway access so an investigation cannot become an outage.

  3. It forms a specific hypothesis

    Not "the API is unhealthy" but "error rate rose 4 minutes after deploy a3f21c, all failures on the /checkout path, all from one region."

  4. It escalates or opens a fix

    A real incident goes to a human with the investigation attached. A known, small cause gets a pull request instead of a page.

What you get back

  • Triage summary
  • Correlated timeline
  • Suspected commit
  • Pull request or escalation

What the agent can touch

Read-only gateway access to logs and metrics

Investigation cannot become an outage — the agent can pull signals but not write anywhere in production.

Deploys, errors, and traces on one timeline

Correlation is where most 3am pages stop being mysterious.

A hypothesis and evidence when someone gets paged

Not a dashboard link — a specific theory and the commits, traces, or dependency checks behind it.

Where teams go next

Common questions

What does the agent do when an alert fires?

Islo spins up or resumes an agent computer, loads logs and metrics, traces the failure, and posts findings to Slack or your incident channel.

Can the agent open a fix PR from an alert?

Yes. When the root cause is in your codebase, the agent can patch the issue, run tests, and open a PR.

Do I have to put production keys inside the agent computer?

No. Gateway policies scope egress and inject credentials at the boundary so keys never enter the agent computer or model context.

Can the agent post its incident findings to Slack?

Yes. Give the agent scoped access to the incident channel and it can post its findings, evidence, and links to any fix pull request.

What if the alert isn't caused by a code bug?

The agent can still report the evidence it found and the most likely source of the incident without changing code or opening a pull request.

Put this workflow on autopilot.