Cursor Cloud Agents Alternative: Merge Gate vs Done Gate

Cursor is an AI code editor, and its Cloud Agents let a developer hand a task to an agent that works in a remote machine and comes back with a pull request. For an engineering lead, the open question is not whether those agents write useful code. It is where the decision that a piece of work is finished actually gets made, and whether anyone outside the repository can see that decision afterwards.

This guide answers that question using Cursor's own documentation, read on 4 November 2026. It looks at the three gates Cursor puts around agent work: rules that steer the agent, hooks that run when it stops, and the Bugbot review check that sits in front of the merge. It then sets those against a task-level done gate of the kind described in our guide to AI agent work management, and says plainly where Cursor on its own is the better choice.

The scope is deliberately narrow. How a coding agent session differs from a task record is covered in our Devin alternative guide, how much to trust screenshots, videos and logs from Cursor and other vendors is graded in our post on coding agent artefacts as evidence, and VM and microVM boundaries are covered in our cloud agent isolation guide. This post holds one altitude: what each of Cursor's gates actually blocks, and what none of them records.

This guide is shipped by the team behind Cognibl, from DILR.AI, work management where people and AI agents share one board and a task reaches done only once a proof version is attached. Or see DATS, our five-stage AI consulting system for placing agents inside real delivery work.

What are Cursor Cloud Agents, and what do they do well?

Cursor Cloud Agents are coding agents that run in isolated cloud virtual machines with a full development environment, rather than on a developer's laptop. Cursor's documentation says they clone a repository, work on a separate branch, build and test the change, and push it back for handoff. A team can run many in parallel and start them from the editor, the web, Slack, Linear, GitHub or an API.

That breadth of entry points is a real strength. According to Cursor's Cloud Agents documentation, an agent can be kicked off from Cursor Desktop, Cursor Web, the iOS app, a Slack command, a comment on a GitHub or Bitbucket pull request, a Linear mention, or the API. The same page says agents can use MCP servers configured for the team, work across several repositories in one run, and produce merge-ready pull requests with screenshots, videos and logs. A developer can even take control of the agent's remote desktop to try the changed software without checking out the branch.

For a team whose engineers already work in Cursor, this removes most of the friction of delegation. Nobody has to learn a second tool to start an agent, and the environment the agent uses is the one the team configured, with the isolation trade-offs set out in our cloud agent isolation guide. Cursor also notes that Cloud Agents need a plan that includes them (Premium and higher, Teams, Enterprise or a legacy paid plan), so this is a paid-plan capability, not a free add-on. That much is settled. The rest of this guide is about what happens at the end of a run, which is where the record question starts. Teams weighing where agents belong in their engineering flow often start with an AI developer productivity review before choosing any tool.

Where do a Cursor agent's success criteria live?

In Cursor, the instructions that shape an agent's work live mainly in the repository and the editor, as rules. Cursor supports four types: Project Rules stored in a .cursor/rules folder, User Rules, Team Rules managed from a dashboard, and AGENTS.md files. Rule contents are placed at the start of the model's context, so they steer what the agent writes, but they do not check the result.

Cursor's rules documentation describes Project Rules as version-controlled files scoped to the codebase, applied always, by file pattern, when the agent judges them relevant, or only when someone mentions them. AGENTS.md is the plain-markdown alternative, supported in the project root and in subdirectories, with the more specific file taking precedence. Both are good places to write conventions such as which tests must run or which folders an agent must never touch.

The limit is in the word Cursor itself uses: rules provide context at the prompt level. A rule that says "every change must include a passing migration test" tells the agent what to aim for. Nothing in the rule system records whether the agent achieved it, and the rule lives with the code rather than with the piece of work a manager assigned. When the work is "fix the invoice export for the finance team", the success criteria a finance lead cares about are rarely in a .mdc file.

That is the gap a task-level definition of done fills. In Cognibl, from DILR.AI, the definition of done is carried on the task, and the evidence behind it is attached to the same record. The two can coexist: rules steer the agent inside the repository, and the task says what has to be shown before anyone calls the work finished. Our proof of done guide shows what a proof must contain for each kind of task.

Can Cursor's Bugbot act as a done gate?

Cursor's Bugbot is a review gate on a pull request, not a done gate on a task, and by default it does not block a merge even when it finds problems. Bugbot reviews each pull request diff and publishes a status check. Cursor's documentation says its default conclusion when it reports findings is neutral, and GitHub treats a neutral required check as passing, so findings alone do not stop a merge.

