A Steering Wheel for Running Agents: Cursor SDK 1.0.31/1.0.32 Brings Back Background Results and Mid-Flight Steering

In the first week of October, the Cursor SDK filled two key gaps

In the first week of October 2026, the Cursor SDK shipped a set of updates with versions 1.0.31 / 1.0.32. Two entries in the official changelog (cursor.com/docs/sdk/changelog, which I opened and verified myself) deserve to be singled out: background subagent results are no longer dropped, and run.steer() can now "steer" a running agent. Together they tell one story — the agent is changing from a black box you fire and wait on, into a collaborative system you can intervene in mid-flight without losing results.

A sourcing note first: Cursor's official changelog page is a cumulative list with no per-entry date stamps. The "first week of October" anchor for 1.0.31/1.0.32 comes from a secondary changelog tracker and Cursor's official X announcement; every functional description below is verified verbatim against the official changelog, with key sentences quoted in English.

Gap one: background subagent results finally make it home

The pain point first. A common multi-agent pattern with the Cursor SDK: the main agent spawns a background subagent via the Task tool for grunt work (say, researching three options in parallel) and moves on. The problem was the "coming home" step — before 1.0.31, a background subagent's result was dropped when the parent turn ended. Your dispatched scout returned to find the camp disbanded, intelligence uncollected.

The 1.0.31 fix is direct, in the official words: "its result now returns to the parent as a follow-up turn on the same run instead of being dropped when the parent turn ends." The accompanying semantics: run.stream() keeps yielding through those turns, and run.wait() resolves after them. Local agents, in TypeScript and Python.

Figure 1: the new behavior, as a sequence. The main agent spawns a background subagent via Task; the developer calls run.steer() mid-flight and it executes immediately as the next turn; when the background subagent finishes, its result flows back as a follow-up turn on the same run, with run.stream() never breaking.

The weight of this change shows in the fan-out/fan-in orchestration pattern. Dispatch three subagents in parallel, wait for all of them, then synthesize — the most common concurrency pattern in agent apps. Droppable results meant this pattern was broken at the SDK layer, forcing developers to build their own state machines outside to catch the results. Now the SDK has absorbed the catching: the run gains turn-continuity semantics, and a background task's completion is no longer an external event to poll but a turn inside the run. For anyone building support agents, ops agents, or code-review pipelines on the SDK, this is the step from "usable" to "pleasant."

Gap two: a "steering wheel" for running agents

The second update is the more thought-provoking one. The semantic change to run.steer(text) is spelled out precisely in the changelog: "run.steer(text) used to resolve revert_to_followup when the agent had ended its turn to wait on background subagents, so your message waited until that work finished. Now the steer runs right away as the next turn, and background results still arrive afterward." Constraint: TypeScript local runs only.

Figure 2: old vs new. Under the old behavior, a steer issued while waiting on background subagents was deferred until the background work finished; under the new behavior it executes immediately as the next turn, with background results arriving afterward as follow-up turns — "steering" is no longer blocked by "waiting."

The design philosophy here deserves unpacking. Steer was not designed as an "interrupt" — it doesn't kill the running background subagent or discard produced work; it "cuts in line" as the next turn. A restrained intervention semantic: humans gain the power to change direction, not the power to flip the table. Consider the alternatives: hard abort (background work lost), queue-and-wait (the old behavior — humans just wait), silent injection (stuffing instructions into the current turn, possibly derailing the model's train of thought). Cursor chose a fourth option: execute immediately as a standalone next turn, with clean turn boundaries so the model can tell "this is a new human instruction" apart from "this is a background result."

Why does this matter? Because it maps to a real production scenario: human takeover in long tasks. Picture a code-migration agent 20 minutes in, and you realize mid-flight it picked the wrong approach — under the old behavior you either waited it out (20 minutes wasted) or killed and restarted (work lost); under the new behavior, one steer switches it to "plan B," and the background research results still come back afterward. The granularity of human-in-the-loop moves from "task level" to "turn level" — a key step for agents going from demo to production.

The constraints deserve equal candor: steer supports local TypeScript runs only; cloud runs and detached handles are excluded. Python local runs get background result follow-up but not steer. The feature is clearly in its "let some runs steer first" phase; cross-runtime consistency comes next.

Also in the batch: the SDK is "growing up"

Several more changelog entries look minor alone but trace a maturity curve together:

