Define AI seat incrementality before the category does

Invent the proof grammar before you invent the lift story.

The misunderstanding

"AI seats" still read as wrappers or chatbots to a lot of buyers. Tickets closed, messages sent, autonomy percentages on a vendor dashboard. That is activity theater, not ops proof. The anxiety underneath is plain: did the seat move anything that matters, or did it just look busy?

Media buyers already lived a version of this. When a channel is new and mistrusted, the first credible move is not a bigger spend story. It is a proof grammar: what you measure, against what baseline, with whose numbers. AppLovin's Ridge case used that arc for media incrementality (misunderstood channel, named method, then lift), with Haus as a third-party co-validator. We are not copying their academy IA or their case layout. We are stealing the shape for a different product: buyer-side proof for AI seats, before a Haus-for-agents vendor exists.

Chat UX patterns do not transfer to production seats either. A helpful chat session is not a governed ops loop. If your seat brief still sounds like a chatbot prompt with a headcount fantasy attached, you are buying theater with a new label.

The category will invent a weaker standard if you wait. Define yours first.

Write the Outcome Spec first

Name what winning looks like before the seat starts. An Outcome Spec is the contract, not a slide.

Write it in language a client analyst can verify:

1. Outcome. The business metric the seat is allowed to move (resolution rate on a named queue, cycle time on a named workflow, error rate on a named handoff). Not "be helpful."
2. Baseline window. The period and population you measure against before the seat is live, or before this seat variant is live.
3. Holdout or control. Where honest: geo, cohort, queue split, or time-boxed control. If you cannot hold out cleanly, say so and shrink the claim.
4. Metric owner. Client analytics, not the agent's self-report and not the vendor's glow dashboard.
5. Pass / fail threshold. What delta vs baseline counts as success for this phase. What the learning phase looks like before you judge.
6. Off-limits. What the seat is not allowed to optimize (vanity volume, gaming the scoreboard, tools outside the allowlist).

If you cannot fill those six lines, you do not have a seat ready to claim lift. You have a demo. Put the Spec in the SOW and in the onboarding packet. Everyone who touches the seat should be able to point at the same sheet.

Name the method

The Spec is the what. The method is how you keep the seat from grading its own homework.

Lock four pieces next to the Spec:

1. Eval harness the agent cannot write. Golden cases, regression suites, and human review samples live outside the agent's write path. The seat may propose answers; it does not own the score.
2. Tool allowlist. Deny-by-default before network or high-blast tools. See Deny-by-default before you give the agent a browser. The allowlist is the seat contract; everything else is a change request.
3. Scoreboard outside the agent. Metrics and scorers sit where the agent cannot update them. See Take the scoreboard away from the agent.
4. Discrepancy norms. Platform activity and client analytics will disagree. Teach the buyer which gap is normal and which gap means the Spec is being gamed. Publish the challenge path in the SOW: how the client disputes a vendor number.

Name the method in the same doc as the Spec. Buyers should be able to fail a bad vendor (including you) with the checklist you hand them. That is the trust moat, not a feature matrix. Wrapper vendors fail this checklist on contact. That is the point.

What lift means (and what it does not)

Lift is Spec-delta vs baseline under the named method. Nothing else.

Ignore seat CTR-equivalents:

• Messages per day without a Spec.
• Tickets touched without resolution quality.
• Autonomy percentages that the agent or vendor dashboard invents.
• Prompt volume as a proxy for ops value.
• "Learning" stories with no baseline window and no pass / fail line.

Public lift claims wait for client-verifiable numbers. This note withholds a metric-in-H1 on purpose. When a cleared pilot exists, retrofit a proof card with the real delta. Until then, invent the grammar, not the percentage.

If a vendor leads with activity glow and no Outcome Spec, treat that as the tell. They are selling theater. Ask for the Spec, the baseline, the metric owner, and the discrepancy norms. If they cannot produce them, you already have your answer.

Product fit (light)

On our desk, Full OS is the ops layer where Outcome Specs, eval cadence, and client-verifiable loops live. Maddy carries the ops proof rhythm: baseline, harness, review cadence. Addy is secondary here: craft loops and experiment volume once the Spec is honest. This note is not a product brochure. The grammar stands without the stack. The stack only matters when you want the Spec enforced in production seats, not in slides.

Also on the desk

• Take the scoreboard away from the agent. Keep the metric and the scorer outside the agent's write path.
• Deny-by-default before you give the agent a browser. Tool allowlists and human gates before network reach.

If you want an Outcome Spec on the seat before anyone claims lift, a governed AI development path, and a scoreboard the agent cannot write, Start your build or write hello@mail.22atlas.com.

Linked sources

• Related Field note: Take the scoreboard away from the agent
• Related Field note: Deny-by-default before you give the agent a browser
• Evidence / strategy cut: AppLovin to 22Atlas alpha (Ridge arc as media proof parallel only; no academy IA clone)