The mechanics are worth reading closely because the default is easy to miss. Cursor's Bugbot documentation lists three conclusions: success when it finds no issues and no earlier comments are unresolved, neutral when it finds issues, is cancelled by a newer commit or hits an internal error, and failure only when the check is configured to fail on unresolved issues. On the branch protection side, GitHub's protected branches documentation says required status checks must have a successful, skipped or neutral status before collaborators can change a protected branch. Cursor says the consequence directly:

"Requiring the status alone does not block merges on findings because findings default to neutral."

Cursor's own remedy is to enable fail-on-unresolved-issues where it is available to the organisation, which turns unresolved findings into a failing status. Two other documented details matter: it reads its configuration file from the pull request's base branch, so a pull request cannot change how Bugbot reviews itself, and it caps how many reviews it runs on pull requests opened by bot accounts.

Even configured strictly, though, Bugbot answers one question: does this diff have bugs Bugbot can see? It does not answer whether the task the agent was given is done. A clean diff that solves the wrong problem passes review. Working out which repositories need a stricter review gate, and which work needs more than one, is a typical output of an AI placement diagnostic. That distinction, between a merge gate and a done gate, runs through the rest of this guide.

What can a Cursor stop hook check before an agent finishes?

A Cursor stop hook is a script that runs when the agent completes, configured in a hooks.json file in the repository. Cursor's documentation says Cloud Agents run these command-based hooks, and a stop hook can return a follow-up message that sends the agent back to work, up to a loop limit of five by default. It is the closest thing Cursor offers to an automated completion check.

Cursor's hooks documentation describes stop as the hook that handles agent completion, alongside hooks that run before shell commands, before MCP calls and after file edits. The follow-up mechanism enables loop-style flows: run the test suite in the stop hook, and if it fails, return a message that tells the agent to keep going. The default cap is five automatic follow-ups per script, configurable through a loop_limit setting. Cursor's Cloud Agents page adds that Enterprise plans also run team hooks and enterprise-managed hooks, which keeps formatters, audit scripts and policy checks active when work runs in the cloud.

This is useful engineering. A stop hook that runs the test suite can send an agent back when it stops with failing tests. It has two properties a buyer should notice, though. The hook runs inside the agent's own environment and is written by the same team that wrote the agent's instructions, so its pass is a check the team wrote for its own agent, not a verdict from someone outside the repository. And once the loop limit is reached, no further automatic follow-ups are sent: the hook can send the agent back, but the hooks documentation describes no record of a refused completion, held against an assigned task, that someone outside the repository can read.

The same question, who verifies agent work and where, sits at the centre of our AI execution office service.

Who can see what a Cursor agent did?

A Cursor agent run can be opened by teammates, but only by members of the Cursor team it was started under who also have access to the repository it worked in. Cursor's documentation says team membership alone does not grant access, and viewing is read-only. That is sound access control for code, and on that rule a manager without repository access cannot open the run.

The Cursor Cloud Agents documentation says a teammate sent an agent's URL can see the conversation, the code changes and the artefacts the agent produced, once they have connected their own source control account and hold access to the repository. Cursor's Linear integration extends the picture: a Linear issue can be delegated to Cursor, the agent shows real-time status in Linear and creates a pull request automatically when complete, and progress is tracked in the Cursor dashboard. How Linear itself decides that delegated work is done is covered in our Linear alternative guide.

The practical effect is that the record of agent work sits in three places: the Cursor run, the pull request and, where used, the issue in the tracker. Each holds part of the story: the issue holds the ask, and the pull request holds the change, its artefacts and its approval. What none of them is built to hold is one statement, attached to the assigned work, that ties the ask to the evidence and to a named acceptance, readable by someone who never opens the repository. For an operations director or a head of delivery, that statement is the reason the question of a record comes up at all, and it is the gap an AI operating model is designed to close before agent seats are added.

How does Cognibl sit alongside Cursor rather than replace it?

Cognibl, from DILR.AI, is a work tracker rather than an editor, so it sits beside Cursor instead of competing with it. The Cognibl page says you can connect your own Claude Code, Claude Desktop or Cursor with an agent key. On a Cognibl board, a task reaches done only once a proof version is attached, and the page says the rule applies to people and agents alike.

The mechanics come from the live Cognibl page and from cognibl.com. The proof is a CSV describing the run, the documents it references and, for code, a coverage report. Without it the status change is refused, and the same rule applies to a person and to an agent. Proof versions are immutable, and every tool call through Cognibl's MCP gateway is written to an append-only, hash-chained trace. The gateway is deny by default, so a toolset that has not been enabled for a project is refused rather than silently missing.

