# What the platform does

> The seven agents, the path from an alert to a verified fix, connections and roles, what spends model budget, and the guardrails that never switch off.

_Concept · Updated 2026-10-25 · Describes release 0.1.164_

The platform receives the alerts and findings your systems already raise, groups them into incidents, investigates each one with an AI agent over read-only connections, and turns a proposed fix into a change request that a person approves. An approved fix runs through a separate write credential, and the platform then checks that the condition really cleared. Everything an agent reads or proposes is recorded on the incident; every decision a person takes lands in the audit trail.

## Seven agents, one pipeline {#agents}

Every workspace has seven pillar agents, all enabled when the workspace is created and none with a schedule; you disable or schedule each one on [Agent behaviour](/portal/agents) (in the product: `/portal/agents`). The short id is what the API and the audit rows use.

| Agent | Id | What it does |
|---|---|---|
| Incident & Problem | `incident` | Investigates an alert or a storm across the connected datasources, localises the root cause, assesses the blast radius, proposes the minimal safe fix and drafts the RCA. Runs when an alert opens an incident. |
| Compliance | `compliance` | Works the findings of your cloud's own scanners (AWS Security Hub, AWS Config, Microsoft Defender for Cloud) by domain — posture, vulnerability, patching, backup — and, once the platform turns them on (phase 2, off today), the platform's own checks against SOC 2 and ISO 27001; it never executes a fix — a failing control becomes a change request or a finding for a person. |
| Change Mgmt | `change` | Produces the execution plan, the post-change verification and the rollback before any apply is proposed. |
| SecOps | `secops` | Triages a security finding against logs and configuration, judges severity and credibility, and proposes containment as gated actions. |
| FinOps · Optimise | `finops` | Detects cost anomalies and pulls the cloud providers' own recommendations through your connectors. Recommendations only. |
| Continuous Improve | `improvement` | Reads closed incidents, approval decisions and corrections; drafts postmortems and proposed skills. |
| Exec Reporting | `reporting` | Aggregates incidents, compliance posture, change success and cost into a digest. |

A disabled agent still receives alerts: the incident opens, its analysis fails with `pillar disabled or unconfigured`, and the incident escalates to a person.

## From an alert to a verified fix {#pipeline}

Every incident page shows the same seven layers under **How this incident was handled (L1–L7)**; each step says who did it — code, the AI agent or a person — and what it concluded.

