The Verified Operator

Viral AI cheatsheets are how most professionals now learn what frontier models can do — and they are almost never checked. We took two of them apart claim by claim. Some of it is invented. More of it is true than a skeptic would guess. This sheet is the corrected, sourced version: what frontier agents actually do, the operating patterns that hold up, and the ledger showing our work.

01 — Why this sheet existsThe cheatsheet economy runs on trust nobody earns

The material that reaches your feed is engineered for saves and shares: dense grids, confident numbers, a call to comment for the "full guide." The format is fine — the problem is that nothing in it is sourced, and capability claims about AI age in weeks. Repeating them unchecked is how teams end up with strategies built on features that do not exist, or — just as costly — dismissing capabilities that are real and documented.

ImageFirm's position is narrow and useful: we publish what survives verification, we show the ledger, and we correct in both directions. This sheet's own sources surprised us twice — claims we expected to debunk turned out to be documented by primary sources. That is the point of the method. Skepticism is not knowledge; a checked record is.

02 — The capability recordWhat frontier agents verifiably do, August 2026

Checked against Anthropic's release notes, platform documentation, and named customer reports for the current frontier tier (Claude Fable 5, the generally available Mythos-class model):

• Long-horizon autonomous work. Run in an agent harness, the current tier plans across stages, delegates to sub-agents, and checks its own output over sessions measured in hours to days — the vendor's own framing, and the axis on which it claims the largest gains.
• Migration-scale coding. Stripe reported a migration across a 50-million-line Ruby codebase completed in roughly a day, against an internal estimate of two-plus engineer-months. A named company, on the record, in the vendor's launch materials — the strongest public datapoint yet for long-horizon coding.
• Vision good enough to operate software. The same tier completed Pokémon FireRed start to finish from raw screenshots only — no maps, no helper tools. A game is a benchmark, not a business case, but the skills it demonstrates (reading dynamic interfaces for hours, holding goals, recovering from mistakes) are exactly what screen-operating agents require.
• Goal-conditioned running. Modern agent harnesses can hold a completion condition and keep working until it is met — in Claude Code this is the documented /goal command — alongside scheduled recurring runs for watch-and-react work.
• Teachable, portable procedure. Skills — folder-based, documented instructions the agent loads on demand — let you teach a workflow once and reuse it across sessions and teams.

03 — Operating patternsThe patterns that hold up in real work

Plan with the strong model, execute with cheap ones, verify with the strong one again

The community calls this the barbell. The idea is sound and matches how serious harnesses are built: frontier-tier judgment at the two ends where it pays (decomposing the problem, auditing the result), faster and cheaper models for the bulk work in the middle. The ratios you see quoted — ten, eighty, ten — are a preference, not a specification. Tune to the task; keep the shape.

State the finish line, not the steps

Goal-conditioned running changes the unit of delegation from "do this step" to "reach this condition." It rewards operators who can write a testable definition of done — ship the refactor with tests green — and punishes vague ones. If you cannot phrase the condition, you are not ready to delegate the task.

Teach once, in files the system actually reads

The documented context mechanisms are the ones that persist: a project instructions file (CLAUDE.md) the agent loads every session, skills for repeatable procedure, and the harness's own memory features. Influencer systems built from personally named files and folders can work — the agent will read what you point it at — but they are conventions of one author, not the platform, and they travel badly across tools and teammates. Prefer the canonical mechanisms; document anything custom.

Let it see

Vision is the most underused capability in practice. Screenshots of the broken state, the dashboard, the competitor's page — dropped directly into the session — consistently outperform prose descriptions of the same. If your workflow never shows the model an image, you are operating below the tier you are paying for.

04 — The operator's methodAnalysis in eight moves, any capable model

One of our source blueprints packaged a business-analysis workflow as tool-branded prompt templates. Underneath the branding is a sound, standard sequence — it maps cleanly onto textbook business-analysis practice. Here is the method, tool-neutral, with the verification step the viral version leaves out attached to every move:

1. State the problem. Feed the raw situation in; ask for the problem restated in one clear sentence plus the key context. VerifyDoes the restatement match what the sponsor would sign? If not, the error compounds from here.
2. Map the stakeholders. From the project context, ask for a map of roles, influence, needs, and concerns. VerifyWalk the map past one insider; models infer org charts they cannot see.
3. Plan communication. Frequency, channel, and key message per stakeholder group, drafted from the map. VerifyCheck the cadence against real calendars — generated plans love meetings nobody will attend.
4. Plan the information gathering. Ask for an elicitation plan: workshops, interviews, document pulls, matched to what each can actually yield. VerifyConfirm access and availability before it becomes the schedule.
5. Capture raw insights. Discovery notes in, organized themes out — requirements, pain points, opportunities. VerifySpot-check three themes against the source notes; summarization drifts.
6. Make sense of the data. Group, deduplicate, and surface gaps and conflicts across the raw requirements. VerifyThe conflicts list is the deliverable — read every item; false conflicts burn goodwill.
7. Agree scope and priorities. Propose a solution scope with high-value items first, from the analyzed set. VerifyPriorities are a human decision. The model proposes; the sponsor disposes.
8. Write the plan. Approach, deliverables, timeline, risks, governance — assembled from everything agreed above. VerifyTrace each commitment back to an agreed input. Anything untraceable is fiction with formatting.

05 — The ledgerTwelve claims, checked

Claims paraphrased from the two source blueprints. Verdicts: VERIFIED primary source found · NUANCE substantially right, overstated or underspecified · NO SOURCE no primary source located — do not repeat.

06 — Operating ethicsThe rules this library publishes under

• Provenance or silence. A capability claim gets a primary source or it gets labeled unverified. No third option.
• Correct in both directions. Debunking is as cheap as hype. Two of the claims we expected to kill in this sheet survived contact with the record.
• Source material stays private. Sheets like this one are original writing; the blueprints that prompted them are never republished.
• The model proposes; the operator disposes. Every workflow above ends in a human verification step. Delegation without a definition of done, and publication without a check, are the two failure modes this entire library exists to prevent.