Rachael-Graham · Oct 27, 2026 · Oct 27, 2026 · Oct 29, 2026
diff --git a/docs-site/assets/kagent-docs/snippets/install-cli.md b/docs-site/assets/kagent-docs/snippets/install-cli.md
@@ -0,0 +1,5 @@
+Download the kagent CLI. The `--version` flag matches the CLI to the release that these docs cover.
+
+```bash
+curl https://raw.githubusercontent.com/kagent-dev/kagent/refs/heads/main/scripts/get-kagent | bash -s -- --version v{{< reuse "kagent-docs/versions/kagent.md" >}}
+```
diff --git a/docs-site/content/kagent/1.x/about/substrate-runtime/standalone-sandboxes.md b/docs-site/content/kagent/1.x/about/substrate-runtime/standalone-sandboxes.md
diff --git a/docs-site/content/kagent/1.x/agents/human-in-the-loop.md b/docs-site/content/kagent/1.x/agents/human-in-the-loop.md
diff --git a/docs-site/content/kagent/1.x/agents/structured-output.md b/docs-site/content/kagent/1.x/agents/structured-output.md
diff --git a/docs-site/content/kagent/1.x/examples/a2a-agents.md b/docs-site/content/kagent/1.x/examples/a2a-agents.md
diff --git a/docs-site/content/kagent/1.x/examples/skills.md b/docs-site/content/kagent/1.x/examples/skills.md
diff --git a/docs-site/content/kagent/1.x/get-started/your-first-agent.md b/docs-site/content/kagent/1.x/get-started/your-first-agent.md
@@ -10,10 +10,7 @@ This guide walks you through creating an agent, from applying a Harness and an A
 ## Before you begin
 
 1. [Install kagent with a WorkerPool provisioned]({{< link path="setup/installation" >}}).