• Custom tools support MCP annotations: annotations passes MCP tool annotations (title, readOnlyHint, destructiveHint, idempotentHint, openWorldHint) through to the model. The official note is deliberate: "They are descriptive hints only; the SDK does not enforce them." — an honest design: annotations are "suggestions" to the model, not a security boundary; real safety still rests on sandboxes and approvals. A sentence every agent-toolchain builder should copy: don't mistake a "hint" for a "guarantee."
• Long-running local agents keep credentials fresh: short-lived access tokens refresh before expiry, so agents running over an hour no longer die on auth failures. The classic "never happens in demos, happens daily in production" problem — its presence in the changelog means enough people run long tasks on the SDK now.
• Output schemas on custom tools: TypeScript's outputSchema / Python's output_schema declares a JSON Schema for a tool's structured result, advertised to the model as the MCP output schema — but results aren't validated against it. The same "describe, don't enforce" philosophy as annotations.
• Usage queries for local agents too: agent.getUsage() / get_usage() now works for local agents with per-turn breakdowns. Cost observability sinking to local runs means the "tune locally, scale in the cloud" workflow is officially supported.
• TS and Python ship version-locked: since 1.0.24, npm's @cursor/sdk and PyPI's cursor-sdk release together sharing version numbers — Python no longer trails. A concrete win for dual-stack teams.

Viewpoint: agent orchestration is shifting from "orchestrating tasks" to "orchestrating collaboration"

Taken together, these two releases answer a question: when agents start working in parallel and tasks start running long, where should the human stand?

The old answer was "outside": humans launch tasks and collect results; the middle is a black box. Black boxes are simple, but the middle is non-intervenable and results can be lost — droppable background results were the price of "standing outside." The new answer is "in the loop": runs gain turn continuity, background results flow back automatically, and humans can steer at any moment with turn-level granularity. This isn't feature accumulation; it's an upgrade of the human-machine collaboration model — from "issuing orders" to "collaborating mid-flight."

The trend isn't Cursor's alone. Look back two months: LiteLLM open-sourced Moyai on cost, Anthropic added agents.md to Claude Code on conventions, Google filled the Java SDK gap for the MCP Toolbox on ecosystem — infrastructure competition for agents has sunk from "model capability" to "engineering experience." What Cursor just fixed are the two most painful pieces of that experience: results don't get lost, intervention is always available. For vibe coders, the bar for building "works 24/7" agent apps (scheduled code review, dependency patrol, support duty) drops another notch: no more hand-rolled state machines to catch background tasks, no more killing an entire run for one course correction.

There's road ahead, of course. Steer is TypeScript-local only for now; conflict resolution across multiple subagents (two background tasks return simultaneously — who goes first?), races between steer and background results (whose turn executes first, the steer's next turn or the follow-up turn?) — the changelog doesn't elaborate, and real usage may surface rough edges. But the direction is right: a good agent SDK should make "human in the loop" the default, not a patch. These two releases are steps in exactly that direction.

Hands-on: what the new semantics look like

Seeing the semantics as pseudocode makes the change tangible:

// Before 1.0.31: background subagent results could "come home to no one"
const run = agent.send("Research options A/B/C in parallel, summarize as a comparison");
// main turn ends; the background Task's result has nowhere to go (dropped)

// After 1.0.31: results flow back automatically as follow-up turns
const run = agent.send("Research options A/B/C in parallel, summarize as a comparison");
for await (const delta of run.stream()) {
  render(delta); // stream stays alive as background results arrive
}
await run.wait(); // resolves only after all follow-up turns complete

// 1.0.32: spot the wrong direction mid-flight? Just steer.
setTimeout(() => {
  run.steer("Skip option C; focus the comparison on A vs B cost");
}, 10 * 60 * 1000); // intervene after 10 min: executes immediately as next turn, no waiting on background

Three snippets, three things: dispatch (Task), collect (follow-up turn), change your mind mid-flight (steer) — a complete long-task orchestration loop that no longer needs a hand-rolled state machine outside.

For comparison: OpenAI's Agents SDK emphasizes "handoff" semantics, LangGraph emphasizes "graphs + state," while the Cursor SDK's bet is "the run is the session" — treating one run as a continuous, memorable, intervenable session rather than a one-shot request-response. The choice matches its product shape: Cursor's core scenario is pair programming in the IDE, where the human sits alongside, ready to chime in. The SDK simply moves that IDE interaction intuition to the API layer.

Three suggestions for readers about to build on the Cursor SDK: first, background Tasks suit "independently verifiable" subtasks (research, search, draft generation), not tasks deeply dependent on the main context — by the time a follow-up turn returns, the main agent's context may have moved on, so write robust synthesis logic. Second, steer is a "steering wheel," not a "brake" — don't expect it to stop an already-runaway background task; real circuit-breaking still belongs in task design (timeouts, budget caps). Third, write MCP annotations where they fit (readOnlyHint, destructiveHint genuinely affect model behavior) — but never treat them as a security boundary. The official docs say it themselves: descriptive hints only.