docs(seo): cross-link integrations, cookbook recipes, and topic hubs

content/docs/cookbook/agentkit.mdx

@@ -9,9 +9,9 @@ description: "Integrate Steel with Inngest's AgentKit framework."
 
 <RecipeQuickstart slug="agentkit" />
 
-Agent Kit is Inngest's framework for multi-agent systems: a **tool** is a typed function the model can call, an **agent** bundles a system prompt with a tool set, and a **network** groups agents so they can collaborate on a task. Agent Kit handles the routing between them and wraps each call in Inngest's `step.run` checkpoint, so a network that crashes mid-flight resumes from the last finished step.
+Agent Kit is Inngest's framework for [multi-agent systems](/cookbook/topics/agents): a **tool** is a typed function the model can call, an **agent** bundles a system prompt with a tool set, and a **network** groups agents so they can collaborate on a task. Agent Kit handles the routing between them and wraps each call in Inngest's `step.run` checkpoint, so a network that crashes mid-flight resumes from the last finished step.
 
-This starter wires Agent Kit to Steel through a single tool, `browse_hacker_news`, that opens a Steel session, drives it with Playwright over CDP, and returns structured rows.
+This starter wires Agent Kit to Steel through a single tool, `browse_hacker_news`, that opens a Steel session, drives it with Playwright over CDP, and returns structured rows. The [Inngest AgentKit integration](/integrations/agentkit) covers install and configuration.
 
 ```typescript
 const browseHackerNews = createTool({

content/docs/cookbook/agno.mdx

@@ -11,7 +11,7 @@ description: Integrate Steel with the Agno agent framework.
 
 Agno's primitive is `Agent(model=..., tools=[...])`. Tools are typed Python methods grouped into a `Toolkit` subclass; docstrings and type hints become the JSON schema the model sees.
 
-This recipe wraps a Steel browser in a `SteelTools` toolkit, hands it to an Agent, and lets the model drive the session by picking which method to call and filling in arguments on its own.
+This recipe wraps a Steel browser in a `SteelTools` toolkit, hands it to an Agent, and lets the model drive the session by picking which method to call and filling in arguments on its own. The [Agno integration](/integrations/agno) covers install and configuration.
 
 ```python
 tools = SteelTools(api_key=STEEL_API_KEY)

content/docs/cookbook/auth-context.mdx

@@ -79,7 +79,7 @@ Auth context fits one-shot flows where you already have a way to log in and just
 - Run an agent that signs in, snapshot at the end, hand the snapshot to the next agent in the pipeline.
 - Keep a single "warm" context in memory and spawn short-lived workers from it.
 
-If you want Steel to store credentials and handle the login itself, see [credentials](/cookbook/credentials). If you need a long-lived named identity that accumulates state across runs (history, extensions, preferences), that's a different primitive.
+If you want Steel to store credentials and handle the login itself, see [credentials](/cookbook/credentials). If you need a long-lived named identity that accumulates state across runs (history, extensions, preferences), that's a different primitive. The [authentication topic](/cookbook/topics/authentication) collects the related recipes.
 
 ## Make it yours
 

content/docs/cookbook/browser-use-captcha-auto.mdx

@@ -9,7 +9,7 @@ description: Build an AI agent with browser-use and Steel that solves CAPTCHAs a
 
 <RecipeQuickstart slug="browser-use-captcha-auto" />
 
