The Ultimate Agent Coding Workflow on Cursor

The Problem#

The target is a large enterprise line-of-business application, the same one from our Copilot, Claude Code, Claude plus Pi, Codex, and OpenCode projects. Its shape is public there, so we can reuse the numbers: 10,000+ functions across 1,000+ files in 22 modules, backed by PostgreSQL, with over a decade of accumulated business logic. Module interdependencies, application-layer data isolation, validation rules, and undocumented gotchas all live in that history. Very little of it is discoverable from the file an engineer happens to be editing.

Generic AI coding assistants fail here for a reason that has nothing to do with model quality. They generate syntactically valid code that breaks foundational platform concepts, crosses data-isolation boundaries, or misses a module-specific rule that is not in the current file. The structural relationships between functions (who calls what, where complexity concentrates) are invisible to any tool that treats code as text.

The naive fix is a bigger context window with more of the codebase pasted into the prompt. That is the wrong diagnosis. You do not need the model to hold ten thousand functions in its head. You need it to know which twenty functions matter for the task in front of it, why they exist, and what happened the last time someone touched them. That is an organization problem, and everything below is an answer to it. Documenting the same answer on Cursor matters because Cursor is the runtime most engineers already have open, and it inverts the usual tradeoff: it hands you more native affordances than any other non-Claude runtime, and asks for the most care in return when you push it to run unattended.

What We Built#

On Cursor, the workflow is the same roster of narrowly scoped agents, arranged in two tiers. Tier A is a driver that dispatches the pipeline; Tier B is the stage subagents that do the work. The driver can live on any of three surfaces, an in-IDE lead agent, the headless cursor-agent -p CLI, or the TypeScript SDK, and for a reproducible unattended pipeline the SDK or CLI driver is the one you use. It sits on top of the same six-layer stack. Every layer already existed as a pattern. The contribution here is assembling them into one coherent harness and showing that the architecture survives even on a runtime that began as an editor rather than a headless agent. The pattern language is the composable set Anthropic describes in “Building effective agents” [1]: a non-coding orchestrator that dispatches scoped workers, and an evaluator that checks their output. We covered the agent-definition side of this in Building Effective Claude Code Agents.

Figure 2 - The Six-Layer Stack: Orchestration topology decides who dispatches whom, the knowledge substrate is what agents read, traceability records what happened, the compounding layer governs what the system may learn, the safety stack catches what slips through, and economics decides which model runs each role. Each layer is independent, so any one can be upgraded in place. On Cursor the topology layer is a two-tier driver over stage subagents, and the safety layer is a rich hooks.json policy plane.

