Cursor makes its Agent SDK generally available for code-defined agents
Cursor announced that the Agent SDK is generally available. It is the framework Cursor uses to build its own managed agents, including Bugbot, Security Reviewer and Rollouts. The pitch: software teams already use agents defined as code for recurring work across the development lifecycle, such as reviewing a pull request, running a compliance workflow or investigating an incident. The most useful ones are tailored to how a particular team works, and until now, Cursor says, building one has generally meant adopting a product designed around someone else's workflow or starting from scratch.
With the SDK, agents are defined in code and managed like any other software project. An agent is organised like a small project: instructions sit alongside code for its tools, connections to outside services and the evals used to test it. Each file represents something the agent knows or can do. Prompts are written in Markdown, and tools are defined as TypeScript functions. Because everything is code, changes can go through the same version control and review process as the rest of a team's software. Users can start from a template or point their own coding agent at Cursor's docs; the SDK also ships with skills that guide coding agents through the development process.
Cursor's main example is code review. A team can build an agent that responds to pull request events from GitHub, GitLab or Bitbucket, assesses the risk of a change, routes it to the right team and approves changes that meet the team's policy. In a concrete case, a team inside Cursor had a large, fast-growing knowledge base of lessons learned and wanted every pull request checked against it, so that past decisions would hold as the codebase changed. They built an agent called kb-reviewer with the SDK in about a day. It now runs on every PR in their main codebase, flags changes that contradict a recorded lesson, cites the note behind each finding, and encourages engineers to reconcile the discrepancies it reports.
For more complicated work, agents can hand a task to another specialized agent with its own tools and sessions, or divide a job among subagents working in parallel. The SDK supports evals and event replay out of the box, which Cursor says allows rapid development with assurance that critical workflows execute as expected. The post says the PGA Tour uses the Agent SDK to power its software development factory, and includes an unquoted testimonial passage saying the SDK let PGA build every component of its software factory on Cursor's infrastructure and that built-in evals let it iterate quickly.
Deployment has two routes. Running agent-sdk deploy from the project directory builds the agent, gives it a URL and starts it on Cursor's infrastructure; secrets and integrations are managed from the dashboard, while the same logs, evals and playground available locally keep working. Alternatively, an agent can run on a team's own infrastructure: each agent is a single Node process that can be packaged in a container.
Getting started looks like starting any other software project: create a project directory and launch the local playground. The sample definition imports defineAgent from @cursor/agent-sdk and sets an agent named Robo with the model id composer-2.5 (parameters effort set to high and fast set to true) and a local working directory under the user's cache folder. From there, a developer iterates locally, runs evals, and then deploys with agent-sdk deploy.
Key facts
- Cursor says the Agent SDK is generally available; it is the framework behind its own managed agents Bugbot, Security Reviewer and Rollouts.
- Agents are defined in code: prompts in Markdown, tools as TypeScript functions, with evals and event replay supported out of the box.
- One command,
agent-sdk deploy, builds an agent, gives it a URL and starts it on Cursor infrastructure; agents can also run on a team's own infrastructure as a single Node process in a container. - A Cursor team built kb-reviewer, which checks every PR in its main codebase against a knowledge base of lessons learned, in about a day.
- Agents can hand tasks to specialized agents or split work among parallel subagents; the PGA Tour is named as a customer.
Why it matters
Cursor is opening up the internal framework behind its own production agents rather than a new product with a fixed workflow. The argument is that useful agents depend on a team's own standards, such as what needs review and who reviews it, and that teams have had to either adopt someone else's workflow or build from scratch. Treating agents as ordinary software projects, with version control, review and evals, is the SDK's answer.
Who it affects
Software teams that want agents reacting to events in their development process: pull requests on GitHub, GitLab or Bitbucket, compliance workflows, incident investigation. Cursor names the PGA Tour as a customer using the SDK for its software development factory. Teams that prefer to host their own agents are covered too, since an agent can run as a single Node process in a container.
How to use it
Create a project directory, define the agent with defineAgent from @cursor/agent-sdk, and launch the local playground. Write prompts in Markdown and tools as TypeScript functions, iterate locally and run evals. Then run agent-sdk deploy from the project directory to host it on Cursor infrastructure, managing secrets and integrations from the dashboard, or package the agent in a container yourself. You can start from a template or point a coding agent at the docs; the SDK ships with skills to guide that process. The source states no pricing or usage limits for the Agent SDK or for hosting on Cursor infrastructure.
How solid is it
This is Cursor's own launch post, so every claim is first-party. The only concrete result is that a Cursor team built kb-reviewer in about a day and that it now runs on every PR in their main codebase. The PGA Tour passage is not in quotation marks and no speaker or title is named. No benchmarks or measured results for kb-reviewer or any other agent are given beyond 'built in about a day'.
Risks and caveats
The source offers no comparison with competing agent frameworks. It does not say what the SDK package or CLI costs or whether it is open source, and it lists no supported models beyond the composer-2.5 example in the code snippet. The release is described only as 'generally available today', with no calendar date. Hosted deployment runs on Cursor's infrastructure, so teams with other requirements need the self-hosted container route.