Building AI-Native Workflows

An agent that can edit code is a loop with a kill switch, not a magic box.

Every coding agent - Cursor's included - runs the same skeleton. The model proposes an action, a tool executes it, the result feeds back and the model decides whether to continue or stop. When you build an AI-native workflow for a customer, you own that skeleton, so you have to know exactly where it breaks.

1. 1Plan. The model reads the task plus current context and decides the next concrete action.
2. 2Call a tool. It invokes one tool - read a file, edit a file, run tests, search the repo - with structured arguments.
3. 3Observe. The tool returns a result the model can actually parse: a diff, a test summary, an error.
4. 4Re-plan. The model updates its plan against what just happened, not against what it assumed would happen.
5. 5Stop. A condition fires - task verified, budget hit or no progress - and the loop ends deliberately.

Where loops actually failthe two failure modes you will demo

Tool design for code tasksthe contracts that make a loop debuggable

The tools matter more than the prompt. A loop with sharp, observable tools recovers from a confused model; a loop with vague tools fails even when the model is right.

def run_agent(task, *, max_steps=12, cost_ceiling_usd=2.0):
    state = init_state(task)
    spent = 0.0
    for step in range(max_steps):
        action, usage = model.plan(state)      # propose ONE tool call
        spent += usage.cost_usd
        if spent > cost_ceiling_usd:
            return stop("cost_ceiling", state)
        result = tools.invoke(action)          # idempotent + observable
        state = state.observe(action, result)  # feed the real result back
        if state.task_verified():              # tests green, types clean
            return stop("verified", state)
        if state.no_progress(window=3):        # diff unchanged 3 steps
            return escalate_to_human(state)
    return escalate_to_human(state)            # hit step budget

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/token budget checked before each model call, not after the bill arrives.
• Progress detection watches whether the diff or test state is actually moving; if it stalls for N steps, the loop is stuck even though steps remain.
• Success check is the only happy stop - tests pass and the type-checker is clean, verified by a tool, not asserted by the model.

Recovering from bad tool callsvalidation, retries and the human fallback

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.

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. 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.

The model didn’t fail your refactor. Your context did.

On a real codebase, output quality tracks context quality far more than prompt wording. The job is to assemble the smallest set of artifacts that fully specifies the change, then encode the customer’s standards so the model edits the way their team would.

What to include, what to leave outcuration, not collection

Encode the team’s standardsrules / .cursorrules as a workflow artifact

A customer’s conventions are part of the spec, not a nice-to-have. Cursor lets you commit rules (the .cursorrules lineage) so every agent run inherits the team’s standards without you restating them in each prompt.

# Stack & conventions
- Backend: Python 3.12, FastAPI. Frontend: TypeScript, React.
- Use the repo's `Result` type for fallible calls; never raise across module boundaries.
- All new endpoints get a pytest test and an OpenAPI entry.

# Editing rules
- Match existing import ordering; do not reformat untouched lines.
- Prefer small, anchored edits over rewriting whole files.
- If a public type changes, update its callers in the same change.

Pin behavior with golden examplesmaking prompts evaluable

A few in-context examples of a correct edit do more than paragraphs of instruction. They also make the workflow measurable: when behavior is pinned by concrete examples, you can build an eval set around those same cases and detect regressions.

• Show one or two golden examples: input code, the exact edit you’d accept and why.
• Keep examples close to the real task distribution, not toy snippets.
• Hold the temperature low for code edits so the same context yields stable output you can evaluate.

The cost of richer contextbudget it deliberately

More context usually means better edits, but every token added is latency and money on every call in the loop. Decide the context budget per workflow before production, the same way you’d decide a memory budget - not as an afterthought when the bill lands.

Mind the context window: the 50-65% rulethe most quantified craft rule

Output quality drops steeply as the window fills - noticeably by 70-80%, badly before 90%. The working guidance converges on staying under roughly 60-65%, and several heavy users start a fresh agent at ~50%. The bottom-right fullness indicator shows how full the window is and its makeup: the system prompt should stay small and the conversation should dominate. If you’re already 50% full before you send a prompt, that’s a warning sign you’ve loaded too many tools or plugins.

The anti-pattern: “make the app better” on the biggest modelvague + expensive = a compounding cost loop

The canonical thing not to do is a vague prompt on the most expensive model. With no clear context the agent makes blind, random edits, burns tokens, then burns more reading and fixing the bad code it just wrote - a compounding cycle. Vague prompts cost more and lower quality; specific, file-referenced prompts cost less and produce better output.

You can’t fit a million-line repo in the context window, so you retrieve the slice that matters.

Retrieval-augmented generation for code is how an agent stays grounded in a codebase too large to read whole. The pieces are an index, a retrieval step that pulls relevant code and the generation that edits it. The quality of the second piece sets the ceiling for the third.

