Source: cursor.com/blog/agent-sdk
The Agent SDK is now generally available. Developers define agents in code and manage them like other software projects, starting from a template or having a coding agent work from the docs. Agents can respond to pull request events on GitHub, GitLab or Bitbucket, assess the risk of a change, route it to the right team and approve changes that meet a team's policy.
Cursor says one of its internal teams used the SDK to build kb-reviewer in about a day. The agent runs on every pull request in the main codebase, flags changes that contradict a recorded lesson and cites the note behind each finding. The SDK also supports evals and event replay, and agents can hand tasks to specialized agents or split work among parallel subagents.
An agent is structured like a small project, with prompts written in Markdown, tools defined as TypeScript functions and evals for testing. Running agent-sdk deploy builds the agent, gives it a URL and starts it on Cursor's infrastructure, while secrets and integrations can be managed from the dashboard. Agents can also run on a team's own infrastructure as a single Node process packaged in a container.
Why it matters if you build agents
Developers building agents can now keep triggers, policies and tests in version-controlled code instead of adapting a product built around another company's workflow. Teams that need to avoid hosted deployment can package each agent as a container and run it themselves. Before relying on the SDK in production, check how it handles your event sources and whether Cursor's hosted deployment fits your secrets and data requirements.
Get stories like this every weekday
One short email with the day's agent tooling news.