MyTechDailyNews Software Guide: Cursor Agent SDK for Team-Defined, Deployable Agents

By Sarah Chen

Today, Cursor opened the Agent SDK to teams as a code-first framework behind managed agents such as Bugbot, Security Reviewer, and Rollouts. The shift matters for software users because the agent is no longer only a prebuilt helper: a team can describe its own recurring engineering habits in code, test them, and then move the finished agent to Cursor infrastructure with agent-sdk deploy in one command, or run it on self-managed hardware as a single Node process.

What teams get from the new Agent SDK release

For an IT support group, an efficiency-tool team, or an enterprise software selection panel, the useful parts of this release are the concrete control points: event triggers, repository connectors, inspectable policy, local testing, and a short deploy path.

• Code-defined agents: prompts are written in Markdown, tools are defined as TypeScript functions, and connections to outside services sit beside the guiding instructions.
• Event-driven review: an agent can react to pull-request activity from GitHub, GitLab, or Bitbucket, judge the risk of a change, route it to the right team, and approve changes that meet policy.
• Governance-friendly policy: because instructions and checks are code, policy behavior can be inspected and changed through the same version-control and review process used for other software.
• Safer iteration: the Agent SDK includes evals and event replay out of the box, so teams can rehearse pull-request review, compliance workflows, and incident investigation before production use.
• Two runtime paths: deploy to Cursor infrastructure with one command, or package each agent as a single Node process for your own infrastructure.

Editor’s checklist before adopting a team-built agent

Before an agent touches production repositories, treat it like any other internal tool project. The checklist below keeps the decision tied to software-delivery outcomes rather than vendor framing.

1. Pick one repeated task with clear input and output: pull-request review, compliance checks, or incident triage.
2. Write the policy in reviewable text, including what the agent may read, what it may approve, and what must be escalated.
3. Map the source-control connector to GitHub, GitLab, or Bitbucket only after confirming repository scope.
4. Store prompts as Markdown and tools as TypeScript so changes can be tested, reviewed, and reverted.
5. Run evals against known events and replay failures or edge cases before deployment.
6. Choose the runtime: Cursor infrastructure with agent-sdk deploy, or a single Node process inside your own environment.
7. Document the agent’s outputs for auditors, especially when it cites a recorded lesson or routes work to a team.

Concrete workflow example: kb-reviewer

The launch material gives a compact proof point for teams with accumulated internal knowledge. A fast-growing knowledge base of lessons learned needed every pull request checked against past decisions, so that earlier choices would remain visible as the codebase changed. The team built kb-reviewer in about a day.

Cited workflow data: kb-reviewer now runs on every pull request in the team’s main codebase, flags changes that contradict a recorded lesson, cites the note behind each finding, and encourages engineers to reconcile the reported discrepancies.

Complex jobs: handoffs, parallel agents, and evals

For work that exceeds one narrow review task, the SDK supports handoff to another specialized agent with its own tools and sessions, or division of a job among subagents working in parallel. PGA Tour uses the Agent SDK to power its software development factory, and evals keep that team moving quickly.

Customer quote from PGA

The Agent SDK has enabled PGA to build every component of our software factory on Cursor's infrastructure. It provides the flexibility we need to build agents that drive our development process. And built-in support for evals allows us to quickly iterate on new ideas and optimize existing capabilities reliably.

Michael Gyarmathy, Principal Engineer, PGA America

Comparison: hosted Cursor deployment vs self-managed Node process

Deployment model	Start	Management surface	Good for
Cursor infrastructure	Run agent-sdk deploy from the project directory; the command builds the agent, gives it a URL, and starts it in one command.	Dashboard can manage secrets and integrations; the same logs, evals, and playground remain available locally.	Teams that want a hosted runtime with minimal server setup.
Self-managed infrastructure	Run each agent as a single Node process, then package it in a container if needed.	Team controls host, network, and release cadence through its own pipeline.	Teams that must keep execution on their own infrastructure.

Step-by-step tutorial: create, test, and deploy a starter agent