Indexing a repochunking, embeddings, freshness

1. 1Chunk along structure. Split on functions, classes and symbols, not arbitrary character counts that cut a function in half.
2. 2Embed each chunk. Turn chunks into vectors so semantically related code is findable even without a keyword match.
3. 3Store with metadata. Keep file path, symbol name and line range alongside each vector so a hit is actionable.
4. 4Keep it fresh. Re-index changed files on save or commit; a stale index quietly retrieves code that no longer exists.

Retrieval that respects code structurebeyond text similarity

Plain text similarity finds code that reads alike. Code retrieval needs more: the function that calls this one, the type this signature depends on, the imports a change must update. Blend semantic search with structural signals from the symbol graph.

When RAG helps vs. when it doesn’tmatch the strategy to the task

Evaluate retrieval on its owndon’t blame the model for a bad fetch

If you only measure final edits, you can’t tell whether a bad result came from the model or from never giving it the right file. Score retrieval independently before you judge generation.

• Build a set of queries with the chunks a human says should come back.
• Measure recall: did the must-have files land in the top-k results?
• Track precision so you’re not flooding the window with near-misses that cost tokens.
• When generation is wrong, check the retrieved set first - often the file the model needed simply wasn’t there.

A workflow nobody waits for and nobody can afford never gets adopted, no matter how good the output is.

Senior customer engineers adopt tools that feel fast and have a defensible bill. That makes streaming, model selection and token budgeting part of the engineering, not polish you add later.

Streaming and backpressuremake partial results usable

• Stream tokens as they generate so the user sees motion in hundreds of milliseconds instead of waiting for the whole response.
• Make partial output usable: render the diff as it forms so a reviewer can start reading before it finishes.
• Apply backpressure when the consumer is slower than the stream, so a fast model can’t flood a slow UI or a downstream tool.

async def stream_edit(req):
    async for token in model.stream(req):       # tokens as they arrive
        await ui.send(token)                    # render incrementally
        if ui.buffer_full():                    # consumer can't keep up
            await ui.drain()                    # wait before pulling more

Match the model to the taskdon’t reach for the biggest by reflex

Always using the largest model is the most common waste in production LLM systems. Route by difficulty: a small model handles the easy bulk, a large model handles the hard tail.

Caching, batching, prompt reusecut cost and latency together

Token budgetingmeasure before you ship

You can’t defend a cost you never measured. Instrument tokens per task during the build, then set a ceiling so a pathological input can’t quietly 10x the bill in production.

Optimize for the right tokens, not the fewesttrue efficiency = efficiency × quality

Cheapest-per-token is the wrong target. A token-cheap model that needs 100 re-prompts isn’t efficient, and a model that one-shots a trivial feature while burning a billion tokens isn’t either. Tokens map straight to dollars - each model has distinct input/output/cached rates - so small inefficiencies compound at scale, but the goal is good hygiene that happens to produce cost efficiency and a better experience. Don’t penny-pinch the per-prompt cost; spend the right tokens on the right step.

The quality / latency / cost trianglepick two, on purpose

Automating a 4,000-file migration is easy. Automating it without breaking production is the actual job.

Large-scale transformation - a framework migration, a language upgrade, an API swap - is where an FDE earns trust or loses it. The model can generate the edits; you own the safety. The plan, the gates and the metrics are the deliverable.

Big-bang vs. incrementalalmost always incremental

1. 1Pilot on one slice. Migrate a representative module by hand or supervised and capture the exact recipe.
2. 2Encode the recipe. Turn it into the agent’s instructions plus a rules entry so every batch follows the same pattern.
3. 3Roll out in batches. Process a bounded set of files per change so a reviewer can actually read the diff.
4. 4Gate every batch. No batch merges until it passes the verification gates below.
5. 5Track and report. Update the metrics after each batch so the customer sees progress and risk in real time.

AST-aware vs. free-text editsknow when each is safe

Verify every changethe gates that earn merge

Rollback and blast-radius controlbe able to undo fast

• Keep each batch a separate, revertible commit or PR so a bad slice is one git revert away.
• Where feasible, gate the new path behind a flag so you can disable it in production without a redeploy.
• Define the blast radiusHow much breaks if a change goes wrong; the scope of potential damage. before you start: how many files, which services, what’s the worst case if a batch is wrong.

Measuring successthe metrics a customer will trust

What this looks like at real scalegrind mode and cloud agents on big repos

For the longest, hardest transformations, Cursor’s grind-until-done mode (in beta) lets a cloud agent grind for hours - or as long as needed - on work like a big migration or a from-scratch build. Most jobs don’t need it: toggling a cloud agent on and asking “implement this feature” already does well. Reserve grind mode for the genuinely long horizon, and don’t overuse it.