What "Harness Substrate" Actually Means in 2026

Cursor SDK — Engineers as the Distribution

Browserbase Skills — The Browser as Tool

OpenAI Apps SDK — Distribution as the Lock-In

The Positioning Matrix

Migration Paths and Exit Ramps

Conclusion: Substrate Selection Is the New Cloud Selection In the last five days, the agent-runtime question went from "which model do I use?" to "which substrate do I deploy on?" That is a structural shift, and it is being driven by three near-simultaneous launches that companies will pick between for the next six months of agent embedding work: 📖 Read the full version with the positioning matrix on AgentConn → The convergence is not coincidence. As Y Combinator's "Software for Agents" pitch and the Cursor/Browserbase/OpenAI launches all crystallized into one week, the read in today's convergence cluster is that the harness layer has finished commoditizing as a feature and is now monetizing as a runtime. Pure orchestration is no longer a category. Substrate is. This piece is the positioning matrix for the three substrates, the lock-in profile each one creates, and the migration path from skills-directory experiments (which we covered in the Cursor 12K-to-200-LoC case study) to production runtime selection. We're explicitly not recommending one — the right answer depends on where your distribution lives. The terminology has shifted fast. A year ago, "agent harness" meant the while True: agent.step() loop wrapping an API call. Today, that loop is a CLI primitive — Codex /goal, Claude Code's session loop, Cursor's runtime — and it ships free with every major coding-agent platform. So if the loop is commodity, what's the new boundary? The answer is the runtime substrate — the bundle of (a) the loop, (b) sandboxed compute, (c) authenticated tool access, (d) skill/MCP discovery, (e) distribution surface. A substrate is what you deploy on, not what you build with. And substrates have very different shapes: Three completely different distribution graphs. Three completely different lock-in profiles. The same underlying primitive — a model that loops, calls tools, and produces output. The Cursor SDK launch is the most operationally specific of the three. Available as npm install @cursor/sdk, the SDK exposes agents that get the full Cursor harness: codebase indexing, MCP servers, skills auto-discovery from .cursor/skills/, hooks via .cursor/hooks.json, and subagents that delegate work via named prompts. The named launch customers — Faire, Rippling, Notion, C3 AI — are not pilot decorations. They are the primary use case in compressed form. Per the launch post, teams at Rippling and Notion are "running agents that pick up Linear or Jira tickets, understand the requirement, generate the implementation, write tests, and open a draft PR for engineer review." That's the canonical Cursor SDK shape: an asynchronous CI/CD-adjacent worker that lives in your engineering pipeline and produces draft PRs for human review. The pricing surface is token-based, not seat-based. Composer 2 Standard runs $0.50 per million input tokens and $2.50 per million output tokens, billed at the API level — not at the seat level. That changes the deployment math materially: you can spin up a thousand parallel agents in CI without a thousand Cursor seats, and you only pay for the work that actually executes. This is the structural advantage Cursor is pressing against the seat-priced incumbents. MarkTechPost's coverage frames it cleanly: "sandboxed cloud VMs, subagents, hooks, and token-based pricing." 💡 Lock-in profile: Cursor SDK locks you into the Composer model line and the .cursor/ skills directory. Skills written for Cursor SDK are almost portable to Claude Code (the SKILL.md spec is shared) but the subagent and hook primitives are Cursor-specific. The exit ramp is the cross-runtime layer — see the gstack open-source harness builder and the cc-switch pattern — but you pay an integration cost on the way out. The signal Cursor is sending with named launch customers and CI/CD examples is that they want to own the engineering-pipeline runtime slot. Not the IDE — they already have that. The pipeline. That's the new battleground. Browserbase Skills is the substrate that picked the smallest fight and is winning it cleanly. The repo description is "a set of skills for enabling Claude Code to work with Browserbase through browser automation and the official bb CLI." Nine skills, all installable via /plugin install browse@browserbase from Claude Code's marketplace: The strategic move here is subtle: Browserbase did not try to be a coding-agent runtime. It built tools for the agents that already exist. By deploying as a Claude Code plugin instead of a competing harness, Browserbase made every Claude Code user a potential customer without having to win them away from Anthropic's distribution. The substrate they're competing on is browser automation as a service — anti-bot fingerprints, session replay, captcha resolution, agent identity. None of those are things Anthropic is going to ship, and few are things Cursor is going to ship. The companion product, Stagehand, is the open-source SDK for browser agents — the layer that lets you write page.act("click the cart button") and have the model handle the selector logic. The Browserbase business model is the cloud runtime underneath: scale-out browser sessions, residential proxies, function-style deployments. Open source on top, paid runtime underneath — the Browserbase internal-agents post walks through the same pattern as the production case study. 💡 Lock-in profile: Browserbase Skills is the lowest-lock-in of the three. Stagehand is open source; you can self-host browser sessions; you can swap the Claude harness underneath. The lock-in lives in Browserbase's paid runtime — anti-bot evasion, fingerprint randomization, residential proxy pools — which is genuinely hard to replicate in-house. If your agents need to log into customer SaaS to scrape or operate, Browserbase's runtime is the default. If they only need to read public pages, you can leave any time. The shape this takes in production: any agent that needs to operate inside a browser session — booking, e-commerce, internal-tool automation, support-ticket resolution — uses Browserbase as the tool layer and Cursor SDK / Claude Code / OpenAI Agents SDK as the orchestration layer. It is not an either-or with the other two substrates. It is a complement. OpenAI's Apps SDK is the substrate with the largest distribution graph and the heaviest gravity. Launched at DevDay 2025 (October 6) and reinforced by the April 15 Agents SDK update, the architecture is simple in principle: The April 15 update added Sandbox Agents as a runtime layer — a SandboxAgent / Manifest / SandboxRunConfig stack with backends for local development (UnixLocalSandboxClient, DockerSandboxClient) and hosted partner integrations for Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel. That partner list is the tell. OpenAI is not building the compute layer — they are integrating with everyone who already does. The Apps SDK is the distribution layer; the partner runtimes are the substrate underneath. Pilot apps in the launch wave: Booking.com, Canva, Coursera, Figma, Expedia, Spotify, Zillow. Notice the pattern — these are not developer tools. They are consumer destinations. The shape OpenAI is pushing is that ChatGPT becomes the aggregator and your existing consumer surface becomes a tool inside it. The agent is the chat. Your app is the back-end. 💡 Lock-in profile: Apps SDK is the highest-lock-in of the three. Your distribution is gated by ChatGPT's directory inclusion and review process. Your runtime is structurally biased toward partners OpenAI has integrated with. Pricing is tied to the App Directory monetization rules (still emerging — see the Render field guide for the current state of in-app billing). The exit ramp is the MCP standard itself: because everything is built on MCP, your server can theoretically be exposed to other harnesses. In practice, the integration surface — auth, billing, UX — is where the lock-in concentrates. The three substrates are not direct competitors. They are competing for different ends of the same value chain: Cursor for the engineering pipeline runtime, Browserbase for the browser-tool runtime, OpenAI Apps SDK for the consumer-distribution runtime. Here's the comparison most teams need: The pattern that emerges when you read the matrix horizontally: most production agent stacks in late 2026 will use two of the three. A Cursor SDK code agent that calls Browserbase Skills for browser-side QA. An OpenAI Apps SDK consumer app whose back-end operates a Browserbase-hosted browser to fulfill orders. A Cursor-built internal agent that surfaces in ChatGPT via the Apps SDK MCP-export path. This is the same pattern AWS / GCP / Azure formed in 2014–2018: not winner-take-all, but each cloud occupying a defensible niche while being interoperable enough to combine. The agent-runtime layer is hitting the same equilibrium five years faster. The strategic question every team is asking right now is how reversible is this choice. The honest answers: The convergence-report take from Radar frames the macro reality: "Anyone shipping pure orchestration without distribution should be selling, not raising." That's the exit-ramp signal. Pure-orchestration startups will get acquired or absorbed; substrate-and-distribution plays will keep raising. The three SDKs we just compared are all on the latter side of that line. 💡 The one decision that matters most: which distribution graph are you closest to? If your users are engineers, Cursor. If your agent has to run inside an authenticated browser, Browserbase (composed with one of the others). If your value lives on the consumer side, OpenAI Apps SDK. Pick that first. The runtime details follow. Six months ago, the question was "Anthropic or OpenAI for the model?" Three months ago, it was "Claude Code or Codex for the harness?" Today, it's "Cursor SDK, Browserbase Skills, or OpenAI Apps SDK for the runtime substrate?" That ladder of abstraction is exactly the same one the cloud business climbed in 2010–2014: from "which servers" to "which managed services" to "which platform-of-platforms." The people who picked AWS in 2012 are not regretting it; the people who built on Heroku because it was the easiest path are. The same shape is forming now in the agent layer, and the substrate choices made in May 2026 will look in retrospect like the platform-of-platforms commitments of the next cycle. The migration math is real but not destiny. MCP being the open standard underneath all three substrates means the worst-case migration cost is bounded. The named customers (Faire, Rippling, Notion, Booking.com, Figma, Spotify) are voting with their integration budgets. And the YC / Karpathy / Naval thesis convergence we tracked in today's convergence report confirms that the runtime layer — not the model layer, not the harness layer — is the next 12-month battleground. Pick by distribution. Hedge by composition. Run the matrix on your own use cases this week, and don't expect any single substrate to win all three columns. Templates let you quickly answer FAQs or store snippets for re-use. as well , this person and/or - Cursor SDK went into public beta on April 29, exposing the Cursor harness — codebase indexing, MCP servers, skills, hooks, subagents — as a TypeScript runtime that "you can run from CI/CD pipelines, embed in customer-facing products, or wire into kanban-driven ticket-to-PR flows."

