2 min lesson
Stop conditions and budgets
Name the key items in "Stop conditions and budgets", then explain why each one matters.
Step 1 of 3
Stop conditions and budgetsthe part interviewers probe hardest
- Max steps caps the worst case so a stuck loop can’t run forever.
- Cost ceiling is a dollar or token budget checked before each model call.
- Progress detection watches whether the diff or test state is moving. If it stalls for N steps, the loop is stuck even though steps remain.
“The model says it’s done” is not a stop condition. The model is the least reliable judge of its own output.
Tie the success stop to a tool result a customer would trust, such as a green test suite and a clean type-check.
Learn more
Full explanation
Recovering from bad tool calls
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,” draw the loop before you sketch any prompt, and name the four tools, the two budgets and the two stop conditions (verified, no progress) out loud. Here is what that sounds like for an agent that fixes failing tests.
“The agent gets four tools: read_file, edit_file, run_tests and search, each returning something it can re-plan on. Two budgets: 12 steps maximum and a two-dollar cost ceiling, checked before every model call. Two stops: verified, meaning the suite is green and the type-check is clean, and no progress, meaning the diff hasn’t moved in three steps, which escalates to a human with the current state. If the model says it’s done while a test is red, the loop keeps going, because only a tool result can end it.”
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 let a parent loop spawn children for independent sub-tasks. Each child 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. 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 (a backend 429 rate-limit change and a frontend dashboard in parallel, say), each doing its own codebase understanding.
If task B is unrelated to task A, start a new chat so one loop’s context doesn’t pollute another’s.
If B and C both depend on A’s output but are unrelated to each other, spawn them as sub-agents; 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, such as a cheap parent spawning a stronger auditor.
Don’t let agents compete on the same files. Parallelize independent slices and keep same-file work in one loop.