If you use Cursor, you already trust one agent with real work: it reads your code, makes the change, and hands it back for you to check. I'm Alex, one of the two people building Operum. This post explains what changes when that one agent becomes a team working on your own repository, and how it stays on your own Cursor account.

One agent vs. a team

A single agent is great at a task. It's less good at the work around the task: deciding what to build, planning it, checking it independently, and keeping a record of what happened. You end up doing all of that yourself, in your head and in chat.

Operum is a desktop app that gives you a team with six roles: PM, Architect, Engineer, Tester, Marketing and Community. They work through GitHub, the way a human team would: issues, labels, branches, pull requests and CI.

A typical loop:

  1. You tell the PM what you want, in plain language.
  2. The PM files an issue. If it needs design, the Architect writes a plan first.
  3. The Engineer builds it on a branch and opens a PR.
  4. CI runs.
  5. A separate Tester agent reviews the change and approves the exact commit it checked.
  6. The PR merges, either when you click Merge or, if you turn on auto-merge, when the PM merges it after QA.

Workflow board with issues in Backlog, Architecture, Ready for Dev, In Progress, QA Testing, Ready to Merge and Done
The Workflow board. Each column belongs to a role. Screenshot from one of our own Operum projects; names and handles blurred.

Your Cursor account, your repo

Cursor is the default engine for a new Operum team. Operum drives Cursor's command-line agent with your own Cursor sign-in, and the agents work in your own GitHub repository. There's no separate AI account to set up for this path, and your code stays where it already lives.

A model per role

Every agent has its own model setting. With Cursor as the engine, the picker lists the models your Cursor login can use, and it marks any model that is outside your plan's included usage, so you know before you pick it.

A setup I like:

  • Architect on Grok for planning: reading the issue, the code around it, and writing the design before anyone touches a file.
  • Engineer and Tester on Composer for the build-and-check loop.

If you don't choose, an agent starts on the default (Composer, when your Cursor CLI lists it).

The Architect's settings in Operum: AI Engine set to Cursor, model set to Grok 4.7 Medium
The Architect's Settings tab: Cursor as the engine, Grok 4.7 Medium as the model. Screenshot from a current development build of Operum, cropped to the engine and model sections.

Diagram: one Cursor account, a model chosen per role. Grok on the Architect, Composer on the other five roles
Diagram (designed): an example setup, one model per role.

The Tester is the gate

This is the part that matters most to me. A merge needs green CI and the Tester's approval of the exact commit being merged. If the Engineer pushes again after the Tester approves, that approval doesn't carry over: the Tester has to look again.

The Tester also says what it didn't verify. "All checks passed" is easy to write. "These three behaviours aren't covered by any test, and here's how to check them by hand" is what I actually trust.

An issue with the engineer's local checks, the CI result and an explicit list of what no test covers
An issue with its linked PR, ending in a "not covered by any test" list. Handles and a package name blurred.

When we counted our own 12-day run, 280 of 296 merged PRs went through that Tester approval. The other 16 were almost all the team's own audit-record files, which skip QA by design.

You supervise from a cockpit

None of this runs on its own without you. You decide what gets built, you answer the decisions the PM brings you, and you merge, or switch auto-merge on for a team when you're comfortable. Marketing and Community draft the planned posts and public replies, and those wait for your approval before they go out.

The founder types "Merge"; PM reports the PR merged and the issue closed, and lists what is still unverified in production
One word from me, and the PM still names what hasn't been checked in production.

What's rough

  • Windows: agents currently run without an OS-level sandbox on Windows, so Operum can't limit where they write files there.
  • Model list: Operum shows what Cursor's CLI lists for your login. If Cursor renames or removes a model, an agent set to it falls back to the default, and the picker tells you.
  • Small PRs, lots of them: a team produces more PRs than you're used to reviewing. The Tester's "not covered" list is what keeps that manageable.

Try it

We're launching Operum on Product Hunt on Tuesday, November 10. If you already like one agent in Cursor, I'd love to hear what happens when you give it a team. Try it on a real repo, and tell me honestly where the loop breaks for you.

— Alex