- Browserbase Skills crossed 1.6k stars on GitHub trending with a nine-skill bundle that turns Claude Code into a remote-browser agent — anti-bot stealth, CAPTCHA solving, residential proxies, all addressable as bb CLI commands the model invokes inline.- OpenAI's Apps SDK — launched at DevDay 2025 and reinforced by the April 15 Agents SDK update — is the MCP-native runtime where 800M weekly ChatGPT users meet your tool. Pilot partners include Booking.com, Canva, Coursera, Figma, Expedia, Spotify, and Zillow. - IDE-driven: Cursor SDK runs your agents on the same cloud VMs that power Cursor's Cloud Agents. Distribution is "engineers already have Cursor open." Lock-in is the Composer model line and the .cursor/ skills directory.- Browser-native: Browserbase Skills runs your agents inside remote, fingerprint-resistant browser sessions. Distribution is "Claude Code users who installed the plugin." Lock-in is the Browserbase platform — sessions, contexts, and the Functions runtime.- ChatGPT-distributed: OpenAI's Apps SDK runs your MCP server alongside ChatGPT itself. Distribution is "every paying ChatGPT user." Lock-in is the App Directory and the partnership/review process for inclusion. - You ship an MCP server that defines your tools and capabilities.- You optionally ship a web component rendered as an iframe inside ChatGPT.- The Apps SDK handles discovery, authentication, billing surfaces, and rendering.- Your app runs alongside ChatGPT itself, available to every ChatGPT user as a /your-app mention. - Cursor SDK → Claude Code / Codex: Your skills (SKILL.md files) port cleanly. Your subagent and hook configs do not. Plan for ~1–2 weeks of adapter work per major flow. The cross-runtime tools at cc-switch help.- Browserbase Skills → self-hosted Playwright: Drop-in for the technical surface. The hard part is replicating the anti-bot, residential-proxy, and session-replay infrastructure that makes Browserbase's runtime defensible. Stagehand is open-source; the cloud runtime is what you're buying.- OpenAI Apps SDK → another MCP host: Theoretically clean (MCP is an open standard). Practically expensive (you lose the ChatGPT distribution graph that was the whole point). The exit is more likely to be "supplement Apps SDK with your own native channel" rather than "leave Apps SDK."