fix(website): repair broken docs links and anchors

website/src/components/marketing/solutions/AgentOSPage.tsx

@@ -854,9 +854,9 @@ const orchestrationFeatures = [
 	{ icon: ListChecks, title: 'Durable sessions', description: 'Every run is a managed session with its own state, history, and lifecycle. Pause, resume, and replay.', docsHref: '/docs/sessions' },
 	{ icon: Workflow, title: 'Workflows', description: 'Chain durable, multi-step workflows that survive restarts and pick up exactly where they left off.', docsHref: '/docs/workflows' },
 	{ icon: Layers, title: 'Agent-to-agent', description: 'Let agents delegate to other agents through host-brokered calls, under the same limits and permissions.', docsHref: '/docs/agent-to-agent' },
-	{ icon: Wrench, title: 'Tools, MCP & skills', description: 'Write tools as JavaScript functions on the host, connect any MCP server, and add skills the agent can call.', docsHref: '/docs/tools' },
-	{ icon: ShieldCheck, title: 'Approvals & queue-in-loop', description: 'Gate sensitive actions behind human approval and queue work for review in the loop.', docsHref: '/docs/queues', span: 'lg:col-span-2' },
-	{ icon: Activity, title: 'Observability', description: 'Stream every event, tool call, and state change for full visibility into what your agents are doing.', docsHref: '/docs/events', span: 'lg:col-span-2' },
+	{ icon: Wrench, title: 'Tools, MCP & skills', description: 'Write tools as JavaScript functions on the host, connect any MCP server, and add skills the agent can call.', docsHref: '/docs/bindings' },
+	{ icon: ShieldCheck, title: 'Approvals & queue-in-loop', description: 'Gate sensitive actions behind human approval and queue work for review in the loop.', docsHref: '/docs/approvals', span: 'lg:col-span-2' },
+	{ icon: Activity, title: 'Observability', description: 'Stream every event, tool call, and state change for full visibility into what your agents are doing.', docsHref: '/docs/sessions#stream-responses', span: 'lg:col-span-2' },
 ];
 
 // "Orchestrate fleets…" title that scrubs in (fade + blur + rise) as you scroll
@@ -1015,7 +1015,7 @@ const osFeatures = [
 	{ icon: Globe, title: 'Preview deployments', description: 'Every app the agent runs gets its own unique preview URL, served straight from the VM.', docsHref: '/docs/networking' },
 	{ icon: Container, title: 'Sandbox mounting', description: 'agentOS handles most workloads — dev servers, CLIs, builds — in-process, and mounts a full sandbox when a job needs a real kernel, native binaries, or a GPU.', docsHref: '/docs/sandbox', span: 'lg:col-span-2' },
 	{ icon: CalendarClock, title: 'Cron jobs', description: 'Schedule recurring agent runs and background jobs inside the VM.', docsHref: '/docs/cron', span: 'lg:col-span-2' },
-	{ icon: Cpu, title: 'Resource limits', description: 'Per-agent CPU, memory, and network limits. One isolate can’t crash or starve the rest.', docsHref: '/docs/security', span: 'lg:col-span-2' },
+	{ icon: Cpu, title: 'Resource limits', description: 'Per-agent CPU, memory, and network limits. One isolate can’t crash or starve the rest.', docsHref: '/docs/resource-limits', span: 'lg:col-span-2' },
 ];
 
 // --- Floating agent logos for the featured "Any agent harness" tile ---

website/src/content/docs/docs/architecture/agent-sdk-snapshots.mdx

@@ -22,7 +22,7 @@ Agent SDK snapshotting extends that same mechanism: it evaluates the agent SDK *
 
 ## Where it sits in the component model
 
