Cursor Cloud Agents

A Cursor Cloud Agent is a way of working a story that does not run on Openbook's own engine at all. You launch it from the story, it runs at Cursor on your Cursor account, and Openbook keeps the story up to date with what Cursor reports — its status, the tokens it used, and the pull request it opened.

Rolling out. This is a pilot behind two server settings, FEATURE_CURSOR_AGENTS and FEATURE_CURSOR_AUTO_PR, both off by default and off in production unless an operator turns them on. With them off, the launch dialog offers only the built-in agent and the Cursor option is not available.

Where it starts

Open a story on a Kanban board. Its Agent runs section has a Launch agent button, which opens Launch an agent — "Choose how this story is worked on." Under Run with there are two engines:

Engine	What the dialog says
Built-in agent	One conversation with this room's model and tools. Paid by Organization AI. Runs in this room; nothing is sent to Cursor. This is the build agent.
Runs in Cursor	Runs on your own Cursor connection. The story is worked at Cursor, on your account.

Status and the pull request link then appear on the story, under Cursor Cloud Agent runs.

Your own Cursor key, nobody else's

Cursor connections are personal. Each person launches on their own subscription, and Openbook never picks a teammate's key for you. The dialog says so, and it is the whole funding rule:

• You connect Cursor once, on My API keys (/settings/ai), with Connect Cursor. The key is held at Bookbag SSO with your other personal keys, and one Cursor key per person is the limit.
• If you have not connected one, the dialog reads "Runs on your own Cursor connection. You have not connected one." and refuses to launch. It never falls back to Organization AI or to the built-in agent.
• Only the key's owner can launch a run or send it follow-ups.
• An organization owner can switch off Members may run agents on their own keys in Organization AI settings; with it off, Cursor launches are refused too. A paused or blocked account is refused before anything is sent.

What you agree to, frozen

Launching is a preview, then consent. Choose a Repository (the list comes from your Cursor GitHub connection — "No repositories from Cursor" means Cursor has none to offer), an optional Starting branch (the repository's default branch when blank), and whether to tick Create PR. The dialog then shows Preview, frozen at consent: the repository, the starting branch, the model, whether a pull request will be created, and a fingerprint of the exact prompt the story produces.

If any of these change after you consent, the launch is refused and you are asked again.

That is deliberate. The launch recomputes the prompt from the story as it is at that moment and refuses a difference, and Cursor refuses a key that has changed since the preview. Nothing runs on a stale approval.

Create PR is the part behind the second setting, FEATURE_CURSOR_AUTO_PR. When it is on and ticked, "Cursor opens a pull request as you, through your Cursor GitHub connection." When it is off, the run still pushes to its branch and you open the pull request yourself. Either way, merge stays with a human.

Watching the run

Cursor's API has no webhooks, so Openbook reads the run back: a server-side poller checks each live run for its status, its pull request link and the tokens Cursor reports. The story's run card shows who launched it, when, on which repository, and one of these states:

State	Meaning
Launching	Openbook asked; Cursor has not confirmed yet.
Creating / Running	Cursor is working.
Follow-up pending	You sent a follow-up while Cursor was busy; it goes when the agent is idle.
Finished / Error / Archived	Cursor's own terminal states.
Cancelled	Cancelled through Cursor from Openbook.
Disconnected	Your Cursor key is gone, so Openbook has nothing to ask Cursor with. The run itself is not cancelled.
Failed	Cursor never confirmed the launch, or lost the agent.

Tokens show as "Cursor reports N tokens for this agent" once Cursor has reported any.

Follow-ups

Send follow-up on a run — "What should the agent do next?" — sends your instruction to the same agent. Only the launcher can. If Cursor is busy the follow-up is queued, one per agent, and sent when the agent is idle; it is never turned into a second agent. A disconnected run can still take a follow-up if you have connected the same Cursor account again.

Cancelling

Cancel run stops the run at Cursor. The launcher can cancel their own run, and a room operator can cancel anyone's — "Cursor stops the run <name> launched, on their Cursor. Work it already pushed stays on its branch." A cancel always runs on the launcher's key, never the operator's.

If you disconnect your key while a run is in flight, the run finishes at Cursor; Openbook marks it disconnected rather than cancelling it.

What a Cursor agent is not

A Cursor agent is a personal agent whose published version names Cursor as its engine (chosen under My keys in the agent editor). It is launched from a story and nowhere else: a Cursor agent reached from a chat channel or a card mention is refused with a sentence pointing you at its card. Shared or organization-funded Cursor agents are out of scope for the pilot.

For the engines that do run on Openbook, see The build agent; for personal keys and who may use a personal agent, see Reusable & personal agents.