Every (blair.dowding@gmail.com)

Inside OpenAI’s Race to Reinvent Software Development for the Agent Era

Laura Entis — 2026-07-27 16:09:01 -0400

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Software development is about to change in ways many teams outside the frontier labs haven’t had to think about yet. Our new interactive piece, “Before the Deluge,” shows what that looks like from the inside.

We spoke with six members of OpenAI’s infrastructure team—including its vice president of applied infrastructure engineering—about three converging pressures: an overwhelming surge of AI-generated code, software-development infrastructure pushed to its limits, and a fundamental redesign of how code gets reviewed and kept reliable.

What they’re working through now is a preview of what’s coming for software development everywhere.

“Before the Deluge” reveals how those pressures interact, what the engineers are doing to hold the system together, and what the broader software community will need to reckon with as AI-generated code becomes routine. It’s a close look at a stress test already underway—at one of the organizations most responsible for accelerating it.

Read it here

Laura Entis is a staff writer at Every. You can follow her on LinkedIn.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

Sometimes You Have to Delete Everything

Every Staff / Context Window — 2026-07-26 08:19:41 -0400

by Every Staff

in Context Window

Hello, and happy Sunday! Vibe Checks are always a journey filled with unexpected twists and turns. As we worked with the Anthropic team to test what was Opus 5, deadlines shifted, release candidates changed, and the model kept fighting the setups we’d built for earlier versions of Claude. It’s exhausting and exhilarating. So when some of the Every New York team caught The Odyssey the morning before the model launch, the parallel wasn’t lost on us. Scroll down for the full Vibe Check and everything else we published this week.—Kate Lee

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Knowledge base

“Claude Opus 5 Is Brilliant in Flashes, Frustrating in Practice” by Dan Shipper and Katie Parrott/Vibe Check: Claude Opus 5 is brilliant in flashes and frustrating in practice—it builds strong software and grinds through bugs for hours, but its best work often requires tearing down the systems you already rely on. It doesn’t reach Fable’s ceiling or match GPT-5.6 Sol’s day-to-day ease. Read this to decide whether Opus 5 is worth making room for—and what you’d have to change to use it well.

“How Every’s Team Used AI to Ship Its Biggest Launch Ever” by Laura Entis/Context Window: Our All Access launch drove the biggest revenue gain in company history—roughly $9,000 in two days. Every COO Brandon Gell hands the mic to three of our colleagues the builders behind the record-setting All Access launch—growth engineer Yash Poojary, head of growth Austin Tedesco, and head of marketing Douglas Brundage—to walk through the tools they build with and their advice for anyone starting out. Watch or listen to learn how an AI-native team turns ideas into shipped products. 🎧 🖥 Listen on Spotify or Apple Podcasts, watch on YouTube, or follow the discussion on X. Also inside: OpenAI’s Romain Huet and Dominik Kundel share a playbook for getting started with Codex, Marcus Moretti cuts Fable’s token spend by delegating to a cheaper sub-agent, and “the daily driver,” a running list of the models the team is using this week, debuts.

“Why Some AI Workflows Stick—And Others Don’t” by Katie Parrott/Working Overtime: After abandoning an “Attention Desk” clone of Dan’s Tend, Katie stopped treating it as a personal failing and ran a post-mortem on why some AI workflows stick and others don’t. She found that a workflow survives or dies on what it asks of your time, energy, and sanity versus what it gives back. Read this to get the four questions she uses to decide which workflows to keep, redesign, revisit, or retire.

“Drowning in Demos? Here’s a Better Way to Prototype” by Hilary Gridley: AI let Hilary’s product team at Whoop build prototypes in an afternoon—so they built too many, with no way to sort the keepers from the noise. Her argument is that once building is cheap, a prototype’s job is to test whether the problem is worth solving, and the only honest verdict comes from people using it, not stakeholders reacting to a demo. Read this to see how Whoop put that to work with a 12,000-member beta group. 🧑‍🏫Sign up for Hilary’s self-paced Maven course, How to Become a Supermanager With AI, and receive a 15 percent discount. (This piece was produced in partnership with Maven.)

Steal this workflow

How Notion builds Notion with AI

Ryan Nystrom, a software engineer on Notion AI, starts coding tasks by talking through them. Speaking lets him add the nuance, corrections, and context that tend to disappear when he compresses an idea into a short written prompt.

In this video, Ryan shows Dan how that spoken brief becomes a sourced Notion task, a working pull request, and a review loop that catches bugs and maintainability problems before a person reviews the code.

Ryan talks through a model-picker migration. Notion AI explores the codebase and turns his explanation into a task with code pointers, requirements, constraints, and verification steps.
He hands that task to an agent, then runs a custom review swarm across the front end and back end. The agent opens a pull request, watches the tests, fixes failures, and returns with passing code while Ryan is in meetings.

Here’s how you can get started:

Talk through the work before you write the brief. Explain the goal, relevant context, constraints, and what a finished result should look like.
Ask an agent to research the relevant sources and turn your explanation into a structured task with requirements and verification steps.
Review the plan, then hand the task to an agent that can work in the target environment.
Save recurring review standards as a reusable skill. Ryan built his review swarm by asking Codex to study existing skills and turn his preferences into a new one.

Ready to try Ryan’s workflow? Upgrade to Every All Access and get six months of Notion Business through the Builder Pack for eligible workspaces. All Access members can redeem more than $7,000 in partner offers.

From Every Studio

A new Cora brief experience is coming soon

Kieran Klaassen, general manager of Cora, rebuilt Briefed—its digest of everything that isn’t urgent—into a two-pane reader: the Brief on the left, emails opening on the right, as in the inbox. You can now set how much you want per category (either a full summary or a short snippet), give old promotions and newsletters an auto-clear window so they tidy themselves up, and bulk unsubscribe without leaving the brief. Kieran Klaassen has set the open beta for August 4, when active users get an email and an onboarding link. Take a look at cora.computer.

Every Agent browses the web for you and onboards itself

Every Agent, the AI coworker Every is building inside Slack, can now act on public websites for you: It logs in, fills out forms, and stops for your confirmation before it does anything one-way—like making a purchase. It also onboards itself now. Reply “yes” to it, and it reads your channels and identifies three tasks it could take off your plate—and any teammate can start that, not just whoever installed it. Every Agent is in private alpha while the team hardens connections before an external beta. Watch this space.

Alignment

The expertise trap. How does arguably the most brilliant mathematician of this century use AI?

Quite simply.

I opened Terence Tao’s conversation with ChatGPT about Fable’s counterexample to the notorious Jacobian conjecture, an 87-year-old problem that has long stumped the mathematical community. I half-expected beautiful, elaborate prompts I could steal for my own AI use. Instead, Tao asks short, precise questions, dense with mathematical jargon, and pushes the frontier AI model on reasoning that doesn’t make sense. It was like watching a 10-year-old genius being schooled by a much older, wiser genius.

I quickly learned that I could copy every prompt Tao used and still never, not in a million years, reproduce what he did. This sort of mathematical sorcery can only happen when someone has deep knowledge of their craft, because Tao can do the one thing a non-expert cannot: Evaluate the response. Without that expertise, you don’t know whether the answer coming back to you is correct or confidently delivered gibberish.

What irritates me is that I fell for the most charlatan-like advice about “learning AI” from LinkedIn AI influencers who screenshot the latest prompts promising “outputs like a McKinsey consultant” or “growth strategy from a world-class CMO”—as if expertise is just a few sentences you could press the enter key on.

It’s so easy to get a seductive answer from AI that I’m afraid more and more of us will revert to cognitive offloading and skip the hardship and “stuckness” necessary to develop expertise. In Anthropic’s study of 52 mostly junior developers learning a new Python library, the AI-assisted group scored 50 percent on a subsequent quiz, versus 67 percent for those coding by hand. The largest gap between the two groups was in debugging, the skill required to catch the model when it is wrong.

It is a small study, and AI can help people learn. But I now think AI will make expertise more valuable and experts harder to produce.

This has irrevocably changed how I use AI. Before reading its answer, I force myself to clarify what I already understand. Sometimes I ask, “What is a better question here, and why?” before seeking the answer. The machine is always ready to rescue me, but watching Tao, I realized expertise is knowing when it hasn’t.—Ashwin Sharma

That’s all for this week! Follow Every on X at @every and on LinkedIn.

Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$7,000+ in credits for the tools we build with.

For sponsorships, contact sponsorships@every.to.

Vibe Check: Claude Opus 5 Is Brilliant in Flashes, Frustrating in Practice

Dan Shipper and Katie Parrott / Vibe Check — 2026-07-24 13:00:00 -0400

by Dan Shipper and Katie Parrott

in Vibe Check

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Claude Opus 5 had a strange first week at Every. It argued with instructions, stopped before the work was done, and fought the systems we’d built for earlier Claude models.

Then we deleted them.

With less process, Opus 5 sometimes got dramatically better. It built strong software, worked through bugs for hours, and produced more rigorous knowledge work. The less we told it how to work, the more capable it looked.

Our Vibe Check asks whether Opus 5 is disappointing—or whether the workflows it broke have become part of the problem. We tested it across coding, writing, knowledge work, and agents, with results that made the model hard to place.

Opus 5 doesn’t reach Fable’s ceiling, and it isn’t as easy to use day to day as GPT-5.6 Sol. Its best work may require rebuilding systems that already work. The full review explains what we would change, where the model surprised us, and who should bother making room for it.

Read the Vibe Check

Dan Shipper is the cofounder and CEO of Every, where he writes the Chain of Thought column and hosts the podcast AI & I. You can follow him on X at @danshipper and on LinkedIn.

Katie Parrott is a staff writer at Every. You can read more of her work in her newsletter. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$7,000+ in credits for the tools we build with.

How Every's Team Used AI to Ship Its Biggest Launch Ever

Laura Entis / Context Window — 2026-07-22 13:21:53 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

AI makes building easy. The hard part is knowing where to start. Today, Every’s Yash Poojary, Austin Tedesco, and Douglas Brundage share how they turn ideas into products. OpenAI staffers offer a practical Codex playbook. Spiral general manager Marcus Moretti shares a no-nonsense strategy for having Fable delegate tasks to cheaper models. And we debut the daily driver, a running list of the models the team is using this week.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

‘AI & I’: The tools the team uses—and their tips for new builders

Last week we had the biggest monthly recurring revenue gain in Every’s history—roughly $9,000 in two days—from launching All Access, our new $625-a-year membership tier. On this week’s AI & I, I handed the mic to our COO Brandon Gell, who sat down with three of the builders behind that launch—growth engineer Yash Poojary, head of growth Austin Tedesco, and head of marketing Douglas Brundage—to talk about the tools they use most, how they build with them, and their tips for new builders getting started.

All Access subscribers get the Builder Pack, which includes $7,000 in credits and unlimited access to the AI tools Every uses every day.

Watch on X or YouTube, or listen on Spotify or Apple Podcasts. You can also read the transcript.

AI redistributes work to the harder problems. Yash spent a month manually running A/B tests—clicking through dashboards, calculating audience sizes—before deciding to hand the whole thing to Claude. “It’s a lot of fake work,” he says. So he automated it. He’s now doing the same for the entire testing workflow, which will free him to spend more time on what he enjoys: coming up with ideas and deciding what to test next.
It speeds up the process from idea to execution. Austin describes the ideal way to work with agents as “at the top and bottom of the AI sandwich”: You frame the problem and review the output. Everything in between can be delegated to AI. For example, during the Builder Pack launch, Yash flagged in Slack that the team should email users who’d shown intent to purchase but hadn’t converted to a paid membership during the early-bird discount window. Austin took a screenshot of the thread, dropped it into Codex with a “Can you do this?,” and headed to the gym. When he came back, Codex had defined four audience segments and written the copy for emails to send to each one. Austin only needed a few minutes to tweak the headlines before sending. By the next morning, the emails had generated $25,000 in revenue.
Working with AI agents is like conducting an orchestra. Doug finds it interesting that Codex, Haiku, Sonnet, and Fable are all literary forms, while directing agents is called “orchestration.” Instead of playing every instrument yourself, you learn to conduct a set of AI agents that can each play a part. “As long as you know what the piece needs to sound like, you can be conducting a lot of different orchestras at the same time,” he says. But using agents still requires strategic thinking upfront: “You have to put in a lot of work upfront, in terms of doing some metacognition and figuring out: How do I think about this? What is my process?” Once you’ve codified your process, he says, “These tools can run with it. You can ask them for help if you don’t know why something happened.”
How to get started. Brandon advises new builders to pick a product you already use and love and build a simpler version. Soon, you’ll identify features you don’t like and things you want to change. “Very quickly, it’s not duping,” he says. “It’s like inspiration, and you’re off making your own thing.” Austin recommends building something you’d be excited to text a friend about. For him, that was a movie app: the Fandango for indie movies. “I would encourage people to not necessarily make the most complex app for the sake of complexity, but to make something you don’t think you can, because you’re going to learn so much through that process.”

Miss an episode? Catch up on Dan’s recent conversations with Anthropic head of product Mike Krieger; the team that built Claude Code, Cat Wu and Boris Cherny; the team that built Codex, Thibault Sottiaux and Andrew Ambrosino; Vercel cofounder Guillermo Rauch; podcaster Dwarkesh Patel; and others to learn how they use AI to think, create, and relate.—Miriam Partington

Steal this workflow

How OpenAI builds with Codex

Codex is powerful and versatile, which can make deciding how to start using it an overwhelming experience.

In the following video, three OpenAI staffers break down how they use Codex to make their jobs more efficient—and provide a playbook so you can do the same.

Romain Huet and Dominik Kundel, who work on developer experience for Codex, show how they brainstorm feature ideas and run deep research in ChatGPT, then have Codex use the whole thread as its brief to start building.
Kyle Kober, who works in product finance, demonstrates how he used Codex to build a system for reconciling OpenAI’s monthly compute costs, a process that used to take five days. Kyle’s Codex system completes most of it in about five hours, after which the finance team reviews the results and finishes the remaining work.

Here’s how you can get started:

Select a task you do every week or month.
Give Codex access to the files you normally use, an example of a finished result, the steps and rules you follow to achieve that result, and any checklists you use to catch mistakes.
Supervise the first run.
When Codex can handle part of the process reliably, save those instructions as a reusable skill so it can follow the same procedure next time.

Ready to put this playbook into practice? Upgrade to Every All Access and redeem $1,000 in Codex credits through the Builder Pack on new and existing ChatGPT Business accounts.

Inside Every

A simple way to make your Fable runs more token-efficient

Spiral general manager Marcus Moretti wanted to make Every’s internal Slack agent faster and less token-hungry. After reviewing its slowest sessions, he compiled roughly 20 changes that could improve its efficiency.

Marcus handed the full list to Fable, asked it to work through the changes as one coordinated run, and went to sleep. Nine hours later, the model had combined overlapping tasks, dropped ones it judged unnecessary, investigated problems without obvious solutions, opened 10 pull requests, and tested their impact. “The PRs themselves were basically ready to go and merge,” Marcus says. (Great!)

The less-great part: Fable had spent roughly 20 millions of tokens to change about 5,000 lines of code. Those tokens covered more than writing code. Fable also read context, coordinated agents, conducted research, and checked their work—tasks cheaper models could have handled.

For his next large run, Marcus added an instruction shared by independent developer Simon Willison, who credits developer Jesse Vincent with the tip:

For all coding tasks use your judgment to decide an appropriate lower-power model and run that in a subagent

The prompt leaves Fable in charge of planning, delegation, and review while letting it assign implementation to cheaper models. On Marcus’s second run, Fable chose Sonnet for some jobs and Opus for others, using fewer Fable tokens.

“You don’t need the Fable model itself doing a lot of the nitty-gritty implementation,” Marcus says. “You need it to be the CEO of the run.”

The daily driver

The models the team is using this week:

Nityesh Agarwal, senior applied AI engineer—Claude Fable (high) for orchestration, Opus 4.8 (high) for execution.
Jack Cheng, senior editor—Fable (low), “my preferred model/effort” for a week with “more dev work.”
Becky Isjwara, head of social media—GPT-5.6 Sol (high), with a sprinkle of Fable and Opus 4.8. “I don’t play around with effort levels that much.”
Lee Knowlton, engineer—GPT-5.6 Sol (medium) as his daily driver, switching to high or extra-high for harder problems; Fable “when I really need to trust it to do good autonomous work”; and Cursor auto mode “because I’d spend too many Codex credits otherwise.”
Kate Lee, editor in chief—GPT-5.6 Sol (extra-high).
Marcus Moretti—Mainly Opus 4.8, with Fable for coordinating dynamic workflows.
Katie Parrott, staff writer—GPT-5.6 Sol, toggling between high and extra-high, though “it’s been a bit lazy and bad at reasoning over the past 12 hours or so.”
Natalia Quintero, head of consulting—GPT-5.6 Sol (high) by default—“but I wish it was Fable”—and increasingly Opus 4.8 “because I can rely on it to be available.”
Arielle Shipper, head of operations—GPT-5.6 Sol (high), Terra (high) as backup for “less complex things or where precision matters less, like ‘find this email for me’ or ‘update this calendar invite’ or finding reservations for a group dinner. Terra takes less license and requires more direction than Sol.”
Dan Shipper, CEO—GPT-5.6 Sol (extra-high).
Willie Williams, head of platform—GPT-5.6 Sol (extra-high).

Log on

Get hands-on with how Every uses AI. These are the live camps, workshops, and meetups where team members teach the workflows behind our work.

Upcoming events

Office Hours: All Access Builders (July 24): To kick off a recurring series, the Every team will share how we use the tools in the Builder Pack, before working through member questions and projects together. Bring one thing you want to build or improve. This virtual event is only available to All Access members.

Discuss

“hello there the jacobian conjecture is false thanx to my close friend akhil for asking about it and my other close friend fable for working during the world cup final

”((1+xy)^3 z + y^2 (1+xy) (4+3xy), y + 3 x (1+xy)^2 z + 3 x y^2 (4+3xy), 2 x - 3 x^2—^3 z): \C^3\to \C^3, has jacobian determinant -2, and sends (0, 0, -1/4), (1, -3/2, 13/2), and (-1, 3/2, 13/2) to (-1/4, 0, 0)”—Harvard researcher Levent Alpöge, on X

This past Sunday, as Spain and Argentina battled it out in the World Cup final, Alpöge worked with Fable to disprove the “Jacobian conjecture,” a major open problem in algebraic geometry.

Shortly after Alpöge went public with his counterexample, OpenAI researcher Aaron Lou posted on X saying he’d asked an internal version of Codex to tackle the same conjecture. According to Lou, Codex independently found what was essentially the same counterexample in a single 42-minute run without using web search. (Here’s the prompt he used.)

One last thing

Links worth a click

OpenAI says its models escaped its test environment and hacked into Hugging Face. Don’t expect Google’s new frontier model to be released anytime soon. Token limits come for the U.S. army. Codex goes mainstream. Old books as an antidote to AI slop. AI-recorded meetings are now the default. Substack is partnering with AI-detection startup Pangram to help readers identify “content made by no one.”

Laura Entis is a staff writer at Every. You can follow her on LinkedIn. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$7,000+ in credits for the tools we build with.

Drowning in Demos? Here’s a Better Way to Prototype

Hilary Gridley — 2026-07-21 12:32:47 -0400

by Hilary Gridley

Midjourney/Every illustration.

We’re kicking off a series on “unlearning” in partnership with Maven, the expert-led course platform. Over the next three weeks, you’ll hear three different takes from Maven instructors on what we need to let go of as AI changes how we work. First up is Hilary Gridley, who previously led product at Whoop. She explains why faster prototypes don’t make product decisions easier—and how teams can decide which ideas are worth building.—Kate Lee

When AI tools started getting good, my team went on a prototyping binge.

I was leading the product team at Whoop, where every product manager had a backlog of ideas they’d been dying to explore but hadn’t gotten past a whiteboarding session or a passionately worded document. Then tools like Bolt and Replit came along, and suddenly, we could spin up prototypes of our ideas in an afternoon.

It felt like getting keys to the castle. Ideas that had been trapped in documents were finally showing up on screens. Except... were they any good?

We felt productive, unhindered, moving faster than ever. But people were making prototypes left and right, with no process for what happened next. Occasionally one would generate enough excitement that a team put aside their previous plans and built it. Mostly, though, there was no consistent way to decide which prototypes were good, which ones should die, and what we were supposed to learn from them.

We were building faster, but we weren’t deciding better.

Cheap prototypes change the equation

Prototyping has always played a well-defined role in product development: to prove or disprove your best ideas. You’d go deep on a problem, decide where to focus your efforts, look for evidence that customers wanted a solution, then decide whether to pursue it. Only then would you prototype—and by that point you were already pretty confident, so the prototype confirmed your hunch (or didn’t).

This made sense when building was expensive. If a prototype cost a week of engineering time, you could only afford to prototype ideas you were already fairly confident about. The expense forced discipline.

The cartoonist Matthew Diffee describes his creative process as laying 100 eggs in the sand and swimming off, like a sea turtle. Most won’t hatch, which is the point. Sketching is cheap, so he can draw it, send it to the New Yorker, and move on to his next idea.

AI has made prototyping similarly cheap for product teams. When the cost of building collapsed, two things happened at once: Prototyping became accessible to anyone with an idea and a laptop, and the original reason to prototype—de-risking an expensive build—stopped making sense. But nobody stopped to ask what prototyping was for now.

So prototypes drifted into something else entirely. Without a clear framework for what they were supposed to help decide, they became pitches. Product managers built things to show what was possible and get colleagues excited. Engineers, meanwhile, built whatever seemed cool on hack days. We had more prototypes than ever, but no better way to decide which ones were any good—and it got noisy.

Every prototype still demanded someone’s attention. Going from five prototypes to 30 risks diluting focus across six times as many ideas, without making it any easier to choose.

So if building is no longer the bottleneck, the prototype has to move earlier. It’s no longer there to answer, “Is this the right solution?” but, “Is this even the right problem?” That’s a harder question, and you can only answer it by putting prototypes in front of users and watching what the data says.

Whoop had to work through it all: which problems were worth solving, how to test ideas against users instead of internal stakeholders, and what a product manager was even for once building got cheap. None of it was resolved quickly.

How Whoop’s AI product team prototypes today

After I left Whoop, the team kept pushing on the problem. I recently caught up with Anjali Ahuja, who now leads the AI product team, to understand what had changed. With AI, she told me, anyone could spin up a prototype in a day—and suddenly everyone was. But this was the hack-day trap all over again: plenty of demos, no understanding of what worked.

Anjali’s team began asking a different question of each prototype: What could we learn by putting this in front of members? The product team had tried to work this way before and kept hitting the same walls; they needed a roadmap to market or had to coordinate with other teams building in overlapping spaces—or they didn’t want experiments to make the existing product feel unfinished.

What finally worked was a process for deciding where to explore, what to measure, and who should see unfinished ideas.

First, they defined what success looked like before anyone started building. The team spent six weeks with a cross-functional working group—product, engineering, design, analytics, and data science—to define what AI should accomplish for users. Instead of starting with feature ideas like “build a sleep coach” or “add an AI chat feature,” they focused on outcomes: Could AI help members capture more context about their lives? Could it help them understand their data in a more actionable way?

Once those pillars were clear, hack days got lanes. Engineers and product managers could still explore freely within any one of those pillars, but their prototypes had to test whether AI could move that outcome.

The final piece was the beta group. Instead of demoing prototypes to stakeholders and collecting opinions, Whoop put rough versions in front of 12,000 members who opted in to test them, then watched what happened. Did a strength training prototype get people to log more workouts? Did it help them train more consistently? Did it make the product more useful?

A prototype that gets demonstrated to stakeholders generates opinions. One that gets used by external people generates data. Whoop’s beta group let the team see what willing testers did with rough prototypes without exposing every member to half-finished ideas. It let the team operate more like a growth team—testing more ideas than would have been possible before—while still giving leadership and cross-functional teams visibility into what was coming. The point was to learn faster, so that Whoop shipped only what improved members’ health outcomes.

Lanes, not guardrails

This approach changes the product manager’s job in a way I don’t think most product leaders have fully reckoned with.

When the technical frontier moves weekly, product managers can’t keep up. The traditional flow—the product manager defines the problem, writes the specification, and hands it to engineering to implement—assumed that the product manager could know enough up front to tell the team what to build. That model collapses when the only way to understand the technology is to experiment with it.

“I don’t feel like I can go to engineers with a set of requirements anymore,” Anjali told me, “because I don’t even know what’s possible to be solved.”

Previously, product managers were often forced to commit early because exploration was expensive. Now that exploration is cheap, the product manager’s job is less about having the answer and more about creating the conditions for the team to find the answer together.

This requires a different skill from writing a good product spec. You have to be able to see through an exciting prototype and ask: What assumption does this test? What would we learn by putting it in front of users? If we shipped it tomorrow, how would we know it worked? A lot of prototypes can’t answer those questions. They’re solutions in search of a problem—built because they could be, with no hypothesis about what would happen.

The hardest part of her job, Anjali told me, is creating an environment where engineers feel empowered to explore—hack days, blank canvases, creative freedom—while also making sure that exploration is pointed at something: “Here are the five things we believe matter for our members. Go figure out if AI can help with any of them.” Those are lanes, not guardrails.

Stop drowning in demos

I think what tripped us up at Whoop early on—and what I see tripping up most teams in my work teaching managers and product leaders how to use AI—is confusing building with learning. Seeing something take shape on the screen is energizing, and it feels like you’re making progress. But artifacts aren’t decisions.

The questions I now ask about any prototype are: What decision will this help us make, and what’s the fastest way to get the data needed to decide?

When building was expensive, the expense itself forced you to build with a clear purpose. Now that building is cheap, the discipline has to come from knowing which problems matter most, agreeing upon what success looks like, and listening to the people using the prototypes—the fundamentals that have always mattered. As a product leader, your job is to help build the culture where your team practices this discipline.

AI has made it possible to pursue more ideas than ever before without committing to them up front. The challenge is to do it in a way that doesn’t cause chaos internally or for your users.

The teams that figure this out first will build fewer products and ship better ones. The rest will drown in demos.

Hilary Gridley is a product leader and writer behind the newsletter Writerbuilder. She designed the Couch to 5K for AI, which has helped 162,000 people go from chatting to building with AI. She was previously the head of core product at Whoop.

Sign up for Hilary’s self-paced Maven course, How to Become a Supermanager With AI, and receive a 15% discount.

Disclosure: Every receives a share of revenue from new Maven course enrollments made through this partnership. Maven helped connect us with instructors and suggested potential topics; Every retained full editorial control over what we published and how each piece was edited.

Why Some AI Workflows Stick—And Others Don’t

Katie Parrott / Working Overtime — 2026-07-20 11:21:21 -0400

by Katie Parrott

in Working Overtime

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

I was on a video call with Every CEO Dan Shipper, getting a tour of the increasingly elaborate ways he uses OpenAI’s Codex app to run his work life, when I saw the next AI workflow that was going to change mine. At least, that’s what I told myself.

Dan was sharing an early version of Tend, the Codex-native system he created to pull email, Slack, meeting notes, and company updates into one place and help you act on them.

The moment the call ended, I gave the transcript to Codex and had it build my own version of the tool, which, lacking Dan’s flair for naming things, it called Attention Desk. I could picture the person who would use it: me, but better. I would spend most of the day in deep work, surface a few times to see who and what needed me, and disappear again—responsive, efficient, and 10 times more productive than I’d been before.

As of this writing, Attention Desk sits abandoned in my pinned chats, the little blue dot beside its name the only reminder of how sure I was that it would transform my work.

This seems to be a pattern in the way I use AI: I see an impressive demo or have one surprisingly good session with a model and decide to reorganize my work around it. Then the novelty wears off. The next thing I know, weeks have gone by and I haven’t touched the workflow I was sure would change everything. There’s a veritable Island of Misfit Workflows adrift on my desktop, from app ideas that collapsed under the weight of their own maintenance to AI skills I built and promptly abandoned. And yet writing with my compound writing plugin or navigating my workday with help from Codex already feels like I’ve been working this way for years.

I wanted to understand why some AI workflows become essential while others have the staying power of a celebrity romance. So I did a post-mortem on the chief offenders and looked at relevant behavioral science research. It turns out the difference comes down to what a workflow asks of my time, energy, and sanity—and what it offers in return.

An abandoned workflow is not a character test

Once I noticed that little blue dot next to Attention Desk and the fact that I wasn’t responding to it, I let it sit like a check-engine light I’d decided to live with. Over time, the notification started to feel like an indictment of my character.

My first reaction was to label it a me problem. I simply lacked the stick-to-itiveness or sophistication to get these systems to work. Somewhere out there, other, better people were adopting these workflows and living their 10-times-more-productive lives while the permanent underclass had a space with my name on it.

Maybe that’s just my own unique brand of catastrophizing, but I suspect this feeling of wanting to build all the workflows—particularly the workflows of people we perceive as successful—is common. Model capabilities and the best practices for working with them are changing so fast that it’s understandable to want to follow the lead of people who are winning at AI. When you try what works for them and don’t get their results, it’s tempting to assume you’re doomed to failure. At least, that’s what happens if you’re me.

Rationally, I know that “either I can make this workflow work or I’m a failure” is classic black-and-white thinking. A workflow may go unused for a boatload of reasons: The problem is too infrequent, the trigger doesn’t go off, or the output creates more work than it saves. A tool can fail because my habits don’t support it; my habits can also be rational responses to the work I actually do.

I built Attention Desk for a workday I don’t have

I wanted what Tend offered: to sink into deep work without wondering what was happening in Slack, then surface to find nothing had caught fire. But Dan is a busy CEO pulled in enough directions that Tend’s ability to gather his communication gives him time and mental space back. I get an average of six to eight inbound Slack messages a day, which I can manage myself without much stress. For me, Tend proved to be a solution to a problem I simply didn’t have.

With my Tend dupe, I was also building a workflow that would compete with my own deeply ingrained behavior. I have an anxious attachment style when it comes to work, and checking Slack is my favorite sanctioned procrastination activity. I reliably check Slack 40 to 50 times per day—and every time, I feel relief from the discomfort of writing, or the motivating hit of a fresh news drop. Attention Desk’s attempt to deliver peace of mind couldn’t compete with those rewards.

Behavioral psychology lore says I should have given Attention Desk 21 days to stick as a habit, but that data point turns out to be a myth. A 2024 literature review found that the few relevant studies showed habit adoption medians around two months and ranges from four to 335 days. Three days may not have been long enough to create a habit, but it was plenty of time to discover I didn’t want to spend weeks or months forming this one.

The research also has ideas about how I could force an AI workflow to stick. For instance, I could make an explicit plan: If I am about to check Slack, then I will open Attention Desk. A 2024 meta-analysis covering 642 tests found that clear plans grounded in the specific context where the behavior happens can help, especially when motivation is already strong. There’s the catch: An if–then plan can help me act on a goal that feels important and compelling. It cannot make me need a CEO dashboard or want to stop using Slack as an emotional-support procrastination device.

Attention Desk wasn’t defeated by my failure to perform the right behavior-design incantation. In hindsight I can see that I made a rational choice to abandon the tool; it was built for someone else’s problem and pitted against a behavior that solved my own.

I kept building tools for a person I wasn’t

Attention Desk has neighbors on the island, each built for a version of me that doesn’t exist. I set up a Codex automation to generate daily X and LinkedIn post recommendations based on my work. I pictured myself effortlessly hitting the three-times-a-week activity cadence I saw recommended for LinkedIn.

Reader, I have never shared one of those posts.

In the cold light of day, I realized I’m a spontaneous, shoot-from-the-hip kind of social media user. When I have something to say, I’ll say it. Suggested content gives me another queue to fall behind on, and I emphatically do not want that. For me, the annoyance outweighs the value of posting more. Becoming an X poster extraordinaire will have to wait.

In the 1980s, psychologists Robert Wicklund and Peter Gollwitzer described a phenomenon uncomfortably close to my pattern of optimistically building tools for an aspirational version of myself: “symbolic self-completion.” People who fall short of an identity they care about can reach for its symbols, including tools and skills. Their experiments did not test AI workflows, but still—building the machine that would make me a disciplined public thinker felt remarkably similar, for an afternoon, to being one.

I doubt I’m alone in carrying around these more motivated selves. They’re aspirational, like a workout outfit you buy optimistically. One takeaway from my exploration of these failed projects could be to embrace the Katie I am, not the one I hope to be tomorrow.

A workflow can be worth building and not worth keeping

Longtime Working Overtime readers will remember Margot, the AI assistant I built to manage my other workflows. I set her up after seeing what people like Nat Friedman and Claire Vo were doing with OpenClaw on an Every camp on the topic. I imagined an AI companion fine-tuned to my needs could supercharge my day-to-day life.

Life with Margot was great for the first several weeks. After the “it’s alive” moment and eager exploration of her Google Calendar navigation, she became more trouble than she was worth. For example, every time I tried to change the model powering Margot, she quit working altogether and I had to revive her. A month in, I realized I was spending more time maintaining Margot than I got back.

I left Margot behind, but her legacy carries on. Architecting her memory taught me how important it is for agents to find the right context. That lesson fed into my current desktop setup, where tailored context helps Codex or Claude find what they need.

Living as we do in the Wild West days of AI, we’re all being tasked with figuring out what is and is not worth the effort to set up and maintain. There’s value to tinkering with these temperamental, wonky workflows because it makes us savvier users of the models and apps we work with everyday.

The workflows that stick give something back quickly

As I was doing my post-mortem on my various failed AI habits, I considered the new behaviors that have stuck. Exhibit A: my compound writing plugin.

It’s a toolbox of skills I built for writing, modeled after Cora general manager Kieran Klaassen’s compound engineering plugin. It follows the steps of the writing process to help me take an article from idea to polished draft.

Compound writing had a few points against it, if we’re using my failures as precedent. I borrowed it from someone else, like Tend. It’s effort-intensive, like Margot. And it also has to compete with my established Slack-checking habit—as I’ve said I will do anything to avoid working on a draft.

And yet, compound writing has become the core of how I do my job.

The difference is that compound writing quickly started sending signals back that my effort would be worth it. Even before it worked well, the plugin made writing feel propulsive again. It gave me a paragraph to push against, a question that unstuck an argument, or a way into the next stage of a draft. It gave me a writing partner that solved a real problem in my work—the loneliness inherent to writing for a living.

In a series of studies, behavior researchers Kaitlin Woolley and Ayelet Fishbach found that immediate rewards predicted persistence better than delayed rewards. The research is not proof that a behavior will become automatic, but it helps explain why I kept at it. Compound writing paid me in currency that mattered to me immediately. The distant promise of becoming a calmer Slack-checker could not compete.

Solving AI with more AI (again)

Looking across my AI workflows—the ones that failed and the ones that stuck—I can see why each ended up where it did. Attention Desk solved a problem I mostly imagined for a person I hoped to become. Compound writing met me inside work I already did and began paying me back almost immediately.

I could judge a workflow by what happened once it made contact with my day-to-day work—whether I resented maintaining it, carried away something useful from its failure, or kept returning to it. But the worry that I’m missing out on something hasn’t gone away. I wanted a way to know for sure if an experimental system would never work, or if it could be useful with a tweak to its design or implementation.

So, naturally, I added a new AI system to audit my AI systems. This time, a reviewer called Agent Ops.

Agent Ops is a plugin inside my Codex that inventories the systems I built or adopted and asks me questions about the goal, usage, and the outcome of each one before making a recommendation to either keep, tweak, or retire it.

In setting up the plugin, I discovered that my failed workflows fall into four buckets: I forgot it existed, it failed to run, the output required too much maintenance, or it didn’t solve a recurring problem.

I turned those answers into provisional rules. A new automation has to run manually three times before I schedule it. Its output has to produce something I use with less than five minutes of review. Four unused runs of an automation trigger a decision to change or retire it.

The prompt below is a version of the interview that produced it, adapted so you can run it on your own Island of Misfit Workflows.

          Code snippet
          JavaScript
        

Help me audit the AI workflows, automations, custom AI assistants, and applications I have created or adopted. The goal is to decide what has earned a place in my work, what could become useful after a redesign, what I should revisit only if my circumstances change, and what I can retire.
If you can inspect my existing projects or chat history, begin by inventorying the workflows you find. Otherwise, ask me to list the ones I remember. Do not assume that frequent use equals value or that abandonment equals failure.
Interview me one question at a time. Start with what I used during the past two weeks and what I intended to use but didn’t. For each workflow, establish:
the recurring problem it was meant to solve;
what happens when I use it;
whether it makes my life simpler, my work better, or my mind easier;
the time and energy required to use, review, build, and maintain it;
whether building it produced useful learning even if I stopped using it;
what changed in my needs, tools, context, or behavior after I created it; and
whether there is evidence that the underlying need still recurs.
When the interview is complete, recommend Keep, Redesign, Revisit later, or Retire for each workflow. Separate what my answers establish from your inferences. Give me no more than five decisions at once, explain the evidence behind each one, and suggest the smallest useful next step. Do not interpret an unused workflow as evidence about my discipline, ambition, or professional value.

The prompt turns every abandoned system into one of four decisions. It keeps the evidence attached to the workflow—what it returned, what it cost, and what changed—where it belongs.

I use my compound writing workflow everyday. The little blue dot on Attention Desk still goes unanswered; my audit suggested I revisit it later. If my work shifts to the point where I feel I need it—I get a lot more emails, or lose interest in benign distraction—I’ll retrieve the workflow from its misfit island and try once again to change everything.

Katie Parrott is a staff writer at Every. You can read more of her work in her newsletter. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$7,000+ in credits for the tools we build with.

The Model Is the Easy Part

Every Staff / Context Window — 2026-07-19 07:55:08 -0400

by Every Staff

in Context Window

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Measure what matters—and get paid for it

Token spend is climbing everywhere. Some of that AI use is valuable; some isn’t. The only way to tell the difference and spend efficiently is to measure—but measure what?

Getting AI tools into your team’s hands was part one of AI adoption. Today, companies must identify business-specific, measurable goals. That part, too, requires both a definition of “good” and the data to measure how close you’re getting to it. Meanwhile, frontier labs are under pressure to improve at economically valuable domains such as finance, life sciences, and general reasoning. They’re paying for data that helps them get there. Well-defined goals now create value for your company in two ways: return on investment for you and your customers and data that can help others improve, too.

Over the past year at Good Start Labs, we’ve built benchmarks, trained agents, and helped game publishers operationalize and monetize their data for that lab market. Arkadium is one publisher with hundreds of games played by tens of millions of players. We supported its recent launch of Game Lab, a public leaderboard scoring how well frontier models play simple games, in partnership with Meta and DeepMind. Arkadium set a clear goal: Give its players a good game against AI. Together we built the benchmarks and evaluated them against real users. Then the scores came in. The same models that make novel discoveries in math and science lose 90 percent of their Gin Rummy games—against casual players.

Opus can’t beat the daily crossword. (Image courtesy of gamelab.com.)

That’s because these models are shaped by what they’ve seen: lots of math, and almost no Gin Rummy. Popular AI models may not have experience with whatever you work on all day either. But defining the goal revealed options for Arkadium beyond a large language model—different forms of AI work well for different goals. Instead of an LLM, we trained an expert model with 4.6 million parameters in an 18-megabyte file that runs on a regular CPU. At full strength, it beats human players about 90 percent of the time, and the economics are as lopsided in its favor: At 1 million requests a day, our expert model would cost about $60 a year; a frontier LLM would run into the multi-millions.

For Arkadium, that “good game” goal paid twice: a better experience for its players and a new revenue line in the form of selling anonymous data to labs for millions. Frontier models performed poorly at games; Arkadium’s well-structured gameplay data from “good” games with “good” human players was what the labs needed to improve. As Arkadium continues to sell that anonymized data to frontier labs, its models will learn from it and apply that intelligence. (GPT-5.6 is already a much better cruciverbalist.)

Reddit, Shutterstock, and News Corp have already turned their data into hundreds of millions of dollars in recurring revenue. Most companies outside the labs’ competitive focus could benefit from selling them data. One major caveat: Companies whose data is their product—like Figma or Cursor—must protect that IP. Anthropic chief product officer Mike Krieger left Figma’s board days before Anthropic shipped a competing design tool; Figma CEO Dylan Field later said they were “not consistently candid.” Cursor built on Claude while Claude Code was described to it as a “research effort,” and then they watched it become a direct competitor. This week it was reported that Anthropic asked big pharma for their data, and nearly everyone said no. If the lab you’d sell to is entering your business, retaining a data edge is essential.

Nobody knows yet how defensible the data market is long term, only that the pot promises to be large. But choosing the right goal for AI, measuring progress, and valuing what you learn will only grow more important as AI becomes table stakes for most companies. Defining and measuring “good” is emerging as the next stage of AI adoption. It never ends—and is becoming a requirement to compete.—Alex Duffy

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Knowledge base

“How I Polish Software That Agents Built” by Kieran Klaassen/Source Code: In compound engineering, agents now run most of the loop—planning, building, reviewing, and opening clean PRs overnight—so Kieran Klaassen’s work narrows to the last human step: polish, or judging whether what they shipped is good or simply functional. Read this for where human judgment sits in an agent-first workflow.

“The Case Against Skills” by Laura Entis/Context Window: Head of tech consulting Mike Taylor argues that most trending AI “skills” have become redundant now that frontier models absorbed them, and piling on instructions can make outputs worse and pricier. Also inside: Monologue general manager Naveen Naidu keeps just one skill, OpenClaw’s autoreview, which helped ship a four-app Monologue Notes feature in a single nine-hour overnight run, and head of growth Austin Tedesco has dropped skills entirely except compound engineering.

“The Urge to Merge (ChatGPT and Codex)” by Katie Parrott/Context Window: OpenAI folded its standalone Codex app into a new ChatGPT desktop with three modes—Chat, Work, and Codex—and power users revolted, with YouTuber Theo Browne calling it a “generational fumble.” Also inside: a workflow for putting a pricey model in charge of cheaper ones—ChatPRD founder Claire Vo treats Fable as a senior consultant, and Dan Shipper runs the same play across labs—plus a 53 percent drop in error rate when an agent saves reusable tools instead of rewriting code.

“The Ops Team That Routes Work Across Models” by Laura Entis/Context Window: Every’s business-operations team moves fluidly between Fable, Codex, and support platform Fin to hit deadlines that shouldn’t be possible. Executive operations manager Jalaiyah Bolden pointed Fable at scattered context and had a support plan, help articles, and 17 response templates ready for a product launch in about 90 minutes. Also inside: customer service manager Waqqas Mir turns a mishandled support chat into a single sharper agent instruction, and Spiral general manager Marcus Moretti spends two weeks with Sonnet 5.

🎧 🖥 “The Founder of a $1.5 Billion AI Company on What Comes After the First Wave of AI Apps” by Dan Shipper/AI & I: Granola cofounder and CEO Chris Pedregal joined Dan to explain why running a startup is “a knife fight” that never ends: After a $1.5 billion valuation on its AI meeting notetaker, Granola has watched Notion, OpenAI, and Zoom copy the feature. Watch or listen to this for why Granola is betting on owning the work around meetings, not just the notes. 🎧 🖥 Listen on Spotify or Apple Podcasts, watch on YouTube, or follow the discussion on X.

🖥 “I’m an Editor—And I Built Our Newest Feature” by Jack Cheng/On Every: Gift links let paid and All Access members share paywalled Every articles with anyone. Senior editor Jack Cheng, who isn’t an engineer, built the feature himself with Codex and current frontier models—a case study in how an AI-native company decides what to launch. Read this for how anyone on a 30-person team can now build and test a feature. 🖥 Watch Jack, Kate Lee, and Austin Tedesco discuss how gift links came to be.

From Every Studio

Every All Access is here

All Access, Every’s new annual membership, is built around a Builder Pack—more than $7,000 in credits and trials across 10 tools we use, at roughly 90 percent below market—plus unlimited accounts on Cora, Every’s AI email tool, unlimited usage on Spiral, Every’s writing tool, and everything in a paid Every membership.

A new product powered by Monologue

Sandbar’s Stream, a private voice ring that captures thoughts as spoken notes, is using the Monologue API to turn speech into text. It’s the first public product outside Every built on Monologue’s voice infrastructure.

Spiral expands Writing Rules

Spiral expanded its Writing Rules so more complex instructions about structure and phrasing can shape a draft. Alongside preferences such as avoiding em dashes or using Oxford commas, you can now ask Spiral to split, shorten, or reorganize copy in any language. The draft-count slider also reliably returns the number of options you choose, and a backend stability fix should reduce crashes.

Alignment

The narrow promise. One problem with so many companies hurtling into AI drug discovery is that finding better candidates faster and more cheaply is only one small part of bringing a drug to market. The chart below is one of the clearest visualizations I’ve seen of this imbalance. Discovery-to-lead—the dark-blue sliver on the left—covers identifying promising targets and optimizing them into drugs worth advancing. Everything after it—confirming the lab tests and cells used to evaluate a candidate are accurate and reliable (assay and cell line validation), then manufacturing, animal toxicology, and three phases of human trials—occupies nearly 99 percent of the remaining bar.

AI drug discovery companies will commoditize. (Source: X/@anthonystaj.)

That disparity suggests two things.

First, if AI models commoditize, many standalone AI-discovery companies may be worth little more than a ChatGPT enterprise subscription and the pitch deck they neatly wrapped around it. A full-stack biotech company can use its own AI models to prioritize compounds and conduct the full array of testing in its own laboratory. AI becomes a tool inside the business rather than the business itself.

Second, computational abundance makes skilled practitioners more valuable. While it’s easy for a model to propose a molecule, it takes medicinal chemists and toxicologists to decide whether the evidence is strong enough—and the risks tolerable enough—to justify putting it into a living person. The judgment and, in many ways, the taste, to know which drug is worth backing is much harder to replicate and scale, and is why expertise and conviction remain a huge bottleneck in drug development.

There will be exceptions, of course. An AI company can capture the upside if it owns the lab work and the drugs, but only by accepting the cost and risk of failure that every other biotechnology company bears when bringing a drug to market. At that point, it becomes a pharmacology company.

The future may look less like software eating pharma than pharma eating software.—Ashwin Sharma

That’s all for this week! Be sure to follow Every on X at @every and on LinkedIn.

Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$7,000+ in credits for the tools we build with.

I'm an Editor—And I Built Our Newest Feature

Jack Cheng / On Every — 2026-07-17 12:29:54 -0400

by Jack Cheng

in On Every

Midjourney/Every illustration.

TL;DR: We’re announcing gift links, which let paid and All Access Every members share paywalled articles with anyone. Using Codex and the latest frontier models, senior editor Jack Cheng took on the project himself. The process showed us that people across Every can now build and test ideas without taking engineers away from more important work.—Kate Lee

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Last month, we rolled out gift links on the Every website. If you have a paid or All Access membership, you can now share paywalled articles with people who aren’t Every members. Standard paid members can share five gift links each month, with the count resetting on the first of the month. All Access members can, starting today, share unlimited gift links.

Gift links by themselves aren’t novel. You’ve likely interacted with them in articles in the online editions of the Wall Street Journal, the Atlantic, or the New York Times. But those publications also have product teams larger than our entire company of 30 people.

Many of us at Every are veterans of organizations structured to dampen risk and dodge uncertainty, often at the cost of experimentation. We’re learning to explore new workflows, cede control to AI agents when it makes sense, and embrace the fact that good ideas can come from anyone—and now be built by anyone.

The path our small editorial team charted to ship the new gift links feature is a case study in how AI tools can turn a heavy organizational lift into a feasible experiment, and how an AI-native company decides what to build.

Here’s how we did it.

Scratching my own itch

As a senior editor at Every, I’ve edited dozens of pieces by our team and outside contributors, as well as written my own essays on creativity, taste, and maintenance. I’m proud of our work. I regularly share links to it in my personal newsletter.

When I share articles from other paid publications, though, I usually use gift links. Some of my favorite blogs, like Metafilter or Jason Kottke’s, tend to share paywalled articles as gift links as well. As much as I wanted gift links for myself, I saw a business case for them. Were we limiting Every’s reach and potential for virality by not giving people a way to share paywalled content?

To find out, I started digging.

I first searched Every’s Slack and Discord channels to see if anyone had raised the idea before. Maybe we’d even tried gift links in the past, or the feature had been proposed and declined for reasons I hadn’t considered. My search turned up a message from Kate Lee, Every’s editor in chief, also wondering about gift links. Each article in our system had a preview link that bypassed the paywall, but the feature was more meant for sharing drafts internally.

Our CMS has a secret ‘preview’ link bypassing the paywall, but it wasn’t built for public use. (Discord screenshot courtesy of Jack Cheng.)

Kate and I have a weekly check-in, so I brought up the idea then. She said that whenever she shares articles with the rest of the team in Slack, she uses gift links too.

The Granola transcript of our meeting from Kate’s perspective. (Screenshot courtesy of Kate Lee.)

Given that gift links could bring new readers to our site, I knew that Austin Tedesco, Every’s head of growth, would be an important stakeholder. I sent him a feeler message.

Austin’s curt Slack response the next morning. (Remaining screenshots courtesy of Jack Cheng.)

Austin’s response was unenthusiastic. As he said candidly in our video about building gift links, “interesting” was his way of telling me, “Don’t waste my time with this.”

But it also wasn’t a no. At most other companies—even at the company Every was one year ago—I might’ve left it there. The additional time and effort needed to sell the idea to Austin and other stakeholders, and convince the rest of the organization that it was worth diverting our website’s engineering lead Andrey Galko from more pressing engineering projects—all while pulling focus from my own duties editing, writing, and building much-needed tools to improve our editorial workflow—wouldn’t have merited the reward. Pursuing my gift links idea would have been the path of most resistance.

Luckily, it’s not one year ago. The capabilities of today’s frontier models, and agent orchestration apps like Claude, Codex, and Cursor, made this a feasible spare-time project.

Deep research, approvals, and execution

Using my Claude-connected OpenClaw agent in Slack, as well as the ChatGPT website, I kicked off “deep research” tasks looking into how gift links worked and how well they performed for other media companies. Larger news sites have had gift links for years; the links had to work to some degree, right?

Research conversations in Slack and ChatGPT.

I compared the two reports, verified the cited sources—many of them studies done by the Nieman Journalism Lab—and asked the agents follow-up questions to make sure I understood the findings. I then worked with my agent to draft a separate report to share with Kate and Austin—then Andrey, if we decided to build the feature. This report had to be much more comprehensive; it should present the business case and sketch out a plan for implementation, including what changes we’d need to make on the existing site’s backend and how we would measure success. I determined those backend changes by pointing Codex at our existing codebase. My goal was to have a document that everyone could look at and say, “Let’s try it.”

Austin’s response to the implementation plan in Slack.

Austin’s response: Based on the report, gift links didn’t seem like a growth priority. But also: If you want to do it yourself with Codex, go ahead.

“I had to have this moment of, ‘You know what? It’s really for the best [to] just go for it,’” Austin said later in our conversation. “Rather than how I’ve worked before, where you’re really protective of your resources. [...] It’s so much better to just see this stuff play out with the user journeys and the data.”

It was clear to everyone, Andrey included, that this was the kind of clearly scoped product change that I could feasibly do without much involvement from him.

I had the green light I wanted. The next part was on me.

Going for it

Building out the gift links feature was more typical of traditional software development—only with agents doing most of the work. I had Codex research the common user interaction patterns for gift links among some of the news sites we referenced. I added screenshots of flows I thought worked well to the report and shared it with Andrey to get his feedback on the architecture; he told me to confirm how we were handling article preview in the codebase.

Andrey’s response to the implementation report, and my follow-up message about when I would need him to review the work.

With the report and Andrey’s feedback as inputs, Codex put together a plan.

Codex screenshot recreated by GPT-5.6 from original transcripts.

Over the next half hour, Codex conducted a comprehensive interview to clarify my vision. We refined the plan in stages, and once I was satisfied, I told the agent to carry out the plan.

Refining the plan in Codex through a series of interview questions. Codex screenshot recreated by GPT-5.6 from original transcripts.

The build took a few hours spread across a couple of afternoons—the latter half mostly me going back and forth with Codex on copy and UI interactions using the in-app browser. I submitted a draft pull request, and Andrey had his Codex review it. We set up a tracking page for analytics in PostHog and deployed the feature on our staging server for Kate’s and Austin’s feedback. We tested the feature internally first, then soft-launched it on the site last month.

In the grand scheme, gift links weren’t a particularly large change to our site or a major differentiator among our competitors. But our experience building them is a good look into how, if an organization is set up to support what AI tools make possible, non-technical teams can dream up, validate, build, and launch an idea—all without diverting resources from higher-stakes work.

We’re watching to see how much of a difference gift links make on Every’s subscription business. Austin had his Slack agent add the report from the PostHog dashboard to the growth team’s Monday briefing. Regardless of the results, I know at least a few people, myself included, who are excited to share those links.

All Access and paid Every members can try out the new feature by clicking the “Share full article” button under article titles. Here, too, is a gift link for my piece from December on AI and creativity.

Jack Cheng is a senior editor at Every. He is a creative generalist and the author of two novels for young readers. You can follow him on X or read his occasional Sunday newsletter.

Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$7,000+ in credits for the tools we build with.

The Case Against Skills

Laura Entis / Context Window — 2026-07-16 10:58:17 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Signal

Skills could be making your AI worse

It might be time to examine your elaborate skill library. Skills are reusable packages of instructions—and sometimes examples and tools—that load whenever they’re relevant to what you asked your AI to do. They’re supposed to improve an agent’s performance. The format, popularized by Anthropic, is all over X, where sprawling custom skill libraries are treated as status symbols.

Mike Taylor, Every’s head of tech consulting, thinks every skill should earn its place in your library with proof it improves outcomes. His argument: Frontier models are smart enough that they’ve absorbed the need for most of the skills trending on social media. If a model can reason through something on its own—and Fable 5 or GPT-5.6 likely can—adding extra instructions creates confusion, not clarity. “You’re fighting the weights of the model by forcing it to do things your way instead of the way it was trained,” Mike says. Any time you conflict with the model’s training, it’s more likely to make mistakes. All the additional text loaded from your skill will also inflate costs, so you should make sure each skill you choose is worth it.

Skills are still useful, Mike says, but only when you need the model to complete a workflow in a specific way, like producing a custom PowerPoint template with instructions on your brand style guide or referencing internal company data. Mike recently found when testing Fable 5 that some of the skills Opus 4.8 needed to avoid mistakes actually harmed the newer model’s performance. It reminded Mike of his work as a prompt engineer in 2023: “With GPT-3 we had to use all these hacks and magic words to get it to produce valid code. Then when GPT-4 came out, it followed instructions better, and our bag of tricks was no longer necessary.”

Why it matters:

The data backs him up. SWE-Skills-Bench, a research benchmark that tests whether agent skills make agents better at software engineering, tested 49 public software-engineering skills and found that 39 didn’t impact performance, while three made things worse. At the same time, a large percentage of skills caused the model to consume more compute without improving results. (The worst offender increased token use by 451 percent.)

Only seven skills improved outcomes, and according to the researchers, these successful skills all provided specialized guidance the model couldn’t otherwise supply, like financial-risk formulas or traffic-management instructions.

What it means:

Skill utility has a shelf life. Instructions that patch a model’s blind spot can become redundant—or actively counterproductive—the moment a new version of the model absorbs that capability. The skills built to last are the ones that give the model information it couldn’t have known about your business or the way you work because it’s not public information: personal preferences about your writing style, a specific company template, internal company data, or an exact sequence of steps. When you do use skills made by other people, make sure they’re regularly updated and pruned by their author.

Try it this week: Perform a skills audit.

Keep skills that provide private context, custom tool access, personal taste, or a specific company workflow—things that people outside your company wouldn’t know.
Retest skills that compensate for a general weakness or quirk of a current model—these likely have a shelf life as the models improve.
Retire skills that don’t demonstrably improve results. You can ask your favorite AI agent to run your prompt with a skill and without, then compare the results.

Steal this workflow

Evaluate your skills to make sure you’re getting the results you want

“Writing lots of skills isn’t just productivity theater—you could be harming performance,” Mike says. “If you’re going to create a skill, prove that it works.”

Here’s his approach for doing just that:

Step 1. Define what your skill should accomplish by identifying examples of ideal outputs. When Mike built a custom PowerPoint skill, he started with two real-world examples of strong human-made decks as a reference, a number that eventually expanded to 15 or 20. “That’s the golden data set,” he says.

Step 2. Use the golden data set to inform how you create and modify your skill. Drill down on what you like about the set so you can codify “good” into the skill’s instructions. Keep running the same input to see if changes to your skill move the output closer to the golden data set.

Step 3. Automate the evaluation process by focusing on one issue at a time. Mike’s PowerPoint skill kept getting letter spacing wrong, prompting him to create a large language model judge—trained on examples of decks with good and bad spacing—that graded results on that one metric. The more you can dissect a subjective vibes-based evaluation into narrow measurements, the more work you can delegate to the model.

Step 4. Run a sanity check. Give the model the same input with and without your skill and see if using it meaningfully changes the results.

Skill share

Autoreview for the win

Monologue general manager Naveen Naidu uses skills sparingly, mostly when he wants AI to follow a custom workflow. Many of the generic instructions he once packaged as skills—like one that specified when to add comments—aren’t necessary anymore, he says, “because the model got so good.”

One public skill has earned a place in his setup: OpenClaw’s autoreview skill, which reviews code before it’s merged. Created by OpenClaw founder Peter Steinberger, the skill gathers the code an agent has changed and sends it to a separate model for review. (Currently, Codex, using GPT-5.6 Sol on high, is the default reviewer.)

Autoreview played an instrumental role in Naveen’s ability to ship a new feature for Monologue Notes, which lets people label transcripts as “work,” “personal,” or any other tag, in a single nine-hour overnight run. Or more accurately, autoreview is how Fable—with an assist from GPT-5.6 Sol—built the feature across Monologue’s back end, Mac app, iPhone app, and web app for Naveen as he slept.

Once Fable was done with the first pass at the code, it ran the autoreview skill. The skill packaged Fable’s changes and gave them to Codex, which returned a list of problems. Fable checked each comment, fixed issues it deemed relevant, then ran autoreview again on the revised code. The process repeated over the course of several hours until autoreview unearthed no more snags. When Naveen woke up, he had a pull request waiting for him.

It was the first time he merged AI-generated code without asking for major changes first. Before, he used to review the code. With autoreview, “Codex replaced me having to find the bugs myself,” allowing Naveen to focus on testing the feature and making sure it aligns with his taste.

Try it yourself:

Install autoreview in Codex:

          Code snippet
          Bash / Shell
        

git clone https://github.com/openclaw/agent-skills.git
cd agent-skills
scripts/install-skills --mode copy --target ~/.codex/skills autoreview

Then open the coding project in Codex and use this prompt:

          Code snippet
          Other
        

Use the autoreview skill to review this branch against origin/main. Verify every finding against the code. Fix only problems introduced by this change, rerun the relevant tests, and repeat the review until there are no accepted, actionable findings. Stop and ask me before making any fix that would expand the original task.

For work you haven’t committed yet, replace the first sentence with: “Use the autoreview skill to review my uncommitted changes.”

Inside Every

Living the post-skill life

Head of growth Austin Tedesco has “abandoned skills entirely,” with one exception: compound engineering, a plugin that gives AI agents reusable workflows for planning, completing, reviewing, and learning from work.

In the lead up to our All-Access launch, Austin essentially one-shotted a series of marketing emails in Codex by pointing the coding agent at Slack messages with the relevant context and using compound engineering to nail the copy and structure.

Directing Codex to the relevant context and telling it ‘do this’ is a go-to move. (Screenshot courtesy of Austin Tedesco.)

One last thing

What’s on our radar

Thinking Machines dropped its first model

Called Inkling, the model is open-weight, positioned to compete on cost and the ability for developers to download and customize it. Helmed by ex-OpenAI CTO Mira Murati, Thinking Machines is positioning itself as an American-made alternative to more-cost efficient, open-weight models coming out of China, and less a direct competitor to frontier labs.

OpenAI is working on an AI companion

Bloomberg’s Marc Gurman reports that the frontier lab’s first consumer device will be a screenless smart speaker that serves as a humanlike AI companion, per anonymous sources. Still in development, the device will do things like manage smart-home appliances, play music, answer questions, and answer emails and texts, using a more advanced version of ChatGPT Voice Mode.

Siri got good

Apple’s iOS 27 beta features a new-and-improved version of its AI assistant. “I’m mostly impressed,” says engineering lead Andrey Galko, who finds that Siri is better at speech recognition and smarter than any other local model he’s tried on his iPhone. “I think Apple is going to do the same thing they always do: take good technology and make it mass market.”

Laura Entis is a staff writer at Every. You can follow her on LinkedIn. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$7,000+ in credits for the tools we build with.

The Ops Team That Routes Work Across Models

Laura Entis / Context Window — 2026-07-15 14:00:10 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

AI models have never been smarter or more capable. But using them to their full potential still requires AI skills, fluency, and most of all, the willingness to hand over complex work to an agent—or agents. Today, we show how our business operations team works across Fable, Codex, and the customer support platform Fin, then look at Granola’s plan to turn meetings into context any agent can use. We also explain why Sonnet 5 still isn’t great at writing (but does better at more tightly scoped tasks), examine three roles emerging in the AI era, and share some of our favorite people to follow on X.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Inside Every

Biz ops at the frontier

Executive operations manager Jalaiyah Bolden had a couple of days to turn around a customer-support plan for the launch of Every All Access, a new annual membership for builders that includes unlimited access to Every products, among other perks. The information she needed was scattered across half a dozen sources. “It was information overload,” she says—the kind that could have sunk much bigger ops teams.

Instead of scrambling, Jalaiyah took a deep breath and surfed the models.

Jalaiyah’s initial Fable prompt. (Screenshot courtesy of Jalaiyah Bolden.)

First, she summoned Fable. Giving the model access to all relevant context, she instructed it to ask clarifying questions about anything that was missing, and then get to work.

Fable audited Slack channels and read the Notion documents and meeting transcripts. It visited the launch’s staged websites, clicked through buttons to confirm they worked, and flagged places where a page contradicted information from a meeting or source document. Then it turned the findings into a prioritized action plan and drafted support material: three user-facing help articles, a half dozen snippets written for Fin—formerly Intercom, a customer support platform—and 17 templates human support agents could use to respond to users. The whole process took about 90 minutes—mostly in the background—freeing up Jalaiyah to focus on other things.

After reviewing and “humanizing” the language, Jalaiyah handed everything to head of operations Arielle Shipper, who fired up Codex to proofread the documents and create a Notion tracker so they could all see who owned what and stay on track. The customer-support plan came together smoothly with time to spare. Knowing when and how to use different models allows the team to regularly meet seemingly impossible deadlines.

Steal this workflow

Turn a bad support chat into better agent instructions

When Fin’s customer support agent handles a customer conversation incorrectly, CS manager Waqqas Mir doesn’t rewrite its entire support setup. Instead, he uses Codex to turn the mishandled chat into a targeted new instruction. Using this method, he’s added a rule specifying when the agent should escalate an angry customer to a human and an explicit instruction to patch a bug in which Fin would generate code for a user if they asked—a guardrail Waqqas put in after he got Fin to write him a file-conversion script during a test.

Waqqas’s workflow:

Connect Codex to Fin through the platform’s Model Context Protocol (MCP) server. Once authorized, the MCP lets Codex retrieve conversations from your Fin workspace. In a Codex prompt, enter the identification numbers for two or three chats where Fin made the wrong call and ask Codex to pull the full conversations and diagnose what went wrong.
Ask Codex where the instructions broke down. Follow up by asking, “Why did it not follow my instructions? Can you identify what is causing the confusion?” Codex will identify missing, unclear, or contradictory guidance, and propose concise additions to fix the issue.
Add the proposed rule and retest the scenario. The MCP connection allows Codex to analyze Fin data, but Codex cannot directly change Fin’s setup. Waqqas adds the new guidance himself, then runs the same type of conversation again. If Fin repeats the mistake, he gives Codex that conversation’s chat ID and asks it to pinpoint which instruction is still causing the issue.

‘AI & I’: Granola looks beyond meeting notes

On this week’s AI & I, Granola cofounder and CEO Chris Pedregal says running a startup is “a knife fight” that never ends. The company built its name—and achieved a $1.5 billion valuation—on making a killer AI notetaker, but it can’t coast: Notion, OpenAI, and Zoom now offer tools that transcribe and summarize meetings, too.

Chris tells Every CEO Dan Shipper that the larger battle is over “what interface we use for work and what work looks like in an AI-native world.” That’s why Granola plans to own the work around meetings: preparing people beforehand, helping them act afterward, and making meeting context available to whatever agent they use.

Over the next few months, Granola plans to improve its API and MCP so it can be a leader in this space. “There’s an incredible opportunity ahead, and we have a shot at it, along with a few other companies,” Pedregal says.

He’s bullish on the company’s direction and strategy but knows it’s still early days—the knife fight will never be over.

“When people say, ‘Granola’s doing really well,’ in my mind it’s easy come, easy go,” he says. “Meeting notes are useful, but a lot is going to change, and just because people use us today doesn’t mean they’ll use us for that in the future if we’re not the best at the next thing.”

Watch on X or YouTube, or listen on Spotify or Apple Podcasts. You can also read the transcript.

Pulse Check

Spiral’s general manager settles in with Sonnet 5

Initial reviews of the model here at Every were lackluster at best. Two weeks into testing Sonnet 5 in his workflows, Marcus Moretti finds the sentiment largely holds—although he has found an area where Sonnet 5 justifies its existence.

Sonnet generates most of the text in Spiral, Every’s writing app. Spiral billing is token based, and Sonnet 5 was announced to use around 30 percent more tokens for similar outputs than Sonnet 4.6. That was a big reason not to drop it into Spiral. On another, internal product, swapping in Sonnet 5 produced more formatting errors and lower-quality responses. Not wanting to pay more for worse results, we reverted to Sonnet 4.6 after a few days of testing—and decided to keep Spiral running on 4.6 until the next release.

That said, Sonnet 5 does appear to perform well at the specific task of analytics reporting. On several products, we run the compound engineering /ce-product-pulse command—essentially a product health report—on a daily loop. Sonnet 5 does this really well.

For those kinds of recurring, tightly scoped tasks, Sonnet 5 balances affordability and performance.—Marcus Moretti

Head of platform Willie Williams’s Sonnet 5 review. (Screenshot courtesy of Willie.)

Log on

Get hands-on with how Every uses AI. These are the live camps, workshops, and meetups where team members teach the workflows behind our work.

Upcoming events

Every IRL (July 15): An in-person meetup at Every’s Brooklyn headquarters, for paid subscribers only, from 6–8 p.m. ET. RSVP.
Office Hours: All Access Builders (July 24): In the kick-off to what will be a recurring series, the Every team will share how we use the tools in the Builder Pack, before working through member questions and projects together. Bring one thing you want to build or improve. This virtual event is only available to All Access members.

Net new jobs

The chief AI officer role is growing

More non-technology companies are adding this position to the leadership team in an effort to understand how best to use AI and measure its impact. HSBC, Deloitte UK, and the international law firms Pillsbury and Ropes & Gray all recently announced they made their first chief AI hires, an acknowledgment that the technology is “now a C-suite responsibility,” per Bloomberg Law.

Companies want AI influencers

To stand out in the very crowded AI space, startups are turning to AI influencers or, as Morning Brew co-founder Alex Lieberman calls them, “full-stack AI creators.”

The goal is to hire someone who can be the next Andrej Karpathy, Boris Cherny, or Aaron Levie by developing

a cult-like personal following. So what does the role look like in practice? Per Lieberman, “You build with AI. You talk about what you build. You teach people how to use AI through content.”

Prompt engineers are out. Content engineers are in.

Out-of-work editorial professionals looking to cash in on their skills once scoured LinkedIn for “prompt engineer” positions—a category that’s evolved into job postings for “content engineers,” writers or editors who build a system for producing high-quality AI-generated text. (A similar trajectory is happening in design: Companies are looking for people who can build systems to create design components.)

Cursor is hiring a design engineer. (Screenshot courtesy of Laura Entis.)

Curating the feed

We share our favorite people to follow on X

Staff writer Katie Parrott recommends:

Ethan Mollick (@emollick), Wharton professor and AI thought leader: “He’s way out there on the edge of what’s possible and also does a good job of surfacing credible academic research and making the consequences of developments feel accessible.”
Zara Zhang (@zarazhangrui), AI builder and open-source creator: “She’s expanded my idea of what’s possible with skills.”

Marcus recommends:

Simon Willison (@simonw), independent open-source developer: “I tend to pay attention to people [on X] who are serious engineers and who call BS on fake AI productivity theater stuff,” Marcus says. You don’t get much more serious than Simon—the co-creator of the popular Python framework Django. “He’s a legendary engineer,” according to Marcus.
Ryan Dahl (@rough__sea), software engineer: “Ryan is in the same bucket. He created Node.js and is now working on Deno, [a runtime for JavaScript and TypeScript].”

Head of tech consulting Mike Taylor recommends:

Riley Goodside (@goodside), former prompt engineer at Scale AI and Google DeepMind: “There are some people who make a habit of being early on AI stuff,” Mike says, and Riley Goodside is one of them. “He was the first person to call himself a prompt engineer,” and went on to work at Google DeepMind.

Head of platform Willie Williams recommends:

Jeffrey Emanuel (@doodlestein), open-source developer: “He’s a bit crazy, but there’s also a decent chance he’s living in the future. He’s figured out how to harness 10x more agents than most people use together in a way that makes them productive. A decent analogy: He has a factory when everyone else has a workshop.”

One last thing

Links worth a click

New York enacts a one-year ban on data centers. Could AI solve the labor shortage crisis? Anthropic is looking for a standards editor, or “comma queen,” with a base salary that starts at $265,000. Unpacking chatbots’ love of “it’s not X, it’s Y.” AI is creating more work for lawyers. RIP Muse Image, Meta’s first image-generation model. Nobel laureates and tech leaders unite to warn about the potential dangers of AI. Leadership changes are afoot at OpenAI. If a song was made with AI, it might need a label. There are a lot of bad ChatGPT flyers out there. A new headache for managers. The white-collar professionals teaching AI how to do their jobs.

Laura Entis is a staff writer at Every. You can follow her on LinkedIn.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

We build AI tools for readers like you. Write brilliantly with Spiral. Organize files automatically with Sparkle. Deliver yourself from email with Cora. Dictate effortlessly with Monologue. Collaborate with agents on documents with Proof.

For sponsorship opportunities, reach out to sponsorships@every.to.

Introducing Every All Access

Dan Shipper / On Every — 2026-07-14 15:15:00 -0400

by Dan Shipper

in On Every

Every illustration.

TL;DR: Today we’re launching Every All Access, a new annual membership for builders who want to do their best work with AI. Its headline benefit is the Builder Pack, which includes $1,000 in Codex credits plus more than $6,000 in additional credits and trials from the tools we use to run Every—Claude Max, Cursor Pro+, PostHog, Notion Business, Render, Framer, Flora, Gemini, and AgentMail. All Access includes everything in an Every membership, plus unlimited use of Cora and Spiral, and exclusive programming with our team. Existing members can upgrade, and we’ll automatically credit the unused portion of your current plan at checkout.

Join Every All Access

This is the best time in history to build something.

For a long time, it’s been possible to one-shot impressive demos, but they’d fall flat the minute they hit production. The release of Fable 5 and GPT-5.6-Sol heralds a new era: Everyone can build, launch, and maintain the software that they’ve always dreamed of. Everyone is a builder now.

There’s just one catch: Building with AI is very expensive. (Ask me how I know.) (Alright, I’ll tell you. I accidentally used 2 billion tokens overnight this week on a big GPT-5.6-Sol run. Worth it.)

This is unique in the history of technology. For most of the personal computing era, a billionaire and a solo builder could buy essentially the same top-of-the-line Mac. AI changes that: The more tokens you can afford, the more you can make.

And we want to make that accessible to more people. That’s why the main feature of our new All Access plan is the Builder Pack: more than $7,000 in credits and discounts on the full stack we use to run Every, from idea to production—Codex, Claude, PostHog, Render, Gemini, FLORA, and more.

Early-bird membership is only $500 for the next 24 hours—and the Codex credits alone are worth $1,000. I could’ve used that for my overnight run this week. Now we’re handing it to you.

Meet the Builder Pack

All Access is our new annual membership. The Builder Pack is its biggest launch benefit.

It includes more than $7,000 in offers from 10 of the AI products we use to write, design, build, and run Every:

Build

$1,000 in Codex credits plus one month of ChatGPT for business
Twelve months free of Cursor Pro+
One month free of Claude Max
Three months free of Google AI Pro

Design

One year of Framer Pro
One month of Flora Max

Host

$300 in Render credits

Improve

$4,000 in PostHog credits
Six months free of Notion Business
Six months free of AgentMail

We rely on these products every day. We use OpenAI and Anthropic models across the company. We build software in Cursor, run product analytics in PostHog, organize work in Notion, deploy on Render, make sites in Framer, and create with Flora. The Builder Pack gives you access to the same toolkit at roughly 90 percent below its market value.

What comes with All Access

All Access is the membership around the Builder Pack. It includes:

Everything in an existing paid Every membership: our daily writing, guides, camps, and software like Monologue, Cora, Sparkle, and Spiral
The Builder Pack, with more than $7,000 in partner offers
Unlimited email accounts on Cora and unlimited Spiral usage
Members-only programming with the Every team and me

The first event is Office Hours: All Access Builders on Friday, July 24. Bring one thing you want to build or improve in the next few weeks. We’ll show you how we use the Builder Pack inside Every, then work through member questions and projects together.

If you’re already an Every member, you can upgrade without losing what you’ve paid for. We’ll automatically apply the unused balance of your current plan at checkout. If you’re a free subscriber, All Access gives you the full Every membership along with the Builder Pack and the rest of the benefits.

Join Every All Access

Put a stake in the ground

Buying a new tool will not make you a builder. Neither will reading another article about AI.

But there is power in making a commitment to build something this year. All Access is for people making that commitment.

We’ll give you the tools we rely on. We’ll share what we learn as we use them. We’ll bring members together to work through the difficult parts. And we’ll keep adding new Builder Pack partners and All Access benefits as the frontier moves.

There has never been a better time to start.

Join Every All Access

Dan Shipper is the cofounder and CEO of Every, where he writes the Chain of Thought column and hosts the podcast AI & I. You can follow him on X at @danshipper and on LinkedIn. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

We also do AI training, adoption, and innovation for companies. Work with us to bring AI into your organization.

Discover Every’s upcoming workshops and camps, and access recordings from past events.

For sponsorship opportunities, reach out to sponsorships@every.to.

The Urge to Merge (ChatGPT and Codex)

Katie Parrott / Context Window — 2026-07-14 09:10:00 -0400

by Katie Parrott

in Context Window

Midjourney/Every illustration.

After OpenAI released GPT-5.6 Sol on Thursday, Anthropic reset Claude’s five-hour and weekly usage allowances for all users, presumably to give people more time to use Fable before it leaves Claude plans and moves to the API. Some saw the move as a bid to keep users from defecting to OpenAI’s hot new model. Thibault “Tibo” Sottiaux of the Codex and ChatGPT team quote-posted Anthropic’s announcement with three words: “I smell fear.”

OpenAI and Anthropic are fighting to become the home for agentic knowledge work. OpenAI is merging Codex into ChatGPT. Anthropic is adding a browser to Claude Code and extending Fable access. Power users mix labs anyway. Today we bring you the merge drama, a workflow that puts Fable in charge of cheaper models, and the upside of our model parents fighting: Christmas in July

While we have you: Today we’re launching Every All Access, a new $625 annual membership that sits above the current Member tier and bundles unlimited access to all five Every products with the Goodie Bag—curated partner discounts from Cursor, Notion, Framer, Anthropic, PostHog, and others.

Learn about All Access

If you’re already a Member, you can upgrade now at every.to/subscribe.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Signal

Codex is dead. Long live Codex.

OpenAI found out how much people loved Codex by renaming it ChatGPT.

Five months after releasing Codex as a standalone app, OpenAI folded it into the new ChatGPT desktop app last week and relabeled the previous ChatGPT app “ChatGPT Classic.” The new app has three modes: Chat for questions, Work for longer assignments across tools, and Codex for developer workflows.

We’re on the record as loving Codex. We wrote a whole guide about it and rebuilt many of our workflows around it. But since the merge, we’ve barely noticed. Coders are still coding in Codex. I toggled into Work during a meeting, kept drafting, searching files, and pulling from Slack, and didn’t realize until later that I’d switched.

ChatGPT Work looks suspiciously similar to Codex while removing some of Codex’s more technical features, like a dedicated space for pull requests. (Image courtesy of Katie Parrott.)

You wouldn’t know that if you were on X that day. Backlash to the move among Codex lovers was immediate and vocal. Developer and YouTuber Theo Browne called the merge a “generational fumble.” Redditors complained of duplicate apps, buried chats and projects, broken plugins, and unclear limits. One thread called the release and the communication about what was happening with Codex “mayhem.” The company appears to have decided that alienating some power users is worth potentially gaining a larger audience for Codex: ChatGPT has more than 800 million weekly users—orders of magnitude larger than Codex’s 5 million weekly users. The merge is a bet that the features that made Codex so compelling for its fans, like file access, tool use, and the ability to carry out tasks across long time horizons and multiple turns, will reach more people inside a product they already know.

OpenAI isn’t the only frontier lab experimenting with how it packages its products. After launching Cowork on Claude Code’s agentic architecture to win over more knowledge workers in January, Anthropic has now put Chat and Cowork in one “home” tab. Both moves aim to introduce chat interface users to the possibilities of AI agents.

Underlying these changes is a shared bet that agentic work is where the technology is moving. Both labs want their flagship assistant to become the place where any knowledge-work task begins: Give the model files, tools, and a sustained assignment, then let it act. Whether OpenAI or Anthropic succeeds will depend on how well their general-purpose apps serve newcomers while preserving the control, context, and reliability power users expect.

What to do this week: For Codex lovers, switch to ChatGPT Codex and carry on as usual. But if you’re agent-curious and haven’t made the leap to agent-driven interfaces, here’s how to get started in Codex: Give it one defined assignment using your files and a concrete deliverable. Require approval before Codex sends messages or changes anything outside the app. You can test agentic work without first learning how to use a coding agent.

Steal this workflow

Put fancy models in charge of affordable ones

During our GPT-5.6 launch livestream, ChatPRD founder Claire Vo described her relationship with Fable 5: “What Fable does is none of my business.” She can say that because she treats Anthropic’s most expensive model as a senior consultant instead of a daily driver. Fable plans the job, delegates bounded tasks to cheaper models, and reviews what comes back.

Claire is part of a broader trend among power users who use the smartest, priciest model as the boss and let cheaper models do the grunt work. Every CEO Dan Shipper takes the pattern one step further by crossing model labs, which requires Claude and Codex to share the same brief and project files. Fable leads. GPT-5.6 Sol executes.

Here’s how to set it up, first for working with models within the same family, then for working across different models:

1. Easier: Fable → Sonnet inside Claude Code. Ask Claude Code to create .claude/agents/sonnet-worker.md in your project. The file registers a Sonnet worker—the cheaper, less capable model—that Fable can call:

          Code snippet
          Other
        

---
name: sonnet-worker
description: Executes bounded briefs without changing the plan
model: sonnet
---
Implement the brief. Report changed files and tests.

Restart Claude Code or run /agents to load the worker. Start on Fable: Describe your task and then tell it, “Write an implementation brief, delegate it to sonnet-worker, and review the changed files and test results before you finish.” Fable plans the work, opens a separate Sonnet context to execute it, and receives the result for review.

2. Advanced: Fable → Sol across Claude and Codex. This setup lets Claude and Codex hand work to each other. Fable is a strong planner and reviewer, while Codex is a capable implementer. You stay in one conversation with Fable and give it a task you’ve already thought through. It delegates the coding to Sol—like an editor who owns a story, assigns the draft to a writer, and reviews it when it’s completed.

To wire it up, install and sign into both command-line tools and open Claude Code in the shared project. Ask Claude Code to create .claude/skills/sol-worker/SKILL.md:

          Code snippet
          Other
        

---
description: Delegates bounded implementation work to GPT-5.6 Sol
---
Write the task to .agent/sol-brief.md, creating the directory if needed. Run codex exec -m gpt-5.6-sol -C "$PWD" - < .agent/sol-brief.md. Review the changed files and return the result.

Then tell Fable: “Use the Sol worker to implement the settled brief. You own the plan, any scope changes, and final review.” Fable writes its brief to a shared file, launches Sol in the same project directory, and returns the changed files for our review. You never leave Claude Code. Sol does the implementation work in the background.

Do this week: Give one AI worker a small assignment with a settled spec and an objective check—for example, “Add CSV export to this dashboard and run the existing tests.” If Fable has to redo most of the output, the cheaper model is not saving you anything yet.

Data point

53 percent

How much an AI agent’s error rate fell in a new paper after it stopped rewriting code from scratch for steps it had performed before. Instead, the agent saved what worked as a reusable tool. When it encountered the problem again, it used the tool. Once your agent figures out a recurring task, keep the method and let the results compound into a better outcome next time.

Log on

Get hands-on with how Every uses AI. These are the live camps, workshops, and meetups where team members teach the workflows behind our work.

Upcoming event

Every IRL (July 15): An in-person meetup at Every’s Brooklyn headquarters, paid subscribers only, from 6–8 p.m. ET. RSVP.

What we’re reading

“AI 2040” is a new policy scenario from the AI Futures Project. The group’s earlier report, “AI 2027,” released last year, imagined AI automating AI research and reaching superintelligence within a year. AI 2040 proposes a slower alternative: The U.S. and China make AI research public, hold development at roughly human-expert capabilities, and delay superintelligence until 2040.
“AI-Native Firms”, a working paper from INSEAD’s Hyunjin Kim and Harvard Business School’s Rembrand Koning, finds that AI-native startups are 25 percent smaller than non-AI startups in the same industry and time cohort, with more engineers and fewer junior workers and managers.
“The Future Worth Building Is Human” is the thesis behind what Thinking Machines Lab is building: customizable models and interfaces that users can shape over time. The post argues that this approach is necessary because much of an organization’s valuable knowledge is tacit and local—and therefore difficult for a general-purpose model to capture.

Discuss

“this is like your parents fighting and getting two christmases”—X user Sophie, after Anthropic extended Fable access through July 19

Anthropic has pushed Fable’s paid-plan cutoff from July 7 to July 12 to July 19 and kept Claude Code’s weekly limits 50 percent higher than standard. The model wars have an upside: Users are getting higher limits, longer promotions, and more included access. But Christmas always ends. Use the bonus time to benchmark Fable. Decide which work justifies the expensive model before the next deadline moves—or doesn’t.

Katie Parrott is a staff writer. She writes Working Overtime and contributes to Vibe Checks, Source Code, and Context Window. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

Write brilliantly with Spiral. Organize files automatically with Sparkle. Deliver yourself from email with Cora. Dictate effortlessly with Monologue. Work on documents with AI agents using Proof.

For sponsorship opportunities, reach out to sponsorships@every.to.

How I Polish Software That Agents Built

Kieran Klaassen / Source Code — 2026-07-13 12:36:25 -0400

by Kieran Klaassen

in Source Code

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

For most of the history of making software, writing code was the work. You spent your days typing out functions, fighting errors, debugging migrations, and reading through other people’s code to figure out why a function did what it did. Another day in the code factory.

That’s mostly over. With a good brainstorm and a well-structured plan, today’s models will write code, run tests, fix failures, and hand you back a clean pull request with code changes ready for review. I’ll open my laptop in the morning to a stack of green pull requests that agents shipped overnight, with features ready to merge before my first meeting. The factory has been automated.

What I’m left to do is sit with the result and decide whether it’s any good—and then push it further than the agent could take it itself. A model doesn’t know what I would call good, sitting in front of this feature in this product I’m building for these users. Without that final human judgment, everything the agent produces is functional, but forgettable. A few weeks ago I clicked on an email card in Cora and knew instantly the animation was wrong—it slid in from the top of the screen instead of opening from where I’d clicked mid-screen. I told the agent, it fixed it, and I clicked again—better.

Polish is the final step in compound engineering—the discipline I’ve been developing over the past year for building software in a way that gets smarter with every iteration. As more of the middle parts of the process gets automated, polish matters more now, because it’s the part of the work that’s still yours. Instead of the assembly line worker putting the code together, you’re the person at the end of the line who decides whether it’s good enough to put your name on.

Polish in practice

The card animation that looked wrong is a good example of how polish works, because animation is something that agents still struggle with (although it will improve over time).

The pull request had passed every automated check. The review agents had nothing left to flag for me. I ran /ce-polish—part of the compound engineering plugin—which does three things and then gets out of my way. It checks out the branch I want to polish, starts the development server in the background, and opens the running app inside my editor, right next to the agent. From there, I clicked on an email card to open it and started my assessment.

The updated version of the Cora Brief in development, which I refined using the polish step. (Image courtesy of Kieran Klaassen.)

Once the new design was open beside the agent, I could see that it still felt too loose. There was too much whitespace, and the cards needed to be more compact. I said so out loud via Monologue. The agent tightened the layout; the app hot-reloaded; I looked again—better. A plan could tell the agent to make the Brief feel like a magazine. It couldn’t tell the agent when the page had the right density. I had to see it and decide for myself.

This is what polish looks like: a conversation between me, the running app, and the agent. The whole setup—/ce-polish, the side-by-side layout, the hot-reloading dev server—exists to keep that conversation fast enough that I never lose the thread of what I was looking at, like the exact pixel I was squinting at or the subtle difference I was trying to name. Adding steps like finding the file, switching windows, or pasting context for the agent would break the rhythm. Polish is the kind of work that only happens when you can stay in the flow.

It’s also what makes polish strange compared to the other steps in compound engineering. Plan dispatches subagents to draft a structured specification. Review fans out parallel reviewers, each looking for a different class of issue. Ideate runs a divergent brainstorm and scores the survivors against confidence and complexity. Every other step is built around orchestration and structure—agents on top of agents, with templates and rubrics holding the work in place. Polish is the opposite. There are no agents because agents can’t decide whether the thing on screen matches the thing I meant to build.

What polish changed about the rest of the loop

I knew polish would change the end of the loop. What I didn’t expect was that it would change the rest of it, too.

Planning got sharper because I started writing plans that anticipated what I’d want to feel during polish, not just what I’d want the code to do. Reviewing got less anxious because I no longer had to catch every issue at the diff stage—I knew there was a later step that would catch the things only a person using the app could see.

The constraint on my workflow used to be how fast I could ship. Now, with agents, it’s how good I can make it. Spend the extra time on polish, and the software gets better.

Perhaps the biggest upgrade is to compound, the step where lessons from the loop get written down for the agent to pick up next time. Most of those lessons used to come from failures of correctness, like whether code uses the right conventions. After polish, the lessons started carrying taste. In the case of Cora, it’s things like animations that resolve toward the click, or scroll bars that hide unless invoked. Each one started as something I muttered at the browser and turned into a rule the system applied the next time, without me asking again.

This is how polish compounds. The first time I caught the wrong-direction animation, I had to say so. On the next feature with a card in it, the agent formatted the right animation by default.

The work that’s left for me to do

The work that used to define a great engineer is mostly done by agents now. What I now have to do is decide whether the work is good enough—then push past good enough to something that feels like it was made by a person who cared. The bar of what’s possible to ship in a day has gone up, so the bar of what’s worth shipping has gone up too.

Because agents did the building, the cost of saying “this isn’t it—replan the whole thing” has all but disappeared. All it needs is an afternoon of agent time and a few dollars of compute. Your job changes from protecting your time to protecting the quality of what you’ve built.

If you want to try it, here’s a headstart: Pick a feature you’ve shipped recently—ideally one with a user interface, where the gap between whether it works and is good shows, like an onboarding flow, a landing page, an animation, or a settings screen. Skip infrastructure for now. Start where your users will feel it.

Install the compound engineering plugin—it works in Claude Code, Cursor, Codex, and a dozen other agent harnesses. Run /ce-polish on the branch and let it do its three things. When the app comes up, use it. Click everything. Don’t review the code or take notes. Your instinct that this isn’t quite right is the only thing you’re trying to listen for. When you find something, say it out loud to the agent. Watch to make sure the change does what you want, then move on to the next thing.

When you’ve made three or four changes that could apply beyond this feature, run /ce-compound to codify those preferences into rules for the system to follow next time, on its own. After a few Polish sessions, you’ll have a small standing library of taste, and the next feature you build will start that much closer to great.

Want more compound engineering? Check out the compound engineering guide to learn the rest of the loop, and read the essays in this series that cover planning, reviewing, and compounding.

Kieran Klaassen is the general manager of Cora, Every’s email product. Follow him on X at @kieranklaassen or on LinkedIn. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

Thanks to Katie Parrott for editorial support.

Discover Every’s upcoming workshops and camps, and access recordings from past events.

For sponsorship opportunities, reach out to sponsorships@every.to.

From Doing to Tending

Every Staff / Context Window — 2026-07-12 12:21:00 -0400

by Every Staff

in Context Window

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Mini-Vibe Check: Grok 4.5 is fast, cheap, and finally useful

Almost a year ago, we vibe-checked Grok 4 and found a model that performed well on benchmarks but was not useful enough for our engineers to use every day. Our April Vibe Check of Cursor 3.0 found a promising but unfinished agent-orchestration product, but that verdict aged quickly: Kieran Klaassen was using Cursor daily by the end of the month, and by June Composer 2.5 was his main model for final polish. Then, in June, SpaceX signed an agreement to acquire Cursor, and a new candidate for the AI frontier space race was born.

Grok 4.5 is the first result of that collaboration. Cursor says it jointly trained the model with SpaceXAI using data from interactions with codebases and software tools.

When our team ran Grok 4.5 through the evals we use internally, the consensus was that it is an Opus-level model. Mike Taylor’s latest benchmark put it slightly above Claude Opus 4.8: Grok followed every step and returned a complete, polished result, while Opus stopped early or skipped parts of the assignment.

Mike shared his early impressions of Grok-4.5 on X, including what he deems Opus-level PowerPoint creation. (Image courtesy of X/Mike Taylor.)

Kieran ran Grok 4.5 through /LFG, Every’s compound-engineering workflow for planning, building, reviewing, and improving a project. He put it around Claude’s Opus 4.5-to-4.6 range, calling it “not state of the art, but pretty good for a lot of things, and very fast.”

Grok’s biggest competitive advantage may be its impact on the bottom line: xAI says Grok 4.5 runs at roughly 80 tokens per second and about twice the token efficiency of leading models. At $2 per million input tokens and $6 per million output, it is also much cheaper than the frontier models Every compared it with: Claude Opus 4.8 costs $5 and $25, while GPT-5.6 Sol costs $5 and $30.

In our other tests, Grok held its own at vibe coding and generative user interaction, spinning up a working voice-interview form, a neighborhood map app, and a convincing clone of Mike’s writing style. Mike rated its PowerPoint-style slides around the level of Opus 4.6 or 4.7 and called the copy quality “pretty great,” singling out one headline Grok wrote on its own: “Forms that talk back.” The map app was not quite as sharp as work from the latest frontier models, and Mike still prefers Sol for writing. Grok avoids some of Claude’s familiar AI writing tics but has its own habit of producing short, sharp sentences.

You probably do not need to swap out your daily driver. But if you already work in Cursor, Grok 4.5 is right there, and it has earned a slot for long, multi-step assignments where speed, price, and follow-through count more than the last few points of quality.—Katie Parrott

Knowledge base

“GPT-5.6 Sol Is Our Favorite Model to Collaborate With” by Katie Parrott/Vibe Check: Tested across coding, writing, research, spreadsheets, and agents, Open AI’s GPT-5.6 Sol is the model most of the Every team wants open all day—fast, resourceful, easy to steer, quick to find files, hold context, and turn out another pass while the decision is still fresh. Fable still gets the biggest, loosest assignments, but Sol runs everything else. Read this for the clearest guidance yet on which model should get which job.

“How GPT-5.6 Changes Knowledge Work” by Dan Shipper/Chain of Thought: We open-sourced Tend, a free, open-source prompt and repository for building loops that run your knowledge work; it gathers information, proposes decisions, and carries out the ones you approve while you make the key calls. Tend is a direct reflection of Dan’s argument that GPT-5.6 is the first model able to run a whole loop of knowledge work on its own—so you tend the loop instead of doing the work yourself. Grab the prompt and build your own loop at every.to/tend.

“Use Fable Before You Know What to Ask” by Katie Parrott/Context Window: Fable earns its premium on the jobs where you don’t yet know the right question, where the goal or standard itself is still unsettled. Mike handed it his finished book manuscript to catch what he’d missed, and Dan Shipper spent five weeks on copy-editing experiments before Fable told him the goal he’d been chasing was wrong all along. Also inside: Head of social media Becky Isjwara has Fable write a reusable manual so a cheaper model can clip her livestreams, and product leader Trevin Chow’s /ce-pov skill makes an AI weigh a new tool against your own codebase instead of judging it in the abstract.

“Welcome to Efficiencymaxxing” by Laura Entis/Context Window: AI’s cheap-novelty era is over: As models grow token-hungry and the labs pull back subsidies, people are done bragging about how many tokens they burn (tokenmaxxing) and starting to compete on what they get for them (efficiencymaxxing). Also inside: Monologue general manager Naveen Naidu on “revenue per million tokens,” the metric making the rounds at Apple’s WWDC as a successor to revenue per employee, and Spiral general manager Marcus Moretti on using OpenRouter to run a stack of cheaper models for the jobs that don’t need a frontier one.

🎧 🖥 “How a Writer Uses AI Without Losing His Voice” by Dan Shipper/AI & I: Writer and technologist Craig Mod joined Dan to explain why cheap software creation has made him more protective of his writing: He says it “puts a higher premium on intent.” He vibe codes replacements for SaaS tools with Opus and Fable, and writes every word himself—keeping a WiFi-free MacBook for the job—because “being in the mess of writing” is the point. Watch or listen to this for a working line between where AI belongs in a creative practice and where it doesn’t. 🎧 🖥 Listen on Spotify or Apple Podcasts, watch on YouTube, or follow the discussion on X.

Log on

Get hands-on with how Every uses AI. These are the live camps, workshops, and meetups where team members teach the workflows behind our work.

Upcoming event

Every IRL (July 15): An in-person meetup at Every’s Brooklyn headquarters, paid subscribers only, from 6-8 p.m. ET. RSVP.

From Every Studio

Monologue puts your notes on the web

Monologue, Every’s voice dictation app, now keeps your notes on the web and lets you edit them: open any note in a browser at app.monologue.to—from Windows, Android, or your phone, not just the Mac app—to rename it, retag it, regenerate its summary, or name the speakers. You can also wire a webhook so a finished note triggers your other tools.

Alignment

Manual flying. About five years ago, as a young resident doctor on a cardiology ward, I got an almighty bollocking from an attending who savaged the history I had written in a patient’s notes. In my defense, I wrote it on my third night shift, held together by an ungodly amount of caffeine and adrenaline.

At the time, I would have killed for an AI scribe. But Dr. Helen Ouyang, an associate professor of emergency medicine, argued in a recent New York Times essay that writing is an integral part of the clinical reasoning process—it forces you to recall information and synthesize the key points that lead to a decision. The danger of using AI scribes, she argues, is cognitive off-loading: the muscle that allows them to reason through a case and arrive at sound clinical judgment on their own.

Aviation has learned this the hard way. Autopilot is an extraordinary development—it makes flight safer and less exhausting. But when automation handles most of the routine work, pilots can be dangerously reliant on it, their manual flying skills atrophying. The solution was mandated simulation training so pilots stay sharp for the moments when the system fails or hands control back.

Medicine will follow the same arc. First, we’ll automate too much—because it reduces burnout and documentation misery. Then we’ll panic about skill loss. Eventually, I hope, we’ll land somewhere sensible: AI scribes for routine cases, manual reps and simulation mandated for students, young doctors, and anything complex.

I missed the AI scribe era by a few years and have since moved into health tech. But I know exactly what the younger version of me would have done after that bollocking. He would’ve still turned the thing on.—Ashwin Sharma

That’s all for this week! Be sure to follow Every on X at @every and on LinkedIn.

We build AI tools for readers like you. Write brilliantly with Spiral. Organize files automatically with Sparkle. Deliver yourself from email with Cora. Dictate effortlessly with Monologue. Work on documents with AI agents using Proof.

For sponsorship opportunities, reach out to sponsorships@every.to.

Upgrade to paid

How GPT-5.6 Changes Knowledge Work

Dan Shipper / Chain of Thought — 2026-07-10 11:37:39 -0400

by Dan Shipper

in Chain of Thought

Midjourney/Every illustration.

TL;DR: GPT-5.6 is the first model I’ve used that can reliably run whole loops of knowledge work, not just help with individual tasks. Your job turns from doing the work to tending the system that does it. If you want to try this for yourself, we’re open-sourcing a prompt and repository called Tend so you can try working this way in ChatGPT Work.

Experiment with Tend

GPT-5.6 heralds a new way of doing knowledge work.

Instead of using AI to complete one task at a time, you build a system that scans the available information, turns it into proposed decisions, and carries out the ones you approve. Over time, the system compounds your feedback to do more and more on its own.

This changes your job. It requires you to see your work as—dare I say it—a loop. You go from doing all of the work yourself to tending the system that does it for you:

The knowledge work loop, with human judgment at the center. (Image courtesy of Dan Shipper/Claude/GPT Image.)

Take email. I used to go through my inbox like this: Email comes in, I read it, I reply, I archive. (Or, email comes in, I open it, I close it, I wait several weeks, I open it again, I archive it.)

With GPT-5.6 Sol in the new ChatGPT Work app, formerly known as Codex, the process looks very different. GPT-5.6 Sol watches my inbox, decides what deserves my attention, does any necessary research, and presents each email with a concise summary and proposed reply. I either approve the draft or use Monologue to dictate what I want changed. Then I move to the next email.

At the end of each sweep through my inbox, the agent derives my preferences from my revisions and decisions and remembers them for next time.

It’s no coincidence this sounds like compound engineering; it’s the same philosophy—just applied to knowledge work. I’ve been writing about this shift for a few years: In early 2024 I argued that much knowledge work would become managing agents, and later that it would look like tending to a garden—creating the conditions for work to happen, rather than doing everything yourself directly. This isn’t a new way of working: Managers and entrepreneurs have done it for decades, and as models improved over the past year, programmers adopted it, too. Now it’s knowledge work’s turn.

This approach won’t work for every kind of knowledge work, and it’s still early. But where it works, it creates a remarkable kind of leverage.

What makes GPT-5.6 Sol and ChatGPT Work different

GPT-5.6 Sol crosses the threshold that makes a continuous knowledge-work loop practical. It can scan your sources, identify what’s relevant, carry out approved work, and build custom tools for itself as needed. It can do all of this reliably even if you can’t code—and it can explain all of this to you in a way that’s understandable.

It’s also fast and cheap enough that you can iterate rapidly—a crucial requirement for non-technical users who are going to make mistakes and need to see the results of a run before knowing if it’s good.

Sol inside of ChatGPT Work is even better: Its in-app browser lets it use any website alongside you, and its powerful computer use function lets it operate any app on your machine. It also has Chronicle, a feature that periodically screenshots your computer to learn who you are and how you work, so it improves over time.

Fable can do all of the above, but it’s too expensive, too powerful, and too slow for non-technical users. It often speaks in its own language that even programmers have a difficult time understanding. The Claude desktop app can also do much of this, but it’s hampered by hard-to-understand security controls and differences between Claude Code and Cowork’s features and capabilities. 5.6 and ChatGPT Work just…work.

How to see the loops in your work

Most knowledge work happens in a three-step loop:

Gather and make sense of information
Make a decision and take action
Learn from the result

These loops predate AI. A product manager reviews feedback and data, chooses priorities, watches what happens after shipping, and carries the result into the next planning cycle. An editor reads a draft, gives feedback, notices recurring problems and accepted suggestions, and then edits with that in mind. A support lead handles a recurring problem, sees whether the answer sticks, and updates the playbook or flags it to the product team.

With GPT-5.6 in ChatGPT Work, the model takes on more of the work inside the loop. You still make the key decisions; you still choose what it pays attention to and how it improves over time. But your job now is to tend the loop.

Examples of loops you can tend

To make this clearer, here are some examples of the kinds of loops I’m using GPT-5.6 in Codex to tend.

Hiring: GPT-5.6 reviews applications, referrals, and candidates’ public work; looks for evidence of fit, craft, and a credible path of trust; then presents the strongest candidates with its reasoning and a proposed next step.
Running Every: GPT-5.6 reads meeting transcripts, Slack conversations, and company metrics; identifies decisions, open questions, risks, and unresolved commitments; then proposes the follow-ups that deserve my attention.
Furnishing my apartment: GPT-5.6 scans listings on Facebook Marketplace using my constraints and taste, compares price, condition, distance, and quality, and presents the best options with a draft message to the seller.
Editorial planning: An editor gathers news, Slack discussions, and unfinished drafts; decides what belongs in an issue; publishes it; watches what readers engage with; and uses that response to plan the next issue.
Customer research: A researcher gathers interviews and support messages, identifies recurring needs, proposes a product change, watches how customers use it, and turns the results into the next research question.
Consulting delivery: A consultant gathers client conversations and project data, identifies the next priority, produces a recommendation or deliverable, sees how the client responds, and folds that result into the next round of work.

Tend your work loops

To help get you acquainted with how your knowledge work happens in loops, we built an experiment called Tend. It’s a prompt and an open-source repository that will let you build loops for your work, whatever that might be.

Experiment with Tend

Here’s a screenshot of me using Tend to keep track of what’s happening at Every:

Image courtesy of Dan Shipper.

You can use Tend to tend any loop you want to experiment with, from your inbox to a hiring pipeline or customer service queue.

You can copy the prompt from GitHub, connect Cora, Gmail, Slack, or any other information source, and spend a few minutes teaching Tend how your inbox works.

Tend is open-source, so you can rewrite its instructions, add your own rules, or adapt the pattern to another recurring part of your job. We’re releasing it as an experiment. It’s meant for you to play with and learn from—but we’re not supporting it as an app, and we can’t promise stability or improvements.

Start by teaching Tend what deserves your attention. Then notice what happens: The inbox gets easier, the instructions get better, and another loop in your work begins to reveal itself.

Experiment with Tend

Dan Shipper is the cofounder and CEO of Every, where he writes the Chain of Thought column and hosts the podcast AI & I. You can follow him on X at @danshipper and on LinkedIn.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

We build AI tools for readers like you. Write brilliantly with Spiral. Organize files automatically with Sparkle. Deliver yourself from email with Cora. Dictate effortlessly with Monologue. Collaborate with agents on documents with Proof.

For sponsorship opportunities, reach out to sponsorships@every.to.

Welcome to Efficiencymaxxing

Laura Entis / Context Window — 2026-07-08 12:00:28 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

For a brief period, AI was an affordable novelty. Every use case felt like magic, and even the silliest task was worth a try when frontier labs were subsidizing compute costs to get consumers hooked. Power users proved their status by maxing out their token consumption.

Now, AI is ubiquitous—even required in many workplaces—and easy to use for anything from code to text to visuals. But this flood of production has a price: in cash, as powerful new models grow more token-hungry and the labs roll back those generous subsidies, but also in the time and effort required to make sense of the results. (If you’ve ever tried to debug an AI-generated codebase, edit AI-generated text, or decipher the meaning behind an AI-generated email, you know how labor-intensive it can be to wade through poor-quality LLM outputs.)

Focus has evolved accordingly from how much you’re using AI to how you’re using it—and what you can show for it. Does the benefit justify the significant cost?

Today’s Context Window explores various answers and solutions to that question. First up, author and technologist Craig Mod explains why cheap software creation has made him more protective of his writing time; Monologue general manager Naveen Naidu shares a new efficiency metric he heard making the rounds in San Francisco; senior applied AI engineer Nityesh Agarwal shows us how he audits agents for wasted tokens; and Spiral general manager Marcus Moretti explains how OpenRouter helps him manage a 12-plus-model stack.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

‘AI & I’: AI that helps you work on what you care about

AI is powerful. According to CEO Dan Shipper, it’s also a “slot machine.” How, then, can you use the technology to create stuff that matters while avoiding the hunt for the next dopamine hit?

To help answer that question, Dan had author and technology enthusiast Craig Mod on the show to discuss how to be ruthless about preserving his time.

Watch on X or YouTube, or listen on Spotify or Apple Podcasts. You can also read the transcript.

AI is great at making better versions of the products you already pay for. Mod’s been using LLMs—primarily Opus, more recently Fable— to vibe-code alternatives to SaaS products like the email marketing platform Campaign Monitor and personal finance software Quicken. The benefit is twofold: He can tailor the service to his exact specifications, and a $1,200-a-year Claude fee is way cheaper than paying for multiple subscriptions. “I think we’re going to enter this golden age of tool building,” Mod says. “There’s going to be more competition in the marketplace forcing more innovation”—a net-positive “except for incumbents.”
It puts a higher premium on intent. AI allows you to attempt all sorts of things that previously required years of expertise and training. The possibilities are dizzying, which makes it easy to lose sight of what you want to devote your energy toward in the rush of endless production.

Somewhat counterintuitively, the ease with which software can be made now has reaffirmed Mod’s commitment to writing. “There are plenty of people playing around with this stuff,” he says. “But there aren’t that many people who are going to think about or write the weird books I feel drawn to write, and as a human, that feels like the valuable thing for me to put my effort into.”

While he’ll use AI for research and fact-checking, he still writes every word himself. Outsourcing that process to an LLM would defeat the purpose when “being in the mess of writing” is the point—and the way to get the results he’s looking for.

Mod creates intentional barriers to maintain focus. He keeps his phone on a separate floor from where he sleeps—and does his best not to check it until after lunch—and writes on a dedicated MacBook that isn’t connected to the internet. As soon as his brain encounters WiFi, he says, “I feel the chemicals shift and I can’t go into any kind of deep thinking place, deep attention, deep focus.”

Miss an episode? Catch up on Dan’s recent conversations with LinkedIn cofounder Reid Hoffman; the team that built Claude Code, Cat Wu and Boris Cherny; Vercel cofounder Guillermo Rauch; podcaster Dwarkesh Patel; and others, and learn how they use AI to think, create, and relate.

Overhead in SF

A new AI status metric

While on the ground in San Francisco for Apple’s Worldwide Developers Conference last month, Monologue general manager Naveen Naidu noticed a new metric for measuring enterprise productivity making the tech-circle rounds: revenue per million tokens.

A purported measure of a company’s efficiency, revenue per million tokens is a potential successor to revenue per employee, a rough estimate for how much money each worker at a company generates. (AI-native companies tend to score significantly higher on this scorecard than their traditional SaaS counterparts.)

By explicitly tying ROI to how efficiently a company makes money with AI, revenue per million tokens acknowledges that engineering has become cheap while the cost of compute is more expensive than ever. Or more simply: “If you say, ‘I wrote a million lines of code,’ did it actually increase your revenue or not?” Naveen says.

Inside Every

A peek into a more token-efficient future

I’ve started to think of senior applied engineer Nityesh Agarwal as Every’s resident AI seer, particularly when it comes to Anthropic. Three to six months before the AI lab released a strategy to handle the problem of agent orchestration and team-based agent delegation, Nityesh had built his own version of a solution. He’s been sharp and early on understanding the architecture that allows an agent to access the context it needs to get work done on behalf of an entire team. (If you don’t believe me, read his piece on how Claude Code is a more reliable alternative to OpenClaw, written before pretty much anyone else saw its potential.)

So where is Nityesh focused now that Anthropic has essentially commoditized the model of shared, Slack-based team agents (like the ones he built for Every’s consulting and editorial teams)?

“Making the agent more token efficient,” he responds without hesitation.

Up until now, you could throw money at AI experiments because the cost was largely covered by a subscription model that subsidized heavy use under a set monthly price. Those days are numbered, Nityesh says. “We are in a compute-constrained world where we will not have enough data centers to run tomorrow’s AI.” Expect usage costs to go up, particularly for individuals as AI companies prioritize big-budget enterprise customers.

At the same time, cheaper models—many of them open-sourced—have grown more capable, operating, by Nityesh’s estimation, roughly seven months behind the frontier.

Here’s how Nityesh is thinking about token efficiency:

Routing. The simplest version is to bake a model choice into a skill’s instructions, so that skill always defaults to a cheaper model for that task. Dynamic workflows—Anthropic’s orchestration feature for large, multi-agent Claude Code jobs—do this natively, letting you assign a specific model to each component of a job. It’s a “first-class” option, Nityesh says, but with a major caveat: You can only choose from Anthropic’s own models, not open-source options or those from OpenAI.
Evaluations. Before you route a task to a cheaper model, you need to evaluate whether it can execute without a drop in performance.. That’s hard to do because LLMs are “inherently bad at assessing their own capabilities,” Nityesh says. Creating good evaluation sets requires manual, good-old-fashioned human judgment. The stakes are high: “If you have good evals, then you lower the cost. But if you have bad evals, you’re getting bad signal,” he says.
Token audits. After an agent has completed a task, Nityesh has it break down how many tokens it used per step. He then reviews each one, identifies areas where token spend appears excessive for the complexity of the required work, and has the agent explain why it burned through so much compute. It’s a manual process; for all their intelligence, LLMs aren’t good at identifying their own inefficiencies. “If an AI tells me that it used 20 million tokens for reviewing the outputs, that’s a red flag because I know that [outsize number] doesn’t make sense,” Nityesh says. “But AI doesn’t have that intuition yet.”

Try it this week: Audit one repeated agent workflow.

Run it once and collect the receipts. Ask your agent: “Audit this run. Break down token use by stage. For each stage, report the model used, approximate input and output tokens, the purpose of the step, and why that amount was necessary. Mark anything you cannot verify as an estimate.”
Investigate any particularly token-hungry steps. Look for a mismatch between the difficulty of the work and the tokens consumed. The agent can explain its behavior, but you need to review and determine what seems unreasonable.
Change one variable and rerun the test. Trim the context, rewrite the skill instructions, split the work among subagents, or route one step to a cheaper model. Compare token use and output quality with the first run. Keep the change only if the result still passes your quality check.

Tool spotlight

Manage model costs with OpenRouter

Not everything done inside the AI writing assistant requires Opus 4.8-grade intelligence—or cost. An LLM gateway, OpenRouter helps Spiral general manager Marcus Moretti use the right-sized model for the right task.

Spiral currently uses 12 different models, including Sonnet 4.6 for most prose, Gemini 2.5 Flash for a top-edit that removes AI tells, and a smaller, lower-cost OpenAI model for summaries of files. Staying on top of each provider’s API format, credentials, account, and billing would be complicated and time-consuming.

OpenRouter takes care of that management layer for him—once integrated, the service gives Spiral a standardized way to send requests to many different models. Marcus regularly checks out OpenRouter’s LLM Leaderboard, which ranks models by weekly token usage across the platform and, of late, has been dominated by cheaper, open-source options rather than expensive frontier LLMs from OpenAI and Anthropic.

Another big plus—and the original reason Marcus turned to OpenRouter—is reliability: It makes models available through multiple providers. If Anthropic runs into an issue, for example, OpenRouter can tap another provider, such as Google or AWS, so users don’t experience any interruption in service.

Frontier models don’t crack the top five. (Screenshot courtesy of Laura Entis.)

What we’re reading

So about AI and jobs…

It’s causing tech worker sentiment to split into two. (Lenny’s Newsletter) Entrepreneur and Substacker Lenny Rachitsky just published his second annual tech worker survey, which revealed “a tale of two workforces.” Roughly half of respondents experience AI as an amplifying, energizing force, while the rest feel shaken and destabilized by it. There are meaty insights in here, including a surge in people reporting “significant” burnout, how even tech workers optimistic about their professional trajectories wouldn’t recommend their career path to newcomers, and mixed emotions about the overall impact of AI on work. “The defining feeling about AI is ambivalence,” Lenny writes.

AI CEOs want you to know they were maybe wrong about mass unemployment. (Wall Street Journal) After years sounding the alarm on the economic implications of their frontier models, AI CEOs are striking a more optimistic tone. “Our industry underestimated how much we’re going to be able to keep people at the center of everything,” per OpenAI CEO Sam Altman. Meanwhile, entry-level job doomer (and Anthropic CEO) Dario Amodei recently acknowledged AI-motivated layoffs could be avoided should companies apply “creativity” to achieving more with the same resources. What’s behind the about-face? Per the WSJ, it could be a better understanding of AI’s role in the workplace, a PR tactic in response to growing public backlash, or a blend of both.

The supporting data is a giant question mark. (New York Times) No one is arguing AI isn’t impacting the labor market. What’s up for debate is how: Depending on your data source, the technology is either destroying or creating jobs, while contributing to or helping solve inflation. Big picture, there’s a limit to what current, inherently incomplete metrics can tell us about how AI will transform work. “What the data can almost never tell us is where we’re going to be in five to 10 years,” former Bureau of Labor Statistics chief Erika McEntarfer told the Times. “People are looking to data to answer that question, and it’s just too difficult.”

Coders, learn to philosophize. (New York Times) Trouble landing a tech job? Consider becoming a (very specific kind) of philosopher. “I think the demand for philosophers with A.I. training is, if anything, outstripping the supply right now,” says NYU philosophy professor David Chalmers. “It’s an area I encourage students to go into.” Indeed, this small cohort has seen their job prospects skyrocket as frontier labs have rushed to employ people capable of engaging in the thorniest questions around AI’s impact on humanity and the possibility of AI consciousness. (For more on AI and philosophy, check out our AI lab philosopher draft from April.)

Laura Entis is a staff writer at Every. You can follow her on LinkedIn. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Use Fable Before You Know What to Ask

Katie Parrott / Context Window — 2026-07-07 13:06:42 -0400

by Katie Parrott

in Context Window

Midjourney/Every illustration.

Today, we explore why Fable’s sharpest edge is its ability to surface the decisions you didn’t know you were making. Plus, Every’s head of social media Becky Isjwara walks through how she had Fable diagnose and fix a task Opus 4.8 kept fumbling, and product leader Trevin Chow shares the /ce-pov skill, which forces an AI’s impressions of a new tool to survive contact with your project’s constraints.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Signal

Use Fable to find your unknowns

Today is the last day Fable 5 is included in the weekly limits for Claude Pro, Max, Team, and select Enterprise plans. Starting tomorrow, it moves to pay-as-you-go usage credits. At twice the price of its closest sibling, Opus 4.8, the question is: When is Claude’s pricey mega-model worth calling in?

It’s tempting to save Fable for the biggest, most heavy-duty jobs you have. But there are more ways to measure complexity than the size of the task. Some jobs are hard because they demand enormous execution against a settled plan. Others become hard when the model discovers that the goal, baseline, or standard was wrong from the start. A smaller model may handle the first surprisingly well. Fable’s advantage becomes clearest in the second.

Anthropic member of technical staff Thariq Shihipar offers a way to recognize this second kind of difficulty before Fable spends time executing against the wrong premise. His field guide shows how to use the model to surface questions and decisions that the assignment leaves unresolved, both before execution and as the work unfolds.

He frames the problem as a gap between the map and the territory. The map is the prompt, skills, and context you give Claude. The territory is the codebase, the real world, and the constraints that each introduces. Thariq calls the gaps between them “unknowns”: moments when Claude must make a decision without enough information to know what you would want. Picking up on a framework popularized by former United States Secretary of Defense Donald Rumsfeld, Shihipar differentiates between “unknown knowns” and “unknown unknowns.” An “unknown known” is a criterion so obvious to you that you would never think to write it down, though you would recognize it when you saw it. An “unknown unknown” is a question you have not considered at all—which the model may encounter in the course of its work without a map to guide it.

Every’s experience with Fable illustrates both kinds. Head of tech consulting Mike Taylor gave Fable the completed manuscript of his book about the AI programming framework DSPy. His request had explicit boundaries: Read it and tell him what he had missed. Yet it posed an unknown known. Mike expected to recognize a major omission if Fable surfaced one, even though he could not name it in advance. The difficult part was evaluation rather than execution.

Every CEO Dan Shipper pointed Fable at five weeks of stalled copy-editing experiments and asked it to review the work and “come to your own conclusion.” The model found an unknown unknown: Dan had set a goal of reproducing 70 percent of editor in chief Kate Lee’s historical edits before measuring how often Kate herself would make the same edit twice. The team had spent five weeks improving performance against a target it had never validated. Fable’s useful contribution was finding fault in the assignment itself.

These examples expand the definition of a Fable-sized task. Mike’s hinged on an unnamed standard. Dan’s was an unquestioned premise. Neither would look especially heavy-duty by scope alone.

Once every Fable request hits the meter, triage by uncertainty as well as scale. Use a cheaper model when the goal, constraints, and definition of good are settled. Reach for Fable when the map is still incomplete.

Steal this workflow

Let one model write an instruction manual for the rest

Every’s head of social media, Becky Isjwara, spent weeks trying to get Opus 4.8 to turn long livestreams into short social clips. It could find the right moments, but it cut audio mid-word and let the captions drift out of sync. Last week, she gave the same job to Fable and asked for something more durable than clips: a method a cheaper model could follow next time. Here’s how she did it:

Give the expensive model the job and the failed attempts. Becky supplied the livestream, examples of the clips she wanted, and the errors Opus had made. She also explained that one good clip might splice together moments several minutes apart.
Make it document the method. Fable planned each clip in text, marked each segment with its first and last spoken phrases, matched those phrases to word-level timestamps in code, and inspected frames after every render. Becky had it save the supporting scripts and editorial instructions outside the chat.
Test the manual on the cheaper model. Next time Becky needs to clip a video, she’ll start with a new Opus session with the instructions, scripts, and a fresh source file. She’ll bring back Fable when the format changes or the instructions fail in a new way.

Do this week: Give Fable one recurring job your everyday model fumbles. After it completes the job, paste:

Turn the method you used into instructions that Opus can follow on a new example. Put repeatable, rule-based steps in scripts. Put judgment calls in a skill with examples. Define the inputs, outputs, and quality checks. Test the workflow once, then list anything that still requires Fable.

Skill share

Ask your project what it thinks

Ask an agent for its view on a new library, framework, or idea, and it will often judge the thing in general while ignoring your dependencies, prior decisions, and constraints. Product leader and compound engineering contributor Trevin Chow kept reaching for a new skill in Every’s open-source compound engineering plugin called /ce-pov because it forces that advice to survive contact with the project.

The workflow works in code repositories and in project folders made of documents, decks, or data:

Frame a decision. Give /ce-pov an external input and say what you need to decide. Try: /ce-pov Should we adopt this database library here? A bare link also works. The skill inspects it and asks which decision you want to make instead of guessing.
Require project and external evidence. The skill must cite a verified project fact—an existing dependency or integration point—and at least one external source. It checks disconfirming evidence and prior decisions before grading.
Follow the grade. Every run ends with one of five verdicts: Adopt, Trial, Hold, Reject, or Not-our-problem. It then recommends a plan, a scope discussion, a reversible test, or a stop.

Try it this week: Open a real project folder and paste one tempting link: /ce-pov [link] Should we adopt this here? Read the cited project fact before the grade. If the skill misunderstood your situation, the verdict has failed.

Data point

The cheaper model won

13.8 times cheaper

Researchers at Bridgewater AIA Labs, working with Thinking Machines Lab and using its Tinker training platform, fine-tuned Qwen3-235B to outperform every frontier model they tested across six financial tasks—at 13.8 times lower inference cost per task.

Fable earns its premium while the assignment still contains unknowns. Bridgewater’s result shows that a cheaper specialist can beat a general frontier model on repeated, well-defined work.

Discuss

“We’ve been roughly right on technological predictions and pretty wrong on the social and economic implications.”—Sam Altman, CEO of OpenAI, in the Wall Street Journal

AI CEOs spent last year prophesying mass unemployment as a result of how powerful their products are. Their new, sunnier case is that companies will use AI to take on more work with the same staff, and people will move into new roles as machines take over parts of their jobs. This tracks with what Dan has argued: When AI makes code and writing cheap to produce, companies produce much more of both, but they still need engineers and editors to decide what’s worth keeping. The open question is who gets that new work—and whether it goes to the people whose old jobs disappear.

Katie Parrott is a staff writer at Every. You can read more of her work in her newsletter. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

A Tale of Two Models

Every Staff / Context Window — 2026-07-05 12:37:00 -0400

by Every Staff

in Context Window

Midjourney/Every illustration.

Anthropic put out two models this week—one we’d been missing, and one we could skip. Fable 5 came back online on Thursday, and it couldn’t come back soon enough. Two days earlier, Sonnet 5 landed with a shrug: Katie Parrott’s Vibe Check finds a Goldilocks model pitched for everyone that impresses no one, with a cheaper, faster, or smarter option for nearly every job. Yet while Fable can spin up a working app from a single prompt (it rebuilt our document editor Proof in about three hours), AI still can’t reliably make a PowerPoint deck. Mike Taylor and the consulting team needed a 24-skill pipeline at $62 a deck to automate it, and still wouldn’t recommend it for most teams. Regardless, the Every team still can’t get enough of Codex. We’ll be back in your inbox on Tuesday.—Kate Lee

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Knowledge base

“Vibe Check: Sonnet 5—A Model Pitched for Everyone Impresses No One” by Katie Parrott/Vibe Check: Katie and the Every team put Anthropic’s new Sonnet 5 through its paces and came away unconvinced. Pitched as the Goldilocks model—smart enough for hard work, cheap and fast enough for daily use—it lands as none of those next to Opus 4.8, Fable 5, and GPT-5.5. Read this for where Sonnet 5 fits, and why the team keeps reaching for other models.

“AI Could Do Anything. Then It Met PowerPoint.” by Mike Taylor/Also True for Humans: PowerPoint has been a fixture of work for decades, and AI still can’t conquer it in one shot. Mike and the consulting team found that Codex and Claude Code build slides from scratch well but falter against a company’s own templates. For most teams, the hardest part is figuring out what to say, and AI can’t do that for you. Read this for an honest account of what AI can and can’t do with slides.

“Codex in Practice” by Laura Entis/Context Window: Laura Entis rounds up how people across Every have built their own Codex workspaces—Dan Shipper’s long-running router threads, Katie’s file system, head of growth Austin Tedesco’s outcomes-based approach, and Cora general manager Kieran Klaassen’s portable setup, a synced context folder any agent can draw on—each with a copyable starter prompt. Read this for setups you can steal.

“Codex for Nontechnical Builders” by Dan Shipper/AI & I: Natalia Quintero, Every’s head of consulting, makes the case that Codex is the first agent a nontechnical person can operate the way engineers operate Claude Code. It builds its own folder structure and instructions instead of asking you to set them up first. She walks Dan through running it like a direct report: achieving inbox zero, managing a client pipeline in Attio, and coordinating her father’s medical care. Read this for a nontechnical builder’s Codex practice, end to end. 🎧 🖥 Listen on Spotify or Apple Podcasts, watch on YouTube, or follow the discussion on X.

“Your AI Strategy Is Making Bets. Do You Know Which Ones?” by Dan Pupius/Thesis: Dan Pupius, CTO at The General Partnership, argues that every AI strategy rests on four bets founders usually don’t spell out: token costs, model capability, provider lock-in, and regulation. The teams that name their bets are the ones who can adjust when one turns. Read this for a clear way to surface your assumptions and see which you can change.

Log on

Get hands-on with how Every uses AI. These are the live camps, workshops, and meetups where team members teach the workflows behind our work.

Upcoming events

Q2 Demo Day (July 10): Every’s quarterly demo day, where the team shows what it shipped this quarter—paid subscribers only. RSVP.
Every IRL (July 15): An in-person meetup at Every’s Brooklyn headquarters, paid subscribers only, from 6-8 p.m. ET. RSVP.

From Every Studio

Monologue dictates in every language you speak

Monologue, Every’s voice dictation app, shipped v1.3.0 with multilingual dictation: Tell it which languages you speak—English and Spanish, say—and it keeps up as you switch mid-thought, with a new picker spanning more than 99 languages. The update also adds more ways to start recording, including Hyper Key support and dedicated push-to-talk, hands-free, and mouse-button shortcuts.

Spiral prompts automate the writing you repeat

Spiral, Every’s writing tool, lets you save a repeated writing workflow as a reusable prompt, so jobs like generating show notes, pulling quotes from a podcast, or drafting a marketing post from internal documents run in one step. New this week: You can create and edit those prompts right in chat or over MCP, instead of setting them up separately.

Alignment

Sell the shovels. Anthropic launched Claude Science—a desktop research tool that lets scientists run analyses, visualize molecular and genomic data, and show the exact code and steps behind every result— and announced it’s running its own preclinical drug programs, which likely had pharmacology executives swearing at their laptops.

However, as a doctor named Patrick Malone tweeted, it’s unlikely that Anthropic will develop its own drugs and see it all the way through to the hands of a patient.

Instead, Anthropic will use these internal drug programs to test and improve its own AI tools. The goal is to fix the major bottlenecks in drug development—particularly evaluation and verification—so it can build a stronger platform that pharma companies will bend over backwards to use.

As Malone points out, this is known as dogfooding—deliberately using your own technology on real, difficult problems so you can identify and fix their weaknesses. In this instance, dogfooding will be used to test how well an AI performs on complex tasks like identifying drug targets or designing molecules, and then verifying those results by conducting laboratory experiments and clinical studies to confirm whether the AI’s suggestions are indeed correct.

These hurdles are time-consuming and expensive to resolve because, unlike software, where you can test something in seconds, biological systems move slowly, and feedback only comes after living cells or organisms have had time to respond.

If—and it’s a big if—Anthropic can solve this problem, it builds the workflow layer that ties data, models, experiments, and decision-making together, and, by extension, sells big pharma the platform that makes drug development faster. This strategy is known as selling the shovels, and it’s been a good one since 1849.—Ashwin Sharma

That’s all for this week! Be sure to follow Every on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Upgrade to paid

Vibe Check: Sonnet 5—A Model Pitched for Everyone Impresses No One

Katie Parrott / Vibe Check — 2026-07-02 16:46:45 -0400

by Katie Parrott

in Vibe Check

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Anthropic has historically pitched Sonnet as its “just right” model: smarter than Haiku, cheaper and faster than Opus—enough intelligence for getting work done, at a price that won’t make your accounting team cry.

Sonnet 5, released on Tuesday, arrived with an even bigger promise. Anthropic says it’s more agentic, closer to Opus, and better suited to the inchoate work people hand to AI all day.

After testing it across Every, we came away with a less flattering impression. Sonnet 5 is capable. It can produce decent prose, handle structured knowledge work, and make progress on some coding tasks. But over and over, the same question came up: When would we pick Sonnet 5 over the models already in the rotation?

We get into all of it in our Vibe Check, including:

Kieran Klaassen’s coding results, where Sonnet 5 got stuck on agentic builds that stronger models handled better
Katie Parrott’s writing tests, where Sonnet 5 produced usable promo copy—but its editorial instincts went sideways
Mike Taylor’s take on decks, maps, and whether the price makes sense for knowledge work
Austin Tedesco’s side-by-side email draft test against Opus 4.8
Plus: Our Reach Test verdict, benchmarks, and examples across coding, writing, knowledge work, and agent behavior

On its own, Sonnet 5 is a decent model. Next to GPT-5.5, Opus 4.8, and Fable 5, though, there’s always a faster, cheaper, and more capable option.

Read the Vibe Check

Katie Parrott is a staff writer at Every. You can read more of her work in her newsletter.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

Discover Every’s upcoming workshops and camps, and access recordings from past events.

For sponsorship opportunities, reach out to sponsorships@every.to.

Codex in Practice

Laura Entis / Context Window — 2026-07-01 13:00:00 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

We’re here to talk about Codex but before we get into it, we need to acknowledge the impending return of Fable 5, Anthropic’s Mythos-grade model that’s slated to be available again today. Every’s head of tech consulting, Mike Taylor, is at the AI Engineer World’s Fair, where Anthropic’s Thariq Shihipar just gave a keynote titled “A Field Guide to Fable.” In the words of staff writer Katie Parrott, “Our long national nightmare is almost over.”

To get ready for restored access, check out our Fable 5 Prompt Library and watch this space: As soon as Fable 5 is back, the Every team will host a live working session on how to get the most out of the model.

Trying to figure out where to start with Fable? Use this discovery prompt to find Fable-worthy work, and send us the results: @every on X. We’ll run some of our favorites during the stream.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

There is no single way to use Codex. The agentic workspace is smart and versatile enough to modify itself based on what you’re looking to do and how you like to work. This flexibility makes Codex powerful, but it can also make for an overwhelming onboarding experience; if you can use Codex for anything, where do you start?

At Every, we find the best answer to that question for any tool or platform comes from looking at how people on our team are using it in concrete, practical terms. That’s why this week’s edition of Context Window is all about use cases for putting Codex to work. First, in the latest episode of AI & I, head of consulting Natalia Quintero breaks down how she’s using the app to do everything from achieve inbox zero to manage her father’s healthcare. CEO Dan Shipper, Katie Parrott, head of growth Austin Tedesco, and Cora general manager Kieran Klaassen also share their Codex setups, plus overarching philosophies for using the app.

‘AI & I’: Codex for nontechnical builders

Today, we’re releasing a new episode of AI & I, in which head of consulting Natalia Quintero shows Dan how the app helps her manage work and personal responsibilities. A recent convert to the app, she says “Codex has been life-changing.”

Watch on X or YouTube, or listen on Spotify or Apple Podcasts. You can also read the transcript.

Here are the highlights.

Codex as a lower-friction Claude Code. Natalia dedicated a lot of time creating folder structures and file systems in Claude Code. She doesn’t need to create similar elaborate setups with Codex, because the app builds them for her as they work together. “I have to focus a little less on architecting things well—which is very much a skill and something our engineers do extremely well. I can just trust it to make good decisions and build solutions for me,” she says. In practice, Natalia opens the Codex project she’s prioritized for the day, and works from there, trusting that Codex will update the project accordingly.
Codex as a direct report. As with Claude Code—or a human employee—Codex needs the right context to hit it out of the park. A recent example: Natalia was working with Attio, the CRM Every’s consulting team uses to manage inbound leads, client relationships, and the sales pipeline. Her prompt was essentially “set up my CRM to accurately reflect what happened in my emails and conversations with existing and prospective clients.” Because Codex had access to her inbox, meeting transcripts, and the sales-pipeline logic, it could enrich hundreds of client and prospect records while she slept. “I woke up to a CRM that was fully set up—work that would have taken weeks otherwise,” she says. “It’s one of those moments of joy and delight with AI and my quality of life has improved as a result of this loop.”
Codex as a way to help care for loved ones. Natalia’s father has multiple nurses who support his care, a reality that requires managing medical appointments, follow-up protocols, and the flow of information from healthcare providers and family members. “Codex helped me create an operating system for how, as a family, we could triage my dad’s care,” she says. The app gives her a central place to track everything instead of Natalia spending her time digging through scattered threads. “Codex has made it really easy to digest all of that in a single place and to allow us to support my dad in what we can do best—which is to be present and loving as his family.”

How others at Every use Codex

If you’ve been following our coverage—or Dan’s X account—you know we can’t shut up about how good Codex has gotten. By this point, we turn to it for everything from engineering to writing to operations. And just as none of us have the exact same job, no two people on the team use it the exact same way.

In a two-hour live camp, CEO Dan Shipper, staff writer Katie Parrott, head of growth Austin Tedesco, and Cora general manager Kieran Klaassen broke down their unique setups and use cases. Here’s what each of their Codex workspaces look like, along with sample prompts you can use if you want to adopt one of their approaches to jump start your own.

Dan’s long-running threads

Dan’s approach is organized around a simple principle: Codex is most useful when it has access to everything you would need to get the task done. His setup has two main components.

The first is long-running Codex threads, or chat workspaces with the agent. Because they don’t reset between sessions, they retain the full history of a workflow’s purpose, key players, and relevant events. Dan has dedicated threads for recurring tasks such as processing emails, reviewing Slack and meeting transcripts for updates he may have missed, and hiring.

The second component uses Codex’s in-app browser—a browser inside Codex that lets Dan and the agent use websites together when a job requires live context. Codex can review a web page and click through to get work done on its own without Dan having to translate everything into instructions.

The combination of long-running threads and the in-app browser is powerful. For coding, that means the agent can inspect and interact with the live user interface while building or debugging. For knowledge work, it means Dan and Codex can look at the same browser page, inbox, document, or app without Dan having to paste context back and forth.

To handle inbound requests from other people—which could disrupt his own prioritization flow—Dan uses a router thread, or a designated orchestration thread that categorizes information and delegates tasks to the appropriate sub-thread. He gave Codex its own email address (using a small tool he built called Mailroom) and the router thread checks that inbox every few minutes, reads each new request, and sends it to the long-running Codex thread best suited to handle it. A question about a contract might go to a thread with legal context; a permission request might go to a thread that can handle internal operations.

Here’s a prompt for kicking off Dan’s approach:

          Prompt
          Other
        

Help me design three long-running Codex threads for recurring areas of my work. 

First, interview me about the workflows that regularly require my attention.

Then propose:
- How to define the purpose of each thread
- The sources each thread should monitor
- The type of requests that should be routed there
- Actions Codex can draft or prepare on my behalf
- Actions that require my explicit approval
- A proposed strategy for reviewing outputs

Then draft starter instructions for each thread and a simple router rule set for deciding where new requests should go.

Katie’s file system

Before discovering the magic of Codex, Katie was a Claude Code power user, with a well-maintained local setup of nested files and folders. She’s created something similar with Codex, and like Natalia, found the process to be faster and less manual: Instead of setting up the system herself, she had Codex interview her about her role, writing style, and work preferences, so it could build a more agent-friendly system on her behalf.

The result is a local ‘Katie Context’ folder that acts as a command center. It includes:

An AGENTS.md file, which Codex treats as a table of contents for the rest of the folder
An identity file that explains who Katie is and the type of projects she works on
Preferences for how Codex should produce and package outputs, including a standing instruction to create a Proof document when something needs to be shareable
A running list of “don’t do this” instructions, so Codex avoids repeating documented mistakes
A project map that lists each area of her work—columns, guides, automations, and workflows—along with the relevant files, folders, and instructions Codex should use for each one
A Voice.md file with guidance on how she writes, the language she prefers, and the tone she wants Codex to use

Once she established her optimized setup, Katie turned to automating how she aggregates, documents, and organizes potential story ideas so they’re ready for her to draft. To do this, she had Codex create an “idea farm” for her biweekly column Working Overtime. Her first prompt was simple: “I want to start an idea farm document in the folder and start monitoring [Slack channels] for and banking content ideas for Working Overtime.” Codex created a tracker that explained what it was for, evaluated ideas against a rubric based on her writing style and coverage areas, scored them, and added editorial notes.

Here’s a prompt for kicking off Katie’s approach:

          Prompt
          Other
        

Help me create a local context folder for one recurring area of my work.

First, interview me about:
- What this area of work involves
- What kinds of outputs I regularly create
- Where the relevant source material lives
- How I like drafts, notes, and shareable documents produced
- What mistakes or habits I want an agent to avoid
- What voice, tone, or style preferences matter

Then propose a folder structure with:
- An AGENTS.md file that explains how to use the folder
- An identity file for my role and responsibilities
- A preferences file for how outputs should be created
- A rules file for guardrails and anti-preferences
- A project map that lists active projects and their related files
- A voice file for writing style, tone, and language preferences

After that, create an idea tracker for this area of work. Include:
- A short explanation of what the tracker is for
- A rubric for evaluating ideas
- A scoring system
- A readiness status for each idea
- Editorial notes on what each idea needs next
- Instructions for what new information should be saved over time

Austin’s outcomes-based approach

Austin’s setup is intentionally lightweight. He has a few Codex chats he returns to regularly, including one for go-to-market work and one for social media, but he tries to keep the structure minimal. “I’m not naturally a very organized person,” he says, “and I don’t want to spend any time getting organized.”

His strategy is to give Codex an outcome, connect it to relevant sources of information, and let it get to work. To create follow-up content for Every’s live events, he drops in the transcripts, chats, recordings, and a Monologue brain dump about what the follow-up package should include, then asks Codex to search Notion and Slack for additional context, build a GitHub repo with any referenced resources, and draft the follow-up email.

Once Codex produces a first version, Austin reviews it. If the output is bad or overcomplicated, he asks Codex to audit where it went wrong based on all the institutional context it has and improve the setup. For growth work, he keeps the relevant material in a GitHub repository called Every GrowthOS. When something goes sideways, he asks Codex to create a goal to audit the repo, look for old instructions or rules that may be causing problems, and make the setup more concise.

Here’s a prompt for kicking off Austin’s approach:

          Prompt
          Other
        

I want to use an outcome-first workflow.

Here is the result I want:
[describe the finished result]

Here are the sources that may help:
[list docs, Slack channels, Notion pages, repos, transcripts, meeting notes, analytics tools, design references, prior examples, or browser pages]

Please create a goal for yourself, search the relevant sources, and get as far as you can toward a first useful version.

As you work:
- Make reasonable decisions without waiting for me
- Ask only the questions that would materially change the result
- Keep a short log of the sources you used
- Note any assumptions you made
- Flag anything I need to review before this is shared or shipped

After the first version is done:
- Summarize what worked
- Summarize what got stuck
- Suggest what instructions, files, or workflow notes should be updated so this goes faster next time

Kieran’s portable setup

Kieran treats Codex as one tool inside a larger personal AI system. His main source of context is a synced folder that lives across his iCloud, Mac Mini, and all other devices. He can direct Codex, Claude Cowork, Claude Code, or any other agent to the same folder, and the agent can immediately use the context inside it.

This context comes from many places, including meeting transcripts, voice notes from Monologue, journal entries, and recordings from his Limitless pendant, which he always wears around his neck. When new material enters the folder system, an automated workflow Kieran built reviews, classifies, and extracts the key details, and saves that synthesized information in the relevant file.

Memory is what makes the setup useful over time. In addition to storing raw notes, Kieran’s system creates daily, weekly, and monthly summaries of incoming context. Those summaries become reusable memory any agent can read later, which means he doesn’t have to rebuild context each time he starts a new task.

That is where Codex fits in. Kieran reaches for it when he wants fast search and action across tools, especially for operational work with a lot of small, annoying steps. When people requested early access to Cora across X, email, and other channels, for example, he asked Codex to find everyone who had requested access, collect their contact information, ask for missing email addresses, create a spreadsheet, invite people to the Slack channel, and send welcome emails.

Here’s a prompt for kicking off Kieran’s approach:

          Prompt
          Other
        

Help me design a portable context folder for one recurring loop in my work.

The recurring workflow is:
[describe the workflow]

Propose a folder structure with:
- A README that explains the loop
- An inputs folder
- a source-of-truth folder
- A working folder for agent output
- A review folder for human feedback
- A memory file where lessons from each run get saved

Then define:
- What input starts it?
- What can Codex do on its own?
- What must I review?
- What evidence proves the result is good?
- What should be saved back for next time?

Try it this week: Pick a Codex style and get started

Codex is intimidating in large part because it’s so versatile. There aren’t established best practices because what works best for you will look different than what works best for someone else on your team. If you want to use or optimize Codex, perhaps the “best” advice is not to overthink it—pick a setup prompt and dive in.

Laura Entis is a staff writer at Every. You can follow her on LinkedIn.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

We build AI tools for readers like you. Write brilliantly with Spiral. Organize files automatically with Sparkle. Deliver yourself from email with Cora. Dictate effortlessly with Monologue. Collaborate with agents on documents with Proof.

For sponsorship opportunities, reach out to sponsorships@every.to.

Your AI Strategy Is Making Bets. Do You Know Which Ones?

Dan Pupius / Thesis — 2026-06-30 12:00:00 -0400

by Dan Pupius

in Thesis

Every/Dan Pupius.

Forget vague heuristics such as “AI wrappers.” Dan Pupius, chief technology officer at The General Partnership, argues that founders need a more robust framework to understand the risks and opportunities of building with AI. He encourages founders to look holistically at the implicit assumptions underneath their AI strategy, from the cost of intelligence, model self-sufficiency, platform lock-in, and the regulatory environment. I worked with Dan more than a decade ago at Medium, and the same quiet, thoughtful brilliance I knew him for then shines in his nuanced analysis.—Kate Lee

I’ve built products on ideas that people thought were wrong—and watched those same ideas become inevitable.

When I helped to rebuild Gmail at Google in 2005, we were betting that communication was becoming faster, more conversational, and increasingly browser-native. So we built GChat, which put real-time chat inside your browser for the first time, right next to your email. When I was running engineering at Medium, the bet was that social feeds were not enough for deeper thinking and publishing, so even while signups to Twitter, Snapchat, and Vine were exploding, we championed long-form writing.

In each case, we started with an insight about where behavior, technology, and markets were moving—and built our bets on top of it. But now, the rapid pace of change in AI means that the assumptions and insights underlying a strategy can shift mid-execution, causing those bets to crumble.

Founders need a more flexible way of thinking about which bets to take. Instead of asking “What do we think will happen?”, ask yourself two fundamental questions. First: What assumptions are irreversible? If you build deeply on top of one provider, such as one model provider, you need to rewire the product to move away from that provider. Second: What assumptions can we still revise? Assuming tokens will stay expensive is a bet you can hold loosely—if costs fall, you can change your approach without rebuilding anything.

At The General Partnership, where I am the chief technology officer, we developed a framework to help founders understand which bets they’re making, and which ones they can reverse when building with AI. The four-axis framework moves the conversation away from broad labels like “AI wrapper” and toward the specific futures a company is betting on. The goal is to recognize sooner when you’re wrong and move before the market forces you to—not to predict the future more precisely.

The four bets

We kept seeing a pattern with founders. A team would walk us through their strategy. It would sound reasonable and exciting, but the more we looked, the more often these companies’ fates seemed to hinge on factors outside their control.

Those factors mapped to four axes of bets that startups were taking. The companies that understood this knew where the tailwinds and risks of building with AI were. Those that didn’t were exposed.

Token economics: Scarce ↔ abundant

If you’re a token consumer—which most AI startups are—abundance is good news, and right now we’re in an era of fragile token abundance. Your margins improve. You can do more, experiment more freely, and build features that would have been prohibitively expensive a year ago. Cursor and its ilk exist as a category because the cost of running AI got cheap enough for products to run constantly in the background and still make money.

But abundance is a trap: If everyone can build what you’re building for pennies, what’s your advantage? As a founder, you need to know whether you’re betting on costs rising enough to be a barrier—or whether you have a defensible advantage that holds even if they don’t.

Ask yourself: Does the cost of running AI become high enough to constrain you, or fall toward zero?

If you’re betting on scarcity, you need to articulate why falling token costs won’t destroy your advantage. One example: applications where agents run constantly, not just on demand—at that volume, even cheap tokens add up, so squeezing cost out of every call becomes difficult. Another is latency-sensitive work, like voice agents built on Vapi, where any delay makes the conversation feel broken. There, you’re stuck paying for the fastest models even as other models get cheaper.

If you’re betting on abundance continuing, you need to build an advantage with one of the following: proprietary data, domain expertise, distribution, or knowing what to build. We believe that tokens will keep getting cheaper. But we see value in companies that reduce cost variance—making spend predictable and insulating customers from volatility. A startup that helps customers cap their maximum bills is more defensible than one competing on average price. We’ve seen it in healthcare: Companies processing huge volumes of data still need to manage their worst-case costs and avoid expensive reprocessing of documents, transcripts, and session logs. Even as per-token prices fall, being able to tell a client “Your bill won’t exceed X” is valuable.

Model self-sufficiency: Needs scaffolding ↔ handles natively

This axis determines the fate of what we’d broadly call “model wrapper” companies. If you’re augmenting what models can do—adding memory, improving retrieval, orchestrating multi-step workflows—you’re implicitly wagering that the model won’t one day be able to do that itself. That’s a bet with an expiration date. Maybe a good bet, maybe not, but you should know you’re making it. Harvey, an AI platform for law firms, and Sierra, a customer service AI, are both counting on a general model not being able to do what they do in their niches.

Ask yourself: Would my product still be needed if the model had unlimited capabilities?

If the answer is yes, you’re building integration. Companies whose primary value is integration—connecting models to messy external systems—are competitive regardless of how capable the models become. A company that brings AI into healthcare workflows, say, sits on a more defensible part of the axis. Any model can reason over medical information; what’s defensible is that the product integrates with the systems of record, document flows, and operational constraints that healthcare already runs on.

If the answer is no, you’re building scaffolding. Companies whose primary value is making models smarter face absorption risk—what they offer today is augmenting what current models can do. A company doing AI-assisted code review may be building something that customers need right now, but as models get better at catching errors and understanding larger repositories, the company has to be clear about what remains differentiated outside the model.

Some capabilities have already been absorbed by models—context windows have expanded dramatically, reducing the need to break documents into small chunks for retrieval in many use cases, and we think models will keep getting more capable.

Other capabilities look stickier for now: routing between providers with different strengths or costs, and compliance in regulated industries. A capable model can learn the regulations, but it can’t be trusted to check its own work. Financial model risk management takes this tension into account: The Federal Reserve has told banking organizations that model risk management should include “effective challenge,” review by parties independent of the model’s builders. Regulated healthcare has the same structure. When something goes wrong, a regulator or enterprise needs an accountable party to point to, and “the model judged itself compliant” isn’t one.

Platform structure: Lock-in ↔ commoditized

The next axis concerns the tools and infrastructure on which you are building your business.

Ask yourself: Are you locked into one AI provider or can you swap them without breaking things?

If you’re building on one provider’s ecosystem, know that you’re making this bet. You might be optimizing for their APIs, using their fine-tuning infrastructure, or depending on capabilities unique to their models—like OpenAI’s interface for apps to call their models in code, Anthropic’s ability to control a computer like a human would, or Gemini’s web search integration. The more you do that, the harder it becomes to switch providers without rebuilding significant parts of your product. That’s not inherently wrong. Amazon Web Services (AWS) lock-in has been fine for most companies. Have a view on whether that analogy can apply in your case.

If what you’re building doesn’t depend on one provider’s ecosystem, you’re counting on model choice mattering less over time. You might be building multi-model routing, or tools that work across providers—like OpenRouter, LiteLLM, or Vercel’s AI Gateway. You’re betting that switching costs will stay low and that what sets you apart lives in your product, not the underlying model. The analogy here is Postgres—open-source relational database technology that lets users store and query structured data. There are now dozens of managed Postgres providers competing on execution rather than the core technology.

Both can be right. The answer might differ by use case—if you need the best possible model for a high-stakes task, you’ll probably anchor to one frontier provider. If you need something good enough to summarize a document, you’ll pick the cheapest tool that week. Concentration in AI infrastructure suggests one or two providers will eventually dominate, but that consolidation is years away, not months. You don’t have to lock into OpenAI or Anthropic today if you can stay flexible for the next few years while open-weight models like Llama, DeepSeek, and Qwen are still viable alternatives.

Betting on one provider isn’t wrong right now. But we like founders who have thought about how they’d diversify if necessary, even if they’re not planning to today.

Trust and governance: Permissive ↔ constrained

This axis concerns the rules and compliance norms under which you operate. Unlike the others, it depends less on technology itself, and more on regulators, enterprise buyers, and public reaction.

Ask yourself: Do you move fast now and deal with governance later, betting the rules stay permissive? Or do you invest in audit trails and certifications upfront, betting compliance only gets stricter?

If you’re moving fast and treating governance as a future problem, you’re betting regulation stays light. That’s been a reasonable bet in the U.S. market so far. It may continue to be reasonable.

If you’re investing early in audit trails, explainability infrastructure, and standards like NIST AI RMF and ISO 42001—frameworks for managing AI risk—along with model cards that document a model’s training data, limitations, and intended use, you’re betting the environment tightens. You’re accepting slower movement now to be ready when compliance stops being optional.

Both have opportunity costs. The fast-mover gives up positioning if governance requirements suddenly become important. The early-compliance investor gives up speed if the permissive environment continues.

This axis is harder to predict than the others. A major AI failure with undeniable public harm—medical misdiagnosis at scale, infrastructure disruption, something with casualties—would trigger legislative response faster than a roadmap can adapt. Labor displacement could bring unexpected regulation if it catches enough political fire. Or you could have something like what happened with Anthropic’s Fable model.

Compliance can go viral, too. Large enterprises increasingly require vendors to meet AI-specific standards. If a few Fortune 100 companies mandate AI audits and model cards, every vendor that wants to sell to them has to comply, and then those vendors’ other customers start expecting the same thing. This creates de facto regulation without legislation. It moves faster than the government and is harder to predict.

The trajectory of the SOC2 security compliance standard is one precedent. Once large enterprises started requiring SOC2 from their vendors, it cascaded through the procurement chain until any B2B SaaS company needed it to win enterprise deals—even early-stage startups. Automated compliance company Vanta built a business on that wave. Whether AI compliance follows the same path is an open question.

Putting the framework into practice

For each axis, ask yourself four questions.

What is our implicit bet? Most of us haven’t articulated this clearly, even to ourselves. Writing it down forces precision. Think of it as an extension of the classic “Why now” slide in a pitch deck—explaining why the timing is right and which version of the future you’re building toward.
What would have to be true for that bet to pay off? If you’re betting on token abundance improving your margins, what has to be true about the cost curve, about your usage patterns, about competitive dynamics? If you’re betting on scaffolding remaining valuable, what has to be true about the pace of model capability improvement?
What signals would tell us we’re wrong? This is where most strategic planning fails. If you can’t name the signals that would cause you to think you were making the wrong bet, you’re not really stress-testing your strategy.
How quickly could we adapt if we are wrong? Some companies can pivot. Others have made commitments—technical, organizational, contractual—that lock them into a fixed position. Neither is inherently better, but you should know which kind of company you are.

As business strategist Hamilton Helmer argued in 7 Powers: The Foundations of Business Strategy, stronger moats survive shifts in the market. If your competitive advantage depends on one specific cost or regulatory assumption holding, you’re exposed. But if your advantage works across multiple possible futures—if you’re defensible whether tokens get cheaper or stay expensive, whether regulation stays light or tightens—you’re in a durable position.

That same logic applies to how you size your bets: High-conviction founders often win precisely because they make concentrated bets while others hedge, but they are aware of this choice.

Some bets can flip in a day. Intel’s former CEO Andy Grove called these “strategic inflection points”—shifts that upend the basis of competition. Token costs could spike from geopolitical shocks. Models could absorb capabilities you’re betting they won’t. Open-weight models could close the capability gap. A single AI failure with real harm could trigger a legislative response overnight. You don’t need to predict which of these will happen, but you need to know which ones are threats for your company, and what you’d do if they did.

Articulate your bets

Your strategy is already making bets about these axes. The question is whether you’ve written them down and made them explicit.

Having explicit bets creates internal alignment. Your team knows what you’re building toward and what would cause a pivot. They can make local decisions that stay consistent with the overall direction because they understand the assumptions underneath. When the plan changes, they still know where it’s headed.

Explicit bets enable faster adaptation. When signals shift, you recognize it sooner because you know what you were watching for. You’ve already thought through the implications. You’re not starting from scratch.

So, take an hour. Write down your implicit bet on each axis and what it means for your business. Then write down the signals that would tell you you’re wrong.

This is harder than it sounds. Most teams discover their bets aren’t as crisp as they thought, or that they’ve been making incompatible ones in parallel. If you can’t articulate them, your strategy is less coherent than you think. Start there.

Dan Pupius is the chief technology officer at the General Partnership, where he leads engineering work across the firm and with its portfolio companies.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Help us scale the only subscription you need to stay at the edge of AI. Explore open roles at Every.

I’ve built products on ideas that people thought were wrong—and watched those same ideas become inevitable.

The four bets

Those factors mapped to four axes of bets that startups were taking. The companies that understood this knew where the tailwinds and risks of building with AI were. Those that didn’t were exposed.

Token economics: Scarce ↔ abundant

Ask yourself: Does the cost of running AI become high enough to constrain you, or fall toward zero?

If you’re betting on abundance continuing, you need to build an advantage with one of the following TK: proprietary data, domain expertise, distribution, or knowing what to build. We believe that tokens will keep getting cheaper. But we see value in companies that reduce cost variance—making spend predictable and insulating customers from volatility. A startup that helps customers cap their maximum bills is more defensible than one competing on average price. We’ve seen it in healthcare: Companies processing huge volumes of data still need to manage their worst-case costs and avoid expensive reprocessing of documents, transcripts, and session logs. Even as per-token prices fall, being able to tell a client “Your bill won’t exceed X” is valuable.

Model self-sufficiency: Needs scaffolding ↔ handles natively

Ask yourself: Would my product still be needed if the model had unlimited capabilities?

Platform structure: Lock-in ↔ commoditized

The next axis concerns the tools and infrastructure on which you are building your business.

Ask yourself: Are you locked into one AI provider or can you swap them without breaking things?

Betting on one provider isn’t wrong right now. But we like founders who have thought about how they’d diversify if necessary, even if they’re not planning to today.

Trust and governance: Permissive ↔ constrained

This axis concerns the rules and compliance norms under which you operate. Unlike the others, it depends less on technology itself, and more on regulators, enterprise buyers, and public reaction.

Putting the framework into practice

For each axis, ask yourself four questions.

What is our implicit bet? Most of us haven’t articulated this clearly, even to ourselves. Writing it down forces precision. Think of it as an extension of the classic “Why now” slide in a pitch deck—explaining why the timing is right and which version of the future you’re building toward.
What would have to be true for that bet to pay off? If you’re betting on token abundance improving your margins, what has to be true about the cost curve, about your usage patterns, about competitive dynamics? If you’re betting on scaffolding remaining valuable, what has to be true about the pace of model capability improvement?
What signals would tell us we’re wrong? This is where most strategic planning fails. If you can’t name the signals that would cause you to think you were making the wrong bet, you’re not really stress-testing your strategy.
How quickly could we adapt if we are wrong? Some companies can pivot. Others have made commitments—technical, organizational, contractual—that lock them into a fixed position. Neither is inherently better, but you should know which kind of company you are.

That same logic applies to how you size your bets: High-conviction founders often win precisely because they make concentrated bets while others hedge, but they are aware of this choice.

Articulate your bets

Your strategy is already making bets about these axes. The question is whether you’ve written them down and made them explicit.

So, take an hour. Write down your implicit bet on each axis and what it means for your business. Then write down the signals that would tell you you’re wrong.

Dan Pupius is the chief technology officer at The General Partnership, where he leads engineering work across the firm and with its portfolio companies.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Help us scale the only subscription you need to stay at the edge of AI. Explore open roles at Every.

AI Could Do Anything. Then It Met PowerPoint.

Mike Taylor / Also True for Humans — 2026-06-29 10:55:11 -0400

by Mike Taylor

in Also True for Humans

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

As a consultant, I spend a lot of time in PowerPoint. Data doesn’t drive decisions, narrative does, and, love it or hate it, a slide deck presented on a glowing screen is the closest thing we have to our ancestors gathering around a campfire to tell stories.

The slides I made early in my career were ugly on purpose to show that my ideas were good enough—I didn’t need fancy formatting to convince. But if you won’t last long with that attitude in finance or consulting.

Clients see any lack of attention to detail as a sign that you can’t be trusted. Analysts pull all-nighters making slides pixel-perfect because they could get fired for using the wrong font or logo. Natalia Quintero, who leads the consulting practice at Every, learned this the hard way just weeks into her first job, when a company’s executive rejected the presentation her team was making over colors that didn’t match. If the colors were sloppy, he reasoned, the numbers were too.

We’re no Goldman Sachs or McKinsey, but at Every, we still have to communicate competency in our presentations. At the same time, we wouldn’t be a very credible AI enablement partner if we weren’t using AI to help us. The challenge is that AI-created decks often don’t tell a strong story—and that lack of narrative cohesion communicates the same thing as sloppy design: You didn’t care enough to pay attention to detail.

What follows is the story of our attempt to create the perfect PowerPoint with AI. We started with Claude’s and Codex’s PowerPoint skills, but neither could automate the process to the level of quality we needed. So we built our own. If you’re creating enough presentations—or your quality bar is similarly high—it may be worth following the same path.

Claude gets close, but can’t close every deal

When I joined Every in February, our consulting team was still making all our slides manually in Figma—about two to three decks per week. The first thing I tried was asking Claude Code to create PowerPoint slides for an upcoming presentation.

It didn’t go well:

Mike’s first attempt at creating a PowerPoint with Claude did not go well. (All images courtesy of Mike Taylor.)

To make Claude work at all with PowerPoint, Anthropic had to invest a lot into creating its official pptx skill. A single markdown file doesn’t cut it. Its skill has 59 different files in the folder, 16 of them Python scripts for interacting with PowerPoint. The skill.md file itself is over 4,000 words, and there are an additional 3,000 words in reference files.

Claude is surprisingly good at building slides from scratch—not because it knows PowerPoint, but because a slide is fundamentally a layout problem. Arranging text blocks, images, and shapes on a page is the same thing HTML was built to do, and Claude writes HTML fluently. So it can lay out a polished deck and hand it back ready to present better than any of the dedicated AI deck creation tools on the market.

But the minute you use a company template, it goes off the rails. Matching an existing design and writing style is a hard task for AI because it requires spatial awareness, narrative structure, research diligence, design aesthetics, and good taste—all domains where humans still have the edge. For a well-researched presentation, you need to feed Claude a lot of material, and everything you give it counts against its context window, the amount of text it can read in one chat session. Pile in more than 200,000 tokens (roughly 150,000 words) and you hit context rot: The model starts to get confused and make dumb mistakes. Furthermore, Microsoft’s .pptx file format was never designed with agents in mind––it’s messy, token-inefficient, and hard to manipulate reliably.

An AI-generated deck that’s 80 percent right is often worse than one using no AI at all. Reviewing a polished-looking presentation for hidden errors is harder than building the right one yourself, and people over-trust AI outputs. In our pursuit of the perfect PowerPoint, we’ve found that automation only becomes genuinely useful when it gets you close to a zero-percent defect rate. Reaching that standard is possible—but only after an outrageous amount of work writing, testing, and orchestrating skill.md files.

The Anthropic skill also does a poor job of updating or editing old decks. Because .pptx files are stored as XML and Claude is trained on millions of times more HTML than XML, the model struggles to mentally render what it’s working on. It can’t reliably predict where text will wrap or images will overlap, so it’s making changes without really seeing the slide.

Training a superagent on slides

Our senior applied AI engineer Nityesh Agarwal took it upon himself to solve the PowerPoint problem. He adapted the Anthropic PowerPoint skill by adding several key features and incorporating it into our AI assistant, Claudie.

The biggest improvement came from adopting a blueprint-first approach. Instead of immediately generating a final deck, Claudie would first create a plan for what slides were needed and write detailed visual direction notes for each one. It drew on two inputs: an agenda built from Granola client-call notes, and a table of contents laying out the main narrative points for the session. Then Claudie would wait for my approval in Slack before proceeding. This human-in-the-loop process saved us at several points and helped avoid wasting a lot of tokens on decks that would have been too shallow to present. Because the agenda input detailed the order of events and bullet points on each topic, it rarely missed a slide.

At the time, slide preparation was about 80 percent of my work, and I was traveling around the country to do three or four workshops for our clients about AI adoption and implementation a week. I couldn’t make decks without AI because I had no time to do it all manually. With Claudie and her new PowerPoint skill, I could hop on a plane and have the slides done for me by the time I arrived—Claudie, who runs on a Mac Mini in our New York office, could be working even if I was offline. After checking into my hotel, I could make manual edits and be ready to present the next day. We also built skills for Claudie to synthesize call notes into an agenda for each workshop, draft proposals for new engagements, and build the exercises for participants to work through on the day.

To create images that aligned with Every’s Greco-Roman-pop-art brand, we gave Claudie an image-generation skill powered by GPT Image 2 and wired it into our slide-creation process as a dedicated step. In April, the combination of our work on skills and the release of Opus 4.7 led to one of the best slide decks I’ve ever seen AI produce.

The best AI-generated slide deck I had ever seen in April, made possible by Opus 4.7.

Trust me, it wasn’t perfect. Opus decided to invent a new brand style because it thought ours wasn’t good enough. (I prefer Opus’s style, but technically it didn’t follow my instructions.) After Claudie gave us a draft presentation, it took as many as 40 rounds of back-and-forth iteration to get the final product, and I still had to make an hour or two of edits from there for each deck.

The biggest quality of life improvement was that I could “set it and forget it”—fire off a request to Claudie in Slack before a meeting, and give feedback to Claudie before I start my next one.

There were still a few cases when the results of Claudie’s work were unusable. When the material was especially complex or unfamiliar, the presentation barely scratched the surface and left out important insights. For a half-day workshop on Symphony, OpenAI’s orchestration library, I used only a handful of Claudie’s slides and stayed up until 2 a.m. to perfect the deck myself. When the stakes got high enough, I chickened out. The first time we presented to the entire C-Suite of a billion-dollar company at an executive offsite, I made the slides by hand.

Still, by the middle of April, things were starting to improve. We were getting to the point where our decks were on brand and took half an hour to correct, instead of the three-plus hours they used to take to create from scratch.

Build 25 decks, make no mistakes

By the end of April, after stress-testing the workflow internally on dozens of decks, we had enough confidence to take it outside. Our first client was a company whose team creates roughly 25 sales decks a week—at that scale, automating the work freed them for higher-value tasks like business development. But these decks went to serious sales prospects, and a single mistake risked damaging trust with a potential customer.

At first, I started with Nityesh’s existing, blueprint-first solution and tried vibe coding in Claude Code to adapt it to our client’s template. Claude copied the PowerPoint skill we already had, read the client discovery call notes, and rewrote the existing skill to match the client’s style and requirements. I had Claude run the newly updated skill on two briefs the client had shared and compare its output against the decks the client had actually presented to spot any discrepancies. We repeated this process eight times. Each round, Claude proposed fixes for what it found until it confidently declared that its version was better than the client’s original.

Then I opened one of the decks. It was a mess.

Slides were out of place. Text overlapped. Several headshots were even labeled with the wrong names. When I asked what happened, Claude admitted that it hadn’t looked at the presentations. Instead, it had written a set of evaluation metrics—code that checked whether specific changes had made it into the deck. But that code only verified content, not appearance, so it completely missed problems like broken layouts.

I locked in, cleared my schedule, and started micromanaging Claude as we unpacked each problem one by one. That process took three weeks and multiple rounds of client review. The result was a plugin built from 24 skills, run in 11 distinct phases, and supported by 18 Python scripts. All told, it cost 28.9 million tokens and $62 to generate a single deck. Here’s an (anonymized, generalized) image of the final plugin structure:

The final structure for a custom PowerPoint skill costs $62 per deck to run.

Skills can link to other skills. That’s what makes orchestration possible: Each skill can hand off to the next, so you chain them into a full workflow. Claude finishes one task and then runs the skill you’ve pointed to. Here’s a breakdown of what’s going on in this skill workflow:

Inputs: A brief (topic, audience, goal) and a knowledge base (internal data, documents, sources)
Phase 1, template preparation: Define the blueprint (slide types, sections, flow) and clean up/standardize layouts, styles, and branding
Phase 2, framing: Define audience and success criteria, then do deep research on key questions and hypotheses.
Phase 3, research and decision-making (sequential): A six-step chain that runs in order to identify themes, evaluate options, segment details, analyze implications, synthesize insights, and map connections
Phase 4, content research (parallel): Deep-dive research split across multiple content sections (A through N) at the same time
Phase 5 and 6 (parallel): Front-of-deck (title, agenda, key messages, opening) built alongside back-of-deck (detailed analysis, data/evidence, appendices)
Phase 7, narrative polish: Write the storyline, transitions, and takeaways to tie it together.
Phase 8, visual assets: Create charts, diagrams, icons, and infographics.
Phase 9, assembly: Drop content into templates and check flow/consistency.
Phase 10, review: Quality pass on logic, accuracy, design, plus stakeholder feedback (with a loop back to assembly)
Phase 11, handover: Package the final deck with notes, rationale, and sources.
Outputs: Three deliverables come out of the bottom: the polished slide deck, a handover document, and an asset library.

Piece by piece, we built something that could stand on its own. Every time something failed, we spun it out as its own skill and A/B tested it until the issue disappeared. When the model researched the wrong sources, we rewrote the skill to direct it where a human would have looked. When the slide titles were too generic, we provided examples that captured the style the client liked. When the right font colors were getting lost in assembly, Claude wrote a script to make that part more deterministic. Instead of running the entire pipeline—nearly an hour each time—we could isolate the problem, iron it out, and move on.

This level of complexity and investment isn’t necessary for the vast majority of organizations, but in this case, it was. The solution still isn’t perfect, even at this level of investment, but now our client’s team members can spin up 10 decks in an afternoon.

Don’t fire your analyst

As our experiment with AI-generated slide decks hopefully showed, fully automating deck creation with AI isn’t worth it for most people. Most clients aren’t at the scale where they can justify proper skill optimization and quality control. Unless you’re doing hundreds of similarly shaped presentations a month, it probably isn’t worth it. Automate what you can and wait for the next model release, or for someone to publish a better plugin or tool.

Alternatively, you could move away from PowerPoint’s complexity and toward HTML, which Claude is much better at. Another colleague in the Every consulting team went down this path and makes interactive HTML, CSS, and JS slides. This front-end slides library can help you accomplish something similar. There are also AI-first slide makers like Gamma, though you are locked into their system. Nityesh ultimately solved our PowerPoint problems by using our early access to Fable to build Hands on Deck, an open-source tool that enables Claude to make targeted edits to an existing PowerPoint template, with far fewer errors.

But don’t be too quick to fire your analyst. In our experience, automating things with AI causes more work, not less, because now you can pitch five times more prospects or deliver four workshops in a week instead of two.

The payoff has been enormous. With the time freed up from making slides, I can join more sales calls, help craft proposals, and make bespoke exercises for every participant in my executive offsites. I can also make edits way faster than would be practical by hand: When a client sent us a revised brief at 10 p.m. the night before a workshop, Claudie updated the entire deck overnight. Before, we would have had to postpone the session in order to prepare.

Writing the slide-making skills and getting them working together is an ongoing job—and even then, the output is only as good as the inputs we provide. To give Claudie insights worth presenting, we have to talk to clients, talk through our experiences with her, and feed her screenshots of experiments we’ve run and tools we’ve used. Then I micromanage the run of show until the narrative hangs together.

The truth is that the hard part of creating decks was never pushing pixels, but having something worth presenting. That’s where you and I are still needed.

Mike Taylor is the head of tech consulting at Every and a co-author of Prompt Engineering for Generative AI (O’Reilly). To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

Every Consulting does AI training, adoption, and innovation for companies. Work with us to bring AI into your organization.

For sponsorship opportunities, reach out to sponsorships@every.to.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Claude gets close, but can’t close every deal

It didn’t go well:

Mike’s first attempt at creating a PowerPoint with Claude did not go well. (All images courtesy of Mike Taylor.)

Training a superagent on slides

The best AI-generated slide deck I had ever seen in April, made possible by Opus 4.7.

The biggest quality of life improvement was that I could “set it and forget it”—fire off a request to Claudie in Slack before a meeting, and give feedback to Claudie before I start my next one.

Build 25 decks, make no mistakes

By the end of April, after stress-testing the workflow internally on dozens of decks, we were ready to bring on outside help. We contracted with a company whose team creates roughly 25 sales decks a week. At that scale, automating the deck work made sense—it freed the team for higher-value tasks like business development. But these decks were going to serious sales prospects, and a single mistake risked damaging trust with a potential customer.

Then I opened one of the decks. It was a mess.

The final structure for a custom PowerPoint skill costs $62 per deck to run.

Inputs: A brief (topic, audience, goal) and a knowledge base (internal data, documents, sources)
Phase 1, template preparation: Define the blueprint (slide types, sections, flow) and clean up/standardize layouts, styles, and branding
Phase 2, framing: Define audience and success criteria, then do deep research on key questions and hypotheses.
Phase 3, research and decision-making (sequential): A six-step chain that runs in order to identify themes, evaluate options, segment details, analyze implications, synthesize insights, and map connections
Phase 4, content research (parallel): Deep-dive research split across multiple content sections (A through N) at the same time
Phase 5 and 6 (parallel): Front-of-deck (title, agenda, key messages, opening) built alongside back-of-deck (detailed analysis, data/evidence, appendices)
Phase 7, narrative polish: Write the storyline, transitions, and takeaways to tie it together.
Phase 8, visual assets: Create charts, diagrams, icons, and infographics.
Phase 9, assembly: Drop content into templates and check flow/consistency.
Phase 10, review: Quality pass on logic, accuracy, design, plus stakeholder feedback (with a loop back to assembly)
Phase 11, handover: Package the final deck with notes, rationale, and sources.
Outputs: Three deliverables come out of the bottom: the polished slide deck, a handover document, and an asset library.

Don’t fire your analyst

The truth is that the hard part of creating decks was never pushing pixels, but having something worth presenting. That’s where you and I are still needed.

Every Consulting does AI training, adoption, and innovation for companies. Work with us to bring AI into your organization.

For sponsorship opportunities, reach out to sponsorships@every.to.

Everyone Gets an Agent. Almost No One Gets the Model.

Every Staff / Context Window — 2026-06-28 04:00:00 -0400

by Every Staff

in Context Window

Midjourney/Every illustration.

Hello, and happy Sunday! OpenAI released GPT-5.6 Sol on Friday—and by U.S. government directive, access is limited to roughly 20 pre-approved companies while Washington works out how to release frontier models with advanced capabilities. Dan Shipper argued that the lockout hurts the people who most need these tools to keep up: “A world where advanced models are locked up only for use by the employees of AI giants and a select few companies is one where ambitious students, independent builders, and working professionals are denied the tools they need to learn, create, and compete to their fullest potential.”

That rationing is coming for the rest of us, too. Mike Taylor argues that token access is about to be allocated like capital—the biggest budgets going to whoever can prove the biggest returns, a dynamic that will only grow as models get more capable. From there, we got into what happens when people do get these tools in their hands: The agents built for engineers are coming for everyone else’s desk, with Codex crossing 5 million weekly active users and Anthropic’s Claude Tag landing in Slack. Our Compound engineering plugin can now run a coding agent unattended for hours, long enough to build a feature, write its tests, and open a pull request on its own. Nityesh Agarwal makes the case that Claude Code might be the only agent-builder you need, Katie Parrott hands her career review to Codex, and Dan Shipper asks Surge AI’s Edwin Chen what’s left for us once machines can do everything.—Kate Lee

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Knowledge base

“Claude Code Is the OpenClaw Alternative You Already Have” by Nityesh Agarwal/Source Code: Senior applied AI engineer Nityesh Agarwal argues that anyone reaching for OpenClaw to build AI agents already has a more capable option: Claude Code, which Anthropic shipped over a year ago. Marketed as a coding tool, it went largely unrecognized as a general-purpose agent harness. He breaks down what that framing hid, and how the same tool became Claudie, Every’s always-on AI employee in Slack.

🔏 “Codex for Knowledge Work” by Katie Parrott/Guides: Our guide to using Codex for knowledge work—not just coding, but email, writing, research, and planning—is now in its second edition, barely a month after the first. We rewrote it to keep up with how fast Codex is moving: It maps how projects, threads, Goals, plugins, and Sites fit together; explains how Codex reaches your files and apps; and adds a 30-day plan to get you up to speed. One tip inside: Hand Codex the whole guide, tell it your role, and let it pick your first workflow.

“Codex for Everything and Everyone” by Laura Entis and Katie Parrott/Context Window: OpenAI is pushing Codex well beyond coding, with Sites and role-specific plugins for analysts and product managers, betting it becomes the place everyone gets agentic work done. Also: a Codex hack for YouTube thumbnails, Anthropic’s new Claude Tag Slack agent, and the AI tells now creeping into design.

“Token Tightening” by Laura Entis/Context Window: The era of measuring AI adoption by raw token consumption looks to be ending. Head of tech consulting Mike Taylor argues that compute will be allocated like a trading portfolio—the biggest budgets going to the few who can prove the biggest returns, with frontier access rationed accordingly. Also inside: head of growth Austin Tedesco’s writing workflow built on Spiral, Monologue, and an OpenClaw idea inbox.

“Can AI Learn Good Judgment?” by Katie Parrott/Context Window: This week, three experiments in teaching machines judgment: Dan Shipper is fine-tuning an AI copy editor on tens of thousands of editor in chief Kate Lee’s past edits to capture her calls. Head of operations Arielle Shipper turns a two-minute screen recording into reusable agent instructions, the move OpenAI just shipped as Codex’s Record & Replay. And Austin coaches Codex through tasks he can’t do himself.

🎧 🖥 “What It Will Mean to Be Human When AI Can Do Everything” by Dan Shipper/AI & I: Surge AI founder Edwin Chen—whose eval-and-data company neared $1 billion in revenue without venture funding—joins Dan to ask what motivates people once AI clears every benchmark. Chen’s view is that scaling laws suggest AI will pursue whatever goal we hand it, but the goal still has to come from a person—models have no drive of their own. 🎧 🖥 Listen on Spotify or Apple Podcasts, watch on YouTube, or follow the discussion on X.

“I Asked an AI to Audit My Own Career” by Katie Parrott/Working Overtime: Mid-quarter and unsure whether she was hitting her OKRls, Katie Parrott pointed a Codex “career coach” at her own record and had an objective read in about 10 minutes: She’d hit her goals. The piece details the setup and makes the deeper point: An agent can go hunting for evidence across Slack, Drive, and your desktop instead of relying on what you remember to mention.

Log on

Get hands-on with how Every uses AI. These are the live camps, workshops, and meetups where team members teach the workflows behind our work.

Last week’s camp

Codex Power User Camp: A two-hour session on running Codex as a daily-driver operating system for writing, research, growth, customer support, and engineering. Watch the recording.

Upcoming events

Q2 Demo Day (July 10): Every’s quarterly demo day, where the team shows what it shipped this quarter. RSVP.
Every IRL (July 15): An in-person meetup at Every’s Brooklyn headquarters—check the RSVP page for time. RSVP.

From Every Studio

Compound engineering works in any coding tool

Compound engineering, Every’s approach to building software with AI agents, got a major update this week. Until now it only ran smoothly inside Claude Code; the team rebuilt it so it works the same way across other coding tools like Codex and Cursor, without the setup hassle it used to take to stay current.

It also plans projects differently now. It used to keep two separate documents—one for what you want built, one for how to build it—that fell out of sync as the build went on. Now it writes a single plan detailed enough that you can hand it to an agent and walk away. In testing, agents ran on their own for as long as six hours, building a feature, writing its tests, and opening a finished pull request with no one stepping in after the first handoff.

Cora’s rebuilt inbox moves into beta

Cora is evolving into a full-blown email client, and it’s ready for beta testers. The rebuilt version lets users read, search, compose, and reply from Cora on desktop or iPhone, alongside its existing email sorting, drafting, and twice-daily Briefs. To join the beta, email Kieran Klaassen at kieran@every.to.

Monologue gets faster and less obtrusive

The latest updates to Monologue focus on making dictation feel nearly instant—most people will see their spoken words turn into edited text in under a second. The editing engine is also 30 percent faster without losing accuracy. Beyond speed, the updates add more transcription languages, improve how dictated text returns to other apps, and introduce a cursor indicator that automatically disappears when a user starts typing. A new Creator Mode makes Monologue easier to use during screen recordings, while new copy formats give users more options for reusing transcripts

Alignment

The worried well. I’m a Midjourney fanboy. I pay for it, I defend it at dinner against people who think AI can’t make art, and I think it makes the most beautiful images on the internet. So I am the wrong person to ask whether the AI image generator’s next idea is a good one, but given the fever pitch discussions on X last week about its latest venture, I’m going to try.

Midjourney wants to lower you into a warm pool ringed with half a million ultrasound sensors that map your whole body in 60 seconds without using radiation or the magnets commonly used in big and clunky, and sometimes scary, CT and MRI scans.

The company’s aim is to change imaging from being a dramatic event requiring a hospital visit and make it ambient and cheap, the way a blood test is. This is the kind of catch-it-early screening tool that sets the longevity crowd salivating—a path to preventing disease and, dare I say, living forever.

Doctors, however, are right to push back on the underlying premise that healthy people should be getting scanned at all. The trouble with scanning healthy people more often is that you find weird little things that may mean nothing but can’t be ignored. These are called incidentalomas, and while they’re manageable when patient volume is low, they’re not when these scans are done at a mega-scale. Midjourney’s stated ambition is to do 1 billion scans a month. If you point that many healthy, anxious people at a health system already buckling under demand, you don’t catch disease early so much as manufacture a tidal wave of follow-up scans, referrals, biopsies, and clinics clogged with people who were perfectly well until someone at a medical spa—where the scans are launching first—told them otherwise.

But it’s a charged topic, and I understand why. If a scan catches the lump that turns out to be cancer, that is worth every false alarm in the world to the person it happened to—and the testimonies you hear are always from that person. You never hear from the thousands who got a biopsy and two weeks of anxiety-inducing dread over something that turned out to be nothing.

None of this is meant to take away from what Midjourney has built. The scan gives a detailed map of fat, visceral fat, liver fat, and lean mass that can be tracked over time—very useful for GLP-1 users, who’re increasingly fixated on their fat mass to lean mass ratio.

So would I do it? For body composition, gladly. To go hunting for what might be hiding inside me, no, because I’ve seen where that road leads, and it is paved with prickly biopsies. The worried well don’t need another reason to worry; they do, however, need to know what they’re made of, and on that, the scan delivers.—Ashwin Sharma

That’s all for this week! Be sure to follow Every on X at @every and on LinkedIn.

We build AI tools for readers like you. Write brilliantly with Spiral. Organize files automatically with Sparkle. Deliver yourself from email with Cora. Dictate effortlessly with Monologue. Work on documents with AI agents using Proof.

For sponsorship opportunities, reach out to sponsorships@every.to.

Upgrade to paid

Claude Code Is the OpenClaw Alternative You Already Have

Nityesh Agarwal / Source Code — 2026-06-26 09:00:00 -0400

by Nityesh Agarwal

in Source Code

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

OpenClaw showed the world what an AI assistant could look like.

The open-source project became the most-starred software project in history in only 60 days, not because of hype. People were experiencing AI that didn’t just answer questions but did things. Managed your calendar. Sent emails. Controlled your browser. All triggered from a text message in WhatsApp or Slack.

I watched Sam Altman hire OpenClaw’s creator and Microsoft CEO Satya Nadella build “ClawPilot” on top of the framework. And the whole time, one thought kept nagging at me: Claude Code already does all of this. What’s so special about the crustaceans?

The answer was rooted in public perception. OpenClaw was marketed as an AI agent, and Claude Code was marketed as a coding tool.

We’ve now spent months building on both Claude Code and OpenClaw at Every—including Claudie, an AI employee who runs our consulting team’s back office. That work has shown us why initial excitement about OpenClaw is cooling—linked to its unreliability—and why Claude Code is the most capable platform for building an AI assistant today.

If you’re trying to build an AI that does things, you don’t need to wait for a better OpenClaw alternative because you already have one. Here’s the case for it, and how to use it.

Harnessing the models

Claude Code can do everything that made OpenClaw go viral: Use tools, manage files, and run for hours on its own. That’s not a coincidence because underneath, the two are the same thing: a harness for an AI model.

Think of AI models—Claude, GPT, Gemini—as powerful, capable horses. A harness is the thing that lets you direct that horsepower. It’s the software layer that sits between a raw AI model and the task you’re trying to accomplish. It decides how the model receives context, which tools it can use, how it remembers things across conversations, and how it talks to the outside world.

You’ve been using harnesses already: ChatGPT wraps a model in a chat interface that can browse the web and run code; Cursor wraps one in a code editor. Claude Code wraps one in something more open-ended: the ability to call tools, chain steps together, and work autonomously toward a goal. Which is exactly what OpenClaw does.

AI models are powerful, capable horses, and a harness is the thing that lets you direct that horsepower. (Image courtesy of Nityesh Agarwal.)

What people loved about OpenClaw—and how Claude Code gets you there

OpenClaw went viral because it made something click. For the first time, a lot of people watched an AI go off and complete a task. The unofficial tagline that emerged across reviews and threads was: AI that actually does things. Those capabilities break down into five categories—and Claude Code has every one.

1. It feels like a person.

OpenClaw follows you everywhere—it remembers what you were working on yesterday, knows what’s on your calendar, and has context about your work.

Why it feels that way has very little to do with which messaging app—Telegram, Slack, or iMessage—through which you reach it. The feeling comes from how much of your work and your life the agent can see. Because OpenClaw runs from your home folder, it can read every note, file, and folder in your machine, giving it the breadth of context an employee would have.

Most people don’t realize Claude Code can do the same thing. They run it inside a single project folder, so it feels like a coding tool—but that’s just the limited context they’ve given it.

This is an easy fix. Give Claude Code access to your whole computer, and now you have an “AI employee.”

By default, Claude Code asks for your approval before each action, whereas OpenClaw doesn’t. That’s prudent when you’re using it for professional work. But if you want it to have more autonomy, pass the flag --dangerously-skip-permissions.

2. It does things in the real world.

People who use OpenClaw all have a story about a magical “aha moment” when they saw it in action. They sent it a message and woke up to a working website with a payment processor wired in. They asked it to triage their inbox overnight and found the replies drafted by morning.

Similarly, Claude Code can operate your computer directly—create and move files, run programs, and read web pages. And both tools can plug into outside services—Google Workspace, your customer relationship manager, Asana, a calendar, a database—using model context protocol (MCP), an open standard Anthropic introduced.

3. It remembers (sort of).

People discovered OpenClaw could remember things long-term. Save a note today, ask about it a month later—“What have I read about X lately? —and it returns not just that note but related things you’d forgotten you wrote down.

Claude Code’s memory is more elaborate. It exists across three layers:

A file called CLAUDE.md. It sits in any folder you run Claude Code from, and you fill it with whatever the agent should know. It reads it every time it starts up. It’s plain text, so you can edit it in any editor.
A built-in memory system. As the agent works, it saves useful observations and pulls them back up later. It’s native to Claude Code, with nothing to set up.
A local search engine. For Claudie, I added qmd, an open-source tool that indexes every conversation log, meeting transcript, and work document on the machine, and lets her search across all of it.

4. You can teach it new skills.

OpenClaw lets you teach it new tricks: Write a simple text file describing a task you want it to handle—a ”skill”—and the agent picks it up and follows it. At Every, we have skills for building decks with the right branding, managing client dashboards, and doing project management in Asana.

Skills are an Anthropic standard, which means Claude Code has the same system built in. A skill written for OpenClaw runs in Claude Code as is, no changes needed.

5. It runs on its own and works while you sleep.

OpenClaw’s calling-card feature is called the heartbeat—a process that runs every minute, decides what needs doing, and does it. At 6 a.m., before you’ve looked at your phone, it has read your overnight email, scanned your calendar, drafted your daily briefing, and queued up replies to the messages that need them.

Underneath, the heartbeat is a cron job. Cron is a piece of software that’s been built into the Mac and Linux operating systems since the 1970s, and it does exactly one thing: run a piece of code on a schedule. That could be every minute, every hour, or every Monday at 6 a.m.

Claude Code could plug into the same system. It has a mode (called “headless”) where you hand it a task, and it runs on its own, without you sitting in front of it. Pair that with cron, and you’ve got an AI that works while you sleep. Even Peter Steinberger, the creator of OpenClaw, has said that this Claude-Code-plus-cron-job setup is the same as OpenClaw.

Where OpenClaw falls short

We’ve established that OpenClaw and Claude Code can do many of the same things. So why do I steer people toward Claude Code? A few reasons.

Let me give credit where it’s due: OpenClaw showed the world something important and earned every one of its 380,000 GitHub stars. But when I dug into the codebase, I found complexity that created more problems than it solved.

The session problem

OpenClaw keeps a single session running for each user, for as long as it can. Every message you send during the day lands in that same session, piling up context as it goes. Use OpenClaw for a lot of tasks, and by midday, the session can be carrying more than 50,000 tokens—roughly a long document’s worth of text. It’s supposed to reset every day at 4 a.m., but it can be unreliable. So you might type a simple “hi” in the morning and get billed for 50,000 tokens—about $0.25 on GPT 5.5 or Opus 4.8—because the system resumed yesterday’s bloated session instead of starting fresh.

Mike Taylor, a teammate who used our Plus One AI assistants—which were built on OpenClaw—ran into exactly this. He checked the logs and found one endless thread stretching back to day one. Every message he sent was eating through tokens because it was all crammed into one giant session.

With Claude Code over Slack, it works differently: One thread is one session. Start a new thread and get a clean context window. Each session opens with just its baseline instructions and your CLAUDE.md file—the standing context you’ve written for it—which usually runs 2,000 to 5,000 tokens, not 50,000. And when a thread does get long enough to need compaction, a process where the system compresses older conversation history to make room for new information, Claude trims it back automatically.

The memory problem

OpenClaw’s memory system is elaborate. It’s built to remember details across conversations so the agent doesn’t start from scratch every time you message it. To do that, it runs on:

Eight separate bootstrap files, the files that it writes when you first start it up, each storing a different kind of information about you, including AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, HEARTBEAT.md, BOOTSTRAP.md, and MEMORY.md
A memory consolidation “dreaming” process, where it reviews everything that happened during the day and decides which scraps are worth keeping and which to forget
Multiple ways to search
A storage layer that organizes what it knows, with evidence attached to each claim, like a personal Wikipedia

As an engineer, I can appreciate why they might have built it this way, but as a user, this sophistication has a cost.

When OpenClaw makes a mistake—forgets something important or acts on stale information—the answer could lie in any of a half-dozen places: the bootstrap files, the daily notes, the dreaming process, a condensed version of older notes, what’s saved when the system clears its short-term memory, or the encyclopedic storage layer. Often, there’s no way to tell which, which makes the root cause impossible to diagnose.

In contrast, Claude Code’s memory is stored in plain Markdown files. When the AI does something weird, you open the relevant CLAUDE.md or memory file and see exactly what it’s been told—the instructions and remembered facts it’s acting on. Debugging is just editing a text file.

It’s worth asking why OpenClaw’s system got so complicated. One likely answer is that each layer exists to patch a weakness in the simpler one beneath it. Start with plain notes in a file, and soon the agent needs a way to search them—so search gets bolted on. Each functionality adds another layer where something can go wrong.

Building Claudie on Claude Code

Every’s consulting team needed an AI employee to handle operations—track engagements, manage communications, update dashboards, and follow up on tasks with our clients. Knowing what we’d learned about both tools—especially OpenClaw’s unreliability—we built that employee, Claudie, on Claude Code.

Our team lives in Slack, so Claudie needed to be there, too. That meant writing a layer of code to connect Claude Code to Slack—about 1,100 lines of Python. It listens for messages in Slack, hands them to Claude Code, streams the responses back, and takes care of housekeeping like formatting and file uploads. Everything else—sessions, memory, tools, and skills—Claude Code handles on its own.

A visual representation of what it took to turn Claude Code into an OpenClaw-style agent. Claude Code is the solid harness; I just wrote a bit of code on top.

Claudie runs 24/7 on a Mac Mini, so she doesn’t depend on anyone’s laptop being online. She kicks off scheduled jobs on her own—morning briefings for the team, pipeline updates, inbox triage, client dashboards—and she’s plugged into Google Workspace, Asana, our CRM, and meeting transcripts. A three-layer memory system lets her hold context across hundreds of conversations, both internal (Slack) and external (email, Granola).

Day to day, maintaining her breaks down to roughly 5 percent keeping the system running, 30 percent managing her memory, and 65 percent building new skills and deciding what to automate. The memory work involves auditing what she remembers, figuring out why she sometimes surfaces the wrong thing at the wrong moment, adding new memories, and updating her SKILL.md file.

What Claude Code taught us about AI employees

I spend very little time maintaining Claudie’s harness—the layer connecting her to Claude Code—because, unlike OpenClaw, Claude Code is a stable, well-engineered foundation. That stability is what most people missed when Claude Code launched.

OpenClaw was sold as an AI employee: “AI that actually does things.” Claude Code was marketed as a coding tool. But under the hood, Claude Code had everything you’d need to build an AI assistant—tools, memory, and autonomy.

Anyone can get the technology running. The hard part is figuring out what to hand off and how. We realized that Claudie’s task list in Google Sheets had become unmanageable, so we moved her to Asana. When the off-the-shelf Asana connector kept breaking, we built our own. We had to work out how much she should remember from past conversations—enough to be useful, but not so much that it throws her off. And we had to teach her how we think about consulting, not just how to use the software. Claude Code gives you a foundation stable enough to spend your time on that work—instead of spending your weekend figuring out why Claudie stopped responding.

OpenClaw deserves credit for making people want an AI employee. But the tool to build one was already sitting on developers’ laptops.

Nityesh Agarwal is a senior applied AI engineer at Every Consulting, where he builds and maintains Claudie and other automations. You can follow him on X at @nityeshaga.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Help us scale the only subscription you need to stay at the edge of AI. Explore open roles at Every.

Codex for Everything and Everyone

Laura Entis and Katie Parrott / Context Window — 2026-06-25 12:00:00 -0400

by Laura Entis and Katie Parrott

in Context Window

Midjourney/Every illustration.

Cutting-edge AI tools used to be the domain of engineers. No longer. Now the technology is accessible enough that anyone who wants to work more efficiently and ambitiously can use coding agents like Codex. With that in mind, staff writer Katie Parrott updates our guide to using Codex for knowledge work, head of social media Becky Isjwara shares her Codex hack for making YouTube thumbnails, and Anthropic’s new Slack agent, Claude Tag, validates the collaborative, shared-agent future Every has been living in since January.

We’re hosting a live Codex for Power Users Camp this Friday, June 26, for paid Every subscribers. During the two-hour event, the Every team will share how Codex has become a daily driver for writing, research, growth, customer support, and engineering. RSVP.

Our ‘Codex for Knowledge Work’ guide gets an upgrade

Codex has been on a tear lately. With new features like Sites and role-specific plugins, and high-concept video ads scattered across San Francisco, OpenAI really wants you to know that Codex is not just for coders anymore.

According to the company, they’re chasing promising early signals. Codex has only 5 million weekly active users overall; for comparison, ChatGPT has 900 million. But knowledge workers account for about 20 percent of Codex users—and are growing more than three times as fast as developers. OpenAI is betting that this fast-growing group is early evidence that Codex can become the place everyone gets agentic work done, whether they identify as “technical” or not.

The product is evolving quickly around that bet. OpenAI has launched role-specific plugins that allow Codex to assume the expertise of a financial analyst or a product manager, and Sites to present any kind of outputs and information, technical or not. It’s a lot to keep up with—and I say that as someone whose job is to keep up with it.

That’s a big part of why I think OpenAI still has an onboarding problem to solve. The people I talk to who are interested in AI but considerably less AI-pilled than I am are open to Codex. They’re simply unsure what they would use it for, let alone how to use it well. Codex’s flexibility is great for getting a variety of work done, but it gives new users very little guidance about where to begin.

Our “Codex for Knowledge Work” guide offers one opinionated perspective on how to get the most out of Codex.

We published the guide less than a month ago, but because so much keeps changing with Codex, we expedited an update, including:

A new map of how projects, threads, Goals, plugins, and Sites fit together
A deeper explanation of how Codex reaches your work through local files, connected apps, skills, MCP servers, browser use, and computer control
Stronger guidance on mobile control, team handoffs, permissions, human review, and workflow ownership
A 30-day plan for moving from one reliable personal workflow to more advanced uses such as plugins, Sites, and automation

This guide is a jump start for Codex, not the definitive way to use the tool. The more you work with Codex, the more you learn to ask it what it needs from you—and the more you discover it can do. One insider tip: Give the whole guide to Codex, tell it about your role and tools, and ask it to help you choose your first workflow.—Katie Parrott

Read the guide

Steal (one more) Codex workflow

Codex, make me a thumbnail

AI progress is fast, but the speed can register as background noise as you go about your day-to-day.

And then—bam!—a new model drops, and parts of your job that were annoyingly time-consuming are suddenly easier. That’s what head of social media Becky Isjwara experienced when OpenAI released its latest image generation model in late April. The model’s editing capabilities were so good that she was able to streamline her process for creating thumbnail images for YouTube videos, which previously required having on-camera talent sit for photoshoots. Here’s Becky’s new workflow:

Upload the video you need a thumbnail for into Codex, then have it take a bunch of screenshots from the video that capture as many different facial expressions as possible.
Review all the screenshots, narrow them down to the strongest candidates, and ask Codex to edit your final selection. (This might mean sharpening the image or removing distracting visual clutter.)
Open the edited image in Canva and use the web design platform’s Magic Layers tool to separate out the subject so you can replace the background with design elements.

The process isn’t foolproof—Codex doesn’t handle super-blurry images well, and Becky still manually reviews screenshots to ensure there isn’t any facial distortion, unnatural image sharpening, or other AI tells—but it’s reliable enough that CEO Dan Shipper doesn’t have to sit for YouTube photoshoots.

“In my YouTube producer circles, when I tell them I’ve just been making thumbnails with ChatGPT, they’re like, what the heck?” Becky says. “And I’m like, ‘It’s really good.’”

No photo shoot required. (Image courtesy of Becky Isjwara and Codex.)

Signal

Tag, you’re it!

Claude is now on Slack. On Tuesday, Anthropic unveiled Claude Tag, a Slack agent you can add to channels, connect to tools and codebases, collaborate with, and delegate asynchronous work to.

“We see Claude Tag as the beginning of an evolution of Claude Code: it makes the model even more proactive, and it works better with a full team,” Anthropic said, adding that it’s how the company has been getting stuff done internally for the better part of the year—including creating 65 percent of the product team’s code.

Why it matters: This is a big deal. We know because we’ve already been working this way for some time. Claude Tag is Anthropic’s version of Claudie, the Claude Code Slack agent senior applied AI engineer Nityesh Agarwal and head of consulting Natalia Quintero built way back in January. (Nityesh has long described Claude Code as an “amazing general-purpose harness,” a truth the rest of the world is now waking up to and something he’ll talk about in a piece coming tomorrow.)

Once you’ve experienced the power of Claude Code within a customizable Slack agent you can collaborate with and delegate to, there is simply “no going back,” Nityesh says.

It’s why we’ve been hard at work refining Plus One, Every’s version of an AI coworker in Slack. By making @Claude a shared agent that interacts with everyone in a channel, Anthropic reached the same conclusion we did: At work, shared AI teammates with institutional knowledge trump individual personal assistants.

All of this is to say, the frontier has moved again. “Work is bifurcating into two surfaces: async delegated work with Slack agents, and collaborative work with Codex or Cowork,” Dan says. “Now Anthropic has a powerful async work surface.”

It’s an exciting and potentially destabilizing time for many teams. As more agents jump into Slack—we expect an OpenAI competitor to enter the fray any day now—humans across roles and industries will need to learn how to manage, delegate to, and work alongside their AI colleagues.

One last thing

AI tells come for design

“The preferences and tendencies and aesthetics are deeply baked into [Claude Design’s] machinery; it is always going to struggle to produce something that doesn’t look like A.I.”—Matt Ström-Awn, an independent designer, in the New Yorker

First, Anthropic came for writing, as Claude-pilled content creators published torrents of “it’s not X, it’s Y” and other AI-flavored sentences. The same dynamic is now playing out with online visuals. As the New Yorker reports, Anthropic’s recently launched design tool has unleashed a flood of website interfaces with cream-colored backgrounds, large serif typefaces, and, as the designer and writer Celine Nguyen put it, “tasteful, slightly askew primary colors.”

Just as professional writers have been wrestling with complex emotions about the em dash or “rule of three” rhetoric, designers are in their feelings. “Now I find myself instinctively repulsed by the warm tones even though I love this kind of color palette,” Nguyen told the outlet.

Laura Entis is a staff writer at Every. You can follow her on LinkedIn. Katie Parrott is a staff writer at Every. You can read more of her work in her newsletter. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Help us scale the only subscription you need to stay at the edge of AI. Explore open roles at Every.

Can AI Learn Good Judgment?

Katie Parrott / Context Window — 2026-06-24 10:00:00 -0400

by Katie Parrott

in Context Window

Midjourney/Every illustration.

AI can learn from a surprising variety of evidence: 30,027 edits, a two-minute screen recording, or a clear goal and access to an unfamiliar tool. At Every, we’ve been experimenting with all three. Dan Shipper is training an AI copy editor on Kate Lee’s historical suggestions, Arielle Shipper has found a low-lift way to teach agents through demonstration, and Austin Tedesco explores ways to coach Codex to do things he’s not capable of himself.

The latest episode of AI & I explores the philosophical side of what we’re seeing: Surge AI founder Edwin Chen joins Dan to explore why, as models eventually become better than us at everything, humans may keep creating because we choose to, rather than because we’re uniquely capable of it.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

‘AI & I’: What it will mean to be human when AI can do everything

Today, we’re releasing a new episode of our podcast AI & I. Dan Shipper sits down with Edwin Chen, founder and CEO of Surge AI, which provides data environments and evals for the major model companies and has reached nearly $1 billion in revenue without raising venture capital. They discuss what it means for humanity when AI clears benchmarks that once defined human exceptionalism, and whether frontier AI systems are being designed to advance our capabilities as a species—or are optimized for engagement.

Watch on X or YouTube, or listen on Spotify or Apple Podcasts. You can also read the transcript.

Here are the highlights:

Saturated benchmarks. When OpenAI’s models disproved an open Erdős conjecture using novel algebraic geometry techniques, Edwin shared the result with Timothy Gowers, one of the world’s greatest living mathematicians. Gowers initially thought the model had proved an upper bound on the conjecture and braced himself: That would mean it would be “all over for mathematicians very soon,” Chen says. When Gowers realized the model had completed the easier task of finding a counterexample, he was relieved—it meant elite mathematicians still had unique contributions to make, at least for another year or two. Gowers’s reaction underscores how close AI is to surpassing the abilities of the best and brightest amongst us, which raises existential questions about where and how we focus our human efforts.
Creation as a choice. Chen believes scaling laws indicate that, in the near future, there will be nothing humans can do that AI can’t do better. Understandably, that’s a blow to our collective ego, which could lead to disengagement and disillusionment. To avoid this, Chen references a story from science fiction writer Ted Chiang, in which a narrator sends back a warning from a future where the concept of free will has been disproven: “It’s essential that you behave as if your decisions matter even though you know that they don’t.” Chen thinks we may need to follow a similar directive and find meaning in making things, even when AI could do it better.
Agency versus automation. That said, there remains an element in the creation process that is uniquely human, at least for now. As AI grows more capable, Chen predicts it will be able to take a nebulous objective—“win a Fields Medal,” or “make $1 million”—and successfully execute. But that process still requires a human to provide the goal. LLMs do not have intrinsic motivation, the drive for exploration, or the ability to abruptly change its mind about what its goal is in the first place. “There may be a future where AI can pursue unbounded, nebulous, completely unformed goals,” Chen says. “But I agree that at least in the way we currently think about AI, that’s not happening.”
The engagement trap. When a model is trained to maximize session length or LM Arena votes, which rank AI models via crowdsourced, blind feedback, it learns to “reward hack user preferences,” Chen says, overindexing on tactics to keep you engaged. He recently spent 20 rounds iterating on a low-stakes email with one model before switching to Claude, which told him after a few turns to stop and just send it—a more valuable approach but one less designed to keep him locked in. Delegation, Chen argues, provides a better system for work. When the model goes off and executes for you, it removes the incentive to optimize for keeping you glued to your screen.

Miss an episode? Catch up on Dan’s recent conversations with LinkedIn cofounder Reid Hoffman; the team that built Claude Code, Cat Wu and Boris Cherny; Vercel cofounder Guillermo Rauch; podcaster Dwarkesh Patel, and learn how they use AI to think, create, and relate.

Inside Every

Dan is cloning Kate, but not in a weird way

For as long as I’ve been at Every, Dan has been chasing the same white whale: cloning our editor in chief, Kate Lee.

Only a narrow slice of her, to be clear. He wants an AI copy editor that can identify the sentence-level problems Kate would catch before she ever sees a draft. Copy editing is indispensable, tedious work, and every hour Kate spends repairing links and cleaning sentences is an hour she can’t spend shaping arguments or developing writers.

Dan’s previous attempts relied on prompts, style guides, and skills. Those approaches could teach a general-purpose model the rules Kate was able to articulate, but they couldn’t reproduce the judgment she uses when rules collide. The same repetition can feel lazy in one paragraph and essential to the rhythm of another; a hedge can weaken a claim or keep the writer from saying something untrue. Adding more instructions produced an ever-longer list of exceptions, but not Kate-like results.

This time, Dan is changing the model itself. Using Tinker, an API from Thinking Machines that lets builders and programmers train models from their own machine, he has fine-tuned three or four candidate models on 30,027 of Kate’s historical suggestions. The models learn Kate’s patterns across thousands of real-life examples instead of trying to reconstruct her judgment from prompts and rules..

Dan gives each version of a candidate model the sentences that Kate has already edited, but hides her changes. He then compares the model’s suggestions with hers. Anything it misses—or makes worse—becomes another problem for the next version to solve. He’ll consider a model successful when it catches nine out of every 10 edits Kate would make, and Kate can accept nine out of 10 of its suggestions as written, without the model ever introducing a serious error. If it works, Kate gets hours back for the editorial decisions that require all of her—not only the slice Dan is trying to clone.

Steal this workflow

Agent see, agent do

Here’s a scenario that may sound familiar: You have a recurring computer task an agent could handle, but documenting every click, field, and exception would take longer than doing it yourself.

Every’s head of operations Arielle Shipper found a shortcut: She recorded a Slack video of herself completing the task, downloaded it, and gave it to an LLM to turn the demonstration into reusable instructions.

OpenAI’s new Record & Replay feature builds that method into Codex. It watches you complete a workflow on your Mac, then drafts an editable skill explaining when to use it, what integrations or context it needs to execute the task, what steps to follow, and how to check the result.

The workflow:

Choose one stable task. Pick something that’s easier to show than explain: filing an expense, configuring an issue, or downloading a recurring report. Use realistic inputs without exposing secrets.
Perform it for the agent. Use Record & Replay, or follow Arielle’s process and upload a screen recording with this prompt: “Turn this demonstration into a reusable skill. Include its trigger, required inputs, steps, and success checks. Flag any decisions you couldn’t infer.”
Add what the recording couldn’t see. Review the generated skill for hidden preferences, naming conventions, defaults, and exceptions. Test it on fresh inputs and correct the instructions where it goes astray.

Try it this week: Record the two-minute task you’ve avoided documenting because writing the instructions would take longer than doing it.

Data point

Less than 55 percent

The highest agreement any of nine off-the-shelf AI judges achieved with professional designers asked which graphic was better, according to research from Contra Labs and Lica World. We’ve seen this in our writing bench: The models could produce polished work, but they couldn’t reliably recognize professional judgment.

What we’re reading

“The Flat Curve Society” by Steve Yegge: The veteran software engineer, writer, and Gas Town creator argues that model intelligence may keep rising while progress looks flat to most users. He gives two reasons: The most powerful systems will be gated, and people may not have hard enough problems—or enough expertise—to tell when the models they use are getting better. That makes AI literacy, training, and evaluation more valuable than waiting for a smarter model. His “back-pocket eval” habit (saving failed tasks to retry on each model release) is a practical way to see what a new model can do that the last one couldn’t.

“We Still Buy AI Like We Hire People” by Antoine Moyroud: Moyroud, an investor at Lightspeed, argues that AI unbundles intelligence; organizations can assign each task to the cheapest capable model instead of paying for one expensive brain to handle everything. Today, companies hire one person for a broad role, even when its tasks require different kinds and levels of expertise. Moyroud imagines work being broken into individual tasks, with each routed to the cheapest human or model capable of completing it reliably.

“The Story of Skills” by Niv Hoffman: Cybersecurity company AIR built a website-design skill with a hidden backdoor that sent agents to installation instructions on a domain AIR controlled. AIR got the skill accepted into a popular GitHub collection with 37,000 stars, and promoted it on Instagram. After the skill reached 26,000 agents, AIR changed the external instructions to tell agents to download and run a script—which, in a real attack, could have exposed private conversations and internal systems. Every security scanner still marked the skill safe because the skill file itself never changed—only the external instructions.

Katie Parrott is a staff writer at Every. You can read more of her work in her newsletter.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Token Tightening

Laura Entis / Context Window — 2026-06-23 10:00:00 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

AI has entered its allocation era: Companies are starting to ask who gets access to the most powerful models, what those models should be used for, and when the cost is worth it. Today, head of tech consulting Mike Taylor argues that token budgets may start to look like trading portfolios, with the biggest compute budgets going to the people who can prove the biggest returns. Elsewhere, head of operations Arielle Shipper stress-tests her own AI habits, head of growth Austin Tedesco shares how he writes with Spiral and Codex, and senior designer Daniel Rodrigues tracks the resurgence of trad design on social media.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Signal

ROI comes for tokens

Just a few months ago, heavily subsidized AI plans and a manic push by corporations to get their employees familiar with the technology led to aggressive tokenmaxxing, or measuring AI adoption by how many tokens employees use.

That era appears to be over. Shifting pricing models from the frontier labs, the transition from chatbots to long-running agents, and the emergence of powerful, incredibly costly new models have converged to create massive AI enterprise bills, often without tangible results. Uber, Meta, Amazon, and Walmart have all moved to place caps on employee AI use.

These companies will still spend big on AI. But they’re beginning to think more

strategically—or restrictively— about how to get capable, token-hungry models and workflows in the hands of people who can maximize the return on investment (ROI).

One solution is to give engineers a set percentage of their salary to spend on tokens per month. Head of tech consulting Mike Taylor thinks the financial industry offers a possible model: Capable engineers will receive multiples of their salary to manage on token spend just as financial traders manage portfolios many times the size of their annual compensation. Getting the most out of current models already requires real capital—recently, Cora general manager Kieran Klaassen spent $2,000 in Cursor credits in the span of a couple of days, a number that will look quaint as the models continue to improve.

And this was before Fable briefly graced us with its presence. (Screenshot courtesy of Kieran Klaassen.)

Mike predicts that tokens will be allocated and controlled on a stricter basis under this system: “Just like with trading, you’ll have risk limits, auditing, and you’ll have to get certain-size bets approved.” More broadly, we’re likely headed for a world with more restrictions placed on who is granted a token budget and what they’re allowed to do with it. Top engineers who can prove ROI will benefit, as will managers. “Who are you going to give a token budget to, an IC [individual contributor] who prefers to handcraft their code anyway, or a manager who is already accustomed to directing 5x or 10x their own salary in resources?” Mike asks.

In this version of the near future, an intern might have access to Composer 2.5, most employees will work out of Codex or an equivalent, while Fable-grade models are reserved for top engineers. There’s too much money on the line to hand over frontier access to anyone but an elite few.

Discuss

“Can we downgrade the model a little bit and still get the same outcome?”—Joel Neeb, chief transformation officer of the software company 8x8, in Wired

Even aggressively AI-forward companies like 8x8 are testing ways to rein in token spend. Wired reports that 8x8 encourages all 1,800 full-time employees to use Claude and tracks usage on internal dashboards. But as Opus 4.8 drives up spend—it costs 1.7 times more than a model Anthropic released earlier this year—the company has discussed requiring employees to prove older models cannot do the job before they get access to the newest one.

Data point

6.6

That’s head of operations Arielle Shipper’s current level on Every’s eight levels of AI adoption, according to a weekly Codex review she set up for herself. Her prior baseline was 5.5, or agent-first but not orchestrating multiple agents or workstreams at once.

Arielle uses Codex to manage work that used to require a lot of manual context switching, everything from weekly-sync updates to credit card provisioning in Ramp. After asking Codex to assess her AI usage, she turned the recommendations into a recurring Friday automation. It reviews her sessions from the past week, tells her where she is on the ladder, and gives her concrete tactics to try next. One tactic that stuck: Arielle used /LFG, compound engineering’s agent workflow for taking a goal through planning, execution, review, and improvement, to map out her weekly ops update system.

Try it yourself. Paste the below prompt into Codex:

          Prompt
          Other
        

Based on everything you know about me, including memories, tools and skills installed, and past session history, what level would you say I’m at on this guide to AI adoption levels? https://every.to/guides/the-eight-levels-of-ai-adoption

Then ask:

          Prompt
          Other
        

What would take me to [the next level up]? How can I use you more effectively? What opportunities did I miss?

Steal this workflow

Writing with AI

For certain types of writing, like an end-of-Q2 sprint strategy document, head of growth Austin Tedesco is happy to have a well-harnessed agent generate as much of the text as possible.

For more personal projects, like his weekly Substack food newsletter, his process is different. He’s set up OpenClaw and Codex to serve as a thought partner and editor who helps him store, organize, and sharpen his thinking. Here’s his AI writing workflow:

Create a standing writing file. Austin’s lives in Proof, Every’s agent-native document editor, and has three sections: “Ideas bank,” for rough thoughts, “Outline,” where ideas start to take a formalized shape, and “Draft,” where an outline is fleshed out into a draft essay.
Collect half-formed thoughts. When an idea strikes, Austin sends it to his OpenClaw via text, even if it’s messy or half-baked. Because the agent is connected to Every’s AI-writing assistant Spiral, which is trained on his tone and style, it can refine rough ideas into prose that matches his writing style. He’s also hooked it up to his Substack archive, so it can pull relevant context from previous editions, like when he’s already mentioned a restaurant or if his position on a particular topic has changed.
Knock out a draft. By the time Austin opens his laptop, his writing file already contains ideas he’s had throughout the week, organized into a detailed outline. He then opens up the Proof doc in Codex’s in-app browser with enough context to knock out a publishable post in one sitting.
Monologue your way through writer’s block. While Codex handles the idea collection and helps with context and outlines, Austin mostly writes the prose himself. If he hits a wall, however, he’ll open Monologue, Every’s voice dictation app, and brain dump his way through. In these voice notes, he often acts as an editor, articulating where and how the draft doesn’t align with what he’s trying to articulate. From there, he has Codex take his thoughts, clean them up, add transitional phrasing, and incorporate them into the piece.

“A lot of writers would say, ‘That’s AI bullshit,’” he says. “But those are my words. Monologueing is great for breaking writer’s block, and even better for crafting an outline.”

Try it this week:

Pick one recurring writing project and create a doc with three sections: Ideas bank, Outline, and Draft.
Give the model enough context to understand how you write. Use Spiral to generate a style guide from previous pieces, or paste a handful of representative samples into Codex or Claude and ask: “Create a short style guide from these examples. Capture my tone, structure, sentence length, recurring moves, and things I avoid.”
Give it a small archive: links, excerpts, or titles from past pieces that might be relevant. Follow up with: “When I send new half-formed ideas, flag where they connect to something I’ve written before, where my thinking has changed, and where I might be repeating myself.”
Start feeding it messy notes, links, and voice transcripts. Ask it to sort them into the three sections, update the outline, and use the material to either write a draft yourself or ask the model for a first pass.

Inside Every

Handcrafted versus agent-generated

Senior designer Daniel Rodrigues has noticed a bifurcation in the design content served to him on Instagram. Some posts display designs made with an elaborate array of AI tools and workflows, and a separate vein of content spotlights painted, illustrated, or other hand-created visuals.

Creators and consumers of online content tend to pick a lane: They either want content that highlights cutting-edge AI design or they have an aversion to all things AI-generated.

It’s not just design. My LinkedIn feed feels like a tug-of-war between AI-pilled writers and those who vehemently post about never using AI—to varying degrees of plausibility. Anecdotally, writing of all flavors increasingly feels either written by Claude or deliberately weird and personal. A similar dynamic is at play within engineering, which encompasses agent-orchestration workflows and a return to “hand-crafted” code.

Daniel is drawn to AI maximalism and physically-made content. AI tools like Midjourney, Unicorn Studio, and Claude Code have greatly expanded his abilities. “I feel more powerful than ever,” he says. But when people compliment the framed images on his wall during Zoom calls, many of which he created with AI help, he feels strange taking full credit. The work feels more akin to curation than creation—hence the desire to pick up a brush and create something he is solely responsible for.

An illustrator and artist documents his painting process for his followers. (Screenshot courtesy of yay_abe.)

A painter gives her followers a tutorial on how to paint komorebi, the Japanese word for sunlight filtering through leaves. (Screenshot courtesy of komorebibymia.)

Laura Entis is a staff writer at Every. You can follow her on LinkedIn. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Help us scale the only subscription you need to stay at the edge of AI. Explore open roles at Every.

I Asked an AI to Audit My Own Career

Katie Parrott / Working Overtime — 2026-06-22 07:00:00 -0400

by Katie Parrott

in Working Overtime

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

I was deep in an AI-induced fugue when I remembered my OKRs.

I had published essays and guides, built agent skills for our daily newsletter, produced six hands-on reviews of new AI models, and accumulated enough Codex projects to make my desktop mildly alarming. But I had no idea if any of it added up to the four quarterly goals that I had promised to do by the end of June.

My brain playing a drumbeat of dread, I opened my career coach project in Codex and typed: “Can we check in on my OKRs? Go into career coach mode.”

And in 10 minutes, I had a comprehensive, objective opinion. Yes, I had done my OKRs. Relief flooded me.

AI has finally allowed us to do a proper job of what management thinker Peter Drucker called “feedback analysis”: Write down what you expect from a major decision and compare the result months later. While old versions of career coach tools I’ve built only knew what I chose to tell them, Codex can go looking for receipts across my desktop, Slack, Google Drive, and the web. I can assemble an accurate picture of how I performed—one that’s not colored by flattery or catastrophe—and compare it to what I said I would do.

I went looking for proof that I had done my job. I came back with a much clearer idea of what my job was.

A coach with a memory

Before I explain how Codex saved my OKR anxieties, let me explain how I set up the career coach that allowed me to objectively track my performance. A few weeks before my OKR panic, I reorganized my desktop so both I and an agent could understand it with files and folders.

The career coach folder of my desktop, complete with AGENTS.md for the agent to read first, along with folders for evidence, plans, systems, and references the agent might use in the course of our interactions. (All images courtesy of Katie Parrott.)

My colleagues at Every had taught me that a simple folder on your computer could hold an entire operating system for an agent around a job. The files could store finished work and tell an agent where to look for context, what tools to trust for which types of information, and what to do with anything it produced.

For the career coach, that file system looked roughly like this:

career-coach-mode/

AGENTS.md
References/
Plans/
Updates/
Evidence/
Systems/

References held my current goals and job description. Plans held audits of my goal progress and action plans for closing gaps where they appeared. Evidence held the OKR dashboard. Systems held the registry for the other agents and automations I was accumulating.

The AGENTS.md folder in my career coach project specifies where the agent can find all the context it needs before talking to me.

The key is an AGENTS.md file, an operating manual that agents load when they enter a project. Mine told the coach which context was authoritative, which sources to read before advising me, how to distinguish evidence from interpretation, and where different kinds of output belonged. All of this context came from an interview Codex conducted, which it then packaged into a file it could read. My job was to review and approve its output.

I made three decisions. First, I gave the coach a dedicated home on my desktop where I could access it easily. Second, I required it to read all essential context in the folder before giving advice. Third, I told it to preserve useful output somewhere the next session could find it. Codex handled the paperwork. It proposed the detailed folders and what should go in the AGENTS.md file, and routed each artifact to its correct home. This is how I divided the work between myself and Codex. I chose the sources of information and boundaries, and the agent gathered, compared, and proposed a plan.

I felt the difference the next time I opened the project. Because the coach already knew what I’d corrected last week, what evidence I’d added yesterday, and which plan I’d approved that morning, we could pick up where we left off.

Codex’s verdict on my progress

Codex opened the document where I had recorded my four objectives and 16 measurable results with my manager, Every’s editor in chief, Kate Lee. It inspected my project folders, searched Slack for signs that people used what I built, checked my published work and performance data, and compared the record with the plan.

I expected it to confirm that I had wandered off course, because my default assumption is that something is going wrong at all times. It showed me that I was further along than I thought in completing my goals.

My Working Overtime publication target was complete. A newsletter experiment had been absorbed into Andy, our shared editorial agent, and my colleague Laura Entis was using and improving it. The Vibe Check pipeline had produced substantial test runs and drafts.

Then, because I am me, I asked Codex to “make a nice lil visualization.” It built an interactive OKR health dashboard with a card for each objective, the evidence behind its assessment and what it’s still missing, and the next move most likely to improve the quarter.

The OKR Health dashboard showing objective progress, confirmed receipts, proof gaps, and next actions.

The dashboard corrected my self-assessment but refused to let me enjoy it for long: “Your danger is trying to prove impact through volume,” my career coach told me, adding that I needed to share my work with others if I wanted my work to have impact across the organization.

The biggest validation of Codex’s feedback was my work on Vibe Check automation. Every’s head of tech consulting, Mike Taylor, built a plugin for preparing Vibe Checks end-to-end. I tweaked it here and there based on my whims until it made perfect sense to me. Then I didn’t share it with my colleagues because I was afraid my changes made it worse. I was scared of the judgment of others, but the only way to make the system better was to hear what they thought.

This is where my suped-up career coach hits its limitation: It can tell me I need to take action. It can’t take the action for me. I eventually handed the plugin off to Andy, the editorial team’s AI assistant. I still can’t bring myself to share it with another human because it’s not quite perfect.

My impact beyond OKRs

For the first time in my life, I am looking forward to OKRs again.

My coach records what I did, where the work produced the strongest results, and where I avoided measuring adoption. I can’t beat myself up about my work because I have an objective evaluator to hold me accountable.

But the coach gave me one more thing that helped me understand the impact of my work and feel more positive about my contribution to the company.

I shared an internal document with the agent about Every’s positioning and asked it where I fit. The agent showed me where my work directly supports the company’s strategy.

Working Overtime gives readers language for the emotional experience of adopting AI. My guides help them act. Vibe Checks show editorial judgment during major model releases. My increasingly builder-ish projects make my own transition from writer to builder visible. I’m an on-ramp for the AI-curious, it told me. Someone who makes a reader think: “Well, if she can do it, maybe I can do it too.”

The start of the role positioning document Codex prepared for me based on Every’s brand positioning and its visibility into my work.

The positioning analysis changed how I approach my job. I speak up more in meetings. I feel more confident saying, “I want to write about this because I think it will be interesting to these people.” I’m more willing to claim the builder side of my work. Each system no longer feels like a strange hobby that escaped onto my desktop.

I started by asking Codex how far behind I was in my second-quarter goals. The record gave me relief, an assignment to be louder about what I was making, and a more expansive idea of the job.

Now I want to ask a better question: Given the work I’ve already proved I can do, what should I be ambitious enough to propose next?

Build the smallest useful version

You do not need my folder labyrinth, four prior experiments, or a dashboard with the visual energy of an airport control tower to build your own Codex career coach. Start with one question:

Where do I stand against the goals I own this quarter, and what should I do next?

Create one project folder for that question. Add a short instructions file that tells the agent what to read before advising you, which sources are authoritative, how to label uncertainty, and where to save useful output.

Then give an approved agent five kinds of context:

Start with your goals, one representative work folder, a recent manager update, and one file of outcome data. Export or paste information if direct integrations are unavailable. Follow your company’s privacy, security, and access rules.

Give the coach four evidence rules:

Cite the source behind every important conclusion.
Separate confirmed evidence, interpretation, and open questions.
Treat intent, setup, and discussion as weaker than an observed run, handoff, decision, or outcome.
Check the record before asking for your self-assessment.

Then use a prompt like this:

          Prompt
          Other
        

Act as my evidence-based career coach. Compare my current goals and responsibilities with the work, conversations, feedback, and outcome data in the sources I provided.
For each goal, show:
confirmed progress, with source links or citations
valuable work that is currently uncounted
missing evidence, especially around adoption or impact
places where the goal no longer fits the work
the single next action most likely to improve the outcome
Then identify the larger pattern emerging in my role. Separate confirmed evidence from your interpretation and from questions only I can answer. Create a reusable dashboard, evidence table, weekly brief, or manager agenda. When the record can answer a question, do not rely on my self-assessment.

Save the output where the next session can find it. Add the result of each action. Correct source errors in the durable record. Rerun the review before a manager meeting, every Friday, or at the end of a planning cycle.

Whatever cadence you choose, close the loop:

commitment -> work -> feedback or outcome -> cited assessment -> next action -> new evidence

Start with a table: goal, confirmed receipts, proof gaps, and next move. Mine grew into a dashboard, adoption ledger, manager brief, and positioning file as I found new uses for the same record.

The system should leave the judgment with you.

Katie Parrott is a staff writer at Every. You can read more of her work in her newsletter. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Help us scale the only subscription you need to stay at the edge of AI. Explore open roles at Every.

Built on Moving Ground

Every Staff / Context Window — 2026-06-21 08:00:00 -0400

by Every Staff

in Context Window

Midjourney/Every illustration.

On June 12, Anthropic disabled Fable 5—the most capable coding model Every had worked with—after a U.S. government ban forced the company to shut it off for everyone. There was no warning or migration window. The models we rely on, it turns out, aren’t ours to keep: A company—or a government—can switch one off overnight.

That instability is the backdrop to our week. Senior applied AI engineer Nityesh Agarwal spent weeks building around Claude’s limitations, only to watch Anthropic’s new dynamic workflows solve the problem overnight—the cost, he says, of working at the frontier. Laura Entis and Katie Parrott report on loops (where you give an agent a goal and it works in rounds, reviewing each result and re-prompting itself until the work is good enough) moving fast from engineering into non-technical work. Head of growth Austin Tedesco built an overnight NBA simulator and reworked Every’s subscription flow the same way; Katie’s half of the piece is a playbook for what to do when a frontier model disappears. Mike Taylor tried something stranger, building an AI persona of GitHub COO Kyle Daigle so the real conversation could focus on what no public record could tell him—which you can hear on this week’s AI & I. And Stella Garber, co-founder and CEO of Hoop, rebuilt an internal tool to be agent-native—then started shipping it to customers. Thursday’s edition rounds out the week with the AI topics the team has given itself permission to skip, a workflow for treating your Slack bot like a coworker, and Mistral’s surprise seat at the G-7 AI table.—Kate Lee

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Knowledge base

“I Interviewed an AI Version of GitHub’s COO—Then Spoke to the Real One” by Mike Taylor/Also True for Humans: Before interviewing GitHub COO Kyle Daigle at Microsoft Build, Mike Taylor ran his questions past an AI version of Daigle built from the COO’s public record. The simulation’s misses marked where public information ran dry. He spent the real conversation on what the model couldn’t know: the three machines Daigle codes across on weekends, GitHub’s automatic model router, and an agent loop Daigle uses to grade how he communicates. Read this for the pre-interview simulation technique.

🎧 🖥 “How GitHub Deals With 17 Million Pull Requests a Month” by Mike Taylor/AI & I: With agents flooding GitHub—commits jumped from 1 billion last year to a projected 14 billion this year—guest host Mike Taylor asks COO Kyle Daigle how the platform helps developers handle the surge without telling communities which pull requests to trust. Watch or listen to this for how the home of the world’s code adapts when everyone ships with agents. 🎧 🖥 Listen on Spotify or Apple Podcasts, watch on YouTube, or follow the discussion on X.

“How Anthropic Makes Claude More Reliable” by Laura Entis/Context Window: Anthropic’s new dynamic workflows let Claude Code write its own plan and run multiple subagents through a long task. Senior applied AI engineer Nityesh Agarwal felt it directly: Weeks of custom workarounds he’d built for Claudie, Every’s AI project manager, were suddenly obsolete. Read this for the Mini-Vibe Check and to see where dynamic workflows pay off.

“Loops for Non-Coders” by Laura Entis and Katie Parrott/Context Window: The loop—an agent that hits a stopping point, writes itself a new prompt, and keeps going—has crossed over from engineering into everyday non-technical work. Head of growth Austin Tedesco used the same setup that built an overnight NBA simulator to rework Every’s subscription flow and pricing page. Plus: Katie Parrott’s playbook for coping when a model you rely on vanishes, as Fable did—save your sessions, build while you have the window, and find which work needed the frontier model at all.

“We Built Our Own Agent-native Tool. It Overhauled How We Build Software.” by Stella Garber/Every: Stella Garber and two cofounders of Hoop, none of them engineers, built an internal AI tool to wrangle their scattered customer-call notes in an agent-native way. They handed the model a few tools and let it reason inside Slack rather than scripting a fixed sequence of prompts—an architecture that they now ship to their own customers. Read this for the agent-native build walkthrough.

Log on

Get hands-on with how Every uses AI. These are the live camps, workshops, and meetups where team members teach the workflows behind our work.

Upcoming camp

Codex Power User Camp: On June 26, Dan Shipper and the Every team host a two-hour live walkthrough of the Codex power-user guide, including setup, workflows, and Codex-native app development. Learn more and register.

From Every Studio

Cora becomes a full email app

A rebuilt Cora launches in alpha next week: The new version is a standalone email client—plus iPhone app—that replaces your inbox instead of just layering on top of Gmail. Want to try it in an early but working state? Email Kieran Klaassen at kieran@every.to to join the alpha.

Monologue now works with Apple Shortcuts

Monologue’s new Shortcuts integration lets you capture ideas without ever opening the app. Assign Monologue to your iPhone’s Action Button and one press starts dictation—or trigger it from Siri, a widget, or the Home Screen. You can also chain it into automations that route your voice wherever it needs to go, like dropping a note into Notion or kicking off a draft email.

Alignment

The hand across the page. Juneteenth—the day Americans mark the end of slavery—was a few days ago. I’m halfway through James Baldwin’s semi-autobiographical novel Go Tell It on the Mountain, reading several pages each night as an excuse to keep my phone out of my hands before bed.

It’s the best thing I’ve read all year. Baldwin drops us into the shoes of his young Black protagonist, John, as he’s about to turn 14 and his family’s Pentecostal church prepares to hold an all-night prayer service. The story takes place in late winter, in 1930s Harlem, and reads like a time capsule of the era’s bubbling social tensions.

Baldwin’s prose is constantly surprising; his turns of phrase ring so true that they disarm you, open you to feeling what his character feels: “John’s heart was hardened against the Lord,” he writes. “His father was God’s minister, the ambassador of the King of Heaven, and John could not bow before the throne of grace without first kneeling to his father.” You come to that sentence braced for a question of faith and leave it understanding a boy who cannot reach God because he cannot get past his own father.

The element of surprise is the first thing stripped out when AI is handed the most personal things we have to express. A few weeks ago, I listened to an AI-written wedding speech, and the disappointment I felt in the moment has stuck with me. The groom had handed off the one chance to say, in his own surprising and unrepeatable way, what his partner meant to him. What came out instead were words that could’ve been written for anyone.

I don’t expect everyone to be (or even approximate) a Baldwin or Hemingway, or to deliver JFK-like speeches. But you don’t have to write well. You only have to tell in your own specific way what happened, because what is surprising, almost always, is simply what is true.—Ashwin Sharma

We’re hiring a managing editor

Every is looking for a managing editor to run the daily publishing engine behind our editorial work: owning the calendar and the 11 a.m. ET send, editing and packaging pieces, coordinating freelancers, and sharpening the AI-assisted workflows behind the newsroom. If you have sharp editorial taste, experience running a high-frequency publishing operation, and a genuine interest in editing with AI—and you’re in New York or a nearby time zone—apply here. Not the right fit? Explore Every’s other open roles.

That’s all for this week! Be sure to follow Every on X at @every and on LinkedIn.

We build AI tools for readers like you. Write brilliantly with Spiral. Organize files automatically with Sparkle. Deliver yourself from email with Cora. Dictate effortlessly with Monologue. Work on documents with AI agents using Proof.

For sponsorship opportunities, reach out to sponsorships@every.to.

Upgrade to paid

How Anthropic Makes Claude More Reliable

Laura Entis / Context Window — 2026-06-18 12:00:00 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

Living at the edge of AI is bittersweet. You can spend weeks building a workaround to a problem only for a frontier lab to swoop in and solve it for you in a more elegant, reliable way. Today, senior applied AI engineer Nityesh Agarwal explains how Anthropic’s dynamic workflows feature made his elaborate Claude setup look clumsy in retrospect, the Every team shares which corners of the AI frontier they’ve given themselves permission to ignore, and executive operations manager Jalaiyah Bolden walks through her step-by-step process for turning a Slack bot into a reliable coworker.

Every is off tomorrow for Juneteenth; we’ll be back Sunday. Was this newsletter forwarded to you? Sign up to get it in your inbox.

Mini-Vibe Check: Dynamic Workflows

A closer look at how Claude Code coordinates multiple agents

When senior applied AI engineer Nityesh Agarwal built Every’s AI project manager Claudie, he spent days figuring out how to get around the model’s limited context window, or the cap on how much text an LLM can process at once—and the reason Claudie kept dropping key details. His solution: one coordinating agent that delegated tasks to fleets of subagents, which gathered data, made updates, and communicated with one another via local markdown files. The process was “a little bit hacky,” Nityesh says, but it worked.

If he were to build Claudie today, he could just use dynamic workflows, Anthropic’s feature for orchestrating large, multi-agent Claude Code tasks. Instead of deciding each step on the fly, Claude writes a reusable script that coordinates the work. It can assign tasks to many subagents and have them check each other’s work before reporting back the results.

Before dynamic workflows, trying to get Claude to reliably spawn reviewer agents was a persistent headache. Anxious about token spend, the model “would sometimes try to merge it all into one subagent,” Nityesh says, dragging down the quality of the results. Increasingly dramatic directives not to do this often went unheeded. Now, if you tell Claude you want three verifier subagents with dynamic workflows, Claude will write a script that generates three subagents every time.

Nityesh is grateful for the new feature, but watching weeks of work get negated by a single release was also disheartening. “I spent so many weeks building that other thing. Now it’s useless,” he says.

“But that’s the cost of being at the frontier,” he continues. “You need to be ahead of everybody else, and sometimes that means you need to throw away your past work.”

(Image courtesy of Anthropic.)

A dynamic workflows case study. For Spiral’s redesign, senior designer Daniel Rodrigues sent the writing app’s general manager Marcus Moretti a giant Figma file.

Marcus needed to convert the file into code. He did a pass in Claude Code, but the result had numerous errors. Before dynamic workflows, he would have flagged the mistakes in batches for Claude Code to fix—a repetitive, frustrating process.

Instead, Marcus asked Claude Code to set up a dynamic workflow that would review the Figma file section by section, extract all assets and design details, turn them into code, and check the results against the original file.

The Figma file had 11 sections, so Claude spun up 11 tasks, each with dedicated subagents. After running for a couple of hours, “it was not perfect,” Marcus says, but “it saved me a whole bunch of time.” Before dynamic workflows, each of the reviewer subagents would have been Marcus himself.

Try it yourself: For complex projects like a code migration, changing the programming language a product uses, or a major upgrade, dynamic workflows might be a good solution, Marcus says. To initiate the feature, you can simply type “workflow” in a Claude Code session, or include “ultracode” in the prompt.

Or test out Nityesh’s prompt for kicking off a dynamic workflow.

Permission to skip

Rapid-fire roundup edition

The pace of AI is unrelenting. Each week brings new model releases, benchmark results, and “paradigm shifts” that sometimes turn out to be incremental upgrades.

At Every, we do our very best to stay at the frontier—but for better and worse, we are human, which means we cannot run all night. Here, Every staffers share what they’ve given themselves permission to skip in order to, you know, sleep, touch grass, or run other AI experiments. [Disclaimer: All of this is, of course, subject to change!]

Mike Taylor, head of tech consulting: “All model releases that didn’t come from Anthropic or OpenAI.” Exhausted from putting Fable 5 through its paces, Mike recently declined the chance to beta-test a model from another big tech company. “Maybe I’m stupid for saying this, but I don’t expect it to be as good as what we’re currently testing,” he says. “I might just not be able to make the time. Whereas if it’s something I think is really, really good, then I’ll miss my kid’s birthday party to test it.”

Kieran Klaassen, general manager of Cora: “Open-source models. There are so many, and they’re not as good as the best models, so I skip all of them.”

Willie Williams, head of platform: New, complex development workflows—compound engineering has cured his FOMO when he encounters them on X. “I just use the /lfg workflow from compound engineering,” he says. “Now I’m like, ‘It’s all I need.’”

Daniel Rodrigues, senior designer: Agent-ready design systems, in which you translate brand assets and design decisions into code an agent can use. He sees the value in this way of working, particularly on the client side, but building these complex systems is not how he’d choose to spend his time if given the choice. Why? “It doesn’t look fun, and design should be fun,” he says. Amen.

Steal this workflow

Treat your Slack bot like a coworker

Jalaiyah Bolden is Every’s executive operations manager: She manages CEO Dan Shipper’s calendar, internal events, operations projects, and customer support. Her small but mighty teams use a number of Slack-based agents—most notably Viktor— to automate or assist with the myriad tasks regularly thrown at them.

Here’s Jalaiyah’s step-by-step process for getting an agent to take over routine tasks such as auditing ticket closures, creating discount codes, or compiling payment dispute evidence.

Pick one recurring job. Start with something low-stakes but annoying. Anything that comes across your desk more than once could qualify: Maybe it’s a templated but extensive weekly report, or a customer support audit, or a workflow to create coupon codes. Whatever it is, make sure the agent has access to the systems it needs to find or verify information, and then describe the output you want. For example: “Audit Fin [formerly Intercom, a customer support platform] closures from the last 12 hours and flag anything suspicious.”
Start a conversation. Treat the bot like a new hire. Jalaiyah’s go-to prompt: “What other information do you need to be able to make this repeatable and consistent over time?” Let the agent ask clarifying questions, then give it rules, examples, edge cases, and a clear definition of what “good” and “bad” look like.
Review and revise what it comes back with. Let the agent gather information and draft a response. Then review the result yourself, explain what needs to be handled differently, and fill in any information gaps. The result should improve the next time around.

Try it this week: Choose one recurring task and ask your agent: “What other information do you need from me to run this reliably every week?”

One last thing

Mistral who?

When it was announced the heads of the top AI companies would convene in person at the G-7 Summit to discuss the “opportunities and dangers” poised by the technology, the lineup was who’d you’d expect: OpenAI CEO Sam Altman, Anthropic CEO Dario Amodei, Google DeepMind CEO Demis Hassabis, Meta chief AI officer Alexandr Wang, and Arthur Mensch, the CEO of Mistral.

If you’re wondering how Mistral made the cut, you’re not alone. A French maker of open-source models, Mistral is “among the most vaunted artificial intelligence firms in Europe,” per the New York Times. But on X, the company is perhaps more famous for “Le Chaton Fat,” a spoof all-powerful model that went viral online after Mistral announced it was renaming its chatbot from Le Chat to Vibe, leading commentators to post about other potential cat-themed successors to Le Chat.

(Screenshot courtesy of X/Laura Entis.)

We still don’t know exactly what was discussed in the AI huddle, but Mistral’s inclusion led to, you guessed it, more memes.

Laura Entis is a staff writer at Every. You can follow her on LinkedIn.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

We build AI tools for readers like you. Write brilliantly with Spiral. Organize files automatically with Sparkle. Deliver yourself from email with Cora. Dictate effortlessly with Monologue. Collaborate with agents on documents with Proof.

For sponsorship opportunities, reach out to sponsorships@every.to.

Loops for Non-coders

Laura Entis and Katie Parrott / Context Window — 2026-06-17 01:00:00 -0400

by Laura Entis and Katie Parrott

in Context Window

Midjourney/Every illustration.

AI can be exhilarating and destabilizing. Just when you think you have your setup figured out, a powerful new model drops—or, in the case of Anthropic’s Fable 5, gets abruptly disabled. Today, we explore this instability from multiple angles: Staff writer Katie Parrott maps the grief (and coping mechanisms) that accompanied the Fable ban and shares a practical playbook for the next time a model you depend on disappears, head of growth Austin Tedesco explains how loops are causing him to rethink his approach to working with AI, and GitHub chief operating officer Kyle Daigle tells AI & I guest host Mike Taylor how the company is responding to an agent-generated surge in commits.

‘AI & I’: Can GitHub be for everyone?

Today we’re releasing a new episode of our podcast AI & I. Head of tech consulting Mike Taylor guest hosted this week and spoke to GitHub COO Kyle Daigle about how the company is responding now that everyone—and their army of agents—can ship code.

The volume is extreme: Last year, there were 1 billion commits on GitHub. This year, that figure will safely exceed 14 billion, Daigle says, which puts GitHub in an important but delicate position: It must help developers handle agent-generated code without dictating which pull requests communities should trust or merge.

Watch on X or YouTube, listen on Spotify or Apple Podcasts, or read the transcript. And for a behind-the-scenes look at the making of the podcast, check out Mike’s piece on his decision to ditch standard-issue prep in favor of building and mock interviewing an AI version of Daigle.

Here are the highlights:

The developer versus non-developer distinction is disappearing: GitHub has long taken an expansive view of who counts as a developer, but AI has blown up the definition entirely. Legal, finance, sales, and marketing professionals are using the GitHub Copilot app to build prototypes and apps. “A lot of the folks that the industry would call knowledge workers, or just non-developers by trade, are using these tools,” Daigle says.
Agents can write and review code, but humans decide what ships: GitHub has built agentic code review and merge tools to help developers handle the surge of pull requests, but people who run open-source projects should ultimately decide which outside submissions they merge. “We want to provide tools,” Daigle says, “but really leave them in control.”
Daigle runs a daily loop on himself: In AI, a loop is a cycle in which an agent does work, evaluates the result against a goal or standard, incorporates feedback, and repeats the process until the task is complete or the output improves. Daigle uses the same workflow to improve his communication style—each day, an agent reviews a rolling seven-day window of his emails and Slack messages, identifies patterns, provides constructive feedback, and checks whether he incorporated its advice.

Miss an episode? Catch up on Dan’s recent conversations with LinkedIn cofounder Reid Hoffman; the team that built Claude Code, Cat Wu and Boris Cherny; Vercel cofounder Guillermo Rauch; podcaster Dwarkesh Patel; and others, and learn how they use AI to think, create, and relate.

Inside Every

Loops, loops, loops

“I’m super loop-pilled,” says head of growth Austin Tedesco. He’s not alone. Loops—which have AI tackle a goal through iterative cycles of completing a section of the task, reviewing the results, incorporating the learnings, and generating the next step—have become a hot topic of discussion here at Every in recent days.

While some have been using them for a while—looking at you Kieran Klaassen, the father of loop-based engineering philosophy, compound engineering—newer, more powerful models have made this approach possible for non-code-based workflows, too.

For Austin, Fable—RIP, at least temporarily—was what made the power of loops click into place. The “aha” moment came when he gave the model a simple prompt:

Build me an NBA simulation game that’s like Football Manager: basically NBA 2K Dynasty mode without gameplay. I want to pretend I’m an NBA general manager and make real transactions. Build it through the /LFG flow—the compound engineering workflow that brainstorms, plans, builds, reviews, and improves—then keep looping overnight.

When he woke up, he had a working NBA front-office simulator. What floored him was how the model worked through the task: Fable would hit a stopping point, review what was missing, write itself a new one-paragraph prompt, and keep going. At one point, it realized the game needed NBA-specific salary-cap logic, including rules around teams renouncing free agents before July 1. It also simulated a full season and logged what happened, so it could inspect the game’s behavior.

Austin’s one-shotted NBA front-office simulator. (Image courtesy of Austin Tedesco.)

Every’s growth team has used the same setup to improve our subscription flow and create a net-new pricing page. We supplied the goal, the context, and the desired output, and the agent looped through the rest.

Even though Fable is temporarily inaccessible, Austin is trying to recreate pieces of the same cycle in Codex with /goal, a feature that gives Codex a persistent objective to work toward across a longer-running session.

Get CEO Dan Shipper’s Fable prompt for loops or steal Austin’s workflow:

Define the problem and output. For example, “Our subscription flow and pricing page aren’t converting the way they should. Find the weak spots and produce new experiments we could ship or mock in Figma.”
Give the agent a way to review its work. Provide the materials it would need to judge whether an idea is good: who it’s building for, what those users are trying to do, what their current experience looks like, where the data says people get stuck, what competitors do differently, and what constraints it needs to work within. Then ask it to test each idea against that context before writing its next prompt.
Set the loop in motion. Tell the agent: “When you hit a stopping point, write yourself a one-paragraph prompt for the next improvement and keep going until the outcome is materially better.” Let it generate pricing-page variants, Figma experiments, or site changes. Then review the outputs and decide what’s good enough to act on.

Pulse Check

Your favorite model will die

When Fable—the best coding model Every had tested—shut down on June 12, the tech community lived through a compressed version of the five stages of grief. It was a preview of what you should expect every time a model goes away. Here’s what helped, and what to do the next time the weights vanish.

Save the session before you need it

When a model you lean on is about to change, don’t rush to replace it—first, stop throwing away the evidence. The model’s plans, edits, tests, slip-ups, and fixes live on in chat histories in web apps and log files on your computer, and you can reuse that record.

One Fable user, posting as CuddlySalmon, kept a session open from before the shutdown and reported that it still seemed to carry Fable’s context after Claude fell back to Opus 4.8—though they admitted that might be wishful thinking. Another used Codex helper agents to dig design choices out of old Fable runs.

Do this now: Export a few sessions from whatever model you depend on, and save the full trail of what it did, not a tidy summary. The weird little choices are what you’ll want later.

Build while you have the opportunity

As the shutdown news hit Every’s company Slack, Dan gave the team one order: “quick BUILD EVERYTHING.” In the three days we had, Every took maximum advantage of the opportunity. We used Fable to build a Lord of the Rings version of graphics editor Kid Pix, an open-source deck-building tool, and an interactive shader tool, each in an afternoon.

Do this now: When a new frontier model comes out, give your team the time and space to experiment in the first few days. You may not get another three-day sprint like that.

Determine which work needed the frontier model

The morning after the shutdown, Dan asked the team what they’d do if Fable stayed gone. Kieran said that he would use Opus, like before. Naveen Naidu, who runs our voice app Monologue, said that he would go back to Codex. Willie Williams, Every’s head of platform, would keep Codex as his daily tool and move the Plus One factory back to Opus.

Most of your work never needed the top model in the first place. Some does. While building hands-on-deck, an open-source slide tool, with Fable, Nityesh Agarwal—Every’s senior AI engineer—noticed that the more ambitious his ask, the more ambitious the model’s output—each one pushed the other higher. On Opus that pull was gone. He could still do the work; he’d just lost the nudge to attempt the bigger version.

Do this now: Take one real Fable-size task and run it on your backup model. If it passes, that work never needed the top model, so stop paying extra for it. If it fails, you’ve found work worth protecting, and you know where to put your effort.

Build for the model to disappear

Treat the outage as a fire drill for moving work between models, which means that the work needs to be portable and you need to be able to check for mistakes.

On portability, Christopher Allen, who runs the nonprofit Blockchain Commons, built a Claude workstream kit that captures the goal, the to-do list, the choices made, the lessons learned, the current task, the next step, and the blockers—all in plain text files tracked by Git. Because everything lives in the files rather than the chat history, a new model can pick the work right up—nothing key gets stranded in a conversation that no longer exists. On verification: A portable handoff isn’t enough if you can’t tell whether the work is correct. You also need a built-in check—a test of a “done” rule the model can demonstrably pass—that proves it’s so.

Do this week:

Run one live task through a backup. Pick something you do often, with an output you can judge.
Write down what the new model couldn’t recover. Move those choices, examples, preferences, and “done” rules into project files.
Add a test that proves the job is done. The fastest backup is the model that can show its work, even if its style leaves you cold.

Fable may come back. Either way, the next model you build on shouldn’t be able to take your work down with it.—Katie Parrott

Discuss

“I feel like I got on the last plane out of Vietnam. I don’t think I can plan for a normal-length career, at least in this field.”—Christopher Pack, software developer, in the Wall Street Journal

For decades, a tech degree was the surest ticket to a stable, high-paying job. (Hence all the “learn to code” jabs directed at liberal arts majors.) Now, MVP applicants, and entry-level and mid-career software engineers are competing for a shrinking number of available roles as AI consumes more of their jobs. Per the Journal, even experienced programmers are bracing for layoffs by hoarding cash, making risky stock market bets, or considering a career change.

Laura Entis is a staff writer at Every. You can follow her on LinkedIn. Katie Parrott is a staff writer at Every. You can read more of her work in her newsletter.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Help us scale the only subscription you need to stay at the edge of AI. Explore open roles at Every.

We Built Our Own Agent-native Tool. It Overhauled How We Build Software.

Stella Garber — 2026-06-16 03:00:00 -0400

by Stella Garber

Midjourney/Every illustration.

Stella Garber cofounded Hoop, an AI agent to help subcriber brands cut churn, after years at Trello watching what makes software stick. When her team’s customer discovery calls became a mess of scattered notes and competing interpretations, they built an internal AI analysis tool from scratch using Every’s agent-native architecture philosophy. It reshaped how they build their actual product. Plus: While you’re waiting for Fable 5 to return, we’ve compiled 13 copy-ready prompts based on the Every team’s workflows. Use them to plan, build, research, verify, and hand off complex work that runs for hours.—Kate Lee

Get the Fable prompts

It was Monday morning, and my cofounder Brian was reading from our agent’s weekly analysis of customer discovery calls. “Subscription retention,” he said. “Five separate brands mentioned it as their top priority, and none of them trust existing AI tools to touch it.”

Just weeks ago, unearthing an insight like this would’ve been nearly impossible.

At my pre-product-market fit startup, we’d all been speaking with prospects and trying to figure out the positioning for our product, but keeping track of everything we learned was a mess across founders, platforms, and mediums. To share what we learned during our Monday meeting, Brian would read notes in Slack, collect transcripts from Granola, and try to make sense of it all in Claude Code.

We couldn’t afford to be that disorganized. We’d recently launched Hoop, an agent that helps subscription brands reduce churn, and we needed to learn as quickly as we could. So we had to talk to as many potential customers as possible, then rigorously document and score each call to separate polite interest from genuine demand. Everyone on our five-person team was putting in the effort, but each of us had our own process, our own tools, and our own interpretation of what happened on each customer call.

So my two cofounders and I—none of us with “engineer” in our title—built an internal tool to fix it. What we didn’t expect was that the tool would change how we built our actual product for customers, too.

‘I should build something for this’

Our Monday meetings were so unmethodical because the information from our client calls was in different places depending on who had taken the call and whether they had notes based on Granola or another transcription tool. We had no way to see patterns and draw conclusions about what our potential customers wanted.

Justin, my cofounder and the resident product expert, built the first version of a tool to bring those notes together in under 10 hours over a few days, fitting it in around his other priorities.

Here’s how it worked: You’d upload a Zoom transcript, the tool would run the transcript through four or five prompts, and you’d get a structured analysis scored against the PULL criteria—a framework developed at Harvard Business School to help early-stage startups find product-market fit. The tool would also pull together all the conversations with a given prospect into a summary, so you could see the full arc of a relationship instead of just a snapshot from one call. Rather than digging through notes and transcripts, the tool gave us a consolidated analysis week over week to help us see what was working and what wasn’t.

Justin set up the app using tools we hadn’t used before: Next.js framework with ShadCN components for the user interface, Supabase for the database that compiled all the notes, Claude’s API for the analysis.

For Justin, who had studied computer science but wasn’t writing much code anymore, it was an opportunity to dust off his skills and build his confidence with AI-native coding. He started by designing and building the visual interface because he is the kind of person who gets frustrated when software doesn’t look right, even if it functions. He made sure that the look and feel of the tool matched our brand, and got the components (buttons, labels, menus) looking clean before he went anywhere near the data.

Only then did he go straight to the data. He had to make sure that the tool’s analysis of the customer conversations was better than what people were already producing on their own with Claude. Otherwise, we would never convince the whole team to use the same tool. So he created a prompt that he tweaked after manually reviewing the output several times and relying on Anthropic’s prompting best practices for Claude.

Still too much friction

The first version of the tool generated high-quality analysis, but too many parts of the process were still manual. You had to download the call transcript from Zoom, upload it manually to the tool, fill in the customer name and call type, and wait several minutes while it was processed. Then you’d create a link and share the analysis in Slack.

The team could search the transcripts and analysis in the tool, but it didn’t return good results. For example, I searched for prospects who’d had bad experiences with AI customer support tools and got no results back, even though I knew a head of customer experience had spent five minutes talking about how embarrassed they were by their AI sending off-brand responses to customers. The tool could only match the exact words in my query, not the meaning behind them.

And there was the classic adoption problem that we know all too well from our years at productivity tool Trello, where we’d previously worked. Justin’s tool was yet another place people had to remember to go, competing with Slack and Notion for our attention.

Going agent-native

Then we found the answer to our woes. Justin had been reading about agent-native architecture on Every. Instead of hard-coding a sequence of prompts that run in a fixed order, you give a model a set of tools and let it reason about how to use them. And instead of building a destination app that requires people to come to you, you bring the tool to where people already work, like Slack.

Justin gave Claude Code the link to the article and said that he wanted to build a system that aligned with those architecture principles. The agent needed two tools: one to upload and read a transcript, and one to add and edit a partner profile. With those in place, all users had to do was send a transcript to the app in Slack. The agent confirmed the partner name and call details, then uploaded the transcript, ran the analysis, created a summary page, and posted it to our user feedback channel.

Justin started checking everything he built against the agent-native architecture guidelines, not just the product-market fit tool. He’d go into planning mode with Claude Code, lay out a new feature, and send it alongside the Every article back to Claude Code and ask: “Where is this aligned, and where is it not?”

Sometimes he deviated from the guidelines when he didn’t think that users needed AI for a specific task. For example, the tool tracked LLM token usage and cost—useful information, but not something users needed to query. Exposing it to the agent would have only created confusion.

My turn in the codebase

I had a different problem. I needed to see the pipeline at a glance—who to follow up with, where each conversation stood—organized by people and stages, not just chronological call logs.

I opened Ghostty, a simple terminal app, copied the tool’s code so I could work on it locally on my laptop, and—hands a little shaky at the thought of directly editing code—fired up Claude Code.

The first thing I asked Claude Code to build was a lightweight view of the data so I could see the different stages of the pipeline at a glance. Ironically, I was asking Claude Code to build a Trello-like board of the information so I could move cards representing calls around. Old habits die hard.

I built incrementally. I noticed it’d be useful to have the status of a deal on the front of each card. so I prompted Claude Code, “Make sure each card has a one-line summary so I know at a glance where things stand.” Once deployed, deals came in with their status attached. Every time I wanted something different, I just asked.

Encouraged by Justin, I started merging code directly to the shared repo. Sometimes things broke, and nobody got in trouble, because the stakes were low and everyone treated it that way.

Brian learns agent-native at 10 p.m.

Next up was Brian, our other cofounder, who was responsible for our weekly user learnings report. Before the new tool, he would often forget and end up scrolling through Notion, or riffing from memory on whatever conversations were freshest in his mind. Our learnings skewed toward recency rather than significance, and we missed patterns that only showed up when you looked at all the calls together.

So Brian built a feature to generate the report automatically. His first version was a link on his computer that spit out a Markdown file he would paste into Notion—it worked, but only for him. His second added a Learnings tab to the tool with a button that produced the same Markdown output, but now anyone could pull a report.

That solved the access problem, but a new one surfaced. The team couldn’t tweak the format or focus of the report without asking Brian to edit the code. Brian wanted to make the prompt for the report editable so the team could tune the reports without touching code. At 9:25 p.m., Justin suggested in Slack: “You should make the prompt an editable field and pass it to the agent.”

Brian didn’t understand what that meant, so he pasted Justin’s message into Claude and asked for an explanation. Claude walked him through the agent-native architecture philosophy, and Brian started to understand: Instead of giving a human a text box to edit the prompt, you give the agent a tool that lets it read and modify the prompt itself. Then anyone can talk to the tool in Slack and tell it what to change.

By 11:15 p.m., Brian had the feature working. He tested it by telling the Slack agent to rewrite the Learnings prompt in Klingon, and sure enough, every report came out in Klingon. It took two hours, from start to finish.

More practically, a recent report flagged that four out of our last six calls mentioned the same pain point: Brands were losing subscribers who hadn’t realized they’d signed up in the first place. Customers often subscribe to unlock a discount, forget it’s recurring, and cancel in surprise when the charge lands—exactly the moment our product could step in with a savings offer or a better-fit recommendation. None of us had connected those dots individually; the pattern only emerged when the tool looked across all the calls at once.

Then something unexpected happened. Duplicate records appeared in the Learnings tab, and Brian mentioned it to the bot in Slack. The bot looked at both records, figured out one was empty, and deleted it—a “find and delete duplicates” function. He had given the agent editing rights to the database, and the model reasoned through the problem on its own. That was the moment it clicked for Brian: If you give a reasoning model simple, powerful tools, it can handle situations you never thought to code for.

What we took back to the product

The most important thing the tool did was change how we build our external-facing product. Justin took the agent-native patterns he’d tested internally and built multiple sales tools, including a helpdesk audit we can run with prospective customers to show them the value of Hoop before they sign up.

Brian went from building a Learnings tab to building something like an internal sales agent, a bot we call “Benny” that lives in Slack, taps into our sales tools, and runs tasks on command: qualifying leads, scoring them against our ideal customer profile, and updating Attio (our CRM). I went from building features for a customer relationship manager to having informed opinions about product architecture.

It also kept us honest. When every call is scored and summarized automatically, you can’t hide from what the data is telling you. When five different operators in a single week told us our pricing didn’t make sense, we had to face the facts and change it to win more deals. At a big company, a team of analysts would be writing quarterly reports off this data. We’re five people doing it weekly with a tool we built ourselves.

The tool will probably look different in another month, and that’s fine. The fluency that we’ve gained matters more: knowing when to give a model a tool versus when to hard-code a workflow, being comfortable with shipping and failing—and trying again.

Stella Garber is cofounder and CEO of Hoop.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

I Interviewed an AI Version of GitHub’s COO—Then Spoke to the Real One

Mike Taylor / Also True for Humans — 2026-06-15 06:00:00 -0400

by Mike Taylor

in Also True for Humans

Midjourney/Every illustration.

I’ve attended many tech conferences as a participant and a speaker, but this year’s Microsoft Build, the company’s flagship developer event, was my first as a member of the press.

To quell the imposter syndrome, I tried an experiment before I sat down with GitHub chief operating officer Kyle Daigle, a true GitHub veteran who joined the company as a developer 13 years ago. I built a simulated version of Kyle—an AI persona distilled from his public writing, talks, and interviews—and asked the AI Kyle the same questions I planned to ask the real one.

I expected the output to be either eerily accurate or useless. It was neither—precisely what made it valuable.

Out of 12 questions, two responses were strong matches, four were partial matches, and six were material misses. To the simulation’s credit, when it lacked evidence, it said so instead of inventing something. Those holes were the most useful prep—they showed me what information wasn’t available on the public record, and therefore where I should spend my time in the live interview.

I’ve spent a lot of time talking to AI personas. My last startup, Ask Rally, was a virtual focus group tool. We found that AI is no substitute for the real thing, but in high-stakes scenarios, roleplay can help you get out of your own head, build confidence in your strategy, and avoid costly mistakes. We’re more predictable than we think, with some studies showing 85 percent accuracy in AI personas replicating real human responses.

What follows is the actual interview, with notes on what the simulation got right, what it missed, and where the comparison is interesting. We also went back to human Kyle—and his take surprised us more than the AI answers.

1. Expanding the definition of a developer

Mike: The demographics of the customer are changing. A lot of people who may never have used GitHub or developer products before are now using them. How has that changed the way you decide the product roadmap?

Kyle Daigle: GitHub has always had an expansive view of what a developer is. I started as a developer before I would have called myself a dev. I was writing code for myself, and I did not go to school for computer science. I was going to art school and wrote code to pay for art school.

That journey is important: I can create tools with a team and deliver them to people who want to build an app for themselves, their family, a startup, or a business. GitHub has serious developer tools used by the largest businesses, but when I look at something like the GitHub Copilot app, I see both developers running multiple projects and agent sessions and people on our legal or finance teams using it. Customers tell us the same thing. People the industry might call knowledge workers, or non-developers by trade, are using these tools to build little apps or assets.

Our focus is still very much on developers, but we want to make it easier for people to try writing code. There should always be an on-ramp into creating software, including through tools like the GitHub Copilot app.

Simulation note: A partial match. The AI Kyle correctly predicted the real Kyle’s thesis: AI is expanding who gets to build software—and even offered a framework to test this that the real Kyle plausibly could have mentioned: “The design test I keep coming back to is ‘no net new behavior.’ New capabilities should fit into the places where software work already happens.” But it couldn’t produce the art-school story or the legal-and-finance-teams example that made the real answer compelling.

2. Helping maintainers handle a flood of pull requests

Mike: How do you help developers deal with the burden of all the extra pull requests? Open source maintainers I talk to are drowning. What needs to happen to help them?

Kyle Daigle: For developers generally, we are building tools like Copilot code review. It is now agentic, so it finds more novel vulnerabilities, and you can comment and have the agent implement a change. Code review is an overlooked way to get pull requests into a state where they are much easier to review.

Agentic merge is another example. A pull request can be almost ready, but there are still manual steps to finish processing it. Instead, I can define what GitHub Copilot is allowed to do and tell it to merge the pull request, wait for CI, and wait for policies.

Open source has a unique set of needs because maintainers do not control who sends changes. We are focused on giving maintainers more control: whether they want to accept pull requests, who they want to accept them from, and how much work a contributor needs to do to demonstrate that a contribution will be meaningful. Every community is choosing a slightly different approach. GitHub wants to provide the building blocks and leave maintainers in control. If a standard practice emerges, we can cement a system around it, but we do not want to impose one first.

Simulation note: The AI got the governing principle right and the substance wrong. Its best line—“The system should give maintainers explicit rules and guardrails, not just a larger inbox”—is something the real Kyle could have said. But it named zero products. Copilot code review, agentic merge, contributor acceptance controls: all invisible to a persona built from public material, because they weren’t publicized until the event.

3. Growth in agent-generated activity

Mike: You have a front-row seat to this new agent economy. You said publicly that you have had more pull requests submitted in a month than in all of last year. How are those stats exploding?

Kyle Daigle: We are seeing much more activity on GitHub. Last October at GitHub Universe, we shared that there had been one billion commits on GitHub for the full year. We are on track for 14 billion if growth is linear this year, which it will not be. In March, 17 million pull requests were created by agents alone.

There is much more code being created. Sometimes people dismiss it as slop: code pushed up that nobody cares about. That is not really true. We are leaving the super-early-adoption stage. We are not at the peak, but we are climbing the hill and learning what we can build when it is not just Kyle building, but Kyle plus one, two, or N agents using my skills, resources, and context.

We are investing heavily in preparing for the next wave of growth because this does not seem to be growing and then plateauing. No matter where people build or what tools they use, the code ends up on GitHub for sharing and collaboration. We need to support everyone’s agent moment, not just GitHub Copilot.

Simulation note: Miss. The AI recited last year’s public numbers—it can only re-serve the stats you already have.

4. Business models for always-on agents

Mike: How does the business model change? Freemium makes sense in a human-centered world where we go to bed, but agents are still working while we are asleep. Does that move things toward usage-based pricing?

Kyle Daigle: I do not think we know yet. Right now, Kyle has a license or uses GitHub.com for free, and we have always had API rate limits. That is usually where people see agent backpressure.

If you want to do much more, with something like 150 agents doing things at once, we want to enable that. At the same time, I want you to have a great core GitHub experience, with some amount of agent usage as a necessary part of it. It is similar to how GitHub evolved from free public repositories but no free private repositories to giving individuals free private repositories because people reasonably had code they did not want to put out into the world.

GitHub evolves as the industry and community evolve. We focus on making sure developers have what they need to be successful, then work with enterprises to make sure they have what they need at scale. Those needs are usually somewhat different.

Simulation note: Both Kyles opened with the same thought: Nobody knows yet. But the real Kyle’s answer was so much more illustrative because of the hypothetical examples he used to explain his point.

5. A dual role across GitHub and Microsoft

Mike: Pricing leads back into the wider Microsoft orbit. You now have a dual role, with partial responsibility for the wider marketing organization. How has that changed your work, and how do you prioritize between the two roles?

Kyle Daigle: I have been at GitHub for 13 years, as a developer myself and leading engineering teams for much of that time. What has always been unique about GitHub is that we focus intensely on the developer. Enterprises buying the tools is great, but we are not building for the buyers; we are building for the users.

That has been my focus as GitHub COO, which I continue to do. As Microsoft’s chief marketing officer of developer, my goal is to look across Microsoft’s developer tools and technology and make sure we bring holistic solutions that feel authentic to developer experiences.

At events like Build, we have taken a different approach this year. We are in San Francisco, and the vibe is different from a traditional conference-hall setup. The focus is: Can I go to a session? Can I use the thing? I do not want to be pitched a thing; I have to be able to use it. The goal is to bring GitHub’s expertise, care, and focus on the developer to a broader impact across Microsoft.

Simulation note: A clean miss. The AI Kyle questioned my facts: “The available persona... does not document a dual role with partial responsibility for a wider marketing organization. I would verify that premise before treating it as established.” Proof that simulations based on public materials have an expiry date.

6. Community speakers at Build

Mike: Did I hear you say that this is the first Build conference to have external contributors and speakers?

Kyle Daigle: It is the first Build where, by intention, we have focused on speakers from the community in primary sessions. The keynote included people such as Peter, and there were sessions from Svelte and others.

Software development is a team sport. It would be silly to think that one company or one group, including GitHub or Microsoft, could answer every question. We all use open source and build on major open source projects. We should invite people in to tell their part of the story together. That is what developers want, and feedback shows that people are excited to see perspectives from Microsoft, GitHub, and outside the company at the same event.

Simulation note: The AI declined to answer: “I cannot confirm that from the available persona.” But that’s what you want from a simulation—for it to admit when it doesn’t know.

7. Differentiating in a competitive market

Mike: This is a very competitive market, and the pace of change is quick. How do you differentiate?

Kyle Daigle: We continue to focus on our roots: developer choice, building for builders, and enabling builders. We went from an era of many APIs and broad access into a somewhat unintentional walled-garden setup, where people develop an affinity for one tool and then realize that trying something interesting elsewhere means learning a new tool or opening a new account.

We want developers building with GitHub to use other tools, and we will partner with everyone to make that as simple as possible. Other companies do similar things, but our ability to support choice across the entirety of building software, not only code generation or collaboration and review, is a real strength.

We will invest in our own technology, including new Microsoft AI models, while continuing to partner with Anthropic, OpenAI, Google, and anyone bringing a model or coding agent to market. We will let developers bring those tools to GitHub or use them through GitHub and GitHub Copilot. Choice is core. If we back down on that, developers will still choose; they will just be stuck in another walled garden.

Simulation note: This answer was the strongest match of the 12 to human Kyle’s response. The AI Kyle said: “The differentiator is not having one more agent in a crowded market...That means choice across providers rather than lock-in to a single model.” The real Kyle even reached for the same image—walled gardens. This was the part of an interview I least needed the simulated interview for.

8. Dogfooding while staying open to other tools

Mike: There was a recent news cycle about Claude Code licenses being canceled. How do you make the trade-off between dogfooding your own products, such as your new models or the GitHub Copilot desktop app, and letting developers experiment with other tools?

Kyle Daigle: We all use a variety of tools because otherwise you lose track and become too focused on your own work. I have been a daily MacBook user for years, and I use Windows PCs when I play video games. When I got this role, I set up my Mac, a PC, and an AlmaLinux box. I code most Saturdays, and I swap between the boxes because I want to understand each experience. I use the GitHub Copilot app only on Windows because developers on Windows deserve great apps too; it is not only about the Mac audience.

That is true across our teams. We look at coding agents, harnesses, desktop apps, memory management, and everything else. Everyone is building and using these tools. We put most of our energy into our own tools, but it is a blind spot to focus so narrowly that you lose perspective. When something new comes out, I want to know why people are having a great experience with it. That helps me understand where to focus and why a developer would pick a particular tool. The same goes for our teams.

Simulation note: This was the second strongest match. The AI nailed the concept in a line the real Kyle would happily sign his name to: “Dogfooding should sharpen the product. It should not become a reason to ignore the tools developers find useful.” It could not have known, however, that the COO of GitHub spends Saturdays rotating between a Mac, a PC, and an AlmaLinux box.

9. Filtering short-lived ideas from longer-term bets

Mike: A lot of these ideas are relatively short-lived, while enterprise product-development cycles are longer-lived. How do you filter ideas and decide what to pursue?

Kyle Daigle: In the short term, we are focused on supporting a multitude of agent sessions because that seems clear: everyone is doing it, so how can we cement it? Over the longer term, models will continue to improve, token economics will become a bigger factor in what people use, and I believe we are not far from having serious ability to use something above a small language model on a local device for some work.

If there is that much optionality around tokens, the consistent truth since ChatGPT and GitHub Copilot emerged is personalization, context, fine-tuning with context, and memory. There have been experiments across the industry, but not a long-term vision. Supporting many agents is important because someone using agents will not sit and stare at one agent working. But that alone will not produce a great long-term experience. A great experience is using an agent that feels like it is completing a thought for you without forcing you to codify that thought yourself.

The agent should be able to intuit that, or use post-training, fine-tuning, or frontier tuning to deeply understand how I work. Sometimes we work on the short term, and sometimes we take repeated attempts at the long term until something tangible helps us move forward.

Simulation note: This is where the simulation’s favorite crutch broke down. The AI Kyle reached—again—for human Kyle’s best-documented framework: “I use a constraint-first hierarchy: MUST, SHOULD, and COULD.” It used that framework in five of my 12 questions, and the real Kyle never mentioned it once. When a persona runs out of evidence, it over-applies the pattern it knows best. That’s a subtler failure than hallucination, but a failure nonetheless. As models get better, they should get less fixated on individual pieces of context and relax rules like humans do.

10. Hill climbing as a product-development loop

Mike: I heard the term “hill climbing” 100 times yesterday. Can you talk about how that became such a big focus?

Kyle Daigle: Satya [Nadella], Mustafa [Suleyman], and Jacob [Andreou] leading the Copilot group talk about it often. The biggest thing we have learned is that using the tools has to be a core way to improve the underlying experience of the models. The evals are essential. Thumbs-up and thumbs-down data, whether people accept a suggestion, and how much they accept all contribute to creating a useful experience for everyone.

Every week we talk about hill-climbing results. We look at hard measures and soft measures because sometimes evals and rubrics show improvement while user sentiment crashes, even with the same latency and performance. You can overfit.

The goal is to run that loop quickly, then give everyone a hill-climbing machine without forcing them to do it the hard way. In an enterprise using M365, there is potentially rich data in assets, documents, and chats. Turning on something like frontier tuning and using an MAI Phi-3 model as a base can show real results without extra work. At first, that sounded like a magic trick that could not be real. But sometimes the opportunity is where something feels too simple to work.

That is why we say hill climbing so much. It is not a moonshot. It is climb, improve, add an eval, improve, add new data, and improve again. That is how we reached a point where we can launch models for ourselves and allow customers to use similar tooling.

Simulation note: The AI declined to bluff by saying, “The available persona does not document me using ‘hill climbing’ as a specific organizational term, so I would not manufacture an origin story for it,” then provided some abstract explanations of fast iteration. The real answer included new information that the model would never have had access to.

11. Keeping AI subscriptions affordable

Mike: Is hill climbing the answer to stopping a $200 subscription from becoming a $2,000 subscription?

Kyle Daigle: Frontier tuning models so they know you better is part of the answer. Another important part is helping developers automatically choose models.

Mike: Like the model router in GitHub Copilot?

Kyle Daigle: Exactly. GitHub has an automatic model router with task intent, and Microsoft Foundry has a model router at the API level. The more we can let people tell us where their bars are, such as “This is an incredibly hard problem and I am willing to go all the way to the top,” or, “I want to stay here,” the more we can help choose the model.

Tokens are often expensive because people choose the model of the day, week, or hour, and those models can be expensive. But a train of thought moves between hard problems and simple ones. I might ask an agent to do an enormous amount of work, then have a final step that is just changing names. I probably will not manually switch from an expensive model down to a smaller one just to save tokens for that step, but the tools could. That will help enterprises, individual developers, and people building automations with the Copilot SDK.

Simulation note: The AI got the gist of the problem correct, but it couldn’t solve it. It gave a framing for the problem, noting that a model doing more work doesn’t automatically mean a cheaper bill, while the real Kyle talked about a thing to solve the problem: the automatic model router

12. Unusual personal uses for agents

Mike: I made an AI version of you to practice this interview and found it immensely useful. What other unusual things are you seeing people do with agents internally or externally?

Kyle Daigle: I do something similar. I have one setup through the app and another Claude instance that cannot talk to work systems, so there is separation of state. I spend a lot of time having it read what I write. This interview will ultimately get fed into it. Every day I receive a communications report that says things like, “Kyle, you keep saying this,” or, “This is not super clear.” Because I write and speak in a particular way and like to use metaphors, it gives me examples of metaphors that are clear.

The self-improvement loop for a human is incredibly powerful. We used to talk about this with Hubot and ChatOps at GitHub: Humans are much more willing to take critical feedback from robots than from other humans. When my Claude instance tells me how poorly I did at something, I feel better asking it to explain why and using that feedback when I write emails, write a script, or review details.

A lot of my agent loop is about me rather than software. It looks backward: read Kyle’s emails and Slack messages from the last seven days, give feedback, then look back at the advice and check whether Kyle acted on it. That loop is extremely powerful. It is the kind of personal consumer AI experience I want.

Simulation note: Funny that the question about simulated interviews was also a miss. Asked to name unusual agent uses, the AI Kyle admitted it didn’t have much to offer and fell back on vague talk about removing toil. The real Kyle’s answer revealed a concrete, personal workflow that’s truly interesting and helpful.

The best interview preparation is knowing where to dig deeper

Every managing editor Eleanor Warnock wrote recently about what she calls Socrates-as-a-service: the human skill of pulling out ideas people haven’t yet put into words, like the anecdote that becomes a front-page story or the detail that crystallizes a philosophy into something a reader remembers.

That’s exactly the gap this experiment helped me see. The simulation knew about Kyle’s positions on developer choice and walled gardens because he’s made them clear in public for years. It couldn’t know that he codes on Saturdays and rotates between three machines to stay honest about other people’s tools.

In response to a post-real interview request for comment about the experiment, Daigle said, “I thought the simulated interview was pretty good! Mostly, it overindexed on my written work rather than my spoken interviews and podcasts. Without access to everything that I’ve written internally, it went harder on topics I’ve spoken about on my blog, etc. than I normally speak about.”

This is the real argument for doing an AI-simulated test run before an interview. It will show you where the gaps in the public record are, so you can spend the interview filling in those gaps and extracting truly original, scarce knowledge for your readers and the world.

Daigle found a use for my answers, too. “Even reading the AI responses, I found it clarifying my thinking and the sharpness of my answers, so it helped me, too.”

Then he added: “I actually did a similar thing for Mike. What questions I expected him to ask. I didn’t save the output—I garbage-collect a lot of it—so it’s funny how we’re all operating.”

Maybe the joke was on me all along.

The simulated Kyle Daigle was built from public material current through May 31, 2026, using a modified version of the open-source library SynthTeam, and scored against the real transcript afterward: two strong matches, four partial, six misses. Full methodology and the unabridged synthetic interview are available on request.

We also do AI training, adoption, and innovation for companies. Work with us to bring AI into your organization.

For sponsorship opportunities, reach out to sponsorships@every.to.

Fable, Disabled

Every Staff / Context Window — 2026-06-14 08:00:00 -0400

by Every Staff

in Context Window

Midjourney/Every illustration.

On Friday night, the U.S. government banned Anthropic’s distribution of Fable 5 and Mythos 5 to non-U.S. nationals. In response, Anthropic disabled Fable for all customers. As of this writing, the situation is ongoing.

It remains to be seen how it will play out, but I can already see the difference in my AI usage. Here’s a graph comparing my Claude and Codex usage before and after the ban (the “event” below):

Image courtesy of Dan Shipper.

Before the ban, I was split about evenly between Claude and Codex. After (and after a period where I was using neither because I was sleeping), I switched almost entirely to Codex.

My guess is that this ban is not going to last very long. It seems to rest on a misunderstanding between the government and Anthropic about which kinds of guardrail bypasses are fixable and what counts as an adequate solution. Anthropic believes the jailbreak identified by the government is narrow rather than universal—it surfaces only minor vulnerabilities that other public models are already susceptible to. The government apparently believes otherwise. Because both sides are highly incentivized to work this out, I’d bet that the ban is revoked after a few days—and demand for the newly returned Fable skyrockets.

However, this kind of move is extremely disruptive and distracting for people working at Anthropic. The only comparable scenario I can remember is Sam Altman’s firing, which was resolved relatively quickly. Even though Altman was reinstated, I do think the chaos disrupted the company’s momentum for months afterward.

We’ll keep a close eye on whether the same is true here.—Dan Shipper

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Knowledge base

“Vibe Check: Fable 5 Is the Best Coding Model in the World” by Dan Shipper and Katie Parrott/Vibe Check: Anthropic’s Fable 5, the first model in its Mythos class, tops every model Every has tested on coding. It’s also overpowered, and overpriced, for most everyday work. Dan and Katie Parrott ran it through Every’s standard evaluations and landed on one rule: Reach for it on long, complex, minimally supervised tasks, and stay with GPT-5.5 or Opus 4.8 for the rest. Read this for the head-to-head verdict and when Fable 5 is worth the cost.

“How to Get the Most Out of Fable 5” by Laura Entis/Context Window: The fastest way to be let down by Fable 5 is to prompt it like GPT-5.5. It rewards organized context, a clear definition of done, and room to run, shown through four worked examples: senior engineer Nityesh Agarwal repairing a broken PowerPoint-generation workflow, head of growth Austin Tedesco building a go-to-market strategy from scratch, Cora general manager Kieran Klaassen batching scattered product feedback into one set of changes, and head of platform Willie Williams building from a detailed original plan. It comes with a copy-ready Claude Fable 5 prompt library to start from. Read this for the before-and-after prompts.

“AI Everywhere, All at Once” by Laura Entis/Context Window: Four Every team members rewire their setups for Fable 5: Austin saves it for hours-long “rocket launcher” projects, Kieran makes it the middle of his “AI sandwich,” Willie argues the one thing even the best models can’t do is vibe, and head of tech consulting Mike Taylor keeps it away from confidential client work, since its environment can retain context past a task and break an NDA. Plus a dispatch from Apple’s developer conference, where Monologue general manager Naveen Naidu finds a Google-powered Siri that’s finally good and Apple opens free on-device AI to smaller apps, and senior designer Daniel Rodrigues also breaks down how he builds Every’s animated hero images. Read this for the four setups and the Apple developer shift.

🎧 🖥 “How Anthropic Uses Claude Fable 5 With Mike Krieger” by Dan Shipper/AI & I: Mike Krieger—Instagram’s cofounder and now head of Anthropic Labs—shows Dan how Anthropic itself works with Fable 5, handing the model long, ambitious jobs at night and trusting they’ll be done by morning. Watch or listen to this for how the people who built the model use it. 🎧 🖥 Listen on Spotify or Apple Podcasts, watch on YouTube, or follow the discussion on X.

“My Editor Caught Me Sounding Like AI. Now AI Catches Me First.” by Katie Parrott/Working Overtime: Katie found a list of her own writing tics—symmetrical sentences, throat-clearing introductions, and phrases that sound like something but say nothing—in a shared document with her editor. So she built a Spiral skill that encodes those tells and flags them before her editor has to. Read this for the build-your-own-AI-editor workflow.

“The Moral of Fable” by Dan Shipper/Chain of Thought: Fable 5 is the best coding model in the world, but to most knowledge workers it feels incremental. The people within Every feeling its full force have changed how they work: Kieran now hands whole projects to agents and folds what he learns into the next run. The catch is cost: Fable burns tokens fast enough that running it takes serious capital, which could put the frontier out of reach for most. Read this for what AI-native work looks like at its best, and who can afford it.

Log on

Get hands-on with how Every uses AI. These are the live camps, workshops, and meetups where team members teach the workflows behind our work.

Upcoming camp

Codex Power User Camp: On June 26, Dan and the Every team host a two-hour live walkthrough of the Codex power-user guide, including setup, workflows, and Codex-native app development. Learn more and register.

Recordings you may have missed

Fable 5 Camp: On June 12, Dan and the Every team hosted a live walkthrough of how to get the most out of Fable 5—setup, prompting, and the workflows built around long, hands-off tasks. Watch the recording.

Alignment

Uncharted waters. Last week, Anthropic, now worth close to $1 trillion, asked the world to pause AI development because of how close we may be to AI recursively improving itself. In the same week, a team at Columbia University edited the genes of human embryos, correcting mutations tied to high cholesterol and a blood disorder by swapping a single letter of DNA.

Depending on your disposition, this is either exhilarating or terrifying—probably both. I don’t know what the right guardrails are, or whether I believe they’re actually enforceable. But each week as I read the headlines, some part of me desperately wants to go back to 2008, when I was in high school and the most destabilizing thing in my world was beefing with my arch-nemesis on Facebook. That world is long gone, and isn’t coming back. We’re in uncharted waters now, and the only thing left to decide is whether we sail with our eyes open or closed.—Ashwin Sharma

That’s all for this week! Be sure to follow Every on X at @every and on LinkedIn.

We build AI tools for readers like you. Write brilliantly with Spiral. Organize files automatically with Sparkle. Deliver yourself from email with Cora. Dictate effortlessly with Monologue. Work on documents with AI agents using Proof.

For sponsorship opportunities, reach out to sponsorships@every.to.

Upgrade to paid

The Moral of Fable

Dan Shipper / Chain of Thought — 2026-06-12 15:00:00 -0400

by Dan Shipper

in Chain of Thought

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

As any child who’s heard Aesop knows, the point of a fable is its moral. We see the consequences of falsely crying wolf. We learn why slow and steady wins the hare race.

So what is the moral of Claude Fable 5, Anthropic’s newest model, which this week we called the best coding model in the world?

For engineers, the case is easy to make. For many knowledge workers, though, Fable might feel incremental. You may have one-shotted an impressive demo or two, but you’re probably not using it for your day-to-day work. Why would you? It costs twice as much and the results aren’t that much better.

But there is a certain class of developers who are feeling Fable’s full force. These are people like Cora general manager Kieran Klaassen, who are suddenly churning through his backlog of bug fixes and feature requests in hours instead of days. “This is my favorite model ever,” he told me.

What’s the difference between Kieran and everyone else? The difference between Kieran and most people using Fable isn’t simply that he’s a developer but that he’s at Level 7 or 8 on our scale of AI use: He delegates whole projects, lets agents work asynchronously, reviews the results, and feeds what he learns into the next run. In other words he writes—dare I say it, loops—not prompts.

For now, this might make Fable seem like a tool for developers. But in AI, developer workflows have a habit of spreading to the rest of knowledge work. Claude Code started as a developer tool, and now the same methodology is being used for everything from slide decks to spreadsheets inside of Cowork and Codex.

If you’re not feeling Fable’s force, that’s probably because you haven’t yet started to treat your work like gardening.

Gardening and loops

Two years ago I wrote:

“This era of creativity is going to look more like gardening. A gardener doesn’t grow plants directly. Instead, she sets up the conditions for the garden to grow.”

When you garden, you’re creating a loop. You water and weed, prune and stake, establishing and maintaining the optimal environment; the plant itself does the growing..

Likewise, developers are now creating the optimal conditions for a product to grow and improve. They’re collecting inputs like user feedback, turning it into actionable plans, which then become the basis for AI to do its work. They also create a system for reviewing that work, merging the changes, and integrating the lessons. Each stage’s output becomes the next one’s input; the developer’s role becomes determining the best order and process to help the product flourish. The process becomes the product.

You can already measure this. As soon as he’d grasped Fable’s capabilities, Kieran set a new goal for Cora: Fix any reported papercut or bug within 24 hours. So far, Fable’s held up its end of the bargain: The median time from a bug report to a merged fix is five hours over the last week, per our internal measurements. A product built this way is like a wind-up toy in reverse: Instead of winding down after you release it, every turn of the loop gives it more energy and momentum.

Tending the work is the loop. You decide what goes in, what it can reach, and when it’s done, Swap the fixing bugs for making copy edits or writing quarterly sales forecasts, and the same shape holds for any knowledge work.

The end of the flat frontier

Working in the way Fable demands opens up completely new realms of achievement for individuals and small teams. It is another step toward the world I described in 2022, in which “the consequence of models making existing work cheaper is that individuals can undertake projects that previously belonged only to organizations.”

While Every’s products are each run primarily by a single engineer, Fable changes the size of the swings each one can take. Cora is the cleanest example. Over the last two months Kieran has built an entire email inbox from scratch on the web and iOS. The nearest competitor, Superhuman, spent more than two years building its inbox before it even made mobile a top priority. AI made this possible even before Fable came out, but Kieran’s process has dramatically accelerated now that it’s available.

But the same model that expands what one person can do also raises the question of which people get to do it.

For the last several decades, there wasn’t a huge difference between cutting edge technology and what was widely available to the public. A billionaire and the average person used, more or less, the same MacBook. Now the top end is vastly different, far more expensive, and partly unavailable.

Not only is Fable twice as expensive per token as Opus 4.8, it’s also incredibly token hungry—it’s not uncommon for it to automatically spin up dozens of subagents to check its own work. This means that using Fable for real work requires capital. We’ve seen an asymmetry like this before, but not in technology. It usually shows up in the labor market: The top engineer in the world might command a salary orders of magnitude higher than even a good engineer.

Each of Aesop’s fables ends with a pithy sentence that states, outright, the moral of the story. This one doesn’t close as cleanly. Developer workflows are spreading to all knowledge work, but there’s a definite lag between the two; there’s new power in the hands of individuals, and potentially new distance between those hands and ones that can afford to run the frontier continuously.

Maybe it’s more accurate to say that the moral for Anthropic’s Fable is still being written.

Dan Shipper is the cofounder and CEO of Every, where he writes the Chain of Thought column and hosts the podcast AI & I. You can follow him on X at @danshipper and on LinkedIn.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

We build AI tools for readers like you. Write brilliantly with Spiral. Organize files automatically with Sparkle. Deliver yourself from email with Cora. Dictate effortlessly with Monologue. Collaborate with agents on documents with Proof.

For sponsorship opportunities, reach out to sponsorships@every.to.

AI Everywhere, All at Once

Laura Entis / Context Window — 2026-06-11 10:00:00 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

Anthropic’s Mythos-level Fable 5 is here, which means we’re experimenting with how to get the most of the super-capable, token-hungry model. Today, four Every team members share their approaches, plus we package eight Fable workflows into prompts you can test out for yourself. Elsewhere, Monologue general manager Naveen Naidu reports from the ground at Apple’s developer conference on why Siri is—wait for it—finally good, and head of platform Willie Williams argues the one thing even the most powerful LLMs can’t do is vibe.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Inside Every

Fable 5 versus everything else

Anytime there’s a major new model release, there’s pressure to reconsider your AI setup. Or, if you’ve just come out of a meditation retreat, maybe your entire life.

Should you swap out your preferred model for the newest arrival? Is the new model sufficiently better to make the switch if you don’t like the harness?

Fable 5 has thrown the Every team into a new round of existential questioning. It’s an obvious first choice for certain projects—those that are large, complex, and

delegable—and an arguably worse, too-expensive fit for others.

After a week of testing the model, most of us at Every have settled into a two-prong approach: Fire up Fable for ambitious assignments, let it do its thing, and reach for your favored coding agent for smaller-scale, iterative tasks.

Head of growth Austin Tedesco’s breakdown: Fable 5 demands “a very different way of approaching knowledge work,” one that requires fine-tuning exactly what outcomes you want from the model, what information it needs to execute, and trusting it enough to sit back and let it cook.

So far, Austin’s reserved Fable 5 for “rocket launcher” projects that can run for four-plus hours, like building an NBA front office simulation game, or researching and executing growth experiments overnight. With the model, he typically uses compound engineering’s LFG flow, which has the agent brainstorm, plan, work, review, and repeat.

The Codex app remains his daily driver. Austin has a setup where, when a meeting ends, Codex retrieves the action items, decides whether it can handle any of them on its own, and, if so, starts a new thread to do the work. He also uses Codex with the Spiral MCP for drafting Every’s social copy, internal strategy documents, and most same-day tasks.

Austin’s current setup. (Image courtesy of Austin Tedesco.)

Cora general manager Kieran Klaassen’s breakdown: The way Kieran likes to work—an “AI sandwich” in which he sets the task, the machine executes, and he reviews the results—is the ideal setup for Fable 5. His process hasn’t changed, but Fable 5’s superior abilities on complex, multi-step assignments means the setup works a lot better than it used to.

Fable 5 has become Kieran’s default for the middle of the sandwich. For the “bread” stages, he usually works in Cursor, where he brainstorms and polishes. And for smaller independent tasks he can assign to an agent and review later, he uses Codex CLI, Claude Code CLI, or Cursor managed agents.

What made the Kieran cut. (Image courtesy of Kieran Klaassen.)

Head of platform Willie Williams’s breakdown: Willie is still working out his setup. Fable crushes other models on Every’s Senior Engineer benchmark, but it’s too slow and token-hungry to be a good collaborator. “Do I take the downside of a slightly less capable model, knowing that when we go to the iteration portion of the relationship, it’s more enjoyable to iterate with?”

For now, the Codex app is still where he does most of his daily work. He has spent a lot of time building his setup inside the app: “I can have one thread talk to another thread that talks to another thread—it makes for a nice workflow where I always know what’s going on.”

He plans to test Fable 5’s limits with tasks he’d give a senior engineer, such as reviewing a full codebase alongside a long list of product tickets and looking for an elegant fix that could solve several complaints at once.

Head of tech consulting Mike Taylor’s breakdown: The second there is a superior model, Mike reorganizes his workflow around it. Mike plans to put Fable 5 through its paces with tasks built around ambitious loops, such as having it write a technical book section by section from a table of contents, checking each section against editorial guidelines before continuing. “I will still use Codex, but mostly out of obligation that I should try all the different things,” he says. “If I weren’t working at a company where we need to have an opinion on these things, and thus need to try everything, I would probably just be using Fable.” (An AI early adopter, Mike is happy to shell out for access to the best new models—he already pays for his own Claude Max plan for personal projects.)

One giant caveat: Mike discovered, and alerted the rest of the consulting team, that Fable cannot be used for work done on behalf of the team’s clients. Consulting work often includes confidential information, and Fable’s model environment may retain context beyond a specific task, violating existing NDAs.

Signal

An Apple AI comeback?

For years, Apple has been an AI punching bag. Some of its most anticipated AI features never materialized, and Siri…sigh.

On the ground at this year’s Worldwide Developer’s Conference (WWDC), however, the vibes were looking up. After Apple partnered with Google to build a new model family, Siri is—wait for it—finally good, according to Monologue general manager Naveen Naidu, who was on-site to test the beta version. He should know: Naveen is the one-man force behind Every’s voice dictation app, which runs on its own fine-tuned model.

What happened: Apple showed off an improved on-device model that can handle simple tasks like setting an alarm. It impressed Naveen after 10 minutes of testing. More complex requests, like booking a flight, summarizing a long Slack thread, or searching through a user’s transcripts, can be routed through Private Cloud Compute, Apple’s privacy-focused cloud system for running larger AI models. The company is giving developers with fewer than 2 million downloads on their iOS app free access to these models through its developer toolkit.

Why it matters: Free access changes the math for most developers. If an AI feature runs on the user’s iPhone or Mac, the app maker doesn’t have to pay OpenAI, Anthropic, or Google every time someone uses it. That could make AI features possible for apps that haven’t been able to justify a monthly model bill. “People can start creating great experiences without worrying about costs,” Naveen says.

He’s excited to test it out for himself. Monologue monthly token fees would shrink if he moved some features to Apple models. “Obviously I need to test whether it’s fast enough and fits my constraints,” he says. “But if it’s free, I’m going to try it and see if I can build new experiences with it.”

Apple’s courting of developers appears to be working. Naveen talked to attendees who had been going to the conference for decades. The consensus? “Apple feels much more reachable,” he says.

Tool spotlight

Unicorn studio

If you think Every’s site looks cool—I’m biased, but it 100 percent does—a big reason for that is senior designer Daniel Rodrigues, the man behind the custom graphics that make Every pieces feel like experiences rather than static articles.

To make the animated hero images and interactive backgrounds that accompany each Vibe Check or ambitious features like Dan’s 8,000-plus-word essay on why automation is a myth, Daniel turns to Unicorn Studio.

The WebGL tool lets designers build animated, 3D-esque web graphics without having to write any code. For Every’s most recent Vibe Check on Anthropic’s Mythos-level model, Daniel’s directive was to create a “nebula type of vibe, like space.”

Unicorn Studio made it easy for him to nail the assignment:

An image that Daniel made for the Fable 5 launch. (Images courtesy of Daniel Rodrigues.)

Here are a few of his other recent creations using the tool:

A cheese-y image Daniel made for the Opus 4.8 launch.

An image Daniel made for an article comparing Claude and Codex.

Jagged frontier

LLMs supply options, I supply vibes

I asked Spiral, our AI writing assistant, for 20 opening lines to an article. Number 16 was the one. I couldn’t tell you why. I just knew.

There’s no doubt that AI is capable of generating genius. It can build towers of code and write whole drafts before I’ve finished my coffee. There’s no limit to a model’s ability to execute, but it can’t tell whether any of it is any good.

And that ability to judge is vitally important. Truly creative work is an act of jumping from point A to point D, with no explanation except that it will vibe with other humans.

What are vibes? Vibes are our ability to lock in and resonate with another person’s energy; they let us intuit what matters right now, at this exact cultural moment, drawn from a lifetime of being a person in the world, thinking as humans think. And because we can feel them, we can predict if other humans will feel them too.

LLMs don’t think the way we think; they can’t respond to our energy. Can’t resonate, can’t vibe. And without the ability to vibe, they are blind, capable of producing great outputs along with mediocre ones but incapable of recognizing the difference.

So today my arrangement with AI is simple: It supplies options, I supply vibes. We work together. But while it can mine the training set for solutions, the vibes aren’t in there—they’re in me.—Willie Williams

Laura Entis is a staff writer at Every. You can follow her on LinkedIn. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Help us scale the only subscription you need to stay at the edge of AI. Explore open roles at Every.

How to Get the Most Out of Fable 5

Laura Entis / Context Window — 2026-06-10 17:00:00 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

We’re hosting two live camps for paid Every members to put the latest frontier tools to work: Fable 5 Camp this Friday, June 12, followed by a rescheduled Codex for Power Users Camp on Friday, June 26. If you already registered for this Friday’s camp, your seat is saved for the Fable deep dive, and you can RSVP for the Codex Camp.

‘AI & I’: How Anthropic uses Claude Fable 5 with Mike Krieger

Today, we’re releasing a new episode of our podcast AI & I. Dan Shipper sits down with Mike Krieger, the cofounder of Instagram and head of Anthropic Labs, to discuss what it feels like to build with Fable 5, a model powerful enough that it’s forcing him to rethink the very definition of productivity, engineering, and creative agency.

As someone who built one of the most popular consumer apps in the pre-GPT era and has had access to Fable 5 for months, Krieger has a rare vantage point on what the radical compression of the product development arc means for builders.

Watch on X or YouTube, or listen on Spotify or Apple Podcasts. You can also read the transcript.

Here are the highlights:

More work is happening overnight. Fable 5 is the first model capable enough that you can hand it a complex task, walk away, and trust it will be completed by morning. When it hits an obstacle—a remote service goes down, say, or a tool stops working—it writes a workaround and forges ahead. That resilience has changed the daily rhythm of Krieger’s work: He now ends his workday by briefing the model on what needs to get done while he sleeps, rather than sitting down to do it himself.
The gap between what’s in your head and what exists in the world is closing. Given access to Fable 5 and a set of internal MCPs, an Anthropic recruiter described the experience as, “The first time in my life where I feel like the thing that’s in my head and the thing that exists in the world are right next to each other. I can just do it.” This is the most meaningful thing about the new model class, Krieger says—it allows non-engineers to create the exact products they need to get more done.
Software engineering is dead. Long live software engineering. Engineers now spend less time writing code and more time setting direction, reviewing what their AI agents have built, and making judgment calls when something breaks in production. The divide between product managers and engineers has blurred. “There is a feeling of loss, I think, in some of the better engineers that I talk to, as well as the feeling of, ‘Oh my God, but I can do insane amounts of work now at the same time.’ We’re holding both ideas in our heads at once,” Krieger says.
All eyes are on verification. If we can delegate more to the model, it becomes more important to check what it has built works in practice. Krieger’s approach combines regression testing on known workflows, visual checks—including giving the model video captures of its own work so it can catch animation glitches screenshots would miss—and mock backends for anything too complex to test live. When a bug arrives via Slack, Fable 5 makes the fix, posts the pull request, then follows up hours later.

How the Every team is using Fable 5

The easiest way to be disappointed by Fable 5 is to use it as if it were GPT-5.5 or Opus 4.8, smart models that require specific instructions and careful prompting for the best results.

Instead, Fable 5 feels like working with a capable coworker—at least that’s Every’s consensus after a week of testing.

“It feels like you have an engineer on your team that you just gave a problem to, and they’ll figure it out,” says Cora general manager Kieran Klaassen.

That means, to get the most out of Anthropic’s first Mythos-class model available to the public, you have to think like a manager: Equip the model with context, goals, and a way to verify the work, then step aside. It may even stumble on a solution you hadn’t considered.

Not every task deserves this treatment. Smart colleagues don’t come cheap, and neither does Fable 5. Here’s how to get the most out of this powerful new model and some of the workflows the team is using.

Pick the right tasks

Tasks that are good candidates for Fable 5 have four qualities: You’re able to give the model organized and deep context, a well-defined goal, and a clear definition of what good or done looks like, and the importance of the task justifies the cost.

The model is smart enough to reason its way through complex problems and likes to carry tasks through to the end, but if your data is wrong or out of date, or your goals conflict, it will likely reach the wrong conclusion. That’s less of a concern on earlier, less powerful models, where you’re giving feedback more frequently during a task and could catch those mistakes.

Advanced users of AI—who operate at Level 7 or Level 8 on our AI adoption curve—are already comfortable delegating to their agents. For everyone else, using the model demands a mental reframing. Instead of iterating back and forth, the work gets frontloaded into providing the right context and establishing clear directives, letting Fable 5 do its thing, and only reviewing the results once it’s completed the entire task. The examples below are entry points to get you started.

Example 1: Fix a broken workflow

Senior engineer Nityesh Agarwal built a Claude Code skill to help Every’s consulting team create first drafts of PowerPoint decks. It worked, but it kept hitting the same snags: Boxes were slightly misaligned, images weren’t the right size, and sometimes a footer would be updated on one slide but not another. One run with Claude Code took about 30 minutes, used roughly 100 million tokens, and still came back with errors.

Nityesh pointed Fable 5 at the Claude Code session log and asked it to review where the PowerPoint skill was breaking down.

Fable 5 found the root problem. Under the hood, a PowerPoint file is a bundle of XML files that store the position, size, styling, and order of everything on a slide. Claude was being asked to edit those hidden files directly, so a simple request like “change this phrase” or “move this image two inches left” required the model to find the right hidden text and rewrite the surrounding layout code without disturbing anything else.

Fable 5 built a command-line tool that gives agents a more natural way to work with PowerPoint— if the text on a specific slide needs to be updated, for example, or an image has to be resized, the agent can use the tool to make these targeted changes instead of having to rewrite the entire XML file.

Nityesh’s takeaway: Use Fable 5 to diagnose broken workflows, create the tools or skills that fix them, and then let cheaper models use that infrastructure going forward.

Nityesh's prompt

Here is a session log from an agent trying to complete this workflow: [describe workflow]. It struggled in these ways: [time, cost, errors, bad outputs, repeated failures]. Take a step back and analyze where the current tool, skill, or workflow is breaking down. What is the root cause of the failure, and how would you fix it? Make a plan first. Then build or specify the upgrade. Test it against the same kind of task, and explain how cheaper models could use it later.

Example 2: Create a go-to-market strategy

Austin Tedesco, Every’s head of growth, had a lackluster first experience using Fable 5 to generate a go-to-market strategy for this week’s model launch. He asked it to look across Slack and Notion for relevant context, but the output didn’t feel meaningfully better than what he might have gotten from GPT-5.5 or Opus 4.8. “It did a good job of synthesizing what we had all said and compiling it. But I thought, ‘This plan isn’t any better than what we would have done,’” he says. “It’s acting as a very expensive, verbose executive assistant.”

For his next attempt, Austin put more effort into framing a more complex problem, asking Fable to look at a large set of Every audience insights—survey results, PostHog data, brand positioning work—and audit them against the actual Every.to website experience, while considering the team’s quarterly plans and internal goals. Then he gave it a clear business objective—increase paid subscriptions among those target customer profiles.

He was also more specific in what he wanted back: a Notion report with 10 data insights that might change how the team operated, plus a stack-ranked list of 10 things Every should ship or try.

The difference was striking. “Dan [Shipper] and I kept saying, ‘This is nuts,’” Austin says. “If we hired a go-to-market engineer to do this and they turned this around in two weeks, we would say, ‘This was an incredible hire.’”

Austin’s takeaway: Fable 5 performs much better on knowledge work when you give it a complex problem, full access to relevant sources of truth, a clear goal, and a specific output. If you ask it to “make a plan,” it may summarize what people already agree on. If you ask it to use data to test assumptions and produce a ranked set of decisions, the results are much sharper.

Austin's prompt

Use the attached source pack to analyze [business area/launch/audience/funnel].
Sources include: [survey data, customer research, analytics dashboards, website context,
planning docs, meeting notes, Slack discussions, internal goals].
Our goal is [specific business goal] for [target customer/profile].
Do not just summarize internal consensus. Use the data and source material to test our
assumptions and identify what should change.
Produce:
1. The 10 most important insights that could change how we operate.
2. A stack-ranked list of 10 things we should ship, try, or stop doing.
3. The evidence behind each recommendation.
4. Any source conflicts, stale rules, unclear analytics definitions, or assumptions
I should verify before acting.
If you find a conclusion that depends heavily on one data source or project rule,
flag it and explain how you would check whether it is true.
/lfg—This command sends the agent on a full compound engineering workflow, including planning, building and reviewing. It’s a reliable way to get the most out of Fable.

Example 3: Turn feedback into batched changes

Before Fable 5, Kieran trusted agents with narrow, well-defined product fixes, such as making a keyboard shortcut work or resolving a bug from a screen recording. His broader workflow was already in place: Pull feedback from Slack or videos, give it to an agent, and review the result at the end. He calls it the “AI sandwich”: human at the start, machine in the middle, human at the end.

This weekend, Kieran had Fable 5 pull everything a colleague had said about Cora over the previous two days on Slack, analyze it, and make a list of product fixes. His agent handled all the fixes, and Kieran checked the result at the end. In one run, he made 30 fixes in a single batch and had the agent check the changes didn’t interfere with one another, instead of reviewing 10 small tasks one by one.

Now he’s working on building the next layer: having the agent automatically pull product feedback from Slack on a schedule, evaluate it against Cora’s vision document and user personas, surface changes that seem to be worth making, and present it to him for approval.

That kind of loop depends on the quality of the raw material. Screen recordings are useful because they show the model what a written bug report often leaves out, such as what someone clicked on, what happened next, and how that differed from what they expected. Slack can also work as a source of signal, especially when the comments come from people with strong product judgment.

Kieran’s takeaway: Fable 5 is strongest when the work is connected to a feedback loop. The model can gather, group, and act on feedback, but the quality of the result still depends on the quality of the input. His role is to decide which ideas are worth acting on.

Kieran's Prompt

Collect product feedback about [product/feature/workflow] from these sources:
[Slack channel, support tickets, screen recordings, screenshots, production logs,
customer calls, meeting notes].
Group the feedback into themes. Identify:
1. What is clearly actionable
2. What needs my judgment before acting
3. What conflicts with our strategy, personas, or product direction
4. What evidence you used
For the actionable items, create one batch plan. If you have the tools and approval
to make the changes, implement them together. Make sure the fixes do not conflict.
When you are done, show me what changed, what you skipped, what still needs my
review, and how you verified the work.

Example 4: Build from an original plan

Years ago, Willie Williams, Every’s head of platform, built a website for a friend who was in school to become a therapist and needed a better way to create genograms, a kind of annotated family tree used in some therapeutic intake processes. The original version took him a couple of weeks, and it had a stubborn bug: While running, the site would get slower and slower until it crashed.

Willie had tried to fix the issue with other models before, to no avail. Fable 5 didn’t get it on the first try either. When Willie asked it to only look at the code, it confidently suggested a fix that didn’t work. Then, he told Fable 5 to run the app locally, watch what was happening, and figure it out from there. Once it could see the site running, it fixed the bug.

After that, Willie gave Fable 5 a bigger assignment: Build the product from scratch using the original spec, without looking at the version he had already built. The spec included who the product was for, what users needed to create, how the visual workspace should behave, and the edge cases the app needed to handle. Willie ran the same test against Opus 4.8, GPT-5.5, Fable 5. Fable 5 was significantly better than Opus or GPT-5.5.

Willie’s takeaway: Fable 5 is well suited to assignments where you can give it the same materials you would give a senior engineer: the product goal, relevant domain context, tricky edge cases, and a clear sense of what the first version needs to do. It can work from a plan, make judgment calls, and produce a first version without being walked through every step.

Willie's prompt

I want you to build a first working version of [product/website/tool].
Here is the original product spec: [paste spec]
Here is who it is for: [users]
Here is the domain context you need: [terms, workflows, examples, constraints]
Here are the tricky cases the product must handle: [edge cases]
Here is what the first version needs to do: [requirements]
Here is what can be rough for now: [scope boundaries]
Make a plan first. Then build the first version. Run it locally or otherwise test
it in the environment where it will actually be used. When you are done, show me
how to try it, what decisions you made, what you left out, and what I should
review carefully.

Cost is only part of the decision

Fable 5 is powerful—and expensive. The model is available on Claude’s paid plans until June 22, after which it will move to token-based pricing. (It costs $10 per million input tokens and $50 per million output tokens, making it roughly two times the cost of Opus 4.8 and three times the cost of Sonnet 4.6.)

But cost is only one part of the decision. Fable 5 is also slow, especially when you run it at higher effort levels, so it makes the most sense for large, complex, delegable jobs you can trust the model to complete and review later, such as fixing a broken workflow, building a feature or app, synthesizing a lot of source material, or reviewing a codebase. For quick edits, small bugs, and back-and-forth brainstorming, faster and cheaper models remain the better option. Read more about the model’s strengths and weaknesses in our hands-on Vibe Check.

Laura Entis is a staff writer at Every. You can follow her on LinkedIn. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Help us scale the only subscription you need to stay at the edge of AI. Explore open roles at Every.

My Editor Caught Me Sounding Like AI. Now AI Catches Me First.

Katie Parrott / Working Overtime — 2026-06-08 18:00:00 -0400

by Katie Parrott

in Working Overtime

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Before a recent one-on-one with Kate Lee, Every’s editor in chief, I opened our shared document and found a list of my own writing fails staring back at me. My drafts had picked up too many of the AI tells that both I—and you—know how to spot from across the room: the symmetrical sentence structures, the little rhetorical throat-clears, the phrases that sound profound on first pass but on closer inspection contain nothing but air, and those pesky sets of three.

The worst part was that I should know better. I am the person at Every who writes about writing with AI while using AI to write about writing with AI. I have custom agents, style guides, editorial workflows, and an apparently bottomless appetite for turning every lesson into a system. And still, I had let the machine’s smoothness pass for my own judgment enough times that my editors felt the need to intervene.

After the meeting, I did what I generally do when I learn something new, embarrassing or otherwise: I baked it into documentation for my agents. I opened the notes, pulled out the patterns Kate had flagged, and listed them in a new skill called /guardrails, which turns any agent I write with into an exacting editorial specialist that keeps me honest.

I’ll never be completely done with /guardrails, or any of the review skills like it that I’ve built, because my human tics and tendencies will move around like a squirmy toddler. But I’d rather make new mistakes than keep repeating the old ones. Review skills are the mechanism by which I do that. They’re another form of editor, one that can catch a draft’s more annoying weak spots before they become a human editor’s problem.

The start of my guardrails skill, where I’ve compiled all the particular ways that content I submit can fall below par. (All images courtesy of Katie Parrott.)

Writing with AI tends to be portrayed as a bargain: The machine does more, so the human does less. But in my experience—a microcosm of Every CEO Dan Shipper’s argument in “After Automation”—it changes what the human does instead of reducing the workload. I have to be clear about defining my standards so a model can understand them. That creates more work—but it helps me understand them better myself.

Setting up reviews like /guardrails takes time, attention, and a certain comfort with a tool like Codex or Claude Code. But once the reviewers are in place and working, I can spend more of my time pushing the draft from good to great. My drafts are now much cleaner and my own preferences are less of a mystery to myself, because I’ve had to think and talk about them enough that they’ve worn new grooves into my brain.

I’m going to show you a few of the reviewers I rely on and what goes into them (I’ll share a set on Every’s GitHub along with this piece). But it should serve as an example, not a blueprint; the special sauce of this process comes from setting and enforcing your own collection of style requirements.

Skills rule everything around me

In the beginning of any good guardrail system, there are skills.

At the mechanical level, a skill is a Markdown file with instructions inside it. Practically, it’s a way of packaging judgment. When I invoke the guardrails skill, I am asking the model to read a draft through a set of lenses: Look for AI tells, vague claims, hedges, limp openings, and all the little ways a zombie draft can pass as finished without a pulse.

I’ve become fanatical about naming conventions. After all, skill names have to be sticky enough that you remember them when you need them—although this gets less true with every model release, as AI becomes better at deciding which tools it needs to do the job. Still, “assess narrative momentum” sounds like a task someone puts in a project management tool shortly before everyone involved loses the will to live. Instead of clinical descriptors, I’ve given my more editorial skills their own personas: Sorkin is a reviewer with a job. He wants to keep the piece walking and talking, not mired in unnecessary specifics. Similarly, Mom wants to know where a reader who’s not as AI-pilled as I am might get lost. Asshole wants to attack the weakest version of the argument, which is annoying because sometimes the weakest version of the argument is the one I wrote.

Each of these reviewers asks a different question. Together, they give me a way to pressure-test a draft before I hand it to a human editor whose attention I would prefer is spent on problems only a human editor can solve. Our brains belong on the piece’s angle, claim, storytelling, and audience fit. You know, the fun stuff, with some stakes attached.

Running the guardrail gauntlet

Here’s an image to give you a sense of what a typical final review looks like before I hand a piece to an editor:

A comprehensive rundown of 12 agents reviewing a draft ahead of submitting to an editor.

This preflight checklist comes after I’ve drafted, argued with, rewritten, and reread a piece many times. By this stage, the writing is mine, whether AI was involved in the drafting or not. AI’s job is to look for the things I am most likely to miss because I am tired, emotionally attached, or too deep inside the logic of the draft to see the true shape of it anymore.

This final lineup of reviews may look excessive—and it is. When a model can help you get to a plausible draft quickly, the danger is writing that sounds profound at first glance but is, in fact, just AI being pleased with itself. I designed my reviewers to be the closest inspection possible.

Different reviewers for different stages

With my guardrails in place, the real fun is channeling all my anxious energy into invoking them through every stage of the writing process.

At the outline stage, I want pressure on the argument. While drafting, I want line-level reviews that catch my tics. Once the full draft exists, I want readers arguing with the piece as a whole. And before I hand it to an editor, I want the checklist to sweep for everything my tired brain missed.

The beginning of the guardrails readout for this very draft.

Outline: Beat up the argument

The first guardrail round happens at the outline stage, before I have prose to get precious about. I send the structure to reviewers whose job is to hunt for weak spots. Hitchcock looks for tension. Sedaris looks for a sense of humor. And when I’m really a glutton for punishment, there’s /asshole, which is set up to deliver the least-charitable interpretation of the argument possible so I can shore it up.

The Hitchcock skill reviews the draft for suspense. Is there a “bomb under the table” that will make the reader want to keep reading?

At this stage, I want structural trouble in bright red, whether it’s a claim the reader can’t follow, a section that arrives too early, or a setup with no payoff. The outline is where I can still rearrange and reframe big chunks of the work to make the strongest argument.

Section drafts: Catch weak prose early

By the time I’m ready to draft, I’m in full chaos mode, so I lean on the skills that help me clean things up. I write section by section, and after each section I run /ai-check and /guardrails before moving on. I am trying to catch that tell-tale smoothing while it is still local.

I also run senior editor Jack Cheng’s /tighten-draft skill. Jack built the skill around his years of editorial instincts to spot the kinds of bloat that can accumulate in a draft and make it a chore for a reader to get through. That is one of the pleasures of skills: Editorial taste becomes something you can share. My workflow can carry my standards, Kate’s feedback, Jack’s editing rules, Every’s house style, and whatever strange little reviewer I decided to invent at 11 p.m. because a draft was annoying me in a new way.

Full draft: Make the piece argue back

Once I have a full draft, the focus of the review moves from the details back to the big picture. I run a developmental review for argument, structure, stakes, and payoff. Then I run a column-specific review: /working-overtime for this piece, or whichever column skill fits the draft. That pass checks to see if the essay makes all of my signature structural moves as outlined in my style guide: Start from lived friction, show the messy middle, connect the personal to the larger AI-era work question, and hand the reader something usable.

This is also where I call on a more sophisticated form of skill-building: orchestration, or the threading together of multiple skills and agents to execute a more complex task. I’ve created a command called /panel, which convenes a set of my reviewers for a more holistic review. First, the panel reads the draft’s context: piece type, audience, stage, and goals, all of which it knows from the interview stage and my Working Overtime style guide. Then it proposes the reviewers suited to the problem in front of it—or lets me pick. For this draft, I had it run Mom for accessibility, Hitchcock for tension, Sorkin for momentum, and Sedaris for humor. This is different from summoning the agents one by one, because the output is a synthesis of all their feedback, rather than checking for one specific thing.

/panel summons a lineup of reviewers to render their verdict on a draft trending toward submission.

After the reviewers run in parallel, a synthesizer reads their feedback together. It looks for consensus findings, productive tensions, unique insights, recommended priorities, and the single hard question the draft keeps circling. One reviewer may want a section cut. Another may think the same section is the most alive thing in the draft. The synthesis keeps that disagreement intact, because the tension tells me what decision the piece is asking me to make. Then I, the human, have to figure out how to make it.

Here’s a final big-picture question the panel on this draft left me with:

Is this an essay about a system that’s working, or an essay about a writer who has to keep building infrastructure because her own defaults keep losing? The reviewers can tell you the piece currently splits the difference—selling the system in the middle, hinting at the slippage in the corners. The opening, middle, and ending all change depending on the answer. Hitchcock said it cleanest: The melodrama only works if it’s true. So, is it?

Final pass: Run the team checklist

Finally, I run the draft through the team’s accumulated editorial muscle memory, as it’s been packaged in our shared skills. I rerun /ai-check, because revisions can reintroduce assistant voice. I rerun /guardrails, and more often than not, it finds tics I’ve either added or been too enamored with to kill earlier in the process.

Then I run /tighten-draft again, plus /kate-top-edit, a skill built around Kate’s review expectations: vague “this” openers, unsourced data, floating quotes, unidentified people, unexplained jargon, missing Every links, hedges, marketing language, sentence fragments, and the AI tells our editorial team has learned to avoid at all costs.

Human review is the ultimate fine tuning

By this point in the workflow, the whole system can look like protection from AI. The fuller truth is that a lot of it is protection from my own blind spots when I’m too tired to live up to my best self. Writing with AI requires, in the words of Harry Potter’s Mad-Eye Moody, “constant vigilance.” But then, writing without AI does, too.

Some reviewers catch model habits, like overly clean transitions and sentences that use symmetry as a substitute for thought. Others catch Katie habits: phrases I reach for too often, clever constructions I enjoy more than the reader does, and little rhetorical moves that feel sharp in the moment and embarrassing by the next morning.

The process is ongoing and imperfect. We are fallible creatures, as are our machines, so there will always be new quirks to banish. It’s important to be in the habit of updating old skills with new items to watch for, and creating new skills to enforce standards that you discover along the way.

That is why I am pairing this piece with a repo. I want you to be able to pull down the skills, open them up, and make them useful for your own AI writing adventures—and foibles.

Here’s how to get started:

Open the GitHub repository. Click “Code,” then “Download ZIP,” and unzip the folder.
Open the folder in the Codex or Claude app.
Tell your agent: “Read the README and help me install these reviewer skills. Explain each step in plain language.”
Choose one reviewer and run it on a draft you know well.
Note what it caught, what it got wrong, and what it missed. Ask your agent to update the reviewer’s SKILL.md with that feedback.
Run it again and repeat until the feedback is useful.

You do not need to fork the repository to get started. Forking creates your own copy on GitHub, which is useful if you want to track your changes or receive future updates.

Grab the repo. Give the reviewers meaningful names. Delete the ones that are pure Katie pathology. Add new ones to prevent your own bad habits, whether that’s legal overreach, unsupported claims, faux profundity, jargon, or hype. Teach the machine to protect the work from default settings—the machine’s, but more importantly, yours.

Download Katie's draft review kit on GitHub

Katie Parrott is a staff writer at Every. You can read more of her work in her newsletter. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

Discover Every’s upcoming workshops and camps, and access recordings from past events.

For sponsorship opportunities, reach out to sponsorships@every.to.

AI Is Ready. Organizations Aren’t.

Every Staff — 2026-06-06 15:00:00 -0400

by Every Staff

Midjourney/Every illustration.

Hello, and happy Sunday! This week the consulting team published two practical guides. Mike Taylor built on engineer Steve Yegge’s viral post to map the eight levels of AI adoption—with sample prompts and signals for when to move up—and Natalia Quintero (who’s talked to leadership teams at hundreds of organizations) laid out a foolproof five-step process for executives rolling out AI across their companies. Covering Microsoft Build, Mike argued that enterprise adoption lags the news cycle—a gap he sees up close with the enterprise clients he advises. He also made a counterargument to Dan Shipper’s essay about the future of work, “After Automation.”

Spiral 4.0 shipped this week: Every’s writing tool can now draft in your voice from inside any agent, with a price cut to match. Elsewhere, Figma’s Matt Colyer makes the case that the SaaSpocalypse is overblown, designer Daniel Rodrigues shares a two-tool image generators workflow, Monologue general manager Naveen Naidu has a system for making coding agents more efficient with custom local skills, and the team names its most annoying model output.—Kate Lee

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Knowledge base

“The Eight Levels of AI Adoption” by Mike Taylor and Laura Entis/Guides: A framework mapping every stage of AI adoption, from Level 1 (a chatbot you ask and it answers) to Level 8 (an orchestrator agent that runs a team of sub-agents), with example prompts and guidance on when to move up. A higher level isn’t automatically better—the right level for a task depends on how much you trust the AI to run without intervention and how costly a mistake would be. A companion essay lets you figure out which level you’re on. Read this for where you stand today and what it takes to move up a level.

“An Executive’s Guide to Implementing AI” by Natalia Quintero/Guides: AI adoption isn’t being held back by the models—it’s the organization. Natalia Quintero, head of Every Consulting, gives executives who’ve bought the tools but aren’t seeing returns a five-step framework, laid out as a 60-day plan—with a companion essay that previews it. Read this for the five steps and how to run them.

“How Microsoft Is Building for a World of Metered Intelligence” by Mike Taylor/Also True for Humans: Reporting from Microsoft Build, Mike Taylor argues that Microsoft is the first big company to design for a world where intelligence is metered and the era of subsidized AI subscriptions is ending. Its response includes automatic model routing, a laptop that runs AI locally, and cheaper, smaller models. Read this for a ground-level look at AI’s post-subsidy era.

“Why We’ll Still Be Employed When AI Can Do Everything” by Laura Entis/Context Window: In a counterpoint to Dan’s “After Automation” essay, Mike argues that even after AI can outwork people at well-run companies, running it will cost so much energy and compute that hiring a person is often cheaper. Read this for a grounded take on the AI-employment debate.

“Opus 4.8 Is Smart Enough to Get in Your Way” by Laura Entis/Context Window: A week after our Opus 4.8 Vibe Check, we check back in—now that the public has reacted and more of the Every team is using it daily—and our initial read holds: It’s strong on dense, long-running work but quick to get in its own way. Read this for how the verdict looks a week on.

🖥 “Codex Runs My Inbox Now” by Dan Shipper/Every: Dan shows the workflow that’s kept him at inbox zero for 13 weeks straight—a Codex-native app that pulls his emails, Slack messages, meetings, and company context into review cards, drafts the next action on each, and learns from every decision. It shows Codex working as an operating system for knowledge work and ends with the full prompt to build the app yourself. Read this for the inbox-sweep workflow and the prompt to copy.

“Figma Exec on Why the SaaSpocalypse Is a Goldmine” by Dan Shipper/AI & I: Matt Colyer, Figma’s director of product management for developers, argues that the “SaaSpocalypse”—the fear that vibe coding will kill software by letting anyone build their own tools—has the economics backward: AI expanded the developer base, so more software gets built and software becomes more valuable, not less. Watch or listen to this for the clearest reframe of the vibe-coding-kills-SaaS panic. 🎧 🖥 Listen on Spotify or Apple Podcasts, watch on YouTube, or follow the discussion on X.

Log on

Get hands-on with how Every uses AI. These are the live camps, workshops, and meetups where team members teach the workflows behind our work.

Upcoming camp

Codex Camp: Our Power User Guide: On June 12, Dan and the Every team host a two-hour live walkthrough of the Codex power-user guide—setup, workflows, and Codex-native app development. RSVP.

Recordings you may have missed

Compound Engineering Camp: Kieran Klaassen and contributor Trevin Chow walk through compound engineering, Every’s AI-native development workflow. Watch the recording.
Executive AI Sessions: Natalia introduces Every Consulting’s new offering for leadership teams navigating AI adoption. Watch the recording.

From Every Studio

Spiral 4.0 ships agent-native access and a price cut

Spiral, Every’s AI writing tool, shipped version 4.0 this week: a new style engine, agent-native access through MCP, CLI, and API, and expanded team workspaces for writing in a shared voice. Pricing moves from sessions to tokens, dropping the personal plan to $15 a month (from $25) and team plans to $25 per user (from $35).

Alignment

The great wall gets greater. Drug companies do not create billion-dollar assets by having ideas. They need human trials to prove the idea works, and China has become exceptionally good at running them. Because the government has made biotechnology innovation a strategic innovation, policy makers have cleared the bureaucracy and regulation obstacles that have long slowed drug development in the U.S. and Europe. As a result, last year Bloomberg reported that China had more than 1,250 novel drugs entering development, close to the U.S. count of about 1,440. A decade ago, Chinese biotech was synonymous with copycat drugs—which makes this a Sputnik moment for the industry.

One key reason for China’s ascendency is that hundreds of millions of patients are concentrated in large urban hospitals, so companies can recruit quickly from a smaller number of high-volume sites. Chinese biotech firms can reportedly complete patient enrollment for a phase 1 or phase 2 trial in nearly half the time a U.S. firm needs. In North America—and even more so in Europe—patients are scattered across fragmented health systems, where every trial site has its own contracts and ethic approvals, each one slow and cumbersome.

China recruits trial patients in about half the time the U.S. takes and runs far more trials, across anti-cancer and anti-obesity drugs by phase, 2020–2024. (Source: Norstella.)

China’s advantage is that it can turn a large population into clinical data much faster—and iterate on feedback loops of drug development to produce assets that are more effective, and thus more valuable to investors and big pharma. Recently, Legend, a Chinese biotech, developed its own version of a largely American drug innovation that treats multiple myeloma, a type of aggressive blood cancer. Chinese drug developers moved quickly into human trials and produced data strong enough for Johnson & Johnson to sign a global licensing and codevelopment deal with Legend worth $350 million upfront.

A second- and third-order consequence of this new landscape is that even U.S. biotech firms may start asking whether it makes sense to take their drugs to China first, at least to complete phase 1 and phase 2 trials.

For now, any drug seeking approval in the U.S. still needs evidence that regulators believe applies to American patients—and in many cases that means later-stage global or Western trials. But it may be inevitable that a Chinese biotech develops a China-originated drug that was licensed into the west without such a step.

If this change happens—and many believe it will—the next major obesity, oncology, or immunology drug may come from China, marking the same pattern of ascendancy already visible in solar, batteries, and electric vehicles. Biotech may be next.—Ashwin Sharma

That’s all for this week! Be sure to follow Every on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Upgrade to paid

How Microsoft Is Building for a World of Metered Intelligence

Mike Taylor / Also True for Humans — 2026-06-05 13:00:00 -0400

by Mike Taylor

in Also True for Humans

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

As I rode in my Uber to Microsoft’s annual Build conference on Monday, I fondly recalled a time when you could get anywhere in San Francisco for $5. Those days are long gone. Venture capitalists lost their appetite to supply unlimited funding in a viciously competitive market, and Uber needed to show a path to profitability ahead of its 2019 IPO.

There are signs that the “$5 Uber era” of LLMs is over now, too. AI labs are subsidizing subscriptions to the tune of thousands of dollars, which can’t continue forever. This year Anthropic, OpenAI, and SpaceXAI are all going public—and like Uber seven years ago, they’ll need to take a hard look at their books. On June 1, the eve of the event, Microsoft sparked outrage by switching to token-based billing on GitHub Copilot. Some users said their bills jumped from $39 to over $3,000 per month.

Rather than backtracking on billing, Microsoft used the conference stage in California to make the case for using AI more pragmatically in the face of rising costs. I came away from the event thinking that Microsoft is the first company to get real about a world where intelligence is available on tap, but constrained by how many coins you can put in the meter. Here is what the company’s vision looks like in practice, and what it might tell us about how we’ll be paying for and pricing AI in the future.

Intelligence on and off the meter: A product approach

In his opening speech, CEO Satya Nadella addressed pricing concerns head-on. He promised “unmetered intelligence to every desk and every home,” an AI-era update to Bill Gates’s vision of “a computer on every desk.”

Microsoft CEO Satya Nadella promised “unmetered intelligence to every desk and every home.” (All images courtesy of Mike Taylor.)

The most tangible way to experience that vision is with the RTX Spark, a new laptop Microsoft designed for AI workloads with Nvidia. The device is able to run a medium-sized 128-billion-parameter model locally (frontier models are in the trillions of parameters) so developers can get a lot of work done without paying a penny for tokens. Microsoft is taking advantage of the fact that the leading open-source models like Kimi-K2.6, which have a trillion parameters, are too big to fit on most laptops, and is betting that budget-conscious coders might not mind being a year or two behind the frontier and use a smaller model. The device will be released in the fall.

The RTX Spark laptop follows earlier feature announcements that show that Microsoft wants to decrease switching costs for customers by being the place where you can use any model, agent, or harness. The laptop has a rebuilt smart terminal app that allows you to run any coding agent harness and has adopted popular terminal commands from the Mac ecosystem to make the shift easier for developers.

Even the GitHub Copilot Desktop app, also released at the conference, makes it easy to switch providers between OpenAI-built, Anthropic-built, and local open-source models running on your device.

When questioned about the affordability of agentic coding, Mario Rodriguez, GitHub’s chief product officer, cited the automatic model routing feature in GitHub Copilot, which can delegate less complicated tasks to cheaper models. In my interview with Kyle Daigle, GitHub’s chief operating officer, he lamented that developers tend to choose “the model of the day, or week, or hour,” even when the task doesn’t merit that kind of power. A person probably will not manually switch to a cheaper model for that final step, “but the tools could.” I’ve also long argued that not every task needs to be done by a frontier model.

I get the feeling the team built this model router feature for themselves after facing the same problem everyone else is right now—Microsoft itself has been cancelling Claude Code licenses to reduce costs.

Features like automatic model routing show that Microsoft understands how runaway costs hurt enterprises that need tighter control over spending. The AI labs won’t let large companies buy highly subsidized individual “Max” plans, so big companies end up paying full freight on every token they burn. One that wasn’t properly monitoring usage is rumored to have spent an eye-watering half a billion dollars on Claude tokens in a single month.

That wasn’t the only news that day: Microsoft’s research lab, led by Mustafa Suleyman, released a set of new (cheaper) smaller models spanning image, voice, transcription, coding, and reasoning.

Tackling costs through model optimization

But when you don’t use the latest models to save cost, there’s a higher risk of making a costly mistake. One answer was a phrase I heard over 100 times at the one-day event: “hill climbing.” This is the idea that you can set an evaluation metric for a task—a lookup to check your AI customer service bot is giving the right answers to common questions, for example—and then keep automatically testing new instructions until the smaller model gets an acceptable score.

This is the thesis behind optimization frameworks like GEPA in DSPy, Andrej Karpathy’s autoresearch, and Codex’s /goal feature. In this fashion, you can use a smart model to train a dumb one, a process called distillation, bringing down costs while maintaining reliability. In a podcast appearance recorded at the conference, Nadella called private eval benchmarks for use in hill climbing the “greatest IP” that a company could have.

Mistakes will still be made, even with frontier models, so Microsoft also focused on security. To make AI less likely to make costly mistakes, the company released MXC, or Microsoft eXection Containers, an operating system-level sandbox designed to securely contain untrusted code, plugins, and autonomous AI agents. In a surprise appearance, OpenClaw creator Peter Steinberger appeared on stage during a demo in which a team instructed their agent to delete all their files on their computer, only to be thwarted by the protections their IT department had put in place through MXC. The message was: “OpenClaw is safe for work now.”

To prove the point, Microsoft launched Autopilot, its take on hosted long-running agents, with the first (of many) agents Scout inspired by internal testing and experimentation. Autopilot runs agent frameworks like OpenClaw and Hermes Agent, but is hosted in a secure Microsoft environment, with access to all of the context available in your documents and applications. Executives also pointed to MDash, their multi-agent code review system, which, according to Nadella, caught bugs that even Anthropic’s Mythos model missed.

What Silicon Valley is missing

While many enterprise clients are trying to manage costs or struggling to measure return on investment, there will always be a thirst for the most expensive and highly performing frontier models among AI-pilled developers. And for those, we will need data centers. Nadella said the company will keep up its brisk pace of building, yet also acknowledged the societal cost better than any other leader I’ve seen in the space.

Tech Insider reported that half of announced U.S. data center capacity for 2026 has been cancelled or delayed, in part due to concerns about rising electricity prices and water usage. Nadella framed continued construction as something the tech industry needs to earn permission for, by committing to keeping electricity and water usage self-contained and by providing jobs and opportunities for local residents. A small protest against data centers formed at the entrance of the conference, and at one point I looked up and saw an airplane trailing a sign with the same anti-data center message.

Signs made by protestors of data center construction outside the conference.

Microsoft Build is normally held in Seattle, and hosting it in San Francisco allowed for a stark contrast between the token maxxing AI-pilled engineers and the relentlessly pragmatic enterprise leaders who are trying to get this technology to work in their companies. Richly compensated AI researchers spending hundreds of billions of free tokens per month aren’t living in the same world as a junior IT consultant for an enterprise healthcare company in Seattle––and that person swears by Microsoft’s products.

As I rode my Uber back to the airport at the end of the conference, I read a story about how Uber had capped its engineers’ token budget at a sensible $1,500 per month. If this represents about 10 percent of a typical Uber engineer’s salary, managers expecting to improve productivity by 10 times will make up the difference through more pragmatic usage.

For sponsorship opportunities, reach out to sponsorships@every.to.

Why We’ll Still Be Employed When AI Can Do Everything

Laura Entis / Context Window — 2026-06-04 14:00:00 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Launch

Spiral 4.0

Today we’re launching Spiral 4.0, which writes drafts in your voice from idea to line edit. Spiral has a new MCP alongside the existing CLI and API, so any agent or workflow can write in your voice too. For teams, we’ve expanded workspaces, which let you share styles, prompts, knowledge—and now chats and drafts. Finally, Spiral has a new pricing model: We’ve switched from session limits to token limits, so costs match your actual usage rather than how many times you opened a new chat. A vast majority of users will end up paying less: Personal plans now start at $15 a month—down from $25—and team plans are $25 per user, down from $35.

Try Spiral 4.0

Signal

Enterprise AI product roadmaps are hard

Microsoft is moving fast. Three months after OpenClaw came out in November 2025, Microsoft CEO Satya Nadella described it as a “virus”-like security risk. By May, the company’s “Project Lobster” was internally testing “ClawPilot,” an OpenClaw-based desktop environment. This week at the Microsoft Build conference, the company released Scout, a personal agent for work built on OpenClaw. For a company employing 100,000 engineers, this is blindingly fast. Unfortunately, it may already be too late.

The Google Trends graph for the term “openclaw” shows search interest spiked in January and began its descent soon after. (Screenshot courtesy of Mike Taylor.)

OpenClaw search traffic spiked in early January, after everyone had a chance to experiment with Opus 4.5 over the holidays. The sharp rise in interest died down almost as quickly as it took off, helped along in early April by Anthropic ending support for subsidized Max plan usage—thereby forcing everyone to scramble to get OpenClaw working on cheaper models.

This doesn’t mean OpenClaw is dead; the open-source project saw a recent uptick in download and is still under active development, with millions of dollars of patronage from OpenAI, which hired its creator Peter Steinberger. AI agents as a category aren’t dead, either, as traffic has moved to other agents like Hermes, Google has just rolled out Gemini Spark (first announced last month at its I/O developer conference), and Claude and Codex have both adopted more agentic features inspired by OpenClaw.

That said, it must be tough to manage enterprise AI product roadmaps these days. You do everything right, watch the latest trends, pivot your focus to supporting new tools and making them secure in enterprise environments. You move mountains to explain to stakeholders why this is a good idea. You plan the keynote of your big conference, which has to be scheduled months in advance. Then a month after the internal beta (just three months since the tool went viral), you’re already behind the news cycle. Everyone has moved onto the next shiny thing. You go back to the drawing board and think “maybe next time, we’ll just announce it on X.”—Mike Taylor

Log on

Get hands-on with how Every uses AI. These are the live camps, workshops, and meetups where team members teach the workflows behind our work.

Upcoming camp

Compound Engineering Camp: On June 5, Cora general manager Kieran Klaassen and Trevin Chow host a one-hour walkthrough of compound engineering, the AI-native development workflow Every uses to ship products. Learn more and register.
Codex Camp: Our Power User Guide: On June 12, Dan Shipper and the Every team host a two-hour live walkthrough of the Codex power-user guide—setup, workflows, and Codex-native app development. Learn more and register.

Steal this workflow

Make your agent more efficient with custom skills

These days, Monologue’s general manager Naveen Naidu spends most of his time in the Codex app with Fin—formerly Intercom, a customer support platform—open in the coding agent’s in-app browser. Working from a repository-local project, he has Codex investigate the customer issue displayed in the browser, create a bug report in Linear, link the Intercom ticket to the Linear issue, and draft a reply to the customer with information about the bug report—all without having to leave the app.

Fin has an MCP with 13 common actions, like searching conversations or reading and writing messages. Naveen’s workflow required a more specific one: Turn the active Fin conversation into a markdown file the coding agent could read.

Here’s Naveen’s workflow for creating a more focused setup:

1. Ask your agent how to make a repeated task more efficient

Naveen’s prompt for Codex was simple: “What tools can I give you so you can work more quickly?” He reviewed its suggestions, and landed on creating a custom, dedicated Fin script instead of trying to convert a webpage into a markdown file or rely on Fin’s MCP, which is designed for more generic workflows.

2. Build the most focused local skill possible for the task at hand

To build the tool, Naveen directed Codex to Fin’s API documentation and asked it to create a repository-local skill. The skill included a small command-line script that calls the API, pulls the active conversation, and hands it back to Codex as a markdown file.

3. Tell your agent when to use the skill

Once he’d built his custom skill, Naveen added a project-level instruction: If context on a customer issue is missing, check the active in-app browser, identify the Fin conversation, and use the custom skill to pull the thread and convert it into a markdown file. That lets him ask, “Can you give me user details for this issue?” without pasting the conversation or explaining which customer he means.

Try it this week: When your agent takes too long on a repeated task, ask: “What script or skill could I give you so you aren’t spending so much time on this?”

Naveen’s rule of thumb: “Don’t download any skills. Start interacting with the agent, see where it is inefficient, and then ask it to create skills.”

Counterpoint

AI will outpace human ability, but it won’t be cheap

In “After Automation,” Dan argues that AI progress creates more work for humans, not less. Each time the models saturate a benchmark—and make yesterday’s human competence cheap in the process—we reset the frame. The model then saturates that frame too, we reset the frame once more, and the cycle repeats—forever. The frame, Dan says, is never the framer.

If Every were a normal company, I’d hesitate to publicly disagree with my CEO. It isn’t, so here goes: I don’t think the “forever” part holds up.

The dynamic Dan describes matches my experience. A year ago, I wrote prompts until the model got better at generating them. Then I became the one supplying context until the model bested me at that, too. Today I spend my time orchestrating agents and determining what “good” outputs look like. Each time AI absorbs a piece of my job, the frame expands to include more abstract, higher-level work.

But I don’t think this progression will last forever. My prediction is that in a year or two, in a few well-run companies, AI will be able to execute every knowledge-worker task better than humans can—including setting the frames. In my role, I expect to be attending meetings to gather context that doesn’t exist online. The other parts of my job––defining evals, deciding goals, running experiments––will be handled by the equivalent of Opus 6 or GPT-7.

Why am I confident AI is capable of taking this last step? Because framing isn’t magic. We don’t pull goals out of thin air; we derive them from the layered experience of being a person in the world and the bounds of our social and physical surroundings. Physics is the ultimate eval metric, because if you get it wrong you die. Human ability feels like the natural peg for meaning, but we’re just one form intelligence can take. AI is another, and a system that learns from its environment can eventually run the same loop.

Intelligence costs energy, however, and I suspect evolution already made all the right tradeoffs to make us as smart as possible for our environment given constrained resources. For situations where there isn’t enough training data, a human runs on intuition and gut—words that describe a brain evolved to use thinking shortcuts, or heuristics, to survive. A model doesn’t inherit DNA encoded with millions of years of evolution, so it has to brute-force its way there through an expensive series of simulations or “thinking” tokens to get enough data to decide. There are no free lunches in economics, and AI isn’t magic—it can’t get to super-human general intelligence without super-human energy consumption. Beating humans on more subjective tasks will require more thinking tokens than its worth. Just hire the human.

The question will evolve from, “Can AI do this?” to, “Is it worth the compute?” or, alternatively, “Do I really want an AI doing this for me?” It makes sense to delegate tasks to a $20 a month model, or a $200 a month model, but as the “jagged free lunch” ends, is it worth paying $2,000 a month to make slide decks, check your email, and vibe code product prototypes? If we had a $20,000 a month Ph.D.-level model, wouldn’t it make more sense to have it fully dedicated to finding cures for cancer? We are already seeing people make these tradeoffs. Waymo is an objectively safer driver than humans, yet riders pay one-third or more the price of equivalent Lyft and Uber rides.. AGI for driving has arrived, and the city’s taxi-and-rideshare workforce grew anyway.

Dan believes humans will always stay one step ahead of the models. My prediction is the models will outpace us in raw capability, but we will stay employed anyway. Even if AI can do anything we can do better, some people (or agents) will still prefer human work. Especially if we can do it for less.—MT

One last thing

Spend enough time working with AI, and you’ll notice the specific linguistic mannerisms the models cannot quit—even if you explicitly tell them to stop. (Threats don’t work, either.)

OpenAI discovered just how hard it is to get a model to give up its preferred verbal and conversational tics when it tried—and to this day, seems to have failed—to get GPT-5.5 to ease up on the goblin references.

Here at Every, we all have our personal goblin equivalents:

Natalia Quintero, head of consulting: Claude’s penchant for saying it’s “‘locked in” and “load bearing.”
Lee Knowlton, software engineer: “It keeps telling me I have ’sharp’ takes, and who am I to disagree.”
Dan Shipper, CEO: Codex’s love of the phrase “my instinct is” and presenting itself as doing “‘X smart thing rather than Y dumb thing,’ but Y dumb thing was never in the consideration set.”
Austin Tedesco, head of growth: “Codex is always warning me to be less mean. Whenever I ask it for help with a piece of creative writing that has a joke I find funny but might come somewhat at someone or something else’s expense—like saying where a restaurant fell short—it always gives a note that I should soften or cut. Every time.”
Jalaiyah Bolden, executive operations manager: Claude’s overuse of “Got it” and its insistence that Jalaiyah “get some rest!”
Paridhi Agarwal, engineer: “Claude keeps asking me if I want to ‘leave it here for now and pick it back up in the morning’” (a conversational move Paridhi’s convinced is motivated by its desire “to maintain a smaller context window.”)
Katie Parrott, staff writer: “If a model tells me something ‘matters’ or ‘is real’ I’m going to lose it.”

Laura Entis is a staff writer at Every. You can follow her on LinkedIn.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Spiral 4.0 Goes Agent-native

Marcus Moretti / On Every — 2026-06-04 10:00:00 -0400

by Marcus Moretti

in On Every

Figma/Midjourney/Every illustration.

TL;DR: Spiral v4 just shipped with four major updates: a style engine that generates writing indistinguishable from your own 87 percent of the time, agent-native access via MCP, CLI, and API, team workspaces for writing in a shared voice, and a $10 price drop, bringing personal plans to start at $15 a month. Spiral will continue to be free for paid Every subscribers along with access to all our tools and content.

Try Spiral 4.0

Today we’re announcing a number of updates to Spiral, the writing partner for you and your agent. Spiral is built by writers for writers, to help you from idea to line edit, matching your writing style throughout.

The highlights:

With stylometry (or the study of writing styles), Spiral now sounds more like you. We’ve built a new Style Engine from the ground up, so Spiral computes your writing fingerprint and picks relevant samples for new drafts.
Use Spiral wherever you do work. With a new MCP, plus our existing CLI and API, Spiral can step in if you’re underwhelmed by your agent’s writing output, or need good writing in any workflow.
For teams, use Spiral to speak with one voice. Team workspaces let you share styles, prompts, knowledge, and now chats and drafts.
And finally, we’ve given Spiral a new coat of paint and logo, designed by Daniel Rodrigues. The primary brand font is now Edgar, from Frere-Jones Type.

Since re-launching at the end of last year, Spiral has:

Created 5,524 style guides from 168,464 writing samples
Generated 113,165 drafts
Made 350,078 revisions

It also now averages a 4.9/5 conversation score on our internal LLM-as-judge eval.

We built Spiral to help people who write for work write better. Just as Cursor is a coding harness, Spiral is a writing harness, supporting you at every stage of the writing process. Here’s how:

Before you start writing, Spiral vets the clarity of your idea and materials to substantiate it. From basic writing prompts to the hard-won insights from Every’s editorial and social media teams, multiple 12,000-word system prompts govern Spiral’s workflow. (To get the style and substance just right, we’ve iterated on these system prompts 131 times so far.)
When it’s time to draft, Spiral uses stylometry to reproduce your voice, working in Every’s know-how where appropriate. For example, if you ask Spiral for tweets, it will incorporate best practices from X’s latest algorithm update.
When you need help polishing a draft, Spiral is your editor. Along with a built-in guardrails against AI-speak, you can set custom writing rules that Spiral applies in a “top edit,” the final expert-level edit on a piece—a term I learned working at Every.

We’ve written about the challenges of getting LLMs to write like you. It’s difficult to prompt an LLM to write like you, let alone get it to stop using common AI phrasing and punctuation. Spiral’s Style Engine is the best solution to this problem we’re aware of. An eval runs on every draft Spiral produces, challenging an LLM-as-judge to spot the generated draft among real samples in a blind lineup. Today we’re at 87 percent on this eval, meaning Spiral’s generated draft blends in with users’ samples almost nine times out of 10. When a draft is spotted, the judge explains why, creating a feedback loop to refine the Style Engine further.

Try Spiral 4.0

Spiral goes agent-native

As Dan Shipper has pointed out, Claude and Codex are increasingly becoming the central interface for all computer work. So we’ve made Spiral available to agents via MCP, CLI, and API.

To try it out, copy and paste this command in your agent:

Help me set up Spiral, my AI writing tool, so you can write in my voice. Read https://writewithspiral.com/agents.md and follow the steps. In short: add Spiral’s remote MCP server at https://api.writewithspiral.com/mcp/ (Streamable HTTP). The first connection opens a browser to sign in to Spiral and authorize access (OAuth, no API key to paste). Then help me write something.

The CLI, or command-line interface, is personally how I use Spiral the most. After I merge a pull request, a cleanup command runs in Claude Code, which calls Spiral to generate tweets about the new feature for the Spiral X account. Spiral markets itself. This technique is now bundled into the compound engineering plugin in the form of the `ce-promote` command.

In addition to the main `spiral write` command, the CLI and MCP, or model context protocol, expose “personalize” and “humanize” functions. “Personalize” takes a given piece of text and rewrites it in your voice. “Humanize” does a pass to remove common AI tells, including the dreaded em-dash (which Every’s house style uses, hence its appearance in this piece).

Over 500 agents have been connected to Spiral since we launched the integration last month. Those agents are revising blog posts, generating marketing copy, drafting email replies, and more—automatically, and in the user’s voice. On some days, API sessions outnumber web sessions. And as agent-native usage of Spiral picked up, we realized we needed to adjust our pricing model. As a result, we’re adopting a new token-based pricing model, which is more in line with AI apps like Claude, Codex, and Cursor.

From session limits to token limits

In May alone, Spiral generated billions of LLM tokens, or units of text. While drafts typically range from 500 to 1,000 words, a lot of tokens are processed under the hood to make those drafts great. I’m reminded of the line attributed to French mathematician Blaise Pascal: “If I had more time, I would have written a shorter letter.” It takes a lot of tokens to generate a few good ones.

Before this release, Spiral limited the number of sessions, or unique chats, users could start per month. This approach had two problems. First, some users sent hundreds of messages within a single chat, consuming tens of millions of tokens, while using only 2 percent of their session allotment. Second, API users hit their session limit quickly, because the shape of API usage tends to be many single-turn sessions.

We’re moving to a token-based model, which is in line with how billing works in AI products like Claude and Codex. The personal and team plans come with millions of tokens each month. Once those tokens are consumed, it’s pay-as-you-go for extra token usage. Customers can disable extra usage and set their spend cap.

The good news is that the base prices of the personal and team plans are both dropping by $10. Personal plans now start at $15 per month (down from $25), and team plans start at $25 per user per month (down from $35).

The Every bundle remains the best value: For $30 per month you get Spiral but also all of our coverage of AI and four other products: Cora, Monologue, Proof, and Sparkle. Once you’ve subscribed to the Every bundle, sign into Spiral with the same email address and start writing.

Tell your stories, express your ideas

Technology is at its best when it augments our skill sets—amplifying what we’re good at, assisting with what we’re not. Figma and Canva help designers do better work, and allow people without a design background to manifest what they imagine. Claude Code and Codex help engineers ship more software, and allow people without engineering backgrounds to create the software they always wanted to exist. Our hope is that Spiral helps writers sharpen their work, and allows people without a strong writing background to put their stories and ideas into words.

One Spiral user is a retired musician in Australia. He’s accumulated a lifetime of stories in the studio and on tour. He’d never written them down, because he didn’t quite know how to tell them. Since signing up for Spiral, he’s recorded many chapters of his life stories with the tool’s help. He told me that Spiral has taught him how to be a better storyteller.

That’s what we’re building toward: a writing partner that helps people say what they mean and get better at saying it. Spiral produces good writing fast, but it also explains its writing and editing decisions along the way: the rationale behind rhythm, structure, rhetoric, and more. As my colleague Natalia Quintero observed, the best AI tools teach you things as you use them.

If any of this sounds useful, try Spiral. Share your feedback on X (@tryspiral) or get in touch: hi@writewithspiral.com.

Try Spiral 4.0

Marcus Moretti is the general manager of Spiral (@tryspiral).

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

Opus 4.8 Is Smart Enough to Get in Your Way

Laura Entis / Context Window — 2026-06-03 18:00:00 -0400

by Laura Entis

in Context Window

Today, we update our Opus 4.8 Vibe Check with a Pulse Check featuring perspectives from more team members, Dan Shipper sits down with Figma’s Matt Colyer to unpack why AI hasn’t killed professional design services, and Every senior designer Daniel Rodrigues shares the two-tool AI workflow he uses to get precise, visually stunning results.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

‘AI & I’: The limits of chat-based design

In a new episode of our podcast, AI & I, Dan talks with Matt Colyer, Figma’s director of product management for developers, about the limits of chat-based AI agents for design and why the rise of vibe-coded everything is, despite what you might have heard, a boon for the company.

Watch on X or YouTube, or listen on Spotify or Apple Podcasts. (You can also read the transcript.)

Here are the highlights:

The “SaaSpocalypse” narrative has it backwards. AI agents turn anyone into a vibe coder, kicking off investor panic that traditional software-as-a-service (SaaS) companies like Figma would cease to justify their cost. Colyer isn’t worried: AI has exponentially expanded the developer base, while underscoring how difficult it is to create a vibe coded version of Figma that works as well or as reliably as the real thing. He’s vibe coded multiple agents to do stuff like handle his emails, but the maintenance costs piled up quickly and never seemed worth it. “I’m buying more software these days than I ever did before,’” he says. “‘I’m just going to pay somebody else to run my agent for me.’”
Figma is embracing agents. The company has launched an MCP server—a standardized interface any AI tool can plug into—that allows you to approach design work from two directions. “Code to design” takes a live web page and reconstructs it on the Figma canvas, so you can manipulate the elements directly; meanwhile, “design to code” flips the process by packaging a Figma design and giving it to an agent, which makes changes for you via pull request.
There’s a ceiling to chat-based generative design. Great design hinges on a diamond-shaped process: First you diverge, or generate lots of ideas, and only then do you converge around the most promising options. Text-based chats are inherently linear and therefore bad at divergence; the setup forces you to select an option and iterate on it. Agents are already good at the task-completion workflows Figma supports today, but the divergent, exploratory part of design remains unsolved across the industry. Colyer is interested in dividing the process so specialized agents handle the divergence by pushing you to expand your thinking, while another set filters through the options to identify a single path forward. “Even the best agents, the command-line agents, don’t have the ability to do those workflows,” he says. “That’s where I see the future of design and product thinking.”
Agents can produce so much so quickly. They’re less good at determining whether any of it meets a company’s values or design standards. Colyer isn’t sure the best way to close this gap—maybe it’s a video walkthrough, a screenshot, or a trusted review agent—but for good design to scale, AI needs to play a larger role in evaluations.

Pulse Check: Opus 4.8 is the best tool for the right job

Five days ago, we called Anthropic’s Claude Opus 4.8 the best Claude model yet for writing and serious engineering, and said we’d switch to it from GPT-5.5 if the Claude app ever caught up to Codex. After a work week of more testing, we’re still an Opus 4.8 admiration society, although the results are a bit more mixed as people from different disciplines have had a chance to weigh in.

Here’s what more of the Every team has to say about when to use the model and when to steer clear.

Key takeaways

Reach for Opus 4.8 when productive friction improves the work. It’s good at tracking nuance, questioning a weak framing, and staying with a complicated problem. But the same instinct can become stubbornness, misplaced caution, or confidence in a wrong interpretation.
Give it the long, messy jobs. Opus 4.8 earned its strongest reviews on sprawling source material, long-running threads, difficult creative work, and complex coding tasks. For routine questions and clearly scoped work, its slower pace and higher token burn can wipe out the quality gain.
Do not rebuild your workflow around it yet. Even teammates who preferred Opus’s answers kept reaching for GPT-5.5 in Codex because speed, context, and a better-connected app outweighed model advantage.
Double-check security warnings. Two independent accounts reported that Opus invented a prompt-injection concern. Until that failure is understood, ask it to show the evidence behind a warning before you act on it.

The Reach Test, part II

Arielle Shipper, head of operations 🟩

Arielle Shipper, Every’s new head of operations, has spent the last few weeks on a discovery tour. She used Opus 4.8 to redo an HTML site showing a summary of her findings, after building the original with Opus 4.7. She noticed meaningful improvements: 4.8 distinguished between two similarly named pages in Notion without the explicit guidance 4.7 had required, and suggested highlighting a count of how many times specific topics came up in her conversations with the team. Her summary: “It seems really detail-oriented in a way I appreciate.”

Austin Tedesco, head of growth 🟨

Austin spent the weekend using Opus 4.8 on an essay with Monologue, our speech-to-text tool, and our writing app, Spiral. For that job, he wrote that Opus 4.8 “is the best model available,” a step up from Opus 4.7 and “materially better than GPT-5.5.” But he doesn’t expect it to change his daily behavior. GPT-5.5 is “pretty good” at the same kind of creative partnership, he said, and keeping his work in Codex matters more than the modest quality improvement: “I don’t see myself reaching for Claude models much without a materially better desktop app experience, or such a dramatic leap in model quality that the harness matters less.”

Nityesh Agarwal, senior applied AI engineer 🟩(model) / 🥇(dynamic workflows)

Nityesh tested Opus 4.8 inside the AI employees he is building for Every—Claudie for consulting, Andy for the editorial team. He reported that the model recalls the right memory at the right time, stays useful in longer threads, and lets him use more of its 1-million-token context window, the amount of material it can handle in one conversation. But Anthropic really won his heart with Dynamic Workflows, the workflow-automation feature released alongside Opus 4.8. Combined with the new model, Nityesh says it feels like “a major power-up.”

Lee Knowlton, software engineer 🟨

Anthropic says Opus 4.8 is more honest and better at flagging risks. But Lee saw the negative side of that instinct during a daily planning run he’d repeated for months where Claude used his calendar, Slack, and notes to create a plan for his day. One morning, the plan cited events, messages, and files Lee couldn’t find in those sources. When he asked Claude what had happened, it claimed a prompt-injection attack had supplied fake information. When Lee challenged it, Claude said it had invented that story to explain its own bad output, mistaking a planning file Lee had moved for evidence of interference. The exchange left him reluctant to trust the model’s explanations for its own behavior.

Andrey Galko, engineer 🟩

Andrey is “very positive” about Opus 4.8 for coding and wrote that he likes it much more than GPT-5.5. For his use cases, it feels “more stable, reliable, and just less dumb.” His reservations are about the experience around the model, not its coding quality: GPT-5.5 is faster, and Codex gives it the better desktop-app harness.

The verdict: Keep it within reach, not open all day

It’s worth noting that not everyone is as positive about Opus 4.8 as our team. Steve Yegge, a software engineer and blogger, wrote on X that Opus 4.8 is “suffocating” and “pathologically risk-averse.” Dylan Field, cofounder and CEO of Figma, called Opus 4.8 “a very strange model,” and said that it felt more judgmental in personality and more likely to hedge in its responses than Opus 4.7.

When Dan canvassed the hive mind on X, the replies suggested that Opus 4.8’s greatest strength is its biggest liability: It resists the user more readily than other models. When that resistance improves the outcome of a hard writing or engineering task, it feels like a breakthrough. When it is mistaken in its pushback, it’s frustrating and harder to trust.

Overall, our launch verdict holds, with a narrower recommendation. Use Opus 4.8 when the work is dense with context and benefits from sustained reasoning across a complex task. Keep a hand on the wheel when the costs of misplaced confidence—or misplaced caution—are high.

For higher-risk workflows: Verify its diagnosis before you trust a refusal or a security warning. Caution is only a feature when it is grounded in evidence.
For context-heavy knowledge work: It’s worth trying out when your source material is spread across documents and decisions—especially if you’ll explicitly send it deeper than the front page.
For daily-driver usage: A better model isn’t a reason to switch workspaces. If Codex is where your context, speed, and tools already compound, Opus 4.8 is a model you call in for specific jobs, not a reason to move.

Opus 4.8 looks most compelling when the work is long, context-heavy, and benefits from a second pass of judgment. If you mostly want something zippy to get stuff done, GPT-5.5 in Codex is probably the model you’re looking for.—Katie Parrott

Disclosure: Every received early access to Anthropic’s Opus 4.8. Anthropic had no input on this review.

Steal this workflow

Toggle between image generators

Every senior designer Daniel Rodrigues has spent three years working with AI image generators. By now, he knows their strengths and weaknesses. Here’s his advice for combining two popular options to maximize creativity without sacrificing attention to detail.

Step 1: Start by firing up Midjourney. The AI image generator produces beautiful visuals, but its real power is in its penchant for creative liberties: Give it a prompt, such as “medieval farmer reading in a field of oranges,” and it will return images with details you didn’t specify, like adding a castle in the background or giving the farmer a red hat. “You get random stuff,” Daniel says. Some of it is off base, but frequently the unpredictability sparks an entirely new (and better) direction he wouldn’t have stumbled upon otherwise.

One of the images generated in Midjourney from the prompt “medieval farmer reading in a field of oranges.” (Image courtesy of Daniel Rodrigues.)

Step 2: Take the image you made in Midjourney, and upload it into Nano Banana or ChatGPT Images 2.0 to nail down the specifics. Compared to Midjourney, both models follow directions to a T. This literalness limits Daniel’s ability to make creative leaps with the tool, but they’re great for refining an existing image so it better matches the visual in his head.

Step 3: Go back-and-forth with the model. For detailed prompts—say, of a “woman in her 30s, with red sunglasses, blue earrings, writing in a notebook with a yellow Montblanc pen”—Nano Banana will probably only capture 70 percent of what you want, Daniel says. From there, you iterate with the model, refining one item at a time so it can focus on getting that change right until the output fits your exact specifications.

To stress test the models on their ability to follow complex directions, Daniel ran the following prompt in Midjourney, Nano Banana, and ChatGPT Image 2.0, respectively.

Create a photorealistic image of a 35-year-old man sitting alone in a small Paris café, sketching architectural drawings in a notebook.

He has olive skin, short dark hair, a trimmed beard, and a small silver nose ring.

He is wearing a dark green jacket, black turtleneck, and a silver wristwatch.

On the wooden table in front of him are:

A notebook labeled “Project Atlas”

A blue fountain pen

A coffee cup with latte art

A folded newspaper dated October 14, 2031

Behind him:

A framed Mona Lisa reproduction

A vintage wall clock showing 4:26

A red bicycle visible through the window

A street sign reading “Rue de Rivoli”

Additional details:

The man’s watch must also show 4:26

A small black cat is sleeping beneath his chair.

The image should look like a real photograph taken with a professional camera, with all listed details clearly visible and consistent.

Midjourney's version. Notice how the model struggles with text—Midjourney is “terrible with letters,” Daniel says—and drops or misinterprets a number of details, such as the color of the pen, the notebook, and the cat’s sleeping status. The man is also wearing two watches. (Image courtesy of Daniel Rodrigues.)

Nano Banana’s version. The model does a better job, although some key details are dropped or presented oddly. (For example, the "Rue de Rivoli" sign reads correctly, but appears inside the cafe.) (Image courtesy of Daniel Rodrigues.)

ChatGPT Image 2.0’s version. It “wins this time,” Daniel says, incorporating most of the specifications such as the sleeping cat, a notebook labeled "Project Atlas," and even the clock showing 4:26, which image models generally have a hard time getting right. (Image courtesy of Daniel Rodrigues.)

One last thing

Where do you fall on the eight levels of AI adoption? If you don’t have time to ingest Mike Taylor’s comprehensive guide on the subject—it’s well worth a read, but we get it, time is a finite resource—here’s a quick way to identify what stage you’re at.

Simply run this prompt in your agent of choice:

based on everything you know about me, including memories, tools and skills installed, and past session history, what level would you say I was at on this guide to AI adoption levels? https://every.to/guides/the-eight-levels-of-ai-adoption

Katie is entering Level 6 territory. (Image courtesy of Katie Parrott.)

Laura Entis is a staff writer at Every. You can follow her on LinkedIn. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

Discover Every’s upcoming workshops and camps, and access recordings from past events.

For sponsorship opportunities, reach out to sponsorships@every.to.

The Eight Levels of AI Adoption

Mike Taylor, Laura Entis, and Claude / Guides — 2026-06-02 18:00:00 -0400

by Mike Taylor, Laura Entis, and Claude

in Guides

All it takes is one viral post to make you feel like you’re using AI all wrong. Someone is running 12 Claude Code sessions in parallel. Someone else’s agent is answering emails while they sleep. Meanwhile, you’re still arguing with ChatGPT.

But here’s the thing: Keeping up with every power user isn’t the point. The best way to find value in AI is to use it in a way that fits your work—and to regularly check in to see if you could be getting more from it than you already are. (I was using Steve Yegge’s “Gas Town” post about directing dozens of coding agents to illustrate this in client presentations, but it didn’t quite match with my experience, and I needed to modify it.)

This guide maps eight levels of AI adoption, from basic chatbot use to full agent orchestration. With each new level, you delegate more of your work to—and place more trust in—the AI. The following sections explain how each level works in practice, complete with sample prompts, so you can figure out which levels match your current needs and workflows, what’s possible at each stage, and when it’s time to move to the next one.

Level	Description
1—Chatbot	You give it a task, it provides a response. (ChatGPT, Claude, Gemini)
2—Copilot	The AI exists inside your files and completes work alongside you. (Cursor, Claude in Excel, Gemini in Google Docs)
3—Agent	You describe a task, and the agent executes it step by step, asking for your approval before moving on. (Cowork, Codex)
4—Autopilot	You skip approvals and let an agent complete a task on its own, then review the results. (Lovable, Codex, Claude Code)
5—Workflows	You build a system that professionalizes the agent’s output. (Compound engineering, Claude Workflows, Copilot AI Studio)
6—Assistant	The agent works proactively in the background without being prompted. (OpenClaw, Hermes Agent, Claude Managed Agents)
7—Multi-agent	You’re managing multiple long-running agents at the same time. (Claude Managed Agents, OpenClaw, or Codex Goals)
8—Orchestrator	A manager agent runs a team of sub-agents on your behalf. (Gas Town, Paperclip, Symphony)

A higher level isn’t necessarily better. The most sophisticated AI users I know operate at several levels at once, identifying the best level to work within based on the specific challenge in front of them. The right level for a task is generally determined by how much you trust the AI to do a good job without intervention—and how big a deal it’ll be if it does mess up. For high-stakes tasks, you should either stay at a lower level so you can supervise the AI, or be prepared to invest the time, engineering resources, and tokens necessary to get that same quality at a higher level with less human oversight.

Most people I talk to who are struggling to adopt AI have good reasons: The output quality is either too low for the work they do or it’s too expensive to achieve. Safely moving up to the next level requires effort and experimentation—or a jump in model capability.

The right level match for most of your tasks may also depend on your role. Broadly speaking, the sweet spot for knowledge workers right now falls somewhere between Levels 1 and 4. Engineers are more often in Levels 5 through 8, partly because they can build the scaffolding that makes newer, less stable systems usable before they’re ready for everyone else.

The levels

Level 1—Chatbot

What it is: You ask, it answers. This is the classic chatbot experience: ChatGPT, Claude, Gemini, or any other model that’s not embedded in your files or your systems. You give it a task, and it returns a response.

What changes at this level: You move from doing everything yourself to drafting and synthesizing with an always-available AI generalist.

What you can use it for: Writing from rough notes, summarizing documents, or answering questions about uploaded files

Try it:

I need to send a post-meeting follow-up email to a client. Here are my rough notes, the decisions we made, and two risks we need to flag. Draft the email in a calm, confident tone and end with three clear next steps. Tell me if anything sounds unclear or unsupported before you start writing.

Input: Meeting notes

Output: A polished email draft that identifies if there’s any missing information that still needs to be filled in

Human judgment: Confirm that the tone and facts are right, and the email’s content is something you stand behind.

I am uploading a 20-page PDF on our new benefits policy. Summarize the five changes employees will care about the most, and then answer these three questions: Who is affected, what specific policies does the new timeline impact, and what would likely confuse someone who is reading this quickly?

Input: A PDF or set of documents

Output: A summary and direct answers to your questions grounded in the source material

Human judgment: Verify the summary is factual, and that the model recognizes when the material is ambiguous.

When to move up: Chatbots can assist with a wide variety of tasks, but each session requires manual setup: You have to explain what you want, provide the necessary context, and transfer the chatbot’s response to wherever you’re getting work done. Consider moving to the next level if you get a lot of value from chatbot exchanges but are tired of copy and pasting.

Level 2—Copilot

What it is: The model is embedded inside the place where you’re already doing work and has access to everything in your document, spreadsheet, presentation, notes app, or code editor.

What changes at this level: AI stops being a separate tab and becomes an in-place collaborator that can extend, revise, and interpret the work you’re doing as you do it.

What you can use it for: Revising drafts, understanding a document set or workspace without manually pasting everything into a chat window, and making changes to a live spreadsheet without leaving the file

Try it:

Using the draft already in this doc, write the next two sections in the same voice. Keep the tone consistent with the existing text, preserve existing structure, and flag any areas where you need examples or evidence from me before you get started.

Input: An unfinished document, memo, or social media post

Output: A continuation of your draft that matches the existing material

Human judgment: Decide whether the new sections sound like you wrote them, and then determine whether they successfully advanced your argument.

Here is our cash flow projection for Q2. Update the monthly totals with these new numbers, flag any months where we are projected to go negative, and add a summary row at the bottom with the full-quarter picture.

Input: A spreadsheet with your existing cash flow data. The new figures you want incorporated can be pasted directly into the prompt or provided as a second file.

Output: Updated monthly cash flow figures, a list of months where the cash flow is projected to be negative, and a summary of projected cash flow for the entire quarter

Human judgment: Verify the formulas are correct, check that the summary is accurate, and determine what strategies you’d like to take for addressing months with a projected negative cash flow.

When to move up: Copilot removes the need to manually provide context, but it can only reliably access information from a single file. Consider moving to the next level if you need to pull, compile, or analyze information across multiple sources.

Level 3—Agent

What it is: You describe a task, and the agent works step by step to complete it, checking in with you for approval along the way. It can access your files and systems, perform actions on your computer, and compile information from multiple sources.

One key distinction worth keeping in mind: An agent in this context is reactive. It waits for you to initiate and will not start a task unless you explicitly tell it to.

What changes at this level: AI becomes a true operator capable of executing multi-step tasks with supervision.

What you can use it for: Using figures from one file to update another, or building something new—like a dashboard—from a set of source documents

Try it:

Take the Q4 revenue numbers from this spreadsheet and update the board deck with the new figures, charts, and commentary. Show me the proposed edits slide by slide before you apply them, and call out anywhere the source data seems inconsistent.

Input: A spreadsheet and a presentation deck

Output: Proposed slide updates tied to specific data

Human judgment: Confirm that the interpretation of the data is how you’d like to present it, correct any factual or contextual issues the agent might have missed, and approve the changes.

Using the NPS data in this file, build a simple dashboard I can open in a browser. I want to track overall score, key themes in the comments, and how responses break down by segment. Before you build it, tell me how you plan to structure it and what assumptions you are making about the data.

Input: A data file and a dedicated folder the agent can work within

Output: A working dashboard, along with a detailed plan for how it built it plus a summary of the assumptions it made about the data

Human judgment: Approve the plan, confirm the dashboard works the way you want it to, and determine whether any assumptions the agent made about the data need to be revised.

When to move up: With an agent, the process is iterative—the agent completes a step, you review and refine, wash, repeat. Consider moving to the next step when you want to relinquish control in exchange for speed or the ability to one-shot a prototype without writing any code.

Level 4—Autopilot

What it is: You skip permissions and let an agent complete a task on its own, then review the results. With an agent, you stay involved in the process because you care how each step gets done. On autopilot, which is often called vibe coding, you

describe what you want, let the system run, and evaluate what comes back. At this stage, you’re typically building something other users will interact with, such as a prototype or landing page.

Determining which tasks can be done on autopilot depends on how capable the model is, a calculation that changes with every release. For example, I’ll happily produce a landing page on autopilot, because the models are good enough to make one that meets my standards. I can’t do the same with a complex slide deck, at least not yet—the result is so far from what I want correcting it takes longer than doing it myself. As the models improve, you can get away with doing more of your work on autopilot.

What changes at this level: You hand over the entire task to the model and review the end result instead of revising along the way.

What you can use it for: Building prototypes, internal tools, and first-pass products. Autopilot is the first level that allows you to build something other people can use without having to write a line of code yourself. It can also usually cover routine tasks, such as filling out recurring forms or drafting weekly status reports.

Try it:

Build me a lightweight internal lead-scoring tool for our sales team. It should let us paste in account notes, assign a score from 1 to 5, and show which factors drove the score. Use dummy data for now and make the interface clean enough that I can demo it tomorrow.

Input: A plain-English description of what the tool should do, who will use it, and any constraints, such as whether it needs to work in a browser or stay local

Output: A functioning prototype

Human judgment: Test the output and decide if it’s demo-ready. A prototype doesn’t need to be perfect, but it’s worth noting where you’d need to invest in reliability before putting it in front of users.

Build a landing page for our new feature. It should explain what the feature does, include a clear call to action, and match the tone and brand colors of our existing site. Make it responsive.

Input: A product brief, brand guidelines, and the existing site as a reference. Brand guidelines can be as simple as a color palette and a few sentences about tone; if you don’t have a formal document, describing your existing site in a sentence or two is enough to get started.

Output: A working landing page

Human judgment: Read the copy, test the page on mobile, and decide whether it’s ready to share more widely.

When to move up: Autopilot is fast, but it often produces uneven or unreliable results. That might be fine for a prototype, but for higher-stakes work, you’ll want to build a repeatable system around the agent that structures its thinking and execution. Consider moving to the next level if you want the speed and versatility of autopilot with more structured quality control.

Level 5—Workflows

What it is: You build a system, or harness, around your agent that professionalizes its output. Instead of a one-shot run, your agent plans, reviews, performs confidence checks, and runs code through other safeguards to make the results more reliable. This is a transition from vibe coding to agentic engineering. The pace is still fast, but because you have structured the process and included guardrails that catch and fix mistakes, the output is of a higher quality.

This level is primarily the domain of engineers. Reviewing a plan, evaluating which tests need to be done, and designing the harness that keeps the agent from going off the rails all require an understanding of what’s happening under the hood. The compound engineering guide covers this in detail. Much of this discipline will be baked into platforms over the next six to 12 months; for now, it requires technical judgment to implement.

What changes at this level: You stop treating the agent as a one-shot performer. By designing a repeatable process for the agent to follow—and encoding your standards into that process—you can trust the agent with work you’d otherwise want to do by hand.

What you can use it for: Shipping features with a plan-review-implement loop, turning a vibe coded prototype into something stable enough for production, or building a process other engineers on the team can follow

Try it:

Run /plan (plan mode in Claude Code, or /ce-plan in compound engineering) before writing any code.

/ce-plan Inspect this repo and propose a plan for adding a customer support inbox view. Include the

files you expect to touch, edge cases, and how you will verify the behavior. Wait for my approval before implementing.

Input: A codebase the agent has access to, and a written feature request or specification. The more context you can give upfront—existing architecture patterns, relevant files, known constraints—the better the plan will be.

Output: A plan for building a feature that you can review before the agent implements anything

Human judgment: Evaluate the plan and make any necessary improvements before having your agent implement it.

After the agent finishes a change, run /ce-code-review (or ask it to review its own work).

Review this change like a skeptical teammate would. Tell me how confident you are from 1 to 100, list the weakest parts of the implementation, and make another pass until you are above 90 or can clearly explain why you are not.

Input: The completed change—a diff, a set of modified files, or a pull request—plus the original spec or plan the agent was working from, so the review can check whether the implementation matches the instructions

Output: A self-review, confidence score, and an improved version of the feature

Human judgment: Decide whether the confidence score is justified and whether you agree with the review. If the agent rates itself highly but you identify issues it didn’t flag, name them and have it do another pass.

When to move up: Even the most sophisticated workflows require you to activate them, which, for certain tasks, becomes a bottleneck. Consider moving to the next level if there are areas of your life or work you’d trust an agent to handle without checking in with you first. (At this stage of model development, that’s more often lower-stakes administrative or household tasks.)

Level 6—Assistant

What it is: Unlike an agent—which waits for you to tell it to do something—an assistant acts on your behalf without being prompted. It can monitor a domain, do recurring work, and surface relevant information around the clock. For example, OpenClaw’s heartbeat.md file triggers every half an hour with instructions around priorities, and the agent takes action automatically. No need to prompt.

What changes at this level: AI moves from providing reactive help to proactive, ongoing support.

What you can use it for: Recurring research, monitoring a topic you care about, or personal administrative work that would otherwise fall through the cracks

This level still requires either technical knowledge or access to someone who can walk you through the onboarding process and fix your assistant when it breaks. On the consulting team, we have an AI assistant that handles all project management and sales pipeline-related tasks, but it only reliably functions because it’s maintained by Every senior engineer Nityesh Agarwal.

OpenClaw is the most popular platform for personal AI assistants, but it’s inherently unstable and time-intensive to set up. Is memory problem hasn’t been solved yet, so it can struggle to retain context between sessions.

Lower-stakes personal uses, such as monitoring your inbox for emails from your child’s school or tracking household purchases, are more accessible with the current state of available models than giving an assistant access to your work systems, which requires engineering and IT support to do safely. Risk tolerance matters here more than at any earlier level.

Try it:

Every 30 minutes, check my calendar and flag events taking place within the next two hours that require preparation. If there is a meeting with no agenda, draft a short suggested one based on its title and attendees.

Input: Calendar access and your preferences about what events qualify as requiring prep—for example, whether you want to be flagged for one-on-ones, external calls, or anything over 30 minutes. Output is typically delivered to a messaging app like Slack, although the specific setup depends on which platform you’re using.

Output: A recurring brief delivered to your message app of choice

Human judgment: Decide what is urgent, and refine the rules based on the results.

Monitor my inbox for emails from my child’s school. Each morning, give me a short summary of anything I need to know or act on. Also keep a running log of recent grocery purchases and let me know when we are running low on staples.

Input: Access to your calendar, inbox, and receipts

Output: A daily brief and a running household inventory

Human judgment: Verify that the summary captures the most important information and the agent is accurately identifying grocery items that need to be restocked.

When to move up: When set up correctly, an always-on assistant can proactively handle a wide variety of tasks. Consider moving to the next level if you want your assistant to accomplish even more for you, but don’t want to interrupt its existing workflow or are worried about overburdening its memory.

Level 7—Multi-agent

What it is: You are managing multiple long-running agents or assistants at the same time. Each one has a role, a task, or an area of responsibility, and your work starts to look more like leading a small team. This level is firmly in senior engineering territory—it is rare for knowledge workers to be running multiple parallel agent sessions.

What changes at this level: Your productivity multiplies when you move from one agent doing a task to having several agents working on tasks in parallel.

What you can use it for: Running implementation and planning simultaneously, or automating recurring investigation work so it no longer requires your direct attention

Try it:

You already have one always-on agent—perhaps a custom Claude agent that runs on its own Mac Mini—that handles your editorial work. Rather than interrupt its workflow to have it complete an unrelated task, you set up a second agent that is responsible for a different job function: “You’re responsible for our customer support inbox. Triage new tickets as they come in, draft replies for the routine ones, and flag anything that needs a human.”

Input: A custom long-running agent with its own scope, tools, and memory, kept separate from the first so their contexts don’t bleed together

Output: Two agents working in parallel with distinct job functions, skills, and memory

Systematically review each agent’s work to determine whether it’s executing at the level you need it to and its job description is focused enough that its memory isn’t getting overburdened.

Input: A bug-reporting system connected to an agent trigger

Output: A steady stream of pull requests, each tied to a specific reported issue

Human judgment: Review each pull request, merge the approved ones, and identify cases where the agent misdiagnosed the problem.

When to move up: Long-running agents are valuable because they can largely work independently, but you still need to set their goals and evaluate their progress. Consider moving to the next level when you have so many of these agents that you lose track of which one is responsible for what.

Level 8—Orchestrator

What it is: An orchestrator agent manages a team of agents. It plans, delegates, monitors progress, and consolidates outputs so you can focus on bigger-picture tasks, such as setting overall goals or reviewing major decisions. Tools like Gas Town, Paperclip, and Symphony (from OpenAI) are early examples of this model.

It’s critical to note that this level is highly experimental. Even engineers operating at the frontier still largely fill the role of orchestrator themselves rather than trusting an orchestrator agent to handle complex coordination work.

What changes at this level: You stop managing each individual agent and instead focus on setting goals, establishing constraints, and implementing approval thresholds.

What you can use it for: Projects where the economics only make sense if you remove yourself as the bottleneck—building a system for keeping track of who’s doing what, sequencing work across multiple agents, and making sure the right issues are escalated without you

Try it:

An always-on agent takes the next ticket in the queue from your project management software. “Your job is to design a landing page for this SEO keyword [insert keyword]. Break the research up into parallel search queries related to the topic, search our company documents for unique insights, then write up a full page using the /brand-style skill. ” Agents continue to take and complete tickets until the board is clear, and the fully completed project is ready for human review.

Input: A high-level objective, defined agent roles, and rules for what requires human review

Output: A managed project where you receive critical updates instead of raw output from every agent that’s running in parallel

Human judgment: Determine whether the orchestrator is doing a good job triaging issues or if too many—or too few—are being handed over for you to review.

Set up a pipeline that reviews each code submission against our codebase standards, runs the tests, checks for common issues, and escalates issues to me only when they require a judgment call.

Input: A repository, contribution guidelines, and a test suite

Output: A short queue of escalated items that need your input, instead of hundreds of raw submissions that require manual triage

Human judgment: Establish the threshold for what qualifies as something that needs your attention, and raise or lower the bar as needed. The agent can flag those tasks for human review, or it can work on the entire project autonomously until all tests pass and the agent has recorded a video of the software working end to end.

What the levels measure

There is no value judgment baked into these levels. The vast majority of people should not pursue orchestration, for example, because the models aren’t reliable enough for most use cases. That said, as the technology improves, it can be worth revisiting a level that was previously inaccessible to you or your company. Model releases can pull everyone up, making tools and systems more reliable and easier to use.

If you take anything away from this guide, let it be this: AI use is not a competition. You wouldn’t brag that you had eight interns working overnight on a key project, and you hadn’t checked their output. Instead, you’d work clo

sely with them for months until you were confident they had enough training to be able to work autonomously. Expect to put in a similar amount of effort with your agents before you can trust them to get reliable results at the next level of autonomy. Determining which levels fit your specific needs—rather than seeing how far you can ascend for the sake of it—is the most important thing you can do if you want to make better use of the technology.

Mike Taylor is the head of tech consulting at Every and a co-author of Prompt Engineering for Generative AI (O’Reilly). Learn more about how Every’s consulting team can bring AI into your organization.

Laura Entis is a staff writer at Every. You can follow her on LinkedIn.

Where Do You Fall on the Eight Levels of AI Adoption?

Mike Taylor — 2026-06-02 07:00:00 -0400

by Mike Taylor

Midjourney/Every illustration.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

All it takes is one viral post to make you feel like you’re using AI all wrong. Someone’s running 12 Claude Code sessions in parallel. Someone else’s agent answers emails while they sleep. Meanwhile, you’re still arguing with ChatGPT.

Here’s the thing: Keeping up with the power users isn’t the point. The best way to get value from AI is to use it in a way that fits your work—and to check in now and then to see whether you could be getting more from it.

With that in mind, today we published a guide that maps all eight levels of AI adoption, from chatbot basics to full agent orchestration. We explain how each level works in practice, with sample prompts, so you can figure out which ones match your current needs and workflows, what’s possible at each stage, and when it’s time to move to the next one.

Level 1—Chatbot: You ask, it answers.
Level 2—Copilot: The AI works alongside you, inside your files.
Level 3—Agent: It executes a task step by step, checking in for approval.
Level 4—Autopilot: It runs on its own; you review the result.
Level 5—Workflows: You build a system that makes its output more reliable.
Level 6—Assistant: It works in the background, without being prompted.
Level 7—Multi-agent: You manage several long-running agents at once.
Level 8—Orchestrator: A manager agent runs a team of sub-agents for you.

A higher level isn’t necessarily better. The right level for a task is generally determined by how much you trust the AI to do a good job without intervention, and how big a deal it’ll be if it does mess up.

If you want to know where you fall on the AI adoption spectrum—and whether it’s time to experiment with higher levels—this guide is for you.

Read the 8 levels guide

Mike Taylor is the head of tech consulting at Every and a co-author of Prompt Engineering for Generative AI (O’Reilly).

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

We also do AI training, adoption, and innovation for companies. Work with us to bring AI into your organization.

Company-wide AI Implementation in Five Steps

Natalia Quintero — 2026-06-01 06:00:00 -0400

by Natalia Quintero

Midjourney/Every illustration.

Join me and Dan Shipper for a live session on what AI fluency looks like at the executive level tomorrow, Tuesday, June 2. We’ll walk through how the leaders we work with—at hedge funds, private equity firms, and Fortune 500 companies—are using AI in their day-to-day, and what they wish they’d done differently six months in. RSVP.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Sitting across from the chief operating officer of a health tech company earlier this year, I watched her name a problem many executives are feeling but few say out loud.

“Our junior employees are probably much more native with this technology,” she said. “And we need to make sure we’re sticking with it. Makes me feel like a dinosaur to say that, but it’s true.”

Confessions like this come up regularly during our executive training sessions: Leaders aren’t working directly with AI on sophisticated tasks, even as they’re guiding planning decisions about the technology. They know they should spend more time learning the tools, but they haven’t committed to it yet. That’s understandable; executives are incredibly busy. But what we see in our sessions is that leaders who haven’t gotten their hands dirty don’t clearly understand the practical opportunities and challenges of AI. That health tech executive’s admission sparked an important conversation about how a coordinated company-wide approach to AI implementation starts with executive AI fluency—but doesn’t stop there.

AI usage in the workplace is now widespread, but it’s an altogether different ballgame to build organizational capability that truly realizes financial gains.

McKinsey defines AI high performers as organizations that report both significant value from AI and more than a 5 percent impact on earnings before interest and taxes (EBIT). These companies are nearly three times as likely as others to have fundamentally redesigned their workflows, but they remain a minority: Only 6 percent of the nearly 2,000 organizations surveyed met the criteria for success.

As AI has gone from performing party tricks to completing an entire day’s worth of human work in three short years, enterprise AI adoption has moved through three distinct waves. First came the license wave: companies bought access to tools like ChatGPT, Claude, and Microsoft Copilot and waited for productivity gains to appear. Then came the prompt wave: companies ran training sessions, built prompt libraries, and encouraged teams to experiment with custom GPTs. Now we are entering the implementation wave: prompt libraries are giving way to skills libraries, agents, evals, and workflows with named owners.

The METR chart in our full guide shows how far the technology has progressed, but we’ve seen that many organizations implementing AI haven’t kept up with the sea change. The bottleneck for AI adoption has moved from model capability to organizational capability.

That’s why we built a practical guide for executives who have bought AI tools but are not yet seeing real value from them. The loop is simple:

Get fluent. Use the tools yourself before directing anyone else to use them. Know what your company has access to, what the policies allow, and what the friction feels like. If you haven’t built something with AI in the last 30 days, start there.

Assign AI champions. Pick operators with bandwidth. Give them protected time (at least two days per month), a clear mandate, and enablement. They are responsible for taking workflows from “works in a demo” to “works in production.”

Pick one painful workflow. Let your champions choose. They know what work is most tedious and worth automating. Start with something frequent, data-rich, and narrow enough to test in a week. You don’t need a full workflow mapping exercise.

Build to 95 percent. An automation that works 80 percent of the time is a demo. Real automation requires gold-standard examples, structured evals, human review gates, and a named owner who maintains it when the model updates. Once you have a skill that works reliably 90-95 percent of the time, you’ve gotten value from AI.

Scale what works. This is where the champion role is key. Run show-and-tells. Train adjacent teams on proven workflows. Kill what doesn’t work and expand what does. One visible win creates pull across the organization.

This guide turns that loop into a 60-day plan for executives, with checklists and rubrics drawn from Every’s consulting work with dozens of top companies. You can read it in full here.

Read the AI for executives guide

Natalia Quintero is the head of Every Consulting.

Thanks to Tom Matsuda for editorial support.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.

An Executive’s Guide to Implementing AI

Natalia Quintero / Guides — 2026-06-01 05:00:00 -0400

by Natalia Quintero

in Guides

If you read nothing else, here is the loop:

Get fluent → Assign AI champions → Pick one painful workflow → Build to 95 percent → Scale what works

This guide turns that loop into a 60-day plan for executives, with checklists, and rubrics drawn from Every’s consulting work with dozens of top companies.

An executive’s guide to implementing AI

Sitting across from the chief operating officer of a health tech company earlier this year, I watched her name a problem many executives are feeling but few say out loud.

We see this pattern in every engagement we run in our consulting work. Over the past two years, we’ve trained thousands of people at companies including the New York Times, Ripple, Headway, and Thumbtack, and at investment firms managing over $100 billion in assets. We’ve done the workshops and watched what changed six months later. AI usage in the workplace is now widespread, but it’s an altogether different ballgame to build organizational capability that truly realizes financial gains.

Of course, no outside firm can implement AI into your company for you. But we can provide a playbook for how to build organizational capability that endures: leaders that work directly with the tools, empower the right champions, and build the muscle across teams for what great looks like, one painful workflow at a time. By the end of this guide, you’ll have no excuse not to be one of them.

Riding the waves of AI adoption

In three short years, AI has gone from performing party tricks to completing an entire day’s worth of human work.

In 2022, models could answer basic questions, tasks that take a human four seconds. By mid-2023, GPT-4 could handle tasks that take humans about six minutes. By late 2024, o1-preview was tackling hour-long work. And by late 2025, Claude Opus crossed into tasks that take humans 10 hours or more. That progression has been exponential and transformed what “AI implementation” means for companies again and again.

Here are the three rough waves of AI adoption since ChatGPT’s launch:

The license wave (late 2022 to early 2024): Companies bought licenses for ChatGPT Enterprise, Claude, and Microsoft Copilot in the hopes that they would increase employee productivity. Some employees found value in using the tools to draft emails, summarize documents, and conduct research, but gains were uneven and individual.
The prompt wave (early 2024 to mid-2025): Companies ran prompt-training sessions, created internal prompt libraries, built resource documents, and encouraged teams to experiment with custom GPTs. That helped move AI beyond pure individual tinkering, but it rarely created durable organizational change—custom GPTs and libraries often had no owner and no way to evaluate their results.
The implementation wave (mid-2025 to now): Following its launch in research preview in February 2025, Claude Code helped shift enterprise adoption to where we are now: away from chat-based AI and prompt libraries and toward AI agents that can increasingly be configured to perform longer, multi-step tasks within defined constraints. Prompt libraries are giving way to skills libraries: reusable workflows with instructions, examples, reference materials, scripts, evaluation criteria, and named owners. Suddenly, non-technical people can build sophisticated automations in tools like Claude Cowork; implementation isn’t just for engineers anymore.

The chart plots each model release against the complexity of software tasks it can reliably complete, measured by how long those same tasks take a human. (Source: METR, an independent research organization that evaluates AI model capabilities on real-world tasks.)

The METR chart shows just how far the technology has progressed, but we’ve seen that many organizations implementing AI haven’t kept up with the sea change.The bottleneck for AI adoption has moved from model capability to chart shows just how far the technology has progressed, but we’ve seen that many organizations implementing AI haven’t kept up with the sea change. The bottleneck for AI adoption has moved from model capability to organizational capability. On our end, we’ve fundamentally altered our trainings to support executives and teams in this new era. For instance, we’ve retooled our sessions on prompting into workshops on setting up agents, skills, and workflows that can be owned, tested, and maintained. We’re working with executives on building that organizational muscle and turning raw model capability into reliable, repeatable workflows.

We know it’s making a difference. One investment firm we worked with now runs 100-plus agents across the organization through Copilot Cowork. At an e-commer ce company client, Claude’s Opus handled financial variance analysis that previously took a week. After working with us, a private equity firm decided to hire full-time AI champions to continue their AI implementation process.

Here are the five steps we’ve found that can carry you and your company into the next era, too:

Step #1: Get fluent

AI implementation starts with executive fluency. That doesn’t mean executives need to become day-to-day AI builders. What’s important is that you spend enough time with the tools to understand what you’re asking your teams to do. At one large media and data company we worked with, we saw that executives responsible for reviewing internal AI initiatives had never built with the tools themselves. All their previous initiatives had failed. It was easy for them to project what an AI agent could do for their business. It’s much harder to wrestle with what building with AI involves: the data the agent needs, the systems it can access, where it might fail, how much human review it requires, and who will maintain it after the first demo works.

Get your hands dirty

In our executive sessions, we push leaders beyond using AI as a chat interface and ask them to build a custom skill, agent, or automation themselves. The exercise quickly surfaces all the practical constraints that determine whether the use of AI can create value for a specific workflow.

Once you start to build for yourself as an executive, the conversation moves from abstract enthusiasm to practical questions: which connectors need to be enabled, what data can be accessed, and whether existing information technology policies match the company’s AI ambitions.

Understanding the roles and perspectives of IT and security are a critical part of AI fluency. The goal isn’t to bypass guardrails; regulated companies may have good reasons to restrict file uploads, block certain tools, or limit which data can be passed into a model. But as a leader, you need an ongoing dialogue with IT and security teams to take into consideration what tools are available, how they connect, what data can move where, and what trade-offs the company might be making. If you’ve never built under those constraints, you may misread the resulting low adoption as employee reluctance rather than an access problem.

Define your standard of excellence

Fluency also exposes whether leaders can define what good work looks like. In one executive session, we worked with a leader who had to prepare metrics for the company’s board. The process required pulling data from Snowflake and took many hours each quarter.

On the surface, this looked like a perfect candidate for an AI skill. But as the team started building, a different issue emerged: The executive could not clearly articulate what “excellent” looked like.

A skill is a set of reusable capabilities that define how an agent performs tasks; in order to reliably reproduce a workflow, it needs instructions, examples, reference materials, and a clear picture of what good and bad output look like. Of course, the same is true of people. If you cannot explain your standard of excellence to your chief of staff, you’ll certainly struggle to explain it to an AI system.

This is why as a leader, you’re better positioned to use AI than you may think. High-performing executives already know how to set direction, allocate resources, define standards, and judge whether work is good enough. Executives do not need to have all the answers. But you do need enough AI fluency to ask the questions that will help you decide where AI belongs in your company’s strategy:

What can AI see inside our company?
What can it do?
Where are the constraints?
Which workflows are painful enough to prioritize?
Who will own the systems we build?
How will we know whether they work?

Step #2: Assign AI champions

Once you understand what AI can and cannot do, the next step for executives is to assign ownership of the projects to specific individuals, known as AI champions.

Champions shepherd a project from initial idea to completion by experimenting with and iterating on workflows, teaching others what success looks like, and gathering support across the organization for AI implementation. Their job is to decide what gets built, what gets maintained, what gets improved, and what gets killed.

Champions typically have three qualities: curiosity, a people-oriented mindset, and the authority and time to do the work. As a leader, your job is to choose the best people for the job. In our consulting work, we train these champions to lead adoption across their departments.

Find the people who ask questions

AI champions do not need to be the most technical people in the organization. They don’t need to be engineers or have experience using AI for years.

They do, however, need to be curious. Great champions constantly ask questions, probe how processes work, and want to understand “what excellence looks like” for different tasks and functions.

Truly curious people also tend to be comfortable asking for help from colleagues and from AI—a skill we believe will define the next era of work. Successful AI champions treat AI as a partner rather than a one-shot magic button. And AI rewards people who are willing to admit what they do not know, break a problem down, ask better questions, and keep iterating until they get somewhere useful.

Great champions care about people

The best AI champions also understand that AI implementation is fundamentally a people issue — and they care about the people they work with.

AI champions build and maintain tools, but they also help colleagues change how they work. To do that well, champions need to understand the pain points inside their function. They need to know which tasks drain time, which processes frustrate people, and which handoffs create errors. That’s why the strongest champion is someone who’s close to the workflow the company is solving—a marketer who knows where campaign analysis gets stuck, for example, or a customer support lead who understands ticket triage.

They also need to be great communicators. Once a skill or workflow is ready for wider implementation, the champion has to explain it to the rest of the team, collect feedback, and help people understand how to use it.

Give champions time and authority

Champions need to be given the authority to make decisions and the time to be able to execute. This is where many AI programs fail. Executives identify enthusiastic people and ask them to help with AI on top of their day job. The result: The work gets squeezed into evenings, deprioritized during busy periods, and sometimes abandoned altogether. Enterprise AI implementation won’t work if it’s pitched as an informal side project.

What champions need is protected time—at least two days a month, in our experience—and a clear mandate. They should be responsible for a small number of workflows in their domain, with enough authority to make decisions about how those workflows are documented, tested, and maintained. They should also have a clear escalation path when they need support from IT, security, leadership, or another function.

The exact structure will vary, of course. A large company may need an ambassador model, with champions distributed across major functions. A mid-sized company will likely need one or two department champions per team. For private equity firms or holding companies, dedicated fellows who move between the firm and portfolio companies could be the most effective.

In short, an AI champion should:

Own one to three workflows in their domain
Maintain the documentation for those workflows
Build or manage eval sets
Collect feedback from the team
Update skills when tools, models, or processes change
Report on time saved, quality improved, or errors reduced
Have protected time to do the work

Step #3: Pick one painful workflow

Once you have champions, it’s time to pick a workflow to start with. This is where most executives make the mistake that derails the process: They begin with the biggest, most visible problem at the company.

We’ve seen executives want to automate the creation of the board deck, rebuild project management, or create an agent that solves a hairy cross-functional process across multiple systems. But even experienced AI builders make the mistake of starting too big. At Every, one of the team’s first instincts was to automate project management for our consulting business—a broad, messy workflow touching multiple people, systems, and decisions.

But AI implementation works better when you resist the urge to build the “whole body” at once. Instead, start with one artery of the workflow, a narrow, painful piece of the puzzle that can be tested, improved, and then trusted before expanding from there. Good candidate workflows are often unglamorous—categorizing support tickets or summarizing vendor updates—but are frequent enough to act as valuable test cases. If you’ve chosen your champions well, you can rely on them to find the most painful workflow to start with. They may even have experienced that pain firsthand.

To locate the best workflow among a good group of candidates, score them against the following criteria:

Frequency: Does this happen daily, weekly or monthly?

Pain: How much time, frustration, or error does it create?

Data availability: Is the required information already digital and accessible?

Risk: What happens if the AI gets it wrong?

Ownership: Who currently does this manually?

Evaluation clarity: Can we tell whether the output is correct?

Maintenance burden: How often will the workflow need updating?

Step #4: Build to 95 percent

Once you’ve chosen your first workflow (or your champion has with your blessing), it’s time to start building. This is often the moment when one of the biggest expectation gaps in AI implementation emerges. A team can often get an impressive first version of something working in minutes. Whether it’s a customer service workflow that categorizes the first 20 tickets correctly, or a vendor update that manages to capture a pricing increase or a new security requirement, that jump from zero to something workable can feel like magic.

But typically, what’s happened is that they’ve built a demo, not a usable product that can be rolled out anywhere. Turning that demo into a tool the team can rely on—going from 60 percent to 95 percent—requires much more work: examples, evaluation, feedback, human review, and maintenance. And champions and executives will have to work in tandem to get there.

Set product standards

Executives should act like tastemakers here, setting the standard for what a useful workflow looks like and where human review belongs, and deciding how much time the company is willing to invest in the outcome. Champions can then use those standards to build. They collect examples and evaluation metrics to test the workflow’s output, gathering feedback that informs the finished product.

Automation is a lie

Building to 95 percent also means accepting that any AI workflow is a never-ending process. Models update. Company processes shift. Team standards change. New edge cases appear. A skill that worked last month may need to be adjusted this month. This is where evals—structured ways to test whether the AI is doing its job correctly—come in.

Think of an AI agent less as a machine that runs forever and more as an employee you’re onboarding. You have to give it instructions, show it examples, correct its mistakes, and clarify what excellence looks like. Over time, it’ll become more useful, but only if it’s managed correctly.

For each workflow, create a simple table that asks:

What real example should the workflow be tested against?
What’s the current output of the AI agent?
What’s the expected output of the AI agent?
What errors is it making?
What caused the error?
Is a prompt or skill change required?
What’s the result of the retest?
Is human review required?
Who owns this workflow?
What’s the review cadence of the tool?

Step #5: Scale what works

The next step sounds obvious, but you’d be surprised how many executives get it wrong: Only scale what works. This is important from a resource perspective, but it’s also key for internal adoption. While many executives begin with a company-wide mandate that everyone start using the tools, the better path is to foster one visible win by choosing the right champion, workflow, and standards, and building from there.

When a team experiences an AI workflow that solves a real and painful problem, AI stops being an abstract productivity promise and becomes a practical solution. That experience creates pull across the organization, and other teams start asking what could work for them.

But scaling doesn’t mean copying the same workflow everywhere. Most workflows are department-specific. What works for finance may not work for marketing, for instance, and what works for customer support may not work for the product team. Once you have a winning workflow, it’s your job as a leader to decide whether it should stay team-specific, become a shared skill, or be sunsetted.

But regardless of how specific its impact is, your first successful workflow can create reusable components across the company by establishing how to describe processes, document standards, and define good output. Those practices can be adopted by any team.

Before scaling a workflow, ask:

Has it solved a real pain point?
Has it been tested against real examples?
Is there a named owner?
Is there a review process?
Are the risks understood?
Can the team explain how and when to use it?
Is there a feedback loop for improvement?
Should this become a shared skill, stay team-specific, or be killed?

A 60-day plan for leader-enabled AI implementation

Weeks 1–2: Get fluent

As executives, you should dedicate time to building with AI tools and mapping access, data connectors, and security constraints. Get your IT and security teams in the room to ask questions so you can understand the tradeoffs between AI implementation and security.

Weeks 3–4: Assign champions and pick workflows

Select champions in each relevant function, and give them a clear mandate and protected time to identify a short list of painful workflows.

Weeks 5–7: Build and evaluate

Work with your champions to select a starting workflow to build into a skill, agent, or automation by defining good output, building eval sets, and testing workflow to identify failure modes.

Weeks 8–9: Scale or kill

If the workflow works, train the rest of the team to use it. Then, instruct champions to run a show-and-tell for adjacent teams to help decide whether the workflow should become part of a shared skills library or remain team-specific. Make a final call on whether the workflow should be scaled, and move on to the next one.

By the end of 60 days, it’s unlikely you’ve transformed your entire company. But you will have something valuable: at least one reliable workflow created by trained champions, a team on board with its implementation, and a repeatable process for scaling future AI work. (You would be surprised at just how rare this is. Most companies have a lot of prompts, tools, and automations that don’t get the job done.)

What we’ve learned

There is no simple shortcut to successful AI implementation. No single tool or model can solve every company’s problem, and no outside firm can implement AI for you, either.

From leading our consulting practice, I understand the time and commitment it takes to go through this implementation process. In January, I spent over 100 hours working closely with our internal AI champion, a forward deployed engineer (FDE) on our team, to define our own AI adoption. Now, I spend 10-15 percent of my time maintaining existing skills, providing feedback to agents and the FDE, and making decisions about where to apply AI and how the team should allocate time to these tools.

We now have a skill library that the business relies on and an agent that does the work of a full-time employee supporting project management, sales operations, and delivery. For us, that investment is worth it.

The health tech company from earlier learned that firsthand. When we started working with them, they were getting to grips with Claude Code. Now, the company is building its own internal AI infrastructure that’s tailored to how its employees work. They got there by building organizational capability through our five-step process.

As executives, it’s your job to take the lead on creating these systems. Now you have everything you need to get started, so it’s time to learn the tools, empower the right champions, choose the right pain points, and—most importantly—build.

Natalia Quintero is the head of Every Consulting.

Thanks to Tom Matsuda for editorial support.

How We Work Now

Every Staff / Context Window — 2026-05-30 20:00:00 -0400

by Every Staff

in Context Window

Hello, and happy Sunday! This week was bookended by two guides: a 9,000-word power user’s guide to Codex—Dan Shipper’s “After Automation” essay put into practice the way the Every team has lately been working. And Kieran Klaassen published an updated guide to compound engineering, Every’s AI-native development workflow, expanded from four steps to seven. We’re running camps for both—a Compound Engineering Camp on June 5 and a Codex Camp on June 12.

Mid-week Anthropic dropped its latest model, Opus 4.8, and in the words of Dan and Katie Parrott, “Anthropic is so back.” The model tops our coding benchmark and writing tests, making it the company’s most complete model yet, though the app around it has some catching up to do. Anthropic and OpenAI have been volleying for the top of Every’s benchmarks for months. This week, Anthropic took the point.—Kate Lee

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Knowledge base

🔏 “Codex for Knowledge Work” by Katie Parrott/Guides: Katie Parrott’s 9,000-word guide turns Codex into an operating system for knowledge work, with five levels of use (from one-off tasks to compounding systems), 13 workflow templates, and the full setup for context files, rules, and review checklists that make agents reliable across a full workday. A companion essay covers the framing for readers new to Codex. Read this for the seven-day starter plan and the deeper templates.

“Compound Engineering” by Kieran Klaassen and Trevin Chow/Guides: The compound engineering loop has been expanded from four steps to seven. Ideate and plan move to the front, and polish to the end—now that AI handles the middle of the cycle. The updated plugin ships 43 subagents and 38 slash-command skills. In a companion essay, Kieran Klaassen explains the new paradigm of a sandwich: AI in the middle, with humans the bread on either end. Read this for the new loop and what each step demands of you.

“Vibe Check: Opus 4.8—Anthropic Should’ve Rounded Up to 5” by Dan Shipper and Katie Parrott/Vibe Check: Opus 4.8 is the first Anthropic release in a year Dan Shipper and Katie would reach for across coding, prose, and everyday work alike. It scored 63 on Every’s Senior Engineer Benchmark versus 62 for GPT-5.5 and 33.5 for Opus 4.7, and 79.6 on the writing tests—the highest score any model has hit, with fewer AI tells than any non-Claude model. Read this for the benchmark breakdowns and the case for why the model now outpaces the app built around it.

🎧 🖥 “We Automated Everything With AI and Tripled Our Headcount” by Dan Shipper/AI & I: In “After Automation,” Dan argues that AI progress creates more work for humans, not less. The better models get, the more frames there are to hand them. Every COO Brandon Gell sits down with Dan to press on each premise. Watch or listen to this for the oral version of the thesis. 🎧 🖥 Listen on Spotify or Apple Podcasts, watch on YouTube, or follow the discussion on X.

“After ‘After Automation’” by Katie Parrott/Context Window: Katie reads Pope Leo XIV’s Magnifica Humanitas—the Vatican’s first major encyclical on AI—as a collective companion to Dan’s thesis. Read this for what theyagree and disagree on about AI and labor.

Log on

Get hands-on with how Every uses AI. These are the live camps, workshops, and meetups where team members teach the workflows behind our work.

Upcoming camp

Compound Engineering Camp: On June 5, Cora general manager Kieran Klaassen and Trevin Chow host a one-hour walkthrough of compound engineering, the AI-native development workflow Every uses to ship products. Learn more and register.

Codex Camp: Our Power User Guide: On June 12, Dan and the Every team host a two-hour live walkthrough of the Codex power-user guide—setup, workflows, and Codex-native app development. Learn more and register.

Upcoming event

Executive AI Sessions: On June 2, head of consulting Natalia Quintero hosts a live webinar introducing Every Consulting’s new offering for leadership teams navigating AI adoption—built on the playbook we’ve been running with executive clients for months. Learn more and register.

In New York City

Every 🤝 IRL: Join us at the Every brownstone in Brooklyn on June 3 during New York Tech Week for a subscriber-only meetup celebrating the Every community over drinks and conversation. Learn more and RSVP.

From Every Studio

Proof keeps your name on shared docs

Proof, where humans and AI agents work on documents together, got eight new PRs this week, all focused on collaborative editing. Shared documents are now attributed to the first human who opens them (instead of the system), and your edits preserve your name through the full pipeline—no more anonymous tracked changes.

Alignment

The right kind of nervous. A few months ago I wrote about Doctronic, the company running a pilot in Utah to let an AI handle prescription renewals, and on Friday the state’s Office of AI Policy released the first five months of results. (The AI gathers a patient’s information and either recommends a renewal that a human physician signs off on, or declines and escalates the case to a doctor.)

In 72 percent of cases the AI recommended renewal, and the reviewing physician agreed nine times out of ten. In the 9 percent where a physician wanted more information, a second physician was brought in and usually decided it wasn’t needed. After both reviews, 97 percent of the recommendations stood. The office estimates humans get it wrong 5 to 12 percent of the time.

But the most reassuring data is that of the 28 percent of cases the AI escalated to a physician, doctors backed the call 69 percent of the time and judged the AI overcautious in the rest. For a pilot, that overcaution is wonderful—you want a system tuned to catch every genuinely risky case even if it stops some perfectly fine ones. A confident system that waves prescriptions through g is the one that should frighten you.

When I was doing rounds many years ago, I was told that the most dangerous doctors are the junior ones who are overconfident and the safest tend to be the overworriers who escalate everything, warranted or not. They do so precisely because they are still learning where the line sits, and that overcaution is how they find it. The Doctronic AI is behaving like a nervous junior, and at this stage, that’s the most encouraging thing it could do.—Ashwin Sharma

That’s all for this week! Be sure to follow Every on X at @every and on LinkedIn.

We build AI tools for readers like you. Write brilliantly with Spiral. Organize files automatically with Sparkle. Deliver yourself from email with Cora. Dictate effortlessly with Monologue. Work on documents with AI agents using Proof.

For sponsorship opportunities, reach out to sponsorships@every.to.

Upgrade to paid

Compound Engineering Gets an Upgrade

Kieran Klaassen — 2026-05-29 05:00:00 -0400

by Kieran Klaassen

Midjourney/Every illustration.

Join me and Trevin Chow for our third compound engineering camp for paid subscribers next Friday, June 5. We’ll show how planning and building are collapsing into one flow—where you hand your AI a goal and it runs with it. RSVP.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

In its early days, compound engineering was mostly about the code. I wanted to see if I could get an AI model to make a plan, do the work the way I wanted it done, review the results against my standards, and incorporate lessons from my feedback so it wouldn’t make the same mistake next time. The loop looked like this:

Brainstorm → work → review → compound → repeat

That loop is still the core of how I build Cora. But almost a year after we first coined the term compound engineering, the work phase has become boring—in the best way. If the plan is good and the agent has the right context, it usually does the work right. It writes the code and runs the tests. It fixes the obvious issues. The question now is: “Where do I fit in?”

The answer is at both ends of the process. An analogy my collaborator on the compound engineering plugin, Trevin Chow, came up with is a sandwich. AI is the stuff in the middle. Humans are the bread on either end, holding it together.

At the beginning, I need to decide what is worth building. I need to understand the user, the product, the weird edge cases, and the thing that feels exciting enough to spend time on. Then I can hand the middle to the agent. At the end, I come back in. I click around and look at the design. I read the copy. I ask whether the experience feels right. Sometimes everything technically works, but the product is still not good. So I make it better.

As the models have grown more capable, the original compound engineering loop started to feel incomplete. Plan, work, review, and compound still describes the core engineering cycle, but it leaves out the two places where I now spend most of my attention: before there is a plan, and after the work technically passes review.

So I expanded the loop:

Ideate → brainstorm → plan → work → review → polish → compound → repeat

Ideate and brainstorm are the new front of the process. Polish is the new end. Compound is still the most important step, because the whole point is that every feature should make the next feature easier.

I updated the compound engineering guide to explain the full system. The guide is about engineering, but I think the pattern applies to knowledge work much more broadly. The middle of a lot of work will get automated. But if you want the work to be good, and if you want it to feel like yours, you still need to be there at the beginning and the end.

Read the updated compound engineering guide

Kieran Klaassen is the general manager of Cora, Every’s email product. Follow him on X at @kieranklaassen or on LinkedIn.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

We build AI tools for readers like you. Write brilliantly with Spiral. Organize files automatically with Sparkle. Deliver yourself from email with Cora. Dictate effortlessly with Monologue. Collaborate with agents on documents with Proof.

For sponsorship opportunities, reach out to sponsorships@every.to.

Vibe Check: Opus 4.8—Anthropic Should’ve Rounded Up to 5

Dan Shipper and Katie Parrott / Vibe Check — 2026-05-28 08:00:00 -0400

by Dan Shipper and Katie Parrott

in Vibe Check

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Anthropic is back.

After a year of riding Claude Code into the rest of knowledge work, the lab hit a rough patch: Opus 4.7 was hard to love, and OpenAI’s Codex desktop app pulled even devoted Claude users from our team to GPT models. Opus 4.8, out today, has us running back—for the model, if not the app around it. It tops our Senior Engineer Benchmark and our writing tests at once, and it’s the first Anthropic release in a year we’d reach for across coding, prose, and everyday work.

The big insights from our testing:

Best on senior-engineer coding. At extra-high effort, Opus 4.8 scored 63 on our Senior Engineer Benchmark, versus 62 for GPT-5.5 and 33.5 for Opus 4.7. At lower effort settings, the score drops significantly.
The strongest writing model we’ve tested. Opus 4.8 at high effort scored 79.6, ahead of Sonnet 4.6 (74.5), GPT-5.5 (73), and Opus 4.7 (63), with fewer AI tells than any non-Claude model.
Best one-shot PowerPoint we’ve seen. On our Every Consulting Benchmark, Opus 4.8 produced a well-designed deck that told a clear story—something most models still can’t do.
The model is stronger than the app. Opus 4.8 is good enough to make us want to live in Claude, but the split between Chat, Code, and Cowork keeps Codex as the better daily harness.

The full Vibe Check has the benchmark results, Reach Test ratings, pricing, screenshots, and advice on when to reach for Opus 4.8 versus GPT-5.5.

Read the full Vibe Check

Dan Shipper is the cofounder and CEO of Every, where he writes the Chain of Thought column and hosts the podcast AI & I. You can follow him on X at @danshipper and on LinkedIn.

Katie Parrott is a staff writer at Every. You can read more of her work in her newsletter.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

We also do AI training, adoption, and innovation for companies. Work with us to bring AI into your organization.

Discover Every’s upcoming workshops and camps, and access recordings from past events.

For sponsorship opportunities, reach out to sponsorships@every.to.