Cursor Agent SDK vs Grok Bot and Automations

Cursor has released the Agent SDK, the framework it says it uses to build its own managed agents, including the code reviewer Bugbot. Teams write an agent’s prompts in Markdown and its tools as TypeScript functions, test it with built-in evals, and then run it on Cursor’s hosting or on their own servers.

The launch post by Rustam Lalkaka, dated 20 October, describes it as generally available. Cursor repeated the pitch on X on 26 October: “Define agents as code, with prompts in Markdown and tools in TypeScript. Deploy them on our hosted infrastructure, or run them on your own.” What makes the release worth a closer look is where Cursor places it. Its own documentation sets the SDK beside two other ways to get an agent working, Cursor Automations and Grok Bot, and says when each one fits.

In brief

The Agent SDK defines an agent as a small software project: Markdown instructions, TypeScript tools, connections and evals, kept in version control.
Agents wake on pull requests, Slack messages, webhooks or schedules, and can deploy to Cursor with one command or run as a single Node process on a team’s own infrastructure.
Cursor’s docs pitch it at teams that want code around model judgment; Automations and Grok Bot cover jobs that need no code.

An agent becomes a folder that goes through code review

According to the blog, an Agent SDK agent “is organized like a small software project”. The instructions sit alongside code for its tools, its connections to outside services and the evals used to test it. Cursor’s changelog entry spells out the layout: instructions.md holds the prompt, each file in tools/ is one typed action the model can call, skills/ holds procedures loaded on demand, mcp-connections/ adds tools from MCP servers, and channels/ sets where the agent receives and answers messages.

Because all of that is code, the blog says, “changes can go through the same version control and review process as the rest of your software.” The Agent SDK documentation puts the split plainly: “You write the instructions and tools, and Cursor runs the model loop that calls them.” It says the SDK uses the same harness behind Bugbot, Security Review, Approval Bot and Rollouts.

Agents start from events. The changelog lists pull request, comment and CI events from GitHub, GitLab and Bitbucket; mentions and direct messages in Slack; webhooks from any provider; and cron schedules. Each conversation keeps its own session, so a follow-up on the same pull request or Slack thread picks up where it left off. Ready-made templates cover a security reviewer, an owners-policy approver, a pull request autofixer and a Linear or Jira triager. For bigger jobs, the blog says an agent can hand a task to another specialised agent with its own tools, or split work among subagents running in parallel, a pattern TSN described in its explainer on agent swarms.

Cursor’s main example is internal. A team with a large knowledge base of lessons learned “built kb-reviewer in about a day”, the blog says. It now runs on every pull request in their main codebase, flags changes that contradict a recorded lesson and cites the note behind each finding. The blog also says the PGA Tour uses the SDK to “power their software development factory”, and quotes Michael Gyarmathy, listed as principal engineer at PGA America, saying “built-in support for evals allows us to quickly iterate on new ideas and optimize existing capabilities reliably.”

Evals check which tools an agent chose to run

The evals documentation defines an eval simply: it “sends a fixed input to the real agent and checks which tools ran and what the answer looks like.” Its sample case passes only if a reviewer agent inspects a pull request and does not approve it. Other checks test a reply against a fixed structure, or use a model as judge where correctness depends on meaning.

Evals run locally or in CI, with JUnit XML output for build systems. The docs suggest a quick “smoke” set on every pull request and the full suite on a schedule. A replay command turns a real GitHub pull request into signed webhook payloads that can be saved as test fixtures.

The documentation carries one clear warning: “Evals run real tools, so guard any writes first.” Eval sessions are marked with purpose: "eval", and the docs show a tool checking that flag and returning its decision without taking the external action, so a test can confirm the agent chose to post a comment without anything being posted.

Deploying to Cursor or to your own servers

The deployment guide says agent-sdk deploy builds the pushed Git ref, “so uncommitted changes don’t ship”, waits until the agent is running and prints its URL. Secrets are set per deployment and read at run time. Each agent must declare the outside hosts it calls, and a team’s egress policy can block a host and fail the deploy. Managed hosting is not available to teams on Cursor’s legacy Privacy Mode setting; there, deploys, hosted sessions and eval runs all refuse.

Self-hosting runs the agent as a single Node process, under Node 22.13 or newer. The docs tell operators to put TLS or an authenticating proxy in front of the server, keep its state on a backed-up volume and enable schedules in only one process per project. The documentation installs the tool from an npm package named @grok/agent-sdk, which it says was @cursor/bdk before; the launch blog’s code sample imports @cursor/agent-sdk.

How it compares with Grok Bot and Cursor Automations

Cursor’s documentation includes its own comparison. TSN has condensed it below.

Option	What you define	Where it runs
Cursor Automations	A prompt, model and trigger in the dashboard	Cursor-managed
Grok Bot	Instructions, skills and connected tools in the app	Cursor-managed
Agent SDK	A versioned Markdown and TypeScript project	Cursor hosting or your own infrastructure

Automations, Grok Bot and the Agent SDK compared, condensed from Cursor’s documentation

Source: Cursor Agent SDK documentation, accessed 27 October 2026.

The docs say Automations suit a job that “fits a schedule or event trigger”, and Grok Bot suits people who “want to configure and talk to an agent without writing code”. The Agent SDK is for teams that want “code around model judgment” that they can “version control, review, test and hillclimb”. TSN’s Grok Bot types guide covers the no-code route in detail. The docs also link to a guide for converting an existing Automation into an Agent SDK project.

Version control turns agent behaviour into something reviewers can audit

The most useful idea here is not the deploy command but the review trail. When an agent’s instructions live in a dashboard, a changed prompt can alter what the agent approves or flags, and the reason for the change can be hard to trace later. Putting prompts and tools in a repository means every change has an author, a diff and a reviewer, the same controls firms already apply to code. For regulated teams in finance or compliance, that is closer to the change management auditors expect than editing a text box.

It is still only part of the answer. An eval suite proves an agent behaved on the cases someone thought to write, not on the pull request nobody anticipated, and the docs’ own warning about real tools shows how easily a test can have side effects. Cursor’s evals sit alongside a wider push to test agents before trusting them: Salesforce has announced Agent Evals for its Agent Fabric, and Microsoft has open-sourced Scope for evaluating coding agents. The difference is placement. Cursor puts the tests in the same folder as the agent, so a prompt change and the test that guards it can land in a single review.

The comparison table is also candid about the trade-off. Grok Bot and Automations ask for no code, while the SDK asks a team to own a software project, with its secrets, egress rules and, if self-hosted, its servers. That fits engineering groups that already run CI. For a small team that wants a daily report, the no-code options look like the shorter path.

What to watch

The launch came three days before Cursor said its agents can now drive desktop apps, and both point the same way: agents that do more of a team’s routine engineering work, under rules the team writes down. The open questions are practical ones. Cursor has named its own agents and one customer, but not how many outside teams run agents on the SDK, and its launch post refers to both the PGA Tour and PGA of America without saying which organisation runs the software factory it describes.