-Steel can solve CAPTCHAs inside a session without the agent lifting a finger. This recipe wires that into Browser Use: one flag at session creation, one custom tool the agent calls to block until the solver reports done. Everything else is the same perception-plan-act loop as the base [Browser Use](/cookbook/browser-use) recipe.
+Steel can solve [CAPTCHAs](/cookbook/topics/captchas) inside a session without the agent lifting a finger. This recipe wires that into Browser Use: one flag at session creation, one custom tool the agent calls to block until the solver reports done. Everything else is the same perception-plan-act loop as the base [Browser Use](/cookbook/browser-use) recipe.
 
 ```python
 session = client.sessions.create(solve_captcha=True)

content/docs/cookbook/browser-use-captcha-manual.mdx

@@ -9,7 +9,7 @@ description: "Manually solve reCAPTCHA v2 using Steel's CAPTCHA API with the bro
 
 <RecipeQuickstart slug="browser-use-captcha-manual" />
 
-Steel can solve CAPTCHAs for you in the background, or it can hand you the status API and let you drive. This recipe picks the second path. The session is created with auto-solving explicitly off, a custom Browser Use tool polls `client.sessions.captchas.status()`, and it calls `client.sessions.captchas.solve()` only for the CAPTCHA type you care about. Every state transition (detected, solving, validating, solved) is yours to read and react to.
+Steel can solve [CAPTCHAs](/cookbook/topics/captchas) for you in the background, or it can hand you the status API and let you drive. This recipe picks the second path. The session is created with auto-solving explicitly off, a custom Browser Use tool polls `client.sessions.captchas.status()`, and it calls `client.sessions.captchas.solve()` only for the CAPTCHA type you care about. Every state transition (detected, solving, validating, solved) is yours to read and react to.
 
 ```python
 session = client.sessions.create(

content/docs/cookbook/browser-use.mdx

@@ -9,7 +9,7 @@ description: Integrate Steel with the browser-use framework for AI-driven web au
 
 <RecipeQuickstart slug="browser-use" />
 
-Browser Use is an agent framework: you give it an LLM, a browser, and a natural-language `task`, and it runs a perception-plan-act loop until the task is done. It doesn't need selectors or scripted steps. The model reads the page, decides the next action, and executes it against the browser you give it. The browser in this recipe is a Steel session, so the agent runs on managed cloud Chrome with stealth, proxies, and a live viewer instead of local Chromium.
+[Browser Use](/cookbook/topics/browser-use) is an agent framework: you give it an LLM, a browser, and a natural-language `task`, and it runs a perception-plan-act loop until the task is done. It doesn't need selectors or scripted steps. The model reads the page, decides the next action, and executes it against the browser you give it. The browser in this recipe is a Steel session, so the agent runs on managed cloud Chrome with stealth, proxies, and a live viewer instead of local Chromium. The [Browser Use integration](/integrations/browser-use) covers install and setup.
 
 ```python
 session = client.sessions.create()

content/docs/cookbook/chromedp.mdx

@@ -9,7 +9,7 @@ description: Use Steel with chromedp to connect over CDP, navigate to Hacker New
 
 <RecipeQuickstart slug="chromedp" />
 
-chromedp speaks the Chrome DevTools Protocol over a websocket and never shells out to a local Chrome. A Steel session exposes exactly that websocket, so `chromedp.NewRemoteAllocator` points at the remote browser and every `chromedp.Run` step executes in the cloud, behind Steel's stealth, proxies, and live viewer. No browser on your machine.
+chromedp speaks the Chrome DevTools Protocol over a websocket and never shells out to a local Chrome. A Steel session exposes exactly that websocket, so `chromedp.NewRemoteAllocator` points at the remote browser and every `chromedp.Run` step executes in the cloud, behind Steel's stealth, proxies, and live viewer. No browser on your machine, just the same [browser automation](/cookbook/topics/browser-automation) over CDP the other driver recipes use.
 
 ```go
 cdpURL := fmt.Sprintf("%s&apiKey=%s", sess.WebsocketURL, apiKey)

content/docs/cookbook/chromiumoxide.mdx

@@ -9,7 +9,7 @@ description: Use Steel with chromiumoxide to connect over CDP, drive the handler
 
 <RecipeQuickstart slug="chromiumoxide" />
 
-chromiumoxide speaks the Chrome DevTools Protocol over a websocket, which is exactly what a Steel session exposes. `Browser::connect` takes the session's websocket URL and hands back a connected browser plus a `Handler`. From there you get plain async chromiumoxide: `new_page`, `content`, `get_title`, `find_elements`, `evaluate`, `screenshot`. No local Chrome, no `chromedriver`, no display.
+chromiumoxide speaks the Chrome DevTools Protocol over a websocket, which is exactly what a Steel session exposes. `Browser::connect` takes the session's websocket URL and hands back a connected browser plus a `Handler`. From there you get plain async chromiumoxide: `new_page`, `content`, `get_title`, `find_elements`, `evaluate`, `screenshot`. No local Chrome, no `chromedriver`, no display, just [browser automation](/cookbook/topics/browser-automation) over CDP against a cloud browser.
 
 The connection is one line, but it returns a tuple, and the second half is the part that trips everyone up:
 

content/docs/cookbook/claude-agent-sdk.mdx

@@ -13,9 +13,9 @@ description: "Use Steel with the Claude Agent SDK (TypeScript) to build a tool-u
 
 <RecipeQuickstart slug="claude-agent-sdk-ts" />
 
-`@anthropic-ai/claude-agent-sdk` is the engine behind the Claude Code CLI, exposed as a Node library. You get the CLI's agent loop, hooks, subagents, MCP support, and built-in tool catalog (`Read`, `Edit`, `Bash`, `Grep`, ...) without spawning the CLI yourself.
+`@anthropic-ai/claude-agent-sdk` is the engine behind the Claude Code CLI, exposed as a Node library. You get the CLI's [agent loop](/cookbook/topics/agents), hooks, subagents, MCP support, and built-in tool catalog (`Read`, `Edit`, `Bash`, `Grep`, ...) without spawning the CLI yourself.
 
-This recipe disables those built-ins and attaches a Steel cloud browser instead. Four MCP tools (`openSession`, `navigate`, `snapshot`, `extract`) sit in front of Playwright; the agent calls them by name and streams back typed messages.
+This recipe disables those built-ins and attaches a Steel cloud browser instead; the [Claude Agent SDK integration](/integrations/claude-agent-sdk) covers install and setup. Four MCP tools (`openSession`, `navigate`, `snapshot`, `extract`) sit in front of Playwright; the agent calls them by name and streams back typed messages.
 
 ```typescript
 const navigate = tool(

content/docs/cookbook/claude-computer-use-mobile.mdx

@@ -9,7 +9,7 @@ description: Claude Computer Use with Steel for autonomous task execution in mob
 
 <RecipeQuickstart slug="claude-computer-use-mobile" />
 
-Mobile-emulated Chrome, driven by Claude's computer-use tool. The agent loop is the same as the [Desktop TS](/cookbook/claude-computer-use) recipe (screenshot in, coordinate out, next screenshot back), but three things change when the surface is a phone: Steel allocates the viewport instead of you, Playwright drives the page over CDP instead of Steel's Input API, and every coordinate is clamped before it touches the browser.
+Mobile-emulated Chrome, driven by Claude's computer-use tool. The agent loop is the same as the [Desktop TS](/cookbook/claude-computer-use) recipe (screenshot in, coordinate out, next screenshot back), but three things change when the surface is a [phone](/cookbook/topics/mobile): Steel allocates the viewport instead of you, Playwright drives the page over CDP instead of Steel's Input API, and every coordinate is clamped before it touches the browser. The [Claude Computer Use integration](/integrations/claude-computer-use) covers the base setup.
 
 ## Mobile session, Playwright driver
 

content/docs/cookbook/claude-computer-use.mdx

@@ -13,7 +13,7 @@ description: Connect Claude to a Steel browser session for autonomous web intera
 
 <RecipeQuickstart slug="claude-computer-use-ts" />
 
-Claude sees the screen as an image and returns concrete actions at pixel coordinates: `left_click [640, 412]`, `type "claude 4.7 opus"`, `scroll down 3`. Something has to execute those actions against a real browser and send the next screenshot back. That "something" is the agent loop in `index.ts`, and the browser is a Steel session.
+Claude sees the screen as an image and returns concrete actions at pixel coordinates: `left_click [640, 412]`, `type "claude 4.7 opus"`, `scroll down 3`. Something has to execute those actions against a real browser and send the next screenshot back. That "something" is the agent loop in `index.ts`, and the browser is a Steel session. The [Claude Computer Use integration](/integrations/claude-computer-use) covers install and setup.
 
 ## The loop
 
@@ -31,7 +31,7 @@ const response = await this.client.beta.messages.create({
 
 The tool definition declares `computer_20251124` with the viewport's `display_width_px` and `display_height_px`. Keep it consistent with the Steel session's `dimensions` (1280x768 here) or clicks land in the wrong place.
 
-`executeComputerAction` is the translation layer. Claude emits computer-use actions (`left_click`, `type`, `key`, `scroll`, `screenshot`, ...); Steel's Input API speaks a parallel vocabulary (`click_mouse`, `type_text`, `press_key`, `scroll`, `take_screenshot`):
+`executeComputerAction` is the translation layer. Claude emits [computer-use actions](/cookbook/topics/computer-use) (`left_click`, `type`, `key`, `scroll`, `screenshot`, ...); Steel's Input API speaks a parallel vocabulary (`click_mouse`, `type_text`, `press_key`, `scroll`, `take_screenshot`):
 
 ```typescript
 case "left_click":

content/docs/cookbook/convex-chat-with-page.mdx

@@ -9,7 +9,7 @@ description: "Convex app that streams an AI agent's answer about any URL. The ag
 
 <RecipeQuickstart slug="convex-chat-with-page" />
 
-A Convex app where the user pastes a URL, asks a question, and an AI agent answers from the live page. The agent runs server-side as a `pageAgent` defined in `convex/agent.ts`, with a single tool, `scrapePage`, that fetches the URL through the `@steel-dev/convex` component and serves the markdown back in chunks. Tokens stream into the UI over websockets via `@convex-dev/agent`'s delta sync.
+A [Convex](/cookbook/topics/convex) app where the user pastes a URL, asks a question, and an [AI agent](/cookbook/topics/agents) answers from the live page. The agent runs server-side as a `pageAgent` defined in `convex/agent.ts`, with a single tool, `scrapePage`, that fetches the URL through the `@steel-dev/convex` component and serves the markdown back in chunks. Tokens stream into the UI over websockets via `@convex-dev/agent`'s delta sync.
 
 ```
 convex/

content/docs/cookbook/convex-price-watch.mdx

@@ -9,7 +9,7 @@ description: Convex cron plus two parallel Steel proxy probes against claude.com
 
 <RecipeQuickstart slug="convex-price-watch" />
 
-A scheduled monitor: scrape `https://claude.com/pricing` every 10 minutes from two parallel proxy probes, store one row per (region, tier, capturedAt) in Convex, and surface tiers where the probes disagree. No LLM, no streaming. Just `@steel-dev/convex`, a cron, and a reactive dashboard.
+A scheduled monitor: scrape `https://claude.com/pricing` every 10 minutes from two parallel proxy probes, store one row per (region, tier, capturedAt) in [Convex](/cookbook/topics/convex), and surface tiers where the probes disagree. No LLM, no streaming. Just `@steel-dev/convex`, a cron, and a reactive dashboard.
 
 ```
 convex/

content/docs/cookbook/credentials.mdx

@@ -13,7 +13,7 @@ description: Use the Steel Credentials API with Playwright to automate flows wit
 
 <RecipeQuickstart slug="credentials-ts" />
 
-Steel's credentials vault stores usernames and passwords against an origin. When a session opts in, Steel watches for login forms on that origin and fills them for you. No login code in your automation, no plaintext passwords in env vars, no custom storage for cookies.
+Steel's credentials vault stores usernames and passwords against an origin. When a session opts in, Steel watches for login forms on that origin and fills them for you. No login code in your automation, no plaintext passwords in env vars, no custom storage for cookies. It's one of Steel's [authentication](/cookbook/topics/authentication) primitives.
 
 Two API calls wire it up. First, save the credential once:
 

content/docs/cookbook/crewai.mdx

@@ -9,7 +9,7 @@ description: Integrate Steel with the CrewAI multi-agent framework.
 
 <RecipeQuickstart slug="crewai" />
 
-CrewAI composes LLM work out of three primitives: an `Agent` (role, goal, tools), a `Task` (description + expected output), and a `Crew` that runs them in order. This recipe wires two agents, a `researcher` and a `reporting_analyst`, to a single custom tool that calls Steel's scrape API. The researcher gathers sources; the analyst turns them into `report.md`.
+CrewAI composes LLM work out of three primitives: an `Agent` (role, goal, tools), a `Task` (description + expected output), and a `Crew` that runs them in order. This recipe wires two [agents](/cookbook/topics/agents), a `researcher` and a `reporting_analyst`, to a single custom tool that calls Steel's scrape API. The researcher gathers sources; the analyst turns them into `report.md`. The [CrewAI integration](/integrations/crewai) covers install and setup.
 
 ```python
 @agent

content/docs/cookbook/deep-research.mdx

@@ -13,9 +13,9 @@ description: Lead orchestrator dispatches parallel researcher subagents, each dr
 
 <RecipeQuickstart slug="deep-research-ts" />
 
-`@anthropic-ai/claude-agent-sdk` exposes typed `AgentDefinition` values that you pass through the `agents` field on `query()`. The lead agent invokes them through the built-in `Agent` tool. Multiple `Agent` calls fired in a single assistant turn run in parallel, and each subagent starts in fresh context.
+`@anthropic-ai/claude-agent-sdk` exposes typed `AgentDefinition` values that you pass through the `agents` field on `query()`. The lead agent invokes them through the built-in `Agent` tool. Multiple `Agent` calls fired in a single assistant turn run in parallel, and each [subagent](/cookbook/topics/subagents) starts in fresh context.
 
-This recipe wires that pattern to Steel. The lead "orchestrator" never opens a browser. It splits a research question into focused sub-questions, hands one to each `researcher` subagent, and synthesizes their cited findings into a Markdown report. Every researcher gets its own Steel session, so three browsers run side by side without stomping on each other's address bar.
+This recipe wires that pattern to Steel, built on the [Claude Agent SDK integration](/integrations/claude-agent-sdk). The lead "orchestrator" never opens a browser. It splits a research question into focused sub-questions, hands one to each `researcher` subagent, and synthesizes their cited findings into a Markdown report. Every researcher gets its own Steel session, so three browsers run side by side without stomping on each other's address bar.
 
 ```ts
 const researcher: AgentDefinition = {

content/docs/cookbook/eino.mdx

@@ -9,7 +9,7 @@ description: "Use Steel with the ByteDance Eino framework to build a ReAct agent
 
 <RecipeQuickstart slug="eino" />
 
-[Eino](https://www.cloudwego.io/docs/eino/) is ByteDance's LLM application framework for Go. Its `flow/agent/react` package ships a prebuilt ReAct agent: give it a tool-calling model and a set of tools, and it runs the reason-act loop for you. This recipe gives that agent two tools backed by Steel's Scrape API and points it at a news front page to write a short research briefing.
+[Eino](https://www.cloudwego.io/docs/eino/) is ByteDance's LLM application framework for Go. Its `flow/agent/react` package ships a prebuilt [ReAct agent](/cookbook/topics/agents): give it a tool-calling model and a set of tools, and it runs the reason-act loop for you. This recipe gives that agent two tools backed by Steel's Scrape API and points it at a news front page to write a short research briefing.
 
 Unlike a CDP-driven recipe, there is no browser session to open or release here. `client.Scrape` runs a browser on Steel's side, fetches the page, and returns clean Markdown plus the page's links. The agent reads pages the way an LLM wants to read them (as text, not pixels), so the tools are plain HTTP calls and the whole program is stateless between turns.