-The [three components](/docs/architecture#three-components) are unchanged. Snapshotting only changes *how* the executor's isolate is seeded:
+The [three components](/docs/architecture#the-big-picture) are unchanged. Snapshotting only changes *how* the executor's isolate is seeded:
 
 - **Client.** Builds the SDK bundle at package-build time and passes it to the sidecar as trusted VM configuration (`jsRuntime.snapshotUserlandCode`). It decides which agents opt in.
 - **Sidecar.** Owns the snapshot. It builds the snapshot once, caches it process-wide, and seeds each session's isolate from it. The SDK runs inside the isolate under the same [permission policy](/docs/permissions) as any guest code — snapshotting grants the SDK no extra capability.

website/src/content/docs/docs/architecture/agent-sessions.mdx

@@ -12,7 +12,7 @@ A session is a long-lived conversation with an agent (such as [Pi](https://githu
 
 ## Where a session sits in the component model
 
-The [three components](/docs/architecture#three-components) are unchanged for sessions: a trusted **client**, the trusted **sidecar** that owns the kernel, and the untrusted **executor** that runs guest code. An agent session adds one more layer on the guest side of the boundary:
+The [three components](/docs/architecture#the-big-picture) are unchanged for sessions: a trusted **client**, the trusted **sidecar** that owns the kernel, and the untrusted **executor** that runs guest code. An agent session adds one more layer on the guest side of the boundary:
 
 - **Client.** Calls `createSession`, `sendPrompt`, and the rest of the session API. It never runs the agent itself; it drives the session over the wire protocol.
 - **Sidecar / kernel.** Spawns the agent as a kernel-managed process inside the VM, owns the session's I/O, applies the permission policy on every syscall the agent makes, and persists the transcript.
@@ -31,13 +31,13 @@ A session is always created against an existing VM. The client resolves a VM han
 4. **The session is registered** in the VM with a `sessionId`, and the adapter performs its handshake with the agent to discover `capabilities` and `agentInfo`.
 5. **The handle returns** that metadata to the client.
 
-The session is bound to that VM for its lifetime. The agent process, its working directory, and its persisted transcript all live inside the VM's isolation domain. A VM can host several sessions at once: each gets its own agent process, but they share the one VM's filesystem (see [Multiple sessions](/docs/sessions#multiple-sessions)). Two sessions in two different VMs share nothing, exactly as described in the [isolation model](/docs/architecture#isolation-model).
+The session is bound to that VM for its lifetime. The agent process, its working directory, and its persisted transcript all live inside the VM's isolation domain. A VM can host several sessions at once: each gets its own agent process, but they share the one VM's filesystem (see [Multiple sessions](/docs/sessions#multiple-sessions)). Two sessions in two different VMs share nothing, exactly as described in the [isolation model](/docs/architecture).
 
 <Aside type="note">MCP servers configured on a session follow the same boundary. A `local` MCP server runs as a child process inside the VM (kernel-managed, gated by the permission policy); a `remote` MCP server is reached over the network, so its traffic flows through the kernel socket table and is subject to the network allowlist.</Aside>
 
 ## How a prompt flows: client to agent and back
 
-Sending a prompt is a request in one direction with a stream of events flowing back in the other. The lifecycle of a single prompt extends the general [lifecycle of a request](/docs/architecture#lifecycle-of-a-request):
+Sending a prompt is a request in one direction with a stream of events flowing back in the other. The lifecycle of a single prompt extends the general [lifecycle of a request](/docs/architecture):
 
 1. **The client calls `sendPrompt(sessionId, text)`.** The request crosses the wire to the sidecar (hop one).
 2. **The sidecar routes it to the session's agent adapter,** which translates the prompt into the agent's native input and writes it to the running agent process.

website/src/content/docs/docs/architecture/filesystem.mdx

@@ -50,7 +50,7 @@ Resolution is **longest-prefix wins**: if `/mnt/data` is a mount and the guest o
 \- ...
 ```
 
-The base layer is in-memory and per-VM; the runtime transparently persists it to backing storage so it survives sleep/wake. Mounts are pluggable: any guest path can be backed by the host, a remote, or a cloud store. See [Mounting filesystems](/docs/filesystem#mounting-filesystems) for the user-facing config.
+The base layer is in-memory and per-VM; the runtime transparently persists it to backing storage so it survives sleep/wake. Mounts are pluggable: any guest path can be backed by the host, a remote, or a cloud store. See [Mounting filesystems](/docs/filesystem#mounts) for the user-facing config.
 
 ## Routing a guest syscall
 

website/src/content/docs/docs/authentication.mdx

@@ -6,7 +6,7 @@ skill: true
 
 import CodeGroup from '@rivet-dev/docs-theme/components/CodeGroup.astro';
 
-agentOS uses the same authentication system as [Rivet Actors](/docs/actors/authentication): clients send credentials as connection params, and you validate them server-side.
+agentOS uses the same authentication system as [Rivet Actors](https://rivet.dev/docs/actors/authentication): clients send credentials as connection params, and you validate them server-side.
 
 - Clients pass credentials in `params` when they connect.
 - Validate them on the server in `onBeforeConnect` (throw to reject the connection), or extract user data into connection state with `createConnState` (read it in actions via `c.conn.state`).
@@ -62,4 +62,4 @@ await agent.sendPrompt(session.sessionId, "List the files in the working directo
 
 *[See Full Example](https://github.com/rivet-dev/agent-os/tree/main/examples/docs/authentication)*
 
-See [Actor Authentication](/docs/actors/authentication) for JWT validation, role-based access control, external auth providers, and token caching.
+See [Actor Authentication](https://rivet.dev/docs/actors/authentication) for JWT validation, role-based access control, external auth providers, and token caching.

website/src/content/docs/docs/bindings.mdx

@@ -135,7 +135,7 @@ agentOS supports two ways to give agents access to external functionality: **bin
 | **Latency** | Near-zero. Bound directly to the host process. | Extra network hop to reach the MCP server |
 | **Setup** | Define bindings in your actor code with Zod schemas | Configure any standard MCP server |
 
-Use bindings when you want to expose your own JavaScript functions to agents. Use MCP servers when you want to connect to existing third-party services. See [Sessions](/docs/sessions#mcpservers) for MCP server configuration.
+Use bindings when you want to expose your own JavaScript functions to agents. Use MCP servers when you want to connect to existing third-party services. See [Sessions](/docs/sessions#createsession-options) for MCP server configuration.
 
 ## Security
 

website/src/content/docs/docs/core.mdx

@@ -21,7 +21,7 @@ The `agentOS()` actor (from `@rivet-dev/agentos`) wraps the core package and add
 | Agent-to-agent communication | Custom | Built into [Rivet Actors](/docs/agent-to-agent) |
 | Authentication | Set up yourself | [Documentation](/docs/authentication) |
 
-We recommend using [Rivet Actors](/docs/actors) because they provide a portable way to run `agentOS()` on any infrastructure with built-in persistence, networking, and orchestration. Use the core package if you need the most bare-bones implementation possible.
+We recommend using [Rivet Actors](https://rivet.dev/docs/actors) because they provide a portable way to run `agentOS()` on any infrastructure with built-in persistence, networking, and orchestration. Use the core package if you need the most bare-bones implementation possible.
 
 ## Install
 

website/src/content/docs/docs/workflows.mdx

@@ -232,4 +232,4 @@ await handle.send("codeReview", { filePath: "/home/agentos/src/auth.ts" });
 - Pass data between steps via the filesystem or step return values, not session state.
 - Keep `state` changes and other actor-local side effects inside `ctx.step()` callbacks; use non-step workflow code (queue waits, loops, sleeps) only for orchestration.
 - Reach the agentOS VM, a separate actor, from inside a step with `ctx.client()`.
-- See [Workflows](/docs/actors/workflows) for the full workflow API reference including timers, joins, and races.
+- See [Workflows](https://rivet.dev/docs/actors/workflows) for the full workflow API reference including timers, joins, and races.