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

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 (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

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

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 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

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 has the full matrix.

What spends model budget, and what is free

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 (in the product: /portal/billing) shows the month by class, model and incident.

The cost cap per investigation on Guardrails & cost (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

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

Where to go next

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

Not sure what to connect? Read Choose your connection. Terms are in the Glossary.

Next steps