When Agents Outnumber Editors

There is a ratio inside every content team that nobody tracks: how many things get written by people versus how many get written by software. For most teams that number was zero for a long time. Then it was a rounding error. Now, on a lot of teams, it has quietly crossed one to one.

Once agents outnumber editors, the shape of the job changes. Drafts become cheap and abundant. The scarce resource is the judgment required to decide what deserves to ship. If your workflow was built around the old bottleneck, it will break in a specific and predictable way: a queue of plausible-looking drafts nobody has time to verify.

The mechanics of what an agent is allowed to touch are a separate subject, and we covered those in AI Agent Write Access: The 4 Real Controls You Get With Your CMS, including the two controls we do not ship yet. This post is about what happens upstream of any of those settings: how the daily work of a content team reorganizes itself once the ratio flips, and which six operating habits have to change with it.

The ratio flips faster than the process does

A two-person content team with four agents running scheduled jobs can produce more drafts in a week than the two humans can carefully read. Reading a 1,500-word post closely, checking its claims against primary sources, and verifying its links takes real time. Generating it takes minutes.

So the throughput ceiling moves from writing to reviewing, and every process decision should follow that move. The goal is to make review fast and to make bad output structurally hard to publish.

Shift 1: scope becomes a commissioning decision

The most common mistake is giving one agent broad access to everything and hoping the prompt holds. Prompts drift. Keys do not.

When you spin up a new agent, treat its scope the way you would treat a job description rather than a configuration screen you fill in afterward:

• Write down the object types each agent is expected to touch, and put that list in its instructions. A social copy agent has no reason to touch your pricing page object, and it should be told so explicitly.
• Default every agent to draft output. Publishing should be a separate, deliberate action taken by someone accountable for it.
• Separate read keys from write keys in your environment. An agent that only summarizes traffic never needs a write key at all.
• Keep destructive operations off the table unless a human explicitly asks for them in that session.

Be clear with yourself about which of these are enforced and which are conventions. In Cosmic today, the enforced boundary is the key an agent holds: read-only or read-write across the bucket. There is no per-object-type permission setting, so "this agent only touches blog posts" is an instruction you give and a habit you audit, not a rule the platform enforces for you. That is exactly why the read-key/write-key split matters so much, and why draft-by-default carries real weight. We wrote up the current controls, and the ones we do not ship yet, in AI Agent Write Access. Capability-level detail for agents is on the AI agents page.

Shift 2: review becomes the throughput ceiling

Draft status is the cheapest safety mechanism you have. It costs nothing and it catches everything. The habit that has to change is calendar-level: review is now the work you schedule your week around, rather than a step you tack onto the end of someone else's.

That means the review queue has to be a real surface your team sees without remembering to check the dashboard. Pull it with the TypeScript SDK and render it wherever your team already works:

import { createBucketClient } from '@cosmicjs/sdk';

const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG!,
  readKey: process.env.COSMIC_READ_KEY!,
});

const recent = await cosmic.objects
  .find({ type: 'blog-posts' })
  .props('id,title,slug,status,created_at,metadata.author')
  .status('any')
  .sort('-created_at')
  .limit(25);

const reviewQueue = recent.objects.filter((post) => post.status === 'draft');

Approval is then an explicit write, with a key that only your review surface holds:

import { createBucketClient } from '@cosmicjs/sdk';

const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG!,
  readKey: process.env.COSMIC_READ_KEY!,
  writeKey: process.env.COSMIC_WRITE_KEY!,
});

await cosmic.objects.updateOne(objectId, {
  status: 'published',
  metadata: { last_updated: new Date().toISOString().slice(0, 10) },
});

Two details matter more than they look. First, read the object back after a write and confirm the field actually stored the value you sent. A write that reports success while dropping a field is the kind of bug that ships a post with an empty meta description. Second, use explicit object IDs for relationship fields such as tags and category. Slugs can collide across object types and resolve to the wrong record.

Shift 3: attribution becomes a weekly number

When five agents and two humans all touch the same bucket, "who wrote this" turns into an operational question you have to answer quickly. You need it to debug a bad claim, to retire an underperforming agent, and to answer the inevitable question about how much of the site is machine-written.

Cosmic Insights attributes traffic by the actor who created the underlying object, splitting results across human users, agents, and automations. That answers a question most teams cannot answer at all: is the agent-authored content earning attention, or just filling the index?

Run that report before you scale an agent up, and put it on the same cadence as your traffic review. An agent producing thirty posts a month that collectively earn less traffic than three human posts is a cost, and the fix is usually narrower scope rather than more volume.

Shift 4: the content model does the editing you no longer have time for

The content model is the only guardrail that applies to every writer equally, human or machine. A required field is required for everyone. A select field with five options cannot be answered with a sixth. Every rule you move into the model is a review comment you never have to write again.

Things worth encoding in the model rather than in a prompt:

• Required SEO fields. If seo_title and seo_description are required, no agent can ship a post without them.
• Character limits. A maxlength on the meta description enforces the limit at write time.
• Select options in place of free text. Category, content type, and funnel stage should be closed sets.
• A verification field. For anything that cites a third party, a required last_verified date makes staleness visible.
• Required relationships. An author reference on every post means attribution is always captured.

Every one of these turns a review comment you would otherwise write by hand into a validation error the agent has to resolve before the object saves. Given that write access is bucket-wide rather than scoped per type, the model is doing more enforcement work than most teams realize.

