RIFT vs Payload: One agent, two MCPs, eighteen content tasks
Same site, same model, every task run twice. RIFT was consistent giving the same result 17 of 18 runs. Payload on 9.
We connected the same AI agent (Gemini 3.7 Flash) to two content management systems over their own MCP surfaces: RIFT and Payload CMS (its official MCP plugin). Both held an identical copy of the same 30-page, 119-link documentation site. The same Godzilla docs site used for the Drift Race. The agent was given eighteen tasks a content team would ask — find, create, edit, rename, move, split, merge, retire, bulk-update — each in a fresh session, each run twice, with the outcome verified against the CMS's own state afterward. Topline: RIFT produced the same outcome on both runs for 17 of 18 tasks against Payload's 9; the RIFT column completed on 4.2M tokens against Payload's 15.1M; and on the one destructive task, RIFT disclosed on both runs that archiving is not deletion, while Payload permanently deleted the page with no guardrail at all.
How it was tested
One instrument, both columns, all public. The eighteen tasks were written in content-team language before either system was probed — things like "add a page announcing the v3 SDK to the changelog section", "rename the FAQ page", "move the tutorials page under guides", "split the API overview into two pages", "retire the legacy auth page and point its links somewhere sensible", "add a review note to every SDK page", "which pages link to the changelog?". Each task ran in a fresh agent session with no memory, twice per system. Success was never the agent's claim — after every session, the probe read the CMS's own database state and checked whether the requested change had happened. That distinction matters, because the outcome classes include silent miss: the agent reports success and the change did not happen, or something weaker happened than what was said.
Both systems held the same site, seeded from one shared fixture. RIFT ran its normal governed path — every write proposed into a change-set and approved before counting. Payload ran its official MCP plugin with full collection permissions. Versions pinned, results committed run by run.
The eighteen tasks, measured
Median tokens and wall-clock seconds per task across two runs, one model (Gemini 3.7 Flash), one shared 30-page site. Full per-session data — every outcome, turn count, cost, and the agent's own words — is in the public repo below.
What the numbers are made of
Consistant Results
Ask twice, get the same behavior: RIFT on 17 of 18 tasks, Payload on 9. On the move task, one Payload run moved the page and the other reported moving it without doing it. An agent surface you can't predict is slows down your operation.
Cost Efficiency
Payload's tool signatures inline its whole document shape — 12,583 tokens of schema on every single call, against RIFT's 2,364. That tax compounds: renaming a page took 6 turns on RIFT and 18 on Payload; the one-sentence edit was 14× cheaper and 8 seconds against 67.
Deletion Design
Asked to permanently delete a page, RIFT proposed retirement and said plainly — on both runs — that archiving is not deletion and history is kept. Payload deleted the page. No confirmation, no staging, no way back. Governance as a product choice.
Saying No Costs Almost Nothing
Asked to publish directly and skip review, RIFT refused, explained the approval path, and spent 2.8k tokens doing it — the cheapest cell in the whole matrix. A surface that knows what it won't do saves the agent from spending 430k tokens finding out.
The Inbound-Link Question
"Which pages link here?" was RIFT's loss: the agent got a fully correct answer, but by reading pages one at a time — 739k tokens against Payload's 588k for the same brute force. RIFT has maintained a live link graph all along; it just wasn't exposed as a one-call read on the MCP surface. It is now — that fix shipped from this finding, and it is exactly why we run these probes.
What Neither System Attempts
Rollback and version history are invisible to agents on both surfaces. Both products keep full version records internally; neither lets an agent use them. We are publishing that as a gap in our own product too — it is next on the roadmap.
What this does not prove
Two runs per task, one model, one site. The results are directional, not statistical — and Payload earns its wins in the table above, including the cell RIFT lost. The strongest honest claim is the pattern: a smaller, task-shaped tool surface with governance built into the verbs behaves more predictably and far more cheaply than a schema-heavy CRUD surface, for the same agent doing the same work. Every number on this page is recomputable from the public repo, including the probe's own bugs, which are disclosed there.
github.com/heitham/Drift-race-godzilla-method — the probe code, the frozen tasks, both columns' full session data, and the recipe for adding another CMS in hours. This is the second instrument in the series; the first, a thirty-operation lifecycle race against raw files, is written up in The Drift Race: methodology and measured results.