Cursor’s Agent SDK Turns AI Agents Into Code You Can Test

Cursor just made its Agent SDK generally available, and it changes how I think about shipping agents to clients. You define an agent as a folder of files: the prompt in Markdown, each tool as a TypeScript function, and tests that run before anything goes live.

Cursor announced it on X on October 26. If you build agents for a living, or want to, this matters because the hardest part of agent work was never the prompt. It is keeping the agent reliable after the first demo.

I build AI agents and automations for businesses. Here is what the SDK actually is, what I like, what I would watch, and what I plan to do with it.

What Cursor actually shipped

The Agent SDK lets you "define agents as code," in Cursor's words. An agent lives in a project folder that you review, test and version in Git like any other code.

According to Cursor's changelog, a project looks roughly like this:

instructions.md: the agent's main prompt.
tools/: one typed action per file that the model can call.
skills/: procedures the model loads only when it needs them.
mcp-connections/: tools pulled in from MCP servers.
channels/: where the agent receives messages and replies.

Cursor says this is the same harness behind its own internal agents, including Bugbot and its security reviewer. So this is not a side project. It is the tooling they use themselves.

Triggers, sessions and two ways to deploy

An agent can wake up from pull request, comment and CI events on GitHub, GitLab and Bitbucket. It can also respond to Slack mentions and DMs, webhooks from any provider, or a cron schedule.

Each conversation gets its own session with a full record of messages and tool calls. If someone follows up on the same pull request or Slack thread, the agent picks up the same session instead of starting cold.

Deployment has two paths. Run agent-sdk deploy and Cursor builds the agent, gives it a URL and hosts it, with secrets and integrations managed in a dashboard. Or run it yourself: Cursor says each agent is a single Node process you can package in a container and put on your own infrastructure.

The part I care about most: evals

Most agent projects I see fail quietly. Someone tweaks a prompt, the agent starts calling the wrong tool, and nobody notices until a client complains.

The SDK builds testing into the workflow. An eval sends a fixed message and checks which tools ran, what inputs they got, and the shape of the reply. Evals run locally or in CI, so a bad change can be caught before it ships.

There is also a neat trick for GitHub bots: agent-sdk github replay turns a real pull request into webhook payloads. You can test against real-world input without pushing anything, and save those payloads as fixtures for future evals.

This is the habit I push on every client team. If you cannot test an agent the way you test code, you cannot safely change it.

What I would watch before betting a client on it

Pricing is not fully clear yet. Coverage describes token-based consumption pricing, but I could not find a separate published price for the SDK or for hosted agents. Run a small pilot and measure cost per task before you promise anyone a budget.

It is TypeScript-first. The project layout and CLI assume Node.js (version 22.13 or newer per the docs). AlphaSignal notes there is no native Python project structure, which matters if your team lives in Python.

Lock-in is a real question. Self-hosting helps, but you still run Cursor's harness and need a Cursor login to run model turns and evals. That is a fair trade for many teams, but make it a conscious choice.

Governance comes first. Mitch Ashley of The Futurum Group, writing about Cursor's SDK work, put it simply: "Enterprise buyers now evaluate Cursor as infrastructure." Treat it that way. Decide who can deploy, where secrets live, and what an agent may do unattended before it opens its first pull request.

How I plan to use it

Cursor ships templates for a security reviewer, an owners-policy approver, a pull request autofixer, and a Linear or Jira triager. These map almost one-to-one onto requests I get from engineering clients.

The example that stuck with me is from Cursor's own launch post. A team built a "kb-reviewer" in about a day that checks every pull request against a knowledge base of past lessons and cites the relevant note when a change contradicts one. Every company has tribal knowledge like that. Turning it into an agent that enforces it is a very sellable service.

My first experiment will be a Slack-triggered triage agent for a client's support backlog: a small set of tools, ten to fifteen evals built from real past tickets, and self-hosted in their own container so their data stays inside their network.

Practical takeaways

Learn the "agents as code" pattern now. Prompts in files, tools as typed functions, evals in CI. This is where serious agent work is heading, whatever framework you pick.
Start with one boring, high-volume workflow. PR review, ticket triage or a scheduled quality check. Not a do-everything assistant.
Write evals before you tune prompts. Use real inputs. Replay real events where you can.
Decide hosting up front. Hosted is faster to start. Self-hosted is easier to sell to clients with strict data rules.
Measure cost per task in the pilot. Do not quote a fixed price for agent work until you have real numbers.

Freelancers and agencies, this is an opportunity. Clients do not want "an AI agent." They want a reliable worker with tests, logs and a rollback button. Tools like this make that easier to deliver.

Are you building agents with Cursor's SDK, or sticking with another framework? Tell me in the comments, and follow me for more practical notes from building AI agents for real businesses.