diff --git a/src/content/docs/docs/alerts/alert-groups.mdx b/src/content/docs/docs/alerts/alert-groups.mdx
index 621b929a..ffb91dc2 100644
--- a/src/content/docs/docs/alerts/alert-groups.mdx
+++ b/src/content/docs/docs/alerts/alert-groups.mdx
@@ -1,6 +1,6 @@
 ---
 title: "Alert Groups"
-description: "Group related alerts into a single notifiable incident, with firing instances, an audit log, and dispatched notifications all in one place."
+description: "Group related alerts into one incident, and see its affected resources, root cause analysis, instances, and notifications on one page."
 sidebar:
   order: 6
 ---
@@ -14,7 +14,7 @@ An Alert Group forms by static grouping or by the AI correlation engine. Both pr
 - **Static grouping** folds alerts together by the deterministic group-by keys on a routing rule. Alerts that share those label values land in one group.
 - **Auto (AI) grouping** hands the decision to the correlation engine, which links related alerts on its own and learns which alerts tend to fire together over time.
 
-You choose the mode per routing rule; see [Routing Rules](../routing-rules/#alert-grouping-static-or-auto-ai). For how membership is decided in each mode, and why a single rule firing on many hosts stays one Auto group, see [How Alert Grouping Works](../how-alert-grouping-works/). However a group forms, it behaves the same everywhere else on this page. An Auto-correlated group also records [why its alerts were grouped](#why-these-were-grouped).
+You choose the mode per routing rule; see [Routing Rules](../routing-rules/#alert-grouping-static-or-auto-ai). For how membership is decided in each mode, and why a single rule firing on many hosts stays one Auto group, see [How Alert Grouping Works](../how-alert-grouping-works/). However a group forms, it behaves the same everywhere else on this page. An Auto-correlated group also records [why its alerts were grouped](#grouped-by).
 
 ## Where to find groups
 
@@ -41,88 +41,110 @@ Severity isn't a filter on the list.
 
 A group carries:
 
-- **Title:** for a **Static** group, the rendered **Title** annotation when every instance that opened the group renders the same text, and otherwise the name of the alert that opened it. The correlation engine names an **Auto (AI)** group. See [Set a custom notification title](../annotations-and-severity/#set-a-custom-notification-title).
+- **Title:** for a **Static** group, the rendered **Title** annotation when every instance that opened the group renders the same text, and otherwise the name of the alert that opened it. An **Auto (AI)** group gets its title from the correlation engine. See [Set a custom notification title](../annotations-and-severity/#set-a-custom-notification-title).
 - **Severity:** the most severe **Severity** annotation among the instances that opened the group.
 - **State:** **Firing** while at least one underlying instance is firing, and **Resolved** as soon as none is. A firing group whose firing instances are **all silenced** stays **Firing** and is marked **Muted**. Muting gates notifications; it doesn't resolve the group.
 - **Labels:** the labels that define the group, read from the alerts that joined it (the group-by keys, in Static mode).
 - **Alerts and instances:** how many distinct alerts and firing instances the group holds so far.
 - **Routing rule:** the rule that opened the group.
 - **Group ID:** the durable identifier you can share with teammates or paste into the assistant.
-- **Correlation reason:** for an Auto-correlated group, why these alerts were grouped. See [Why these were grouped](#why-these-were-grouped).
+- **Grouped by:** for an Auto-correlated group, why its alerts were grouped. See [Grouped by](#grouped-by).
 - **Investigation:** a root-cause investigation, when one is attached. Start it manually with **Run RCA**, or automatically with [Auto-RCA](../auto-rca/); see [Run RCA and View RCA](#run-rca-and-view-rca).
 
 ## Group detail
 
 Click a group's title to open its detail page.
 
-![Alert group detail page: the Run RCA, Ask Assistant, and Silence this group buttons above the Instances panel](./images/alert-group-detail.png)
+![An alert group's detail page: the facts row with Grouped by and the Correct and Wrong buttons, the Root cause analysis card, and the Affected resources table](./images/alert-group-detail.png)
 
 ### Header
 
-- **Title:** named from the alerts that opened the group. See [Anatomy of a group](#anatomy-of-a-group).
 - **Run RCA / View RCA:** starts or opens a root-cause investigation for the group. See [Run RCA and View RCA](#run-rca-and-view-rca).
 - **Ask Assistant:** opens the assistant chat panel with the group's labels, state, alert and instance counts, and routing rule pre-loaded into the prompt, so you can start investigating without retyping context.
 - **Silence this group:** opens the silence creator with matchers derived from the group, bound to the group so the silence lifts when the group resolves. The binding sets when the silence ends, not what it mutes: the silence covers any alert in the workspace whose labels match its matchers, group member or not. See [From an Alert Group](../silences/#from-an-alert-group).
 
-### Instances
+### Facts
 
-The **Instances** panel lists the unique alert instances in this group. Filter it by **All**, **Firing**, or **Resolved**; it shows **Firing** instances by default.
+The row under the title shows the group's **Status** and how long it has been in that state, how many **Instances** are firing, the **Last update**, and the routing rule under **Routed by**. Click the rule to open it.
 
-- **Common labels:** labels shared by every instance, so the per-row labels column only shows what varies.
-- **Columns:**
-  - **State:** **Firing** or **Resolved**. Instances muted by a silence or maintenance window are also marked **Muted**, so you can see at a glance which ones are firing but suppressed.
-  - **Value:** the last evaluated value behind the instance's state.
-  - **Alert:** the alert rule name. Links to the rule when the alert is KloudMate-native (carries an `alarm_id` label).
-  - **Instance labels:** the labels that distinguish this instance from its siblings (common labels are stripped out).
-  - **Since:** how long this instance has been in its current state.
+On an **Auto (AI)** group with more than one instance, the row also shows the **Grouped by** reason and the **Was this grouping correct?** buttons. A **Static** group has neither.
+
+### Grouped by
+
+**Grouped by** shows the strongest reason the correlation engine put these alerts together: **Same alert**, **Shared label**, **Fired together**, **Known cascade**, **Topology**, or **AI**. For what each reason means, see [Why alerts group in Auto mode](../how-alert-grouping-works/#why-alerts-group-in-auto-mode).
 
-Use this panel to see what's firing inside the group at a glance. Switch to **All** to see, for example, that service A's `prod` and `staging` are firing while `dev` has already recovered.
+Hover over the reason to see the details: a sentence that explains the grouping, the likely root resource when there is one, the labels the alerts share, and any further reasons. For example, a group can show "Fired together 14 times in the last 30 days" or "Alerts on directly connected resources: pods and deployments."
+
+### Cold start
+
+A new workspace has little co-occurrence history for the engine to learn from, so it leaves most alerts as separate groups of one, with no **Grouped by** reason. That's expected. Correlation strengthens over the following days as the engine sees which alerts tend to fire together.
+
+### Rate the grouping
+
+Under **Was this grouping correct?**, click **Correct** or **Wrong**. When you click **Wrong**, pick the alert that doesn't belong, or mark the whole group as wrong.
+
+Your answer trains the correlation engine: a **Wrong** answer makes it less likely to pair those alerts again, and **Correct** reinforces the grouping. The current group doesn't change.
 
 ### Run RCA and View RCA
 
 The root-cause button's label depends on whether an investigation is attached:
 
 - **Run RCA:** shown when no investigation is attached. It starts a root-cause investigation for the group on demand.
-- **View RCA:** shown once an investigation is attached. It opens the root-cause summary, which links to the full investigation.
+- **View RCA:** shown once an investigation is attached. It opens the full analysis in a side panel, with a link to the full investigation.
+
+When an investigation is attached, a **Root cause analysis** card appears under the facts row. It gives a short overview and the numbered findings, each with its confidence, such as **Medium confidence**. Click **Read full analysis** to open the side panel.
 
-This is the manual trigger. To investigate every group a rule opens automatically instead, enable [Auto-RCA](../auto-rca/) on the routing rule; the result appears under the same **View RCA**.
+This is the manual trigger. To investigate every group a rule opens automatically instead, enable [Auto-RCA](../auto-rca/) on the routing rule. The result appears in the same card and under **View RCA**.
 
 ![View RCA drawer with the root-cause summary and a View full investigation link](./images/alert-group-rca-drawer.png)
 
-### Tabs
+### Affected resources
 
-- **Alerts:** one row per alert rule in the group, with its state, how many of its instances are firing, and when it was last seen. The alert name links to its rule when the alert is KloudMate-native.
-- **Blast radius:** what the group's firing resources connect to. See [Blast radius](#blast-radius).
-- **Audit:** a timeline of the group's history, from when it opened to when it resolved. It records each notification and reminder sent, notifications suppressed by a silence or skipped, and investigations. For Auto-correlated groups, it also logs when the engine opened the group and when it correlated each alert.
-- **Notifications:** every notification sent for the group, reminders included, with each channel's result and a link to where it landed: the Slack thread, the Jira ticket, the KloudMate Incidents incident, and so on.
+**Affected resources** lists the resources that the group's alerts are about, one row per resource. The resource that started firing first is at the top, because in a cascade the first to fire is usually the closest to the cause.
 
-![Reminder on an alert group Audit tab](./images/alert-group-audit-reminder.png)
+Each row shows the resource, its type, and where it runs, such as a Kubernetes cluster and namespace. For a Kubernetes workload, **Pod that fired** shows the pod and the node it runs on. A red dot next to the node means the node has alerts of its own. Hover over the dot to see them.
 
-### Blast radius
+Expand a row to see what the resource connects to, grouped by relation, such as **Runs on** or **Talks with**, with how many of those resources are alerting. A connected resource that belongs to this group is marked **In this group**.
 
-The **Blast radius** tab resolves the group's firing alerts to the resources they name, then graphs what each one depends on, so you can see how far the incident reaches.
+If an alert doesn't match any resource, it's counted under the table. Hover over the count to see why.
 
-Each affected resource anchors its own graph, its neighbors connected by labeled edges: **runs on**, **talks to**, **calls**. Neighbors of the same kind collapse into one node (for example, *116 Pods · runs on*) that you click to list them.
+### Related alerts and resources
 
-The same graph appears on a single alert's **Blast radius** tab and on a resource's **Dependencies** tab in Cloud Inventory. An empty graph means KloudMate hasn't mapped a connection yet, not that the lookup failed. When nothing is firing or the alerts don't match a known resource, there's no graph to draw.
+The **Related** card lists clues to the cause from around the affected resources:
 
-![The Blast radius tab: a row of affected resource chips above a graph of each resource and what it runs on](./images/alert-group-blast-radius.png)
+- **Nodes with alerts:** nodes that run a pod that fired and have alerts of their own.
+- **Connected resources with alerts:** resources that the affected resources connect to and that have alerts of their own. Resources that the affected resources depend on come first, because they're more likely to be the cause.
+- **Other alerts on the affected resources:** alerts outside this group that are firing on the same resources.
+- **Shared resources with no alerts:** resources that two or more affected resources connect to, such as a database that two workloads both talk to.
 
-### Why these were grouped
+When a tooltip on this page lists alert rules, click a rule to open it in a new tab.
 
-**Why these were grouped** gives the reason in plain English, the shared labels, and supporting detail.
+![The Related card listing nodes with alerts, a connected resource with alerts, and other alerts on the affected resources, above the Instances, Alerts, Notifications, and Audit tabs](./images/alert-group-related.png)
 
-This reason appears only when the engine grouped more than one alert instance, either several alerts or the same alert firing on multiple targets. A lone instance the engine left on its own has none, which is expected (see [Cold start](#cold-start)).
+### Tabs
 
-### Cold start
+Each tab shows how many items it holds, such as **Instances (7)**.
 
-A new workspace has little co-occurrence history for the engine to learn from, so it leaves most alerts as separate singletons with no correlation chip. That's expected, not a failure. Correlation strengthens over the following days as the engine sees which alerts tend to fire together.
+- **Instances:** every unique alert instance in the group. See [Instances](#instances).
+- **Alerts:** one row per alert rule in the group, with its state, how many of its instances are firing, and when it was last seen. The alert name links to its rule when the alert is KloudMate-native.
+- **Notifications:** every notification sent for the group, reminders included, with each channel's result and a link to where it landed: the Slack thread, the Jira ticket, the KloudMate Incidents incident, and so on.
+- **Audit:** a timeline of the group's history, from when it opened to when it resolved. It records each notification and reminder sent, notifications suppressed by a silence or skipped, and investigations. For Auto-correlated groups, it also logs when the engine opened the group and when it correlated each alert.
 
-### Feedback
+![Reminder on an alert group Audit tab](./images/alert-group-audit-reminder.png)
 
-You can rate the grouping **Correct** or **Wrong**.
+### Instances
+
+The **Instances** tab lists the unique alert instances in this group. It opens on the **Firing** instances, or on **All** of them when the group is resolved. Filter it by **All**, **Firing**, or **Resolved**.
+
+- **Common labels:** labels shared by every instance, so the per-row labels column only shows what varies.
+- **Columns:**
+  - **State:** **Firing** or **Resolved**. Instances muted by a silence or maintenance window are also marked **Muted**, so you can see at a glance which ones are firing but suppressed.
+  - **Value:** the last evaluated value behind the instance's state.
+  - **Alert:** the alert rule name. Links to the rule when the alert is KloudMate-native (carries an `alarm_id` label).
+  - **Instance labels:** the labels that distinguish this instance from its siblings (common labels are stripped out).
+  - **Since:** how long this instance has been in its current state.
 
-Choosing **Wrong** lets you point at the specific alert that doesn't belong, or mark the whole group as wrong. That feedback trains the correlation engine: a **Wrong** verdict makes it less likely to pair those alerts again, and **Correct** reinforces the grouping.
+Use this tab to see what's firing inside the group at a glance. Switch to **All** to see, for example, that service A's `prod` and `staging` are firing while `dev` has already recovered.
 
 ## When a group resolves
 
diff --git a/src/content/docs/docs/alerts/auto-rca.mdx b/src/content/docs/docs/alerts/auto-rca.mdx
index c9d6c8fb..c7be0441 100644
--- a/src/content/docs/docs/alerts/auto-rca.mdx
+++ b/src/content/docs/docs/alerts/auto-rca.mdx
@@ -15,7 +15,7 @@ When a routing rule with Auto-RCA enabled opens a group, KloudMate schedules an
 
 When the investigation completes, its summary attaches to the group:
 
-- You can open the summary from the group with **View RCA**, which also links to the full investigation. See [Run RCA and View RCA](../alert-groups/#run-rca-and-view-rca).
+- The group's page shows a **Root cause analysis** card with a short overview and the numbered findings. Click **Read full analysis** or **View RCA** to read the whole analysis, which links to the full investigation. See [Run RCA and View RCA](../alert-groups/#run-rca-and-view-rca).
 - The notifications dispatched from the group include the investigation summary, where the channel format supports it: a Slack thread reply, a KloudMate Incidents comment, and so on.
 
 :::note[One investigation per group]
diff --git a/src/content/docs/docs/alerts/create-alerts.mdx b/src/content/docs/docs/alerts/create-alerts.mdx
index c4cd2f6a..c7885c9b 100644
--- a/src/content/docs/docs/alerts/create-alerts.mdx
+++ b/src/content/docs/docs/alerts/create-alerts.mdx
@@ -246,14 +246,13 @@ Click **Save** to save the alert, or **Save & Close** to save it and return to t
 
 To open an alert, select its name on the **Rules** tab. The detail page has these tabs:
 
-![Alert detail page with the Overview, Instances, Blast radius, History, and Rule tabs](./images/alarm-detail-overview.png)
-
 - **Overview:** instance states, breaching instances with their labels, reason, and duration, plus recent state transitions.
 - **Instances:** the full list of alert instances and their current states.
-- **Blast radius:** the resources the alert's instances map to, and what those resources depend on.
 - **History:** the state-change history over time.
 - **Rule:** the alert configuration and query definition.
 
-![Blast radius tab on an alert rule](./images/alarm-detail-blast-radius.png)
+![The Overview tab of an alert rule: instance states, breaching instances with their value and last seen time, and recent transitions](./images/alarm-detail-overview.png)
+
+To see which resources the firing alerts affect, and what else is alerting around them, open their [alert group](../alert-groups/#affected-resources).
 
 The instance tables on **Overview** and **Instances** also show each instance's last evaluated value and when it was **Last seen**.
diff --git a/src/content/docs/docs/alerts/how-alert-grouping-works.mdx b/src/content/docs/docs/alerts/how-alert-grouping-works.mdx
index 12414665..bf0b8212 100644
--- a/src/content/docs/docs/alerts/how-alert-grouping-works.mdx
+++ b/src/content/docs/docs/alerts/how-alert-grouping-works.mdx
@@ -19,7 +19,7 @@ One alert rule can fire on many targets at once. A `High CPU` rule fires once pe
 
 Every alert runs through a [routing rule](../routing-rules/), and each rule groups its alerts one of two ways.
 
-**Static** grouping is deterministic: you name the labels, and alerts that share those values land together. **Auto (AI)** grouping hands the decision to the correlation engine, which links related alerts on its own and learns which of your alerts tend to fire together over time.
+**Static** grouping is deterministic: you pick the labels, and alerts that share those values land together. **Auto (AI)** grouping hands the decision to the correlation engine, which links related alerts on its own and learns which of your alerts tend to fire together over time.
 
 | | **Static** | **Auto (AI)** |
 |---|---|---|
@@ -48,15 +48,15 @@ Some rules you *do* want split per host, like a disk-filling-up check. Switch th
 
 Auto grouping analyzes each burst of alerts and links them on the strongest connection it can find, in this order:
 
-1. **Same rule:** every firing of one rule (always together, as above).
-2. **Same identity label:** firings that share a `key=value`, like `pod=api-7`.
-3. **Fire together often:** alerts with a track record of going off at the same time.
-4. **Cause and effect:** a known pattern where trouble in one resource sets off another.
-5. **Connected resources:** the two are linked in the dependency graph.
-6. **AI grouping:** a machine-learning model makes the call on whatever's left.
+1. **Same alert:** every firing of one rule (always together, as above).
+2. **Shared label:** firings that share a `key=value`, like `pod=api-7`.
+3. **Fired together:** alerts with a track record of going off at the same time.
+4. **Known cascade:** a known pattern where trouble in one resource sets off another.
+5. **Topology:** the alerts are on resources that are directly connected.
+6. **AI:** a machine-learning model makes the call on whatever's left.
 7. **On its own:** nothing links it, so it stays a group of one.
 
-However alerts link, the group shows the reason under [**Why these were grouped**](../alert-groups/#why-these-were-grouped), naming the strongest connection that covers the whole group. The engine also learns continuously: a new workspace starts with less history, and grouping gets more precise over the first few days as the model sees which alerts travel together. See [Cold start](../alert-groups/#cold-start).
+However alerts link, the group's [**Grouped by**](../alert-groups/#grouped-by) fact shows the strongest connection that covers the whole group. Hover over it for the details, such as "Fired together 14 times in the last 30 days." The engine also learns continuously: a new workspace starts with less history, and grouping gets more precise over the first few days as the model sees which alerts travel together. See [Cold start](../alert-groups/#cold-start).
 
 ## How Auto grouping behaves
 
@@ -71,4 +71,4 @@ Auto grouping follows a few predictable rules:
 ## Related
 
 - [Routing Rules](../routing-rules/): set the grouping mode and Group-by keys.
-- [Alert Groups](../alert-groups/): the group you get, and where the grouping reason shows.
+- [Alert Groups](../alert-groups/): the group you get, and where its **Grouped by** reason shows.
diff --git a/src/content/docs/docs/alerts/images/alarm-detail-blast-radius.png b/src/content/docs/docs/alerts/images/alarm-detail-blast-radius.png
deleted file mode 100644
index 91f16985..00000000
Binary files a/src/content/docs/docs/alerts/images/alarm-detail-blast-radius.png and /dev/null differ
diff --git a/src/content/docs/docs/alerts/images/alarm-detail-overview.png b/src/content/docs/docs/alerts/images/alarm-detail-overview.png
index c368c4cb..9343f19c 100644
Binary files a/src/content/docs/docs/alerts/images/alarm-detail-overview.png and b/src/content/docs/docs/alerts/images/alarm-detail-overview.png differ
diff --git a/src/content/docs/docs/alerts/images/alert-group-blast-radius.png b/src/content/docs/docs/alerts/images/alert-group-blast-radius.png
deleted file mode 100644
index 82722b79..00000000
Binary files a/src/content/docs/docs/alerts/images/alert-group-blast-radius.png and /dev/null differ
diff --git a/src/content/docs/docs/alerts/images/alert-group-detail.png b/src/content/docs/docs/alerts/images/alert-group-detail.png
index 50f2ce68..2fe7ace7 100644
Binary files a/src/content/docs/docs/alerts/images/alert-group-detail.png and b/src/content/docs/docs/alerts/images/alert-group-detail.png differ
diff --git a/src/content/docs/docs/alerts/images/alert-group-rca-drawer.png b/src/content/docs/docs/alerts/images/alert-group-rca-drawer.png
index dc166fa2..2aa6f734 100644
Binary files a/src/content/docs/docs/alerts/images/alert-group-rca-drawer.png and b/src/content/docs/docs/alerts/images/alert-group-rca-drawer.png differ
diff --git a/src/content/docs/docs/alerts/images/alert-group-related.png b/src/content/docs/docs/alerts/images/alert-group-related.png
new file mode 100644
index 00000000..fecfdad3
Binary files /dev/null and b/src/content/docs/docs/alerts/images/alert-group-related.png differ
diff --git a/src/content/docs/docs/alerts/images/auto-rca-single-investigation.png b/src/content/docs/docs/alerts/images/auto-rca-single-investigation.png
index 789c1d82..1dce80c4 100644
Binary files a/src/content/docs/docs/alerts/images/auto-rca-single-investigation.png and b/src/content/docs/docs/alerts/images/auto-rca-single-investigation.png differ
diff --git a/src/content/docs/docs/infrastructure/hosts.mdx b/src/content/docs/docs/infrastructure/hosts.mdx
index 257a25ab..82eaf5ba 100644
--- a/src/content/docs/docs/infrastructure/hosts.mdx
+++ b/src/content/docs/docs/infrastructure/hosts.mdx
@@ -63,6 +63,15 @@ Provides immediate access to the logs generated by the selected resource.
 ### Containers Tab (Hosts Only)
 When inspecting a Host, this tab lists all the active containers running on that specific machine, displaying their individual CPU, Memory, Image, and Runtime metrics. Clicking a container in this list updates the drawer to show the details for that container.
 
+### Topology Tab (Hosts Only)
+The last tab in the host drawer lists the services and databases that run on the host, what it talks with, and the EC2 instance it runs on. When the host runs on an EC2 instance, the tab also lists that instance's security groups, subnet, volumes, and target groups.
+
+Each group shows how many of its resources are alerting. Hover over a resource's **firing** count to see its alerts, and click an alert to open its rule in a new tab.
+
+![The Topology tab of a host, listing the databases and services that run on it](./images/hosts-topology-tab.png)
+
+Linking a host to its EC2 instance needs KloudMate agent 2.2.0 or later. If an AWS account is connected and the host runs an older agent, the tab asks you to [update the agent](../../kloudmate-agent/management/#updating-the-agent).
+
 ## Getting Started
 
 Host metrics are collected **automatically**, with no configuration, once you deploy the agent.
diff --git a/src/content/docs/docs/infrastructure/images/hosts-topology-tab.png b/src/content/docs/docs/infrastructure/images/hosts-topology-tab.png
new file mode 100644
index 00000000..f113cf54
Binary files /dev/null and b/src/content/docs/docs/infrastructure/images/hosts-topology-tab.png differ
diff --git a/src/content/docs/docs/infrastructure/images/inventory-by-type-aws.png b/src/content/docs/docs/infrastructure/images/inventory-by-type-aws.png
new file mode 100644
index 00000000..1783d28b
Binary files /dev/null and b/src/content/docs/docs/infrastructure/images/inventory-by-type-aws.png differ
diff --git a/src/content/docs/docs/infrastructure/images/inventory-by-type.png b/src/content/docs/docs/infrastructure/images/inventory-by-type.png
new file mode 100644
index 00000000..9d42125a
Binary files /dev/null and b/src/content/docs/docs/infrastructure/images/inventory-by-type.png differ
diff --git a/src/content/docs/docs/infrastructure/index.mdx b/src/content/docs/docs/infrastructure/index.mdx
index 70252f43..9a2ee6cc 100644
--- a/src/content/docs/docs/infrastructure/index.mdx
+++ b/src/content/docs/docs/infrastructure/index.mdx
@@ -23,6 +23,7 @@ The fastest way to start collecting host and Kubernetes metrics is the KloudMate
 
 ## Guides
 
+- [Inventory](./inventory/)
 - [Hosts & Containers](./hosts/)
 - [Advanced Host Configuration](./server-metrics-to-kloudmate/)
 - [Kubernetes Monitoring](./kubernetes/)
diff --git a/src/content/docs/docs/infrastructure/inventory.mdx b/src/content/docs/docs/infrastructure/inventory.mdx
new file mode 100644
index 00000000..a915f2f3
--- /dev/null
+++ b/src/content/docs/docs/infrastructure/inventory.mdx
@@ -0,0 +1,67 @@
+---
+title: "Inventory"
+description: "Browse every resource KloudMate knows about, from cloud resources to hosts, Kubernetes objects, services, and databases, and see what each one connects to."
+sidebar:
+  order: 0.5
+---
+
+**Inventory** lists everything KloudMate knows about in your workspace: cloud resources, hosts, Kubernetes objects, services, and databases. Use it to find a resource, see where it runs, and check what it connects to. To see how a resource performs, open it in Kubernetes, Hosts, APM, or Databases.
+
+You don't need an AWS account to use Inventory. The [KloudMate agent](../../kloudmate-agent/) adds your hosts, Kubernetes objects, services, and databases. [Connect an AWS account](../../aws-integration/account-setup/) to add its resources too.
+
+## Browse by type
+
+Open **Inventory**. The **By type** tab shows a card for each resource type with its count, grouped into **AWS**, **Kubernetes**, **Hosts and services**, **Databases**, and **Other**. Click a card to list the resources of that type on the **All resources** tab.
+
+![The By type tab of Inventory, with cards for Kubernetes, Hosts and services, and Databases resource types](./images/inventory-by-type.png)
+
+AWS resources get their own group after you connect an AWS account.
+
+![The AWS group on the By type tab, with cards for EC2 security groups, Lambda functions, S3 buckets, and other AWS resource types](./images/inventory-by-type-aws.png)
+
+## Filter by source
+
+When the workspace has a cloud account, use the **Source** filter to choose where the resources come from:
+
+- **All sources:** every resource.
+- **A cloud account:** the resources of one connected account.
+- **Telemetry:** the resources the KloudMate agent reports, such as hosts, Kubernetes objects, and services.
+
+The filter applies to both tabs. Without a cloud account, every resource comes from telemetry, so the filter doesn't show.
+
+If you pick an AWS account that has regions turned off, some of its resources may be missing. Click **Review** on the warning to turn those regions back on. See [Region sync status](../../platform/settings/data-sources/#region-sync-status).
+
+## Find a resource
+
+The **All resources** tab lists each resource with its **Name**, **Type**, **Where**, **Tags**, and **Last seen**. Search by name or key to find one.
+
+**Where** shows where the resource lives:
+
+- A cloud resource shows its region and account.
+- A Kubernetes object shows its cluster and namespace.
+- A database shows the address and port that clients connect to.
+- Hosts and services leave it empty.
+
+Resources that the agent reports leave the list when they haven't been seen for 2 hours. Cloud resources stay until a sync finds they're gone. Inventory doesn't list containers, network endpoints, or storage mounts.
+
+## Open a resource
+
+Click a resource to open its details. Every resource has these tabs:
+
+- **Overview:** the resource's type, where it runs, its key (the ARN for an AWS resource), and when KloudMate first and last saw it.
+- **Related:** what the resource connects to, grouped by relation, such as **Runs on**, **Talks with**, or **Contains**. Each group shows how many of its resources are alerting, and a group with alerting resources opens by default. Click a resource to open it.
+- **Tags:** the resource's tags.
+
+AWS resources also have **Alerts**, **Metrics**, and **Config** tabs, with the resource's active alerts, its CloudWatch metrics, and its AWS configuration.
+
+When a resource has its own page elsewhere in KloudMate, a button takes you there: **Open in Kubernetes**, **Open in Hosts**, **Open in APM**, or **Open in Databases**.
+
+## When Inventory is empty
+
+If Inventory shows **No resources yet**, nothing has reported to the workspace. [Install the KloudMate agent](../../kloudmate-agent/) to list your hosts, Kubernetes objects, and services, or [connect an AWS account](../../aws-integration/account-setup/) to list its resources. An organization **Owner** can start either one from the empty page with **Install the agent** or **Connect AWS account**.
+
+## Related
+
+- [Kubernetes Monitoring](../kubernetes/): how clusters, nodes, and workloads perform, and a map of the traffic between workloads.
+- [Hosts & Containers](../hosts/): host metrics and logs, and what each host connects to.
+- [Alert Groups](../../alerts/alert-groups/): the resources an alert group affects, and what else is alerting around them.
diff --git a/src/content/docs/docs/infrastructure/kubernetes/images/kubernetes-topology-tab.png b/src/content/docs/docs/infrastructure/kubernetes/images/kubernetes-topology-tab.png
new file mode 100644
index 00000000..b66c82fc
Binary files /dev/null and b/src/content/docs/docs/infrastructure/kubernetes/images/kubernetes-topology-tab.png differ
diff --git a/src/content/docs/docs/infrastructure/kubernetes/index.mdx b/src/content/docs/docs/infrastructure/kubernetes/index.mdx
index d0327e69..a10688ab 100644
--- a/src/content/docs/docs/infrastructure/kubernetes/index.mdx
+++ b/src/content/docs/docs/infrastructure/kubernetes/index.mdx
@@ -7,7 +7,7 @@ sidebar:
 ---
 Kubernetes Monitoring in KloudMate gives you visibility into cluster health, workload availability, resource usage, pod behavior, and related telemetry collected by the KloudMate Agent.
 
-KloudMate organizes Kubernetes data into tabs for clusters, nodes, namespaces, pods, storage, workloads, and jobs, so you can move from fleet-level health to pod-level troubleshooting quickly.
+KloudMate organizes Kubernetes data into tabs for clusters, nodes, namespaces, pods, storage, workloads, and jobs, plus a map of the traffic between workloads, so you can move from fleet-level health to pod-level troubleshooting quickly.
 
 ## What This Covers
 
@@ -89,6 +89,27 @@ The **Jobs** tab lists Jobs across your clusters, with their status, completions
 
 ![Jobs tab in Kubernetes](./images/kubernetes-jobs-tab.png)
 
+### Map
+
+The **Map** tab shows how the workloads in a cluster talk to each other. Pick a cluster, then pick a namespace or keep **All namespaces**.
+
+- **All namespaces** shows one box per namespace, with how many workloads and Services it has and how many of them are alerting. A line joins two namespaces whose workloads talk to each other. Click a namespace to open its map.
+- **A single namespace** shows its Deployments, StatefulSets, DaemonSets, and Services, with a line between each pair that talks. Workloads and Services in other namespaces that they talk to are dimmed. Click one to open its namespace.
+
+Click a workload or Service to open a side panel with its firing alerts, what it connects to, and **Open in Kubernetes** (**Open in Inventory** for a Service).
+
+The map draws workloads and Services that sent data in the last 2 hours, up to 200 at a time. In a larger cluster, pick a namespace to see all of them. Nodes aren't drawn. In a namespace, workloads and Services with no traffic are counted under the map instead, with a link to the namespace.
+
+The lines come from network flow data that the KloudMate agent collects with eBPF, so the nodes need a kernel that supports it. See [eBPF requirements](../../kloudmate-agent/ebpf-observability/#deployment-modes-and-requirements). Without flow data, the map draws no lines and notes that the cluster sends no traffic data.
+
+## See what a resource connects to
+
+Open a node, pod, Deployment, StatefulSet, or DaemonSet, and select the **Topology** tab, the last tab in the drawer. It lists what the resource connects to, grouped by relation, such as **Talks with** for network traffic and **Runs here** for what runs on a node.
+
+Each group shows how many of its resources are alerting, and a group with alerting resources opens by default. Hover over a resource's **firing** count to see its alerts, and click an alert to open its rule in a new tab. Resources not seen in the last 2 hours are counted but not listed.
+
+![The Topology tab of a Kubernetes node, with Talks with expanded to show the hosts and workloads the node talks with and their firing alerts](./images/kubernetes-topology-tab.png)
+
 ## Find resources that stopped reporting
 
 Every tab includes a **Last seen** column. A resource stays in the list for seven days after it last reported, and its **Last seen** dot turns from green to gray once it has gone 15 minutes without reporting. If a resource reported nothing in the selected time range, its metric cells show a dash.
diff --git a/src/content/docs/docs/kloudmate-agent/auto-instrumentation/gitops-clusters.mdx b/src/content/docs/docs/kloudmate-agent/auto-instrumentation/gitops-clusters.mdx
index 333865b7..fef65878 100644
--- a/src/content/docs/docs/kloudmate-agent/auto-instrumentation/gitops-clusters.mdx
+++ b/src/content/docs/docs/kloudmate-agent/auto-instrumentation/gitops-clusters.mdx
@@ -1,6 +1,6 @@
 ---
 title: "GitOps-managed clusters"
-description: "Trace Kubernetes workloads that Argo CD or Flux reconciles, with eBPF, a namespace annotation, a committed annotation, or your own policy engine."
+description: "Trace Kubernetes workloads that Argo CD or Flux manages, with eBPF, a namespace annotation, a committed annotation, agent patching, or your own policy engine."
 sidebar:
   label: "GitOps clusters"
   order: 11
@@ -8,7 +8,7 @@ sidebar:
 
 import { LinkCard, CardGrid } from '@astrojs/starlight/components';
 
-Argo CD and Flux reconcile a cluster back to what's in git. The KloudMate agent detects the workloads they own and doesn't write to them, so you can't turn on **SDK** tracing for them from KloudMate. You can still trace them. Start with eBPF mode and work down the list.
+Argo CD and Flux keep your cluster matched to what's in git. The KloudMate agent detects the workloads they manage and doesn't change them, so you can't turn on **SDK** tracing for those workloads from KloudMate. You can still trace them in other ways. Start with eBPF mode and work down the list.
 
 | Approach | Pods restart | Repo change | Argo CD or Flux change |
 |---|---|---|---|
@@ -20,27 +20,27 @@ Argo CD and Flux reconcile a cluster back to what's in git. The KloudMate agent
 
 ## Why the agent doesn't patch these workloads
 
-To turn on SDK tracing, the agent adds an OpenTelemetry Operator annotation to the workload's pod template. Your controller reverts anything that didn't come from git, and the agent would re-add it on the next check-in. Every revert and re-patch changes the pod template, so your pods would roll once a minute, and nothing would show up as an error.
+To turn on SDK tracing, the agent adds an OpenTelemetry Operator annotation to the workload's pod template. Your controller removes anything that didn't come from git, and the agent would add the annotation again on the next check-in. Each change to the pod template restarts the pods, so they would restart once a minute, and nothing would show up as an error.
 
-The agent reads ownership from the markers each controller adds to the workload. Argo CD's tracking annotation, an Argo-prefixed instance label, and Flux's kustomize-controller and helm-controller labels all name their controller outright, so they count on any cluster.
+The agent checks the markers that each controller adds to a workload. Argo CD's tracking annotation, an Argo-prefixed instance label, and the labels that Flux's kustomize-controller and helm-controller add all identify the controller directly, so the agent trusts them on any cluster.
 
-Argo CD installs that use label-based resource tracking are the exception. They mark a workload with `app.kubernetes.io/instance` and nothing else, and plain Helm charts set that same label, so the agent counts it only on a cluster where Argo CD itself is running. That cuts both ways: on such a cluster, a workload you installed with Helm and never put under Argo CD carries the label too, and shows as Argo-managed. Any of the options below still instruments it.
+Argo CD with label-based resource tracking is the exception. It marks a workload only with the `app.kubernetes.io/instance` label, and plain Helm charts set the same label. So the agent trusts this label only on a cluster where Argo CD itself runs. On such a cluster, a workload that you installed with Helm and never put under Argo CD also shows as managed by Argo CD. Any of the options below still instruments it.
 
 :::note[When Argo CD runs outside the cluster]
-A central Argo CD that manages this cluster from elsewhere installs nothing in it, so the agent can't tell that Argo CD is involved. With annotation tracking, detection still works, because the tracking annotation travels with each resource. With label tracking there's nothing for the agent to go on, so it keeps patching those workloads and rolling their pods.
+A central Argo CD that manages this cluster from somewhere else installs nothing in it, so the agent can't see Argo CD. With annotation tracking, detection still works, because each resource carries the tracking annotation. With label tracking, the agent finds no marker, so it keeps patching those workloads and restarting their pods.
 
-Annotation tracking is the default from Argo CD 3.0. On an older instance, switch `application.resourceTrackingMethod` to `annotation`, migrating through `annotation+label`. Or use any of the options below, none of which depend on detection.
+Annotation tracking is the default from Argo CD 3.0. On an older version, set `application.resourceTrackingMethod` to `annotation+label` first, then to `annotation`. You can also use any of the options below, because none of them depend on detection.
 :::
 
 ## Check whether a workload is externally managed
 
-Open the cluster's agent settings in KloudMate and find **Application instrumentation**. Workloads that Argo CD or Flux owns show as managed by that controller. The rest of the list behaves normally, so a cluster running Argo CD can still have workloads the agent instruments for you.
+Go to **Settings → Agents**, open the cluster agent's actions menu (⋮), and select **Configure**. On the **APM** tab, the **Application instrumentation** card shows **Managed by Argo CD** or **Managed by Flux** on each workload that one of them manages. Other workloads work as usual, even on a cluster that runs Argo CD.
 
 ## Turn on eBPF mode
 
-Set the workload to **eBPF** in **Application instrumentation** and apply. The change takes effect on the next agent check-in. The agent writes nothing to your cluster objects, your manifests don't change, and no pods restart, because eBPF attaches to processes that are already running.
+Set the workload to **eBPF** in **Application instrumentation** and click **Apply**. The change takes effect on the next agent check-in. The agent doesn't change your cluster objects or your manifests, and no pods restart, because eBPF attaches to processes that are already running.
 
-You get request rate, errors, duration, and trace spans. What you don't get is the in-process detail an SDK adds, such as spans for your database queries, framework internals, and outbound HTTP calls. For Go, Ruby, and PHP, eBPF is the only option on Kubernetes, whatever manages the workload, because the OpenTelemetry Operator has no injector for those runtimes. Those workloads aren't traced until you select eBPF for each one.
+You get request rate, errors, duration, and trace spans. You don't get the in-process detail that an SDK adds, such as spans for database queries, framework internals, and outbound HTTP calls. For Go, Ruby, and PHP, eBPF is the only option on Kubernetes, whatever manages the workload, because KloudMate doesn't inject an SDK for those runtimes there. Those workloads aren't traced until you select eBPF for each one.
 
 ## Annotate the namespace
 
@@ -62,14 +62,14 @@ metadata:
     instrumentation.opentelemetry.io/inject-java: km-agent/km-agent-instrumentation-crd
 ```
 
-Under Argo CD, the namespace is often created by the `CreateNamespace=true` sync option rather than declared in the app repo. If yours is created that way, the Namespace object isn't part of any Application's desired state, so annotating it doesn't count as drift and nothing reverts it.
+Under Argo CD, the `CreateNamespace=true` sync option often creates the namespace, instead of a manifest in the app repo. If yours is created that way, the Namespace object isn't part of any Application's desired state, so annotating it doesn't count as drift and nothing reverts it.
 
-The annotation doesn't change running pods. New pods get the injection, so delete the running ones or wait for the next deploy. Deleting pods doesn't create drift, because your controller reconciles the Deployment, not the pods it creates.
+The annotation doesn't change running pods. New pods get the injection, so delete the running ones or wait for the next deploy. Deleting pods doesn't create drift, because your controller manages the Deployment, not the pods it creates.
 
-Know the limits before you use this:
+Keep these limits in mind:
 
 - **Every pod in the namespace gets injected**, including short-lived jobs.
-- **One runtime per namespace.** The annotation names a single language. If a namespace holds a Java service and a Python service, this covers only one of them.
+- **One runtime per namespace.** The annotation sets a single language. If a namespace holds a Java service and a Python service, this covers only one of them.
 - **.NET runtime options come from the pod only.** If a .NET workload needs one, put it on that workload's pod template.
 
 ## Commit the annotation
@@ -84,13 +84,13 @@ spec:
         instrumentation.opentelemetry.io/inject-java: km-agent/km-agent-instrumentation-crd
 ```
 
-Your controller applies it on the next sync, and the pods roll once. Argo CD and Flux need no extra configuration, because the annotation is now part of the desired state rather than a difference from it.
+Your controller applies it on the next sync, and the pods restart once. Argo CD and Flux need no extra configuration, because the annotation is part of the desired state.
 
-Set that workload to **SDK** in **Application instrumentation** as well. The agent still won't write to it. The selection keeps the workload tracked in KloudMate, and once your controller syncs the annotation the workload reports as **Instrumented**.
+Also set that workload to **SDK** in **Application instrumentation**. The agent still doesn't change the workload. The setting keeps the workload tracked in KloudMate, and after your controller syncs the annotation, the workload shows as **Instrumented**.
 
 ## Allow the agent to patch these workloads
 
-If you'd rather keep the per-workload toggle in KloudMate, configure Argo CD to accept the agent's annotation, then turn the agent's patching back on. You need both of the Argo CD settings below.
+If you'd rather keep the per-workload toggle in KloudMate, set up Argo CD to accept the agent's annotation, then turn the agent's patching back on. You need both of the Argo CD settings below.
 
 First, ignore the inject annotations in the `argocd-cm` ConfigMap:
 
@@ -121,10 +121,10 @@ spec:
 ```
 
 :::caution
-`ignoreDifferences` on its own only changes what Argo CD reports as drift. Self-heal still reverts the annotation, so the pods keep rolling while the Argo CD UI shows the Application as synced. `RespectIgnoreDifferences=true` keeps the field out of the sync itself.
+`ignoreDifferences` on its own only changes what Argo CD reports as drift. Self-heal still reverts the annotation, so the pods keep restarting while the Argo CD UI shows the Application as synced. `RespectIgnoreDifferences=true` keeps the field out of the sync itself.
 :::
 
-With both in place, turn the agent's patching back on with the `patchExternallyManagedWorkloads` Helm value:
+With both settings in place, turn the agent's patching back on with the `patchExternallyManagedWorkloads` Helm value:
 
 ```bash
 helm upgrade kloudmate-release kloudmate/km-kube-agent \
@@ -132,13 +132,13 @@ helm upgrade kloudmate-release kloudmate/km-kube-agent \
   --set patchExternallyManagedWorkloads=true
 ```
 
-In the fleet-manager pod spec, this shows up as `KM_K8S_APM_PATCH_MANAGED=true`. It's a cluster-wide switch, so any Application left without the exception above reverts the annotation again and rolls its pods. Those workloads also stop showing as managed by Argo CD in **Application instrumentation**, and go back to reporting the usual instrumentation status.
+This value applies to the whole cluster. If an Application doesn't have the settings above, Argo CD reverts the annotation and the Application's pods keep restarting. With the value on, workloads that Argo CD manages no longer show **Managed by Argo CD** in **Application instrumentation**. They show their usual instrumentation status instead.
 
-These steps are specific to Argo CD. On Flux, exclude the same annotation from drift correction before you set the variable, or Flux reverts the agent's patches again.
+These steps are for Argo CD. On Flux, exclude the same annotations from drift correction before you turn on `patchExternallyManagedWorkloads`, or Flux reverts the agent's changes.
 
 ## Use your own policy engine
 
-If you already run Kyverno, have it add the annotation to pods at admission:
+If you already run Kyverno, have it add the annotation to pods when they're created:
 
 ```yaml
 apiVersion: kyverno.io/v1
@@ -162,17 +162,17 @@ spec:
               instrumentation.opentelemetry.io/inject-java: km-agent/km-agent-instrumentation-crd
 ```
 
-Argo CD and Flux compare Deployments, not the pods those Deployments create, so a policy that annotates pods never shows up as drift. The OpenTelemetry documentation suggests the same pattern, and KloudMate needs no configuration for it. As with the namespace annotation, running pods pick it up when they're recreated.
+Argo CD and Flux compare Deployments, not the pods those Deployments create, so a policy that annotates pods never shows up as drift. The OpenTelemetry documentation suggests the same pattern, and KloudMate needs no configuration for it. As with the namespace annotation, running pods get the annotation when they're recreated.
 
 ## Install the agent on a GitOps cluster
 
-`helm install` is the tested path, and it keeps the agent-update button in the KloudMate dashboard working. See the [Kubernetes installation guide](../../installation/kubernetes-agent/).
+Install the agent with Helm, as shown in the [Kubernetes installation guide](../../installation/kubernetes-agent/).
 
-To manage the agent through Argo CD instead, its Application needs these settings:
+To manage the agent through Argo CD instead, set these on its Application:
 
-- **`ignoreDifferences` on the agent's own ConfigMaps.** The agent writes each collector's live configuration into the `/data/agent-daemonset.yaml` and `/data/agent-deployment.yaml` keys of `km-agent-configmap-daemonset` and `km-agent-configmap-deployment`. Argo CD renders the chart without reading the cluster, so every sync would otherwise push those collectors back to the configuration the chart ships.
-- **The destination namespace set to `km-agent`.** The chart hardcodes that namespace on the Instrumentation resource that the inject annotation points at (`km-agent/km-agent-instrumentation-crd`).
-- **`SkipDryRunOnMissingResource=true`** in the sync options. On the first sync, Argo CD applies the Instrumentation resource in the same wave that installs the OpenTelemetry Operator's CRDs, and the dry run fails without it.
+- **`ignoreDifferences` on the agent's own ConfigMaps.** The agent writes each collector's live configuration into the `/data/agent-daemonset.yaml` and `/data/agent-deployment.yaml` keys of `km-agent-configmap-daemonset` and `km-agent-configmap-deployment`. Argo CD renders the chart without reading the cluster, so without this setting, every sync resets the collectors to the configuration in the chart.
+- **The destination namespace set to `km-agent`.** The chart always creates the Instrumentation resource in `km-agent`, and the inject annotation points to it as `km-agent/km-agent-instrumentation-crd`.
+- **`SkipDryRunOnMissingResource=true`** in the sync options. On the first sync, Argo CD applies the Instrumentation resource in the same wave that installs the OpenTelemetry Operator's CRDs, and the dry run fails without this option.
 
 ```yaml
 spec:
diff --git a/src/content/docs/docs/kloudmate-assistant/mcp-server.mdx b/src/content/docs/docs/kloudmate-assistant/mcp-server.mdx
index dd9d983a..9c12d6e2 100644
--- a/src/content/docs/docs/kloudmate-assistant/mcp-server.mdx
+++ b/src/content/docs/docs/kloudmate-assistant/mcp-server.mdx
@@ -16,7 +16,7 @@ After you connect, your agent can chain KloudMate's query tools to investigate a
 
 ## Connection details
 
-The server is a single remote endpoint. You authenticate with a KloudMate [Personal API Key](../../platform/settings/api-keys/#personal-api-keys) passed as a bearer token, and name the workspace you want to read with an `x-workspace-id` header.
+The server is a single remote endpoint. You authenticate with a KloudMate [Personal API Key](../../platform/settings/api-keys/#personal-api-keys) passed as a bearer token, and set the workspace you want to read in an `x-workspace-id` header.
 
 | Setting | Value |
 |---|---|
@@ -182,7 +182,7 @@ Every tool is read-only. The server queries your telemetry; it never creates, ed
 **Service health (APM)**
 
 - `get_service_error_count`, `get_service_requests_count_and_avg_latency`: error counts, throughput, and average latency for a service.
-- `get_service_to_service_requests_count`, `get_service_to_service_failed_requests_count`, `get_service_to_service_request_duration`: request volume, failures, and latency between services, to scope a blast radius.
+- `get_service_to_service_requests_count`, `get_service_to_service_failed_requests_count`, `get_service_to_service_request_duration`: request volume, failures, and latency between services, to see which services a problem affects.
 
 **SLOs**
 
diff --git a/src/content/docs/docs/workflows/run-history.mdx b/src/content/docs/docs/workflows/run-history.mdx
index 56c7e0cb..044bc6f9 100644
--- a/src/content/docs/docs/workflows/run-history.mdx
+++ b/src/content/docs/docs/workflows/run-history.mdx
@@ -63,7 +63,7 @@ You can't re-run a test run this way, because it ran a draft, not a published ve
 
 **Workflows → Usage** shows how workflows are doing across the workspace over the time range you pick, the last 7 days by default. Its tiles show the **Runs** that finished, the **Failed** runs, the **Success Rate %**, and the **Credits** used, above a chart of **Runs and Failures Over Time**. It doesn't count test runs from the builder.
 
-Each run counts 1 credit, and each **AI Prompt**, **AI Extract**, or **AI Route** step it runs adds 2. A workflow that a **Call Workflow** step starts counts as a run of its own. Loop items and parallel branches don't.
+Each run counts 1 credit. A workflow that a **Call Workflow** step starts counts as a run of its own. Loop items and parallel branches don't.
 
 Workflow credits are separate from the [AI credits](../../kloudmate-assistant/usage/) that the KloudMate Assistant uses in chat. An **Ask KloudMate Assistant** step adds no workflow credits, and spends 1 AI credit each time it answers instead.
 
diff --git a/src/content/docs/guides/workflows/answer-common-questions.mdx b/src/content/docs/guides/workflows/answer-common-questions.mdx
index 96512220..5f9e23c1 100644
--- a/src/content/docs/guides/workflows/answer-common-questions.mdx
+++ b/src/content/docs/guides/workflows/answer-common-questions.mdx
@@ -30,7 +30,7 @@ Slack: New message in a channel
 - You need the **Developer** role in a KloudMate workspace whose plan includes workflows.
 - You need a Slack connection and a Jira Cloud connection, both with the **Workflows** capability. Invite the KloudMate bot to your help channel.
 - You need a Jira project for help desk tickets.
-- Each message in the channel uses workflow credits, and the **AI Extract** step uses more. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
+- Each message in the channel uses 1 workflow credit. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
 
 ## Step 1: Write the answers
 
diff --git a/src/content/docs/guides/workflows/deploy-from-slack.mdx b/src/content/docs/guides/workflows/deploy-from-slack.mdx
index e22618e6..c3abb53f 100644
--- a/src/content/docs/guides/workflows/deploy-from-slack.mdx
+++ b/src/content/docs/guides/workflows/deploy-from-slack.mdx
@@ -34,7 +34,7 @@ Slack: Bot is mentioned
 - You need the **Developer** role in a KloudMate workspace whose plan includes workflows.
 - You need a Slack connection with the **Workflows** capability, and a channel for deploy requests. Invite the KloudMate bot to that channel.
 - You need a GitHub repository where you can add a workflow, and permission to create a fine-grained personal access token for it.
-- Each run uses workflow credits, and the **AI Extract** step uses more. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
+- Each run uses 1 workflow credit. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
 
 ## Step 1: Add a deploy workflow in GitHub
 
diff --git a/src/content/docs/guides/workflows/escalate-urgent-tickets.mdx b/src/content/docs/guides/workflows/escalate-urgent-tickets.mdx
index 6133c58f..ca208d43 100644
--- a/src/content/docs/guides/workflows/escalate-urgent-tickets.mdx
+++ b/src/content/docs/guides/workflows/escalate-urgent-tickets.mdx
@@ -34,7 +34,7 @@ Webhook: an urgent ticket from the help desk
 - You need the **Developer** role in a KloudMate workspace whose plan includes workflows.
 - You need a Jira Cloud connection and a Slack connection, both with the **Workflows** capability. Invite the KloudMate bot to each channel the workflow posts in.
 - Your help desk must be able to call a webhook when a ticket matches a rule, with a JSON body you write. To add the note to the ticket, it also needs an API with a token.
-- Each urgent ticket uses workflow credits, and the **AI Extract** step uses more. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
+- Each urgent ticket uses 1 workflow credit. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
 
 ## Step 1: Save the variables
 
diff --git a/src/content/docs/guides/workflows/it-help-desk-in-slack.mdx b/src/content/docs/guides/workflows/it-help-desk-in-slack.mdx
index e570ed0f..4c018320 100644
--- a/src/content/docs/guides/workflows/it-help-desk-in-slack.mdx
+++ b/src/content/docs/guides/workflows/it-help-desk-in-slack.mdx
@@ -26,7 +26,7 @@ The workflows find each other's data through [Storage](/workflows/storage/) keys
 - You need the **Developer** role in a KloudMate workspace whose plan includes workflows.
 - You need a Slack connection and a Jira Cloud connection, both with the **Workflows** capability.
 - You need a Jira project for help desk tickets. This guide uses the key `IT`.
-- Each ticket uses workflow credits, and the **AI Extract** step uses more. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
+- Each run of either workflow uses 1 workflow credit. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
 
 ## Step 1: Save your Jira address as a variable
 
diff --git a/src/content/docs/guides/workflows/route-requests-with-ai.mdx b/src/content/docs/guides/workflows/route-requests-with-ai.mdx
index 919b71b2..37d4ef7d 100644
--- a/src/content/docs/guides/workflows/route-requests-with-ai.mdx
+++ b/src/content/docs/guides/workflows/route-requests-with-ai.mdx
@@ -26,7 +26,7 @@ Form: Ask for help
 
 - You need the **Developer** role in a KloudMate workspace whose plan includes workflows.
 - The people who submit the form need to be members of your KloudMate workspace, because the form has **Sign-in required** turned on.
-- Each request uses workflow credits, and the **AI Route** step uses more. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
+- Each request uses 1 workflow credit. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
 
 ## Step 1: Import the workflow
 
diff --git a/src/content/docs/guides/workflows/summarize-slack-thread.mdx b/src/content/docs/guides/workflows/summarize-slack-thread.mdx
index 4bd46f2b..59df6752 100644
--- a/src/content/docs/guides/workflows/summarize-slack-thread.mdx
+++ b/src/content/docs/guides/workflows/summarize-slack-thread.mdx
@@ -22,7 +22,7 @@ Slack: Reaction added, 📝 only
 
 - You need the **Developer** role in a KloudMate workspace whose plan includes workflows.
 - You need a Slack connection with the **Workflows** capability. The workflow works in every channel the KloudMate bot is in, so invite the bot to the channels where you want summaries.
-- Each summary uses workflow credits, and the **AI Prompt** step uses more. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
+- Each summary uses 1 workflow credit. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
 
 ## Step 1: Import the workflow
 
diff --git a/src/content/docs/guides/workflows/triage-jira-bugs.mdx b/src/content/docs/guides/workflows/triage-jira-bugs.mdx
index 75b12ec2..885b4275 100644
--- a/src/content/docs/guides/workflows/triage-jira-bugs.mdx
+++ b/src/content/docs/guides/workflows/triage-jira-bugs.mdx
@@ -36,7 +36,7 @@ Jira: New issue
 - You need the **Developer** role in a KloudMate workspace whose plan includes workflows.
 - You need a Jira Cloud connection and a Slack connection, both with the **Workflows** capability. Invite the KloudMate bot to each team's Slack channel, and to a channel for bugs that need a person.
 - Note your Jira project key, such as `APP`, and the email address of each team's lead.
-- Each run uses workflow credits, and the **AI Extract** step uses more. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
+- Each run uses 1 workflow credit. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
 
 ## Step 1: Save your Jira address as a variable
 
diff --git a/src/content/docs/guides/workflows/weekly-reliability-report.mdx b/src/content/docs/guides/workflows/weekly-reliability-report.mdx
index 39efd5f7..3b1fcd16 100644
--- a/src/content/docs/guides/workflows/weekly-reliability-report.mdx
+++ b/src/content/docs/guides/workflows/weekly-reliability-report.mdx
@@ -26,7 +26,7 @@ Schedule: Mondays at 09:00
 
 - You need the **Developer** role in a KloudMate workspace whose plan includes workflows.
 - You need a Slack connection with the **Workflows** capability, and a channel for the report. Invite the KloudMate bot to that channel.
-- Each run uses workflow credits, and the **AI Prompt** step uses more. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
+- Each run uses 1 workflow credit. See [Check workflow usage](/workflows/run-history/#check-workflow-usage).
 
 ## Step 1: Connect the KloudMate MCP server