Cursor adds mid-run steering for agent teams with Grok Bots

Watching a long agent run go wrong is a specific kind of helplessness. You can see it at minute three — it has misread the task, picked the wrong module, and is now about to spend nine minutes being confidently thorough in the wrong place. Until recently your options were both bad. Wait it out, and the wrong direction compounds: more files touched, more context poisoned, more to unpick. Kill it, and you throw away the run's state along with the twenty minutes of correct work it did before the turn where it went off.

On 5 October 2026, Cursor's SDK 1.0.31 shipped a third option: run.steer(), which injects a new instruction into the turn that is already running, without cancelling it or discarding its state. It is a two-line API. It moves the unit of control from the run to the turn, which is a bigger deal than it sounds — and it lands on the same platform that now puts a shared Grok Team Bot in a Slack channel, where a whole team can reach for the same wheel.

That combination is what makes this interesting, and slightly alarming. The question stops being can I interrupt this? and becomes who is allowed to steer, and what happens to the half-finished work when two people do it at once?

What actually shipped

Three pieces landed over about eight weeks, and they are easier to reason about apart than together:

• Steering in the product (19 August 2026). A message sent to a working Cloud Agent no longer cuts it off. Follow-ups wait for the next tool call instead of interrupting mid-action. In the editor, pressing Enter once sends your queued message into the active run to steer it; press Enter again and you interrupt the turn.
• Steering in the SDK (5 October 2026). run.steer(text) on SDK 1.0.31, returning a SteerAckOutcome of either "complete_delivered" or "revert_to_followup". Local runs only — cloud runs expose the method but always resolve to revert_to_followup.
• Subagent demotion. Steer while a foreground subagent is running and that subagent moves to the background, so the parent can take your new instruction without waiting for a long subtask to finish.

The tool-call boundary is the quiet engineering decision here, and it is the right one. A tool call is the only moment in a turn where the agent's state is coherent: it has finished reasoning and has not yet acted. Deliver a message there and it costs nothing. Deliver it mid-action and you get the thing everyone has seen — a half-written file, a branch left dangling, an edit applied to two of three call sites.

The two outcomes are the entire feature

Most people will read steer() as a command. It is not. It is a request the running turn may decline, because by the time your message arrives the turn may be past the point where it can usefully act on it. Cursor's API is honest about that in the only way that matters: it refuses to pretend, and hands you back an acknowledgement with two possible answers.

const run = await agent.send("Migrate auth module to new session API");

// steer() is optional on Run — check for it rather than assuming it exists.
const outcome = await run.steer?.("Skip the admin routes for now");

if (outcome !== "complete_delivered") {
  // The turn did not take it. Deliver it the old way, after the run.
  await run.wait();
  await agent.send("Skip the admin routes for now");
}

That if is the feature. Branch on the outcome instead of assuming delivery and the same code path also covers the case where steering is unsupported entirely — which is exactly what a cloud run is, since it always answers revert_to_followup. Skip the branch and you have written a system that silently drops user instructions on every deployment target except your laptop.

Then a Team Bot takes the wheel

Grok Bot is the other half of the headline: a computer-use agent that drives applications, browsers and development environments, running in Cursor's cloud on a dedicated per-user machine. It went into early beta on 11 August 2026 and broadened across the paid Cursor and SuperGrok tiers on 26 August. The part that matters for orchestration is that a Bot can delegate coding tasks to Cloud Agents, under whatever Cloud Agent controls you already have — and that an admin can turn that spawning off with one team-wide toggle.

Team Bots are the multiplayer version, and the sharing model is drawn more carefully than I expected. One owner configures the plugins, secrets, skills and files once; the whole team then talks to that one Bot. Each teammate still gets their own private chat, which the owner cannot read. Team memory is shared; per-person notes are not. A plugin that needs a sign-in uses the account of whoever is talking to the Bot, so credentials do not leak sideways. Shared conversations — Slack channels, group DMs, threads — execute on a shared Team Bot computer, separate from anyone's personal one, and in a shared thread the Bot asks before it reaches for one of your connectors. Usage bills to the teammate who talked, not to the owner.

Stack that on top of Cursor Projects, where a coordinator agent plans work and delegates it to implementing agents rather than writing code itself, and the journey a single steer has to make gets long. Someone types one sentence in Slack. Five layers down, machines are already running.

The number everyone will quote

pull requests per dayreported, from a five-person team

100+

of Cloud Agents coordinatedthrough one Team Bot

100s

possible steer outcomesand you must handle both

2

admin toggle disables agent spawningteam-wide

1

The case study doing the rounds: a five-person team used a Team Bot to drive a Cursor Project coordinating hundreds of Cloud Agents, with the Bot filing tickets, dispatching coding agents and reporting blockers into Slack. More than a hundred pull requests a day, and a launch finished in weeks.

I believe the throughput and I do not know what it bought. There is no reported figure for review time, revert rate, or how many of those PRs were accepted into production — and PRs per day is a throughput metric for a system whose bottleneck is human review. Five people cannot review a hundred pull requests a day and also do anything else. So either the agents were reviewing each other, or the number measures how fast work arrived at a queue rather than how fast it cleared one.

Which, incidentally, is the strongest argument for steering. The win is not more pull requests. It is fewer wasted ones — correcting a run at minute three instead of reviewing and reverting it at minute forty.

How I would actually use it

1. 1Treat steer() as advisory and always write the fallback. Cursor's own example does. One unhandled revert_to_followup is a user correction your product swallowed in silence.
2. 2Phrase steers as forward constraints, not corrections. "Skip the admin routes for now" survives arriving four seconds late. "Undo what you just did" does not, because by then what you just did means something else.
3. 3Show the queued state. A steer accepted at the next tool call is invisible for seconds. With no feedback, people press Enter again — and the second Enter interrupts. Your UI is the difference between steering and killing.
4. 4Decide who may steer before you put a Bot in a channel. In a shared Slack thread, everyone with channel access has a steering wheel, and the Bot answers them all.
5. 5Log every steer with its author. With shared skills and private chats, an audit trail is the only way anyone will later reconstruct why a run changed direction at 14:52.
6. 6Cap the fan-out you cannot steer. Dispatch is the point of no return. If the coordinator can hand out two hundred tasks before you next look at it, put the gate there rather than hoping to catch it downstream.

The actual shift

A run you can redirect while it moves is worth more than a run that finishes faster.

Mid-run steering is a quiet admission that long autonomous runs do not reliably converge on their own, and that the fix is not better planning up front. We tried that. It produced enormous prompts and agents that confidently executed stale plans. The fix is a control surface you can reach while the thing is moving, and a protocol honest enough to tell you when you reached for it too late.

What Cursor and xAI have shipped between them is that surface, plus a shared seat in front of it. The engineering problem has moved accordingly. It is no longer how do I stop this agent. It is who holds the wheel, what the other hands are doing, and how much of the convoy has already driven out of earshot.