1. **L1 Signals received** (code). Your alert source posts to the workspace webhook; the alert is normalised, deduplicated on its identity and recorded with where it came from and when.
2. **L2 Service correlation & noise suppression** (code). Alerts that share a service, a change window or a cause fold into one incident; services failing together are grouped under the one they depend on, and unrelated ones stay separate; cascading alerts are suppressed behind their root. **How these were grouped** shows the mechanics.
3. **L3 Incident creation & routing** (code). The incident gets its severity from the worst alert, a priority P1–P4 from severity and blast radius, an assignee from your assignment map, and its pillar. A connected ticket system gets a ticket at this point.
4. **L4 Automated triage** (agent). One investigation runs over the read connections, within the cost cap, and ends in a structured wrap-up: root cause, evidence, confidence and a remediation plan. A fix validated on an earlier incident with the same signature is offered to the agent first.
5. **L5 Remediation & approval** (person). The wrap-up mints a change request with a class — standard, normal or emergency — and a tier. An operator requests it, an approver releases it. A fix a certified runbook matches exactly is a standard change, released under the standard rules even for a P1; any other P1 or critical fix is an emergency change (L3), which needs two different approvers. A person may only raise a class — normal to emergency. A certified runbook may open its pull request without a per-incident click. The fix runs through the change executor and a connection allowed for approved plans, never through an investigation tool.
6. **L6 Validation & normalisation** (agent, code first). After a fix or a close, code checks the condition is gone where it can — a typed fix is verified by its own read at no cost — and a paid agent run is the last resort. A verdict of *still present* reopens the incident; **Verify** always runs the agent.
7. **L7 RCA & problem management** (agent). The RCA is written to the incident with its occurrence class (new, reopened — the same alert on the same resource, `recurring ×N` on a new incident's chip — or `repeated` — the same issue under another key, on the same resource for a cloud alert that names one), its remediation history and timeline; the ticket is updated and closed, and a recurring signature opens a problem record.

## Connections: reading and writing are separate {#connections}

A connection is one connected instance of a connector type — this cluster, that cloud account, your metrics server. Each carries a role, chosen under **Use this connection for**: **Investigate only** (`read`, the default) is what the agents see; **Approved changes only (separate credential)** (`write`) is a remediation-only credential that no agent can see, name or call; **Investigate and approved changes (same credential)** (`read_write`) is one identity used through the same read-only tool boundary. A write role does nothing until **Allow use for approved plans** is switched on, and switching it on approves no individual plan.

Three other inputs are not connections in this sense: an **alert source** posts to the workspace webhook and holds none of your credentials; a **private-network agent** is a container inside your network that performs the reads when the platform cannot reach a system; a **ticket system** connection files, updates and closes tickets. [Choose your connection](/help/choose-your-connection.md) compares them.

An AWS, Azure or Kubernetes read connection is also **harvested**: a deterministic read of its inventory that feeds the Estate map and the blast radius. The harvest is a required onboarding step.

## Roles and permissions {#roles}

Access is a set of sixteen permission keys, such as `incidents.view`, `datasources.manage` and `approvals.decide`, grouped into five builtin roles: **owner** (every permission, including members and roles), **operator** (day-to-day work — analyse incidents, connect sources, request approvals and suppressions — but cannot approve, suppress or release), **approver** (read access plus the decisions: change releases, risk requests, suppressions and paused agent actions), **viewer** (read-only) and **executive** (reads everything, asks the insights chat, approves risk requests and changes). An operator requests, an approver decides and runs. Owners can add custom roles from the same keys; single-sign-on groups can map to roles but can never grant `members.manage` on their own. [Permissions](/help/permissions.md#the-permission-matrix) has the full matrix.

## What spends model budget, and what is free {#costs}

Free, because code does it: receiving, deduplicating, correlating and routing alerts; the estate harvest; connection tests; the platform checks on your cloud connections; and every validation code could answer, which **Usage & billing** counts as free checks.

Paid, because a model runs: the L4 investigation of each incident, the insights chat, an Estate x-ray scan (up to the **Budget (USD)** set at launch, 25 USD by default and capped by the platform's per-scan ceiling), a validation that reached the agent, and — while **Analyse P1/P2 findings automatically** is on — one analysis per P1 or P2 compliance finding. Test Lab runs are test spend, outside the operating figures. [Usage & billing](/portal/billing) (in the product: `/portal/billing`) shows the month by class, model and incident.

The **cost cap per investigation** on [Guardrails & cost](/portal/guardrails) (in the product: `/portal/guardrails`) bounds one run: at 70% of the cap the loop drops one model tier; at 100% the run stops before the next model call, with no wrap-up, and the incident escalates to a person. An empty field follows the platform default; `0` removes the cap. **AI budgets & kill switch** adds daily and monthly limits for the workspace, a per-incident limit, and **Pause all agents**. Alerts and incidents keep recording whatever a budget does. `$0.0000` while agents clearly ran means the model is not priced yet, never that it was free.

## Guardrails that never switch off {#floors}

The floors on the Guardrails page are code, not settings; your configuration can add gates on top but never remove one.

- **Write floor** — investigation tools refuse mutating or unknown estate operations, even when the credential could perform them; changes use a separate server-validated plan, an eligible connection and an exact approval.
- **Credential execution boundary** — remediation-only connections stay outside investigation registries; a shared connection stays read-only there.
- **X-ray read-only** — estate scans run in a read-only registry; a gated call is denied outright, never paused.
- **PII scrub-at-capture** — everything the agents capture is pseudonymised before it lands anywhere; there is no off switch.
- **Untrusted-input fencing** — estate data is delimited as data, never instructions, so a prompt-injected agent still hits the write floor.
- **Egress control** — web fetches outside your allowlist never run on the agent's say-so, search queries are scrubbed before they leave the platform, and private and metadata addresses are blocked.

## Where to go next {#next}

1. [Start here: your first investigation](/help/getting-started.md) — connect one read source, harvest it, send a test alert and read the answer.
2. [Send your first alert](/help/send-first-alert.md) — the test alert, its receipt and the incident it opens.
3. [Rehearse your first approved fix](/help/first-approved-fix.md) — add a write credential ([Write connections and approved fixes](/help/setup-write-connections.md)) and rehearse one approved fix.

Not sure what to connect? Read [Choose your connection](/help/choose-your-connection.md). Terms are in the [Glossary](/help/glossary.md).


## Next steps

- Next: [Start here: your first investigation](/help/getting-started.md)
- [All Get started pages](/help/get-started/llms.txt)
- [Documentation home](/help/)