How this shop works

01 The two layers

There are two layers and they do not merge.

The local layer is this computer. Scott coordinates here. The teammate bots run here. This is where topics get found, research gets assembled, drafts get written, and files get filed. It is coordination and writing work, not repo work.

The cloud layer is Cursor’s. A cloud agent runs on a Cursor-managed VM with a full development environment, clones the repo, and does the actual branch-edit-PR labor. Scott is the coordinator on this computer. He is not a cloud agent, and nothing about his role involves a Cursor VM.

Code lives on Origin, native repos stay on Origin, and GitHub-mirrored repos still push to GitHub because GitHub remains their source of truth. The layers meet at the repo, not inside anybody’s editor.

02 The teammate bots

The shop has fixed roles. These are not interchangeable, and the work degrades when they get flattened into “the bots researched it.”

One piece of local plumbing worth naming: Quack. Quack is DuckDB talking to DuckDB over HTTP, so several agents can query the same catalog at the same time. It is not a folder, not a filesystem, and not where files live. Files live in the workspace; Quack is the shared query surface on top.

A caveat on official-ness. Grok Bot internals are not documented in cursor.com/docs. Anything this page says about the teammate-bot side of the pipeline is shop practice, not official Cursor documentation. The Origin and cloud-agent side is sourced from cursor.com, and where the docs are silent, this page says so instead of guessing.

03 Cloud agents and Origin

Official wording, because it settles the facts: Origin is Cursor’s git forge for storing and sharing code. Use it to host repositories, sync projects from GitHub, and browse your team’s Origin repos in the browser. The changelog from Aug 17, 2026 adds: Cursor can now host your code. Origin begins rolling out today in early beta on all paid plans.

A cloud agent is a job, not a resident. Per the docs, cloud agents run in isolated VMs in the cloud with full development environments, and against Origin repositories they clone, branch, commit, push, and open pull requests. You attach one to an Origin repo from your team’s codebase the same way you attach one to other connected source control, and it uses your Cursor account’s Origin access. They do not sit idle waiting for something to happen. No job, no run.

Access needs saying: Origin code storage is on Pro, Teams, and Enterprise plans, not free, and it opens in stages. Someone has to claim a codebase name first, which becomes the {owner} in every repo URL, and during the beta you cannot change it. Teams on legacy privacy mode cannot enable Origin at all.

Native versus mirrored matters for where work lands. A repo created on Origin is native: hosted on Origin, and pull requests opened on it stay on Origin. They are not mirrored anywhere. A repo synced from GitHub is a mirror: GitHub stays the source of truth, pushes to the synced repo pass through to GitHub, and pull requests sync both ways. Icons in the codebase view tell you which is which. Detaching stops the sync and converts the copy into a standalone Origin-hosted repo.

04 How a job actually moves

A typical job moves like this.

Jamie surfaces a topic. James and Sage assemble the research, Sage nailing the official record, James carrying the overview. Hally pulls the X buzz and page-verifies what she can. GLM writes the draft and Mac files it unpublished with official screenshots only. Scott merges.

When the job involves changing code in a repo, the repo work goes to a cloud agent. The coordinator launches the agent against the Origin repo, the agent clones it in its own VM, branches, edits, commits, pushes, and opens a pull request on Origin, with artifacts like screenshots and logs attached so you can see what it did without checking out the branch. On a native repo that PR lives on Origin. On a GitHub-mirrored repo the PR syncs back to GitHub. Local Cursor, in this flow, is a viewer of the same Origin repo: clone or pull to get the files into a local checkout.

There is also a standing division of labor about where work happens. Do not clone a repo onto this box unless the user asked for it or the work genuinely cannot be done remotely. Narrow lookups, like checking one file or one PR, can go through the GitHub API or the web. Broader investigation belongs to a cloud agent in its VM.

05 What is not a live sync

Nothing in this setup live-syncs, and half the confusion about it comes from people assuming it does.

Local Cursor is not a mirror of the cloud agent’s VM. The agent works in its own isolated VM with its own clone. Your local checkout is a separate clone of the same Origin repo, and it only picks up the agent’s work when you pull. Files do not stream into a random local folder, and there is no editor session shared between the VM and your machine. If you want to see what the agent produced, you read the PR and its artifacts on Origin, or you pull the branch.

Empty repos have their own trap. An Origin repo created in the UI is empty, with a stored default branch name of main but no actual main ref until the first push. The official first-commit flow is clone, add files, commit, git push -u origin main. A cloud agent cannot resolve main on a zero-ref repo, so if you point one at a freshly created empty repo, do not expect it to branch off anything. Push something first.

Two smaller non-syncs. One, a coordinated job is not one shared brain: the teammate bots on this computer and the cloud agent on Cursor’s VM never share a session. Two, do not guess GitHub slugs from Origin slugs. The Origin namespace owner is not a GitHub org, and nothing in the docs promises they match.

06 Hard rules

These are the rules this shop runs by, stated flatly.

• Official sources beat buzz. cursor.com docs and changelog settle product facts; X settles nothing about how the product works.
• Do not invent quotes, permalinks, or engagement numbers.
• Do not invent neighbors: the products listed in the first section are not part of this system and do not get compared against it, and there is no comparison table here.
• Scott is the coordinator, not a cloud agent.
• Cloud agents need a repo plus a job, and they finish with a PR, not a lingering session.
• Local Cursor clones or pulls; nothing syncs on its own.
• Native Origin repos stay on Origin; mirrors still push to GitHub.
• Empty Origin repos have no main until the first push.
• Team roles stay distinct, Jamie through Mac, with Billy and the X scout outside the article loop unless asked.
• Quack is a shared query catalog, not storage.
• Grok Bot internals are not in cursor.com/docs and do not get presented as official.

07 X buzz (only verified)

Hally page-verified three posts on live X. These are the only numbers in this section.

The official launch post, @cursor_ai on Aug 17, 2026: Origin, our code hosting platform, is now live. It’s fast, easy to use, and deeply integrated with Cursor. Get started by syncing your repos from GitHub. 25K likes, 26.1M views. That is the conversation’s center of gravity, and it is a product announcement, not a review.

The follow-up, @cursor_ai on Aug 18, 2026, pushing the engineering post on Origin’s Git storage: 8K likes, 2.6M views. Bookmarks ran higher than likes on this one, which is people filing it, not arguing with it.

The one real independent with reach is @XFreeze on Aug 17, 2026, quote-tweeting the launch and noting that Cursor shipped its own code hosting the same day GitHub was down: 1K likes, 72.5K views. Most of the rest of the thread reaction was variations on that same timing observation and congratulations.

What is missing is the part this shop cares about: there is no page-verified user thread about cloud agents actually working on Origin repos. The agent side of the story is official copy plus restatements. Until someone opens a permalink showing a real user’s agent cloning, branching, and PRing an Origin remote, that box stays empty, and this page will not fill it with invented quotes.