From fabff1f0e88d7f7aed2264b9c715fa905514eedc Mon Sep 17 00:00:00 2001 From: Nicholas Kissel Date: Sat, 27 Jun 2026 11:47:46 -0700 Subject: [PATCH] fix(website): repair broken docs links and anchors - Repoint four home-page feature cards to existing docs pages - Convert dead /docs/actors* links to rivet.dev externals - Fix stale heading anchors in architecture, filesystem, and bindings docs --- .../src/components/marketing/solutions/AgentOSPage.tsx | 8 ++++---- .../docs/docs/architecture/agent-sdk-snapshots.mdx | 2 +- .../src/content/docs/docs/architecture/agent-sessions.mdx | 6 +++--- website/src/content/docs/docs/architecture/filesystem.mdx | 2 +- website/src/content/docs/docs/authentication.mdx | 4 ++-- website/src/content/docs/docs/bindings.mdx | 2 +- website/src/content/docs/docs/core.mdx | 2 +- website/src/content/docs/docs/workflows.mdx | 2 +- 8 files changed, 14 insertions(+), 14 deletions(-) diff --git a/website/src/components/marketing/solutions/AgentOSPage.tsx b/website/src/components/marketing/solutions/AgentOSPage.tsx index c1f709ac2..742777d2c 100644 --- a/website/src/components/marketing/solutions/AgentOSPage.tsx +++ b/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 --- diff --git a/website/src/content/docs/docs/architecture/agent-sdk-snapshots.mdx b/website/src/content/docs/docs/architecture/agent-sdk-snapshots.mdx index bbdf693b5..c02a48c90 100644 --- a/website/src/content/docs/docs/architecture/agent-sdk-snapshots.mdx +++ b/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. diff --git a/website/src/content/docs/docs/architecture/agent-sessions.mdx b/website/src/content/docs/docs/architecture/agent-sessions.mdx index 11d307088..70bc723cf 100644 --- a/website/src/content/docs/docs/architecture/agent-sessions.mdx +++ b/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). ## 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. diff --git a/website/src/content/docs/docs/architecture/filesystem.mdx b/website/src/content/docs/docs/architecture/filesystem.mdx index 41eccf38d..ac2d703fc 100644 --- a/website/src/content/docs/docs/architecture/filesystem.mdx +++ b/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 diff --git a/website/src/content/docs/docs/authentication.mdx b/website/src/content/docs/docs/authentication.mdx index 0d049acab..1eb6d40e8 100644 --- a/website/src/content/docs/docs/authentication.mdx +++ b/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. diff --git a/website/src/content/docs/docs/bindings.mdx b/website/src/content/docs/docs/bindings.mdx index 1d64f4a11..4c8b86b86 100644 --- a/website/src/content/docs/docs/bindings.mdx +++ b/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 diff --git a/website/src/content/docs/docs/core.mdx b/website/src/content/docs/docs/core.mdx index 68b1ea346..3d5cf244c 100644 --- a/website/src/content/docs/docs/core.mdx +++ b/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 diff --git a/website/src/content/docs/docs/workflows.mdx b/website/src/content/docs/docs/workflows.mdx index afbb28b71..b5b153dbd 100644 --- a/website/src/content/docs/docs/workflows.mdx +++ b/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.