06-reference

every bread in ai sandwich

Tue Apr 21 2026 20:00:00 GMT-0400 (Eastern Daylight Time) ·reference ·source: Every (Context Window) ·by Laura Entis

“You’re the Bread in the AI Sandwich” — Laura Entis (Every / Context Window)

Why this is in the vault

Sharpens the human-in-the-loop frame from “review the AI’s work” to “you ARE the load-bearing layers — framing on the front, judgment and taste on the back; the AI is only the filling.” The Plus segment (one-Claudie-with-plugins vs many-discrete-agents) is a direct preview of the org-design question RDCO’s agent-deployer thesis has to answer for clients.

⚠️ Self-promo / curation bias

Not third-party sponsored. But the issue heavily promotes Every’s own products (Sparkle, Cora, Spiral, Monologue, the AI & I podcast) and Every’s in-house “compound engineering” methodology authored by Kieran Klaassen (Cora GM). When Entis links to “compound engineering” or “Claudie” she is linking to Every-internal IP, not external curation. Read the framing as advocacy for Every’s product worldview, not neutral synthesis.

The core argument

Three layers in a knowledge-work AI workflow:

  1. Front bread (human) — planning, framing, problem diagnosis. Generating multiple candidate solution paths.
  2. Filling (AI) — execution. Multi-hour deep work, code generation, drafting.
  3. Back bread (human) — review, judgment, taste. Deciding whether the output matches the intended vision; the layer that separates art from “generic slop.”

Maps onto Klaassen’s Plan / Work / Review / Compound loop — AI dominates Work, humans own the other three. Entis’s contribution is the sandwich metaphor: making it visceral that removing either bread layer doesn’t give you a faster sandwich, it gives you no sandwich.

Issue contents — Plus segments

Trust batteries (Tobi Lütke / Shopify origin, applied to AI agents): the metaphor that trust is a stored quantity that gets depleted by surprises and recharged by predictable behavior. Applied here to human-agent working relationships — agents that surprise you (in either direction) drain the battery; the goal of agent design is predictability, not just capability. Note: founder’s brief mentioned Marquet/Halligan; the actual concept origin is Lütke. Worth clarifying in any vault concept article.

How many agents we’ll have in the future (“Now” / “Next”): Every’s own internal experiment with “Claudie” — a Mac-based consulting-workflow agent built by Nityesh Agarwal — converged on plugins inside one agent rather than spawning new agents per capability. Entis frames the open question as: will the equilibrium be per-worker personal agents (one Claudie per person, plugins for everything they do) or centralized super-agents with department-specific plugins serving many workers? The “Next” deep-dive is paywalled.

Mapping against Ray Data Co

Strength: strong. Two load-bearing connections:

  1. Sandwich metaphor sharpens the verification-layer pitch. The RDCO positioning has been “deterministic verification is the defensible asset.” The sandwich frame gives a customer-facing version: “you’re not paying us to install the AI, you’re paying us to engineer the bread — the framing layer that decides what the AI works on, and the verification layer that decides whether to ship its output.” When pitching, the sandwich lets a non-technical buyer hold the whole concept in one image. Cross-link to 2026-04-20-every-ai-autopilot-verification-decay — Sarkar et al. is the empirical case for why the back-bread layer matters; this issue is the metaphor that makes it sellable.

  2. Agent-architecture question is THE strategic decision for clients. The “one agent with plugins vs many discrete agents” choice maps directly to the operating-model question every prospect will ask once they’ve decided to deploy. RDCO’s current implicit answer (visible in this skill library: many narrowly-scoped skills inside one Claude instance, orchestrated via TaskList) is the plugins-in-one-agent path. Worth making this an explicit position rather than an emergent default — and worth a concept article on the trade-off (latency, context budget, observability, blast radius of failure).

Gap surfaced: trust-battery as a design constraint for agent UX hasn’t been formalized in the vault. Predictability > capability as a near-term agent-design heuristic is consistent with the broader RDCO bet (verification > raw model power) but should get its own concept page before it shows up in client-facing material.

Curation section — notes

Deep-fetches performed: 0 (paywalled “Next” segment skipped per skill rules; all curation links were Every-internal or generic).

Tracked-author candidates

Article body summarized via WebFetch extraction; Gmail MCP returned snippet-only. No direct quotations included. All concepts paraphrased; “trust battery” is Tobi Lütke / Shopify terminology, “compound engineering” is Kieran Klaassen / Every terminology — both used as reference, not original to this issue.