The roster is the proven Copilot pipeline, split further for parallel review: an explorer, a planner, an implementer, a code-reviewer and a security-reviewer running in parallel, a documenter, a skill-capture agent, a skill-validator that acts as a gate, and a skill-builder. The cognitive separation between the agent that writes code and the agent that reviews it is load-bearing, because a single agent grading its own work ships the security holes it just wrote. On Cursor each role is a stage subagent defined in a .cursor/agents/*.md file with its own model, and skills are native SKILL.md files that Cursor reads directly, including from .claude and .codex skill folders. The code graph, wiki, and issue history reach the agents as MCP servers configured in .cursor/mcp.json, shared across the IDE and the CLI.

KEY INSIGHT: Splitting the developer and the reviewer into two agents with no shared memory is not process overhead. It is the cheapest security control in the stack, because an independent reviewer catches the exact class of bug a self-grading agent is blind to. The runtime does not change that; on Cursor it just means the reviewer is a stage subagent in its own worktree that the driver dispatches, not a nested child.

Most of those layers are more than a pattern we cite: each is carried by a component we built, measured, and published as its own project, and this workflow is the assembly of those measured parts. Eight such instruments span the knowledge substrate and the layers beneath it. They are runtime-neutral by design, so the same eight carry the Cursor build; what Cursor changes is the wiring around them, covered later. The table below names the instrument behind each layer, links its project page, and gives the headline number we measured on it.

Key Results#

The Copilot pipeline proved the seven-stage shape. The Claude Code rebuild added the four layers the first version lacked, the Pi build recovered nested teams, the Codex build moved the orchestrator out entirely, and the OpenCode build proved it on the most neutral host. The Cursor build keeps every one of those layers and lands on the runtime with the most native affordances of any non-Claude host: native worktrees, a real policy plane, and any-depth nesting, with the honest costs being that its trace spine is bolt-on, an unattended run is harder to keep reproducible, and its richest ergonomics are tied to the editor.

The Development Workflow#

The staged pipeline is unchanged from what the Copilot workflow proved: research plus doc, then plan plus doc, then code, then review plus doc, then skill capture, then knowledge capture, then an issue comment plus doc. What changed is the mechanics of the handoff underneath. On Cursor there is no native pipeline, so the driver is the state machine: it reads a work list, dispatches each stage to a fresh stage subagent in its own worktree, and moves the durable output of one stage into the input of the next. This mirrors Anthropic’s guidance for long-running agents: a non-coding initializer or orchestrator, repeated stateless coding sessions, and progress written to files and commits rather than held in a single swelling context [2].

Figure 3 - The Seven-Stage Pipeline: Each stage produces a durable artifact (a research note, a plan, a diff, a review, a skill, a wiki entry, an issue comment) that becomes the next stage’s input. The artifacts are files, so a stage can be re-run or resumed without replaying the whole session. The review stage forks into a code-reviewer and a security-reviewer that rejoin before documentation. On Cursor the driver owns the sequence, and each stage runs in its own native git worktree. The amber arrows run backward: a failing test or a rejected review routes to the planner for another research-and-refine pass, and only verified work moves forward.

The important property is that state lives on disk, not in a conversation. A research agent writes a findings file, the planner reads it cold and writes a plan, the implementer reads the plan cold and writes code. Each agent starts from a clean context and a written brief, which is why the pipeline can run for hours without a long session slowly forgetting its own early decisions. On Cursor this discipline pairs naturally with the native worktrees: because each stage runs in its own checkout and writes its durable artifact to disk, a restart resumes from files and worktrees rather than from a lost editor session, and parallel stages never trip over one another’s uncommitted changes.

On paper that reads like a conveyor, and it is not one. The pipeline iterates, and the loop runs through the planner. The implementer’s definition of done includes running the tests, and a failing test does not move forward; it routes back to the planning stage with the failing output attached. The planner owns the diagnosis. It can send the explorer back out for more research, and it can decide to instrument the code, adding debug statements for terminal inspection or setting breakpoints and stepping through the failure, to gather the evidence the first plan lacked. The refined plan goes back to the implementer, which applies the changes, re-runs the tests, and verifies the fix actually worked. Only a verified change reaches review, and review findings travel the same road: a rejected diff goes back through the planner rather than to an ad hoc patch. On Cursor the driver re-dispatches the planner subagent with the current plan and the failing evidence, and the native worktrees earn their keep here: the instrumented code, the debug statements and half-applied attempts, stays quarantined in the work item’s own worktree until the fix verifies, so exploratory scaffolding never leaks into the main checkout. Every pass leaves an amended plan and a fresh findings note on disk, so the iteration stays as traceable as the pipeline itself.

The Knowledge Substrate#

Underneath the pipeline are four kinds of memory that do not substitute for one another. Getting this taxonomy right is the sharpest part of the whole design, because conflating any two layers produces silent retrieval failures.

• Structural memory is the code graph. We run CodeGraphContext (CGC), an open-source code-graph tool we adopted and fixed rather than built; our contributions were Neo4j node-conversion fixes, logger bug fixes, Windows PATH compatibility, and a portable .cgc bundle system. It parses the source into a Neo4j graph exposed over MCP, so an agent can ask “who calls this function” and get an exact answer, not a similarity guess. It re-indexes on save, never rots, and is exempt from the refinement gate because it is deterministic. On Cursor it mounts over .cursor/mcp.json, shared across the IDE and the CLI so every stage subagent reaches it the same way.
• Semantic memory is a file-based domain wiki: the why behind a workaround, the business rule behind a data model, what tenant isolation means in this specific codebase. This is knowledge you cannot infer by reading the code.
• Episodic memory is the issue history: one dated entry per ticket, capturing what happened and why, so a returning agent starts warm instead of re-discovering a dead end. On Cursor the issue history is one of the MCP servers you build, because there is no native episodic layer.
• Procedural memory is skills: progressive-disclosure files that describe how to run a repeatable task. The library splits into two families, both load-bearing. Engineering skills encode the codebase’s coding conventions and its API reference surfaces, the exact call shapes of internal services and third-party SDKs. Domain skills encode how the business actually works in this system: how orders flow, how invoicing runs, how credits apply. They are also living files, not one-time documentation. When an agent working in one of those areas discovers something a skill missed, the skill-capture stage feeds that discovery back into the skill, so the library sharpens with every ticket it touches. Cursor reads the same SKILL.md format natively, and reads .claude and .codex skill folders as well, so the procedural layer ports with no work at all.

Figure 4 - Four-Layer Memory: The code graph holds the shape, the wiki holds the why, the issue history holds what happened on a specific ticket, and skills hold how to perform a task, from coding conventions and API call surfaces to domain procedures like orders, invoicing, and credits. Each layer has a characteristic wrong-use pattern (a procedure buried in the wiki, domain lore stuffed into a skill) that degrades retrieval when boundaries blur. On Cursor the code graph mounts over .cursor/mcp.json and identity lives in Rules plus AGENTS.md plus Memories.

The agents do not pick a retrieval method at build time. We hand them every tool and let the loop choose, cheapest mode first: navigational (read the wiki and issue-history index first, because a documented answer beats a fresh investigation), then structural (the code graph for exact call chains and blast radius), then textual (grep for literal strings the graph does not model), then semantic escalation only when the cheaper passes fail. The navigation map that makes that first rung cheap is one we packaged as MapKit, built on the upstream DOX/AGENTS.md pattern rather than invented, where we measured 2.1x fewer context tokens per edit against reading raw files.

Figure 5 - The Retrieval Ladder: Retrieval climbs from cheapest to most expensive. Navigational lookups answer most questions from an already-written index. Structural queries hit the code graph for exact relationships. Textual grep covers literal strings. Semantic vector search is the last rung, reached only when the first three fail, not the default.

This is where we take our most contrarian position: a vector database is premature by default on this codebase. Embedding pipelines cannot keep pace with an active team’s change rate, and the code graph plus grep plus a wiki index already covers structure and lookup. When a vector layer does earn its place, it belongs over the wiki prose, never over the code, and only on a named pain signal, such as the wiki outgrowing what an index and grep can serve. Building it speculatively buys a staleness and security problem in exchange for a capability you were not yet using. The runtime does not move this line: the substrate is identical on Cursor, which is the whole point of documenting it once and reusing it across all five runtimes.

KEY INSIGHT: On a live codebase, retrieval quality comes from letting the agent climb a cheap-first ladder, not from bolting a vector store onto everything. Earn the vector layer with a real pain signal, and put it over prose, never over code the graph already models.

Traceability and the Self-Improving Loop#

This is the biggest single upgrade over the Copilot workflow, which had no trace layer at all. Traceability is what turns the back half of the pipeline (review, skill capture, knowledge capture) from a manual chore into a self-improving loop.

We capture every session as a trace. On Cursor this is the one layer that is genuinely bolt-on, and we say so plainly because it is the honest cost of this runtime. Cursor emits stream-json event streams and hook events, not a hierarchical trace product, so the LangSmith spine is a shim you build: an adapter that reads the event stream plus the hook firings and correlates them into one pipeline-run trace. It is the weakest trace story of the five runtimes, and it is real work rather than a config flag. The payoff, once built, is the same as everywhere else: the append-only event log becomes the agent’s identity, and runs are replayable, forkable, and portable. We built the harvest side of this as TraceKit, which reads a coding session’s transcript into a cost curve and a reliability scorecard, catching 17 of 17 process faults that an output-only check misses.

Figure 6 - The Self-Improving Loop: Every session emits a trace, on Cursor through a bolt-on shim that reads stream-json events plus hooks into a LangSmith adapter you build. A two-phase loop reads those traces, first identifying recurring issues, then generating candidate fixes. The fixes are proposed edits to skills and to the domain wiki, which is exactly the skill-capture and knowledge-capture stages automated. The gate is what keeps the loop from feeding on its own noise.

The loop itself is simple to state. Trace the runs, then run a two-phase pass over them: identify recurring failure modes, then generate fixes as proposed edits to skills and to the wiki. That is the skill-capture and knowledge-capture stages, automated, and we described the general shape of a system that improves its own agents in our writeup When AI Builds AI. The one non-negotiable is that the proposed edits pass through a gate before they land, the subject of the next section. A self-improving loop with no gate does not improve; it compounds its own mistakes.

One boundary deserves a hard guard. Any stage that reads an issue tracker or an error log is a prompt-injection surface, because hostile text can ride in through a ticket body. The issue-comment stage needs a safety classifier in front of routing, so a poisoned ticket cannot steer the agent. The classifier we built for that boundary is Ingest-Guard, which caught 85.0% of injections at 0.0% false positives keyless in our tests, with 0 of 40 payloads leaking through.

Orchestration#

This is where Cursor is most distinctive, because it hands you more native structure than any other non-Claude runtime and then asks you to be disciplined about it. The topology is two-tier: a driver in Tier A dispatches seven stage subagents in Tier B. Cursor allows any-depth nesting and up to eight parallel agents, each with its own model, so you could nest much deeper than two tiers. We deliberately do not. The two-tier shape keeps the pipeline legible and its trace readable, and the extra nesting capability is held in reserve for a work item that genuinely splits into parallel sub-tasks. The driver itself is external code for a reproducible run, either the TypeScript SDK, which is the natural spine, or the cursor-agent -p CLI, and the in-IDE lead agent is the interactive alternative when a human is in the loop.

Figure 7 - The Two-Tier Topology: A driver in Tier A dispatches seven stage subagents in Tier B, and each stage runs in its own native git worktree. Cursor is the one runtime of the five where worktree isolation is native rather than a hand-rolled pattern, so parallel lanes never collide and a plain merge resolves them. Cursor also allows any-depth nesting and up to eight parallel agents, so the two-tier shape is a deliberate choice for legible tracing, not a runtime limit.

The standout affordance is native git worktrees. On every other runtime in this series, the worktree fan-out pattern, one worktree per work item so parallel file mutation never collides and a plain git merge resolves two half-solutions mechanically, is something you enforce by hand. On Claude Code and Pi it is a documented pattern; on Codex and OpenCode it is partial, with sharp edges like Codex’s shared session directory and OpenCode’s missing flag. Cursor is the one runtime that ships it: /worktree gives each stage subagent its own checkout natively, so the isolation the pattern asks for is a first-class feature rather than a discipline. We still present worktree fan-out as an architectural pattern rather than a benchmarked result, but on Cursor it is the pattern with runtime support underneath it.

The strongest external driver framework, when you want a vendor-neutral spine rather than Cursor’s own SDK, is Pydantic AI v2, and it maps onto this architecture cleanly. Its typed, schema-validated structured outputs are the stage gates and the refinement gate, because a gate is a branchable typed verdict object. Its agent delegation and graphs are the seven-stage sequence and the parallel review fan-out. Its durable execution with first-class human-in-the-loop approval is the restart-safe run and the gate that pauses for a person. Its Logfire and OpenTelemetry emission is one more trace source to fold into the adapter, and its MCP client is how the substrate mounts. It reached general availability in mid-2026 with a stated three-month breaking-change window, so we treat it as promising rather than settled, and note that its path to LangSmith is an OpenTelemetry bridge rather than a native sink. On Cursor the idiomatic driver is the native TypeScript SDK, and Pydantic AI v2 is the neutral alternative for a team that wants the spine to be model-agnostic and portable.

Two orchestration cautions carry across from the research. The first is a warning: flat equal-role agents do not scale. Cursor has reported that 20 peers sharing a coordination file collapse to the throughput of 1 to 3 under lock contention, and that the cure is role separation into a planner, a sole-owner executor, non-coordinating workers, and an independent judge [3]. We treat that figure as Cursor’s self-reported finding, not a universal law, but the shape matches everything we have seen, and a two-tier driver over scoped stage subagents is exactly that role separation. The second is the parallel fan-out itself, which on Cursor is the native-worktree strength above rather than a pattern you enforce. The model map is held constant to isolate the harness effect. Opus 4.6 runs the two low-volume, high-leverage roles, the orchestrator and the planner. Sonnet 4.6 runs the high-volume verifiable roles: implementer, reviewers, documentation, and the skill roles. Cursor’s own model menu is broad, spanning Claude, GPT, Gemini, Grok, and Composer, but the workflow map stays on the two Anthropic models so the comparison across runtimes stays clean. We walked through the multi-agent handoff mechanics in more depth in Multi-Agent Pipelines.

Compounding Without Slop#

The system is allowed to learn, but only through a gate, because agents lack the pain bottleneck that stops a human from writing bad documentation. A person who writes a misleading wiki page eventually gets burned by it, an agent does not. Left ungated, the loop feeds on itself: the wiki page an agent gets wrong today is the source the next agent reads as established fact tomorrow, and the error is re-copied and amplified on every pass after that. That is the ouroboros problem, named for the serpent drawn eating its own tail, and compounding slop is what it produces.

The gated refinement loop runs after review. It proposes three things: skill edits, wiki-page edits, and an always-written issue-history entry. The issue-history entry is ungated, because it is episodic fact and low blast radius. The skill and wiki edits are gated, either by a human or by a capped validator agent. On Cursor the gate is expressed inside the same hooks.json policy plane that carries the security frame: an ask verdict on the write pauses the edit for a human, so the refinement gate and the security boundary are one first-class layer rather than two bolt-ons. We built that loop as FlywheelKit, which compounded 1 to 4 gotchas across 3 harvests while blocking a plausible-but-wrong rewrite at the gate, and the definition-of-done check behind it as the Deterministic Gate Harness, where 0 phases advanced without evidence across 6 gated runs and the same workflow ungated shipped 4 broken artifacts.

Figure 8 - The Three-M Gate: A proposed edit auto-applies only when all three risks are absent. Megaphone asks whether a wrong update broadcasts widely, Money whether it touches anything financial, and Meaning whether it corrupts a shared context file other skills depend on. Any one present routes the edit to human review. The criterion is blast radius, not confidence.

The gate criterion is blast radius, captured as the three-M test. Megaphone asks whether a wrong update broadcasts widely. Money asks whether the change touches money. Meaning asks whether it corrupts a shared context file other skills depend on. The loop auto-refines only when all three are absent, and routes everything else to a human. For model specialization, the sellable pattern is the teacher-model pattern: a stronger teacher watches a cheaper student fail, writes a skill that captures the fix, and the student executes from that skill thereafter. Full custom reinforcement-learning distillation is real, but it fails the practicality test for a typical mid-market client with no GPU infrastructure, so it stays a reference rather than part of the workflow we ship.

KEY INSIGHT: Give a self-improving system a blast-radius gate, not a confidence threshold. Confidence is what a wrong agent has too much of; blast radius is what actually determines whether a bad edit costs you a typo or a corrupted shared context file. On Cursor you wire that gate into the same policy plane that already guards every action.

Quality, Safety, and Economics#

Safety is a stack, not a reviewer. Each layer catches what the others miss, and on Cursor the second layer is the richest of the five runtimes: a hooks.json policy plane that carries both the security frame and the refinement gate.

The first layer is adversarial verification: the checker re-derives the answer and ignores the worker’s self-report, so a confidently wrong result gets caught at any rank, including the orchestrator’s own. We wrote about this red, blue, and referee structure in our adversarial testing series, and the fresh-context judge we built for it is RubricGate, which took task success from 0/3 to 3/3 at 1.00 judge precision and recall on our labeled sample. The second layer is the policy plane, and here Cursor is a genuine strength rather than a caveat: its hooks.json layer spans roughly twenty hook events with allow, deny, or ask verdicts, and it is a real boundary the runtime enforces, not an advisory suggestion. Every stage action crosses it before it can touch application state, allow proceeds, deny blocks, and ask routes to a human, and a separate security-reviewer stage subagent still checks tenant isolation, parameterized SQL, OWASP categories, and auth boundaries at review time. The third layer is hard action gates: a typed SDK is the agent’s only door to mutate state, and a deterministic execution step catches the false-completion failure where an agent reports done with nothing committed. Governing how much autonomy each role earns, the Trust-Ladder Deployer runs four eval-gated rungs whose auto-demote kept 7 bad writes out of production. The last discipline is to prune scaffolding as models improve, because a verifier written around a model limitation that has since been fixed can start doing harm.

Figure 9 - The Hooks Policy Plane: On Cursor the security frame and the refinement gate are one first-class layer: a hooks.json policy plane with roughly twenty hook events and allow, deny, or ask verdicts. Every stage action crosses it before it can touch application state. Allow proceeds, deny blocks, and ask routes to a human, which is how the refinement gate is expressed. This is the richest policy layer of the five runtimes, a real boundary rather than an advisory suggestion.

On economics, the rule is to route by dollars per task, not dollars per token. The flagship model runs planning and hard code, a mid tier runs by default, and the cheap tier runs mechanical labeling and knowledge chores. Two mechanics keep the bill down and both have vendor-direct backing. Anthropic’s prompt caching reads cached input at 10% of the normal input rate, a 90% discount on repeated context [4]. Lean tool design matters because tool definitions themselves eat the context window: Anthropic measured tool-definition token loads in the tens of thousands, with a five-server setup of 58 tools costing roughly 55K tokens before a single call is made, and its Tool Search Tool with deferred loading cut that by about 85% in Anthropic’s own measurement [5]. That capability is in beta, not general availability, so we treat it as a near-term optimization rather than a shipped default.

Figure 10 - Routing by Dollars per Task: The two low-volume, high-leverage roles (orchestrator and planner) run on the flagship tier. The high-volume verifiable roles (implementer, reviewers, documentation, skills) run on the cheaper tier. The routing target is cost per completed task, not cost per token, because a cheap model that loops ten times is not cheap. On Cursor the tiers are selected per stage subagent, and billing is a subscription plus usage.

Cursor bills as a subscription plus usage, which sits between the flat-rate Max plan and the fully metered API, so the model map that isolates the harness effect is also a soft budget lever rather than a hard one. That is why Opus stays confined to the two low-volume, high-leverage roles: the routing discipline holds regardless of exactly how the plan meters. The re-feed problem is the other cost lever, because the dominant token cost in a coding session is the output of tool calls, the file reads, git status dumps, test logs, and JSON blobs the agent pulls in, not the prompt you write. Sebastian Raschka, who writes the Ahead of AI newsletter, ran one open-weight model across three harnesses on an identical task set and found that Claude Code used by far the most input tokens and Codex the fewest, with a single Claude Code run burning roughly 578k input tokens against 4.5k of output across 25 turns [6]. That is one author’s five-task private benchmark, so we read it as directional rather than definitive. The mitigation is a reversible, type-aware compression layer between the agent and the model: compress each tool result by content type (AST-strip for code, field-prune for JSON, smart-filter for shell), cache the original, and leave a retrieve(id) escape hatch so nothing is lost. Tejas Chopra, an engineer at Netflix, laid out this pattern in his Headroom talk at the Linux Foundation’s Open Source Summit North America, and noted that AST compression matters more when the agent reads raw files than when it works through an LSP [7]. Cursor works through an LSP for much of its editing, so the AST-strip lever is smaller here than on the raw-file runtimes, though field-prune and smart-filter still apply to the JSON and shell output that dominate a session. We built that measured implementation as ContextLedger, which unifies three patterns we had arrived at independently and recorded a 44.0% tool-output token reduction, fully reversible, on a real 127-payload session at roughly a 1% retrieve rate. To be precise about provenance: we built ContextLedger and the 44% is our own measurement, while the compression pattern itself is Chopra’s Headroom work. It stacks with the prefix caching above rather than replacing it.

KEY INSIGHT: The biggest token line in a coding agent is the output of its tool calls, not the prompt you write. Compress that output reversibly and by content type, and you cut the bill at its actual source while losing nothing, because the original is one retrieve(id) call away.

Figure 11 - Tool-Output Compression: A large raw tool result passes through a content router into a type-aware compressor (AST-strip for code, field-prune for JSON, smart-filter for shell). A compact payload goes to the Cursor agent carrying a retrieve(id) handle, while the original is cached in a store. On Cursor the layer plugs in as an MCP server between the tool and the agent, and the measured result on a real session is a 44% reduction in tool-output tokens, fully reversible.

What Transfers#

The thesis of this whole build is that the architecture is runtime-neutral, and five runtimes in, the evidence is complete. The roster, the four-layer substrate, the gates, and the traceability spine were identical on Claude Code, on Pi, on Codex, on OpenCode, and now on Cursor. What differed each time was only how each affordance is provided, whether native, ported, or built by hand. Claude Code provides nearly all of it natively and flat. Pi recovers nested teams. Codex provides strong parts and no assembled pipeline. OpenCode is the strongest neutral host. Cursor provides the most native structure of the non-Claude runtimes, native worktrees and a real policy plane and any-depth nesting, and asks in return for the discipline to keep an unattended run reproducible and to build the trace spine yourself.

Figure 12 - The Portability Matrix: The same workflow ports across five runtimes. Claude Code is native across the board but flat, Claude plus Pi adds nested teams and deeper hooks at the cost of a metered bill, and Codex, OpenCode, and Cursor each provide the affordances differently, with the orchestrator living outside the agent for every non-Claude-native runtime. The architecture is the constant; the wiring is the variable.

There is one cross-runtime finding worth stating plainly, and it lands on Cursor the same way it landed on Pi and OpenCode. Newer Claude models are being tuned toward Claude Code’s own edit tool, which means running Claude inside a third-party harness can degrade its custom tool-schema calling. Armin Ronacher, who builds the Pi harness, reported exactly this effect and Simon Willison relayed it: the newest Claude models are worse than their older siblings at correctly calling Pi’s edit-tool schema, appending invented fields to the call so the harness rejects it and the model retries [8][9]. Ronacher’s proposed cause, reinforcement-learning post-training toward Claude Code’s own edit tool, is his theory rather than an Anthropic-confirmed mechanism, and the account is a qualitative developer report with no published failure rate. This workflow runs Anthropic models on Cursor to hold the map constant, so the mitigation is the same as on the other neutral hosts: keep each stage subagent’s edit-tool schema close to what the chosen model is trained on, and validate tool calls at the boundary so a malformed call is caught and retried rather than silently mis-applied.

Cursor also carries honest costs that the series would be dishonest to skip, and they are the reason it is the last runtime rather than the first. Its trace spine is bolt-on, a shim off raw event streams rather than a native trace product. Deterministic unattended reproducibility is genuinely harder here than on the CLI-first harnesses, because Cursor began as an editor and its headless surfaces are newer, with occasional reports of the cursor-agent -p CLI hanging in unattended runs. Its richest ergonomics, best-of-n generation, plan review, and memory approval, are also still tied to the graphical editor rather than the headless path. None of these change the architecture; they change how much care an unattended Cursor pipeline asks for, which is exactly the kind of runtime-specific detail this series exists to surface.

Conclusion#

The workflow that ran on GitHub Copilot, then on Claude Code, then on Pi, then on Codex, then on OpenCode, survives its move to Cursor intact, because it was never really about the runtime. It is about organizing a decade of codebase knowledge into four durable memory layers, dispatching narrow agents against a written brief, tracing every run, and letting the system learn only through a blast-radius gate. Moving it onto Cursor completes the argument the whole series was built to make: the substrate, the gates, and the safety stack ported without change across five very different runtimes, while the wiring shifted every time. Cursor hands you the most native structure of any non-Claude host, native worktrees and a real policy plane, and asks for the most care in return when you run it unattended.

That is the whole payoff of documenting one workflow five ways. The design is the constant. Each runtime tells you which parts it hands you, which you build, which you must guard against, and which you must be disciplined about. Claude Code is the cleanest native host for the flat version. Pi buys back nesting. Codex and OpenCode move the orchestrator out, one over an MCP server and one over an HTTP server. Cursor gives you native worktrees and a rich policy plane inside an editor. Pick the runtime by what the job actually needs, port the architecture unchanged, and wire it to what that runtime provides. The knowledge organization is the product; the runtime is a choice.

Technologies#

As a Consulting Engagement#

This is how we run a harness-engineering engagement when a team already lives in Cursor and wants the coding agents where their engineers already work. We assess the codebase, stand up the four-layer substrate as MCP servers, build the two-tier driver and both gates (the TypeScript SDK is the natural spine, Pydantic AI v2 the neutral alternative), put each stage in its own native worktree, wire the security frame and the refinement gate into the hooks.json policy plane, and build the bolt-on trace adapter that Cursor does not ship. Each of the eight instruments behind the six layers is independently deployable, so an engagement can start with the layer that hurts most, whether that is token cost, agent reliability, or injection exposure, and expand from there. The Cursor build is the right call specifically when a team wants native worktree isolation and a rich policy plane inside the editor they already use, and is willing to invest in the trace spine and the reproducibility discipline that an unattended run needs. If you are running coding agents against a large legacy codebase and cannot tell which scaffolding to keep and which to delete as the models improve, we are happy to talk it through or lend a hand.

The Series#

This is the fifth and final project writeup in the Ultimate Agent Coding Workflow series, one state-of-the-art coding harness documented per runtime:

1. The Ultimate Agent Coding Workflow on Claude Code: the flat, fully native build on Max, where the code graph, skills, hooks, and tracing are all first-class.
2. The Ultimate Agent Coding Workflow on Claude + Pi: the hybrid that puts a Claude orchestrator over Pi workers to recover nested teams and deeper TypeScript hooks.
3. The Ultimate Agent Coding Workflow on Codex: the external OpenAI Agents SDK or Pydantic AI v2 orchestrator driving Codex as an MCP server in a star topology, with a two-ring security model.
4. The Ultimate Agent Coding Workflow on OpenCode: an external TypeScript SDK conductor over a headless server, with a real per-agent permission frame and best-in-class model-agnostic routing.
5. The Ultimate Agent Coding Workflow on Cursor (this writeup): the two-tier, IDE-first variant with native git worktrees, a hooks.json policy plane, and a bolt-on trace spine.

References#

[1] E. Schluntz and B. Zhang, “Building effective agents,” Anthropic Engineering, December 19, 2024. https://www.anthropic.com/engineering/building-effective-agents

[2] J. Young, “Effective harnesses for long-running agents,” Anthropic Engineering, November 26, 2025. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

[3] Cursor, “Towards self-driving codebases,” Cursor Blog, February 5, 2026. https://cursor.com/blog/self-driving-codebases

[4] Anthropic, “Prompt caching,” Claude Platform Documentation, 2026. https://platform.claude.com/docs/en/docs/build-with-claude/prompt-caching

[5] Anthropic, “Introducing advanced tool use on the Claude Developer Platform,” Anthropic Engineering, 2026. https://www.anthropic.com/engineering/advanced-tool-use

[6] S. Raschka, “Using Local Coding Agents,” Ahead of AI, June 27, 2026. https://magazine.sebastianraschka.com/p/using-local-coding-agents

[7] T. Chopra, “Headroom: A Context Optimization Layer for LLM Applications,” Open Source Summit + Embedded Linux Conference North America 2026, The Linux Foundation, Minneapolis, MN, May 19, 2026. https://www.youtube.com/watch?v=UOWSHg18cL0

[8] A. Ronacher, “Better Models: Worse Tools,” Armin Ronacher’s Thoughts and Writings, July 4, 2026. https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/

[9] S. Willison, “Better Models: Worse Tools,” Simon Willison’s Weblog, July 4, 2026. https://simonwillison.net/2026/Jul/4/better-models-worse-tools/