Cursor 3.2 /multitask Changes Coding Agents

Cursor used to feel like an AI-native editor. Cursor 3.2 /multitask makes it feel more like an agent operations console.

That sounds subtle. It is not. The moment coding agents can run multiple async subagents, the product category changes from "AI helps me edit files" to "AI executes software work while I supervise."

Key Takeaways

• Cursor 3.2 /multitask matters because it reframes Cursor as an agent execution surface, not just an editor.
• Async subagents are powerful only when tasks are independent, state is tracked, and merge rules are explicit.
• Research on asynchronous tool use shows that delayed feedback causes real degradation unless agents handle dependencies carefully [2].
• Reusable subagents are becoming the new unit of coding automation, similar to executable skills in AgentFactory [3].
• The best prompts for /multitask look more like orchestration briefs than normal coding requests.

---

What did Cursor 3.2 /multitask really change?

Cursor 3.2 /multitask changes the user mental model from "ask one agent to edit code" to "coordinate multiple specialized workers." The important shift is not parallel execution by itself. It is that the editor becomes a place where agent runs can be started, watched, resumed, reviewed, and merged.

Cursor has been moving in this direction for a while. Reporting on the Cursor TypeScript SDK describes programmatic agents that use the same runtime behind Cursor's desktop app, CLI, and web interface, with cloud execution, hooks, skills, and subagents [4]. That is not just an IDE feature. That is infrastructure.

OpenAI's own Agents SDK direction points the same way: long-running agents need sandbox execution and a model-native harness, not just a chat box wrapped around function calls [1]. Once you accept that, Cursor's editor UI becomes only one entry point into a broader execution layer.

Here's the simplest way to see the category shift.

Old Cursor mental model	Cursor 3.2 /multitask mental model
One agent helps with one coding task	Multiple agents pursue scoped subtasks
User waits for a run to finish	User supervises async progress
Prompt is a request	Prompt is an execution brief
Editor is the workspace	Agent runs are the workspace
Review happens after edits	Review happens across branches, diffs, and subtasks

Here's what I noticed: the winners in this workflow are not the people who write longer prompts. They are the people who write better delegation specs.

---

Why do async subagents matter for coding work?

Async subagents matter because software work is naturally decomposable. One agent can inspect failing tests, another can trace API behavior, another can draft a migration, and another can check docs. But async only helps when the subtasks are genuinely separable and the parent task has clear integration rules.

The AsyncTool paper is useful here because it studies what happens when agents must handle multiple tasks with delayed tool feedback. The authors found that asynchronous execution creates performance degradation when models continue dependent work before results arrive, confuse tools across tasks, or neglect earlier tasks [2].

That maps directly to coding agents. If one subagent is refactoring auth middleware while another updates tests against the old interface, you do not have productivity. You have a merge conflict with a language model attached.

The AgentFactory paper offers the more optimistic side. It argues that successful task solutions can be preserved as executable subagents, then reused and refined over time [3]. In coding tools, this suggests a future where "write tests," "inspect migrations," "audit API compatibility," and "summarize risky diffs" become reusable agent skills, not one-off prompts.

This is why /multitask feels bigger than a convenience command. It is a primitive for reusable, parallel engineering workflows.

---

How should you prompt /multitask without creating chaos?

You should prompt /multitask by naming each workstream, defining what it owns, stating what it must not touch, and explaining how outputs should be reconciled. Good async prompts reduce ambiguity before execution begins. Bad async prompts simply create several confused agents instead of one confused agent.

Here is the kind of prompt I would avoid.

Use /multitask to fix the checkout bugs, clean up the code, and add tests.

That sounds reasonable, but it hides every important boundary. Which bugs? Which files? Which tests? Can agents edit the same modules? Should they branch separately? What counts as done?

A better version looks like this.

Use /multitask with three independent subagents.

Subagent A: Investigate the checkout failure reported in issue #482. Only inspect code and logs. Do not edit files. Return the likely root cause and exact files involved.

Subagent B: Review existing checkout tests and identify missing coverage for payment retry, expired carts, and coupon validation. Do not edit implementation files. You may propose test cases.

