Cursor as ops console — rostered AI teammates + skills

I run the operations of a small e-commerce company from a code editor. An AI agent, a repository full of scripts and a folder of written rules turn out to be a good operations console. Since mid-July every agent task has been logged, so instead of describing the setup in the abstract, this post reads the log: 12,131 tasks, 603 multi-step workflows and 17,859 cost lines. Some of it worked as designed. Some of it says the design was weaker than I thought.

The setup in one paragraph

Work is owned by a roster of ten named AI teammates: marketing, tech, design, product, support, a senior proofreader, a family-buyer review lens, business development, finance and strategy. Each has a stored profile that is prepended once per task. Rules live in a folder of small files, one per lesson, loaded always or on request. Repeatable workflows (adding a product, writing a manual, testing links) are written up as skills. Three coding agents share the repository through separate git worktrees and only main ships. Every task is logged with an owner, a stable source id, and for multi-step work a workflow id and a step name.

What the log contains

Outcomes: 11,763 completed, 154 failed, and 214 that were started and never closed. That last number matters more than the failures, and I come back to it below.

The scheduled jobs are the quiet majority. A third of all logged work is the company running itself overnight — price guards, order pulls, review crawls — attributed to the teammate who owns that area. That is the part of the setup I would copy first: a job that logs under an owner shows up in that owner’s weekly view, so nobody has to remember it exists.

Finding one: a default owner swallowed a third of the log

The editor hook logs every agent session automatically. When a session has no explicit owner it falls back to a default, and the default was the strategy persona. Result: 4,016 tasks titled “Cursor agent session” sitting under strategy, which makes strategy look like the busiest teammate by a wide margin. It is not; it is the bucket for “unknown”.

This is the same mistake as an “Other” category that grows until it is the biggest slice of a pie chart. A catch-all default is useful for not losing data and harmful for every metric built on top of it. Two fixes are better than one bigger default: log the unattributed sessions as an explicit unassigned owner so they are visibly unknown, and attribute at the moment the session states its task (we already prefix task descriptions with the teammate name, so the hook can parse it).

Finding two: the review gate is a convention, not a gate

Public copy is supposed to flow draft → buyer review → proofread → revise → approve → publish, with each step logged as its own task under one workflow id. The log lets me check how often that really happened:

Some of the eleven were probably proofread and just not logged. That is exactly the problem: a log that depends on the agent remembering to write it cannot prove the review happened, and a rule that says “always proofread public copy” cannot stop a publish. The step that can enforce it is the publish script itself: refuse to publish a workflow that has no completed proofread task, the same way the deploy script refuses to ship uncommitted code. Every rule in this setup that actually held is enforced by code at a choke point; every rule that drifted is enforced by memory.

Finding three: started is not done

214 tasks were logged as started and never closed, 210 of them by agents logging through the API. The pattern is easy to picture: the agent logs “started” at the beginning of a turn, the turn ends in a question or an error, and nothing logs “completed” or “failed”. October alone has 78. An open task is worse than a missing one because dashboards count it as in progress forever.

The fix is boring: a nightly sweep that closes anything started more than 48 hours ago as abandoned, plus a rule that the agent re-logs the same source id at the end of a turn whatever the outcome. The upsert on a stable source id is what makes that cheap.

Finding four: costs do not join to work

The design says every API cost line carries the task’s source id, so a workflow page can show what it cost. Of 17,859 cost lines, 54 join to a logged task. Almost all of the rest are estimated costs written by automated jobs — comment moderation with a vision model alone accounts for more than half the lines — and those jobs never had a task to point at. Cost by provider and by teammate works; cost by piece of work does not. If I wanted the latter, the jobs would need to open a task per run and pass its id to the cost logger, which is a two-line change per job.

The rules folder

There are 124 rule files. 37 of them start with a dated origin line naming the incident that created them: 19 from July, 10 from August, 8 from September. The falling count is the closest thing I have to a learning curve: the same classes of mistake stopped generating new rules. Here is one, shortened:

---
description: Live-test every customer-facing link before any send
alwaysApply: true
---
# Campaign link test - before every send
Origin: a claim URL was emailed with an undeployed route (live 404).

## Hard gate
For every distinct URL in the message:
1. HTTP-check the exact string customers receive (after short-link wrappers).
2. Follow up to 5 redirects; final host/path must match the intent.
3. Money / checkout CTAs: one real browser open.

The honest caveat is that 124 files is a lot of context. Most are scoped to file patterns or loaded on request through an index, but the always-on set is still large enough that it needs pruning. A rule that is never relevant still costs tokens on every call.

Skills are under-used

There are 12 written skills. Tasks can record which skills they used, so the dashboard can show which workflows carry the load. Only 267 of 12,131 tasks (about 2%) recorded any. So the dashboard cannot yet tell me which skill deserves investment, which was the point of recording them. Same lesson as the review gate: if recording is optional, it will mostly not happen.

Key takeaways

1. Make the default owner visibly “unassigned”. A catch-all default that is a real teammate silently corrupts every per-owner metric. Attribute from the task description at log time.
2. Enforce review at the publish choke point, not in a rule. Have the publish script refuse a workflow with no completed proofread task; logs written from memory cannot prove a gate held.
3. Close every started task. Upsert on a stable source id at the end of every turn whatever the outcome, and sweep anything open for more than 48 hours to abandoned.
4. Give automated jobs a task id per run. Otherwise cost lines join to providers and owners but never to the work that caused them.
5. Count your rules by origin date. A falling rate of new incident rules is a cheap signal that the system is learning; a rising always-on rule count is a signal to prune.

If you want to copy it this week

• Create one table: owner, title, status, source id, workflow id, step, started, ended. Log from your scheduled jobs first; they are the easiest win.
• Add an unassigned owner and a nightly query that reports its share. If it is above 10%, fix attribution before trusting any per-owner chart.
• Pick your one public-facing publish script and make it check for a review record before it runs.
• Write your next incident as a rule file with a dated origin line; in three months, count them by month.

Closing

The editor is just the window. The leverage comes from ownership, written rules and scripts. The log adds the part I did not expect: it shows which of those rules are real (enforced by code) and which are hopes (enforced by memory). The structure is published in the open Agentic Company playbook.

— Alex