Shift 5: reversibility becomes a publishing prerequisite

When one person writes one post a day, a bad edit is a small, visible event. Somebody notices and somebody fixes it. When five agents run scheduled jobs against the same bucket, a single bad run can touch a dozen objects before anyone opens the dashboard, and the objects it touched are usually the ones nobody was watching.

So the question you have to be able to answer changes. Prevention still matters, and draft-by-default still catches most of it. What decides how calm your week is, though, is whether you can put content back the way it was without reconstructing it by hand.

Two controls do that work, and they behave differently:

• The audit log tells you what happened and who did it. It is included on every Cosmic plan, including Free. Retention runs 30 days on Free and Builder, 90 days on Team, 180 days on Business, and 365 days on Enterprise.
• Revision history lets you restore a previous version of an object. It is a per-Project add-on at $99 per month, or $199 per month for the bundle that also includes Webhooks, Localization and Automatic Backups. Retention follows the same ladder: 30 days on Free and Builder, 90 on Team, 180 on Business, 365 on Enterprise. Current details are on the pricing page.

The distinction matters when you are deciding what to buy. An audit log without revisions tells you exactly which twelve posts an agent damaged and gives you no way to undo it. Revisions without an audit log let you roll a post back and leave you guessing which agent did it and whether it touched anything else.

Two habits are worth adopting alongside them:

• Keep the number of agents holding a write key small. Every additional write key is another thing you have to reason about when something goes wrong. Read-only agents can be numerous and boring.
• Do the rollback once on purpose before you scale an agent up. Restore something you do not need, from a revision, on a normal Tuesday. Teams tend to discover the gaps in this the first time they try it under pressure, which is the worst moment to learn that the retention window on your plan is shorter than the gap between a bad run and the day somebody noticed.

Shift 6: cost becomes a governance surface

Agent output has a price attached, and it is the first signal you get that tracks volume rather than quality.

Every Cosmic plan includes a monthly token allowance: 300k in and 300k out on Free, 500k each way on Builder, 1M each way on Team, and 3M each way on Business, with custom limits on Enterprise. Above the allowance, top-ups start at $9.50 per million, and packs run $25 for 2M, $110 for 10M and $475 for 50M. Each plan also sets how many agents and workflows you can run, from 1 on Free up to 25 on Business. Semantic search queries consume tokens as well, although embedding your content for search does not, so you pay when you run a query rather than when you index.

None of that is expensive on its own. The reason to watch it is that it proxies for something you otherwise cannot see. A pipeline that drafts forty posts a month and publishes four is spending its allowance on thirty-six drafts nobody used, and the tokens are the cheapest part of that waste. The expensive part is the review time those thirty-six drafts consumed on the way to being rejected.

Put spend next to the attribution report from Shift 3 and read them together. Three questions fall out of it:

• Which agents produce output that ships? A high draft count with a low publish rate is a scoping problem, and the fix is a narrower brief rather than a better prompt.
• Which agents produce output that earns attention? Thirty published posts that collectively earn less traffic than three human ones are a cost, whatever the token bill says.
• What does one shipped, verified piece actually cost? That number, tracked month over month, is the one that tells you whether adding agents is working.

Reviewing this monthly is enough. The point of the exercise is to make retiring an agent a normal decision rather than an admission that an experiment failed.

The failure modes to watch for

Four patterns show up repeatedly once agent volume rises:

1. Near-duplicate content. Two agents, or the same agent on two runs, produce posts that target the same query. They then compete with each other in search. Search your own bucket before commissioning anything new.
2. Confidently stale third-party claims. An agent reuses a competitor price or feature limit from an older draft. The rule that fixes this is simple: any claim about another product must be re-verified against that vendor's live page in the same run that writes the sentence.
3. Invented specificity. Round numbers, benchmark figures, and customer counts that no source supports. Require a link next to every number.
4. Drift from the house voice. Individually fine, collectively recognizable as machine output. Keep an explicit list of banned constructions and check drafts against it.

A fifth one is worth naming because it caught us while writing this post: an agent describing your own product's capabilities from memory instead of from current documentation. The first version of this article claimed Cosmic could scope an agent's write access to a single object type. It cannot. Apply the same verification rule to your own product that you apply to competitors.

Each of these is an argument for putting the gate before publication rather than after a correction.

What this does to headcount

The interesting outcome is that the team does not grow the way you would expect. Output rises while headcount stays flat, and the roles that remain shift toward editing, verification, and deciding what to commission.

Customers describe the same pattern when a CMS stops requiring a developer for routine changes. As Maximilian Wuhr, Co-Founder at FINN, put it: "Cosmic is: us never having to ask a developer to change anything on the backend of our website."

If you do add a reviewer, the cost is predictable. Cosmic plans include a set number of team members (Free includes 2, Builder 3, Team 5, Business 10), and additional users are $29 per user per month. Current plan details are on the pricing page.

Getting started

If you are heading toward this ratio, the sequence that works is: tighten the content model first, make draft the default second, build the review queue third, and add agents fourth.

Cosmic gives you the pieces for all four. The headless CMS provides the content model and validation, the REST API and TypeScript SDK provide the review surface, the MCP server connects Claude, Cursor, or any MCP client directly to your content, and Insights tells you whether any of it is working. If you want the specific permission controls behind all of this, we documented each one and how to verify it.

Start free with a Cosmic account, no credit card required. If you want to talk through how this would work for your team, book time with our CEO.