Subagent C: Inspect recent commits touching checkout, payments, and cart state. Summarize risky changes and possible regressions.

After all subagents report back, create one integration plan. Do not modify code until the plan lists file ownership, dependencies, and test commands.

Notice the difference. The improved prompt defines roles, permissions, outputs, and a synchronization point. That matters because async agents need state discipline. The research says frequent switching is not enough; agents must switch at the right moment while preserving task correctness [2].

If writing this kind of orchestration prompt feels tedious, tools like Rephrase can help turn a rough task into a cleaner agent prompt in a couple of seconds. I'd still review the final prompt myself, especially before allowing edits across multiple files.

---

What are the failure modes of async agent execution?

The main failure modes are premature continuation, tool confusion, duplicated work, forgotten subtasks, and unsafe integration. Async agents make these problems more visible because each subagent may have partial context, delayed feedback, and different assumptions about what the other agents are doing.

AsyncTool gives names to several of these problems. Models may act before a tool result returns, invent missing parameters, call the right tool for the wrong task, or simply neglect one of the active tasks [2]. In a codebase, those become bad imports, stale tests, duplicated migrations, and misleading summaries.

I would add one more failure mode: "confident merge theater." That is when the parent agent produces a polished integration summary even though the subagent outputs were incomplete or contradictory.

A practical guardrail is to require evidence with every subagent result. Not "I fixed it." Instead: files changed, tests run, command output, known risks, and remaining uncertainty.

For every subagent result, include:
1. Files inspected
2. Files changed
3. Commands run
4. Evidence of success
5. Risks or assumptions
6. Whether another subagent depends on this result

This is where prompt engineering becomes operational design. You are not trying to coax a clever answer from a model. You are defining a lightweight protocol for distributed work.

For more prompt patterns like this, the Rephrase blog has practical guides on turning vague AI requests into structured prompts that hold up under real workflows.

---

How does this change product strategy for AI IDEs?

Cursor's direction suggests that AI IDEs are becoming agent control planes. The editor still matters, but the strategic surface shifts toward task queues, sandboxes, durable runs, permissions, hooks, code review, and PR creation. In that world, the best AI coding tool is not the one with the flashiest autocomplete.

The best tool is the one that can safely execute work.

That is why the Cursor SDK reporting is important. Cloud agents that keep running when the local machine disconnects, connect back into the Agents Window, and open PRs when finished are not editor features in the classic sense [4]. They are workflow features.

The Reddit "focus restore" example is a small but telling community signal. A user built a hook to bring Cursor back into focus when an agent finishes, because async work creates new UX gaps: you start something, context-switch, then need to return at the right moment [5]. Tiny annoyance, big category clue.

As async agents become normal, teams will need conventions: which tasks are safe to parallelize, which require human approval, which can open PRs, and which must stay read-only. The prompt becomes the first policy layer.

My recommendation: start with read-only multitasking. Let subagents investigate, compare, test, and summarize before you let them edit. Once your team trusts the pattern, graduate to scoped edits in isolated branches or worktrees.

The future is not "one agent does everything." It is "many constrained agents do specific things, and the human remains the editor-in-chief."

---

References

These sources are grouped by hierarchy. The core claims about async coordination and reusable subagents come from Tier 1 documentation and research. Cursor-specific product details and workflow examples are used as supporting context, not as the sole foundation.

Documentation & Research

1. The next evolution of the Agents SDK - OpenAI Blog (link)
2. AsyncTool: Evaluating the Asynchronous Function Calling Capability under Multi-Task Scenarios - arXiv cs.AI (link)
3. AgentFactory: A Self-Evolving Framework Through Executable Subagent Accumulation and Reuse - arXiv cs.AI (link)

Product Reporting & Community Examples

4. Cursor Introduces a TypeScript SDK for Building Programmatic Coding Agents With Sandboxed Cloud VMs, Subagents, Hooks, and Token-Based Pricing - MarkTechPost (link)
5. Focus Restore feature for your Cursor - r/PromptEngineering (link)