-2. Download the kagent CLI. The `--version` flag matches the CLI to the release that these docs cover.
-   ```bash
-   curl https://raw.githubusercontent.com/kagent-dev/kagent/refs/heads/main/scripts/get-kagent | bash -s -- --version v{{< reuse "kagent-docs/versions/kagent.md" >}}
-   ```
+2. {{< reuse "kagent-docs/snippets/install-cli.md" >}}
 
 3. Install [`jq`](https://jqlang.org/download/), to read the Session ID out of the CLI's JSON output.
 

diff --git a/docs-site/content/kagent/1.x/observability/launch-ui.md b/docs-site/content/kagent/1.x/observability/launch-ui.md
diff --git a/docs-site/content/kagent/1.x/operations/upgrade-from-0x.md b/docs-site/content/kagent/1.x/operations/upgrade-from-0x.md
diff --git a/docs-site/content/kagent/1.x/reference/release-notes/1.0.md b/docs-site/content/kagent/1.x/reference/release-notes/1.0.md
@@ -9,7 +9,7 @@ Each section covers one patch release in the kagent 1.0 line, newest first. For
 
 ## 1.0.0
 
-kagent 1.0 is a clean break from the 0.10.x line rather than an incremental release. It changes how an agent runs, how you declare one, and which custom resources exist. Because 1.0 does not share a database schema with 0.10.x, moving an existing installation means standing up a new one rather than running `helm upgrade`.
+kagent 1.0 is a clean break from the 0.10.x line rather than an incremental release. It changes how an agent runs, how you declare one, and which custom resources exist.
 
 For the component versions that this release pins and the Kubernetes version that it is tested against, see [Version support]({{< link path="reference/versions#what-a-kagent-release-includes" >}}).
 
@@ -19,24 +19,24 @@ The runtime moved off Kubernetes Deployments, so the cost of an idle agent and t
 
 - **Each conversation runs as an {{< gloss "Actor" >}}Actor{{< /gloss >}} on {{< gloss "Agent Substrate" >}}Agent Substrate{{< /gloss >}}**, rather than as a long-lived Deployment that serves every conversation for one agent.
 - **Conversations suspend between turns.** When a turn ends, Agent Substrate writes the Actor's memory and filesystem to a {{< gloss "Snapshot" >}}snapshot{{< /gloss >}} and releases the {{< gloss "Worker" >}}Worker{{< /gloss >}} that hosted it. The next message restores that snapshot onto whichever Worker is free. For the lifecycle, see [Suspend and resume]({{< link path="about/substrate-runtime/suspend-and-resume#suspension-between-turns" >}}).
-- **Every agent runs in a gVisor sandbox by default.** 0.10.x relied on a Kubernetes `securityContext` to constrain an agent, and 1.0 provides process, network, and filesystem isolation without per-agent security context configuration. For what the sandbox separates, see [Sandboxing]({{< link path="about/substrate-runtime/sandboxing#what-the-sandbox-separates" >}}).
+- **Every agent runs in a gVisor sandbox by default.** 0.10.x relied on a Kubernetes `securityContext` to constrain an agent. 1.0 provides process, network, and filesystem isolation without per-agent security context configuration. For what the sandbox separates, see [Sandboxing]({{< link path="about/substrate-runtime/sandboxing#what-the-sandbox-separates" >}}).
 
 ### How you declare an agent
 
 The single 0.10.x `Agent` resource described both what an agent does and how it runs. 1.0 separates those concerns across two reusable resources, names each pairing with a third, and adds a fourth object for a running conversation.
 
-- **A {{< gloss "Harness" >}}Harness{{< /gloss >}} defines how an agent is allowed to run**: its runtime, workload image, {{< gloss "WorkerPool" >}}WorkerPool{{< /gloss >}}, and snapshot storage. One Harness serves many agents, so expect fewer Harnesses than you had 0.10.x Agents.
-- **An {{< gloss "AgentTemplate" >}}AgentTemplate{{< /gloss >}} defines what an agent does**: its model, system prompt, tools, skills, and plugins.
-- **An {{< gloss "Agent" >}}Agent{{< /gloss >}} pairs one AgentTemplate with one Harness.** `spec.template` takes either a reference to an existing AgentTemplate or a complete inline spec, while `spec.harnessRef` takes a reference only. The Agent owns readiness, and callers address the Agent rather than the AgentTemplate or the Harness.
-- **A {{< gloss "Session" >}}Session{{< /gloss >}} is one running conversation** with an Agent. Unlike the other three, a Session is not a custom resource: kagent's gRPC API creates it and kagent's database tracks it.
+- **A {{< gloss "Harness" >}}Harness{{< /gloss >}} defines how an agent is allowed to run**, including its runtime, workload image, {{< gloss "WorkerPool" >}}WorkerPool{{< /gloss >}}, and snapshot storage. One Harness serves many agents, so expect fewer Harnesses than you had 0.10.x Agents.
+- **An {{< gloss "AgentTemplate" >}}AgentTemplate{{< /gloss >}} defines what an agent does**, including its model, system prompt, tools, skills, and plugins.
+- **An {{< gloss "Agent" >}}Agent{{< /gloss >}} pairs one AgentTemplate with one Harness.** `spec.template` takes either a reference to an existing AgentTemplate or a complete inline spec. `spec.harnessRef` takes only a reference. The Agent owns readiness. Callers address the Agent, not the AgentTemplate or the Harness.
+- **A {{< gloss "Session" >}}Session{{< /gloss >}} is one running conversation** with an Agent. Unlike the other three, a Session is not a custom resource. kagent's gRPC API creates each Session, and kagent's database tracks it.
 
-Nothing pairs a Harness and an AgentTemplate implicitly. Neither resource carries a field naming the other, so an Agent is what makes a template runnable on a Harness. For the full model, see [Core concepts]({{< link path="about/core-concepts#agent" >}}).
+kagent does not pair a Harness and an AgentTemplate implicitly. Neither resource has a field that references the other. An Agent makes a template runnable on a Harness. For the full model, see [Core concepts]({{< link path="about/core-concepts#agent" >}}).
 
-The CRD API group also moves from `kagent.dev/v1alpha2` to `api.kagent.dev/v1alpha3`, with no conversion between the two. 1.0 no longer bundles kmcp, so it does not install the `mcpservers.kagent.dev` CRD. The two releases still cannot run side by side on one cluster, because both charts name their ClusterRoles after the release.
+The custom resource definition (CRD) API group also moves from `kagent.dev/v1alpha2` to `api.kagent.dev/v1alpha3`. kagent does not convert resources between the two groups. 1.0 no longer bundles kmcp, so it does not install the `mcpservers.kagent.dev` CRD. 1.0 also no longer bundles the Grafana Model Context Protocol (MCP) server, so it does not create the `kagent-grafana-mcp` RemoteMCPServer. The two releases still cannot run side by side on one cluster, because both charts name their ClusterRoles after the release.
 
 ### Removed and replaced resources
 
-Six resource kinds are removed or replaced and three carry forward. The distinction matters when you plan a move, because a replaced kind has somewhere for its configuration to go, while a removed kind has none.
+Each 0.10.x resource kind is replaced, removed, or carried forward in 1.0. The distinction matters when you plan a move. A replaced kind has a destination for its configuration. A removed kind does not.
 
 | 0.10.x resource | Status in 1.0 |
 | --------------- | ------------- |
@@ -51,14 +51,14 @@ Six resource kinds are removed or replaced and three carry forward. The distinct
 > [!IMPORTANT]
 > 1.0's `Harness` and 0.10.x's `AgentHarness` share part of a name and nothing else. `AgentHarness` provisioned coding-agent sandboxes, while `Harness` governs how any agent is allowed to run. Read `Harness` as a new resource rather than a renamed one.
 
-Several `Agent` fields have no `v1alpha3` equivalent at all, including `a2aConfig`, `executeCodeBlocks`, `shareTools`, and `context`. A2A is always on in 1.0. A caller addresses an Agent at `/agents/{namespace}/{name}` over HTTP, or through the A2A `tenant` field over gRPC. Tool bindings also changed shape. A 1.0 `ToolBinding` carries an `mcp` or `subAgent` block and no `type` discriminator. For the field-by-field mapping, see [Agents become an AgentTemplate, a Harness, and an Agent]({{< link path="operations/upgrade-from-0x#agents-become-an-agenttemplate-a-harness-and-an-agent" >}}).
+Several `Agent` fields do not have a `v1alpha3` equivalent, including `a2aConfig`, `executeCodeBlocks`, `shareTools`, and `context`. Agent-to-Agent (A2A) is always on in 1.0. A caller addresses an Agent at `/agents/{namespace}/{name}` over HTTP, or through the A2A `tenant` field over gRPC. Tool bindings also changed shape. A 1.0 `ToolBinding` contains an `mcp` or `subAgent` block and does not have a `type` discriminator. For the field-by-field mapping, see [Agents become an AgentTemplate, a Harness, and an Agent]({{< link path="operations/upgrade-from-0x#agents-become-an-agenttemplate-a-harness-and-an-agent" >}}).
 
 ### Upgrade paths
 
-Compatibility promises start at 1.0 rather than continuing from the 0.10.x line, so plan a migration rather than an upgrade.
+Compatibility promises start at 1.0. Plan a migration from 0.10.x, not an upgrade.
 
-- **0.10.x to 1.0 in place is not supported.** An existing 0.10.x database has no migration bridge to 1.0 and 1.0 requires a new PostgreSQL database.
+- **0.10.x to 1.0 in place is not supported.** kagent does not migrate a 0.10.x database to 1.0. 1.0 requires a new PostgreSQL database.
 - **Downgrade from 1.0 to 0.10.x is not supported.**
 - **1.0 to a later minor release is supported.** From 1.0 onward, migrations are append-only and each minor release retains compatibility with the previous release line.
 
-Moving an existing installation therefore means installing 1.0 alongside the old one, recreating your resources on it, and retiring 0.10.x once the new installation answers correctly. Conversation history does not carry across, because nothing in 1.0 can read a 0.10.x database. For the full procedure, see [Upgrade from 0.x]({{< link path="operations/upgrade-from-0x#in-place-upgrade-blockers" >}}).
+Moving an existing installation therefore means installing 1.0 alongside the old one, recreating your resources on it, and retiring 0.10.x once the new installation answers correctly. Conversation history does not carry across, because 1.0 cannot read a 0.10.x database. For the full procedure, see [Upgrade from 0.x]({{< link path="operations/upgrade-from-0x#in-place-upgrade-blockers" >}}).