1 min lesson
Recovering from bad tool calls
Name the parts in "Recovering from bad tool calls" and give the practical job of each one.
Step 1 of 2
Recovering from bad tool callsvalidation, retries and the human fallback
- Malformed tool args
- Validate against a schema before executing; return the validation error so the model can self-correct.
- Tool throws / times out
- Retry with backoff a bounded number of times, then surface the failure into the loop as an observation.
- Edit doesn’t apply
- Re-read the file, re-anchor the patch; never force a blind overwrite that loses local edits.
- Repeated failure
- Fall back to a human with the state, the last error and a concrete suggested next step.
When asked to “build an agent for X,” resist sketching prompts. Draw the loop, name the four tools and state your two budgets and three stop conditions out loud.
That ordering signals you’ve shipped one in production, where the prompt is the easy part.
Cursor Agent is this pattern made concrete. It reads and edits across files, runs the terminal, searches the indexed codebase and asks for approval on actions that touch the outside world. When you deploy a workflow on top of it for a customer, you’re tuning these same knobs - which tools it can reach, when it pauses for a human and what counts as done.
Learn more
Full explanation
One loop, many loops: parallel orchestration
One loop, many loops: parallel orchestrationhow the single loop scales in Cursor
The single loop is the unit; production work runs many of them at once. Cursor exposes two ways to fan out. Sub-agents (shipped in Cursor 2.5) let a parent loop spawn children for independent sub-tasks - each gets its own isolated context window, writes its findings to a file and hands only that file back, so the parent re-plans on a summary instead of swallowing every child’s tokens. In one demo the parent spun up two sub-agents and summarized while staying at roughly 16% of its own window. Multitask modeSending one prompt that fans out into several agents working on independent tasks at the same time. Press Enter for the full definition. spins up multiple full agents from one prompt (e.g. a backend 429 rate-limit change and a frontend dashboard in parallel), each doing its own codebase understanding, with effectively no hard limit on how many run at once.
If task B is unrelated to task A, start a new chat - don’t pollute one loop’s context with another’s.
If B and C both depend on A’s output but are unrelated to each other, spawn them as sub-agents so each runs in isolated context and the parent only re-plans on the returned files.
Three sub-agents are built in - explore, bash and browser - and you can pin a different model per child (e.g. a cheap parent spawning an Opus-class auditor).
Isolated context also sidesteps the old multi-tab collision - two foreground agents editing the same file used to block each other; parallelize independent slices and keep same-file work in one loop.