# Cursor Agent SDK The Cursor Agent SDK is [[Cursor]]'s framework for building agents as code. It became generally available on 20 October 2026. It isn't a new toy for Cursor: it's "the framework we use to build our own managed agents", like [[Cursor BugBot|Bugbot]], Security Reviewer and Rollouts. Now you get the same tool. The idea is simple. An agent is a small software project: a folder of Markdown and [[TypeScript]] that holds the instructions, the tools, the service connections and the evals. It lives in Git, and changes go through code review like any other code. In Cursor's words: "define agents in code and manage them like any other software project." ## How it works - **Prompts in Markdown, tools in TypeScript.** You write the instructions, the tools (plain TypeScript functions) and deterministic code hooks. You define the agent with `defineAgent` (the blog example uses the `composer-2.5` model with high effort) - **Cursor runs the loop.** Sessions, [[AI Subagents|subagents]], tool calls, model routing, evals, [[Model Context Protocol (MCP)|MCP]] connections, secrets, sandboxing, deployment and storage are Cursor's job. You own what the agent does; Cursor owns how it runs - **Develop locally.** `agent-sdk init ./my-bot`, then `agent-sdk dev` opens a local playground. Evals and event replay are built in, so you can re-run a real event (a PR, an incident) against a new version of the agent - **Deploy in one command.** `agent-sdk deploy` builds the agent, gives it a URL and hosts it on Cursor's infrastructure. Secrets and integrations are managed in the dashboard - **Or self-host it.** Each agent is a single [[Node.js]] process (Node 22.13+), so you can put it in a [[Docker]] container on your own servers - **Agents that build agents.** Cursor ships [[AI Agent Skills|skills]] so your coding agent can build SDK agents for you, and you can point it at the docs A small naming mess to be aware of: the blog imports from `@cursor/agent-sdk`, while the docs install the CLI as `@grok/agent-sdk` (formerly `@cursor/bdk`). That's probably the SpaceX/[[xAI]] acquisition showing through. Check the docs before you copy an install command. ## Where it sits in Cursor's offer Cursor now has three ways to run an agent without you watching it: | | You define | Where it runs | |---|---|---| | [[Cursor Automations]] | A prompt, a model and a trigger, in the dashboard | Cursor's cloud | | Grok Bot | Instructions, skills and connected tools, in the app | Cursor's cloud | | **Agent SDK** | A versioned Markdown and TypeScript project | Cursor's cloud or your infrastructure | The rule of thumb from the docs: use the SDK when you want code around model judgment that your team can version, review, test and improve. There's even a guide to convert an Automation into an SDK project once it outgrows the dashboard. ## What people build with it - **PR review.** React to pull requests on GitHub, GitLab or Bitbucket, assess the risk, route the review to the right team, and approve changes that meet your policy. The docs ship templates for review, triage and an owners-policy approver - **Compliance and incident investigation.** Long, boring, rule-heavy work - **kb-reviewer.** A Cursor team built it in about a day. It checks every PR against a lessons-learned knowledge base and cites the note that applies. I love this one: it turns a team's past mistakes into a reviewer that never forgets them - **PGA Tour / PGA America** built their whole "software factory" on it, according to their principal engineer ## My take This is [[Harness Engineering]] packaged as a product. The model is the brain; the SDK project is where the body lives: tools, checks, evals, versioned and reviewed. That's the right shape. Prompts that live in a dashboard drift, nobody reviews them, and nobody can tell which version broke what. Putting them next to the tools and the evals, in Git, fixes most of that ([[Context-as-Code]] in practice). kb-reviewer is the pattern I'd copy first. My vault already holds lessons learned for my agents; a reviewer that cites them on every change is a cheap way to stop repeating mistakes. The tradeoff is lock-in. With the [[OpenAI Agents SDK]], [[Pi Mono|Pi]] or [[Mastra Harness]], the agent loop is a library in your code. Here, Cursor runs the loop, picks the routing and holds the evals and the replays. Self-hosting the Node process helps, but you're still building on Cursor's runtime, and Cursor now belongs to SpaceX/xAI. If you're a Cursor shop already, it's an easy yes. If not, I'd want to see how much of the project survives a move to another runtime before committing. ## References - Introducing the Agent SDK (Rustam Lalkaka, Cursor blog, 20 October 2026): https://cursor.com/blog/agent-sdk - Documentation: https://cursor.com/docs/agent-sdk ## Related - [[Cursor]] - [[Cursor Automations]] - [[Cursor Cloud Agents]] - [[Cursor BugBot]] - [[Cursor Subagents]] - [[Cursor Skills]] - [[Composer 2.5]] - [[AI SDKs]] - [[OpenAI Agents SDK]] - [[Claude Code SDK]] - [[GitHub Copilot SDK]] - [[Antigravity SDK]] - [[Mastra Harness]] - [[Pi Mono]] - [[Harness Engineering]] - [[AI Agent Harness]] - [[Agent Development Lifecycle (ADLC)]] - [[Context-as-Code]] - [[AI Agents]]