Merge works differently too. The Cognibl page says merge is a console button only a person can press, that merging is refused while a branch clashes with its base, checks are failing or changes are requested, and that a merge moves a task one status forward, never straight to done. That last point is the main difference from a merge-triggered Done model. In a merge-led workflow, the merge is effectively the finish line. In Cognibl, the merge is one step, and done is a separate, evidenced decision.

The table below compares what each side documents on its live pages as of 4 November 2026. It is a comparison of where decisions are made, not a feature scorecard.

The runtime row matters for honesty. Cognibl runs coding agents on Claude Code and Codex, each in its own microVM, and does not ship a coding agent of its own. A team that wants Cursor's agents, editor and review bot can keep all three. What Cognibl adds is the task record that sits above them.

When is Cursor on its own the better choice?

Cursor on its own is the better choice when the people assigning and accepting agent work are the same developers who read the pull request. In that setting the pull request is the record, Bugbot plus a human reviewer is the acceptance step, and rules and stop hooks keep the agent honest. Adding a separate tracker would add a step without adding a reader.

That covers a lot of teams. A small product team where every task starts and ends in the editor gets more from Cursor's speed than from a second record. Cursor's spread of entry points, from Slack to Linear to a pull request comment, also means delegation happens where engineers already talk. If the team has turned on fail-on-unresolved-issues for Bugbot, required a human approval in branch protection, and written stop hooks that run the real test suite, the merge gate is strong.

The case for an additional done gate starts when someone who does not read diffs has to rely on the work. That might be a finance lead accepting a reporting change, a client accepting a deliverable, an auditor, working to a framework such as SOC 2 or ISO/IEC 42001, asking what an agent did and who signed it off, or a data protection lead whose organisation, as controller, must be able to demonstrate compliance under Article 5(2) of the UK GDPR where agent work touches personal data. Our what is Cognibl explainer sets out that boundary for non-engineering readers, and our DATS consulting system is where we help teams decide which of their workflows cross it.

What is the best Cursor Cloud Agents alternative for proving work in 2026?

The best Cursor Cloud Agents alternative for proving agent work in 2026 depends on which part you want to replace. To replace the coding agent, the realistic options are other agents such as Devin, OpenAI Codex or Claude Code. To keep Cursor and add an evidenced record of what was done, the alternative is a done-gated tracker such as Cognibl, connected through an agent key.

Judged on the criteria in this guide, the questions are concrete. Does the tool record success criteria on the work item rather than only in the repository? Does it refuse a done status without attached evidence, or only flag a diff? Is a merge the finish line, or one step before acceptance? Can a non-developer read the record without repository access? On these criteria, Cursor's documentation covers the agent and the review in depth, and says less about a record a business owner reads. Devin's session model is compared in our Devin alternative guide, and the wider question of how to verify an agent's task is set out in our AI agent task verification guide.

Where Cursor wins, it wins clearly: inside the editor, at speed, for teams whose reviewers are the people who assigned the work. Where the record has to outlive the pull request, a done gate on the task is the piece Cursor does not try to provide. If you want help mapping which of your agent workflows need which gate, book a scoping call with the team.

Frequently asked questions

Does Cognibl run Cursor's own coding agent?

Cognibl does not run Cursor's Cloud Agents. Cognibl runs coding agents on Claude Code and Codex, each in its own microVM, and its live page says a team can also connect its own Claude Code, Claude Desktop or Cursor with an agent key. In that set-up Cursor remains the editor and agent, and Cognibl holds the task, its definition of done and its proof.

Agent keys are scoped through Cognibl's gateway, where each project grants tools toolset by toolset, all off by default. The detail is on cognibl.com.

Can branch protection make Bugbot block a merge?

Branch protection can make Bugbot block a merge only if Bugbot is set to return a failing status. Cursor's documentation says Bugbot reports findings as neutral by default, and GitHub treats a neutral required check as passing. Cursor's advice is to enable fail-on-unresolved-issues where it is available, so unresolved findings produce a failure that branch protection then enforces.

A failing check stops a merge, which is useful. It still says nothing about whether the assigned task is finished, which is why teams that need that answer pair the merge gate with a done gate. Our AI placement diagnostic is a short engagement for working out where each gate belongs.

Where to go next

Want to see this in production? Try Cognibl with your own agents, review AI developer productivity options, book an AI placement diagnostic, or read about our approach to placing AI inside enterprise systems.

More guides on agent governance and delivery sit on our strategy category page, and you can read about Dilr.ai and the team that builds Cognibl.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.