Getting started resembles setting up any small software project. The Agent SDK also ships with skills that guide coding agents through the development process, so an agent can point at the docs and help build the bot.

1. Create a project directory.
2. Launch the local playground.
3. Start a simple agent: import homedir from node:os and join from node:path, then use defineAgent from @cursor/agent-sdk.
4. Set basic parameters: name it Robo, select composer-2.5 as the model, set effort to high, enable fast true, and use a homedir-based local cwd such as .cache/factory/robo.
5. Add the prompt and tools: keep guiding instructions in Markdown and expose actions as TypeScript functions.
6. Connect the agent to GitHub, GitLab, or Bitbucket only after the repository trigger and allowed actions are clear.
7. Run evals and replay representative events to confirm the workflow behaves as expected.
8. When ready, deploy with agent-sdk deploy, or move the project to a self-managed runtime where it can run as a single Node process.

Permissions, privacy, and governance notes

Because the Agent SDK is useful at the point where code review and policy intersect, its permission surface deserves the same scrutiny as the runtime choice. The project is intentionally small enough to inspect: instructions, tools, connections, and evals live in code, so a reviewer can read the behavior rather than treat the agent as an opaque service. The deployment note also states that secrets and integrations can be managed from the dashboard, which means teams should define who can change connections, rotate secrets, and approve the final deploy.

No new privacy claims are needed to make the point: any agent connected to GitHub, GitLab, or Bitbucket should be scoped to the repositories, branches, or compliance checks it actually needs.

Compatibility and efficiency considerations

The SDK’s compatibility story is practical: prompts in Markdown, tools in TypeScript, Node runtime, container packaging, and local logs, evals, and playground. For teams measuring efficiency gains, the strongest evidence is the local iteration path. A policy-heavy agent does not need to be guessed at in production; it can be tested against recorded events, refined through evals, and then deployed with one command.

Common misconceptions

• Myth: It only helps with Cursor’s own managed agents. Reality: the Agent SDK is the framework used to build managed agents such as Bugbot, Security Reviewer, and Rollouts, but it is also intended for team-defined agents.
• Myth: A self-built agent must be a large platform project. Reality: it is organized like a small software project with prompts, tools, connections, and evals.
• Myth: Deployment requires giving up local visibility. Reality: after Cursor infrastructure deployment, logs, evals, and playground remain available locally.
• Myth: Every agent must run on vendor-hosted infrastructure. Reality: each agent can run on your own infrastructure as a single Node process.

FAQ

Who should evaluate this update first?

Teams with stable pull-request flow, compliance checks, or incident-review habits. It is most useful when the workflow can be written down and tested.

Which repository platforms are supported?

The release material mentions GitHub, GitLab, and Bitbucket.

Can the agent be tested before production?

Yes. Built-in evals and event replay support safe iteration for pull-request review, compliance workflows, and incident investigation.

Is there one local starter example?

Yes. A starter agent can be named Robo, use composer-2.5, set effort high and fast true, import homedir from node:os and join from node:path, and call defineAgent from @cursor/agent-sdk.

Do teams have to deploy to Cursor?

No. They can use agent-sdk deploy for Cursor infrastructure, or run each agent as a single Node process on their own infrastructure.

Action recommendation

For a software team starting from scratch, the best first step is not a broad automation rollout. Begin with one narrow, reviewable use case: a pull-request checker, a compliance gate, or an incident-summary agent. Encode the rule in Markdown, expose only needed actions in TypeScript, connect it to GitHub, GitLab, or Bitbucket, and prove its behavior with evals and replay before using agent-sdk deploy in one command.

If the team’s policy is too vague to test, the agent will inherit that ambiguity. If the team can already write a checklist, the Agent SDK gives that checklist a software delivery path.

Bottom line for MyTechDailyNews readers

The Agent SDK matters because it turns team policy into a deployable software artifact: agents can be defined in code, connected to familiar repository events, reviewed for risk, tested before release, and run either on Cursor infrastructure or as a single Node process on your own systems.