Your platform is the moat, the coding agent is a plug-in

We already run our own autonomous engineer. You assign a task and a repo; a Claude Agent SDK executor plans, writes the code, runs the tests, reviews its own diff, and opens a pull request. We call it Origin, and it lives entirely on our infrastructure.

Then we wanted Cursor’s cloud agents as well — their isolated cloud VM, the speed of composer, and a model mix (grok, opus, gpt) we don’t host. The obvious question is “which one do we standardize on?” It’s the wrong question. The right answer is: don’t choose the executor — make it swappable.

That reframing is the whole point of this post. After you’ve built the orchestration layer once, adding a second engine — even a hosted, third-party one — is not a rewrite. It’s a thin adapter. Here is the shape of it.

The orchestrator is the platform; the executor is a plug-in

An agent platform is two separable things: the surface + orchestrator (how tasks are assigned, tracked, reviewed, evaluated, budgeted) and the executor (the thing that actually does the work). Teams pour their differentiation into the first and rent the second. So the executor should be the swappable part.

flowchart TD
  subgraph Platform["Your platform — the part you own"]
    S["Surface: chat · task board · issues"]
    O["Orchestrator: state, review, evals, budget, PR flow"]
  end
  O --> REG{"Engine registry"}
  REG -->|self-hosted| C["Claude Agent SDK
(your machines)"]
  REG -->|hosted| CUR["Cursor Cloud Agents
(their VM)"]
  REG -->|local| L["Local model
(Ollama)"]
  C --> PR([Pull request])
  CUR --> PR
  L --> PR

Our platform already had an engine registry — three of them (fast, smart, dsh). Adding Cursor meant adding a fourth value, cursor, and teaching the orchestrator what to do when it sees it. Nothing above the registry changed: same task board, same reviewers, same evals, same pull-request review.

An integration agent is four small pieces

Wrapping a hosted coding agent as a first-class engine took exactly four parts. This is the reusable recipe.

Piece	Job	Ours
Connector	Normalize the vendor API to launch → poll → PR	cursor.py — 90 lines of stdlib
Tool	Expose it to any model as a function	cursor_code(task, repo, model)
Agent	A persona whose job is to use the tool	”Cursor Engineer” — a coding bot
Harness	Register it in the orchestrator’s engine set	engine=cursor on the task board

None of these is big. The connector is the only real code, and it’s small because Cursor’s Cloud Agents API is well-shaped for this:

sequenceDiagram
  participant P as Platform
  participant A as api.cursor.com
  participant G as GitHub
  P->>A: POST /v1/agents {prompt, repo, model, autoCreatePR}
  A->>G: clone repo into an isolated VM
  A-->>P: {id, latestRunId, status}
  loop until terminal
    P->>A: GET /v1/agents/{id}/runs/{runId}
    A-->>P: {status, result, git.branches[].prUrl}
  end
  A->>G: push branch + open PR
  P-->>P: surface the PR url on the run

Launch with a prompt and a repo, poll the run until a prUrl appears, surface it. That’s the entire contract. The connector exposes one blocking helper, run_blocking(...), with an on_event callback so the task board streams the agent’s status transitions live — exactly like our self-hosted engine does.

One surface, chosen per task

Because the engine is just a field on the task, the choice is per-task, not per-platform. The task board’s engineer picker simply lists both:

	Self-hosted (Claude)	Cursor Cloud
Where the code is cloned	your machines	Cursor’s VM
Cost model	your Claude subscription	your Cursor subscription
Control over the loop	full (plan/build/test/review, human gates)	the vendor’s (fast, opinionated, auto-PR)
Model	Claude	composer · grok · opus · gpt
Best for	private code, custom review checklist, gated flow	speed, throwaway tasks, model variety

Same kanban, same assignee/labels/comments, same GitHub-issue sync, same PR review. The team picks the engine like they’d pick a runtime.

Why bother — three concrete wins

• No lock-in. The vendor is an executor, not the platform. If Cursor’s pricing or behavior changes, you flip a field, not migrate a workflow.
• One pane of glass. Hosted and self-hosted runs share a task board, an event stream, an eval harness, and a review flow. You compare engines on your golden sets, not their marketing.
• The integration is cheap. Any hosted agent with a launch-and-poll REST API drops into the same four slots. The expensive part — the orchestrator — you only build once.

That last point is the real lesson. The industry keeps shipping better executors; that’s a gift, not a threat, if your platform treats them as interchangeable. Build the surface and the orchestration you’d want regardless of who’s behind it, register the engines as plug-ins, and let the best one win per task.