Cursor Made Its Agent SDK Generally Available. An Agent Is a Markdown Prompt, TypeScript Tools and One Node Process You Can Put in a Container. Here Is the First One a Solo Dev Should Build.
On October 20, Cursor announced that its Agent SDK is generally available, and the post climbed the Hacker News front page on October 28 under the title "The Agent SDK." Cursor says it uses the same framework to build its own managed agents, including Bugbot, Security Reviewer and Rollouts. The part that matters if you work alone: an agent is a Markdown prompt plus TypeScript functions, and each one runs as a single Node process that can be packaged in a container. That is small enough to hold in your head and cheap enough to self-host.
What the SDK actually is
Per Cursor's post, an agent is organized like a small software project. Instructions, tools, connections to outside services and evals sit together, and each file covers one thing the agent knows or can do. Prompts are written in Markdown. Tools are TypeScript functions. Because it is all code, changes go through the normal version control and review you already use.
The getting-started sample uses defineAgent from @cursor/agent-sdk. It sets a name, a model (the sample uses composer-2.5, with parameters for effort and fast mode) and a local working directory. Agents respond to events, with pull request events from GitHub, GitLab and Bitbucket as the headline example. An agent can assess a change's risk, route it to the right team, or approve it under a policy you set.
Two features separate it from a pile of scripts. Evals and event replay come built in, and the same logs, evals and playground work locally and after deployment. And agents can hand work to other agents with their own tools and sessions, or split a job across subagents running in parallel.
Two ways to run it
You can deploy with agent-sdk deploy from the project directory. The command builds the agent, assigns it a URL and runs it on Cursor's infrastructure, with secrets and integrations managed from a dashboard. Or you can take the single Node process, put it in a container, and run it wherever you run everything else. Cursor describes the runtime as "a single Node process that can be packaged in a container."
For a solo operator the second path is the interesting one. It means your review agent does not have to live on a vendor's servers. It also means you can see what it costs you in a way a hosted per-seat plan never shows.
What the announcement does not say
The post gives no pricing, limits, quotas or list of unsupported features, and it does not say which languages beyond Markdown and TypeScript work. It says the SDK is "generally available today" and sends you to the docs. Everything I describe above comes from that one post, so I would read the docs and run the sample before putting this near anything that touches production.
I would also note who the examples come from. A Cursor team built an agent called kb-reviewer in about a day, which checks every pull request against a knowledge base of recorded lessons and cites the note a change contradicts. PGA Tour uses the SDK for its software development factory and cites evals as a key benefit. Those are stories from the vendor and a customer it chose to mention, not independent results.
The first agent worth building
The kb-reviewer idea transfers directly to a one-person shop. You do not have a reviewer, and you also have a list of mistakes you have already made: the migration you ran without a backup, the environment variable you forgot to set in production, the endpoint you left open. Most of us carry that list in our heads, and that is exactly the part that fails when we are tired.
So the first agent I would build has one job. On every pull request, it reads a Markdown file of lessons I wrote, compares the diff against it, and comments only when a change contradicts a lesson, citing the line. It never approves, merges or edits. It has two or three tools: read the diff, read the lessons file, post a comment. That is small enough to finish in an evening, and the evals feature gives me a way to check it with past pull requests where I know what went wrong.
Where I could be wrong
Maybe this is the wrong layer to adopt. A GitHub Action that calls a model API directly does the same job without a framework, and a simple script is easier to understand than any SDK. Adopting a new framework a week after a general release also carries the usual risk of changes to the interface. And with no pricing in the post, I do not know what a hosted run costs. If the answer is "more than a plain API call," the self-host path is the only one that makes sense for me.
My view is that the framework earns its place if the built-in evals and replay hold up, because those are the parts that are annoying to build yourself and that make an agent trustworthy after the third week.
What I'd actually do
I would write the lessons file first, because it is useful with or without any agent. Then I would build the comment-only reviewer as a container, run it on one low-risk repo for two weeks, and keep a count of comments that were right, wrong or noise. If fewer than half are useful, I delete it and I have lost an evening. If most are useful, I add the next lesson. I would not hand it approval rights until I have a month of that count.
Author
Lukas
@lukcombinator