Three projects in this neighborhood get conflated constantly. They solve different problems, optimize for different teams, and the wrong choice will cost you months of refactoring. Here’s the honest decision matrix.

The three contenders

CopilotKit — React-first sidebar copilot framework. Wrap your app in <CopilotKit>, mark state with useCopilotReadable, expose actions with useCopilotAction. Gets you a polished sidebar AI in an afternoon.

Stagehand — Server-side browser-automation library (by the Browserbase team). Headless Playwright + agentic act / extract / observe primitives. Operates a browser for the user, often automating sites the operator doesn’t own.

Linda — In-browser agent SDK with a virtual filesystem view of the live page. Runs in the user’s tab. Reads the DOM directly. Multi-agent, MCP, browser-side file parsing.

What problem are you solving?

Decision starts here:

Your problemPick
Sidebar Q&A copilot for my React SaaSCopilotKit
Agent reads/writes my live page (forms, DOM)Linda
Automate browsers from a server (scraping, RPA)Stagehand
Browser extension with per-origin agentsLinda
In-page agent + sidebar Q&A bothLinda (covers both via slash commands)
Need framework-agnosticLinda
Need agent to operate on a SaaS I don’t ownStagehand (server) or Linda + extension (client)
Need browser-side file parsingLinda
Need real-time multi-agent handoffsLinda
Need first-class React componentsCopilotKit > Linda’s React wrapper

If you read that table and went “I want two of these,” that’s the right reaction. They overlap.

Where they overlap and where they don’t

Linda vs CopilotKit: same neighborhood. Both put an AI on your page. The architectural difference: CopilotKit asks you to plumb state via useCopilotReadable; Linda reads the DOM via /page. CopilotKit is React-first; Linda is framework-agnostic. CopilotKit has a cloud offering (Co-Agents); Linda is pure SDK.

The right one depends on how much state plumbing you want to do. Greenfield React apps where state is already React-native: CopilotKit is ergonomic. Existing apps, multiple frameworks, lots of dynamic DOM: Linda wins because there’s no plumbing.

Linda vs Stagehand: orthogonal. Both have act / extract / observe primitives but apply them in opposite directions. Stagehand: I (the operator) am running an agent on a headless browser somewhere. Linda: the user is running an agent on their browser. Same vocabulary, opposite contexts.

You might use Stagehand to test a Linda-powered form. You wouldn’t pick one over the other for the same problem.

CopilotKit vs Stagehand: different problems entirely. CopilotKit is for your end-user-facing app UX; Stagehand is for your server-side automation. You’re more likely to use both (CopilotKit for the UX, Stagehand for the backend agent that does work for the user) than to pick between them.

The architectural bets

Each project has made a bet about where AI agents on the web belong.

CopilotKit’s bet: AI on the web lives in a chat sidebar. Make that sidebar amazing — readable state, action handling, multi-step suggestions, document workflows. Bet pays off if “AI as sidebar” is the lasting paradigm.

Stagehand’s bet: AI on the web is for automating browsers. Make the headless agent loop reliable, observable, and primitive-rich. Bet pays off if RPA / scraping / web-agent-as-a-service is the dominant shape.

Linda’s bet: AI on the web lives in the page itself, as the user works. Make the in-page agent runtime small, capable, and provider-agnostic. Bet pays off if conversational agents become a UX layer on top of every web app.

All three bets can be right. They’re not zero-sum. But the choice you make commits you to one shape.

Practical trade-offs

DimensionCopilotKitStagehandLinda
Where it runsBrowser (React app)Server (headless browser)Browser (any page)
Where the user isLooking at your appNot in the loopOn their browser
Bundle size (gz)~80 KBN/A (server)~35 KB
FrameworkReactNodeAgnostic
Multi-agentCo-Agents (paid)LimitedBuilt-in
Browser APIsNoNoYes (clipboard, NFC, etc)
File parsingServer-sideBrowser-side (in headless)Browser-side (lazy WASM)
MCPLimitedLimitedClient + server
ProvidersAnthropic, OpenAIAnthropic5 + OpenAI-compatible
LicenseMITMITMIT
Hosted offeringYesYes (Browserbase)No
Sweet spotReact SaaS sidebarServer automationIn-page agent

A decision framework

Three questions get you to the right answer:

1. Who’s driving the browser?

  • Your server → Stagehand.
  • The user → CopilotKit or Linda.

2. Where does state live?

  • React useState/zustand/Redux, you’re happy plumbing it → CopilotKit.
  • The DOM, third-party state, multiple frameworks, dynamic → Linda.

3. What does the agent need to do?

  • Answer questions / suggest text → either CopilotKit or Linda.
  • Fill forms, click buttons, read files, hand off to specialists → Linda.

The honest verdict

There’s no winner. The honest answer is: pick the one whose architectural bet matches yours.

We built Linda because we wanted an in-browser agent that operates on the page like a colleague — reads what’s there, writes back, hands off when needed, parses files locally, talks to your CRM via MCP. That’s our bet.

If your bet is “AI as a polished React sidebar,” CopilotKit is excellent.

If your bet is “AI that drives browsers from my server,” Stagehand is excellent.

Read the comparison pages for the head-to-head deep-dives. Or just install Linda — 10-second demo — and see if its shape clicks.

FAQ

Can these three be used together?

Sometimes. Linda + Stagehand: opposite use cases, no conflict. Linda + CopilotKit: overlapping; pick one for the in-page agent surface.