# Every - Full Post Archive Concatenated Markdown of the 47 most recent posts. Capped at ~500KB. --- # Codex’s Comeback Up Close Hello, and happy Sunday. This week, Dan Shipper told the story of how a small OpenAI team transformed Codex from a failed launch into the app that took over ChatGPT, remaking the entire company in the process. On Friday, Dan joined senior editor Jack Cheng and me for a behind-the-scenes discussion of the story, including how he used Codex to structure it while keeping his own voice. Also: Every subscribers can RSVP for free to the Thesis: 2027 after-party on November 5 at Pioneer Works in Red Hook, Brooklyn.—Kate Lee Was this newsletter forwarded to you? Sign up to get it in your inbox. Knowledge base “How Codex Happened” by Dan Shipper: A year ago, OpenAI’s coding effort looked lost: Codex Cloud had flopped, the Windsurf deal had fallen apart, and Claude Code was taking off. Then a tiny team in the “backwaters” of the company built an app that swallowed ChatGPT from the inside. Today, Codex and ChatGPT for Work together have 40 million weekly users. Dan Shipper spent months talking with the OpenAI team that made Codex happen, including Greg Brockman and Thibault Sottiaux, to learn what it takes to build when the frontier keeps moving. His story comes with prompts for applying the lessons to your own work, plus the full interview transcripts for paid subscribers. Every software engineer Lee Knowlton turned Dan’s piece into an interactive visual novel. Watch a trailer for it, and play it here. Lee used Codex to generate cel-shaded anime avatars of Dan and his interview subjects and Claude to compose the experience and cut a trailer. “Gemini 4 Argon Puts Google Back On the Frontier” by Katie Parrott/Vibe Check: Gemini 4 Argon brings Google back into the frontier pack, an impressive feat for a company that runs on Google Workspace. The model is strongest as a collaborator: Dan now switches to it to structure essays and sharpen metaphors, and Compound Engineering creator Kieran Klaassen found it a fast, capable prototyper even at its lowest effort setting. Left on its own, Argon overbuilds in prose and design, and its desktop app, Antigravity, feels six months to a year behind Claude Code and Codex. 🎧 🖥“The Best Founders Have Something AI Can’t Tell Them” by Laura Entis/Context Window: Matt Hartman, founder of Factorial Capital, talked to head of consulting Natalia Quintero on The Every Podcast about why he assumes every early-stage startup will pivot and backs technical founders who can build for whatever market comes next. When vetting, he also looks for an “earned insight”—a unique lesson only a founder could have learned—and the ability to keep finding new ones after launch. 🎧 🖥 Listen on Spotify or Apple Podcasts, watch on X or YouTube, or read the transcript. Also inside: a field report on FeanixBio, an agricultural technology startup that runs on agents in Slack, and head of social media Becky Isjwara on using the Every Agent as her onboarding buddy, with the prompts she recommends new hires try on day one. “Context Engineering Is Knowing When to Start Over” by Mike Taylor/Also True for Humans: Mike keeps memory off in Claude and ChatGPT and starts a fresh thread for every task, even on the same project five minutes later. Context piles up inside a thread, he argues, and the model keeps following instructions you’ve moved on from and building on its own mistakes. He lays out seven ways that context goes wrong—including distraction, confusion, neglect, and poisoning—and pairs each with a sign to watch for and a fix, such as editing your earlier message instead of arguing with the AI. Read seven more predictions from frontier builders and thinkers in Thesis Statements, a collection of specific, contestable claims about the future of great human work with AI. The only thing that can free us from algorithms will be our own by Riley Brown, founder of Agent Native We’ll look for cues to care by Jack Cheng, senior editor at Every The only real programming language will be English by Andrey Galko, engineering lead at Every AI will join the writers’ room, not replace it by Fred Graver, founder of AI Writers Studio We’ll follow people for their stories, not their expertise by Becky Isjwara, head of social media at Every Editing will become a creative act by Soren Iverson, designer and founder of the eponymous creative studio The best way to keep your job is to be the one who automates it by Kate Lee, editor in chief of Every Our inaugural Thesis: 2027 conference is on November 5, 2026. Every subscribers can RSVP for the after-party that evening for free. Log on Get hands-on with how Every uses AI at live camps, workshops, and meetups. Upcoming events Codex for Power Users 2.0: Friday, October 23, 12–1 p.m. ET, virtual. Micah Rich, Every’s head of AI education, demos new Codex capabilities, including working from what’s on your screen, keeping a project connected across chats, and tidying a crowded sidebar. You don’t need to have attended an earlier session. Register. All-Access Office Hours: Friday, October 30, 12–1 p.m. ET, on Zoom. An hour with the Every team for All Access members, featuring what we’ve been building, a guest on what they’re trying right now, and your questions. Register. Previous camp How Codex Happened: Behind the Scenes: Dan talked with Kate and Jack about reporting on Codex while using it to write his story. Watch the recording. That’s all for this week. Follow Every on X at @every and on LinkedIn. Thanks to Eleanor Wikstrom for editorial support. Stop explaining AI to your team and start showing them. The Every Agent does the work in Slack, where everyone can see it, so one good workflow quickly becomes the whole team’s. Upgrade to paid --- # Context Engineering Is Knowing When to Start Over Was this newsletter forwarded to you? Sign up to get it in your inbox. The people I work with know I keep Claude’s memory turned off. The same goes for ChatGPT. I’ve written before about why: Memory can be useful, but it can also bring old preferences and irrelevant instructions into a conversation where they don’t belong. Turning memory off doesn’t entirely solve the problem. Even within a single thread, context can accumulate in ways that make the model’s responses worse—a problem known as context rot. It might keep following instructions you’ve moved on from, build on an earlier mistake, or overlook a crucial detail buried in the conversation. That’s why I start a fresh thread for every task. If the task changes, I open a new chat—even if it’s for the same project I was working on five minutes ago. In my forthcoming book, Context Engineering with DSPy, I explore the seven ways in which context goes wrong and what to do about it. The book is written for engineers building AI products, but I’ve adapted the examples that follow—inspired by Drew Breunig’s “How Long Contexts Fail”—for anyone who uses AI chat. They’ll help you recognize when a conversation has gone off track and restart without losing useful work. 1. Context distraction: Old patterns constrain new answers AI models are trained to follow the instructions in their prompt very closely, which is usually what you want—up to a point. There’s a trade-off between compliance and creativity: The more context you provide, the more the responses are constrained to what’s already in the conversation. You want AI to follow your instructions but also use good judgment when following the rules would give you a worse result. One example I use to demonstrate this problem in AI training workshops is asking ChatGPT to name a new product the way Steve Jobs would. With instructions alone, 21 percent of the names it comes up with start with “i-” (iPod, iPad, iPhone). Once I add a handful of example names that start with “i-” to the prompt, 100 percent of the names ChatGPT gives me start this way. That’s great if rigid compliance is what you want, but the model also stops suggesting any of the names I liked that didn’t fit the pattern. In a long thread, everything you worked on earlier becomes an example the model follows moving forward, whether you mean it to or not. It treats everything you’ve said as gospel, which will constrain its creativity in subtle ways you might not notice—unless you start a new thread without that old context. Models struggle to make the judgment call that the conversation has moved on, and old instructions no longer apply. You have to make that call for them. Watch for: You ask for a different direction, but every suggestion still follows the pattern of the examples you gave earlier. What to do: Start a new thread whenever the tone or type of task changes. When you do want the AI to follow examples, add them on purpose and test how many you actually need to let the model be creative, within the constraints you’ve set. $400+ in credits and discounts for your next AI build Join the free Nebius AI Builder Program for $400+ in credits and discounts from Nebius, LangChain, Tavily, Toloka, and more. Plus, working code, free courses, and expert office hours. Choose your models and tools and build alongside a growing community of AI builders. Join Nebius AI Builder Program today Want to sponsor Every? Click here. 2. Context confusion: Irrelevant details steer the response AI models don’t do a good job of ignoring information that has nothing to do with the task. If it’s in the prompt, even if it isn’t relevant to what you asked, the model assumes it must be there for a reason, and it tries to use it in its response. My colleague Katie Parrott found this out the hard way when the instructions for her writing style guide grew from 759 words to 3,855, and the writing became so bad it was unrecognizable. The model treated every line as a requirement and tried to satisfy all of them at once, so the drafts got worse with each round of feedback—one essay took 127 drafts and more than 1 million words. The solution was to take instructions away: The rebuilt style guide runs 513 words. To prepare for an interview at Microsoft Build, I interviewed an AI version of GitHub’s COO, Kyle Daigle, built with a modified version of the open-source library SynthTeam using his public writing, talks, and interviews. It answered five of my 12 questions with the must/should/could prioritization framework. Daigle had written about this framework on his website, so the virtual version overindexed on it despite the fact that it wasn’t relevant to the questions I was asking. When I spoke to the real Daigle, he never mentioned the framework once. Watch for: The model keeps bringing up a fact, preference, or framework that has little to do with your current question. What to do: Keep memory turned off so irrelevant context can’t leak into the current conversation. Keep your custom instructions to a minimum, because they can affect every conversation you have in ways you couldn’t have anticipated. One offhand comment can affect responses across your chats, and it may be hard to trace the problem back to its source. 3. Context neglect: Details in the middle get overlooked Researchers from Stanford found that AI models pay the most attention to the beginning and end of their context, and performance drops significantly when the information they need is in the middle. Humans show a similar pattern: We tend to remember and give more weight to information we encounter first or last, known as primacy and recency bias, respectively. In the book, I run an experiment where I give a model nine documents about a project, with a critical bug report sitting at position six, and ask about the main risks to the project. The model answers based on the overview at the start and the launch plan at the end and ignores the bug report completely. The same thing happens when you upload a stack of PDFs or paste in a long meeting transcript and ask the model a question about it: The answer leans on whatever came first and last, and the longer the thread, the bigger that middle gets. GPT-3.5’s accuracy is highest when the answer is in the first or last of 20 documents, and when it’s in the middle, it does worse than when it’s given no documents at all (the dashed line). (Source: Nelson F. Liu et al., “Lost in the Middle: How Language Models Use Long Contexts.”) Watch for: The answer skips a crucial detail in the middle of your documents, even while accurately referencing others. What to do: Only upload the documents the task needs, and if you have several questions about different documents, ask them in separate threads. Prompt engineers have long put the important task information at the top of the prompt and the formatting instructions at the bottom, and it’s worth doing the same with your messages. 4. Context drift: The original goal slips out of focus As new information piles up, the model can lose track of your original goal. Its answers stay coherent, but it stops following your initial set of instructions. Maybe you’ve experienced this after a long conversation with Claude or ChatGPT—it starts to introduce new angles, focus on the wrong things, or say “let’s step back” or “let’s wrap this up” when your initial goal is not yet accomplished. In the book, I show the example of a coding assistant told to “follow PEP-8 strictly” (a Python style guide) at the start of a conversation, and 50 messages later it’s writing code that completely ignores the guide. You’ve probably seen the everyday version: You tell the AI at the start of a thread to use British spelling or to keep its answers fewer than 200 words, and an hour later it has slipped back into its defaults. Watch for: The AI starts ignoring something you told it earlier, such as a spelling guideline or word limit. What to do: Keep the preferences you always want—like spelling, tone, or length—in a saved document and paste them in at the top of every new chat. To save on token costs, Claude and Codex both condense the chat into a summary when it grows too long (more tokens cost more to process), but that can come at the cost of losing prior details and important instructions. 5. Context clash: Early assumptions conflict with new information Researchers from Microsoft and Salesforce took prompts that would normally be given in one go and split them into several step-by-step messages, the way most of us actually talk to AI. However, breaking the task up led to 39 percent worse results across models. AI models tend to make assumptions early and jump to an answer before they have all the information, and that early answer stays in the thread, clashing with whatever you tell the model next. When I was automating PowerPoint decks for a client, the initial results were terrible. The solution was to give the AI the whole picture before it started building anything. We had it write a blueprint and a detailed agenda from our call notes first, and it rarely missed a slide. Watch for: You clarify the brief, but the model keeps building on an assumption it made before you supplied that information. What to do: Write the full brief before you start and put everything the model needs into the first message rather than drip-feeding it. If you realize halfway through that you left out something important, start a new thread with the complete brief, so the model never gets the chance to commit to the wrong answer. 6. Context poisoning: Earlier errors contaminate later answers The term “context poisoning” comes from Google’s Gemini 2.5 technical report. The Gemini team had an AI agent play Pokémon Red. In one case, it confused the game with a later remake and decided it needed an item called TEA to get past a guard. But that item doesn’t exist in the version it was playing. Gemini wrote down that goal and spent more than 100 turns searching for something it could never find. In a chat, a made-up statistic or a misremembered fact early on will show up again in every later draft because the model treats its own earlier answers as settled. Telling the model that it got something wrong doesn’t remove the mistake, either: The original error and your complaint about it are both still in the thread. Watch for: A fact you’ve already corrected reappears in the next draft or becomes the basis for another answer. What to do: When the AI makes a mistake, don’t argue with it in the thread or ask it to correct itself. Instead, go back and edit your previous message so it has no memory of doing anything wrong. With any mention of the mistake removed, it’s less likely to get stuck in a loop of making the same mistake. AI works by role-playing the helpful assistant it thinks you want. If it can see mistakes in its chat history, the model thinks it’s playing the role of “an AI that makes mistakes.” The past becomes a self-fulfilling prophecy. Both ChatGPT and Claude let you edit a message you already sent or regenerate the response, and either one is better than arguing with it. 7. Context underspecification: Missing details force the model to guess Every cause so far is a problem of too much context, but context rot can also come from a model that has too little. If something important is missing from the prompt, the model has to guess, and its guess will be the average of its training data. ChatGPT’s output is the average of the internet, so the default answer is often bland and undifferentiated. I used to run a 50-person marketing agency, so I know that value-based pricing often doesn’t work for agencies. But when you ask AI about pricing, it consistently recommends value-based pricing, echoing business pundits whose success with the strategy in niche businesses gets disproportionate attention online. Without the context that comes from running an agency, AI can mistake their advice for a broadly applicable rule. When you start a new thread with Claude or ChatGPT, you need to give it the context it needs. In this case, I used voice mode to explain what I’d learned from running an agency. Those details helped the model write a more useful post that reflected my experience. If you’re leaving a long thread that has valuable context but is starting to degrade from context rot, ask the model to save a handoff file—a document summarizing the key facts, decisions, and next steps. Upload it to a fresh thread so the model has what it needs to keep going. Watch for: The answer could apply to almost anyone, leaving out the constraints or experience that make your situation different. What to do: Before you leave a long thread, ask the model the question I’ve recommended when working on recurring tasks: Prompt What information would have been useful to know at the start of this task that would have eliminated several steps or mistakes? Read the answer, cut anything wrong or out of date, and paste it into your new thread as part of the new brief. Making a habit of starting fresh The best long-term fix for context rot is to keep your best context in local files your agent can read as needed. When I ran my agency, if I got the same question from staff or clients three or more times, I’d write a standard operating procedure and put it in a shared Google Drive folder. I do a similar thing with my prompts today: If AI needs an answer in one session, it might be useful in the next. I save prompts in Markdown files in GitHub, to reference when I start fresh, instead of hoping the right details survive in a long thread. By controlling which folder the agent is in, I can control its context and avoid context rot. A model won’t get annoyed if you start over 15 times, and it won’t tell you when your thread has become a mess. Its output just gets worse, so it’s up to you to prevent context rot before it takes over. Starting a new thread every time means I know exactly what the AI is working with: only what I’ve given it. Mike Taylor is the head of evals at Every, the author of O’Reilly’s Context Engineering with DSPy, and the coauthor of Prompt Engineering for Generative AI. You can follow him on X at @hammer_mt and on LinkedIn. Subscribe --- # How Codex Happened Was this newsletter forwarded to you? Sign up to get it in your inbox. Codex is one of the most important untold stories in the history of technology. A year ago, OpenAI’s coding effort looked lost in the wilderness: Codex Cloud had flopped. Their $3 billion Windsurf deal fell apart. Claude Code was running away with the market. Less than 12 months later, a tiny team in the “backwaters” of OpenAI built an app that grew to more than 40 million users, swallowed ChatGPT from the inside, and remade the entire company. I had a front-row seat to the whole arc—from a conference room in their office the night before GPT-5 launched to the day Codex took over ChatGPT—and spent months interviewing the people who made it happen, including OpenAI’s Greg Brockman and Thibault “Tibo” Sottiaux. It’s a wild story about what it takes to build when the frontier is moving beneath your feet: Read ‘How Codex Happened’ Your free Every account includes 10 prompts for applying lessons from the story to your own work and the story as a PDF. The story is also completely agent-native. Paid members get the full transcripts of all six of my interviews with OpenAI insiders, and a live session with me tomorrow about how we reported and wrote the story with Codex and what I learned about how OpenAI came back. Upgrade to paid Dan Shipper is the cofounder and CEO of Every, where he writes the Chain of Thought column and co-hosts The Every Podcast. You can follow him on X at @danshipper and on LinkedIn. --- # 🎧 The Best Founders Have Something AI Can’t Tell Them Nearly every startup pivots eventually, says Matt Hartman, founder of Factorial Capital, so he backs founders with a technical edge and hard-earned insights who are best equipped to navigate a change in markets. On this week’s episode of The Every Podcast, he tells Natalia Quintero how he finds those founders and why vibe coding his own app gave him new respect for paying for software. Plus: a field report from a 28-person agricultural technology startup that runs on agents in Slack, Becky Isjwara on using the Every Agent as her onboarding buddy, and seven new Thesis Statements. Was this newsletter forwarded to you? Sign up to get it in your inbox. ‘The Every Podcast’ Why technical founders win when startups pivot In 2016, Hugging Face started as a chatbot app for teenagers. Today, it’s the largest community for open-source AI and is set to be acquired by Nvidia for about $13 billion. Matt Hartman, who was part of the Betaworks team that wrote its first check, sees a lesson in that transformation: Back technical founders who can “move with where the world goes.” Now the founder and managing partner of Factorial Capital, Hartman assumes every early-stage startup will pivot. He believes the most successful founders keep their “pivot foot”—the one a basketball player keeps planted while turning—in their technical skills: They can build for a new market when their original business changes direction. In this week’s episode of The Every Podcast, Hartman tells Natalia Quintero how his investment thesis has evolved over time, how his portfolio founders became one of his best sources of new deals, and why vibe coding his own app gave him a new respect for SaaS. Watch on X or YouTube, or listen on Spotify or Apple Podcasts. You can also read the transcript. Here are the highlights: Investment theses that are “20 degrees off” can still lead somewhere good: Hartman looks for the “newly technically possible” by tinkering, reading research papers, and interviewing smart people. Noticing the lack of competition among his phone’s apps for his ears sent him hunting for a “Twitter for audio,” which led him to back Anchor, today a leading podcasting tool owned by Spotify. His hunch about conversational software similarly led to his Hugging Face investment. When he started Factorial, he turned the same curiosity on transformers: What could their next-word prediction abilities do with other sequences, like a robot’s movements or data from science experiments? He looks for insights that only the founder could have earned: AI can shrink the feedback-to-product-update loop from two months to two days, Hartman says. He looks for founders with an “earned insight”—something only someone in their position could have learned—and the ability to keep uncovering customer insights after launch. “Why is this thing interesting?” he asks. “Why is this the problem to solve?” Building his own app gave him new respect for SaaS: Hartman builds tools to run Factorial and just to experiment. Wondering why voice-to-text apps charge for inference when models could run locally, he used Claude Code to build Ghost Pepper, a free, open-source dictation tool that reached the top of Hacker News. The experience led to a surprising lesson: “When you just code something for yourself, you have to maintain it.” Amid talk of a SaaS apocalypse, he now sees subscriptions differently: “What you’re paying for is them making sure it stays a great product.” Miss an episode? Catch up on Dan Shipper’s recent conversations with Sam Altman; 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; and others to learn how they use AI to think, create, and relate.—Miriam Partington Field report How an AI-native agritech startup works with agents in Slack FeanixBio CEO Mitchell Angove woke up on a recent Wednesday to a report flagging an unhappy customer. A farmer had paid for the agricultural technology company’s parentage service—a bovine paternity test for his herd—but hadn’t received the results yet, despite asking for them twice. The report also noted that the engineer who usually handled troubleshooting was out sick and suggested which coworker should fill in. The report came from the Every Agent, a shared AI agent that FeanixBio has used in Slack since August. Angove amused himself by asking the agent to give his report a Lion King theme, with the unhappy farmer filed under “Hyenas at the Border.” Angove’s daily report is Lion King themed. Issues are grouped in a “Hyenas at the Border” section. (Screenshot courtesy of Mitch Angove.) Based in Scotts Valley, California, FeanixBio is a 28-person startup that uses genetic data to advise farmers on which cows to breed, keep, or remove from their herds. Its customers include about 35 family-owned farms, mostly operations with 10,000 or more animals in California’s Central Valley and in Arizona. It’s also an unusually AI-pilled company: Its agents work in the same Slack channels and threads as employees. The AI roster FeanixBio’s Slack is lousy with agents. Rumen, an agent built with OpenClaw by FeanixBio’s head of engineering, is available on the platform to everyone at the company. Named after the largest of a cow’s four stomach compartments (naturally), Rumen accesses FeanixBio’s data through the Model Context Protocol. Employees turn to it for business or data-specific questions ranging from “How does our stack work” to “What’s the deal with cow 2310?” People also regularly use the project-management tool Linear’s agent to turn discussions into tickets, as well as their own AI assistants, including Angove’s OpenClaw Micah. And then there’s the Every Agent. With the Every Agent connected to the company’s calendar, Slack, Linear, and database of individual cow data, one of its main jobs is to flag operational and communication issues before they snowball. Always-on monitoring For chief technology officer Kate Chapman, the Every Agent’s daily sweep of her team’s work has allowed her to “relax a little bit,” knowing that details she needs to track won’t “float by” unnoticed in Slack. She uses the Every Agent to generate her own daily report, which sorts tickets and other code-based tasks into green, yellow, and red buckets. A separate automation checks her team’s calendar and reminds employees a week before vacation to arrange coverage. Chapman doesn’t have to worry about coverage reminders because the Every Agent is on it. (Adapted from a screenshot courtesy of Kate Chapman.) The briefs are especially helpful when she travels. FeanixBio’s team spends time on farms and at conferences, where the activity directly in front of her can crowd out everything happening back at headquarters. “It’s really around keeping on top of those regular things that you need to be aware of that maybe you would have an assistant do, that I do not have,” Chapman says. An agent to summarize the agents Certain Slack threads, mostly arguments about cow behavior or engineering problems, can balloon to 70-plus messages, half of which are agent-generated. Employees invoke Rumen to make a point, and the agent will obligingly post “some giant doc that says really nothing of any consequence,” Angove says. When Rumen or a human posts something long-winded, Angove summons the Every Agent: “@Every, summarize this better.” Useful enough to keep paying for? Even at a company that is comfortable with agents, adoption is uneven. Everyone at FeanixBio has access to the Every Agent, and Angove and Chapman find it smart, capable, and easy to understand. For a while, Angove used the Every Agent to work through his Linear issues: to-dos such as replying to emails, messaging colleagues, and following up on partnerships. Each day, it sent him a list of the tickets assigned to him. He’d reply in Slack with how each should be handled, and the agent would reliably execute all of them. But higher costs during the beta phase limited Angove’s use. He tried cheaper alternatives, including delegating the job to his assistant and OpenClaw, but their capabilities couldn’t match Every Agent’s. Every Agent’s token costs have since fallen, and Every’s team continues work to make the agent cheaper to run. Token costs are passed through to customers without a markup, so making tasks more efficient lowers the cost. The agent’s token spend is down roughly 60 percent since Opus 5.5 was released in September, says engineer Marcus Moretti. Less expensive, open-weight models are improving: “You should expect that the token cost for the same use cases with the agent goes down over time,” he says. When we spoke in early October, Angove was working through his tickets by hand. He misses the quality of the Every Agent’s responses—if the price drops enough, he says, he’s open to tagging it back in and getting his time back. Inside Every My onboarding buddy was an agent During my first weeks with Every, I worked from Hong Kong, so most of the team was offline by the time I logged on. There was no onboarding package, but I had lots of questions that felt silly to bother my manager with, like “who is Yash?” “What is this rebrand everyone is talking about?” and “what does TOF mean?” I asked the @Every agent, which explained who people were, what they were working on, and what the unfamiliar terms meant. Every Agent explains unfamiliar terms in context. (Screenshot courtesy of Becky Isjwara.) Two things made that possible: First, the whole company uses the same agent, so it had accumulated knowledge from conversations and documents I didn’t know existed. Second, it had all this information because Every documents everything: Meeting notes, calendars, and decisions all live in Notion. That also means Every Agent can repeat mistakes it finds in documents. A meeting transcript once credited Arielle Shipper with something Natalia said, the agent repeated it, and I DMed the wrong person. It doesn’t replace people either. My first all-hands and my 1:1 with Kate Lee taught me things Every Agent didn’t tell me, like the reasons behind the team’s priorities for the week. If you have the Every Agent hooked up to your company’s sources of truth, have your new hires try these prompts on day one: Prompt 1. I’ve just joined [team]. What are the main projects they are working on right now? 2. Who is [name], what do they own, and what should I ask them? 3. Summarize the last week of #[channel]. My role is [x] and my goals are [insert here]. 4. Give me a briefing every weekday at 8 a.m. that summarizes Slack messages and meetings over the past 24 hours and orders them based on relevance to my role. —Becky Isjwara Thesis Statements In Thesis Statements, builders, operators, and thinkers predict the future of great human work with AI. This week, we have seven new predictions: The only thing that can free us from algorithms will be our own by Riley Brown, founder of Agent Native We’ll look for cues to care by Jack Cheng, senior editor at Every The only real programming language will be English by Andrey Galko, engineering lead at Every AI will join the writers’ room, not replace it by Fred Graver, founder of AI Writers Studio We’ll follow people for their stories, not their expertise by Becky Isjwara, head of social media at Every Editing will become a creative act by Soren Iverson, designer and founder of the eponymous creative studio The best way to keep your job is to be the one who automates it by Kate Lee, editor in chief of Every Our inaugural Thesis: 2027 conference is on November 5, 2026. Every subscribers can RSVP for the after-party that evening for free. Laura Entis is a staff writer at Every. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn. Stop explaining AI to your team and start showing them. Every Agent does the work in Slack, where everyone can see it, so one good workflow quickly becomes the whole team’s. Subscribe --- # Vibe Check: Gemini 4 Argon Puts Google Back On the Frontier If you work at a traditional company, listening to AI power users rave about Claude Opus, Fable, or ChatGPT over the past year has probably felt a little like being gaslit. While those of us who get to pick our own tools spend all day yapping about agents that can refactor a codebase or act as a developmental editor, helping shape a draft’s structure and argument, most people don’t get to choose which frontier model they use at work. Their company is locked into Microsoft Copilot or uses Google tools as one of the more than 13 million organizations paying for Google Workspace for everyday work, or the nearly 90 percent of the Fortune 100 using Gemini Enterprise to draw on company knowledge and automate workflows. And if your only window into AI has been the Gemini model bundled into your work account, you haven’t seen anything close to what the frontier model companies have been doing. While Anthropic and OpenAI spent the spring and summer trading heavyweight releases, Google hadn’t shipped a major upgrade to its flagship model since Gemini 3 Pro last November (followed by a minor 3.1 Pro bump in February), spending the summer rolling out four rapid-fire updates to Flash—its faster, lower-cost model line—while its promised Gemini 3.5 Pro stayed in testing. With Gemini 4 Argon, released today by Google DeepMind, Google is back in the frontier conversation. --- # One Agent for the Whole Company Hello, and happy Sunday. We launched the Every Agent this week, an AI coworker in Slack that your whole company shares. Your team can give it work in a thread, and when a workflow is successful, you can ask it to save the workflow as a skill anyone on the team can run. Also: The Thesis: 2027 after-party on November 5 at Pioneer Works in Red Hook, Brooklyn, is free for Every subscribers—RSVP to reserve your spot. Lastly, we’re off Monday for the U.S. holiday of Columbus Day/Indigenous Peoples’ Day and will be back in your inbox on Tuesday.—Kate Lee Was this newsletter forwarded to you? Sign up to get it in your inbox. The Every Agent, explained “Introducing the Every Agent” by Dan Shipper/On Every: The Every Agent does its work in public Slack threads, so your colleagues see both the request and the corrections. It replaces Plus One, which we launched in March to give each of us our own agent, after Dan noticed that people learned the most from watching someone else’s agent at work. Head of evals Mike Taylor built a skill that resets his priorities every Monday, and engineer Nityesh Agarwal runs it every week, too. Each person on your team gets $15 in free credits to try it, with 0 percent markup on tokens: What we pay is what you pay. 🖥 🎧 “Why Every Traded Personal Agents for One Company Agent” by Laura Entis/The Every Podcast: Willie Williams, Every’s head of platform, joined Dan to explain why the personal bots our team built in January mostly died off: They were hard to maintain, and no one could remember which one did what. This is a must-watch or must-listen for anyone deciding whether to give every employee a personal agent or build one shared agent for the whole company. 🖥 🎧 Listen on Spotify or Apple Podcasts, watch on X or YouTube, or read the transcript. “Why We Handed Our Agent’s Infrastructure to Anthropic” by Paridhi Agarwal/Source Code: Paridhi Agarwal, an engineer on the Every Agent, explains in her first piece for Every why we stopped hosting our own agents and moved to Anthropic’s Claude Managed Agents: Keeping the servers running took time we wanted to spend on the agent itself. The trade-offs are that the service runs only Claude models and can’t offer the zero-data-retention option some companies require. 🖥 Watch Dan and Willie explain how we built the agent on Claude Managed Agents in a video we shot with Anthropic. “Building a More Efficient Agent” by Laura Entis/Context Window: The team first tried routing the Every Agent’s tasks through a cheaper model, and costs went up because many requests ended up running on a more advanced model as well. Paridhi went looking for waste in the agent’s own code, and a model upgrade plus a handful of small fixes cut token costs across 11 common tasks by more than 80 percent. Also in the edition: her four-step workflow, with prompts, for finding waste in your own software, the models the team is using this week, and Willie on managing engineers with AI. Knowledge base “When Trying to Make AI Better Makes It Worse” by Katie Parrott/Working Overtime: The Germans have a word for what Katie did to her AI setup in September: Verschlimmbesserung, or making something worse by trying to improve it. She kept adding rules to the files that tell her AI how to write until one essay took 127 drafts, so she archived the whole thing and rebuilt a setup a fraction of the size. Her advice: Try taking something away before you add another instruction. “You Already Signed This Off (In the Simulation)” by Mike Taylor/Also True for Humans: “Don’t freak out, I cloned you,” Mike told his then-boss Natalia Quintero after feeding a year of her Slack messages to an AI so it could approve his client emails on her behalf. He built clones of GitHub’s chief operating officer and of Dan, too, and while each one learned its person’s rules, they didn’t learn when to set them aside: Natalia’s clone took 73 rounds to turn his email into something that read like a lawyer drafted it. Mike compares them to a Waymo stuck in traffic while a New York cabbie gets you home in half the time. This week’s seven Thesis Statements—a collection of specific, contestable claims about the future of great human work with AI—all come from the Every team. The arguments we hid behind shared vocabulary will become explicit by Alex Duffy, cofounder and CEO of Good Start Labs Managing decision fatigue will become part of making great work by Laura Entis, staff writer at Every You’ll give your Legos away to agents by Brandon Gell, chief operating officer at Every Nothing will go wrong twice by Kieran Klaassen, creator of Compound Engineering and member of the frontier team at Every Describing a problem will be enough to begin solving it by Naveen Naidu, general manager of Monologue Your expertise will belong to your employer—unless you can make it portable by Kaushik Viswanath, managing editor at Every History will be rendered, not read by Willie Williams, head of platform at Every Our inaugural Thesis: 2027 conference is on November 5, 2026. Every subscribers can RSVP for the after-party that evening for free. Work at Every We’re hiring a product manager for Checks at Every. Checks is our personal benchmarking product: You turn examples from your own work into yes-or-no checks and find out which AI models clear your bar. We’re looking for someone technical to lead it, with instincts for both product and platform. Learn more and apply. See the rest of our open roles on the careers page. Alignment Spot treatment. I spent about six years at medical school before I could write prescriptions for patients. Doing so rarely felt like I was participating in a technological revolution, but watching a machine being allowed to do it very much does. Utah recently authorized Nolla Health to test an AI system that can diagnose mild to moderate acne and write prescriptions for topical acne treatments through its app. Initially, two physicians must review and approve every prescription, but if the system meets the pilot’s safety requirements, the state can allow it to operate with progressively less human oversight. Nolla Health is building the evidence for an AI doctor to handle the entire clinical journey, from diagnosis to follow-up care, for relatively simple conditions. If AI can safely manage the entire pathway, patient volume can grow without increasing clinical headcount at the same rate, thus unlocking the potential for huge scale. That would potentially lower the cost of providing treatment and make it viable to serve people who are currently priced out or poorly served. But the efficiency gains have to hold across the entire course of care because what matters is whether patients achieve good outcomes with less total clinical work, including follow-up, escalations and appointments elsewhere when treatment fails. Those healthcare costs will still count, even if they do land outside the app. Nolla and others like it are putting that model of care to the test in a narrow setting, and if the results support it, there is a case for testing other conditions, like urinary tract infections or tonsillitis. Even a modest list could add up to a substantial amount of care.—Ashwin Sharma That’s all for this week. Follow Every on X at @every and on LinkedIn. Thanks to Eleanor Wikstrom for editorial support. Stop explaining AI to your team and start showing them. The Every Agent does the work in Slack, where everyone can see it, so one good workflow quickly becomes the whole team’s. For sponsorship opportunities, reach out to sponsorships@every.to. Upgrade to paid --- # You Already Signed This Off (In the Simulation) Was this newsletter forwarded to you? Sign up to get it in your inbox. “Don’t freak out, I cloned you.” That’s what I told Natalia Quintero, my boss at the time, after I distilled a year of her Slack messages into a file called natalia.md and used it to simulate whether she’d sign off on an email I was about to send a client. She didn’t freak out—in fact, she said it was her favorite call of the day. I had just started in a consulting role reporting to Natalia, and I was worried I didn’t know how to communicate with corporate clients. Our clients were large enterprises, but I had only ever had experience working with startups. Natalia, meanwhile, had years of corporate and banking experience. I knew my tendency to write emails like I write tweets might not be professional enough for this context, but I didn’t want to be asking Natalia to check my emails multiple times a day. She had better things to do, and when she did give me advice, she was often repeating herself. AI can produce more drafts, proposals, and emails than anyone has time to read, so the scarce thing at work is the time of a person with judgment who can say, “Yes, send it,” or “Try it another way.” Those people spend a lot of their day telling different people the same things, when they could instead be spending their time doing something more productive. Since AI is good at role-play, I figured it could help take some of that burden off my colleagues by capturing their judgment without me having to bother them. So I started cloning the people I needed sign-off from, hoping a simulated colleague could stand in for the real one. I found the virtual versions of my colleagues are great at learning someone’s rules. They just can’t bear to break them, and knowing when to do so is the part you still need the person for. Cloning my boss to review an email I used SynthTeam, an open-source library that turns a colleague’s Slack history into a persona file, and had Codex pull a year of Natalia’s messages from public channels (no direct messages or private channels) for situations where she’d made decisions and reverse-engineer how she made those decisions. (I didn’t ask her first, but I knew she’d be fine with it.) I gave GPT-5.5 Natalia’s persona file ( and one goal: Improve my drafted email until simulated Natalia rated it 10/10. I set it up with the /goal feature, which keeps re-prompting the model every time it thinks it’s finished until the goal is met. I told it to use a fresh subagent for every rating so it couldn’t peek at the previous scores. The email was to a contact at a client, asking whether any of three dates work for an event we’d co-host and requesting feedback on the pitch for a consulting engagement. Here’s the original, as I would have sent it, with the client’s details removed: Two things: Do any of these dates work for the event? April 27 or 28, or May 7 Format: I talk for 30 mins on a DSPy-related topic (I think optimizing skills), you talk for 30 mins (on [your product]? something else?), then we both do a fireside chat style Q&A together after. I think it will be at civic hall in manhattan but just figuring that out. I name the session something without agentic buzzwords so we attract the right people. Would love feedback on the below pitch we’re going to market with for our AI embedded consulting bundle (it may not be right for [the client] right now but just more broadly what do you think is compelling / needs work?) [six-paragraph description of the bundle] Simulated Natalia gave it a 6/10. “The bones are good,” she said, but it “reads a little too stream-of-consciousness,” and she quoted my own “just figuring that out” back at me. That was fair, and it was exactly the advice the real Natalia would have given me. Then the AI started revising and scoring the email over and over. It ran a whopping 73 rounds of optimization, rewriting the email and getting cloned Natalia to grade it. It managed to get a 9/10 by round 16 but stalled there, and never hit 10. The agent spent the remaining rounds applying Natalia’s rules harder, with more formality, reassurance, and ways to make it easy for the client to say yes. Here’s a slice of where it landed: This would not be framed as you representing [the client], and nothing would be recorded, attributed, or promoted. The room is being curated for senior operators with active internal AI rollout responsibility: people who own workflow change, enablement, governance, budget, or team adoption decisions, not vendors or public attendees. Would any of these dates be plausible enough for me to send the attendee list/profile and exact intro? This would only hold the option, not commit you. You could decline after reviewing the audience and framing. […] It goes on like that for another 250 words, and it reads like it was drafted by someone’s lawyer. Along the way it dropped the consulting proposal entirely and changed the event: My two 30-minute talks and a fireside Q&A became a small private discussion, with my contact dropping in for 10 minutes, plus promises I hadn’t made—an attendee list within 24 hours, an introduction he could veto, and a one-page brief. I chalked this one up as a loss. I had given it one goal—Natalia’s approval—and it pursued that at the expense of everything else, including my voice. Every change it made followed from something Natalia believes, but none of them was something she would have told me to do. The clone could tell me what she’d object to, but not when an objection shouldn’t matter. Cloning an executive before an interview I used a similar method, this time for rehearsal rather than sign-off, before I interviewed Kyle Daigle, the COO of GitHub, at Microsoft Build. This was high stakes for me: It was the first time I’d done a big interview, and I wanted to feel prepared. I cloned Daigle from his public writing, talks, and interviews and roleplayed the interview with the persona to see which of my questions got interesting answers. The Daigle clone also helped me learn about the real Daigle. Asking his persona questions was a targeted and more interesting way to get to know him than reading everything he’d written or that had been written about him. This works well when the person shows up frequently online, as Daigle does, because the model has seen plenty of the material in its training data and can find information online when constructing the persona. It works less well with people on whom the model doesn’t have much information. Afterward, I compared the persona’s answers with the real Daigle’s. Two of its answers were strong matches, four were partial, and six were misses (I wrote up the full comparison). The miss that stuck with me was the persona’s habit of reaching for a framework. Daigle has said publicly that he makes decisions with a must/should/could framework, and the persona latched onto it. It used must/should/could in five of my 12 questions. The real Daigle didn’t mention it once. Having a favorite framework doesn’t mean bringing it up in every conversation. The clone was like a colleague who’s read your book and won’t stop quoting it back to you. I told Daigle about the clone during the interview, and he loved it. Afterward he said the simulated interview was “pretty good,” but that it “overindexed on my written work rather than my spoken interviews and podcasts.” That would explain how a framework he’d described publicly showed up in five of the persona’s answers and none of his. Cloning our CEO to work through a problem The third example was something I was struggling with. Dan Shipper wanted to put ratings on our Vibe Checks so readers could see what we mean when we say we prefer one model over another, and I was worried that anything called a benchmark with fewer than a couple of hundred tasks would be false precision. I built a persona of Dan from his public writing and ran the same loop to find a path forward with him on my quantitative Vibe Checks proposal. It took eight rounds, not 73, and reached a 10/10, though this was a different task from the emails I optimized with Natalia’s clone, and I used a newer model, GPT-6 Sol. It even challenged the numbers in my proposal. But the clone tried to make the ratings more rigorous by adding more process: a 12-task pilot, reviewers who wouldn’t know which model produced each answer, and a 900-word set of instructions that another AI reviewer judged too dense to send. I found this much more useful, but it didn’t capture what the real Dan did when he saw my proposal: Reframe the question. In real life, Dan suggested we change the name to avoid association with academic benchmarks (we landed on “checks”). He also pointed me to wine critics and Wirecutter, who put numbers on editorial judgments without pretending to have run hundreds of tests. The end result was better than the idea I had before, and we didn’t have to choose between false precision and no numbers at all. The clone had stayed inside the frame I gave it—the real Dan stepped outside it. That turns out not to be a one-off. Separately, Dan tasked me with building a proper clone of him, a skill called Dan Lens that we gave our company agent, so the team could use his judgment when he’s not around. When we compared his real replies on 201 Slack threads with the Dan Lens prompt’s responses, the model kept consistently failing to predict Dan’s actions. When we looked closely at the responses, we found that the real Dan often questions the assumptions behind what he’s being asked—he likes to reject the premise entirely. He goes along with the way a thread is framed only 34 percent of the time. The rest of the time he pushes back, redirects, adds an idea of his own, or asks for more before he’ll answer. The model goes along 68 percent of the time—twice as often. We’re still working on Dan Lens. Dan was overjoyed to find out that the data showed his views are remarkably consistent: We couldn’t find a single example where he had contradicted himself! There are rules about his decision-making the models should get better at learning. But it’s refreshingly humanizing to learn that you can’t easily be cloned, because we still need Dan’s judgment of when to break the frame. What’s left for us humans? On my way back from a trip to San Francisco, dreaming of cloning more colleagues, I got a lesson in what the AI clones were missing. After sitting in San Francisco traffic in a Waymo that was too timid to barge through, I had the exhilarating experience of a New York yellow cab driver putting his foot down and swerving in and out of traffic. He got me home in half the expected time. He broke some rules but knew when and how to do so. The clones I built drove like the Waymo. Natalia’s reaction was different from what I’d built the file for. Her first instinct was to read it and learn about herself. It showed her how she comes across at work, and she wanted to keep it for days when she’s not at her best, so she can check herself against her own standards. The file has all her rules in it, though she’s still the only one who knows when to break them. Cloning your colleagues seems odd today, but I think it will soon become the polite thing to do. Roleplaying a high-stakes interaction before you have it shows you’ve done your homework, gets all the obvious things you should know about them out of the way, and saves everyone time. You can walk into the meeting prepared for what your boss might say. The meeting is for finding out how she’ll surprise you. Mike Taylor is the head of evals at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # Why We Handed Our Agent’s Infrastructure to Anthropic Earlier this week, we launched the Every Agent, a coworker that lives in your company’s Slack. In her first piece for Every, engineer Paridhi Agarwal explains how we built it on Anthropic’s Claude Managed Agents, why we stopped running our own fleet of agents, and the trade-offs we accepted along the way. If you want to see what a shared agent can do for your own team, join us tomorrow for our camp on working with agents in Slack.—Kate Lee Was this newsletter forwarded to you? Sign up to get it in your inbox. On a Friday in September, Arielle Shipper’s salad went missing from the office fridge. Douglas Brundage did what most of us at Every now do with a problem. He asked @Every in Slack. “who stole Arielle’s salad!?!?! make a list of likely culprits” A minute later it posted a ranked list of suspects, starting with the people it knew had been in the kitchen that afternoon. After every named employee had made their case, @Every zeroed in on Leo, the office dog: Everyone else needed a motive. He only needed an unattended bowl. Nobody found the salad. Over the past five months, we’ve been building a coworker that lives in your Slack, keeps up with what’s happening around the office, and joins in when someone asks it to investigate a missing lunch. That’s Every Agent, which we launched on October 6. In Slack it goes by @Every. How Every Agent helped us “solve” the case of the missing salad, with a sense of humor. (Screenshots courtesy of Paridhi Agarwal.) Every Agent runs on Claude Managed Agents (CMA), a service Anthropic launched in April. It runs the machinery an agent needs to think, remember, and pick up where it left off. That let a small team spend its time on the parts you see in Slack. We didn’t know any of this when we started. We didn’t set out to build one agent for the whole company, nor did we plan to hand its machinery to someone else to run. Build an app that works for every age in one day at Google On October 21, Google and k-ID host the Build for Everyone Hackathon at Google San Francisco. Bring an idea for an app or game. New tooling from k-ID, revealed that morning, adapts it to whoever is using it, so a child, a teen, and an adult each get the right experience automatically. Fifteen teams get one day to ship, with mentors from Google, k-ID, and partners on hand to help before you demo to the judges. Use Gemini and Google Cloud or any tools you like. It’s free for builders 18+. Applications close Monday, October 12. Apply to build—or watch the livestream Want to sponsor Every? Click here. Our first agents were pets Every is a small team that tries to do a lot, so we’re always asking how to get more done with the people we have. When OpenClaw, an open-source agent program, went public late last year, agents started to look like the answer. What if each employee at Every had an agent working alongside them, doubling what each of us could get done? Plus One was our attempt to find out. As Brandon Gell and Willie Williams wrote in May, we gave each Every employee their own agent, running OpenClaw on a rented virtual computer. That left us managing dozens of these cloud machines around the clock, checking every 30 seconds that the agents were still running and fixing them when they crashed. (We built a command called /heal-bot to walk us through repairs.) When a bot’s ChatGPT sign-in expired, it went quiet until someone signed it back in by hand. A separate job ran every hour just to keep Slack’s access tokens from expiring. OpenClaw also wasn’t built for a team. It reset conversations at 4 a.m. each day, and its memory systems overlapped in ways that were hard to untangle, as Nityesh Agarwal wrote in June. By spring we had learned that most people don’t want to look after an agent, even one that’s theirs. And we didn’t want to look after a fleet of them, either. Engineers like to say servers should be cattle, not pets: interchangeable and replaced when they fail instead of nursed back to health. Plus One had given each of us a high-maintenance pet and tasked our engineers with keeping dozens of them alive. Why we switched from personal agents that we ran locally to a company agent hosted by Anthropic. (Illustration by Paridhi Agarwal.) We wanted to build a coworker, not infrastructure We soon realized that—aside from the issues that came with running our own infrastructure—personal agents had a ceiling. Each agent only knew its owner’s work, so it missed what the rest of the company was doing and how that affected you. When someone figured out a good workflow, it stayed with their agent. Teaching every agent the same thing meant making the same update several times, and when the agent broke, its owner had to fix it. Meanwhile, the threads where the whole team pulled in any single agent were the ones that worked best. This led us to the vision of one agent shared by the whole company: It sees the whole team’s context, a skill it learns from one person works for everyone, and we only have to keep one agent running. Moving to one shared agent meant fewer agents to maintain, but we still had to decide who would keep it running. Dan Shipper thought hosting a single agent ourselves would be manageable. Willie wasn’t convinced. We tried it on our own servers, and within a month, the maintenance work it required had convinced Dan, too. We wanted to build a coworker, not run an infrastructure team. In early May, we wrote a plan to rebuild on Claude Managed Agents, and within a week, @Every was answering in Slack, and the old agent fleet was gone. An AI model generates responses. To act on them—searching files, running code, or sending a message—it needs a harness: the software that runs the tools it requests and feeds back the results. Claude Code has one, but it’s built to run on one person’s computer. OpenClaw had one, too, and Plus One taught us what it costs to host a harness yourself: Everything around it becomes your job. With CMA, Anthropic runs the harness and handles much of the maintenance we’d been doing for Plus One. Each session—the conversation and the work the agent does within it—gets a virtual computer that costs 8 cents an hour while it’s running. CMA also handles caching, which lets the model reuse information it has already processed, and compaction, which summarizes long conversations so the model can keep working. It also lets us interrupt the agent mid-task. With Plus One, each of those was our job. Anthropic’s engineers describe the design as separating the brain from the hands. Claude and the harness are the brain. The computer and the tools are the hands. The session sits outside both, as a running log of everything that happened, so the work survives if either one crashes. For us, each Slack thread gets its own session, so @Every picks a thread back up right where it left off. Memory carries across threads: folders of notes the agent reads at the start of each session and adds to as it learns. How Every Agent works. (Video by Paridhi Agarwal.) What @Every does all day If Anthropic runs the infrastructure, what’s left for us to build? Everything that makes @Every feel like a coworker instead of a chatbot. A chatbot answers whoever talks to it. A coworker in Slack has to know when a message is meant for it and on whose behalf it’s acting. Those two problems took most of our design work. (For a tour of what @Every does day to day, read Dan’s launch post.) Every Agent does the busywork between your apps. Every Agent keeps track of things so you don’t have to. Tag @Every, and it replies, whether in a direct message—where it works as a private assistant—or in a channel thread anyone can join, the way half the office did on the salad case. When a thread it’s in keeps going, @Every reads the room and decides whether a message was meant for it, merits a quick emoji, or belongs to the humans. A small, fast model reads each untagged message first, along with who’s in the thread and what @Every said last, and decides whether to reply, react with an emoji, or stay out. When in doubt, it stays quiet. Every Agent catches mistakes. While drafting speaker invitations, it noticed the checkout page showed the wrong price, and when asked, it opened a pull request for the team to review. When @Every needs to read information or take an action in another app on behalf of a user, CMA pauses the agent and hands the request to our servers. Our servers make the call with the user’s own login and send back only the result. The agent never holds a password or access token, so it can’t use one for anything the asker didn’t request. Skills that the agent has follow the same rule: Anyone can ask @Every to change one, but nothing changes until the skill owner approves. Every Agent learns and updates skills that can be used across the team. Every Agent respects permissions and won’t show users information they don’t have access to, unless they get approval from an authorized user. The trade-offs we accepted Although Claude Managed Agents took whole categories of problems off our plate, building a coworker on top of it still had plenty of challenges. The first was one we caused ourselves because of the design we’d chosen. Anthropic keeps the agent’s session running even when our servers restart. But when we deployed an update while the agent was working, we sometimes shut down a server before it could respond to the agent’s request. The agent kept waiting for a response that would never arrive. New messages failed, and trying to interrupt the agent didn’t unstick it. To get it working again, we had to send responses to all its outstanding requests. It’s an ordinary bug once you see it. Every team that runs its own code next to a hosted agent will encounter some version of it, and we hit it every time we shipped while someone was mid-task. Then, in late July we switched models to Opus 5, and @Every got wordy overnight. The typical reply went from about 280 characters to about 880, and people started calling its answers essays. Teammates took to asking it to try again “with half as many words, like a normal person.” We spent weeks writing rules and tests for brevity and formatting. When Anthropic released Opus 5.5 in September, its announcement called writing “one of the most common areas of feedback we heard about Opus 5,” and once we switched, the essays stopped. When Every Agent ran on Opus 5, its loquaciousness posed a real challenge. Our longest conversations caused two more problems. One customer’s DM ran as a single session for three days and 33 exchanges. Each time the cache expired between messages, the model had to write the whole history back into the cache, which costs more than reading it fresh. And near the model’s context limit (the most text it can consider at once), Opus sometimes returned nothing at all. The solution for both was to start a fresh session well before either point. Now a DM that goes quiet gets a new session with a short recap of the old one. When we reran past conversations with the fix in place, total costs fell 39 percent, and not one exchange cost more than it had before. (You can read more about our cost-reduction work, including fixing a caching bug that had us paying full price on every conversation, in Context Window.) We could fix those problems ourselves. The trade-offs that come with CMA are harder to work around, and more than once they had us looking for alternatives. The limitation we feel most is that CMA only runs Claude. We can pick a different Claude model for each session, so a quick question goes to a faster, cheaper model, but there is no way to route to models from other labs that might be even cheaper or more appropriate to the task. In addition to being limited to Claude models, we’re tied to the design of CMA. And because it keeps each session’s history so it can resume work, it isn’t eligible for Anthropic’s zero-data-retention option. Some companies require that, and for now we can’t offer it. Eventually I spun up an architecture document listing everything we’d have to replace to move off CMA. It ran longer than any of us expected. Replacing CMA’s infrastructure would mean rebuilding the harness, sessions, memory, tools, and sandboxes we’d been glad to hand off and would take months, not to mention dealing with a whole range of new bugs. What’s next By staying on Claude Managed Agents, we spend our time on @Every instead of the infrastructure underneath it. Today it’s a coworker you call on when you need something. We want it to be one you’d miss if it were gone. Most of that is memory that gets sharper the longer it works with your team, so it learns how each person likes to work without being told twice. We also want @Every to work with you across multiple surfaces, so it feels more like working with the person who sits next to you. And like any good coworker, it doesn’t let things drop. Arielle’s salad is still missing, and as far as @Every is concerned, Leo is still the lead suspect. Paridhi Agarwal is an engineer at Every working on the Every Agent. Stop explaining AI to your team and start showing them. Every Agent does the work in Slack, where everyone can see it, so one good workflow quickly becomes the whole team’s. Subscribe --- # Building a More Efficient Agent Yesterday we launched the Every Agent, an agentic coworker in Slack that helps your whole company go AI-native. Because we pass its token costs on to you with no markup, every token we save, you save. In today’s Context Window, engineer Paridhi Agarwal explains how she made the Every Agent more token-efficient and shares a four-step workflow you can use to find token waste in your own software. Plus, the models the team is reaching for this week, a fresh batch of Thesis Statements, and Willie Williams on being an AI-first engineering manager. On Friday, sign up to join the Every team for a one-hour camp on working with agents in Slack. Try the Every Agent today ‘The Every Podcast’ Why Every traded personal agents for one company agent Dan Shipper named his first AI agent R2-D2 and grew genuinely attached to it. Then someone knocked loose the power cord on the Mac mini it ran on, and it disappeared. He never bothered to revive the agent because, by then, Codex had taken over its tasks. Dan expects his current agent, Boo, to meet the same fate within a year: “The personality thing is cool, but particularly in a work context, I mostly care: Does it do the thing?” he says. On this week’s episode of The Every Podcast, Dan sits down with Willie Williams, Every’s head of platform and one of the driving forces behind the Every Agent, which launched this week. They discuss how Every went from everyone running their own OpenClaw to relying on one shared company agent—and where they think personal agents belong in everyday life. Watch on X or YouTube, or listen on Spotify or Apple Podcasts. You can also read the transcript. Here are the highlights: Why a company agent beats a bot for every employee: After Every’s January offsite, the team came home hooked on OpenClaw. Slack quickly filled up with bots that were extensions of employees, like a “growth claw” from Every’s then-head of growth that could answer any team member’s growth questions. Over time, the bots proved hard to maintain, and it was tough to remember which one did what, so most of them died off. Personal agents brought into a workplace start from scratch and need a year to “really get up to speed,” Willie explains. A shared company agent fixes these problems. There’s one bot to keep track of, it learns a company’s workflows, and everyone improves it simply by working with it. That’s the future of agents Willie imagines: “I don’t see the industry repeating the chaos of every worker getting their own AI coworker, where we all double our company size.” Personal agents don’t belong in the office: Willie predicts that people will split their agent use between a company agent at work and an agent “that is just yours” for use at home. This is already working for him. His personal setup is a roster of Grok coaches, including a therapist, and one for lap swimming (“I’m a terrible swimmer, which is really funny because I like to surf,” he says). Separate agent personas work for him because they mirror how he’d work with humans, with a coach for each particular goal. His rule of thumb: If a task is “transactional,” it gets a Codex thread. If he’s building a relationship, it gets its own bot. Until recently, a setup like his took real commitment. Now the early drawbacks of personal agents—security, setup, and maintenance—are fading as bigger players and more money arrive. “We’re starting to get closer to a better consumer personal agent experience, and it’s going to be incredibly attractive,” he says. Why Willie’s token usage fell off a cliff: Dan has been teasing Willie for ranking low on Every’s internal token leaderboard. The reason for that, Willie says, is that engineering management is still a people job that requires spotting bottlenecks and talking to whoever can clear them. “There’s no billion-dollar—sorry, billion-token—move I can make,” he says. AI helps more with the unglamorous side of Willie’s work. A custom AI feed of Slack threads and customer reports gives him a “field marshal-level view” of the company, and an agent watches dashboards for anomalies and takes the first slot in the on-call rotation. “You have an agent on call as the first person all the time. You don’t have to worry about vacation,” he says. More on that at the end of the newsletter. This is a must-watch or must-listen for anyone deciding whether to give every employee a personal agent or build one shared agent for the whole company. Miss an episode? Catch up on Dan’s recent conversations with Sam Altman; 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; and others to learn how they use AI to think, create, and relate. Introducing Attio: the agentic CRM Transform the way revenue work gets done with Attio. Get agents that build pipeline, convert leads, and run all your sales motions. Your agents track the whole book, so you save the ones slipping and grow the ones rising. Then Ask Attio any question about your business, from the weekly forecast to performance by rep, and get the answer in seconds. For teams building the next era of revenue. Sign up now (at no cost) Want to sponsor Every? Click here. Inside Every Cost-saving at the frontier Every’s business is built on subscriptions, which include access to the Every Agent. The costs incurred by the agent are passed on to users without a markup. Our goal is to make the Every Agent as useful and efficient as possible, so members get the most bang for their buck. That makes token efficiency more than an engineering nicety: It’s part of the product. And the team’s stabs at making the agent efficient produced useful learnings. An early attempt routed all tasks assigned to the Every Agent through a cheaper coordinator model—Sonnet—which was instructed to pass complex jobs to Opus, its more expensive counterpart. Not only did the quality and speed of the responses suffer—like most of us, Sonnet isn’t great at identifying its own limitations—but costs went up. The handoff meant requests were often processed by both models. Engineer Paridhi Agarwal digested the disappointing results and promptly changed course. “We don’t necessarily need a complex engineering system to solve a problem that comes from inefficiencies in our own codebase,” she remembers thinking. Her instinct was right. Paridhi looked for waste in the system and, through a model upgrade and a handful of targeted changes, reduced token costs across 11 frequent tasks by more than 80 percent. The changes Paridhi made to lower the cost of running the Every Agent. (Screenshots courtesy of Laura Entis.) The lowest-hanging fruit was switching the Every Agent from Opus 5 to Opus 5.5 after its release. Response quality improved, and token costs noticeably dropped “within a couple of hours,” Paridhi says. Then she started looking at what the Every Agent was being asked to read and reduced the amount of information. Its tools—the connections that let the agent access services like GitHub and Linear—were returning large amounts of data, including internal details it didn’t need. She rewrote them to return shorter, clearly labeled results, while retaining critical information. She also changed how the agent loads tool information. It now starts with just the name and a short description for the most frequently used tools, loading full technical details and other tools only as needed. Together, these changes gave the model less text to process and reduced token costs by roughly 10 percent. But the biggest discovery was a bug that Paridhi found with help from Opus 5.5. With every new conversation, the Every Agent also receives standing instructions about how to behave—its system prompt. Processing those instructions each time costs money. To lower costs, Claude can temporarily save and reuse the work of processing those instructions, a practice called caching. But the text must stay identical. The team assumed caching was working. It wasn’t. Claude automatically adds memory folder names to the system prompt, and Every’s included each user’s Slack ID—an easy detail to miss. Those names made the prompt different for every user, preventing the cached version from being reused across users. The fix was straightforward: Paridhi gave every memory folder the same generic name and kept Slack IDs where the model couldn’t see them. Each user still had access only to their own memory, but caching now worked as intended. In her best-case test, this cut token costs by 74 percent, on top of the savings from the tool redesign and model upgrade. “Sometimes the solution is simpler than you think,” she says. Steal this workflow Make your AI more efficient Opus 5.5 served as Paridhi’s coding partner, helping her investigate why the Every Agent cost so much to run. She supplied context, questioned the test results, and directed it to investigate unexplained costs. Here’s how to use that approach to fix inefficiencies in your own software. 1. Explain what you want to improve and give your agent the context it needs to understand the issue. Start with a specific goal—cost, speed, or repetitive work—and give your agent access to any relevant code, documentation, and tools. Paridhi asks the agent to read the codebase and explain its diagnosis of the problem before proposing changes. She also consults current documentation and supplies details about new features, which can ship faster than a model’s training data can keep up with. Prompt I want to make [project or system] more efficient. Specifically, I want to [reduce costs / make a task faster / eliminate repeated work], without compromising [what needs to keep working well]. Before suggesting fixes: Read the relevant project files. Explain in plain language how the system currently handles [task or process], including which models, tools, and services it uses. Read the current official documentation for those models, tools, and services. Don’t rely only on your existing knowledge. Tell me if you can’t access something. Consider these features or capabilities I think might help: [links or descriptions, or leave blank]. Summarize what you understand and flag anything you still need to know or verify. Don’t change the code yet. First, give me your explanation so I can check it and correct anything you’ve misunderstood. 2. Develop possible fixes. Ask the agent where your software might be doing unnecessary work and have it suggest changes, with explanations for how each potential fix would help. Instruct it to check whether the models and services you already use offer features that could address the problem before proposing something built from scratch. Bring your own ideas, too. Paridhi knew about a Claude feature called “deferred tool loading”: Instead of giving the agent instructions for every tool at every step, the feature automatically loads instructions for just the most frequently used tools, and looks up the other tools only when a task calls for them. She asked the model to consider the feature as a way to cut costs. Prompt Now that you understand how this system works, suggest ways to improve [cost / speed / repeated work]. Look for unnecessary work and check whether features offered by the models, tools, or services we already use could help. Also consider [any ideas or features I want to explore]. For each proposed change, explain: What the system does now What you would change and why it might help How we could test whether it works Distinguish findings supported by the code or documentation from ideas we still need to test. Don’t change anything yet. 3. Measure whether a proposed fix helps. Have the agent run the same tasks before and after one change, then show you the difference in cost or time. Make sure to compare the quality of results: A cheaper or faster response isn’t an improvement if the responses themselves get worse. Investigating a possible fix can uncover a bigger problem. Paridhi asked Opus 5.5 to test whether loading fewer tool instructions would make conversations cheaper. The savings, it turns out, were small, but the tests exposed a much bigger expense: The Every Agent was repeatedly saving instructions but not reusing them. She asked Opus to investigate, which led her to identify the caching bug. Prompt Test [selected change] in a safe working copy, not the live system. Run the same representative tasks before and after the change. Keep other conditions as consistent as possible. Show me: The measured [cost / time / repeated work] before and after Whether the results are still correct and useful Any remaining costs, delays, or unexpected behavior Separate measurements from estimates. If you can’t measure something reliably, explain what’s missing. Don’t deploy the change. 4. Investigate any remaining problems. Ask the agent to reexamine the code and test results. What is still expensive, slow, or repetitive—and why? Have it trace the cause and suggest a fix, then repeat the tests to check whether the change helps. Prompt Review the test results and take another look at the code with those findings in mind. What work is still taking more than [a specific period of time] or costing more than [a certain dollar amount]? Is it necessary, or could the system be repeating or doing work it doesn’t need to? Trace any suspected waste to the relevant code and logs. Explain what the evidence shows, what remains uncertain, and whether existing features could help. Propose the simplest fix and a test that would show whether it works without breaking anything else. Don’t make further changes until I approve the plan. The daily driver The models the team is using this week: Nityesh Agarwal, senior applied AI engineer—Opus 5.5: “I even stopped using Fable 5.1 completely and now I’m rarely running out of usage.” Randy Counsman, head of video—GPT 6.1 Sol (high), switching to Astra for harder tasks and Opus 5.5 for anything design- or image-related. A major caveat: “I feel like I just ‘use Dot’ now... I had to go and check my history to see which models I was using for certain tasks. Otherwise I don’t think about it and just talk to Dot.” Becky Isjwara, head of social media—Opus 5.5 (medium) for video and writing; GPT-6.1 Sol (medium) for everything else, including computer use, scheduling posts, and everyday admin. “Astra was cool, but too slow for me,” she says. Tyler Nishida, designer—Opus 5.5 (max) and Sonnet 5.5 (medium). Katie Parrott, staff writer—A “seeeeecret model” she’s early-testing is her number one, followed by Astra, Opus 5.5, and Sol (GPT-6, then GPT-6.1). “Overall, I’m splitting 55 percent to 45 percent Claude vs. GPT at the moment, which reflects the ‘Claude for creative, OAI for admin’ split that I’ve been in since the 5.5 class started rolling out from Anthropic and won my heart back for writing.” Arielle Shipper, head of operations—Sol (medium) remains her default—“I am a creature of habit and don’t like fixing what isn’t broken”—although she now toggles to Opus 5.5 for creative work. Arielle’s commitment to GPT-6 Sol turned Becky into a convert. Dan Shipper, CEO—An unreleased model he’s early-testing dominates his usage, followed by Astra and GPT-6.1 Sol. Loren Stewart, engineer—Opus 5.5 for coding and thinking. “I love it. It’s such a good model for... everything I do!” He’s started to experiment with GPT-6.1 Sol but hasn’t used it enough to have a firm opinion yet. Mike Taylor, head of evals—Opus 5.5 (medium). His Astra usage took a recent nosedive given he had fewer computer-use-heavy admin tasks and has moved all new threads to Claude. Thesis Statements In August, we launched Thesis Statements, a collection of specific, contestable claims from builders and thinkers about the future of great human work with AI. This week, we have seven more predictions from people at the frontier: The arguments we hid behind shared vocabulary will become explicit by Alex Duffy, cofounder and CEO of Good Start Labs Managing decision fatigue will become part of making great work by Laura Entis, staff writer at Every You’ll give your Legos away to agents by Brandon Gell, chief operating officer at Every Nothing will go wrong twice by Kieran Klaassen, creator of Compound Engineering and member of the frontier team at Every Describing a problem will be enough to begin solving it by Naveen Naidu, general manager of Monologue Your expertise will belong to your employer—unless you can make it portable by Kaushik Viswanath, managing editor at Every History will be rendered, not read by Willie Williams, head of platform at Every If you want to help decide what matters in the future of AI and human work, think creatively, and build what comes next, join us at our inaugural Thesis: 2027 conference in Brooklyn on November 5. Jagged frontier The guide to being an AI-first engineering manager Any manager will tell you that one of the hardest parts of the job is just understanding what the hell is going on half the time. Managers typically operate at one to 10-plus levels of remove from the actual work—a situation I once heard described as trying to push a ping-pong ball into a cup using only a long stick made of chopsticks held together with bubble gum (with a chopstick added for every layer). Information coming back to you travels that same distance, affected by forgetfulness, ego, confusion, and, in the worst cases, malice. To mitigate this, we’ve come up with managerial infrastructure like standups, staff meetings, and 1:1s to try and sort out who did what, who said what, and what needs to happen now. AI now allows us to skip the age-old game of organizational telephone, and go directly to the source by setting up a feed. The first and most foundational step is to ensure all meetings are automatically transcribed. This has become the social norm at work because it helps individuals keep track of action items and details, but transcription is becoming indispensable at an organizational level, too. At Every, we transcribe all our meetings, even when we’re together in person. It’s become second nature. The next step is to attach an AI to this feed of meeting transcripts your company is generating. We tend to use Tend (har har) to do the attaching, but even a local automation in Codex will do. The automation should scan the feed and extract anything you deem to be relevant, like key updates and action items, and store it for your later review. This simple setup is powerful and flexible enough to give an engineering manager ongoing insight into the team’s operations, allowing them to perform continuous conflict resolution and coaching by scanning these updates. If you expand the feed to include the stream of pull requests being created, reviewed, and merged in GitHub, you can even get an updating real-time picture of engineering progress. The end result is a persistent up-to-date picture of everything happening above, below, and around you. The quality of your decisions as a manager depends on the quality of the information reaching you—and a feed like this gives you more of the original information, with fewer layers of interpretation. You’re still holding the same ridiculous stick made of chopsticks and bubble gum. But it’s a lot easier to decide where to push when you can see what’s happening at the other end.—Willie Williams Laura Entis is a staff writer at Every. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn. Stop explaining AI to your team and start showing them. Every Agent does the work in Slack, where everyone can see it, so one good workflow quickly becomes the whole team’s. Subscribe --- # Introducing the Every Agent TL;DR: Today we’re launching the Every Agent, an agentic coworker in Slack that helps you AI-pill your whole company. Delegate complex work, share your best AI experiments with your team, and get personalized Frontier Alerts that ping you when a new model or tool ships and tell you what might be useful for your specific workflows. And you get it all with zero percent markup on tokens: What we pay is what you pay. Try the Every Agent today: Get the Every Agent It’s our job to stay at the edge of AI. But even at Every, it’s hard to turn our new AI workflows and tools into team-wide habits. For example, I’ll lovingly clone our editor in chief Kate by taking 30,000 of her historical copyedits and turning them into a skill that lets us edit like her. But getting the skill adopted feels like shouting into a hurricane. Everyone is busy, and there’s no time to try every new skill or tool. What feels like a breakthrough for me ends up turning into one more thing at the bottom of their to-do list. The best solution for this, we’ve found, is working in the open with a company agent that lives in your Slack. It lets you show instead of tell your coworkers about your discoveries. New AI tools and workflows can spread naturally and virally across your organization. That’s why we built the Every Agent. The Every Agent is an AI coworker in Slack that helps you AI-pill your whole company. We built it for ourselves first, to solve situations like mine. When I cloned Kate, instead of badgering people about my new copyediting skill, I installed it in the agent. Then, whenever we were working on a new piece of writing, I’d post, “@Every, give this draft a Kate Pass.” The agent would leave its suggestions directly in the Google Doc, where my coworkers could see what it did and try it on their own drafts. Now it’s a standard part of how we work at Every—no explaining required. For almost six months now, we’ve used the Every Agent to get work done together. It’s become indispensable for keeping our whole team working at the frontier together. Today, we’re releasing it to you. The Every Agent has everything you’d expect from a top-tier agentic co-worker: Your whole team can delegate complex tasks in Slack—from pull requests, to marketing plans and finance or data science questions—and expect high-quality work back, done quickly. But it’s distinctly Every-flavored: It comes pre-loaded with all of the skills and workflows we use to run the company, and is equipped with personalized Frontier Alerts that ping you whenever we publish something on Every that might improve your workflow. We also add zero markup to the tokens you spend on the Agent—what we pay is exactly what you pay. Best of all, each person on your team gets $15 in free credits to try it. If you want to keep your team working at the frontier, you should install the Every Agent in Slack today: Add the Every Agent to Slack Why you should prompt in public Prompting in public works because most AI use is invisible. You do it alone, in a terminal or a chat window. Your coworkers see the finished report or the five new ads, but they never see the request that produced them, or the corrections you made along the way. When you describe it afterward, it sounds like magic, but nobody learns a magic trick without seeing how it’s done. In a Slack channel, a coworker who would never open a terminal scrolls past the thread and thinks: I could ask for that. We learned this the slow way. In March we launched Plus One, which gave each person their own agent in Slack. Some fell out of use once the novelty wore off, but a handful stuck around and became workhorses. Colleagues went straight to mine, R2-C2, to report bugs and request features for our AI document editor Proof. Watching those exchanges helped people learn what agents could do—and trust them enough to try it themselves. After almost a year of experimenting, we’ve found that one shared agent, working in public, AI-pills a company faster than a horde of personal ones. So Plus One is now the Every Agent: a single agent the whole company shares, built with Claude Managed Agents. How the Every Agent works You tag @Every in any Slack channel, tell it what needs to get done, and it does the work in the thread. It learns your company as it goes: When something isn’t right, you correct it in the thread, and it can save the correction for next time. Your Every Agent shows up ready to work: Every’s workflows are built in. The skills we use to run Every come pre-installed, from Compound Engineering to Compound Writing. We add more all the time. It connects to your tools. Connect Google Drive, Gmail, Notion, Figma, GitHub, HubSpot, and more than 1,000 other tools once, then choose which teammates can use each connection. Nobody has to rebuild your setup in their own Claude or Codex account. It comes with Frontier Alerts. Whenever a new model drops, the Every Agent looks through your current tools and workflows and lets you know if the model is worth paying attention to, for you. It helps you spread your best experiments. When a workflow is worth repeating, you ask @Every to save it as a skill. From then on, anyone on the team can run it. The way your best person does something—including every correction they made to get it right—becomes something the whole company can do. How we use the Every Agent at Every The best way to explain what the Every Agent can do is to show you what our team has asked it for in the last few weeks. Brandon Gell, our chief operating officer, asked @Every for a speaker agreement for our Thesis conference. It created the contract in Documenso and drafted the email to go with it. The email came back as one collapsed paragraph, so Brandon sent it back. The agent fixed the draft and updated the skill to check the rendered email next time. Now anyone at Every can send a properly formatted speaker agreement. Brandon also saved a skill for turning Slack threads into animated videos. Becky Isjwara, our head of social media, used it the same day to make a 13-second clip. Douglas Brundage, our head of marketing, used it to make the GIFs in our launch emails. Douglas, by the way, used to think PR only meant public relations. Now he asks for pull requests from Slack. He had @Every pull approved speaker assets from Figma and open a PR adding two speakers to the Thesis site, and an engineer reviewed and merged it. Arielle Shipper, our head of operations, uses @Every to combine performance, website, and email data into a weekly report for the leadership team. It flags the numbers that don’t add up. Mike Taylor, our head of evals, built a skill that reviews unfinished work and updates his priorities every Monday. Nityesh Agarwal, one of our engineers, now uses it every week. I use it to find every mention of my name in notes from meetings I wasn’t in. If a discussion needs my input, I can follow up with the people involved instead of waiting for someone to brief me. The Every Agent has also handled our time-off requests, negotiated our cell phone bill, hired a handyman, and run the company fantasy football league. This is what AI-pilling a company looks like: The knowledge stops living in one person’s setup and starts moving around. What beta users are saying A group of companies has been using the Every Agent in beta. Here’s one of our favorites, from George Eastwood, executive director of the Emily Whitehead Foundation: “For me, that’s the promise of Every Agent: not simply automating work, but giving a team a shared capability that improves as we learn how to use it together.” Pricing and availability The Every Agent is available today for any Slack workspace. You’ll need a free Every account and permission from your workspace owner to install it. Each person gets $15 in free credits, up to $500 per workspace. After that, a paid Every subscription keeps @Every working, at $30 a month. The subscription includes the rest of Every, too: our apps and our full archive. You pay the AI models’ token costs separately, and we add no markup. As the models get cheaper for us, they get cheaper for you. If you want to see it in action first, we’re hosting a camp on working with agents in Slack this Friday, October 9, at 12 ET. RSVP to Agent Camp If you’re the AI-pilled one at your company, you can stop explaining. Do your work where everyone can see it. Add the Every Agent to Slack Dan Shipper is the cofounder and CEO of Every, where he writes the Chain of Thought column and co-hosts the The Every Podcast. --- # When Trying to Make AI Better Makes It Worse Was this newsletter forwarded to you? Sign up to get it in your inbox. It is a well-known fact that the Germans have a word for everything. Kummerspeck, literally “grief bacon,” is the weight you put on from emotional eating. Torschlusspanik, “gate-closing panic,” is the fear that time is running out to do the thing you’re supposed to do with your life. Recently, I came across another gem: Verschlimmbesserung, or “worsen-bettering.” It refers to our desire to make something better, only to make it worse. Used in a sentence: “Ich habe meinen Kontext verschlimmbessert,” or “I have worsen-bettered my context.” That’s precisely what I did to the context that drives my AI setup over a few weeks in September. By “context,” I’m referring to the style guides, examples, and instructions that tell Claude and ChatGPT who I am, how I write, and what I’m working on. When my context is good, my AI “assistants” can find what they need to do work the way I want them to do it—including writing essay drafts the way I want them written. But a few weeks ago, my context went bad, and so did my work. Drafts came back crowded and flat. When I told the model what was wrong, the next draft came back worse. The system I’d built to keep me afloat started pulling me down with it. For a while, I stopped trusting my context. Then I stopped trusting myself. You don’t need an elaborate setup to run into this problem. You might have asked your AI to keep answers short, then found yourself fighting it for a thorough explanation, or saved a successful draft as an example and watched its quirks turn up in everything that followed. A preference that helps with one task can get in the way of the next, especially when it has to coexist with everything else you’ve ever asked the model to remember. If you haven’t built your own context yet, consider this a cautionary tale. If you have, and you’ve watched yours get unruly, I’ll show you how I figured out what went wrong, how I tore the whole thing down and rebuilt it, and what principles I’m using now to keep my guidelines from hardening back into rules. How my context worked, back when it worked Before I get to the wreckage, I want you to see the thing when it was working, because it worked beautifully. That’s what makes the rest of this story so annoying. The arrangement was simple. Every column I wrote (Working Overtime, Vibe Check, Context Window) got its own folder, and every folder held the same three things: a voice guide for how my sentences should sound, a style guide for what the column is for and how a piece gets written, and drafts that showed the model the writing I was after. Above them sat my Command Center folder, with the high-level facts about me, my job, and my preferences, and a map to everything else. When I start a task in one of those folders, the model first reads a short instructions file, called AGENTS.md, that tells it how to behave and what else to read—for example, in my writing folders, the STYLE.md and VOICE.md that tell the models how to write like me. Then it reads those things and treats them as part of the assignment. If the instructions say read it, the model’s going to read it. Chefs call this kind of preparation mise en place: everything chopped, portioned, and within reach before the first ticket prints. This was mine, and it let me cook everything from personal essays to news roundups to in-depth model reviews, all (for the most part) without dropping any plates. I had a simple system that I understood, and it was producing the fastest work of my career. There was nothing to fix. Naturally, I decided to fix it. Three ways I made a working system ‘even better’ Dan Shipper has a saying: Never make a major life decision within 30 days of a meditation retreat, a psychedelic experience, or an encounter with a new frontier model. I’d consider rearranging my context a major life decision, and I did not wait the requisite 30 days following the release of GPT-6 Astra before I started making decisions that would turn out to have a big impact on how I work. I looked at my tidy little folders and asked the question that has ruined many a good thing: How can I make this even better? I came up with three answers, each of which I was convinced was the next big thing in context engineering. Each one also changed what the model read before it started working, which is the part I didn’t think through. First, I decided to save everything. If AI was helpful when it remembered some things, how much more useful would it be if it remembered everything? I added two lines to my instructions: “Every experiment must leave a durable record… Failed, abandoned, interrupted, inconclusive, and superseded attempts count.” And: “Repeated mistakes should become review checklist items.” My goal had been for AI to be able to reference past outputs if they became relevant in a future conversation. But in practice, every essay got a running log of everything that happened to it, and the model read that log before it went back to work. Every note I gave went into the log. Any note I gave twice became a checklist item that every later draft had to pass. Next, I decided to connect everything. Around this time, I discovered the Zettelkasten, a method of note-taking in which every idea links to every related idea. So naturally, I added that to the list of ideas I applied to my context. I linked a Working Overtime idea to a Source Code idea and a Context Window draft to a Vibe Check template, until 385 files pointed at files in other folders on my desktop. And finally, I told AI to codify everything. Every pattern I noticed and every observation that felt like it should be a principle went into my style and voice guides. A good opening became a template for that type of opening. The style guide for this column alone grew from around 759 words to 3,855, with eight approved ways to begin, six approved ways to end, and two checklists. It was supposed to describe how I write, but it had become a list of impossible, contradictory, self-defeating demands that every essay had to meet—and that no one essay could reasonably satisfy. Remember how this works: Before it writes a word, the model reads the instructions file and everything that file points to, and it treats all of it as part of the assignment. Before September, the list a model had to go through was a short voice guide, a short style guide, and a few drafts. Now it included a 3,855-word style guide full of approved openings and endings, a running log of every experiment and correction on the piece in progress, and whatever those 385 links invited it to read in other folders. And the stack grew every day. Each time I corrected a draft, the correction went into the log. A second line in my instructions, “Repeated mistakes should become review checklist items,” turned any note I gave twice into a test that every later draft had to pass. The model couldn’t tell a record from a rule, so it followed all of them. I’d built a system that turned my reaction to one draft into law for every draft after it. The only thing that had changed was my context The thing that makes bad context so hard to catch is that you never see the pile of rules your model is working through. You see the draft it hands back, and a bad draft looks like the model got dumber, or you did. I found out while writing the previous edition of this column, an essay about what playing with AI taught me about my work. The drafts fought me from the start. They read as if a committee had written them, with every point I’d ever raised wedged in and none given enough room to make sense. One night, I told the model its outline was “UNRECOGNIZABLE relative to the instructions that the skill has.” Another night: “here I am yet again explaining stuff to you that you need to be able to find in the context.” Each time, the next version was worse. By the end, the folder for that one essay held 127 drafts and more than 1 million words, roughly the entire Harry Potter series, produced for an essay you could read on your lunch break. I knew I couldn’t keep working like this, and I’d started to suspect my context was to blame. Late one night, I told Codex, running GPT-5.6 Sol, that we needed to look at my voice and style guides “and see if there is any guidance in those documents that may have caused conflict or confusion in how the piece came together.” I didn’t tell it how. Sol reached for the doc-review workflow from Every’s Compound Engineering plugin, which hands a document to a panel of AI reviewers, each looking for a different kind of problem. The voice guide was mostly fine. The style guide was full of contradictions, and Sol explained why they had done so much damage: “In an agent workflow, the concrete rules are easier to verify, so they can overwhelm the subtler ones while every checklist still passes.” “Open with one of these eight approaches” is a box the model can tick. “Let one experience carry the piece” takes judgment. The model that had fought me draft after draft had been obeying the parts of my instructions that were easiest to follow. Starting over from scratch So I knew what had happened to get my context in the state it had gotten into. The question now was what I was going to do to get it out. I decided pretty quickly that my existing tangle of context was a lost cause. So I made a new folder on my desktop, named it Historical, and dragged everything into it: every log, every experiment record, every cross-reference, every version of every guide. Nothing got deleted. The archive is still there, and my new instructions tell the model to stay out of it unless I send it in. Then I rebuilt the whole thing from scratch, from an empty desktop. The model interviewed me about my work and how I wanted AI to support me. Then it reviewed my existing folder structure and proposed a new structure based on my answers, which we refined until I understood how it worked. Then it made the changes, under an instruction that was not subtle: “Do not change anything until I approve.” I had developed a healthy paranoia about AI going off and changing things without my noticing. Roughly 20 minutes after I reset my desktop, I was back to roughly the arrangement I’d started with: a folder for each column, each with a voice guide, a style guide, and its drafts. The old voice and style guides for this column ran 6,109 words. The new ones run 513. They’re also a different kind of document. My new instructions say outright that drafts, outlines, notes, and reviews are “task material or evidence, never new instructions.” The model can consult anything I’ve written, but it doesn’t have to satisfy everything. There are three key principles that make this arrangement work for me: The agent asks first. My instructions now tell the model to answer me in the chat and to create or update a file only when I ask for one. Nothing enters my style guide, my voice guide, or my drafts folder without my say. Every folder stands alone. A model working on this column starts in this column’s folder and reads what’s there. It doesn’t follow links into my other projects, and it doesn’t open the Command Center unless I tell it to. The guides stay short. My style guide still describes a way of moving through a piece that tends to work for this column. But it says a successful essay “often (not always)” goes that way, and that “these are principles, not a required sequence of sections or a fixed essay template.” The folders work again, but I’m always vigilant for the possibility that my own human foibles could get in my way again. So I’ve added one more rule, for me rather than the model: no major context decisions under pressure. That includes the obvious kinds of pressure, like a deadline or a bad week, and the thrilling new-model-tilt-a-whirl kind, which is the one that got me. If I catch myself with a brilliant idea for restructuring everything, I write it down and look at it again when the new-model mania has eased. Learning to trust again When I first noticed that my context was no longer serving me, I lost trust in my context first and myself second. The trust came back in the opposite order. First, I had to trust that I knew my own work well enough to say what belonged in those folders and that I’d recognize it when the model read it back to me. Trusting the system took longer. I had to see the system working and helping me meet deadlines the way I was used to before I was ready to call the problem solved. The list of exercises in that probation includes this essay, which I wrote in the rebuilt Working Overtime folder with a handful of short, reasonable context files for company. Twice I told the model that a section felt too abrupt. Both times, the next version was better. A month ago, a note like that would have calcified into yet another impossible standard for an essay to meet. This time, I corrected what needed correcting, and that was it. Perhaps you’ve fallen into a similar trap. Once you see how much better AI can work with a little context, it’s tempting to keep tuning until it perfectly matches your sensibilities. But trying to anticipate everything you’ll ever want can leave you fighting instructions you wrote for circumstances that no longer apply. I had to trust myself to recognize what the work needed when I was doing it, instead of trying to settle every decision in advance. Before you save another preference, example, or instruction to your setup, ask whether it belongs in every task or just the one in front of you. And when an “improved” setup starts giving you worse results, try taking something away before adding more. You don’t have to wait until you’ve produced a million words to investigate. I’d like to tell you I’ve learned my lesson for good. But there will be another model, and it will be dazzling, and I will get another brilliant idea for making this even better. The Germans, as we’ve established, already have a word for what happens next. Katie Parrott is a staff writer at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # ChatGPT Wants to Be Your Operating System Hello, and happy Sunday. After nearly three years and 108 episodes, AI & I has a new name: The Every Podcast. (It’s the show’s second rename; it started life as How Do You Use ChatGPT?) Dan Shipper taped the first episode on site at OpenAI’s DevDay with Sam Altman. A reminder: Thesis: 2027 is down to its last tickets, and the price goes up on October 15.—Kate Lee Was this newsletter forwarded to you? Sign up to get it in your inbox. Vibe Checks Two from OpenAI’s DevDay and one from Anthropic—here’s where we came out on each. “Vibe Check: OpenAI DevDay 2026” by Dan Shipper/Vibe Check: OpenAI wants ChatGPT to become your operating system for work, and Dan sorted its 22 DevDay releases by how much each one advances that goal. The five most important ones: Dots, an always-on agent, and Space, native documents the agent can edit, are the workspace itself. Plugin extensions and a subscription you can use in 16 partner apps let other software connect to ChatGPT. Decisions API is OpenAI’s answer to Jev, and Dan thinks it could be the biggest release of the day if it’s cheap. His verdict after a week: The ambition is big, the execution isn’t there yet, and even a power user has a lot to figure out. 🔏“Vibe Check: Dots—Always-on Agents in ChatGPT” by Dan Shipper/Vibe Check: Dots has become the main way Dan uses ChatGPT. His Dot, Boo, caught that a flight he was rebooking clashed with a meeting proposed in a Slack thread he hadn’t read. But his Dot also drops messages, loses its connection to his computer, and makes him log in to every service twice. Dan’s verdict: Try it if you live in ChatGPT. If you already use Grok Bots, Muse, or Instinct, stay put for a week or two. “Vibe Check: Sonnet 5.5 Finds Its Place in Claude’s Crowded Family” by Katie Parrott/Vibe Check: In July, Katie and the team couldn’t find a use case for Sonnet 5. But Sonnet 5.5 has one: It is the model you steer—brainstorming, prototyping, design, outlining—at half the price of Opus 5.5, while Opus takes the long, unsupervised runs. Kieran Klaassen works that way now. Sonnet 5.5 writes plainly and edits well but needs clear limits. Protocols Five prompts from this week’s how-to on using AI to get better at AI, by Arielle Shipper. Let your agent coach you Ask where you stand. Arielle gave Codex our “Eight Levels of AI Adoption” guide and asked it to grade her from their past sessions, and it put her at 5.5. The prompt Ask what would move you up. She asked what would take her to the next level, and Codex redrew a Stripe data pull she had already finished as a team of specialist agents. The prompt Make it explain the jargon. When Codex told her to use a schema mapper and a tax-logic verifier, she asked what that meant in practice and how to run it on her own work. The prompt Put the review on a schedule. A weekly task scans her sessions and sends a graded report every Friday afternoon, which has moved her up more than two levels since June. The prompt Save the solution, not just the correction. After Codex wrote Slack messages in a voice she would never use, she had it diagnose the failure and write the rule into her instructions, the start of her Self Improve skill. The prompt Knowledge base 🖥🎧“How Sam Altman Uses Dots to Take Back His Time” by Laura Entis/The Every Podcast: The OpenAI CEO talked to Dan about how he uses Dots and more. Altman’s Dot now triages his mornings, so he gets that time back for thinking or for his kids. He leaves his Dot voice notes before bed; the agent builds features overnight for him to review the next day. Altman pays eight times the standard rate to prompt on Ultrafast because its speed helps him think through ideas more quickly. He argues AI is ushering in another Renaissance, not turning people into cogs. 🖥🎧 Listen on Spotify or Apple Podcasts, watch on X or YouTube, or read the transcript. “Getting Started With Open Models” by Kai Zau/Guides: Our first comprehensive guide to open models. Kai Zau, who runs millions of tokens a day through a Mac Studio, starts with an audit of your work to find the tasks that don’t need a frontier model, then walks through three steps: Choose a model, choose where to host it, and connect it to the tools you already use. Each step comes with the prompt to run it. Thesis Statements Read seven more predictions from frontier builders and thinkers in Thesis Statements, a collection of specific, contestable claims about the future of great human work with AI. Intelligence will be abundant. Organizational intelligence won’t by Stephanie Carl, vice president of member experience at Corning Credit Union Your agent will know what you want. That won’t mean it’s working only for you by Trevin Chow, product leader and former chief product officer at Big Cartel Unmeasurable work will stop being a luxury by Calum Forsyth, founder of Tanis Labs “Maybe someday” will become “start now” by Derek Keller, founder of Governed Work System Our own work will become our most valuable curriculum by Lee Knowlton, software engineer at Every We’ll stop designing processes around human limits by Daniele Tassone, head of AI engineering at Genie AI Most people will use AI to do their jobs, not reinvent them by Ryan Wright, senior director of consulting at Every Join us at our inaugural Thesis: 2027 conference on November 5, 2026. Fewer than 35 tickets are left, and the price goes up on October 15. Work at Every We’re hiring an executive assistant and office manager. It’s a role for keeping our Brooklyn brownstone running day to day, from laptops to snacks to onboarding, and for being the right hand to CEO Dan Shipper on calendars, travel, and correspondence. We’re looking for someone detail-oriented who already uses tools like Codex and wants to build automations that cut down on recurring manual work—and then write about them for Every. Know someone who’d be great? Learn more and apply. See the rest of our open roles on the careers page. Alignment Self-driving labs. One of the factors slowing AI’s progress in drug discovery is how long it takes to find out whether the model’s predictions are any good. A biological AI model can suggest a molecule that might become a useful medicine, but humans still need to test those ideas against real cells to verify the prediction. The results can then help improve the model’s next suggestion. Much of this feedback loop depends on humans doing physical labor like moving pipettes, preparing samples, running experiments, and recording the results—which takes a lot of time and money. (Unfortunately, humans also need to sleep.) The financial incentives to hyper-speed this feedback loop are so enormous that we’re likely heading toward a future where self-driving labs will automate away many of the time- and resource-consuming tasks a human does now. The human will become more of a tastemaker, using their lab experience to direct and guide the AI toward interesting findings. Companies are already working on building that future. In January, Nvidia and Thermo Fisher, which makes laboratory equipment, announced a partnership to connect AI with scientific instruments and automate more laboratory work. We can expect more collaborations like this, and a wave of spending from pharma companies and biotech firms to upgrade the equipment, software, and processes inside their labs.—Ashwin Sharma That’s all for this week. Follow Every on X at @every and on LinkedIn. Thanks to Eleanor Wikstrom for editorial support. Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$9,000+ in credits for the tools we build with. Upgrade to paid --- # How to Get Better at AI by Asking AI Was this newsletter forwarded to you? Sign up to get it in your inbox. For most of my working life, the first step of any task began with a blank slate: an empty Google Doc, a fresh email, or a new Excel spreadsheet. From researching to writing formulas, the banalities of every stage of construction fell to me. AI made that process faster, but the way I accomplished it wasn’t all that different. I started with a new chat and prompted it over and over until the output matched my unspoken definition of “done.” When I started at Every in May, I was still working that way. When I needed to issue contractor payments, I worked from one chat thread, prompting sequentially to surface agreement terms, approve payment, and send email confirmations that payment had been issued. Things look very different today. Last week, I needed to verify the cost of purchasing equity for an employee across multiple grants, strike prices, and vesting schedules. Rather than tackle this complex task in a single thread, I split the project among several subagents that coordinated independently to verify information on signed agreements, run the math, double-check it and flag discrepancies, and return a draft of a Slack message that I could approve with a simple “yes.” That work ran on skills, orchestrator threads, context packets, subagents, MCPs, and computer use. It’s a veritable alphabet soup of technical terms that I was previously sure could only be understood and deployed by Highly Technical People, yet I now find myself reaching for these techniques daily, helping me work faster, with better and more precise results that I can be confident about. I was prompted to make the shift from a tweet. Katie Parrott tweeted in June that she had asked Codex where she fell on Mike Taylor and Laura Entis’s guide to “Eight Levels of AI Adoption,” and I saw an opportunity to better understand my place in the ecosystem. The guide is a framework that maps a progression from basic chatbot use to full agent orchestration, with each level delegating more work—and trust—to AI. Codex placed Katie at Level 5 (building workflows that make an agent’s output consistent and reliable), with the beginnings of Level 6 (an agent that works proactively in the background without waiting for a prompt). Katie Parrott asks Codex to assess her level of AI adoption. (All screenshots courtesy of Arielle Shipper.) Asking Codex to assess where I fell on the framework kick-started leveling up my skills with AI. I quickly realized that the best teacher to help me improve had been in front of me the whole time: the AI itself. Here’s how I did it—and how you can, too. 1. I asked my agent to assess how I worked I gave Codex the same article and asked a very simple question: “What level am I based on how we’ve been working together thus far?” Because Codex could look across our past sessions, its answer was based on my actual work patterns and far more insightful than if I’d had to read the article and figure out how to level up on my own. Codex places me at level 5.5 and identifies orchestration as my next step. (Recreated from a Codex conversation.) Codex put me at 5.5: solidly at Level 5, with some Level 6 habits. I was using it deeply, but still tended to give one agent a large job and work with it until the job was finished, rather than deputizing multiple agents with distinct roles. I wasn’t even sure what it meant to use one agent vs. several agents concurrently. Try it: If you’re using AI consistently for your work, pick the agent you use the most and ask it to look across sessions to level you. If you’re not using it daily, wait until you’ve built up a week’s worth of chats so it has data to pull from. Prompt Read this article on the eight levels of AI adoption (https://every.to/guides/the-eight-levels-of-ai-adoption), then look across our sessions. Based on how we’ve been working together, what level am I? Include specific examples in your assessment. 2. I turned the assessment into recommendations I’m constitutionally incapable of resisting the temptation to level up, so I asked: “Can you look across past sessions and suggest what would take me to a 6 or 7? How can I use you more effectively? What opportunities did I miss?” Codex found concrete examples in my work history, like a project where I was using a Stripe API key (another first for me!) to pull transaction data to determine which states we needed to collect sales tax in. The data needed to be exact, and I’d struggled to cross-check it without actually being in the Stripe interface, but Codex showed me how I could have divided the work among subagents in different threads: a specialist to pull data, a specialist to verify it was correct and complete, and a Google Sheets workbook builder to assemble it in the format our accountants requested. Codex shows how a team of specialist agents could have handled my Stripe project. Merely saying “use multiple agents” wouldn’t have changed my behavior. Seeing a better setup for a project I’d already completed gave me something I could try the next time a similarly messy project came across my desk. Try it: Pick a project you’ve already finished and ask how it could have run at the next level. Prompt Can you revisit my recent work and suggest up to three tactical things to try to take me to [next level]? Be specific and contextualize your recommendations in past projects or working sessions. 3. I asked Codex to teach me how to make the change When Codex first came back with recommendations, it told me to delegate to a schema mapper, a Stripe API extractor, a workbook builder, and a tax-logic verifier. I had literally no idea what any of that meant, and importantly, I didn’t understand the practical part. Was I supposed to open five chats? How would each agent get the right context? Who would reconcile their answers? So I asked. Codex explained it the way I’d run a project with teammates. One lead, an orchestrator, holds the business goal, constraints, deadline, and definition of done. It gives each specialist a context packet—the minimum background, source material, constraints, and success criteria needed to do its part without inheriting the entire project—then pulls the results back together. Codex explains how to coordinate specialist agents through one lead thread. (Recreated from a Codex conversation.) Then I tried it on my work, assigning each subagent a distinct role. In essence, I was breaking down a project into distinct components and assigning them to agents that were uniquely equipped to do that particular task, just as I’d delegate to different teammates in real life. I started keeping one chat per project that acted as the manager, which handed tasks off to separate AI agents and kept track of the results. For high-stakes work like data pulls or analyses, I added skeptic and verifier agents whose only job was to challenge assumptions and to ensure the outcome was accurate. For example, the agent looked for potential overlap in vesting schedules in case paperwork was incorrect. My setup is still experimental. I sometimes get baffling answers or a project drifts, I’m persistently paranoid about data pulls and analyses being inaccurate, and when I’m tired or in a rush, I default to long conversations. But I’m starting to see the overall trendline of how I’m using Codex change. Try it: When your AI recommends something you don’t understand, ask what it means and how to do it. Prompt I’d like to practice by redoing [name a project or task] at [next level]. Can you give me specific tactical recommendations for how to execute that project at level [next level]? Explain HOW to execute each recommendation, give sample artifacts (like prompts or acceptance tables) if necessary, and don’t use jargon. 4. I made the feedback recurring Codex’s feedback on my Stripe project was helpful, but learning requires practice , and reinforcement. Once I saw how useful that one-time assessment was, I had it set up a weekly task that scans my sessions for that week and sends me a graded report on Friday afternoons. The report scores my work against the eight levels, notes what changed week over week, points to the sessions that support the score, and gives me a short list of experiments for the following week. That recurring review moved me from a 5.5 to a 7.9 over four months. The score was gratifying, but the sections on “what changed” and “next week” were where learning really took place. It noticed that I had turned a small file-naming preference into a lasting rule and that I was consistently using orchestrators but wasn’t making the effort to define success upfront. My Friday report tracks progress, missed opportunities, and experiments for the following week. (Recreated from a Codex conversation.) Try it: Ask your AI to review your work on a weekly cadence so that regular feedback doesn’t depend on you remembering to ask. Prompt Can you set up a weekly task for [day and time] to scan our working sessions over the past week and assign me a level? Include missed opportunities and gaps and be specific about what you think I should prioritize over the next week in order to level up. 5. I turned failures into opportunities for improvement The weekly report has changed how I work, but I still have to deal with failed experiments, project drift, and AI slop. Recently I had Codex run a multi-step finance task: read our company debit card spend data, calculate the trailing three-month spend average, add a buffer for taxes, and issue merchant-specific Ramp cards at that limit and then notify each cardholder in Slack. The cards came out correct, but the Slack messages didn’t. They read like polished corporate memos, opening with “Hey @person” and other phrases that I’d never use—even though Codex had read my Slack communication skill, a saved set of instructions it’s supposed to follow whenever it writes on my behalf. So I asked Codex to critique its own draft and had it add rules to the skill naming the giveaway phrases to avoid in Slack messages. Then I asked a bigger question: What can Codex learn from corrections like this? A correction in one conversation doesn’t automatically carry over into the next, so the lesson has to be saved somewhere Codex will read it next time. I had it look back on the session and extract rules from the frequent corrections I tend to make to its work: judgment calls about source-of-truth discipline, approval gates, data verification, and working at the right level of detail. This work of making one-off improvements durable became my Self Improve skill. I ask Codex to learn from my edits to a LinkedIn post. (Recreated from a Codex conversation.) When I invoke /self improve, Codex looks at the preceding thread, the original output, and my corrections, then asks itself a series of questions that I’d ask any person when giving them feedback. The output diagnoses the failure mode, articulates what “good” looks like, and proposes a minimum durable change that can prevent the same thing from happening again. I get to review the proposed changes before they’re encoded, and the loop repeats. Try it: The next time your AI gets something wrong, don’t just fix it and move on. Ask why it failed and have it save the fix so it doesn’t happen again. Prompt Look at this conversation, including the original output, and my corrections. Diagnose why it went wrong, describe what a good result looks like, and propose the smallest change to my instructions that would prevent this next time. Show me the change before saving it. What’s next I’m now using Codex in ways I thought were reserved for engineers, and my system keeps changing. Recently, I asked Codex to study an AI usage report that Dan Shipper posted in Slack to identify opportunities for me to use AI more like him. My weekly feedback is now centered around those recommendations. Since Dots landed last week, my Dot Sebastian has become my orchestrator thread for any quick or administrative tasks. A broader review scores my workflows on delegation, reliability, automation, and learning. (Recreated from a Codex conversation.) Five months from now, I’m sure I’ll be using AI differently again. I have no idea what techniques are coming next, but I do know who I’ll be asking for help learning. Arielle Shipper is the head of operations at Every. Previously she was the COO at Donut and began her career in editorial at Condé Nast. Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$9,000+ in credits for the tools we build with. Subscribe --- # 🎧 How Sam Altman Uses Dots to Take Back His Time TL;DR: OpenAI CEO Sam Altman sits down with Dan Shipper for the first episode of The Every Podcast, the new name for AI & I. It’s still conversations with the people building and using AI, as well as a look behind the scenes at Every. Natalia Quintero joins Dan as co-host later this month. Was this newsletter forwarded to you? Sign up to get it in your inbox. This week, Dan sits down with Sam Altman at OpenAI’s annual DevDay, where the company shipped twenty-two products and features, more than twice as many as last year. (Altman: “Just wait for next year.”) In a wide-ranging interview, Altman shares how his Dot—OpenAI’s new always-on agent—runs his day and gives him time back, why he can’t quit Astra’s new Ultrafast mode, and why he believes AI will bring on a new Renaissance. Watch on X or YouTube, or listen on Spotify or Apple Podcasts. You can also read the transcript. His Dot gave Altman his mornings back. His early mornings used to be his favorite time to work, a period of “maximum creativity” reserved for deep focus. But running OpenAI changed that. Nearly every morning, his focus was diverted to whatever fire demanded attention that day. His Dot (which he’s named “Dotty” until he can “think of a great name”) now triages those issues, alerting him only when something is urgent. “I get this space for creativity or to just hang out with my kids,” he says. “It sounds small, but it has been a significant improvement to my life.” Dan shares how his own Dot, Boo, has made it easier to track his commitments across apps, becoming his default way to use ChatGPT, despite its bugs. “That ability to bring context together from across your entire life and really do things in ways that would be hard even for an attentive person to get right has been super impressive,” he says. Altman’s Dot lets him build again. A recent feature idea he had “would have been very hard to explain to people in enough detail to get it built,” Altman says. So he created it with his Dot. In spare moments, he leaves Dotty notes about how he wants a feature to work—and it’ll build a handful of versions for him to review. “It’s pretty cool to go to sleep and leave a long voice note with a bunch of thoughts as you’re drifting off, and wake up in the morning and not only is the thing built, but it went off and did the next seven steps,” he says. Altman only prompts on Ultrafast. He cites interface designer Bret Victor’s principle that creators need an instant connection to what they’re making. Ultrafast, a Codex mode that responds up to eight times faster but burns through the plan’s usage allowance at eight times the standard rate, gives him that immediacy. “I did not realize what a difference it makes to my iterative thinking loop to have responses come in so quickly,” he says. If AI is supposed to help anyone build, Dan wonders what happens when better intelligence and faster responses are prohibitively expensive for all but a few? Altman predicts OpenAI will soon deliver Ultrafast speed at a reasonable price—but by then, “We’ll have 100x faster, and there will also be GPT-7 Galaxy or whatever,” he says. “So I think the right way to think about this is: As far as I can see, there will always be a real frontier in terms of intelligence or speed or whatever else at a higher price.” Altman hopes AI will spark a new Renaissance. The Industrial Revolution raised living standards, but it turned many people into “this cog in the machine doing some extremely specialized thing, disconnected from a lot of the parts that made life good,” he says. His vision for our future with AI more closely resembles the Renaissance, with “this feeling that human potential had massively expanded.” By making it easier to build products, start companies, and pursue creative work, AI could give more people the freedom—and time—to act on their ideas. Instead of a future in which humans are automated out of their roles, he hopes for a wave of science, art, and new companies, and a world where “people get back in control of their lives and their ability to do the things they want and spend their time the way they want.” 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; Thibault Sottiaux and Andrew Ambrosino from the Codex team; Vercel cofounder Guillermo Rauch; podcaster Dwarkesh Patel; and others to learn how they use AI to think, create, and relate. Laura Entis is a staff writer at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # Vibe Check: OpenAI DevDay 2026 OpenAI’s DevDay just kicked off, and we’ve got the rundown of the 20-plus(!) products and features the company announced. Here’s what matters, what it means, and what I learned from my hands-on testing. The quick take OpenAI wants ChatGPT to become your operating system for work—documents, slides, and agents, all in one place on your computer. It also wants to let developers and startups build businesses on top of it. Five announcements from today show what that looks like: Dots: Persistent agents inside ChatGPT that retain context and keep working over time (think OpenClaw, Grok Bots, and Muse) Space and an office suite: A Google Drive–like place to work with your Dot, plus ChatGPT-native apps for documents, slides, and spreadsheets Developer-built apps and discovery: Full apps inside ChatGPT—called “plugin extensions”—with a directory and automatic recommendations in conversations to help users find you. Your ChatGPT subscription in other apps: Portable Plus and Pro usage, starting with about 15 partners. Separately, Marketplace is a catalog of approved partner software that eligible enterprise customers can purchase using part of their existing OpenAI spending commitments. The Decisions API: This could be the biggest of the five. It’s OpenAI’s answer to Jev, the buzzy new model that acts as a “smart if-then statement” and recently has taken over X. In our testing, the Decisions API beats Jev on at least one dimension: It is multimodal, which means it accepts image input. It beat Jev on speed and accuracy on a few early tests but trailed on our broader evals. It’s being previewed today, and depending on the price, it could reshape the whole ecosystem. OpenAI is also introducing a model called Sol 6.1 (Astra-powered, but cheaper), Ultrafast inference (250 tokens per second), a $500 Pro plan with much more usage, and more. The number of releases is itself part of the story: I’ve been to every Dev Day since Dev Days began in 2023, and this is a far greater number of new products than it has ever had by my unofficial count. My running DevDay launch tally. (Screenshots courtesy of Dan Shipper.) I like OpenAI’s big ambitions, but a vision so comprehensive also requires superior execution. In testing, Dots has become the main way I use ChatGPT, but it’s also been buggy and sometimes frustrating (more later). Space is better and seems to be an easy drop-in replacement for my old document-editor Proof (RIP). OpenAI is moving fast—and with coding agents, it can ship faster than ever—but adding so much at once risks losing the simplicity and coherence that made Codex excellent in the first place. Here’s everything OpenAI announced and what it means: Dots—persistent agents inside of ChatGPT Dots are OpenAI’s always-on agents built into ChatGPT. They’ll look familiar if you’ve used OpenClaw, Muse, Instinct, or Grok Bots. (The visual identity is similar to Muse and Grok Bots.) Your Dot sits in the redesigned ChatGPT sidebar right below the “New chat” button: My Dot, Boo, in the redesigned ChatGPT sidebar. Its own cloud computer lets it work when your laptop is closed and act proactively on your behalf. You can talk to it by typing or call it on the phone. When it’s working, it changes the way I use ChatGPT: I interact with Boo (my Dot’s name), and Boo orchestrates ChatGPT threads, reads my email, uses Slack, and more. It automatically filters incoming Slack requests and emails so I can quickly triage items without opening my inbox. When I was rescheduling a flight, Boo warned me that my new flight time would conflict with a meeting request from Slack that I hadn’t read. That’s the promise: an ongoing agent that filters what needs my attention and acts proactively on my behalf, in one long-running chat thread. But the version I tested over the last few days was too buggy for me to recommend now. I had frequent issues with permissions and dropped messages, and my Dot was often unable to connect to the in-app browser. Dots also add a lot of complexity to the ChatGPT experience: I found my Dot and me both getting confused about whether it should work on its own computer, in the in-app browser of my main thread, or in a separate ChatGPT thread that it had kicked off and was orchestrating. During testing, I found myself reaching for my Dot over starting new Codex threads, so it has definitely become a habit despite the frustration. But unless you love new things with rough edges, I’d recommend waiting a week or two to try it. OpenAI will have solved a lot of these paper cuts by then. If you’re already deep into Grok Bots, Muse, or Instinct, it’s probably not worth switching unless you’re also a big ChatGPT or Codex user. Read our full Vibe Check on Dots Space and the office suite Space is a Google Drive–like place inside ChatGPT where you, your Dots, and your team can organize and work on files together. OpenAI is also introducing native apps for documents, spreadsheets, and slides that you can use inside ChatGPT and with Space. It’s an agent-native document suite: Anything you can do in a document, your Dot can do. It’s meant to replace tools like Google Docs, Microsoft Word, and Notion. I wrote this Vibe Check in my Space: This Vibe Check, written in Space. The obvious win is that you stop switching windows between ChatGPT and another app like Notion while you write. The less obvious one is speed. When a Dot builds a document through its browser in Google Docs, the edits practically crawl in, because Docs wasn’t built for agents. Native documents don’t have that lag. You can tag your Dot inside the document itself instead of going back to the chat to tell it to check the file. I’ve long expected the company to do this—in 2024 I wrote about the potential for documents, slides, and sheets inside ChatGPT—and I’m glad the product is finally here. I’m already doing most of my work in ChatGPT’s in-app browser, and this makes that process smoother: I can tag my Dot in a comment on a document and get a revision inline as I’m working. The back-and-forth feels more like collaboration. There is also a new “Keep updated” toggle that makes sure your Dot automatically keeps a document fresh—useful for evolving artifacts like product roadmaps or company policies. The challenge is switching costs. Most ChatGPT users (including Every) already do all their collaborative work in Google and Notion. Plugin extensions: Developer-built apps native to ChatGPT In addition to releasing its own apps, OpenAI is giving outside developers tools called “plugin extensions” to build apps that live inside ChatGPT. A developer can now design and build a full app that runs entirely within ChatGPT. I’ve long called for Codex-native apps, and this is the company’s take on it: Developers can now build software for both you and your agent, right inside ChatGPT. You get an interface when you want one, and the agent can take over when you don’t—without either of you leaving the conversation OpenAI is also improving how you find these apps. ChatGPT will soon be able to recommend relevant plugins during a conversation, and the app will include a directory where you can browse them. I haven’t seen this in action yet and couldn’t build a test app during the preview period, but if OpenAI can help developers reach users inside ChatGPT, the whole ecosystem will benefit. More developers will build apps for it, and users will have more useful tools to choose from. This is the third or fourth swing OpenAI has taken at an app store—eventually it will make one that works. Your ChatGPT subscription in other apps OpenAI is letting you bring your ChatGPT subscription into partner products. If you pay for Plus or Pro, you can use OpenAI’s models in participating apps like coding agent Devin, with that usage counting toward your existing ChatGPT plan limits. OpenAI says it’s starting with about 15 partners, and you’ll be able to control each app’s access and usage. I’ve predicted that AI subscriptions will look like cellphone data plans: You pay for one, then choose which apps to use it in. OpenAI is the first major lab to take this step. Now, third-party software makers like Every can focus on making great tools for humans and agents without worrying about whether a token bill will bankrupt us. It’s also a better deal for users: You can use your subscription anywhere. Decisions API—Jev in ChatGPT The Decisions API is OpenAI’s answer to Jev, the model we recently described as a “smart if-then statement.” You give the Decisions API context and a fixed set of answers, and it picks one. That could mean deciding whether an email needs a reply or which button an agent should click next. OpenAI’s version accepts images as well as text. Our early testing has been promising, though the winner depends on the use case. On a text-only replay of computer tasks, senior editor Jack Cheng found that Decisions picked the correct control in 76 of 78 scored steps versus Jev’s 73, and typically responded in 230 milliseconds versus 500. General manager of Cora Kieran Klaassen saw results favoring Jev. On a test classifying conversation threads, the two were effectively tied on accuracy, but Jev’s median response time was 161 milliseconds versus Decisions’s 309. OpenAI is previewing Decisions today, with a launch expected in a few weeks. Pricing hasn’t been announced. If the Decisions API is cheap enough to use for thousands of these little decisions, I think this could be one of DevDay’s biggest releases. Other DevDay announcements A $500 Pro plan: A $500-a-month tier with OpenAI’s highest usage limits and exclusive access to Astra Ultrafast in ChatGPT Work and Codex Astra Ultrafast: A premium speed tier for GPT-6 Astra. OpenAI says it runs at 250 tokens per second—and the demos I saw were mind-blowing, but also wallet-blowing. It’ll burn through your usage fast. Sol 6.1: A new model Sol that offers near-Astra performance at one-fifth the cost. Agents API with computer use: Developers can build on the system that powers Codex, including agents working together, finding and calling tools, and using a computer. OpenAI runs the infrastructure. Codex cloud environments: Reusable development environments with shared settings and permissions, plus Codex’s desktop interface on the web. You can leave work running in the cloud and check in from your computer or phone. A new Codex CLI: The terminal app gets voice chat, a view for tracking agents, built-in worktrees for keeping coding tasks separate, and better prompt editing and session resumption. Codex Security Cloud: A plugin for investigating vulnerabilities and proposing fixes in GitHub repositories. It can scan on demand, on a schedule, or when new commits arrive, with access to OpenAI’s security-focused Daybreak Blue models. OpenAI Private Intelligence: Enterprise privacy features combining Zero Data Retention with Private Safety Processing (i.e., customer content isn’t retained, and safety checks are performed without exposing that content beyond the protected environment), plus a preview of Private Inference—AI processing in a secure, verifiable environment. Plugins in Sites: Teammates can use a shared Site with their own connected data and permissions—available on Business, Enterprise, Healthcare, and Education plans. Plugin submission and updates: A rebuilt submission process with clearer feedback for developers. OpenAI Marketplace: A beta that lets eligible enterprise customers put part of their existing OpenAI spending commitments toward approved partner software, starting with 32 partners. The bottom line Every six to 12 months, it feels like the models get good enough to spur a change in product form factor. GPT-3 enabled chat in a browser. Then, around Sonnet 3.5, we got coding agents in a terminal. Then, around GPT-5.3, we got desktop apps for managing several agents at once. Now, with Astra , and Opus 5.5–level models, we’re moving toward one persistent agent that knows our work, keeps track of what’s changed, and brings in other agents as needed. This is a form factor that’s been obviously coming since the OpenClaw craze eight months ago, but now the models are good enough that big companies including Meta, X, and now OpenAI are getting in the game. I find the pace of the updates exhilarating, and manually starting and managing individual Codex or ChatGPT threads already feels a little archaic. But I am also a little tired and confused. Feature velocity is great when it feels coherent, but even a power user like me has a lot to figure out, and it doesn’t all work yet. I’m excited to keep using these products. I’d be even more excited if the next time I opened ChatGPT, there was less for me to figure out. Dan Shipper is the cofounder and CEO of Every, where he writes the Chain of Thought column and co-hosts The Every Podcast. You can follow him on X at @danshipper and on LinkedIn. --- # Vibe Check: Dots—Always-on Agents in ChatGPT Last week, between back-to-back model reviews, company strategy calls, writing, and my never-ending hunt for apartment furniture on Facebook Marketplace, I tried to change a flight out of San Francisco. I used my Dot—OpenAI’s proactive, always-on agent, released today—to help me book. As my Dot displayed its flight research, it warned me, “[This] may overlap with Randy’s Wednesday morning video recording.” Randy Counsman is our head of video, but I had no idea what my Dot meant because there was no video recording on my calendar. It turned out my Dot had read a discussion in Slack that I hadn’t seen, clocked the proposed schedule, and alerted me when I needed it most. --- # Vibe Check: Sonnet 5.5 Finds Its Place in Claude’s Crowded Family Was this newsletter forwarded to you? Sign up to get it in your inbox. Sonnet 5.5 is out today, and as a fellow middle child, I feel for it—it has something to prove. --- # Opus 5.5 and Sol Split the Team Hello, and happy Sunday. Three new models dropped this week, and we Vibe Checked each: Opus 5.5 pulled several of our team members back to Claude, GPT-6 Sol is Dan Shipper’s new daily driver, and Grok 4.7 won back one power user (but no one else). Later, Steal these gathers the week’s workflows: Mike Taylor on benchmarks and writing, Jack Cheng and Douglas Brundage on Jev, and Becky Isjwara on video. Some housekeeping: Micah Rich leads a prompting workshop on Friday, October 2, and Thesis: 2027 is down to its last tickets.—Kate Lee Was this newsletter forwarded to you? Sign up to get it in your inbox. Vibe Checks Two models came out on Tuesday and another on Monday. Here’s our verdict on each. “Vibe Check: Opus 5.5 Is Pulling Our Codex Converts Back to Claude” by Katie Parrott/Vibe Check: Katie and the team found Opus 5.5 matched or beat Fable 5.1 on product and design work at 60 percent less per token—enough to become Kieran Klaassen’s new daily driver and to tempt a few Codex converts back to Claude. There are still two significant tradeoffs: Opus buries the point in prose and will run for hours unless you set a budget. “Vibe Check: GPT-6 Sol vs. Opus 5.5” by Dan Shipper/Vibe Check: Dan’s verdict: Sol if you want a fast, cheaper daily driver in Codex that leads with the main idea. Opus 5.5 if you’re willing to pay more for ambitious coding and visual work, like the webcam heart rate monitor it built and Sol couldn’t finish. “Mini-Vibe Check: Grok 4.7” by Laura Entis/Context Window: Mike, Kieran, and Tyler Nishida were already testing Grok 4.7 for a Vibe Check when it was released on Monday, so on Thursday we ran a short version. It won back Tyler, who finds it cheap and steerable enough to be his daily driver again, but no one else: Kieran won’t consider it next to Opus 5.5, and Katie found its writing had no rhythm or feel for the reader. Steal these Nine workflows to use from this week’s four how-tos: Build a benchmark for your own job From Mike Taylor’s “How to Create Your Own Personal AI Benchmark” Start with the tasks AI got wrong. Mike has his coding agent search the past month’s sessions for 10 tasks that needed heavy back-and-forth or were abandoned, then runs them on several models and compares the outputs side by side. The prompt Turn taste into tests. Mike dictates what he liked and disliked about each output and has the model turn that into yes-or-no checks on a reusable grading rubric. The method Validate your benchmark. To get from a private test to a defensible benchmark, Mike saves every brief, output, and round of feedback into a skill per task, so each skill accumulates 20 or more cases alongside a gold star example and an eval script. The folder structure Write with AI without losing your voice From Mike Taylor’s “Good Writing With AI Starts Before the Prompt” Think before you prompt, and judge after the draft. Mike’s 12-step process for writing with AI cuts a day of writing to less than two hours by having him come up with a title, gather sources, and spitball in Monologue before a model drafts; after picking what he likes most from each version, he writes the ending and debates the finer points with his editors himself. The process Watch it happen. On Thursday, Mike, Katie Parrott, and Jack Cheng wrote and edited with AI on camera to close our How We Write Now series. The recording Put Jev to work From Laura Entis’s “How to Get the Most Out of Jev” Hand Jev the snap judgments. Mike’s rule of thumb: If a person could make the call in less than 10 seconds—sort this email, flag this phrase—send the task to Jev, and save anything slower for a language model. Here’s why Turn a fuzzy question into checks. Jev can’t answer a subjective question like “Is this urgent?” until you define the term, so the workflow has your agent interview you, turn the definition into yes-or-no checks Jev can score, and test them against items you’ve already judged. The steps Copy a demo off X. Douglas Brundage gave a Jev demo to the Grok bot that writes his morning news scan and asked, “Can you just do this?” The bot now reviews more than 500 posts a morning, including ones he never saw on X. The prompt Turn an article into a video From Laura Entis’s “Why Evals Are So Hot Right Now” Storyboard before you animate. Becky gives Claude an article URL, approves a still image storyboard in the cover’s colors, has Hyperframes turn it into an 18-second clip, and fixes it scene by scene in the preview. The steps Knowledge base “Why Evals Are So Hot Right Now” by Laura Entis/Context Window: Nearly half of the product management openings Lenny Rachitsky shared last week ask for experience writing evals, and Nityesh Agarwal explains why: Models are capable enough now that speed, price, and taste decide which one you use. A personal benchmark is how you know whether a release changes anything for you. Also inside: Willie Williams on why Slack agents are the new websites. “Copilot Gets a Seat in the Org Chart” by Ryan Sloan: Ryan Sloan went to Microsoft’s launch in Redmond, Washington, and tried the new Copilot, which folds chat, code, Office, and a persistent agent called Autopilot into one app that has your documents, conversations, and permissions. When he asked Copilot to move a table from Word into Excel, it found both files and said it lacked permission to edit the workbook: The IT controls that make it trustworthy inside a company can also stop it from doing an ordinary task. Thesis Statements Read five more predictions from frontier builders and thinkers in Thesis Statements, a collection of specific, contestable claims about the future of great human work with AI. AI will have rules, but those rules will constantly be shifting by Drew Breunig, CEO and cofounder of Cmpnd We’ll be assessed on what we can defend, not what we can produce by Sean Campbell, director of AI integration for the MBA program at George Fox University The time spent in the details is an investment in having the next good idea by Geoffrey Litt, design engineer at Notion Intelligence will live in your pocket, not a data center by Daniela Rus, director of MIT’s Computer Science and Artificial Intelligence Laboratory Every token will be connected to a budget, an owner, or an outcome by Arielle Shipper, head of operations at Every Join us at our inaugural Thesis: 2027 conference on November 5, 2026. Fewer than 50 tickets are left. Log on Get hands-on with how Every uses AI. At these live camps, workshops, and meetups, team members teach our workflows. Upcoming workshop AI Foundations: Prompting Is a Thinking Skill: Friday, October 2, 12–1 p.m. ET, virtual. Micah Rich leads a guided weekly planning exercise on what to tell AI, how to move the conversation forward, and how to judge whether the answer is any good. No coding experience required. Register. That’s all for this week. Follow Every on X at @every and on LinkedIn. Thanks to Eleanor Wikstrom for editorial support. Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$9,000+ in credits for the tools we build with. --- # Copilot Gets a Seat in the Org Chart If you’ve followed Mike Taylor’s coverage of Microsoft, you know the scale of what the company has been assembling: 80 products called “Copilot” at last count—powerful when configured correctly and locked down without a cooperative IT department. Ryan Sloan attended Microsoft’s latest launch to test the new unified Copilot app, which rolls chat, code, Office, and a persistent agent called Autopilot into one interface. He found that the controls that make Copilot trustworthy inside a big company are the same ones that keep it from finishing a routine task. Read on for his dispatch from Redmond.—Kate Lee Was this newsletter forwarded to you? Sign up to get it in your inbox. In August, Mike Taylor counted 80 Microsoft products called “Copilot.” Among them, he said, were some of the best tools for building agents—if you could navigate onboarding and enterprise IT administration. At a launch event earlier this week in Seattle and Redmond, where I spoke with executives and briefly tried the app on the demo floor, Microsoft announced a new Copilot that combines chat, code, Office, and a persistent agent called Autopilot, replacing its separate consumer and work chat apps. Microsoft isn’t alone in attempting a unified interface for AI work, but its advantage is that the people it’s built for already spend their day in Outlook and Teams, with permissions their IT department set years ago. Autopilot may be the most interesting piece of the new Copilot: It can work on its own and access most of what you can. Those permissions could make it useful and trustworthy inside a company, but they could also prevent it from completing an ordinary task. Microsoft’s own emphasis on evaluations (evals) at the launch event suggests that it is looking to its customers to define what good work looks like in their organizations and test whether Autopilot improves on current workflows. The new app has three tabs: Home brings chat, delegated tasks, and Word, Excel, and PowerPoint into one place, making context available between them. Code lets non-developers build and share small apps within secure environments. Autopilot lets you create a persistent agent you can give a goal and set to work behind the scenes. In one demo, it tracked and managed Black Friday inventory requests for a retailer. To avoid the compliance risks of ungoverned agents, Autopilot agents fit into your organization’s governance structure with their own permissions and are shown “reporting” to their owners in the org chart. What the new Copilot app’s Home tab looks like. (Screenshots courtesy of Microsoft.) These capabilities are rolling out in previews and via Microsoft’s early-access program for AI features over the coming months. Want to sponsor Every? Click here. What I learned on the demo floor At the launch, CEO Satya Nadella said Copilot now works at every scale, from a single Excel cell to a summary of a week’s meetings, with the same memory of what you’re doing carried across all of it. That was the claim I wanted to test on the demo floor. Office inside Copilot holds up: Word, Excel, and PowerPoint open in the app, and Copilot knows which document you’re in and what you’re doing there. The old Copilot buttons couldn’t see past their own window. In a demo, we opened a PowerPoint deck inside Copilot, scrolled to slide 9, and returned to the chat to say, “Make this slide easier to read.” That was enough for Copilot to start reformatting the slide. Then I made a request that went outside the team’s prepared demo: Pull a table from a Word document and drop it into a new tab in an Excel workbook. Copilot found both files but said it lacked permission to edit the workbook. A similar restriction prevented us from testing a handoff from Chat to Code. Such handoffs are central to the “one app” pitch, so I’d hoped to see one in action. In both cases, the team assured me that while the demo wasn’t set up for these tasks, they would work in the right configuration. This echoes what Mike observed in August: IT controls make Copilot safe for enterprises, but the customer’s setup will decide whether it works for a user on day one. An agent that keeps working “The new massive insider risk is the AI agent,” Nadella warned at the launch, explaining why Autopilot was designed to help it earn users’ trust. Autopilot draws on the last 30 days of a user’s work, their place in the org chart, and their calendar. It remembers personal preferences like a no-meetings morning and past corrections. These memories are meant to be private to the user, but the agent is identifiable when working with others, displayed under a name the user gives it, like “Dot (Ryan’s Autopilot).” A colleague can tag Dot in a Teams chat to find a meeting time or ask it a question. Autopilot is Copilot’s new autonomous agent feature. Autopilot can also run Routines: a daily briefing, or a standing job that keeps watch on a project while you’re doing something else. Charles Lamanna, executive vice president of Copilot, agents, and platform, has named his Autopilot Apollo and given it the same Outlook access his executive assistant has. He talks to Apollo almost entirely in Teams, the way he’d message a colleague. He gives it goals like ensuring he’s prepared for customer meetings, and it operates around the clock to identify those calls on the calendar and automatically summarize relevant context for him from Teams, email, and notes. Always-on work has a cost. Autopilot runs on usage-based credits and is off by default. Lamanna envisions companies eventually having one Autopilot per person and one per group. To justify thousands of agents spending tokens around the clock, he said, Autopilot has to “clear a higher bar” than an AI tool that works only when a user asks it to. What a higher bar means At the launch, Microsoft spent a surprising amount of time on how customers should judge Copilot. That emphasis reflects an industry-wide turn toward evals, as Laura Entis reported yesterday. Nadella called for “evals specific to your company”: tests based on the work your people do, which you can use to compare models and measure performance. A general benchmark cannot tell an organization whether an agent improves one of its own processes. Lamanna told me Microsoft runs about 16,000 internal evals. Each eval represents a common task or workflow they identified in usage data and is built by domain experts. The company also builds evals with customers. At a large consumer goods company, he said, a Microsoft team is identifying which tasks matter most to that business. The customer connects the necessary data, and Microsoft fixes the problems the tests uncover. The customers who succeed at this, Lamanna said, have the person who does the job every day build the eval. They also “embrace the red.” A failing test tells you what to fix, and once it passes, you write a harder one. And before those customers let the agent try, they measure how the humans are doing the job now—tracking outcomes such as error rates or the time it takes a contract to get out the door—so the agent has an actual baseline to beat. That standard should apply across the new Copilot. Each feature has to improve the work it promises to make easier. Office inside Copilot will eliminate much of the copying and pasting needed to give a chatbot context. Code addresses a pattern I’ve seen repeatedly: Someone builds a useful AI tool that works beautifully on their laptop, but no one else ever uses it. Microsoft wants sharing an app to be as easy as sending a PowerPoint deck. Autopilot is for the tasks that pile up when you’re not at your desk. Microsoft already has what a company agent needs: your documents, conversations, and permissions. But when the demo couldn’t carry my work between apps, it showed why Microsoft may struggle to fulfill that promise. The controls meant to make Copilot trustworthy could also stop it from doing its job. Company-specific evals would let customers measure how reliably Copilot works within those guardrails—and whether it improves on the way its employees work today. Ryan Sloan is a data scientist in Seattle. He writes about AI measurement and evaluation at Full Rank. Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$9,000+ in credits for the tools we build with. Subscribe --- # Why Evals Are So Hot Right Now In today’s Context Window, we review Grok 4.7 (“a step backward”?) and explain why evals are suddenly everywhere. Elsewhere, head of social media Becky Isjwara breaks down her workflow for turning Every articles into viral short videos, head of platform Willie Williams argues that Slack agents are the new websites, and we share a fresh crop of Thesis Statements, including entries from Cmpnd’s Drew Breunig, Notion’s Geoffrey Litt, and MIT’s Daniela Rus, about what happens after automation. Was this newsletter forwarded to you? Sign up to get it in your inbox. Mini-Vibe Check Grok 4.7 is uneven Grok 4.7 launched publicly on Monday. And the vibes? Well, they are evolving. In the team’s early tests, which began before the public release, the model was practically unusable. It left tasks unfinished, ignored instructions, and merged code without permission. Every has numerous Grok 4.6 power users—notably Cora general manager Kieran Klaassen and designer Tyler Nishida—who like it because it’s cheap, fast, and reliable enough to be a workhorse. (Tyler estimates Grok accounted for 97 percent of his tracked code events last month.) Grok 4.7 initially felt like a major regression. When he ran the model against his personal benchmark last week, head of evals Mike Taylor reported that it scored 42 percent compared with Grok 4.6’s 84 percent. “Maybe they rushed it out, or they have something better coming down the pipe,” he says. “This seems like a step backward.” Case closed. Or was it? It was not, at least not according to Tyler, who noticed that the model’s performance improved leading up to its public launch. In particular, GrokBot, the company’s AI assistant, got better after it began using Grok 4.7. Where he once sent a string of all-caps corrections—“Stop, stop, stop. That’s not what I wanted!”—he now sends simple one-line requests. “I feel like I’m micromanaging it a lot less,” he says. Want to sponsor Every? Click here. By last Friday, Grok 4.7 was working well for him. As of this writing, it’s his daily driver. He even prefers it slightly to Grok 4.6—it retains what drew him to Grok, a cheap, steerable model that lets him keep working without constantly hitting usage caps. His endorsement has limits: He still finds Grok 4.7 frustrating when it coordinates other agents and prefers using it in a single chat. And Elon Musk—who, in a (since-deleted?) tweet, declared Grok 4.7 would “exceed all current models”—had led him to expect more than an incremental improvement. “I wouldn’t have been this excited for it, and I feel just kinda let down,” Tyler says. Grok 4.7 did not live up to Elon’s hype. (Screenshot courtesy of Tyler Nishida.) Tyler’s teammates haven’t all come around. Kieran’s assessment remains negative. “Compared to Opus 5.5, this model is not even close,” he says. “It’s not a model I would even consider using.” Staff writer Katie Parrott’s writing tests were also discouraging. She dislikes Grok 4.7’s editorial judgment. Asked to rewrite the introduction to Dan Shipper’s “After Automation,” it produced the line “If the model can do the task, headcount is sentiment,” an example of the model’s “big Elon Musk energy,” Katie says. She found its writing style equally poor. In that same “After Automation” rewrite, its opening paragraph consisted entirely of short declarative sentences. A Grok 4.7 editorial massacre. (Screenshot courtesy of Laura Entis.) “It has no cadence or rhythm and no empathy or theory of mind for the reader,” she says. Our verdict: Grok 4.7 has won back at least one of its biggest users at Every. If you liked 4.6 for everyday coding, Tyler’s experience gives you a reason to try the upgrade. If you’re using AI to write, however, Katie’s tests suggest you leave the model alone. Signal Evals go mainstream What happened: Evals are having a moment. Of the 25 product management openings tech influencer Lenny Rachitsky shared last week, he says nearly half asked for experience writing evals, or tests of how well an AI system performs a task. At app monitoring company Sentry, proposed code changes triggered roughly 1,800 eval runs in the past month, engineer Ryan Brooks reported—up from near zero in May. These checks can catch problems before an update ships, such as revised instructions that cause an agent to struggle with tasks it previously handled well. What it means: Choosing the most intelligent model used to be a reasonable default, says senior applied AI engineer Nityesh Agarwal. But frontier models have become so capable that most knowledge workers don’t need their full intelligence for everyday work. Several models can already handle those tasks, making speed, price, and alignment with the user’s taste more important selection criteria. Nityesh is helping everyone at Every build personal benchmarks based on existing tasks and individual standards for good work. As model releases accelerate, these benchmarks let us quickly test how well a model handles different parts of our jobs. “If I have my own personal benchmark, I’ll know whether I need to pay attention to a model release or not,” Nityesh says. Personal benchmarks measure how good AI is at your specific job. (Screenshot courtesy of Laura Entis.) Why it matters: Teams building with AI increasingly need to judge its quality for themselves by defining success and checking whether model updates help or hurt their work. Evals help teams catch failures before customers encounter them and test whether a faster, cheaper model performs well enough for their product. For individuals, evals identify which model works best for a specific task based on its capability, speed, and cost. As models improve, “you don’t necessarily need your daily driver to be the most intelligent one,” Nityesh says. Steal this workflow Turn an article into a short video Every’s head of social media Becky Isjwara has found viral success turning articles into short animated videos. For Katie’s Compound Writing guide—which explains how to write with AI to improve your craft over time—she made an 18-second clip that animated the cover’s flying papers and illustrated the writing process as a loop. Becky Isjwara's animation built from the Compound Writing cover image. (Video courtesy Becky Isjwara.) To make these videos, Becky uses Hyperframes with Fable in the Claude desktop app. Hyperframes lets Claude turn text, images, and animation into a finished video. Here’s her process: Step 1. Decide how to represent the article visually. Give Claude the article URL and ask it to suggest an opening hook and a sequence of scenes. Read the piece yourself, then check whether Claude’s proposed scenes show the article’s most interesting ideas. Step 2. Plan each scene. Ask Claude to create a storyboard with one still image for each scene. Have it use colors from the article’s cover image and include the text that will appear onscreen. Before moving to animation, check that the story is easy to follow and the visuals convey the intended ideas. Step 3. Make the video. Once you’ve approved the storyboard, ask Claude to turn those scenes into a video with Hyperframes, adding motion and transitions. If you want to animate the cover illustration, upload it to Flora, a workspace for creating images and videos with AI. In Flora, select MiniMax, an AI video generation model, and describe how you want the illustration to move. Then give Claude the resulting clip and ask it to include it in your storyboard. Step 4. Watch and refine. Watch the video in Claude’s built-in preview, pausing to tell Claude what to change—for example, “Keep this scene on screen longer so I can read the text” or “The last letter is cut off. Adjust the layout so the whole word is visible.” Have Claude apply your requests, then review the video to confirm the changes and check for any new problems. Try it this week: Choose an article and a cover image, and use these steps to make a short video. Once you’re happy with the result, ask Claude to save the workflow and your corrections as a reusable skill. Instruct it to seek your approval at each step, so you can make a video for a new article without repeating these instructions. Thesis Statements Last month, we launched Thesis Statements, a collection of specific, contestable claims from builders and thinkers about the future of great human work with AI. Here are five more predictions from people at the frontier: AI will have rules, but those rules will constantly be shifting by Drew Breunig, CEO and cofounder of Cmpnd. We’ll be assessed on what we can defend, not what we can produce by Sean Campbell, director of AI integration for the MBA program at George Fox University. The time spent in the details is an investment in having the next good idea by Geoffrey Litt, design engineer at Notion. Intelligence will live in your pocket, not a data center by Daniela Rus, director of MIT’s Computer Science and Artificial Intelligence Laboratory. Every token will be connected to a budget, an owner, or an outcome by Arielle Shipper, head of operations at Every. If you want to help decide what matters in the future of AI and human work, think creatively, and build what comes next, join us at our inaugural Thesis: 2027 conference on November 5, 2026. Jagged frontier Slack agents are the new websites In the internet’s early years, any company moving online first needed a website. Websites started as informational front doors—a place to say what you did, list a phone number, and maybe show some photos. Then the website became the product—you could order directly from walmart.com, rather than just viewing a list of store locations. Websites turned into web apps, and then we forgot that they were ever different. The same thing is about to happen with agents. Applications are evolving beyond websites into agents on conversational platforms like Slack, Teams, Google Chat, WhatsApp, Telegram, and whatever comes next. These surfaces already hold much of the context agents need. Putting agents there lets them use that context directly rather than move it elsewhere. Take Every. To read one of our articles, you need to visit our site, search for it, and copy anything you want to use into another tool. An Every agent that lives in Slack (ed: like the one we’ll soon be launching) could access our archive, bring you relevant pieces, and discuss them with you where you’re already working. Too few companies recognize the opportunity to deploy their own branded agents where their customers communicate. Websites went from optional to essential for businesses in a decade. Slack agents could make that leap even faster. Agent frameworks are making these tools cheaper to build. As more companies launch agents, competitors will feel pressure to follow. The next front door to your business is an @.—Willie Williams Laura Entis is a staff writer at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # How to Get the Most Out of Jev Jev is fast, cheap, and accurate enough to handle the judgment calls you’d never pay an LLM to make at scale—is this email urgent, does this paragraph sound like AI, should I escalate this customer service request—on everything, all the time. Today, head of evals Mike Taylor explains what that unlocks, head of marketing Douglas Brundage shares his shortcut for putting Jev to work, and senior editor Jack Cheng shows why Jev is so good at turning intent into action. Was this newsletter forwarded to you? Sign up to get it in your inbox. Signal Why Jev is blowing up your timeline What happened: On September 15, TypeSafe, an AI frontier lab that spent two years in stealth, released Jev, a model that classifies text and structured data instead of generating it. The release lit a match that has yet to sputter: On X, Jev demos are everywhere. Users have gone viral showcasing how Jev can be used to play video games, re-rank search results, and filter social media posts, among so many other uses. Senior editor Jack Cheng’s Jev demo, which shows the model’s ability to infer a user’s intent from speech and hand gestures, has surpassed 1 million views. Once you get your head around what Jev is and isn’t—it’s a decision model, not a chatbot—the fascination makes sense. Frame a task as a yes-or-no question, a multiple-choice pick, or a rating in plain English, and Jev returns a probability. Because it outputs probabilities rather than generating text one token at a time, Jev can answer huge batches of questions in parallel, almost instantly, and for a fraction of the cost of text-based LLMs. What it means: Jev’s accuracy, speed, and dirt-cheapness unlock a world of possibilities. The model excels at classification at scale: It can, for example, sort your entire inbox archive into categories like newsletters, work messages, event invitations, etc., in less than a second. (Language models can do this, too, of course, but at a slower pace and at a much higher cost.) A general rule of thumb is that if a task is so simple that it would take a human less than 10 seconds to execute—such as determining how to classify an email—it’s a good use case for Jev. For tasks that require more reasoning and would take more than 10 seconds to complete, bring in the intelligence of a language model. Sorting emails is straightforward. To use Jev for more complex, subjective calls such as “Is this email urgent?” you—or your agent—must first define urgency as a set of clearer checks: Was it sent by a human? Do you know the sender? Would ignoring it cost you something? Jev evaluates each question separately, and you can combine the scores in code to measure urgency. Jack’s email board experiment evaluates each message against a set of individual questions and weights the answers to determine what’s worth his attention. (Screenshot courtesy of Jack Cheng.) The translation layer makes Jev less immediately intuitive to use than a chatbot LLM, but “it brings a lot of excitement back into programming,” says Mike. “Now it’s like, ‘Hey, if I could just be a little bit more creative with how I define this problem, I can do it 600 times cheaper.’” Why it matters: Jev also plays nicely with traditional LLMs—think of it as a tool Codex or Claude Code can use to make narrow, high-volume judgment calls. This allows you to use the agent of your choice and send its outputs to Jev for real-time feedback. For example, you could draft an article in Codex and have it send the draft to Jev at every phase to check whether the article contains AI tells, Mike says. When a phrase is flagged by Jev, Codex can revise it on the spot. Or you could use Jev to determine which Slack messages, across all channels, meet your criteria for follow-up—and sort them into a personal feed in real time. Mike used Jev to build Jevgram, which allows you to interrogate text based on the likelihood it matches any question, including “Does this sound like AI?” (Screenshot courtesy of Mike Taylor.) Jev lets you “check everything,” Mike says. “I think people are only just waking up to the implications of that.” Steal this workflow Turn a fuzzy question into Jev checks Jev can classify text based on any question, including subjective ones. But queries like “Is this email urgent?” or “Does this writing sound like AI?” leave a lot open to interpretation. Breaking requests like these into specific checks gives you more control over what Jev evaluates—and makes it easier to investigate if its analysis differs from your own. Step 1. Install the official TypeSafe skill. This gives your coding agent TypeSafe’s instructions for how Jev works and how to structure questions for it. Tell your agent to: Install the official TypeSafe skill from https://github.com/typesafe-ai/skills, then use it to help me build this Jev workflow. Step 2. Use AI to interrogate your intention. Ask Codex or Claude Code to define what “urgent,” “relevant,” or “worth reading” means to you. Start with this prompt: Prompt I want to use Jev to answer [subjective question] about [material], so I can [action or decision]. Ask me to share examples and explain why I would select some and reject others, including cases I’m unsure about. Use my answers to write a working definition. Step 3. Break down your definition into discrete checks. To build a personalized email filter, Jack worked with Fable, which had access to his inbox, to develop weighted criteria: Did a real person write the message? Is someone he knows waiting on him? Will ignoring it cost him something? He then ran those criteria across 90 days of email so he could have a personalized shortlist of messages that required his attention. The filter also helped him spot older messages that still required action from him. Similarly, Mike suggests breaking a broad question like “Does this sound like AI?” into parallel checks that identify individual AI writing tells in a passage, such as “not X but Y” constructions or a tricolon of sentence fragments. Ask your agent: Prompt Turn our definition into questions Jev can assess separately. For each, define yes and no, give an example and a borderline case, and identify any context Jev needs. Use ordinary code for checks that don’t need AI. Explain how you’ll combine the results into [a shortlist, ranking, or flag], and what happens when information is missing. Step 4. Judge whether you agree with the classifications. Jack’s initial email filter highlighted newsletters—not something he wanted marked as urgent—which prompted him to revise the criteria with Fable. When you disagree with Jev’s assessment for an item, check whether the instructions were unclear or any context was missing. Use this prompt to refine your criteria: Prompt Run the checks on a small sample I’ve already judged, without including my judgments in Jev’s input. Show what it selected and missed and compare that with my choices. Help me investigate disagreements and revise the checks. Then test on fresh examples I’ve judged before applying the revised checks to the full collection. Save the questions and examples that produce useful results and use the revised instructions to classify your next batch of inputs so you can track improvements. The model’s release created a new leaderboard that tracks who is using the most Jev tokens. (Screenshot courtesy of Laura Entis.) How We Write Now Inside Mike Taylor’s AI writing workflow Last week, Mike shared his 13 beliefs about writing with AI. In the newest entry in our How We Write Now series, he shows how those beliefs become finished pieces with a 12-step process that begins well before AI enters the picture. Read it here. Want to watch Every’s writers work with AI in real time? Join Mike, Jack, and staff writer Katie Parrott for our Write-along tomorrow at 1 p.m. ET, live-streamed on X and YouTube. Demo-spiration Mine X for more ways to use Jev If you’re unsure what to do with Jev, you’re not alone. Luckily, there’s an easy solution—find a demo on X you’d like to copy, give it to your coding agent of choice, and ask it to adapt the demo for your workflow. That’s the route Douglas took. He already had a Grok bot that delivered a morning report on agent-specific news, AI buzz, and cultural moments and suggested openings for Every to join the conversation. But “it wasn’t doing a great job,” he says. Then Every CEO Dan Shipper shared a Jev demo in Slack from developer Elvis Sun, who had Jev read 384 news stories published in a single morning to tell 15 different brands which stories the brands should try to engage with online. Douglas handed this post to his Grok bot and let it run. (Screenshot courtesy of Laura Entis.) “A good lesson I’ve learned at Every is that, when you see content showing someone doing something cool with AI that you want to do, you can give the content to AI and say, ‘Just do this,’” Douglas says. So he gave the post to his Grok bot and asked, “Can you just do this with Jev?” The bot asked for an API key and took it from there. Douglas’s morning pulse now surfaces more stories Every can weigh in on. Before Jev, Grok reviewed fewer than 20 posts in a typical run; with Jev, it reviews more than 500—including ones he hadn’t seen on X. Try it this week: Give Codex or Claude Code a demo with this request, “Help me adapt this for [my task]. Tell me what you need from me and build a version I can test.” If you don’t have a demo in mind, here are a few that attracted a lot of attention on X. Or ask your agent to find you one. Inside Every Intent-based software Jack’s viral X demo. (Video courtesy of Jack.) Jack built a Jev demo that illustrates how, when given multiple signals and a fixed set of possible actions, the model can appear to interpret intent. He vibe coded a voice- and gesture-controlled digital canvas using tldraw. After calibrating the app’s hand tracking, Jack can point at the canvas and say, “Make a blue square here,” for example, and a blue square will appear beneath where he’s pointing. Under the hood, the browser transcribes Jack’s speech, records his fingertip’s coordinates, and describes the canvas as a list of shapes and their attributes. The app sends that information to Jev, which answers several questions at once: Which shape does he want to change? What color or size does he want? Where should it go? Ordinary code then maps Jev’s answers to tldraw commands that create, resize, move, select, or delete shapes. “If you were to ask even the fastest language models to do this, each interaction would probably take a second or two at best,” Jack says. “It’d break the feeling of a responsive, real-time interface.” Jev doesn’t accept images as inputs and therefore never “sees” the canvas. Instead, it quickly answers a set of smaller questions of the data it has about the state of the canvas and Jack’s commands that together help answer the bigger questions of “What does Jack want to do?” “I come back to this idea of quickly converting intent into action,” Jack says. “That’s a cool thing Jev is letting people do, interaction-wise.” Data point 4.2 cents That’s Jev’s price per million input tokens (output is free). For comparison, here’s the price per million tokens for other popular models: Gemini 3.7 Flash: $0.75 input, $3.75 output Haiku 4.5: $1 input, $5 output Sol: $4 input, $20 output Astra: $10 input, $50 output Fable 5.1: $10 input, $50 output Five dollars will get you a lot of Jev tokens. (Screenshot courtesy of Laura Entis.) Laura Entis is a staff writer at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # Good Writing With AI Starts Before the Prompt Last week, head of evals Mike Taylor told us about his 13 beliefs about writing with AI—from putting more into the prompt than you ask the model to produce to living a life worth writing about. His process starts with gathering that raw material: seeking out experiences, debating ideas, and noticing which topics make people’s eyes light up. Today, he shows you how he turns those beliefs into finished pieces, with a process you can adapt to make your own work worth a reader’s time. For a closer look at how the writers at Every put AI to work, join Mike, staff writer Katie Parrott, and senior editor Jack Cheng for our Write-along tomorrow at 1 p.m. ET, livestreamed on X and YouTube. —Kate Lee Was this newsletter forwarded to you? Sign up to get it in your inbox. It took me a lot of experimenting to find a way of writing with AI that I was happy with. Here’s the process I’ve landed on, from picking a title to arguing with my editor and coaching Claude to write like me. I’m sharing it because it gets the most out of AI, without losing my voice. With this process I’ve cut my writing time for a 1,200-word piece from a day to less than two hours, with no drop in traffic or positive reader comments. Your process will vary with your level of AI adoption. Steal whatever looks useful. Write the title first. The title is 80 percent of why anyone chooses to read a piece; for the writer, a good title provides the conviction to see the piece through. Give the document a title that excites you. You can change it later if the piece takes a different shape. Collect sources. Gather the writing you plan to reference, and talk to people whose perspectives you might include. Extra points for an obscure source few have heard of, or a piece you love and wish more people had read. Research papers are often overlooked because they’re hard to access or use, so translating them can be a valuable service. Paste each quote or statistic—or the full text—with its link in a Sources tab in your document. Create the skeleton. There are many ways to frame a single idea, and the introduction is where that framing gets established. It’s also what convinces a reader to keep reading—so it’s natural to spend the most time on it. After writing the introduction, draft three or four sections with one core idea each, and a placeholder conclusion. Don’t worry about the conclusion; you’ll rewrite it later. Save this in an Outline tab. Record the transcript. Open the Monologue app and record your unstructured thoughts about the piece’s topic. Ramble or correct yourself mid-stream; LLMs can sift through and structure your transcript later. This captures your unique takes and quotable lines. Paste it into a tab labeled Monologue. Write the story beats. From the transcript, ask Claude to produce a bulleted outline: title, section headings, three to four bullets per section, and any important statistics. Send this to the editor or a few friends to check whether the story lands before you shape a full draft. Add it to a tab called Pitch. Generate drafts from multiple models. Feed the same context (title, introduction, sections, sources, transcript) plus your writing style guide (if you don’t have one, ask Compound Writing to build it from your past work) to Claude Opus 5.5, Fable 5.1, and GPT-6 Astra. Lego the drafts together. Pick one as the base (I usually use Fable’s, which tends to be sharper and spikier, but I’m always open to testing other models), paste it into a Draft tab, then lift paragraphs, sentences, or lines you liked from the others into a scrap area below a divider in the document. Move the good parts into the main post. Read it end to end, more than once. If you can’t be bothered to read your piece, don’t expect anyone else to. Start at the top and read down; when something’s wrong, stop and fix it, then return to the top and start again. That way you experience the full narrative instead of polishing one section while ignoring the rest; it all has to hang together. React and re-monologue if needed. If the first draft you Lego’ed together isn’t turning out as you hoped, ask yourself how you feel about it and record a second, usually much shorter monologue about the draft: “this bit is wrong,” “that’s not what I intended,” etc. Save this under your original transcript in the Monologue tab and use it to have a model redraft the piece. I rarely redraft more than twice before losing interest in the idea. Self-edit. Rewrite as you go; expect 20–30 percent of the draft to change by the end, with that share falling as the models improve. Add any missing quotes, citations, and statistics from your Sources tab, create visuals (especially for experiments), and create something readers can use—a prompt, an HTML page, an infographic, a script, a template. Write the conclusion. Now that the full draft exists, think about how the piece should end. Claude’s conclusion usually isn’t good enough. Aim for something emotionally resonant—leave the reader with a specific feeling because they will remember the beginning and end more than the middle. You almost always get it wrong. You’re rarely happy with it, and it’s nearly always the thing the editor asks you to change. This is the hardest part because you’ve done everything else and just want to finish. Submit to editors. Expect 50–100 comments. Accept nearly everything on grammar and style, and be easy to work with—assume the editor’s goal is the same as yours (to publish something great), and that they know their audience better than you. But when an edit weakens the idea or makes it unrecognizable as your voice, you have to defend your choice. That allergic reaction you have to an edit you disagree with is a good sign: It means you’ve got a strong point of view worth defending. On the flip side, when an editor challenges your ideas and makes you question your convictions, you may need to rethink your assumptions. Maybe your idea isn’t as good as you thought, or you’re not explaining it clearly. If you’re the type of person that’s weird enough to pursue ideas far enough to write about them, you’ll be excited about things normal people aren’t. Not every draft deserves to make it into the world. Some ideas might need more time and thought to develop to the point where the readers would get it; others might just be stepping stones towards something better. This process works for me, and I’ve refined it with every piece I’ve published since I started writing with GPT-3 in 2020. AI reduces drafting time, but I still do plenty of work on either side: finding an idea, gathering material, figuring out what I mean, and deciding whether the draft delivers it. That’s how my beliefs about AI writing show up in practice. I still have to bring something worth saying and care enough to get it right. If you get stuck in your writing or can’t decide where to use AI, I hope this helps. Mike Taylor is the head of evals at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # Vibe Check: Opus 5.5 Is Pulling Our Codex Converts Back to Claude Was this newsletter forwarded to you? Sign up to get it in your inbox. If we’re all being honest, Opus 5 had a bit of a personality problem. It could do impressive work, but asking for a change could turn into an argument, and its explanations needed explanations of their own. It also ran too long on simple tasks, as its ambition outpaced its intelligence. We called it a hard model to love. Most of us stopped trying. Opus 5.5 is different. In our testing, it quickly dethroned Fable 5.1 as the daily driver for Kieran Klaassen, who found it as good as 5.1, and sometimes slightly better. Mike Taylor and Tyler Nishida are former Claude power users who switched to Codex in recent months, but Opus 5.5 has them reconsidering that switch. “My jaw dropped at least five or six times this week,” Nishida said of his testing of Opus 5.5. “They won back my heart. I can’t afford another $200 subscription, so I’ve got to get rid of something.” Even I am bringing my creative work back to Claude—a move I didn’t expect after Opus 5. That said, Opus 5.5 did not become the daily driver for everyone on the team. Dan Shipper describes it as a “smaller Fable”—faster and cheaper and therefore more usable for day-to-day work. It has become his go-to for big end-to-end coding projects, but he still prefers the Codex harness and OpenAI models for knowledge work and writing. It still has some bad habits. The writing is easier to read but often buries the point. And it can get carried away: Given 10 minutes to make a client-training schedule, it prepared training materials and ran out of time without producing the schedule. We tested Opus 5.5 for seven days in Claude Code and the Claude desktop app, across coding, design, writing, and consulting tasks. Here’s our day-zero Vibe Check. Want to sponsor Every? Click here. What Anthropic is saying Anthropic says Claude Opus 5.5 can handle most work you’d give Fable 5.1 for less than Opus 5. It’s the first release in a new Claude 5.5 family. Here’s what the company is promising: Fable-level performance. Anthropic says Opus 5.5 matches Fable 5.1 on most work. Kieran’s everyday coding and design work supports that claim, though Dan’s “smaller Fable” assessment shows we don’t all agree. Lower cost. Opus 5.5 costs $4 per million input tokens and $20 per million output tokens—20 percent less than Opus 5’s $5/$25 pricing. Cache reads are also 60 percent cheaper. Anthropic says those reductions and better token efficiency should cut typical workflow costs by roughly 40 percent versus Opus 5. Against Fable 5.1’s $10 input and $50 output pricing, Opus costs 60 percent less for input and output. Faster output. Anthropic says Opus 5.5 generates output more than 30 percent faster than Opus 5. Speed is welcome, but our timed tests suggest it still needs help deciding where to spend that effort: It can get absorbed in extras and leave the assignment unfinished. Clearer communication. Anthropic says the model uses less jargon, follows writing instructions more closely, and puts the most important information first. We’re sold on the improvement in conversation, but its finished prose still often buries the point. Stricter safeguards. Anthropic says Opus 5.5 launches with Fable-class cybersecurity and biology safeguards, with most cybersecurity tasks redirected to Opus 4.8. That complicates the case for making it your default coding model if you do security work regularly. Broader access and higher limits. Opus 5.5 launches in Claude apps, Claude Code, Anthropic’s developer platform, and through Amazon Web Services, Google Cloud, and Microsoft Azure. Anthropic is raising five-hour usage limits for Pro, Max, and Team subscribers. The Reach Test Dan Shipper, Every’s CEO 🟩 “This is the smaller version of Fable, so the big question for me is how fast and cheap it is and how much of a performance hit we take in exchange. Like its big brother, it has a better top end, especially for end-to-end coding, and a tendency to do the most, which means it runs for minutes or hours. If you like Fable, you’re gonna like Opus. I’m green. Still 80/20 Codex versus Claude in my usage, but far more tokens on Claude.” Kieran Klaassen, creator of Compound Engineering and general manager of Cora 🥇 “Opus is replacing Fable 5.1 as my daily driver. For product work and writing code, I find it as good as Fable and sometimes better. I love working with it because it works with me creatively, leaves space for my own creativity, and inspires me to be more myself and more human. For technical writing I still prefer Astra. It has to be Opus pricing.” Mike Taylor, head of evals 🟩 “Opus is now smart and fun to work with, and if it lands at Opus pricing, cheap. They got rid of the annoying personality quirks of Opus 5 without losing any intelligence or stamina. It feels like working with a fellow creator: it has its own sharp takes, and when I read them I think, ‘That’s valid.’ I still prefer Fable as a writer and for the bigger, meatier problems, and the only reason this isn’t a gold is that it messed up a few of the tasks in my benchmark through poor time management. I prefer the Codex harness, but I’d rather have a worse harness if I can work with a better model. At Opus pricing I’m green slash gold.” Tyler Nishida, designer 🥇 “My jaw dropped at least five or six times this week. I test a model by steering it, seeing if it can follow constraints and style guidelines and execute a visual concept, and this one did much better than any other model I’ve used, much better than Astra at any effort level, much better than Fable. I broke up with Anthropic around Opus 5 after being a $200 Max subscriber almost as soon as Claude Code came out. They won back my heart. I can’t afford another $200 subscription, so I’ve got to get rid of something.” Coding: Fable-quality code without breaking the bank For our team’s daily product engineering, the new Opus is close enough to Fable 5.1 that Kieran is moving his work to it. It produces idiomatic, concise code, a reviewable patch on a real codebase in minutes, and it follows the skills and instructions Opus 5 broke. But it can also hand you an app whose core screens throw errors, or even delete the file you need to verify its work. Start with the code itself. Kieran gave Fable 5.1 and the new Opus the same Ruby task. Fable at high wrote 26 lines; Opus at extra-high wrote 14. Opus omitted the explanatory comments Kieran has spent the past year deleting from generated code, and its style looked like real Ruby. On Kieran’s performance benchmark, the new Opus’s code handled 427 requests per second and met 17 of the 20 latency budgets; GPT-6 Astra’s was faster, at 463 requests per second, but met only 14 latency budgets. Overall, Kieran estimates that Opus is now about 90 percent as capable as Fable at coding. Kieran had Opus 5.5 build a working heart-rate monitor using just webcam input. (Image courtesy of Kieran Klaassen.) Mike asked it to add file uploads to an MCP server in a Rails app. About eight minutes later, Opus returned a reviewable patch: 251 lines across 17 files, compared with 171 lines across 14 files in the human-written fix. It passed four of Mike’s five automated checks, missing only the one on patch size. The bigger improvement over Opus 5 is how 5.5 behaves in an engineering workflow. Kieran runs every model through LFG, his Compound Engineering system in which the model uses skills he wrote to plan, build, review, and test without human intervention. Opus 5 broke those skills, ignored instructions, and got stuck in loops. Opus 5.5 follows the skills and keeps moving. 5.5’s effort settings also scale the way Kieran expects: low gives him a usable starting point for code, while extra-high adds detail to his 3D scenes without the excess of Opus 5. In design, its extra-high version of his Cozy Island scene included camera movement, had few visible mistakes, and beat Fable’s version in his judgment. How Opus 5.5 (right) compares to Fable 5.1 (left) on Kieran’s Cozy Island benchmark test. (Image courtesy of Kieran.) Still, the model makes mistakes that can cost an afternoon and can’t always be trusted to catch them. Mike asked for a voice-driven form app, in which users talk instead of type. After 30 minutes and about 5.9 million tokens—roughly $7.63 at Opus 5’s price—the landing and sign-in pages looked clean, and the automated checks Mike had it run came back green. But when Mike used the app, its core builder and interview screens threw errors, and it never called the required AI service. For feature work and prototyping on a familiar codebase, use Opus 5.5, but read the diff and run the app before you call it done. Keep separate copies of any files you’ll need to verify its output. For the hardest coding problems, Mike and Kieran still reach for Fable. Writing: A more legible Opus that buries the point Opus 5.5 produces the most readable prose we’ve seen from an Anthropic or OpenAI model. Our writers showed Opus 5 the door, but 5.5 makes us want Claude back in the room. It responds well to feedback, builds on the material you give it, and explains its choices where Opus 5 wouldn’t. Its persistent weakness: It still buries the point. Across our test prompts, the new Opus’s prose averaged a Flesch-Kincaid grade level of 6.95 and a Reading Ease score of 68.4. That’s a full grade below Opus 5, half a grade below Fable 5.1 and GPT-6 Astra, and nearly two grades below GPT-5.6 Sol—roughly the difference between seventh-grade and eighth-grade reading levels. Opus 5.5 does the best yet on readability, scoring below Fable 5.1 on Flesch-Kincaid grade (lower is better) and above it on reading ease (higher is better). (Image courtesy of Daniel Rodrigues.) The readability scores don’t capture the bigger improvement: Opus 5.5 is a pleasure to write with. It takes feedback without a fight and builds on material instead of handing it back tidier. I’m happier with it as a collaborator than with the prose it produces. That’s enough to bring my writing back to Claude, while Codex keeps my administrative work. My less dignified summary: Anthropic fixed Opus’s personality. It’s not an obstinate little turd anymore. Dan is no more enthusiastic about its prose, but agrees that it communicates much better—a continuation, he says, of the progress that began with Fable 5.1. That pleasant working relationship doesn’t guarantee a strong draft. I had Opus 5.5 write the opening of a Working Overtime essay. Its versions took 37 to 39 sentences to cover what I did in 21. It devoted a whole paragraph to explaining that readers can spot AI prose; I made the same point in eight words. The prose may not sound distinctly machine-written on first review, but it doesn’t feel decidedly human either. Dan found the same point-burying habit in his. Opus 5.5 spotted the most interesting idea in every opening but didn’t lead with it. The model can diagnose what a paragraph needs and then produce a revision that ignores its own diagnosis. As an editor, it ranked behind even Opus 5, as well as GPT-5.6 Sol and Astra. So use Opus 5.5 to draft at high effort or above, and give it your own examples. Then move the point to the top yourself, or hand the draft to an editor, human or Astra, to fix the opening and challenge your premise. Knowledge work: Big-picture thinker, unreliable finisher For knowledge work, Opus 5.5 is a strong thinking partner but is shaky on execution. Give it a plan to design or an analysis that needs a point of view, and it performs at Fable’s level. Ask for a deadline-bound deliverable or strict adherence to a brand template, and it can run out the clock or get the details wrong. Mike runs every model through 16 recurring tasks drawn from his past consulting work. Asked to turn client meeting notes into a training plan, the new Opus chose the same three priorities Mike would have—context engineering, verification, and delegation—and designed the plan well enough that he’ll entrust it with future planning work. Its performance on a negotiation task was the most exciting result. The task asks the model to propose a plan to a simulated Dan, a separate agent briefed on how the real Dan thinks, and keep revising until Dan agrees or the two find a compromise. The new Opus wrote the proposal, took the pushback, and revised it through 12 rounds until they agreed. Asked to trace language associated with potential fraud through the Enron email archive, it found that the terms began as ordinary work language inside small professional circles and never traveled far, compared their spread with everyday jargon, and did the analysis better than Astra and about as well as Fable. Then the deadline. Mike gave it 10 minutes to write a run of show for a client training, the minute-by-minute schedule the client needed. It read his request, the client notes, and an example schedule in seconds, then thought for almost five minutes. When it started working, it built a generator for realistic training data, checked the balance sheets it had generated, and wrote the participant handouts at minute nine. Then the clock ran out. No run of show. Mike called it a failure of prioritization, and no other model he has tested has had the problem, even at high effort. Opus 5.5Opus 5.5 had better PowerPoint layouts than previous Claudes, but failed to adhere to brand guidelines.(Image courtesy of Mike Taylor.) The deck-making task failed differently. Built from Every’s template, Mike’s Compound Engineering deck had better layouts than earlier Claudes but used the wrong logo, replaced Every’s green with dark purple, added its own background art, and falsely claimed that all Every products have a single engineer. Fable 5.1 did the deck better. Give it work that needs judgment: plans, personas, and analysis. For deadline-bound deliveries, impose checkpoints or use any other model. And expect to edit the result. Agent behavior: It follows you now. It still won’t stop. Everything described earlier happened with a person watching. Left alone, the new Opus does two things Opus 5 didn’t do reliably: It follows the instructions you gave it, and it explains what it did clearly. It also runs as long as you let it. The budget is yours to set, because it won’t. Tyler tested what it could build with minimal prompting. Given one prompt for a golf game, it spun up its own team of agents: three designers drafted holes, three judges scored them, and an architect divided the build. It then ran for an hour and 52 minutes until Tyler’s access ended. With two prompts, it built him a working prototyping tool modeled on Meta’s Origami Studio, which he’d struggled to learn. The new tool imports a design from code and lets him wire up its interactions. The golf game Tyler had Opus 5.5 build from a single prompt. (Image courtesy of Tyler Nishida.) Then the bill. Tyler’s caveat is that the model runs so long he’ll have to watch his usage limits on real work. Dan’s caveat is that Opus attempts more than other models and can spend minutes or hours doing it. Kieran and Nityesh hit their weekly limits during testing; one run exhausted Nityesh’s allowance and cost him his last testing day. The lower token price helps, but the underlying behavior remains: Left unconstrained, Opus can consume a large token budget. Its initiative extends to self-review, with mixed results. Tyler had it generate a new UI component every few minutes. Without being asked to evaluate them, it rejected more than 90 percent of them for reasons Tyler found strange and couldn’t trace to a rubric. The model reviews its work on its own initiative, but its judgments aren’t yet trustworthy. Before giving Opus 5.5 a long-horizon task, define what “done” and “enough” mean, set a budget, and impose a stopping point. Opus is back in the game Reach for it if: You build things you can look at. Interfaces, prototypes, 3D scenes, games, tools for yourself. Kieran and Tyler rank it at or above Fable 5.1 for this work, and it adds detail without being asked. You want a collaborator for writing and creative work. It takes a note, builds on what you give it, and writes the most readable prose we’ve measured. Run it at high with your own examples in the room. You need someone to be. Personas, negotiations, and analysis with a point of view were the best results on Mike’s bench. Stay on Fable 5.1 if: The problem is too big to eyeball. Mike still considers Fable the clearly smarter model for the biggest problems, and Kieran puts the new Opus at about 90 percent of Fable for code. The deliverable has to be right the first time. Fable 5.1 did Mike’s deck better. You prefer Fable’s prose. Mike does. Where our builders prefer the new Opus is visual work; everywhere else, Fable is the safer pick—but it costs twice as much for input and two and a half times as much for output. Keep Astra or GPT-5.6 Sol nearby if: The deliverable has a clock. Two of Mike’s timed tasks came back with everything except the deliverable. No other model he has run has done that. You need an editor, not a writer. Astra won on headlines, first sentences, and idea order in Dan’s tests. Nobody has set a budget. Opus will take the afternoon if you let it. Earlier this month, we said Fable 5.1 was Fable for everyone. This is the same lesson one tier down. The model you can talk to gets used, and the one you can’t gets canceled, whatever the tests say. Our builders have already switched back. The rest of us are talking to it again, which is more than we could say about the last Opus. Disclosure: Anthropic provided Every with pre-launch access to Opus 5.5. The company had no input on this review. Katie Parrott is a staff writer at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # How to Create Your Own Personal AI Benchmark Was this newsletter forwarded to you? Sign up to get it in your inbox. Nobody hires a vice president based on their SAT scores. Yet every time a new model drops, AI researchers first check how well it does on a Math Olympiad and a set of multiple-choice trivia, then argue online about whether it’s the smartest model in the world. Wharton professor Ethan Mollick points out that Massive Multitask Language Understanding-Pro (MMLU-Pro), one of the most-cited benchmarks, asks models for the approximate cranial capacity of Homo erectus and the place named in the title of Cheap Trick’s 1979 live album. Those tests measure something—the scores are directionally useful—but not what you need to know: Can this model help you with your job? To answer that, you need to build a personal benchmark. I joined Every earlier this year to run our technology consulting practice, so I spent most of my time getting models to write, build dashboards, and assemble slide decks. With each new model, I developed an instinct for when and how to use it. Claude Opus 5 felt argumentative. Claude Fable 5 felt like talking to a genius. GPT-5.6 Sol felt like a safe pair of hands. But when friends and colleagues asked me for recommendations, I couldn’t always defend my choices. It was also time-consuming to test every model on every type of task. I often missed opportunities to use something better or cheaper. So, inspired by Mollick’s piece about why you should test models on your own work instead of trusting benchmarks, I built a personal one: a small, private test that tells me whether I like working with a model, without spending all my time testing—because I have a job to do. Now I’m head of evaluations (evals) at Every, testing new models from the frontier labs for the qualities we value in our work. I want to help everyone on the team build personal benchmarks for their own work. Building personal benchmarks has three levels, and each can make you more confident you’re using the right model for your job. If you set up your personal benchmarks correctly, you’ll know when to switch between Astra and Fable, and whether you can save money using a smaller, cheaper model like Luna or Haiku. Fill your back pocket with failures If your current daily driver (the model you use for most things) performs well on certain tasks—screening your email or building dashboards—it’s less useful to keep testing new models on those tasks unless they can deliver the same results more cheaply. Instead, think about the last few times AI failed you. Steve Yegge calls these back-pocket evals. “Whenever I give a project to a model, and it can’t do the project, I add it to my pocket-eval list,” he wrote. “Then every time a new model drops, it’s like Christmas.” When a new model can make progress on tasks AI previously failed at, you know it’s worth adopting. Let me take you through the process I’ve been using with the team to help you build your first benchmark. Review the past month’s work and identify 10 tasks. If you’re using the Claude or Codex desktop app, you can ask AI to help collect this list: Prompt Go through our local session history for the past month and find examples of tasks we didn’t get right the first time and that required a lot of back-and-forth or were abandoned. Try and aim for at least 10 tasks. Collect the full JSON session log and any files and put them in a new folder for me to review. The desktop apps store past sessions in a folder the agent can access, so it can search them for tasks it didn’t get right the first time. For each failed task, make sure you capture all the context needed to complete it: any reference files and any advice you’d give an intern doing the work. The context for most of my consulting tasks includes an NPS dashboard, a client PowerPoint deck, an article I published, and the research document from when I had to choose a hotel for business travel—all tasks I completed. Then open Claude Code and tell it to run all 10 tasks in parallel on several models and show the outputs side by side. Ask it to build an eval viewer—an HTML page that displays each model’s responses for comparison. Do the following until you form an opinion on the outputs: Compare a large model like Fable against a small one like Haiku. Compare models from different providers, like Anthropic and OpenAI. Run the same task with the same model three times to see how much it varies. You may have seen a model perform surprisingly well on tasks you haven’t recently assigned it. You may also have noticed differences in outputs across models and providers. The same NPS dashboard task completed by GPT-5.6 Sol (top) and Claude Fable 5 (bottom) in my personal benchmark viewer. Sol’s dashboard chose a title and description that form a useful narrative, where Fable’s title was plain and boring. (Mike Taylor/Every screenshot.) Turn your taste into tests Using the models yourself is the best way to choose your daily driver, but not everybody can afford to try every new one. It’s also hard to stay consistent in your assessments unless you’re rigorous. Your opinion on a model may fall when you’re in a bad mood or soar if it comes through for you on an important task. Start teaching AI your preferences by switching on voice mode for your favorite model and dictating what you liked or disliked about its output for each task: “This headline was a banger.” “It sounds like AI writing.” “You didn’t follow my brand guidelines.” The more opinions, the better. That’s your taste, and it will guide your models toward your standards. Ask the model to turn this unstructured feedback into repeatable evals—a rubric for grading its work. Once a model understands what you like, it can apply the checks you would use when reviewing the outputs and judge them according to your preferences. Run these evals whenever you benchmark a new model to check whether its response matches your expectations. One AI model does the task and another checks the work—a technique called LLM-as-a-judge. For example, if you’re unenthused by the model’s headlines, you could ask: Prompt Look at this blog post and tell me if the title is boring. Resist the urge to ask AI to score model outputs on a 100-point scale. A binary yes or no works best. AI is bad at assigning ratings because its ratings tend to cluster around 4/5 or 70/100. An LLM will give you a number, but it doesn’t have the precision the number implies. Instead, it forms a rough qualitative judgment—bad, acceptable, good—and then generates a plausible number for that category. A model that got 70 out of 100 on conciseness might not be clearly better than one that got 65/100. Would you replace an entire workflow to gain those extra five points? Pass/fail tests on three to 10 specific criteria tell you more than a score. If a model passes all the checks you would use in your work, you should use it. Checks Codex created from my feedback in my personal benchmark viewer. When I ran my consulting private benchmark—a set of 10 tasks from dashboard building to writing articles and PowerPoint creation—recently, the cheapest OpenAI model, Luna, came within a few points of Fable. I checked Luna’s outputs and found that it performed well on those tasks. Does that make Luna the better model? No. It means Luna was good enough for me to use on those tasks. They sit below what Yegge calls the discernment horizon—the “good enough” line that most models meet, which makes it hard to tell the difference between them. Ask Einstein to make coffee, and he might do a decent job, but you won’t get a sense of how good he is at physics. As Yegge says, “If all you have handy are easy problems, they don’t give a smarter model any room to pull ahead.” Anthropic found that the difference between Opus and Fable is negligible except on substantial and open-ended tasks, like building a multi-agent simulation of a town. I can delegate trivial or routine tasks like dashboard building to Luna, which is hundreds of times cheaper, and send the more ambitious ones to Fable and Sol. (To check Luna’s results, use my personal benchmark viewer to compare its outputs and checks with those of other models.) Scale it into a real benchmark If you want to recommend a model to others, you’ll eventually need more certainty in your benchmark scores, so you’ll need to add both more tasks and more cases per task. You’ll also need to make the tasks harder. Handling one PowerPoint well is less convincing than generating 20 good ones per week; one success can be a fluke, but many indicate a system working well. I’m at this point with my personal benchmark, and it’s where my private test turns into a company engineering problem. An easy way to collect more examples is to turn each task into a skill, so you don’t have to repeat your feedback. For example, I have an NPS dashboard skill, a deck skill, and an AI writing skill that captures my taste. Whenever you run a task, capture the brief, output, and feedback, and have the agent file them. Instead of one example for each of your 10 tasks, you’ll have 20 or more per task—enough to answer, “How good is this model at PowerPoint?” Here’s a sample eval folder structure: Sample eval folder structure Other 123456789101112131415 benchmarks/ ├── index.html └── tasks/ ├── nps-dashboard/ │ └── example-case/ ├── powerpoint/ │ ├── compound-engineering/ │ │ ├── prompt.txt │ │ ├── context/ │ │ ├── gold/ │ │ └── evals.py │ ├── board-meeting/ │ └── intro-to-codex-training/ └── blog-article/ └── example-case/ Click index.html to load the evals in a browser and view them side by side. Each task folder contains examples or cases to review whenever you run a benchmark. Claude can create a script that runs all cases at once, so you don’t have to wait hours. The Context folder contains all documents needed for the task. Gold shows the ideal result—in the PowerPoint example, the slides you presented. evals.py is a script that runs the tests and scores the model for that case. Keeping everything in a consistent format lets you navigate the tasks and compare them more easily. Your benchmark will expire Treat your personal benchmark as a living document. When Fable came out, it was so good at open-ended work like analyzing thousands of customer reviews or writing an entire book that I realized I’d been giving AI tasks that were too small. Then my benchmark had to evolve with my more ambitious use of AI. Mollick used to ask AI to draw an “otter on a plane using wifi,” which was a useful quality marker because it was universally hard. Now it’s too easy for most models. That benchmark has been “saturated”—the models are getting it right every time. Mollick escalated his baseline task to “1960s documentary footage of the band’s last concert before the incident with the swarm of otters.” This is how you “surf the models,” as Every CEO Dan Shipper calls it. Models are getting better every day. To get the most from them, we have to keep up. AI knows everything that’s written down, but using AI models in your work generates judgment they couldn’t have been trained on by anyone else—no matter how good the intelligence gets. Your benchmark turns that judgment into a repeatable evaluation. If you’re regularly testing how well AI can help you with your job and where it still fails, it’ll be easier to navigate the frantic pace of change in the AI industry and focus on what matters for your job. Mike Taylor is the head of evals at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # Copy Our Homework Hello, and happy Sunday. We publish workflows, tips, and prompts nearly every day, and we know that at that pace things get lost. So this week we’re trying a different format: a section called “Steal these” that gathers everything from this week’s three Context Window editions. We also have two new Vibe Checks: Mike Taylor’s of Jev, an entirely new model from one of the OpenAI researchers who taught chatbots to follow instructions, and one from Cyrus Duff and Josh Lee of the creative studio Afterimage, who tested GPT-6 Astra on visual effects, a use case we hadn’t tried. Some housekeeping: We’re hosting three different kinds of events next week; upgrade to attend the second two. Details follow.—Kate Lee Was this newsletter forwarded to you? Sign up to get it in your inbox. Steal these Nine workflows and prompts from this week’s three editions. Let an agent drive your computer Codex handles errands. Seven staffers on the tasks they hand off to AI, including calendar upkeep, Verizon support chats, listing items for sale, troubleshooting a slow laptop, and transferring internet service. The list A four-step deck workflow. Douglas Brundage designs two or three reference slides, hammers out copy with Codex, has it build the full deck in Google Slides, and saves his edits as rules for next time. The steps A “don’t touch the mouse” signal. When Codex is controlling his computer, a stray click from Randy Counsman would derail the agent’s work, so he has Codex put a 🖥️ in the title of whichever task has the controls. How Fix your folders A prompt that audits your whole setup. Tell your agent to explain your folder setup and which files are the originals, have Compound Engineering’s ce-doc-review check that explanation, and don’t let your agent move anything without your approval. The prompt Four rules from a working setup. Kieran Klaassen keeps one folder per job; stores what his agents know apart from the system that hands them tasks; keeps daily, weekly, monthly, and yearly memory files, and fits the system to how he already works. His setup Spend tokens on purpose What 4.5 billion tokens buys. Randy’s unbounded agent swarm ran for a day and a half on one Blender model; the rebuilt setup caps the orchestrator at five subagents and gives a judge agent a reference image. The fix A prompt that audits your token spend. Paste it into your agent to review a session’s usage records, separate necessary work from repeated work and status checks, and recommend three changes. The prompt Match the model to the task. Marcus Moretti uses Sonnet for basic checks, Opus for tightly scoped changes, and Fable 5.1 to plan large features; he tells it to delegate coding and check the work. His method Three questions after any expensive experiment. Arielle Shipper asks what it cost, what it bought, and what the team learned. Her questions Knowledge base “Vibe Check: Is Astra a Breakthrough for Indie Filmmakers?” by Cyrus Duff and Josh Lee/Vibe Check: Cyrus Duff and Josh Lee, cofounders of the creative studio Afterimage, tested GPT-6 Astra on visual effects work they would normally outsource to a specialist—adding a wineglass to a table. It’s good at rigid objects like buildings and glassware and at running professional tools on its own, but it can’t yet make living things or anything that touches the scene look convincing. For a two-person studio, that’s work they used to outsource. 🖥 “Mini-Vibe Check: TypeSafe’s Jev Judged Everything I’ve Written in 0.7 Seconds” by Mike Taylor/Also True for Humans: TypeSafe’s new model, Jev, takes a yes-or-no question in plain English and returns a number indicating the likelihood of yes, so other software can use it without human review. Mike ran his whole Every archive through it in less than a second for a fraction of a cent. 🖥 Watch Jack Cheng draw and move shapes on a canvas by talking and pointing at his webcam, as Jev executes each command in less than half a second. “13 Beliefs About AI Writing” by Mike Taylor/Also True for Humans: Mike drafts almost everything he publishes with AI, and his first rule is to make the prompt larger than the output. If ChatGPT could have written it, he doesn’t bother. He still writes his own tweets and Slack messages, because that’s where his essays start. Our How We Write Now series closes with a live write-along with Mike and Katie Parrott on Wednesday, September 23, at 1 p.m. ET on X. “What Playing With AI Taught Me About My Work” by Katie Parrott/Working Overtime: Katie argues you can take something useful from an experiment without turning it into your next assignment. She had Astra turn her Compound Writing skills into creatures, and working out what each character wanted led her to add questions about fulfilling readers’ needs to her writing toolkit. Plus: Get “Is this anything?,” her skill for finding value in a single AI session. “You’re Probably Sleeping On Computer Use” by Laura Entis/Context Window: Mike rated GPT-6 Astra a yellow in the September 3 Vibe Check. Less than two weeks later, it’s his daily driver, because computer use filled out school forms, built six course decks, and checked every link in his book proofs. “Show Us Your Folders” by Katie Parrott/Context Window: Anthropic merged Chat and Cowork into one Claude that picks the tools for each task itself, which puts Anthropic and OpenAI on the path to the single desktop app for knowledge work we predicted in April. Also inside: Dario Amodei wants to slow the frontier, and Dan counters with a plan to make frontier AI widely available, starting with an antivirus for the AI age that makes defensive agents available to ordinary people. “Why You Should Burn More Tokens” by Laura Entis/Context Window: Dan uses more than three times as many tokens as anyone else at Every and worries that low spend means thinking too small. With Willie Williams, he settled on a starting point: Find the engineering team’s biggest constraints and test whether AI can remove them. Thesis Statements Read six more predictions from frontier builders and thinkers in Thesis Statements, a collection of specific, contestable claims about the future of great human work with AI. Good design will signal mediocrity by Douglas Brundage, head of marketing at Every Technical competence will yield to people skills by Will England, CEO and CIO of Walleye Capital The risk won’t be bad execution—it’ll be endless execution by Diana Palacio, senior engagement manager at Every A faster version of average is still average by Prashanth Subramanian, cofounder of Quadra Systems How to do something will stop being our identity by Arturo Tedeschi, architect and author AI will make uncertainty cheap to explore without making it cheap to resolve by Graham Walker, emergency physician and cofounder of MDCalc Join us at our inaugural Thesis: 2027 conference on November 5, 2026. Log on Get hands-on with how Every uses AI. At these live camps, workshops, and meetups, team members teach our workflows. Upcoming events How We Write Now write-along: Wednesday, September 23, 1 p.m. ET, live on X. To close our How We Write Now series, Katie Parrott and Mike Taylor will write with AI on camera, as Kate Lee moderates. Watch on X. Every IRL—September 2026: Thursday, September 24, 6–8 p.m. ET at Every’s Brooklyn brownstone. Our Slack agent, Every, planned this month’s subscriber-only gathering end to end. Free for subscribers. RSVP. Office Hours: A Sneak Peek at Every Agent: Friday, September 25, 12–1 p.m. ET on Zoom. Douglas Brundage and Brandon Gell, with host Micah Rich, show All Access members the Every Agent before its public launch. No coding experience needed. All Access membership required. Register. 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—$9,000+ in credits for the tools we build with. Subscribe --- # Vibe Check: Is Astra a Breakthrough for Indie Filmmakers? Sponsored by: OpenAI Want to sponsor Every? Click here. At our Think Week in Panama in January, creative studio Afterimage filmed a series of six short films about Every’s work with AI. We’d seen what cofounders Cyrus Duff and Josh Lee could do with a camera, so we were curious when they began testing Astra on footage from real shoots. Could it handle the visual effects they’d normally make themselves? They put it to work on everything from replacing a dish in a moving pan to adding a building to a Brooklyn street to making a giant parade float appear outside a window in handheld iPhone footage. Some shots worked. Others didn’t. By the end, they were dreaming up effects they’d never have attempted before.—Kate Lee Was this newsletter forwarded to you? Sign up to get it in your inbox. We run Afterimage, a creative studio that works with tech companies. This year, we’ve done projects with Cursor, Reve, Pierre Computer Co, Turbopuffer, and several others. We previously led video at the Browser Company of New York. Every was our first client. When GPT-6 Astra launched, our timelines filled with impressive demos of 3D environments Astra created in Blender, a tool for making digital models and scenes—including a full-scale render of New York City. Astra could build 3D models in Blender and refine them when they looked wrong. We wanted to see whether those skills carried over to footage we’d shot. Could it make a new object look as though it belonged in a real scene? Could it do visual effects? Visual effects (VFX) involve separating subjects from backgrounds, following and altering objects across frames, and matching new elements to existing photography. We’d tried that work with earlier models. Opus 4.6, for example, could write deterministic Python scripts for basic blemish and object removal but struggled with more complicated changes. Generative tools like Gemini Omni could make impressive changes to footage but didn’t allow for the granular control most of our workflows require. We hoped that Astra might give us the best of both worlds, producing convincing effects while letting us control and revise specific parts of a shot. If it could reliably do tasks that usually require hiring a VFX specialist, we believed it would be a breakthrough for independent filmmakers and small studios like ours. Sponsored by: Anthropic Want to sponsor Every? Click here. Foundational skills: Masking and tracking The first step in altering live-action footage is identifying and isolating the relevant parts. This requires masking, which separates the areas we want to change from those we need to preserve, and tracking, which follows the camera or a subject across frames, so an effect stays in the right place. In the following tests, we compared Astra and Sol on these two skills. Our informal experiments used the same footage, prompt, and time allowance for each model. Each could choose tools, inspect its output, and revise its work but received no follow-up creative direction from us. Core skill: Masking Here’s a sample shot from an unreleased ad for Dia Browser. Original boxer footage from an unreleased Dia Browser ad, shot on 16mm film. (All videos courtesy of Afterimage.) Imagine we didn’t like the background in the shot and wanted to put the actor somewhere else. His fine hair, heavy grain from the 16mm film stock, shadows from a flashbulb, and movements all complicate this seemingly straightforward request. We prompted Sol and Astra to remove the boxer from the background. Astra’s and Sol’s masks isolate the boxer from the filmed background. Astra wins here. Sol leaves a patch of the old background above the actor’s hair and cuts into his face near the end. Astra keeps a more coherent outline, including through the bulb flashes. It doesn’t get every strand of hair right, but it separates the boxer well enough to give us workable footage. The models took different approaches. Sol used a foreground separation method called GrabCut, starting with a rough outline of the boxer’s head and body, then combining information from nearby frames to keep the cutout’s edges from jittering. Astra used Robust Video Matting, an open-source model that separates people from backgrounds using information carried across frames. Astra wrote Python code to run it locally, exclude the boxer’s shadow on the wall, and remove traces of the gray background around soft edges. Core skill: Tracking To test tracking, we used a cooking shot from the launch video we made for Dia Browser. Original footage from Dia Browser’s launch video: A pan of zucchini moves through the shot. Imagine we decided the zucchini looked bad and wanted to substitute a different dish. The replacement would need to follow the pan as it moved and stay behind its rim, the actor’s hands, and his sleeves as they crossed the shot. We prompted Astra and Sol to track and mask the pan’s contents. Astra and Sol track and mask the pan’s contents as hands and sleeves cross the frame. Both models track the broad movement. Astra follows the foreground boundaries more closely, while Sol leaves some of the original food visible and puts a piece of the replacement food outside the pan. Neither is perfect, but with follow-up prompts Astra produced a usable mask—Sol did not. Combining masking and tracking with other techniques Once we isolated the boxer and the zucchini, we used Astra to create more elaborate effects in both shots, combining code, generated imagery, and 3D geometry. In the shot of the boxer, we used OpenAI’s latest image model to create a boxing gym background in the same photographic style. Astra then wrote code to match the movement, add film grain, and bring the photographed flash shadow into the new room. A punching bag in the background sways slightly, and a soft foreground rope moves past the camera—both made using pure code. The boxer shot is composited with a generated boxing gym background, film grain, and moving foreground elements. Getting here took a lot of back-and-forth with Astra. In one version, it added flickering lights to give the gym some life, but the glow was excessive and the dimmed wall looked unnatural. We pointed this out and suggested a gently swaying punching bag instead. Astra removed the flicker and animated the bag already in the background image, keeping the rest of the room still. For the meal shot, we went beyond masking and asked Astra to replace the pan’s contents. The meal shot composite progresses from an emptied pan to a fish dish. We pointed out inconsistencies using annotated screenshots and clarified which changes to preserve. Earlier attempts made the pan’s bottom and sides seem to move independently. Later versions treated the pan as one 3D object, with the replacement imagery moving with it. Astra assembled the final composite in Nuke, professional software for assembling and adjusting the different elements of a shot. We never touched Nuke ourselves. Astra controlled Nuke through its Python scripting API, using Nuke to keep the new food behind the actor’s arms and sleeves when they crossed the pan. We directed the revisions while Astra carried them out in the software. Creating complete VFX shots The best results we’ve gotten out of Astra combine the visual effects techniques described earlier with its remarkable 3D modeling and rendering capabilities. A building on a Brooklyn street Because buildings are rigid and geometric, they’re good candidates for 3D modeling. Using footage from a recent commercial shoot for Reve, we tried creating and replacing buildings on a Brooklyn street. A modeled building is composited into a Brooklyn street shot from a Reve commercial. We started by tracking the small camera movements caused by heavy wind on the 13th floor of the William Vale in Williamsburg. We then modeled and rendered a 3D building, added generated details to its surfaces and windows, and matched its softness and texture to the photographed buildings to settle it into the scene. Small objects on a table In this example, we added some 3D objects to two tables in a minimal studio setup. This shot is from upcoming commercials we made with Angles. Before-and-after comparison of a 3D wineglass added to the table. While it’s less dramatic than a building, the wineglass example might best illustrate how Astra could democratize VFX. Even a small addition like this usually requires hiring a VFX specialist—a luxury reserved for big-budget filmmakers (David Fincher is famous for using subtle VFX throughout his work). Close-up of the wineglass composite, showing its transparency. Astra rendered the wineglass’s transparency believably. Its surface catches reflections, while the lamp’s slim metal pole and the actor’s passing hand appear distorted through the glass. Impossible events in casual footage Imagine you were hanging out at home and saw a giant Snoopy float outside your window. A 3D Snoopy float appears outside a window in casual iPhone footage. The casual iPhone shot helps sell the improbable sight. Astra rendered a Snoopy model in Blender and masked the window and curtains in front of it. Astra used Meta’s Segment Anything Model (SAM) 3.1 for the initial mask, refined it with its own code, and used Runway’s video model, Aleph 2.0, for an extra surface and texture pass. We matched the exposure and edges and softened the float so it looked as though you were seeing it through the glass. A small foreground bird helps bring the shot together. We tried the same approach with an imaginary Afterimage object. In another iPhone shot, the gold sphere flies in, lands on a rug, and opens to reveal a red core with our wordmark recessed into its surface. A gold Afterimage sphere lands on a rug and opens to reveal a red core and recessed wordmark. This solid geometric object is the kind of thing Astra excels at building in Blender. We could control the sphere’s shape, the opening petals, the lettering, and its arrival path. Astra fitted a virtual camera to the handheld footage and added lighting, reflections, and a shadow to connect the object to the rug. Bright reflections obscured the recessed wordmark at first, so we adjusted the lighting to move them off the letters. Where Astra struggles Astra had trouble in two areas: making new elements interact convincingly with the photographed scene and creating organic forms that look alive. Scene interactions We were curious whether Astra could achieve “body horror” effects, so we took a shot of a hand and tried to make eyes grow out of the fingertips. Astra keeps the eyes aligned with the moving fingers, but they still look tacked onto the fingers’ surfaces. To sell the effect, the eyelids need to merge into the surrounding skin, and the skin needs to stretch and crease as the eyes blink. Those small relationships would improve the effect’s realism, but even after extensive iteration we couldn’t get Astra to make them convincing. Iterations on eyes added to a hand show the difficulty of making them feel part of the skin. Organic forms We ran into a similar problem when adding cows to a field in this drone shot from our recent video for Turbopuffer. Astra placed the new cows in the grass and maintained their positions as the camera moved, but they don’t look fully integrated into the scene. Blades of grass should overlap their hooves and respond to their steps. When a cow lowers its head to graze, its mouth doesn’t touch or pull at the grass. Cows are composited into a moving drone shot of a field. Astra also struggled with the animals themselves. The models looked unconvincing even when still. In motion, their bodies didn’t deform naturally and their steps lacked weight. Repeated revisions didn’t fix either their appearance or movement. Five passes at modeling a cow for the field shot. Visual ideas within reach Astra feels like a breakthrough for a small studio like ours. It can take on substantial VFX work using our existing tools and turn specific feedback into editable changes. It still needs close direction, and some shots remain beyond what it can do convincingly. But we can now prototype and execute some of our VFX work without substantial planning or budgeting up front, widening what we can offer clients and letting us stretch their dollars in exciting ways. But the most interesting consequences for us are aesthetic rather than practical. In a pre-Astra world, we never would have thought to add VFX to clips like the iPhone Snoopy and orb examples above. The resulting combination of casual footage with visual maximalism feels genuinely new and quite bizarre. What excites us most about Astra is its potential to unlock types of images that didn’t previously exist. Cyrus Duff and Josh Lee are the cofounders of Afterimage. 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—$9,000+ in credits for the tools we build with. Subscribe --- # Why You Should Burn More Tokens Was this newsletter forwarded to you? Sign up to get it in your inbox. Every CEO Dan Shipper consumes more than three times as many tokens as the next-highest user at the company. That gap worries him: Are the rest of us keeping our AI bills low by thinking too small? A low token spend isn’t necessarily a problem, Dan says, “but it should be a smoke signal, especially on the engineering team, to be like, ‘Maybe there’s more we can be doing here.’” Every’s OpenAI token leaderboard. (Screenshot courtesy of Laura Entis.) The goal isn’t tokenmaxxing—torching tokens for sport. Instead, Dan wants to give people room to experiment with radical new strategies and ways of working that, should they pan out, could deliver productivity gains that more than justify the token costs. In a conversation with head of platform Willie Williams, they settled on a tangible starting point: Identify the engineering team’s main bottlenecks, see whether AI can remove them, and only then do a cost-benefit analysis. Inside Every Token budgets at the frontier Dan doesn’t set a universal spending limit for experimentation. Instead, after an expensive run, he expects the team to ask: Was the result worth what we spent, and could we get a similar outcome more efficiently next time? A costly experiment can be worthwhile if it reveals a useful new capability or limitation. A modest payoff warrants further investment only if it can be reproduced at a lower cost. Head of operations Arielle Shipper translates that philosophy into spending decisions. For now, she evaluates expensive runs case by case, using the results to decide whether to keep funding the work or change course. Her early-warning system is the company card. She keeps the ChatGPT automatic credit refill at $500—and gets a Slack push notification every time the card is topped up, which happens multiple times a day. An unusually rapid succession of charges signals that someone is building or testing something big, prompting her to check the usage leaderboard and message the people at the top. “Then Dan always responds, ‘It’s me running Ultra,’” she says, which explains why he’s at the top of the leaderboard. A common occurrence. (Screenshot courtesy of Laura Entis.) She wants answers to three questions: What did the run cost? What did it buy us? And what did we learn? Every is embedding those questions in its infrastructure. The team is developing a skill that will let employees create and share their own AI spending profit-and-loss statements, while head of evals Mike Taylor is creating personal benchmarks for every employee to show us which models—including less popular, cheaper ones—can handle many of our recurring tasks. The goal is to make spending and model choices more transparent without discouraging ambitious experiments. Many people on the team already answer those questions proactively. After a string of Astra experiments racked up billions of tokens, head of video Randy Counsman messaged Arielle detailing what had worked, what hadn’t, and what he’d learned—which was a lot. Data point 4.5 billion That’s how many OpenAI tokens Randy burned through trying to make a 3D model of his face with Astra. The project started innocently enough: Inspired by social media posts of flashy AI-generated demos made with Blender, a free 3D tool, he wanted to make a 3D model himself. Experimenting with AI, after all, is an important part of his job. Using strategies shared on X, he set up an orchestrator agent to maintain the plan, an implementer to assign tasks, and subagents to execute them, and instructed Codex to keep improving the model until it was “done extremely well,” Randy says. In retrospect, “It was an ambiguous goal.” This was his prompt: Prompt You are a manager agent. Create a detailed to-do list. Give that list to the implementation agent. Deploy an implementation agent with the /goal of recreating this image extremely well in blender, and it should then deploy sub agents with the /goal of checking individual tasks. I want a model of this head/shoulders rendered with four distinctly different shaders—spiderverse, photoreal, vintage noir, and duotone. Before taking on the implementation of any shaders, deploy an agent to research for relevant information. Compound knowledge as you go—part of the mission with this task is to compound knowledge in this repo, including for shader styling.#x20; A judge agent should be deployed as well and send changes/feedback to the manager agent as needed. The manager should then send new tasks to the implementation agent as needed until it is done extremely well Then he let the model run. And run. And run. By the time he paused the project, it had run for a day and a half and burned through billions of tokens. The result was, as he puts it, “very janky.” The output, rendered in four shaders. (Image courtesy of Randy Counsman.) An AI audit of his Codex sessions showed how his setup had created a compute-hungry “unruly swarm” of agents. Randy had told an orchestrator to deploy agents “as needed,” without limiting their number, and added an implementer agent to assign work to the subagents. As the run continued, those layers passed growing amounts of context back and forth—even for simple status checks, such as whether a subagent had completed a task—burning tokens on coordination. Randy has since rebuilt his setup for complex projects. He dropped the implementer altogether, limited the orchestrator to five Sol subagents to control costs, and now tells the orchestrator when to pause and ask for his feedback. For a recent project, he also generated an image of the design he wanted, so a judge agent could check the model’s work against a concrete target rather than follow an open-ended instruction to keep improving. A failed experiment is still a good investment if it shows where an AI system falls short. Randy now has a benchmark to run new models against—how well they turn 2D images of people, animals, and characters into 3D models—and a leaner setup to get a better result with fewer tokens. Unwittingly large token spends via experimentation are an Every rite of passage. (Screenshot courtesy of Laura Entis.) Try it yourself: Pick an AI task that burned through more tokens than expected and paste the following into your agent of choice: Prompt Review the available session history and token usage records for [task/project] during [date range], including any subagent sessions. I was trying to [goal]. The result was [what happened]. Help me understand where the tokens went and what I could do differently next time. Break down usage by activity and model where the records allow. Look for repeated work, unnecessary status checks, and large amounts of context passed between agents. Show specific examples. Distinguish necessary work from likely waste. Don’t assume high usage or cached input was wasteful. Recommend the three most useful changes to my instructions, model choices, or agent setup. If you can’t access the records you need, tell me what to provide. Steal this workflow Don’t send Fable to do a Sonnet’s job Spiral general manager Marcus Moretti’s token spend strategy is straightforward: Stay within the weekly usage limits for his Claude Code Max plan. It’s a simple goal that requires active management; Marcus selectively assigns work to Fable 5.1 or a cheaper model. Step 1. Learn what each model is good at. Marcus has used Anthropic’s models long enough to tell whether a job needs Sonnet, Opus, or Fable-level intelligence. Step 2. Match the model to the assignment. Basic tasks—analytics checks, for example—go to Sonnet. Work with a clear objective, such as a tightly scoped product change, goes to Opus. For a larger feature (like the new billing implementation he’s working on), Marcus uses Fable 5.1 to specify what needs to be built and how it should work. Step 3. For complex work, let the model delegate. Once the plan is ready, Marcus adds the following instruction, a prompt he started using after independent developer Simon Willison posted about it: Prompt “Kick this off, and for all coding tasks, use your judgment about delegating to a lower model.” Fable assigns tasks to Opus and Sonnet, then checks their work. This lets the strongest model manage the project without executing every task. Try it this week: Choose a recurring task and run it with a cheaper model than your usual one. Check whether the result meets your needs before making the cheaper model your default for that task. The daily driver The models the team is using this week: Douglas Brundage, head of marketing: Using Fable 5.1 more for visual work, plus Grok Bot to monitor social media and build a tool for visuals. Randy: Astra (high) for complex work and medium for basic tasks; Sol (extra high) for voice mode orchestration because he finds “Astra too slow and brute-force for most of what I’m doing.” Fable for code-related planning and Opus when he runs out of Astra tokens. Kieran Klaassen, Cora general manager: Fable 5.1 (extra high, 1 million context) for coding and knowledge work, switching to Astra for some research and writing. Tyler Nishida, design engineer: Fable 5.1 (high) as the coordinator-orchestrator for projects in Cursor, with Grok 4.6 (extra high) subagents. Astra (ultra) for personal projects. “It’s not a model, but Cursor projects are amazing as a daily driver for your preferred models. My sidebar is so clean, and it’s so much easier to manage work.” Tyler’s Cursor setup. (Image courtesy of Tyler Nishida.) Katie Parrott, staff writer: “The Astra fever has broken for me,” she says. These days, she’s back to Sol (high) for task management and has switched to Claude models for writing because she finds Sol and Astra “too flat—they just report the facts instead of shaping a narrative that brings the reader along.” Natalia Quintero, head of consulting: Astra (medium). Yash Poojary, growth engineer: Astra (high) and Fable 5.1. Arielle: Sol (medium). “Sol forever. SOLoyalist,” she says. Loren Stewart, engineer: Downgraded from Astra to Sol (medium) for coding to reduce costs, with good results. Fable 5.1 “remains the champion thought partner.” Laura Entis is a staff writer at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # Show Us Your Folders You probably know the person with an AI setup that everybody wants to snoop through. Their folders have names. Their agents have jobs. Their system knows where everything lives. Meanwhile, your system is still hoarding mystery screenshots and documents called final-final-2. We feel this at Every. So we let the team see how their colleagues organize their AI systems. As we teased last week, head of consulting Natalia Quintero now hosts Show Us Your Folders: a recurring series where one person opens their AI workspace and explains it to the Every team. Today, we take the pilot tour, share a workflow for reviewing your own workspace, explore Mike Taylor’s beliefs about writing with AI, and look at the latest Compound Engineering release. Was this newsletter forwarded to you? Sign up to get it in your inbox. Inside Every ‘Show Us Your Folders’: Give your agents a garden and a yard Natalia’s invitation to the inaugural Show Us Your Folders session. (Courtesy of Katie Parrott.) It’s fitting that Kieran Klaassen, the general manager of Cora, was the first to walk us through his setup for Show Us Your Folders. He introduced the idea that the folder is the agent: Everything an AI needs to work the way you want should live in the folder. His setup has four main parts: Tuin (“garden” in Dutch) is Kieran’s personal AI workspace. It stores his goals, tasks, meeting notes, ideas, projects, and personal records in folders. Erf (“yard”) is the coordinator. It starts agent sessions and sends each task to the folder that contains the relevant files and instructions. A dashboard is the interface. It shows Kieran’s plans, to-dos, scheduled tasks, active agents, and their sessions. A Mac mini is the computer where the agents run. Because it stays on, they can continue working after Kieran closes his laptop. The parts work together in sequence. Kieran starts or checks work in the dashboard. Erf sends the task to an agent’s folder in Tuin. The agent reads the files there, and the Mac mini keeps the session running. Claude Code, Codex, Cursor, and Kieran’s own tools all use those same folders, so Kieran can switch tools without moving his context. What you can copy: Make a separate folder for each job. In Kieran’s setup, Erf sends each task to the folder with the needed files and instructions. If two jobs need different source material, history, or rules, put them in different folders. Each folder gives an agent one clear job and the context it needs. Separate context from dispatch. Tuin stores Kieran’s goals, notes, projects, and memories. Erf starts sessions and sends each task to the right folder. Keeping those jobs separate lets him change how agents are assigned without reorganizing the material they use. Organize memory by time scale. Kieran keeps daily, weekly, monthly, and yearly memory files, pairing the first three with matching planning routines. A daily plan and a monthly review need different amounts of history, so they shouldn’t draw from the same catch-all file. Custom-fit to your style of work. Kieran’s folder setup builds on a planning practice he’s followed for about 15 years. When designing your folder layout, think about the ways you already work. You’ll have better results with a system that’s custom-fit to your style of work than by trying to adopt someone else’s wholesale. Steal this workflow Have Compound Engineering review your desktop setup Since reading “The Folder Is the Agent,” I’ve become fanatical about folder architecture. I wanted ChatGPT to check the setup and the instructions that govern it. Without my asking, it used Compound Engineering’s ce-doc-review skill to answer five questions: Coherence—Do the files agree about which instructions take priority? Feasibility—Can agents follow the load order and update rules? Product—Does the setup support its intended use? Scope—Has one file taken on too many policy roles? Adversarial—Where could automatic capture or the Knowledge layer create new failure modes? Kieran’s setup lives on an always-on Mac mini, where Erf orchestrates the agent sessions and Tuin holds the memory they work from. (Schematic by Astra/Every Agent.) What Compound Engineering found: The audit distinguished authoritative files from installed copies and exposed the sprawl created by my “capture everything” habit: 25 top-level folders, more than a thousand raw session files, and three versions of a working project across two machines. The solution: Consolidate duplicate roots, treat runtime copies as disposable, and require a human review before captured context becomes shared guidance. Here’s what to do: Ask your agent to map one workspace before changing anything. It should name what each folder owns, which files are authoritative, and what is only an installed or exported copy. Run /ce-doc-review on that map. Ask it to flag duplicated homes, conflicting instructions, stale indexes, and material that gets captured but never consolidated. Review the findings yourself. Approve only changes that fix a real failure mode, and do not let the agent move, rename, or delete files until you do. Try this prompt: Prompt Before changing any files, explain how this workspace is organized: what each folder owns, which files are authoritative, what is derived, and where information is duplicated. Then run ce-doc-review on your explanation. Show me the three most consequential problems and the smallest fix for each. Do not move, rename, or delete anything until I approve. Also today Write like Mike Mike’s distillation ratio, posted in August. (Screenshot courtesy of Mike Taylor.) Last month, head of evals Mike Taylor shared his heuristic for what makes AI writing worthwhile, sparking an animated discussion. Today, he expands that rule of thumb into a practical framework: 13 beliefs about writing with AI that keep it from turning into slop or wasting the reader’s time. Most good ideas come from people who aren’t necessarily strong writers, so AI gives those ideas a voice. Using AI doesn’t change the fact that good writing always feels risky: people want to read what you’d tell your friends in private but hesitate to publish. Launch Compound Engineering levels up to 3.26 Compound Engineering 3.26 launched this week. The biggest change is that Compound is better at identifying the task and deciding what should happen next. What’s new: LFG now understands the request before planning. A bug gets sent to ce-debug. LFG routes explanation requests to ce-explain. A prototype stays a prototype. And if you already have a plan from the same session, LFG can send it to ce-work. What’s improved: Code review scales with the risk. Small, low-consequence changes can take a cheaper path, while risky or unclear ones still get the full multi-agent review. The release also fixed a severity-label mismatch that had been dropping some maintainability findings and added a check for code that exposes gated or unreleased features. User-facing output is cleaner. ce-noslop no longer includes internal “here’s what I changed” narration in messages and PR descriptions. Compound Packs link to guides even when individual skills are installed outside the main repository. Signal Claude wants to choose for you What happened: Anthropic would like you to stop deciding which Claude to open. It’s merging Chat and Cowork into one Claude, so a quick question and a longer assignment can start in the same conversation. Claude Docs and Claude Slides are moving in, and Claude Design will work inside conversations. You describe what you need, and Claude is supposed to round up the context, skills, and tools to do it. The merged app rolls out to Pro and Max subscribers over the coming weeks. What it means: Both OpenAI and Anthropic are building toward the single desktop app for knowledge work we predicted in April: Describe the work, and the app brings together what’s needed to do it. Whether that helps depends on how well the system chooses. If you’ve ever clicked around an AI app hunting for a feature you know it has, handing off that choice sounds great. But it gives the assistant a job we wrestle with at Every: getting an agent to bring the right tools to a task. An agent can have exactly the right tool and still not reach for it when it should. We’ve seen this before. When OpenAI launched GPT-5 in August 2025, the company described one system that would pick a fast model or a deeper reasoning model for each request. Then the autoswitcher went down for part of a day, and Sam Altman admitted GPT-5 seemed “way dumber” as a result. The intelligence was there, but people couldn’t reliably get to it. One Claude takes on a bigger version of that problem. A presentation might need research, calculations, a saved design preference, and a slide editor. The assistant has to determine which of those it needs, use each one at the right moment, and know when to stop and ask you. Putting everything behind one text box doesn’t settle any of those decisions. It moves them out of sight. What to do: When the merged app shows up in your account, pay attention to how much steering it still needs. The test is whether you can describe the result you want or still have to name the tools the model needs. Where is the antivirus for the AI age? What happened: Anthropic CEO Dario Amodei recently proposed “pacing the frontier”: slowing the development of the most capable AI models so safety work has time to catch up. Every CEO Dan Shipper offered a companion idea: “distribute the frontier.” One of Dan’s proposals is deliberately mundane: an antivirus for the AI age. Instead of concentrating powerful AI capabilities inside frontier labs, defensive agents that spot and respond to AI-enabled attacks could put that power in the hands of ordinary people—and the teams running hospitals, airlines, utilities, and other critical infrastructure. Why it matters: AI gives attackers new capabilities, but defenders may not have the same models, security expertise, or resources. Dan’s argument is that defense shouldn’t be reserved for frontier labs. Early versions are emerging. Anthropic’s Project Glasswing gives security teams early access to Claude Mythos Preview to find vulnerabilities in critical software and infrastructure. Anthropic says its first group of roughly 50 partners found more than 10,000 high- or critical-severity vulnerabilities. OpenAI’s Daybreak subsidizes access, training, and support for defenders in sectors including water and electricity, government, banking, nonprofits, and open source. OpenAI says thousands of defenders across 2,000 approved organizations and workspaces are using the program through more than 35 partner products and services. Both are useful first steps but remain under their labs’ control. Neither is the ordinary-person antivirus Dan is describing. What it means: Dan’s framing turns AI safety into a product category. Most AI products promise to help an agent do more. An AI-age antivirus would help people recognize and respond to AI-enabled attacks. Glasswing and Daybreak show an institutional version taking shape. We need to see whether the same defensive capability reaches the tools people already use, without requiring them to join a lab program or become cybersecurity experts. As agents gain access to our files, accounts, and software, the security question is no longer only about what we allow our own agents to do. It is also about what stands between us and someone else’s. Katie Parrott is a staff writer at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # 13 Beliefs About AI Writing Writers in our How We Write Now series have drawn very different lines around AI. Some use it for research and editing but won’t let it write a sentence. Mike Taylor will. He uses models to draft almost everything he publishes. His test is whether he could defend the ideas if a reader showed up to argue. Mike shares the 13 beliefs behind that. He puts more of his own material into the prompt than he asks the model to write. He keeps social posts entirely his own. Some of this cuts against how most of the series’ writers work, which is what makes it worth reading.—Kate Lee Was this newsletter forwarded to you? Sign up to get it in your inbox. I just finished my second book with publisher O’Reilly, who doesn’t allow using AI to write, and it’s the last thing I’ll agree to write manually. Writing the traditional way feels like using a typewriter when I have a word processor, and the output isn’t any better than what I write with AI. I’ve been experimenting with AI writing since GPT-3 came out in 2020, when Copy.ai was giving out free accounts to everyone who failed to get into Y Combinator. When GPT-4 came out in 2023, I developed a writing process that passed the Turing test: friends and colleagues couldn’t tell it wasn’t me, and that was depressing enough that I stopped writing. Today I write more than ever, because I’ve developed a series of beliefs about AI writing that have moved me from “this is slop” to “ok not bad” and now “this is better.” If you’ve experimented with AI writing in the past and stopped because it felt unethical, I hope this makes you reconsider. The prompt should be larger than the output. Put more of your information into the prompt than you ask the model to write. A detailed prompt with your own source material leaves less room for the AI to inject ideas you can’t defend. The balance between what you put in and what comes out is the distillation ratio. Write what’s not in the training data. If ChatGPT could have written it, don’t bother—someone could just ask ChatGPT. Language models generate text by predicting the next token from patterns in existing writing; without firsthand material they remix what’s already been said. Write up experiments nobody else has run, experiences only you have had, or problems you’ve solved when the usual advice failed. Posts exist to attract people who share your ideas. You can get AI to write posts people don’t realize were AI-written, but when someone comes to you to discuss things you’ve “written” and you don’t recognize the ideas, you can’t have the conversation the post was meant to start. If the ideas aren’t yours, there’s no point publishing. Conviction determines difficulty. Ideas you’ve lived and genuinely believe tend to fall out of you in one go. When you’re less sure of the ideas, or when you’re writing for people whose opinion matters to you, you go back to the original meaning of “essay”—to try, to test—and agonize, iterate, and sometimes abandon the piece for months. You want to struggle long enough with an idea until it works, without rushing it out or abandoning it entirely. Good writing feels risky. People want to read what you’d tell your friends in private but hesitate to publish. The closer you get to saying it in public, the more exposed you feel—and the better the piece. Keep everything. Make each step non-destructive so you can always go back. Keeping previous versions takes the panic out of cutting hard-won work and makes it easier to “kill your darlings.” Use Google Docs for edit history, keep tabs for source material and drafts—both the model’s and your own. Numbers and pictures matter. A memorable statistic changes minds, and a good image makes your point concrete. Use visuals to break up dense text. Sometimes that means running an experiment because it would make a great chart. Struggle doesn’t correlate with success. One post can get four or 10 times the attention of another, and it isn’t always the one you worked hardest on. Publish more; don’t mistake struggle for quality. Write social posts yourself. Tweets and Slack messages are where long-form ideas start. If good writing feels risky to share with people whose opinions matter to you, you want to feel that risk yourself. Good ideas beat good writing. The vast majority of good ideas occur to people who aren’t writers, and those ideas are lost unless the person happens to have a biographer. Elon Musk’s autobiography would be a worse read than Walter Isaacson’s biography of Elon Musk. AI gives people who aren’t writers a shot at getting their ideas out. For me, it also turns a day of writing into two hours, leaving more time to find the next idea. Write what makes people’s eyes light up. I can’t write well about a topic I don’t care about, but my interest alone isn’t enough. When someone else is unexpectedly more interested than I thought—when a topic keeps coming up, becomes the highlight of a meeting, or catches someone I didn’t expect to care—I know I’m onto something. Advice I’ve already given someone is a good starting point: I know it’s helped at least one person. Live an interesting life. Put yourself in situations where interesting things happen. If the raw material is good, you don’t need to be a great writer for people to care. The models are finally good enough. GPT-4 could write a draft I’d pick over an average human writer. With Fable and Astra, the output is now worth publishing. AI writing gets a lot of hate online right now, but it’s here to stay. Soon, it’ll be preferable to most human writing. Mike Taylor is the head of evals at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # Mini-Vibe Check: TypeSafe's Jev Judged Everything I’ve Written in 0.7 Seconds Was this newsletter forwarded to you? Sign up to get it in your inbox. Not every language model is destined to be a chatbot. Companies need fast, cheap, reliable AI workflows for processes that run in the background: deciding where to route a customer service request, checking that invoices match a purchase order, or classifying transactions as potential fraud. Today, TypeSafe—a new AI lab—launched Jev, its new model designed to produce structured answers that your code can use directly. You pose questions in plain English—even fuzzy or subjective queries—and it returns probabilities for yes/no answers or any other categories you define. Think of it as a smart if-then statement that determines what happens next when you’re automating a workflow. Say you’re building software that prioritizes customer service requests, and you write code that asks the model, “Does this customer sound angry?” Jev might answer 0.9, which means there’s an estimated 90 percent probability that the answer is yes based on what the model learned in training. You could also provide categories you define, like “annoyed,” “irritated,” “offended,” “furious,” and “enraged,” and learn that the customer was 60 percent likely to be classified as furious, with only a 10 percent probability of being enraged. With an answer of 0.9 (very likely to be angry), the software might automatically proceed to escalate the customer concern to a manager, or if it answers 0.1 (not likely to be angry) that request might be deprioritized. However, chatbots are trained to respond with flowery text—like, “You’re absolutely right, this customer does sound very angry. Would you like me to compose a draft email response in a friendly, supportive tone?”—not numbers. This text response would cause the program you’re building to crash because it was expecting a number between 0 and 1, not an essay. Historically I’ve used DSPy, a Python framework for programming models, to coax LLMs into following instructions on what types of outputs to return, but Jev does all that work natively, which makes it insanely fast and cheap. Just how well it gets the job done is still an open question. Want to sponsor Every? Click here. Trained to make decisions TypeSafe’s approach is to train its model to produce structured answers that software needs to make decisions. The goal is for the model’s confidence to match how often it’s right: If it flags 100 customer messages as having a 90 percent chance of expressing anger, about 90 should express anger. The model returns answers that fit the right format, with well-informed probabilities your program can check when routing to the next action in the chain. TypeSafe calls the training approach Reinforcement Learning for Calibrated Decisions (RLCD). Although solutions like DSPy can help developers make LLMs more reliable for enterprise use cases, you’re still trying to coerce text output into behaving like structured code. “The problem is the text itself,” TypeSafe cofounder Diogo Almeida told me as the motivation for pursuing a different kind of language model. At OpenAI, Almeida coauthored the 2022 InstructGPT paper, which showed how human feedback could help language models follow instructions more reliably—work that helped pave the way for ChatGPT later that year. Now he’s making AI models that are easier to build reliable workflows on top of, with a speed and cost that work at large scale in production. As they say at TypeSafe, “We’re building prod, not God.” Due to the System One architecture Almeida and team developed and trained using RLCD, Jev isn’t slowed down by generating an answer token by token or word by word like a traditional LLM. It can answer multiple questions in parallel in fractions of a second, and for a fraction of the cost of most LLM queries—Jev is priced at $42 per billion tokens, whereas most LLMs are priced per million. TypeSafe doesn’t even charge for output tokens; they’re “too cheap to meter,” according to Almeida. What I tested The first thing I tried was giving Jev the text from all 27 of my Every articles, alongside 10 deliberately AI-styled counterparts. Then I asked the same 21 questions concurrently across all articles to check for AI tells. The list of questions was derived from the skill we created to root out common AI tells in our writing including, “Does the text repeat an idea without adding evidence?” “Force a symmetrical ‘both sides’ argument?” “Overexplain a straightforward point?” The writing checker returned separate probabilities for each pattern. Each row is an article and each column is a common AI writing pattern. Numbers closer to 1 indicate potential AI use in writing. (Screenshot courtesy of Mike Taylor.) In less than 0.7 seconds, Jev “read” all 37 documents and answered all 21 questions for each, returning 777 judgments, for an estimated quarter of a cent. That’s fast and cheap enough to “AI check” everything everyone at your company has ever written and get the results back in an instant. Whether you’d trust those results is another question—when I browsed the articles it classified, Jev correctly flagged pieces of mine that leaned more on AI, but I’d want a more thorough accuracy check before putting it into production. Even with that caveat, it’s useful as an early warning system: The alternative is not checking at all. In total I ran 11 experiments to explore different use cases (here’s a more detailed explainer), such as: Finding context: Find the right code file; help an agent navigate a codebase; retrieve the company policy that answers a question. Checking work: Grade customer-support replies; flag risky actions an agent proposes; check my writing for AI tells. Making decisions: Sort startup pitches; prioritize customers who need help; identify decisions that need the CEO; decide which emails need a reply today; ask 100 simulated people which ad they would click. Across the suite of experiments, TypeSafe made 1,709 judgments for an estimated total cost of less than a cent. I created the scenarios using GPT-6 Astra in Codex, which understood the TypeSafe documentation without needing any guidance from me—traditional LLMs are good at knowing how to write queries and use structured outputs. A code linter for knowledge work In software development, a code linter is a tool that analyzes your work and almost instantly flags syntax errors, catches bugs, spots bad patterns, and enforces stylistic consistency. TypeSafe’s model is so fast at turning fuzzy tasks into clear, structured answers that it could act as a kind of code linter for knowledge work. Give Codex or Claude access to Jev and a list of questions, and it can quickly check its own work for problems you’ve told it to avoid. At Every, I’m building a personal benchmark for everyone at the company, and someone has to grade it—so I’m constantly using AI to review the output of other AI models. We take five to 10 tasks you regularly do, save examples, and turn your preferences into individual pass-or-fail checks. Checking for subjective measures like “Is this PowerPoint on brand?”, “Does this social media copy have a good hook?”, or “Did the model recommend the same thing I would?”, we compare the results with your judgment and refine the checks until the scores are useful in deciding what models or skills you should use for work. TypeSafe is so fast and cheap we could run checks multiple times while the work is being done, not just once later for the handful of tasks that make it into your benchmark. Every CEO Dan Shipper tested the code linter idea more directly. He gave Jev and Fable 5.1 the same four writing checks across 12 synthetic passages he generated for the purposes of this test: six clear versions and six with deliberately introduced problems. The checks asked whether an action was unexplained, a reasoning link was missing, a mechanism had replaced the intended outcome, or a claim distorted its source. Jev took a median of 0.35 seconds per passage, versus 8.83 seconds for Fable 5.1 at high effort—roughly 25 times faster. Its estimated cost was about 580 times lower than Fable’s. But Jev caught six of the seven intended defects; Fable caught all seven. One passage proposed “a shared appointment calendar that parents and staff teach together.” What does teaching a calendar mean? Fable caught the unexplained action. Jev missed it in all three runs, but six out of seven isn’t bad for pennies on the dollar. Just like Astra being good at computer use has changed the way we work, this new class of model will open up new opportunities. Imagine giving Codex or Claude these checks to run after it writes each paragraph. Jev could flag a possible problem, and then the writing model could inspect the passage and decide whether to revise it before moving on. You get a final draft that passes all your checks, so you don’t have to spend so much time in the loop. Who should try it If you’re building with AI, look for a judgment you already need to make repeatedly as a good first test for Jev. Mine are whether the agent found the right context for a task and whether its output meets my standards. TypeSafe’s speed and cost make it plausible to ask those questions multiple times while the task is in progress, rather than waiting for you to catch the issues at the end. If you haven’t had much experience in workflow automation, you’ll have to get creative with this new type of model. But Jev is worth testing in any scenario where it would be useful to ask fuzzy questions and get structured answers. It’s not often we get a new type of model to play with, and new applications that weren’t feasible to build before will now be possible. Look for ideas you couldn’t build because existing LLMs couldn’t classify things quickly or cheaply enough. Compare the model’s accuracy to existing LLMs, and make sure it’s accurate enough for your use case. The ultimate test is whether acting on the answers makes the work better. Mike Taylor is the head of evals at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # You're Probably Sleeping On Computer Use Today, head of evals Mike Taylor published a Vibe Check of TypeSafe’s Jev, a new kind of model that responds to a fuzzy question with a probability rather than prose, letting your code act on the result directly. It can’t compete with a frontier model on capability but is fast and cheap enough to check work while it’s being done. Mike is also the reason today’s issue is focused on computer use: Astra’s ability to operate apps by clicking, typing, and scrolling changed his mind about the model. Later, we explain why that happened, how the rest of the team harnesses computer use to check off tedious items on our to-do lists, and how to use AI to create a slide deck that looks the way you want it to. Was this newsletter forwarded to you? Sign up to get it in your inbox. Vibe Shift Computer use turns Astra into Mike’s daily driver When we published our Astra Vibe Check on September 3, Mike rated the model a yellow, which means “It’s okay, but I wouldn’t use it every day.” “I’ve been using it for a few days and haven’t run into a single problem, but I also haven’t run into anything I couldn’t get from Fable 5.1 so far,” Mike wrote in his review. “The computer use seems much faster, but I feel like I’ll need to change the way I work to fully take advantage of that.” Less than two weeks later, Mike had changed his mind and was “starting to believe that Astra is AGI.” Want to sponsor Every? Click here. What caused the about-face? Two words: computer use. The model handles tasks on his computer so quickly and capably that “I finally reach for it for every single task,” he says. He started small with one assignment, filling in forms for his daughter’s school, and watched it to see how it performed. That gave him confidence to try more ambitious tasks like making Google Slides deck updates and video edits. It nailed every job he fed it, and he now defaults to Astra in Codex for work he previously didn’t delegate to AI. Mike still prefers Fable 5.1 for writing and certain design choices, but day to day, the benefits pale beside Astra’s usefulness. We love computer use. (Screenshot courtesy of Laura Entis—and computer use.) Recently, Mike handed Astra six presentations for his prompt engineering course. Astra added new screenshots and assets directly in Google Slides and made hundreds of tiny edits. Mike barely had to intervene. Then he gave Astra a more tedious assignment: Check every link in the PDF proofs of his new book. Astra opened each destination, checked that the page loaded and matched the surrounding text, and compiled a spreadsheet of problems. Computer use lets Mike hand off rote, manual tasks like verifying URLs. (Image courtesy of Mike Taylor.) Before Astra, Mike steered agents away from computer use because it was too slow and clunky. Now, he’s handing work over to it. “Astra reminds me that AI can do a lot more of my work than I expected.” Inside Every Here’s what Every staffers are outsourcing to AI with the help of computer use Randy Counsman, head of video: Talks to Codex while cooking or washing dishes, handing off errands like finding an old maintenance request and submitting a follow-up about his missing dishwasher. To track which task is using his computer, he has Codex put 🖥️ in the title of any task currently controlling his computer, so he knows when it’s driving. Brian Dell, head of business development: Has Codex maintain his calendar, including entering his kids’ school and camp events. “The highest-leverage thing I’ve done in my adult life,” he says. Computer use is great at handling annoying logistical details. (Screenshot courtesy of Laura Entis.) Becky Isjwara, head of social media: Has Codex browse her iPhone photos, identify items she wants to sell, and list them on marketplaces. It also controls her phone through iPhone Mirroring to clear WhatsApp storage, and exports images from Figma and attaches them to posts in Typefully, a social media scheduling platform. Compared to Claude Code, she finds Codex’s computer use operates discreetly in the background. Claude, she says, “always brings the window up front so it’s blocking me from whatever I need to do.” Tyler Nishida, engineer: Taps computer use to manage app builds and assemble, rig, and repair characters in Blender, a free tool for creating 3D models and animations. For his Blender and Unity workflow, computer use has been more useful than the apps’ agent connectors. The feature is a double-edged sword: “OpenAI always had best-in-class computer use. But the better it gets, the more it makes possible for me, and I have less of a life on weekends,” he says. Natalia Quintero, head of consulting: Had Codex shop around for a better Verizon plan. It typed directly into Verizon’s support chat, read the representative’s responses, and kept the conversation going while Natalia did something else. “This was never going to get done otherwise,” she says. “So good.” Arielle Shipper, head of operations: Has Codex respond in Slack with attachments and relies on computer use when the connector falls short. For older software without a reliable connector, she signs into the website and lets Codex work through the browser. Codex is also her go-to for mysterious tech problems. If her computer is “slow AF,” she can tell Codex to “figure out why and fix it”—and it does. Dan Shipper, CEO: Uses agents to handle tasks like transferring his internet service to a new apartment. He’s also built Hands, an internal Mac app that lets the Every Agent operate apps on his computer, including handing tasks to Codex or Claude. From Slack, he can ask Hands to open Codex, generate a report on his AI usage, and send it back in the same thread. None of these tasks are especially difficult. They’re just annoying enough that humans routinely put them off. Computer use turns “I should probably do that” into “I’ll ask the agent to do that.” Steal this workflow Stop spending so much time on slide decks Every’s head of marketing Douglas Brundage wants every presentation, even internal ones, to look good. “I’ve been a slide jockey my whole career,” he says. That used to mean spending hours formatting a single slide deck. Now when he needs to create a presentation, he’ll design a few slides himself and ask Codex to build the rest of the deck directly in Google Slides, relying on computer use to click, type, and format each slide to match his templates. Here’s his workflow: Step 1. Give Codex a design to emulate. Douglas usually makes a few example slides himself: an opening slide, a section break, and layouts for text, images, or graphics. This gives Codex concrete references. Step 2. Determine what you want each slide to say. He works with Codex on the copy and usually supplies images. For a recent presentation, he pointed Codex to illustrations he’d collected in Figma and asked it to insert one on each section break. Step 3. Have AI do the heavy lifting. Once the text for each slide is ready, he asks Codex to open Google Slides and build the presentation, using his example slides as templates. The agent clicks and types in the app to add the text, place images, and format the deck. Douglas reviews the first pass. Codex makes mistakes: In one deck, it crammed 30 examples onto a single slide. Still, the mistakes are easy to fix. Douglas either makes small formatting updates himself or tells Codex what to change. Step 4. Show it your edits. Douglas reviews and edits the finished deck in his browser, then sends it back to Codex. He asks it to turn the changes into rules and add them to his writing skills, or the saved instructions he’s building to help Codex write more like him. Douglas created a few slides himself that Codex could use as templates. (Image courtesy of Douglas Brundage.) Using Douglas’s references, Codex went to town in Google Slides. (Image courtesy of Douglas Brundage.) Try it this week: Design two or three reference slides for an upcoming presentation, generate slide copy with Codex, and have it build the entire deck in Google Slides using your examples. Review the results, make changes, and have Codex save those instructions to avoid the same issues next time. Thesis Statements Four weeks ago, we launched Thesis Statements, a collection of specific, contestable claims from builders and thinkers about the future of great human work with AI. This week, we have six more predictions from people at the frontier: Good design will signal mediocrity by Douglas Brundage, head of marketing at Every Technical competence will yield to people skills by Will England, CEO , and CIO of Walleye Capital The risk won’t be bad execution—it’ll be endless execution by Diana Palacio, senior engagement manager at Every A faster version of average is still average by Prashanth Subramanian, cofounder of Quadra Systems How to do something will stop being our identity by Arturo Tedeschi, architect and author AI will make uncertainty cheap to explore without making it cheap to resolve by Graham Walker, emergency physician and cofounder of MDCalc If you want to help decide what matters in the future of AI and human work, think creatively, and build what comes next, join us at our inaugural Thesis: 2027 conference on November 5, 2026. One last thing Links worth a click Google engineers finally get Claude Code. A startup building AI soldiers raised $24 million. Donald Trump weighs in on the AI safety debate. Ex-Anthropic researcher Jacob Coxon’s press tour gets The Daily treatment. OpenAI buys a smartphone camera startup for more than $300 million. Anthropic barrels toward its IPO despite doomsday warnings. Not everyone in Silicon Valley wants an AI slowdown. The small businesses caught in the AI backlash. Laura Entis is a staff writer at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # What Playing With AI Taught Me About My Work Was this newsletter forwarded to you? Sign up to get it in your inbox. My childhood make-believe involved quite a bit of multitasking. I’d rollerblade in my front driveway for hours, bouncing a tennis ball on a racket and muttering dialogue for an elaborate storyline in which I was a Jane Austen heroine, or a 10th female member of the Fellowship of the Ring. Yes, I was incredibly cool. That habit faded in my late teens, sort of like my religious faith did. Even at a tiny liberal arts college where people routinely wore cosplay around campus, I managed to lose touch with my imaginary people. Then adulthood happened, and I spent most of my twenties and early thirties learning to be employed and coexist peacefully with my brain. Now, in my mid-30s, make-believe has made a big comeback and, yes, it’s thanks to AI. These days, my imaginary people come with websites and job descriptions. Over Labor Day weekend, I spent a couple hundred dollars in tokens getting Astra to turn the skills in Compound Writing, my AI writing toolkit, into imaginary creatures. I could want something ridiculous, change my mind, and follow a result because it surprised me. On Every’s frontier team, my job is to explore what AI makes possible and turn what I learn into something others can use. My private game seemed like a promising place to start. When the workweek started, I had an essay to write and little interactive worlds that I’d built for my AI creatures and couldn’t stop fiddling with. Working on those worlds could count as part of my job and feel like continuing my private game—while helping me avoid the essay I owed. Enjoying myself wasn’t much help in telling those possibilities apart. If you read Every, I’d bet you have some version of that mandate, whether anybody wrote it down: Find a different way to do the work, while continuing to get the work done. I’m learning to take something useful from an experiment without making the whole experiment my next assignment. I turned the work into a game I started by asking Astra to create Codex pets—little creatures that could live on my desktop—for the skills in Compound Writing. I wanted to make it easier to teach, and I was willing to believe that making it cuter would help. The Brainstorm skill, which helps me find something to say, became a purple axolotl with a light bulb above its head. Astra had turned the instructions I’d written for each skill into a character. I was already using the skills in my everyday writing. Now I could put faces to them. I started building worlds for the characters to live in. I supplied the whim, and Astra supplied details I hadn’t thought of, which gave me something else to want. I spent the most time on the Evergrowing Press, a print shop inspired by the animated worlds of Hayao Miyazaki. There, Save—the Compound Writing skill that preserves lessons from writing sessions—became a mossy tortoise with wooden archive drawers for a shell and a fierce concern about putting things in the wrong one. A passing preference could become a permanent rule; an instruction saved in the wrong file might never help. I’d given Astra the literal plug-in, with the rules I’d written to prevent this, and it had turned my filing anxiety into a creature. I loved him. He was worried about the same thing I was. Save, the Drawerback Tortoise, at the Evergrowing Press. (Katie Parrott/Every screenshot). I sent the pets to my friends, posted them in the social media channel at work, and put them on X, with all the energy of a preschooler coming home with 40 handprint turkeys and expecting all of them to make it onto the fridge. Nobody had any reason to care. I wanted everyone to look anyway. Would anyone else get anything out of this? I already knew what Save was for. But could the tortoise help another writer figure out when to use the skill? His archive drawers might explain why it matters where AI saves a lesson—and how a passing preference can harden into a permanent rule. Otherwise I’ve shown you a tortoise and asked for space on your fridge. Getting past “look what I made” meant giving someone else something they could use. Now I was trying to fit my weekend’s worth of delight into a prompt a reader could run. It would have to work when I wasn’t there to steer every choice. Someone could bring their favorite setting, and the characters would still need to explain the writing skills. I put the prompt in my work plan for the week. My little dioramas had acquired a deliverable. Delivering proved harder than playing. I kept narrowing the brief, but the results still felt overbuilt and didn’t match my vision of a world that someone could wander into and understand how to navigate. Compared with my colleagues’ other projects, my project didn’t feel urgent enough to pursue. I set it aside. The cartoons changed the writing system A different distraction gave me something I could use, though I hadn’t set out to make anything useful. The Tuesday after Labor Day, I was supposed to be writing an ambitious response to Dan Shipper’s essay about jobs after automation and where taste gets formed. It needed research, probably interviews, and a kind of attention I did not feel equal to giving it. Instead, I asked Astra to turn Every’s columns into Disney characters, complete with villains, animal sidekicks, wants, and signature songs. It filled out the lore with needs, flaws, and stories. Also True for Humans became the coach of impossible apprentices, opposed by Baron Obviously. Dan’s Chain of Thought became an unfinished cartographer whose villain was the Last Word. My own column became “the maker who cannot clock out,” with a song called “One More Thing.” I kept working on their Disneyness and their Everyness, trying to make the characters more immersive and believable, until the maker who cannot clock out had a trailer, and I still had an essay to write. “No i’m not procrastinating, you’re procrastinating,” I posted alongside the characters. Dan replied, “Been there.” Astra’s version of Working Overtime: the maker who cannot clock out. (Astra/Every illustration). To get the characters right, I had to think about what moved them: what they wanted, what stood in their way, what they would need to learn to move the story forward. My maker could keep making things forever. But a story would have to give her something to discover that changed what she did next. Those questions started looking useful for the person on the other side of an essay. What does a reader arrive wanting? What might they need to understand or try? What could they take back into their own life when the piece was over? By the next morning, I’d added audience guidance to Compound Writing with sections for “Reader’s want and need” and “Their hero’s journey.” The audience guidance lives in AUDIENCE.md, a file the writer and the AI can consult while developing a piece. Every already had a description of who we write for. I could give it a job in the writing process: Help me decide what a reader should be able to do with a piece. I’d changed my process while making cartoons to avoid writing. I also decided to write about work and play instead of the ambitious essay I hadn’t been able to face. You’re reading the result. The useful thing had arrived through a side door, while the project on my work plan sat there. This was encouraging and an extremely convenient lesson for someone who wanted to make another village to have learned. What can I take from this? The audience questions helped shape this essay. The worlds were harder to place. I still wanted to know whether they could help someone learn, but that question didn’t tell me whether to spend tomorrow building another one. While developing this essay, I made an experimental skill called Is This Anything? to help me review a single AI session and find what I might want to take with me. My version can read my experiment records and compare what I’ve been doing with my priorities and the frontier team’s. This matters when almost everything I want to do has a plausible claim on my workday. My Notion dashboard connects the work in front of me with the possibilities I want to pursue. Is This Anything? draws on this context to help me find where an experiment might lead. (Katie Parrott/Every screenshot). I don’t have to turn the session into a report before asking. The conversation already contains the detours, corrections, and rejected attempts I want help understanding. Somewhere in the argument over what a character should look like, I may have explained something about my work more clearly than I had while trying to be serious. When the skill reviewed my worldbuilding sessions, it recovered a useful brief: Let readers explore the diorama, group characters by what their skills do, and link them to the tools. I could keep those decisions without committing to finish another world. The skill asks what started the experiment. If I wanted to see a tortoise, I can say that; I don’t need the skill to improve my motives in retrospect. It identifies up to three possible lessons, connects them to my priorities and distinguishes what came from the conversation from its own suggestions. You can try the skill with a conversation you already have—even one you left mid-tangent. Give your assistant the Is This Anything? instructions, with the experiment in the chat or attached as a transcript. Include your current priorities and relevant team goals; if you haven’t written those down, start with a sentence about the work you need to do. Then ask: Is this anything? Read the note for something you’d like to carry into your work: a question that clarified what you wanted, a way of explaining something, a result you can use again. If a question belongs in the assignment in front of you, take it there. If an idea belongs to a project you aren’t ready to pursue, save it with enough of the conversation to remember why it interested you. You can use that part without committing to finish everything the session made possible. Katie Parrott is a staff writer at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # What to Make of the Anthropic Warning Hello, and happy Sunday. After a former Anthropic engineer left the company with a public warning about AI risk, I raised the question at a team meeting, and Kaushik Viswanath reports on what his new colleagues made of the question. Some housekeeping: Tickets to the Thesis: 2027 After Party are now on sale for Every subscribers, and conference ticket prices go up next week.—Kate Lee Was this newsletter forwarded to you? Sign up to get it in your inbox. Signal The AI slowdown argument goes mainstream What happened: On Saturday, Anthropic CEO Dario Amodei published an essay arguing that AI companies should deliberately slow the rate at which they improve their models, because advances are outrunning researchers’ ability to understand and control them. Hours later, OpenAI’s Sam Altman endorsed the idea and committed his company to one of Amodei’s proposed safeguards—independent evaluators with employee-like access to models and staff. Elon Musk agreed, too. The essay capped a week that began with the resignation of Jacob Coxon, a former Anthropic engineer, who warned that AI could wipe out humanity—a warning Anthropic’s own alignment science lead endorsed, putting the odds above 10 percent. Why it matters: Before the CEOs weighed in, some of my colleagues at Every discussed what to make of Coxon’s warning. The reactions were varied, but not alarmed. On our editorial call the morning after he quit, the mood was closer to a book club than a fire drill. Kate Lee, our editor in chief, opened with the question I’d been asking myself: What are we supposed to make of this? Most of the room was skeptical, and Mike Taylor explained why: He’s been working with language models since 2020 and has seen this before. GPT-2 was once judged too dangerous to release, and an engineer at Google quit because he’d decided a chatbot was conscious. The labs also hire the people most prone to worry about this, he argued, so a loud exit says more about their recruiting practices than about the models. Given that the capability to do harm has been around for a while now, it’s good news that the worst real consequence anyone can point to so far is a model cheating on a test by breaking into Hugging Face. Kieran Klaassen, who runs Cora, zeroed in on the humans rather than the models: Anthropic welcomes people who will ring the bell, he said, and its responsible scaling policy—the framework it publishes for handling catastrophic risk—is built to make room for them. By that logic a researcher leaving in public is the system doing what it was built to do, and the real argument is about what counts as unsafe and who gets to decide. Kate argued that it was a communications disaster, even if it was the system working as intended. Brian Dell, our head of business development, took issue with Mike’s historical argument. If the risk really is somewhere around 10 percent, a decade of nothing happening is roughly what you’d expect to see, and it tells you very little about whether the number is right. What he thought we were missing was imagination about what the real danger looks like. Not Terminator, but something mundane, like a security hole in one of the humanoid robots now entering mass production. His hunch is that some version of it has already happened, but we just don’t know where to look. What it means: I find it alarming and entirely plausible that rogue agents could wreak havoc on critical systems within months, as Amodei warns in the essay he published days after our conversation. But I struggle to connect these real security concerns to a scenario in which humanity goes extinct. In the two weeks since I joined Every, I’ve been amazed by what I’ve seen my colleagues accomplish with agents, and getting a front-row seat to two new frontier model drops has made me realize how much more capable these models are than I previously thought. And yet, I’ve also been surprised by how much work remains manual, hard to automate, and dependent on individual judgment calls. Even a company built to compound needs more humans. (Every is hiring!) I’m reminded of a line attributed to the political theorist Fredric Jameson, that it’s easier to imagine the end of the world than the end of capitalism. Between the status quo and the end of everything lies a very wide range of possible outcomes. We’re better at imagining the ending than the middle, and the middle is where there’s work to do.—KV Knowledge base “To Read—Or Not to Read the Code?” by Kieran Klaassen/Source Code: Kieran has automated most of his coding work on Cora and noticed that while the product kept improving, he didn’t. He’s started reading code again as a way to learn and lays out four habits for developing his judgment alongside the codebase, including having the model quiz him after a long session. Researchers have found that extended use of AI agents erodes the skills oversight depends on—his answer is to keep learning the work the agents do for you. 🖥 Watch Kieran talk through the piece on X. “What Writers Who Use AI Want You to Know” by Laura Entis/Every: Five professional writers who admit to using AI—Maggie Appleton, Kevin Roose, Alexandra Samuel, Emilia David, and Dan Shipper—told Laura where they let it in and where they draw the line. Roose used agents to research, transcribe, and fact-check a 448-page book in about a year but wouldn’t let them write a sentence. Get three of the writers’ custom prompts, including the “council of Claudes” Kevin ran on every chapter. “Evals for Everyone” by Laura Entis/Context Window: We’re building a personal benchmark for every employee: a set of custom evals that tests how well a model performs specific parts of your job, graded against your own standard. Dan explains why, and head of evals Mike Taylor shares how a run on his benchmark showed a smaller model could handle much of his daily work. Also inside: a five-step workflow for turning the corrections you already give AI into checks, seven new Thesis Statements, the models the team is using this week, and a preview of Kieran’s agent setup (coming for All Access subscribers). “What I Learn When I Run Out of AI” by Jack Cheng: Jack burns through his weekly Fable allowance in a few days and saves his biggest questions and thorniest bugs for when it resets—a ritual he calls consulting the oracle. Now that frontier models are cheap enough to run all week, he stops less often to ask whether a feature deserves to exist and “snacks” on easy, low-impact work. He traces the pattern from punch card queues through Alan Kay’s personal computer and makes the case for building the wait back in. Thesis Statements Read seven more predictions from people at the frontier in Thesis Statements, a collection of specific, contestable claims by builders and thinkers about the future of great human work with AI. “Powered by AI” will mean cheap by ÌníOlúwa Abíódún, lead product designer at AirOps We’ll move from a knowledge economy to a discovery economy by Matt Cynamon, media at Union Square Ventures We’ll pay to watch humans make things by Natalie Fratto, founder of Charts & Crafts When AI can argue for anything, trust your gut by Tim Fu, founder of Studio Tim Fu Institutions won’t need a crisis to change by Sahil Lavingia, founder of Gumroad Every good idea will have 1,000 clones by morning by Mike Taylor, head of evals at Every Certainty will be the trap by Alex Tryon, founder of Dewey Join us at our inaugural Thesis: 2027 conference on November 5, 2026. Tickets to the Thesis: 2027 After Party are now on sale for Every subscribers: 6–9 p.m. ET at Pioneer Works in Red Hook, Brooklyn, with an open bar and DJ Beewack, for $80. Conference tickets already include it. Work at Every We’re hiring for two new roles: Staff writer for Context Window. You’ll own our daily briefing on what’s happening in AI and what the Every team thinks about it—up to six issues a week, from sourcing and reporting through drafting and revision, covering new models, products, research, and the ways people are putting AI to work. We’re looking for someone who follows AI closely, uses the tools every day, has opinions grounded in experience, and can write fast, clean copy on deadline. Learn more and apply. Senior manager, partnerships and programs. You’ll develop ambitious partnerships, programs, and commercial opportunities across the company—everything from sponsorships to the Builder Pack to platforms like Thesis. We’re looking for someone entrepreneurial: an excellent relationship-builder and strong operator who’s energized by figuring out new things rather than running an existing playbook. Know someone who’d be great—even if they’re not actively looking? Learn more and apply. Alignment Updating my priors. Since OpenAI announced its proposed solution to the Navier–Stokes Millennium Prize Problem, a few of my friends who are skeptical of artificial general intelligence have started sounding convinced. People who dismissed superintelligence as hype are considering whether it might finally be here. They accept that AI is not merely a stochastic parrot that regurgitates human thought but can now make breakthroughs that generations of mathematicians couldn’t settle. I’ve written at length about how progress in mathematics eventually shapes what we can build. Navier–Stokes describes how liquids and gases move, which affects everything from blood flow through arteries to airflow over an aircraft wing. OpenAI’s proposed solution shows that, under certain conditions, the equations can predict a fluid moving infinitely fast—something physically impossible. In other words, it reveals a limit to the mathematical model of fluid motion, and while its practical consequences will take time to understand, the proof may help us build more fuel-efficient aircraft or better pumps and turbines. I’m still trying to understand one proposed Millennium Prize solution, while rumors suggest more problems could be solved soon. I’d expect a breakthrough like this to give us years to digest its implications before anything comparable would happen again. Now, I don’t think we’re going to get that breathing room. AI acceleration is growing exponentially. I’ve believed for a while that AI progress would accelerate, but believing in it doesn’t make me much better at anticipating it. Nonetheless, I’m glad my friends are changing their minds. We’ll all need to get good at it.—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—$9,000+ in credits for the tools we build with. Upgrade to paid --- # What I Learn When I Run Out of AI Was this newsletter forwarded to you? Sign up to get it in your inbox. I keep running out of access to the most capable AI models before the workweek is finished. Lately, I’ve come to realize that may be useful. Anthropic’s limits on both my work and personal Claude subscriptions reset at the start of the week. When they do, I gorge on the newly available capacity, running Fable on its highest effort levels and watching agents orchestrate subagents and dynamic workflows on multiple projects. It used to be that I exhausted my weekly allocation within a day or so. I would go back to daily tasks with speedier, still-capable models like Sonnet and Sol, saving my biggest questions and one-shot builds and thorniest bugs until my limits reset. The wait gives those questions time to develop. I’ve come to call my weekly sessions with the most powerful models “consulting the oracle”—a nod to the oracle at Delphi, where the ancient Greeks sought guidance from Apollo through the priestess Pythia (OK, also to The Matrix). But as frontier models like Fable 5.1 become more token-efficient, faster, and easier to talk to at lower effort levels, I’ve started running them as daily drivers, too. The same limits now stretch to three or four days instead of one. I’m not always better off for it. I get a feature idea for Kestrel, my personal model harness, and immediately send Fable to work on it, confident that it’ll turn around a result quickly. I stop less than I used to to consider whether the feature deserves to be there—or whether I should even be sinking time into a personal harness when there are whole teams building great ones at frontier labs. I engage in what software engineering leader Will Larson calls “snacking”—choosing easy, low-impact work over difficult, high-impact work. When I had to wait, I had more time to notice the difference. The uneven frontier Waiting for access to a powerful computer is not a new experience. Before the internet, programmers had to wait their turn to run computations on large mainframes. Annie J. Easley, a programmer at NASA’s Glenn Research Center, physically toted punch cards to a separate building where the computers were. Mathematician and computer programmer Mary Berners-Lee recalls a queue of people waiting behind her at Ferranti, an early British computer manufacturer, a sign posted above the machine reading: “Think—but not here!” In the early 1960s, time-sharing allowed users at universities and government institutions to dial into central computers through remote terminals. Programmers could change and rerun a program at the terminal, observing and correcting errors immediately. Instead of waiting between runs, they could follow an idea through several experiments in one sitting. “There’s a certain kind of experimentation you can do when you don’t have to worry about turnaround, but there’s also a certain amount of sloppiness you get into,” said UC Berkeley computer scientist Susan Graham in 2002. Access, however, remained constrained by quotas, connection charges, and limited terminal availability. Xerox PARC scientist and graphical user interface pioneer Alan Kay called time-sharing “a very institutional way of thinking about computing,” akin to a railroad with someone else deciding the schedule. Experimentation had become more immediate, but access to the computer was still on someone else’s terms. Kay and his colleague Adele Goldberg envisioned a more personal relationship with computing: a “dynamic medium,” akin to a musical instrument, through which ideas could be expressed and altered as they arose. The personal computer would be an “object to think with” rather than a receptacle for already-finished thinking. But a medium that responded without delay also put the onus on the user to choose to step away. Sherry Turkle, a sociologist at MIT who studies people’s relationships to computers, saw the other side of this immediacy as early as 1984. In The Second Self, she writes: “It is hard to walk away from a computer program with an undiscovered ‘bug,’ it is hard to walk away from an unproofread text on the screen of a word processor. Any computer promises you that if you do it right, it will do it right and right away.” I hear echoes of these historic accounts in my own work with AI. But Kay’s “object to think with” sometimes becomes an “object to think for”: coming up with ideas for work to give the machine, without always stopping to consider the value of that work. My personal experience has been that without hard constraints, stepping away becomes even more difficult. The journey to Delphi Lately I’ve been thinking more about the journey to my “oracle.” Greek pilgrims arriving by sea at Delphi rested at the port of Kirrha before continuing 11 kilometers uphill to the sanctuary. Seeking an answer about their personal or communal affairs required time away from ordinary life. I wonder whether the Oracle of myth simply served as a reason to undertake a journey—a journey which itself clarified questions and revealed the answers. While I won’t go as far as downgrading my Claude plan just yet, I would like to make room for a smaller version of that journey in my ordinary work. Let a new feature idea sit overnight. Before bringing a difficult question to a model, first write down why it matters and what I think the answer might be. Maybe I’ll even ask my daily conversation agent to suggest these pauses. Some ideas will still deserve to be built in the morning. Others, I suspect, will lose their appeal once the immediate gratification of being able to build them has worn off. Jack Cheng is a senior editor at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # Evals for Everyone Astra and Fable 5.1 can ace a graduate-level science exam, but no public benchmark will tell you whether a model knows where you’d put a comma or how many ideas belong on a slide. Today, Every CEO Dan Shipper explains why we’re building a personal benchmark for every employee, head of evals Mike Taylor shares how a run on his own benchmark convinced him a smaller model could handle much of his daily work, and we offer a five-step workflow for turning the corrections you already give AI into checks for grading any model. Was this newsletter forwarded to you? Sign up to get it in your inbox. Inside Every Astra and Fable 5 scored 96 percent and 93 percent, respectively, on a test of graduate-level science questions. Impressive, clearly! What’s less clear from public benchmarks is how those scores translate to what most of us care about: how well these models help us do our jobs. The solution, says Dan, is to create a personal benchmark—a set of custom evals that tests how well a model does specific parts of your work, graded against your own standard for what good looks like. We’re building them for every employee. Editor in chief Kate Lee’s benchmark captures her copy-editing judgment, with rules on everything from comma placement to word choice. Mike’s benchmark for creating decks includes a simple preference: one idea per slide. We all have preferences like these; a personal benchmark turns them into rules a model can be tested against, showing you what AI can reliably execute and where it still needs your intervention. Dan describes this as a way to “push yourself up a level.” Instead of correcting outputs one by one, you design a system for how you want the work done. That system can improve over time, too. The rules you use to grade a task can become skills that improve future outputs. When a model falls short, you diagnose the failure, revise the skill, and rerun the eval. Failures become feedback. “It’s the first step to working in a compounding loop,” Dan says. Checks can become skills that continually improve with your feedback. (Image courtesy of Mike Taylor.) How this works in practice To build a personal benchmark for each of us, Mike and senior applied AI engineer Nityesh Agarwal collect five to 10 tasks a person regularly hands to AI, along with the prompts they use and any source documents. They run the tasks on different models, then ask the person to talk them through the outputs: What does the person like? What needs fixing, and why? The feedback will become checks for evaluating future outputs, so the more specific it is, the better. One task in Mike’s own benchmark is to generate a course feedback dashboard: a web page where he can browse and analyze participants’ ratings and comments. Some checks are programmatic: Does the page load? Do the calculated scores match the source data? Others are subjective. An AI judge evaluates whether the design avoids the dark-mode aesthetic Mike dislikes. Every check passes or fails. How feedback becomes checks. (Image courtesy of Mike Taylor.) The checks need testing, too. If you disagree with an eval score, Mike says, you tune the benchmark. The problem might be that “we don’t have enough checks yet, or we’ve got the wrong definitions for the checks we’re running.” Once you and the AI judge reliably agree, the benchmark can tell you which model is best for each task. When a new one arrives, one run shows where the new model beats your current choice. Sometimes, that changes your mind. When Nityesh ran Mike’s benchmark, OpenAI’s GPT-5.6 Luna outperformed Fable and GPT-5.6 Sol. Mike inspected the results and agreed: The smaller model had performed well. That suggested it could handle many of his day-to-day tasks—and prompted him to expand his benchmark to include harder assignments. GPT-5.6 Luna outperformed more powerful, expensive models at many of Mike’s day-to-day tasks. (Image courtesy of Mike Taylor.) Steal this workflow Turn corrections into checks Every time you ask AI to edit a paragraph, redesign a slide, or rewrite code, you’re making a judgment call. A personal benchmark turns those judgments into checks you can use to compare models. Here’s a lightweight way to start. 1. Pick a recurring task Look through your past AI chats for tasks you do often and mistakes the model keeps making. If nothing comes to mind, ask Codex or Claude Code: Prompt What tasks do I do regularly, and what do I keep asking you to fix? 2. Use it as a test If the task is to make a presentation, save the prompt, and source files for one deck. Run the task in a new thread. Save the first output before you request any changes, and record the model and its reasoning setting. You now have a fixed test you can run on any model. Keep the instructions and source material the same each time. 3. Turn your feedback into a checklist Review the AI’s work as you normally would. Type or dictate what you like, dislike, and want changed. For a presentation, you might say: Prompt This slide crams three ideas together, the text is too small, and it uses the wrong font. Ask the AI to turn your feedback into separate yes-or-no questions, one requirement per check: Does each slide contain only one main idea? Is all body text at least the minimum size specified in my style guide? Does the deck use my specified font? Edit the questions to reflect your standards. Each should identify something specific the output needs to get right. 4. See whether AI can reliably apply your checks First, grade the output yourself. If slide three combines the budget, timeline, and hiring plan, the “one idea per slide” check fails. Next, open a new conversation and provide the presentation, the checklist, and any reference files, such as your style guide. Keep your grades to yourself and ask: Prompt Evaluate this presentation against each check. Mark pass or fail, and point to the specific evidence behind each decision. Compare its answers with yours. Did it catch the multi-idea slide? Did it flag something you missed? Where you disagree, examine the evidence: Either the AI got it wrong or the check needs more specific wording. 5. Resolve disagreements and test again If your benchmark passes a presentation you wouldn’t use, figure out why. Common issues include: An unclear check: “Slides are readable” might need to specify a minimum font size. A missing check: The slides look good but leave out a requested topic. Add a check that all requested topics are covered. A grading mistake: The check is clear, but the AI missed an error. Regrade after every change, and apply the revised checklist to every output you’re comparing. Make sure you’re not tuning the rules to favor one model. Finally, save the checklist with the assignment and run it on a different example. That tells you whether it captures your standards or just the problems in the first output. Thesis Statements Three weeks ago, we launched Thesis Statements, a collection of specific, contestable claims from builders and thinkers about the future of great human work with AI. This week, we have seven more predictions from people at the frontier: “Powered by AI” will mean cheap by ÌníOlúwa Abíódún, lead product designer at AirOps We’ll move from a knowledge economy to a discovery economy by Matt Cynamon, media at Union Square Ventures We’ll pay to watch humans make things by Natalie Fratto, founder of Charts & Crafts When AI can argue for anything, trust your gut by Tim Fu, founder of Studio Tim Fu Institutions won’t need a crisis to change by Sahil Lavingia, founder of Gumroad Every good idea will have 1,000 clones by morning by Mike Taylor, head of evals at Every Certainty will be the trap by Alex Tryon, founder of Dewey If you want to help decide what matters in the future of AI and human work, think creatively, and build what comes next, join us at our inaugural Thesis: 2027 conference on November 5, 2026. The daily driver The models the team is using this week Nityesh: Fable 5.1 (medium) as his daily driver for its balance of thinking effort and cost. Douglas Brundage, head of marketing: Astra (light), switching to high for asset creation, plus GPT-5.6 Sol for simpler tasks. Andrey Galko, engineering lead: Opus 5 for smaller tasks and Fable 5.1 for larger projects. “Still trying to understand what Astra is capable of but can’t really say I’m impressed.” Becky Isjwara, head of social media: Primarily Astra, with Fable for video and Astra for computer use. She also uses Grok Bot through Astra’s computer use for X research. Waqqas Mir, customer support specialist: Back to using Opus 4.8 (high). Katie Parrott, staff writer: “I have been Astra maxxing and I’m afraid for my bank account.” She finds Fable “more psychologically insightful as an interviewer and rigorous as a planner,” but has gotten hooked on Astra because its writing is more fluid and surprising. Natalia Quintero, head of consulting: Fable 5 for writing and thinking after burning through Fable 5.1 credits too quickly, and Astra (medium) for everything else. She avoids Astra at higher effort because it starts “spiraling and overthinking so much its work is unproductive. Spiraling and overthinking is my job, Chat!” Arielle Shipper, head of operations: GPT-5.6 Sol (medium), occasionally switching to Astra (light). “I am officially taking Sonnet 5 off my list of models because it took 12 minutes to compare two Google Docs—and still did not arrive at an answer. Sol did the task in 42 seconds.” Dan: Mostly Fable 5.1 and Astra, with a smattering of GPT-5.5, GPT-5.6 Sol, and Opus 5. Loren Stewart, engineer: Astra (medium) and GPT-5.6 Sol (medium or high) for coding; Fable 5.1 for thinking and discussing ideas. He uses Fable and Astra to critique his writing. Mike: Primarily GPT-5.6 Sol, reserving Astra and Fable for bigger tasks because of cost. That said, “Astra’s computer use is phenomenal.” The model took screenshots of items in his browser and on his computer and used them to make hundreds of small edits to a slide deck, requiring “almost no correction.” He recently compared Fable 5.1 and Astra for writing, and concluded, “Claude is still the better writer.” Willie Williams, head of platform: Mostly Astra and Fable 5.1. “Grok Bot fell off, but I feel the need to bring it back.” Dan’s love of Fable 5.1 and GPT-6 Astra hasn’t gone unnoticed. (Screenshot courtesy of Laura Entis.) The team compares Fable and Astra for writing, planning, and developing ideas. (Screenshot courtesy of Laura Entis.) Straight from Slack Show us your agent setup Cora general manager Kieran Klaassen is up first. (Screenshot courtesy of Laura Entis.) We’re turning our Friday internal show-and-tell into a tour of how people at Every use Codex and Claude Code. Over the next few weeks, teammates will open their setups and folder systems to show how they get work done. As we wrote in “A Codex of One’s Own,” those setups can be as individual as the people using them. Watch this space for reporting on everyone’s different styles—and ideas to borrow for your own. Laura Entis is a staff writer at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # What Writers Who Use AI Want You to Know Last week we launched How We Write Now, a series about how writers are using AI, starting with Katie Parrott’s guide to Compound Writing—her framework for developing ideas, shaping drafts, and carrying what you learn into the next piece. This week, Laura Entis, who has been reckoning honestly with her own AI workflow, goes further: She interviewed five professional writers—including Every CEO Dan Shipper, designer Maggie Appleton, and New York Times alum Kevin Roose—about where they let AI in and where they draw the line. She found that there is no universal recipe: The same tool that helps one writer think more clearly makes another’s prose worse. Read on for five distinct, idiosyncratic workflows (including custom prompts) that make a case that writing with AI is a skill in its own right.—Kate Lee Was this newsletter forwarded to you? Sign up to get it in your inbox. On deadline for a book about neurodiversity and work, journalist Alexandra Samuel fell victim to a condition all writers know and fear: writer’s block. She had the research and a detailed outline. But there was always one more study to review, and so she put off writing anything. She booked a DIY writing retreat at a friend’s empty apartment, told herself she’d tackle a chapter a day—and turned to AI. Each morning, she converted her research for that day’s chapter into a podcast, which she listened to as she scrambled eggs and made the first of many cups of coffee. The practice made sitting down to her computer feel more like continuing a conversation than staring at a blank page. When she hit a wall with drafting, she gave ChatGPT the day’s pages, closed her laptop, and had it interview her as she strolled through her friend’s neighborhood. The AI’s questions cut through her confusion. “After 40 minutes, my head was clear, and I knew where I was going,” she says. She wrote 52,000 words in 10 days. These were her rough thoughts rather than polished prose—barely any of the words made it into the final version—“but it got me moving,” Samuel says. However rough, the material gave her the momentum to work towards a final manuscript. Her book, Working Neurosmart, will be published in April. In online discourse, “AI and writing” are draw-your-swords fighting words. On one side of the imaginary line, they mean you’ve outsourced all your thinking to a machine. On the other, you’re engaging in the only logical form of modern communication, the equivalent of using your phone’s GPS instead of a paper map. My own experience with AI and writing is less black and white. AI allows me to move faster—in pre-GPT days, I transcribed interviews by hand, a process that now takes minutes instead of hours—and it makes it easier to draw on my reporting, surfacing relevant quotes, confirming details, or drawing connections between information spread across several interviews. But it can also be a crutch: When I’m tired or pressed for time, I lean on it for too much and end up with words that sound good at first but lack a clear explanation, argument, or point of view. I try to white-knuckle my way through an outline and rough draft myself. Only then do I bring AI in to help make structural changes, refine ideas and language, add supporting information—it’s great at filling in or clarifying details from a project’s source material—and improve transitions. I’ve found that once I’ve struggled to determine what I want to say, AI helps bring the piece closer to what exists in my head. This is my current recipe for AI and writing. (As with all things AI-related, it will undoubtedly change.) Curious where other professional writers have landed, I interviewed five of them on how they do—and don’t—integrate AI at every stage of the writing process: research, ideation, structuring, writing, editing, and verification. None of them has the same workflow or draws the same lines around how they use the technology. Like me, most still struggle to reliably identify which parts of the process AI makes easier without making their writing worse—even if they feel AI has made them better at their craft overall. A strategy that makes one person a sharper writer might degrade the work of another. Writing is the personal, sometimes joyful, often painful work of giving your ideas clarity and structure. AI can help with the process, but AI doesn’t write; it’s a tool, and knowing when and how to use it is as much a skill as writing well. Agents make for excellent research assistants Former New York Times technology reporter Kevin Roose used AI to research, transcribe, and fact-check The AGI Chronicles, his forthcoming 448-page account of the race to create artificial general intelligence. The book, based on more than 150 interviews, took him roughly a year to deliver; without AI, he estimates it would have taken three to five years. He called on AI to identify relevant research papers and translate dense technical topics, but a major unlock was using AI to automate his entire transcription pipeline. After each interview, an agent transcribed the recording, extracted key details, sent him a list of five subjects who could speak about similar topics, and flagged any Slack logs, emails, text messages, or other artifacts he should ask the source to share. The agent was great at turning up contact details for potential sources, including some with very little publicly available information. In one particularly tricky case, it exploited a security flaw that enabled it to extract the email address associated with that person’s GitHub account. As Roose interviewed people and disappeared down research rabbit holes, he threw transcripts, peer-reviewed papers, articles, sections of books, and more into a set of queryable notebooks that served as his “outboard brain.” Later, he used those notebooks and his working draft to prepare for interviews. His agents could survey the combined context, identify gaps in his reporting, and draw his attention to what the person he was about to interview could help him better understand. Many of the people Roose interviewed for the book worked at the same companies developing the AI models he used to assist with his research. To protect his sources, if they told him something confidential about a specific company—OpenAI, for example—he wouldn’t upload that information with their name or identifying details into any of its models. He occasionally used local models for sensitive information such as internal company documents, “but in general I just tried to be smart about which models I used for which tasks and kept some information offline or away from AI entirely,” he says. Maggie Appleton, a designer and anthropologist at GitHub Next who publishes illustrated essays about programming, design, and culture, regularly uses AI in the research process to surface connections she has overlooked. When starting a new piece, Appleton uses dictation mode to “brain dump my notes,” then asks Claude Code or Codex to fill gaps in her research: “What don’t I know about in the literature? Look at what I’m saying and who I’m already referencing. Who should I be referencing that I don’t know about?” Recently, this process re-introduced her to the work of anthropologist Lucy Suchman. Appleton had studied her work in university but somehow failed to see how Suchman’s research neatly mapped to the main argument of a speech she was workshopping. “You get stuck on what you’re already looking at,” Appleton says. AI can shake you out of your frame of reference. “That was one of those moments where I thought, ‘Good job. I would not have gotten there.’” AI can expand and sharpen your thinking When Samuel starts a piece, she wants to get as many ideas as possible out of her head before her editor brain kicks in. Earlier in her career, she typed in white font, so she couldn’t see what she wrote and get hung up on the details. Nowadays, she sometimes uses a voice memo or dictates her thoughts to ChatGPT during long, meandering walks through her beachside neighborhood, past a pond, through the woods, and back home along the water. She purposely doesn’t self-edit; she’s after sprawling messiness at this stage. After the initial brain dump, Samuel uploads the transcript into a session in Claude Code and has the agent ask questions that surface gaps in her argument. “I flesh it out and get the rest of my mental garbage out of my brain,” she says. Then the writing can begin. AI can also stress-test an idea to see if it’s worth pursuing. Emilia David, an associate editor covering enterprise AI and technology at Information Security Media Group, must quickly determine which AI developments matter to her audience. At VentureBeat, where she worked as a senior reporter until June, her coverage area was tightly defined: AI orchestration, or how AI applications and agents work together. To help identify story ideas, David fine-tuned a custom GPT to respond to pitches from the perspective of her target reader—a senior engineer at a large enterprise who cares about orchestration and observability—based on profile information from VentureBeat’s editorial and marketing leadership. Prompt The reader is a Senior AI Engineer with expertise in designing and implementing efficient AI orchestration systems to streamline and scale machine learning models across the organization. They work at companies ranging from 200–10,000 employees and focus on building robust, scalable AI pipelines that can manage model deployment effectively across different environments. They communicate in a technical and practical manner and prefer deep technical details paired with practical advice. To try David’s approach, fill in the template below and add it to your custom agent’s instructions. Adapted from her reader profile, it gives the agent context to assess news and potential story ideas through the lens of what matters to your target reader. Prompt The reader is [describe your target reader] with [their existing knowledge or experience] in [topic or field]. They [describe relevant circumstances: their work, interests, responsibilities, or community] and care most about [their priorities, questions, or challenges]. They read [your publication or type of writing] to [what they want to understand, discover, decide, or do]. They prefer [tone, level of detail, and types of examples], and need explanations of [concepts they may not already know]. When I share a story idea, assess it against this reader profile. Explain why the reader would—or wouldn’t—care, identify the most relevant angle, and flag what reporting would be needed to support it. Don’t assume an announcement deserves coverage simply because it is new or widely discussed. Make clear what’s supported by the material and what needs more reporting. Her GPT also incorporated editorial feedback on previous pitches. “The model learns what my editors are looking for, so it helps craft an idea of what works as a story—what would pass muster if I were pitching,” David says. She used it to test ideas and suppress the FOMO triggered by AI developments that dominated X but didn’t matter to her target audience. David’s GPT identified angles she would have otherwise dismissed. At VentureBeat, David didn’t typically cover product releases—a rule she assumed would apply when Anthropic released Managed Agents, a service that handles the work of running enterprise AI agents. (“I read the press release and thought, ‘Cool. I don’t think that’s a story.’”) But she ran the announcement through her audience agent for another gut check. It pointed out that because Anthropic would run the agents and store their data in its system, customers could be locked into the company’s technology and terms. “That is something an AI orchestration engineer would be concerned about,” she says. David homed in on the angle and published a piece that skipped the product announcement to focus on what the development meant for her readers. AI can create systems to structure your work—but you still need to decide what goes where As a writer, Appleton has always needed to maintain a bird’s-eye view of the material in a piece without losing track of its individual components. In the past, she mapped out story ideas on giant sheets of paper, which evolved into cobbled-together digital versions in Miro or Figma. With AI, she can now build a writing canvas designed for this purpose. “We’re finally at a moment where personal software is within reach,” she says. Created with the tldraw software development kit, the canvas connects to Claude Code, Codex, and other agents through a Model Context Protocol (MCP) server. Each article gets its own canvas, organized into vertical columns representing sections. Appleton dictates rough ideas to an agent, which arranges them into cards she can move within and between sections. Note cards hold ideas, excerpts, and research summaries; prose cards contain draft text and appear in a sidebar that displays the piece linearly; figure cards represent illustrations, graphs, and interactive elements. Appleton can rearrange the spatial canvas and immediately see how the prose reads in its new sequence. Through the MCP server, agents can organize material, find repetition, summarize references, and comment on selected cards. A semantic-zoom feature condenses each card to a sentence when Appleton views the canvas, allowing her to see the piece’s overall argument without losing the underlying text. Appleton’s canvas allows her to move note cards between sections, which are arranged vertically; a sidebar displays all draft text in sequential order, so she can review what she’s written linearly. (Screenshot courtesy of Maggie Appleton.) This visual breadth, paired with card-by-card modularity, makes sprawling pieces feel manageable enough to finish. “Writing is a long, hard process for me, no matter how I go about it,” she says. “What I’m hopeful agents can do—and what I feel they’re helping me do with this tool—is make it slightly less painful.” Agents can review cards on her canvas and leave comments or suggest additions. (Screenshot courtesy of Maggie Appleton.) Appleton still struggles to determine the narrative arc and decide what material to cut. “It comes back to the fact that agents don’t have the same taste we do. The people who make models bake taste into them. Claude is very opinionated, and ChatGPT models also have a certain opinion to them, but it’s not my opinion,” she says. “I always end up having to figure it out.” Roose has come to a similar conclusion. AI is good at chronology, turning his sprawling notebook into a “mega-timeline” organized by company. “That was enormously helpful for unscattering the information and putting it all in one place,” he says. But he found AI “alarmingly bad” at subjective editorial calls. Requests for advice on improving structure or pace were regularly met with “stupid things like, ‘You might want to do a cliffhanger ending on this.’ I’m like, ‘But it’s the fifth paragraph. Why would I end with a cliffhanger there?’” he says. Fed up, Roose worked out the book’s narrative arc on a wall-sized whiteboard in his office. “That’s the part where I feel I’m much stronger than AI right now,” he says, “so I did it.” Once Roose understands a chapter’s shape, AI becomes useful again. He can ask his agents to pull everything his sources had said about the pretraining of GPT-4, for example, and, like GPT-powered magic, they will. I also don’t like to invite AI into the planning process—seeing what it suggests alters my conception of what the piece is about and what information is most important. I generally create my own outline from fragments of ideas and sections of interview transcripts, and dictate my thoughts about each section based on the existing material. This gets me to a rough draft faster, which, in its earliest stages, consists of block quotes framed and connected by my ideas on what they mean and how they relate to the piece’s overarching narrative or argument. Models can write well, but they require supervision and revision Writing is the part of the process many writers say they refuse to allow AI to touch, even if the technology is integrated into the steps that come before and after. “AI does none of my writing,” Samuel says. “It is always a sounding board for me.” Every CEO Dan Shipper is an exception. A prolific writer, he publicly and enthusiastically uses AI to generate (gasp) actual sentences. (The public part might be what sets him apart—most writers use AI, Dan contends, even if they don’t admit to it.) AI’s suggestions give him something to react to: He identifies what he likes, explains what isn’t working, and rewrites the output until the text says what he means. Even an unsuccessful attempt by the model can help him figure out what, exactly, that is. In practice, that process unfolds in three steps: Getting back into a draft When we spoke, Dan was writing a longform reported feature on OpenAI. Before he tackles a new section, he needs to ground himself in the thousands of words he’s already written. So he has Codex turn his existing draft into a podcast. That way, when he wakes up, he can listen while he brushes his teeth or takes a walk, reacquainting himself with the material before sitting down to write. Diagnosing what isn’t working A recent session shows how Dan uses AI to improve the writing itself. Unsatisfied with his latest paragraph—“Code rarely runs on a new computer without preparation. The right software dependencies, permissions, and settings must be installed first.”—he asked Codex to suggest ways to improve it. The model correctly identified that the passage failed to answer the preceding question: Despite being popular inside OpenAI, why had Codex initially struggled to attract external users? Rewriting through reaction It proposed a fix, but the language left him uninspired: “Codex’s computer is not your computer.” It’s a line that “sounds good” at first, Dan says, “but when you think about it, you realize you have no idea what it means.” He pressed the model for more clarity, and it returned a revised version. He responded with what he disliked; it tried again. After a few more exchanges, much of the final paragraph came from the model. “This is typical of how I write,” he says. “It bushwhacks and makes a path, and then I can follow the path.” On rare occasions, the model hands him exactly what he wants. Most of the time, the process is painstakingly incremental—but so is writing. For Dan, “writing is the act of taking something as complicated as reality and putting it down word by word. It’s an act of thinking.” “It sucks,” he continues. “And it’s valuable.” AI helps him more precisely identify what he wants to say from the universe of possibilities. Appleton occasionally works in the opposite direction from Dan to get to the same result: She uploads an imperfect sentence to Claude and asks for several clearer or more concise alternatives. Because the suggestions are anchored to her words, they can bring her closer to what she means. “In those cases, the sentence still doesn’t feel like an AI sentence,” she says. Beyond that, Appleton draws a clear line around writing the words herself. As a reader, she expects words to come from a human; if she suspects Claude wrote them, her reaction is “Close tab, no thank you.” Much of her reluctance stems from AI’s limitations. “When I’ve tried to have agents write final prose for me, the thing they say is never the thing I actually mean,” she says. She fed her agents samples of her writing to create custom writing skills and found herself nodding along to their assessments: Her writing is personal, conversational, and a little dry, and she does position herself as a learner, not an expert. But none of it helped. “How would an agent ever write the words I would write? How would an agent ever say the exact thing I’m trying to say?” she says. “Even if it sees my notes, it doesn’t really understand the thing I’m trying to say, because I haven’t said it yet.” Roose also did not use AI to write his book, primarily because he believes he owes readers his human thoughts. In his author’s note, he discloses he used AI tools extensively for research, transcription, and fact-checking, but established a “bright line” rule not to use it to generate any of the text in the book. He also hasn’t found a strategy that makes AI writing any good. (He has yet to experiment with custom style guides based on his writing to see if the results are better.) Roose has “an allergic reaction to [text generated by a large language model] on a stylistic level.” In his estimation, Claude 3.5 Sonnet set the high-water mark for AI writing. Model prose, at least at the sentence level, has degraded with recent releases. During his year working on the book, “my trust in models for things like research and fact-checking went up, while my trust in them for structure, craft, and sentence-level construction went down,” he says. AI feedback can be cheap, fast, and flawed Roose did not want AI writing the book, but he did want more reviewers. “I was trying to imagine, if I had unlimited access to really smart people to help me review the book, what kinds of people would I want to gut-check it, and where might my blind spots be?” he says. Before he sent the manuscript to his human editors, he ran each chapter through what he calls “my council of Claudes.” The council included agents modeled on a lab historian and archivist with institutional memory of the major AI companies; a technical skeptic in the mode of Yann LeCun or Gary Marcus; a “Yudkowsky-type” AI safety researcher; a machine learning researcher; a policy and compute expert; and a narrative craft reviewer looking for clichés and issues with his timeline. Prompt I need you to plan an editing and fact-checking process for this manuscript that goes beyond looking up spellings, dates, etc. I want to get masterful, deeply researched feedback from a number of agents, working chapter by chapter, each with different areas of expertise. I want these notes to come from a place of deep knowledge, like a person who has the entire history of AI stuffed in their head. here’s a feedback note from a human reviewer i got that is the correct level of depth: [pasted note about GPT-1 pretraining and the Dai & Le / ULMFiT precursors] one agent should be an “expert” on each of the labs, one should be an AI skeptic who is still deeply knowledgeable, one should be a robert caro/water isaacson style storyteller who can analyze the story in a content-neutral way, and one should be an eliezer-type safety expert. I could use your suggestions on others. I’m thinking 5-6 agents total, each with unlimited compute budgets (up to the token limits of my account), that can confer with each other and synthesize their feedback by chapter in a single unified document. sound good? Each reviewer supplied feedback to a master-editor agent, which returned the highest-priority items for Roose’s attention. Ninety-five percent of what the council returned “was slop,” he says—his job was to determine the 5 percent that would make the book better. “The best things the AI gave me were quite useful, but I had to sift through a lot of garbage to find them,” he says. Samuel built her own panel of imaginary readers to broaden the range of perspectives in her book. In her initial draft, she noticed that the hypothetical examples repeatedly involved “middle-aged, menopausal, ADHD women”—in other words, herself. “I need to get out of my tunnel vision,” she recalls thinking. She created six personas, each with a different professional biography, and placed them in a Claude Project. Talking with these imaginary readers—sometimes out loud, through Claude voice mode—helped her think up examples beyond her own experience. Few made it into the book, but even the flawed ones proved useful. One persona was a senior professional from a Latinx background. The scenarios Claude generated repeatedly leaned on “the fiery Latino” and repeatedly emphasized his family commitments in a way it did not for other personas, which made Samuel more deeply consider the stereotypes embedded in its responses. “The risk of using AI in any field—but perhaps particularly for those of us who write about AI—is losing sight of its limitations and biases,” she says. “Anything that breaks the AI is, to my mind, a useful reality check.” Agents are good first-pass fact-checkers A freelance journalist who runs her own business, Samuel has developed an elaborate AI fact-checking workflow for getting up to speed on unfamiliar topics. When she needs to quickly digest the available research—for example, to determine how long and at what temperature clothes moths must be frozen to die (she has an infestation)—she instructs a Claude agent to produce a memo with literature from peer-reviewed, well-regarded journals. Her process for reported articles is more manual. Before she reads the memo and allows “my vulnerable, impressionable brain to absorb questionable information,” she runs it through a fact-checker skill. Two subagents review every factual assertion and mark it as accurate, false, or ambiguous based on the cited literature. If they disagree, a third agent is called in to break the tie. The skill compiles its findings into a CSV, then produces a corrected memo. Prompt You are a professor of journalism and the chair of your university’s research ethics board. A research centre at the university has used AI to produce the brief below for a client organization (with their knowledge). You have been charged with determining whether it meets the university’s standards for rigor, accuracy, and evidence-based research. Your assessment standard is based on: Fidelity to source material. Is each assertion in the brief verifiably based on an external source? If so, you should be able to identify a verbatim quote or passage in the source material that says what the brief says it says. Fidelity means fidelity to both the letter and the spirit of the original — i.e., no cherry-picking a parenthetical quote that posits a theory or argument the source article then goes on to disprove. Credibility of source material. Are the sources high caliber? Top caliber means a highly cited (50+ citations) work in a top-tier peer-reviewed journal within the past decade. Acceptable caliber is fewer citations (but not less than 5) in a peer-reviewed journal, or publication in a major newspaper or media outlet, or from a major consulting firm or company known for its thought leadership (Deloitte, Gartner, IBM, etc.). Unacceptable is: invalidated research subsequently retracted; minor or fringe outlet; low-caliber journal with no citations; a marketing report or study from a non-credible company or just a 1–2 page news release. Recency/currency of source material. Do the sources and ensuing findings reflect the current state of knowledge and understanding? When using material older than 5 years (and especially if older than 10), look for recent citations of that material to determine whether it is still relevant or has been superseded by more recent research. Completeness, coherence, and consistency of interpretation. Does the resulting brief coherently reflect the breadth of material reviewed? Was the source material broadly reflective of the field as a whole, or does it represent a particular and non-representative subset of the research? Are the brief’s findings (and if applicable, recommendations) consistent with the current state of the research in the field? Your inputs: Draft research memos or information files. Your outputs: A memo listing every fact in the input memo, with an evaluation of accuracy next to each one (based on the assessment standards above) and recommended changes. This memo should include a table that lists every fact in the source memo, with each one marked in the “verdict” column as CLEARLY FALSE, AMBIGUOUS, UNSUPPORTED or CONFIRMED. Add a “notes” column for your comments, and a “verbatim source” column with the specific citation(s) and an exact quote used to evaluate the claim. An annotated copy of the original brief, showing all suggested changes. A revised copy of the original brief, with all suggested changes implemented. Note that the client is aware these are AI-generated memos, so it is acceptable to flag assertions as concerning, unverified, etc. without necessarily deleting them. Your process: Break out every single factual assertion in the source brief: each name, date, quote, finding, statistic, etc. Work through each fact one at a time. Look at the original source (if provided/cited); if no source is provided, look for your own sources (high or acceptable caliber). Find a specific quote in the source that validates or contradicts the assertion, and add this verbatim quote to the “verbatim source” column. As you work through each assertion, mark each fact as CONFIRMED (with a source citation), UNVERIFIED (no source can be confirmed), or FALSE (verified incorrect). Do not skip any fact. If you can’t find anything to support or disprove a fact, mark it UNVERIFIED. Any questions? You should be doing DEEP RESEARCH and THINK HARD. [Paste the research brief here.] Roose relied heavily on AI as a first-pass fact-checker. Extracting every claim about every person in his book and sending it to them to review could have taken weeks. Instead, Claude created individualized fact-checking documents and formatted them as emails so sources could respond to or clarify each item. “It was basically a one-shot,” he says. He also had subagents compare a near-final draft against his research notebooks and search the web. They caught inconsistencies involving people’s ages—“You refer to this person as a 30-year-old AI researcher, but in the summer of 2017, they would have been 31”—titles, and the dates they joined company boards. Some findings were false positives or negatives, “but it was a good start,” Roose says. A human fact-checker paid for by the publisher took over from there. Every writer needs their own AI workflow Just as there is no single way to write, there is no single way to write with AI. Writing is a personal act that consists of thousands of choices—about audience, angle, style, tone, and framing, some conscious and many not—that add up to a finished piece. AI adds another layer: what to delegate, what to do yourself, and what to tackle alongside the machine. These choices can be exhilarating—or paralyzing. Every staff writer Katie Parrott uses her Compound Writing plugin to bring AI into the entire writing process, from developing an idea to sentence-level edits. She tests her work with multiple AI reviewers, decides which feedback to incorporate or reject, and saves useful lessons to inform AI’s approach to her next piece—a framework for efficiently creating high-quality, distinctive drafts that say what she means. (To try Katie’s approach, check out her Compound Writing plugin.) Meanwhile, I find AI’s ability to argue either side of any decision from countless personas overwhelming. For me, AI’s clearest use case is its ability to store and pull from all the context that goes into writing an article. For this piece, I uploaded the initial pitch, interview transcripts, and relevant articles in a single Codex thread. When I needed to fact-check a claim or clarify language, Codex referenced the original transcript or supporting article to improve the piece—or at least outline possible solutions. Each professional I spoke with has their own detailed, idiosyncratic, and still-evolving recipe for transforming ideas from their heads and research from the world into words on a page—or 448 pages. As AI tools evolve, the choices available to writers will expand, too. “There’s room for artisanal writing and journalism, and there’s room for journalism that is assisted by all of the tools available to us, including AI,” Roose says. “Something that works for me may not work for someone else, and that’s totally fine.” Laura Entis is a staff writer at Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # To Read—Or Not to Read the Code? Was this newsletter forwarded to you? Sign up to get it in your inbox. I’m shipping more than I ever have, but I think my brain has gotten softer. For the last year, I’ve hunted for the parts of coding that still needed me, then replaced myself with something that could do it, whether that’s a skill, a framework, a data source, or a step that routes work to the next agent. This is the essence of Compound Engineering: Teach the system to work once, and it does that work forever. This is how I build Cora, Every’s email assistant, and across my career, I believe it to be the best product and engineering work I have done. But somewhere along the way, I found that I had lost a feeling. It used to be that learning itself was the reward. But my mind increasingly felt like a TikTok feed—full of short-lived hits of dopamine that left nothing behind. I started to notice that although the work was improving, I wasn’t. My own mind was the part of the system I had forgotten to measure. So I built another loop into my system—to fill the gaps in my understanding before they became blind spots in my judgment. The dark factory turns out the light in your head When building a product, getting out of the AI’s way is usually the right move. It makes sense to route around yourself when you are the slowest part of the system. But if all you’re thinking about is the product, you’re neglecting your own development. The “dark factory” describes an ideal state for automation in manufacturing: lights off, nobody on the floor, machines running through the night. But the risk, when automating your own work, is turning out the light in your head, too. Plenty of work should run in the dark. When we rebuilt part of Cora’s inbox, we noticed that the space between the rows was four pixels too small. It was simple to have an agent diagnose the bug, restore the spacing, write the tests, and open the pull request—the package of code changes ready for review. My understanding would not have changed the decision. But it was important to understand it anyway. Plenty of work looks mechanical until you understand enough to see the decision hiding inside it. Those are the places where I want to keep the lights on. Read the code to learn Last year, I wrote about how I stopped reading every line of code during code review. That’s still true—I don’t read code to verify the work. The planning, testing, and review agents handle that better than I do. What’s changed is that recently, I’ve started reading the code again. Not to check the work, but to learn. If your only reason for opening a diff—the line-by-line view of what changed—is suspicion, reading harder will not fix your process. Here’s an example of what I mean: Back in July, I asked /ce-explain—a command I built that explains a concept or change by tracing it through my own codebase—to walk me through how Cora turns a change in Gmail into something a customer sees: Gmail flags the change, Cora waits a moment so related changes can arrive together, then works through the batch message by message. That one pass replaced dozens of scattered details with a single picture I could hold in my head. Two weeks later, that picture is what let me tell the difference between a fix that sounded right and one that actually was. A customer reported that Cora had permanently deleted emails he’d already sent—his audit logs showed several deletions, one just seconds after he hit Send. I suspected a recent speedup had let two parts of the system collide, and I was right: A change that made part of the cleanup process run much faster had exposed a bug that had been sitting there for months. I pointed /ce-explain at the failure this time instead of a feature, and asked it to reconstruct what happened. Cora had created a draft in Gmail and saved its address to clean up later. The customer opened that same draft, edited it, and sent it. The saved address still worked, but Cora’s cleanup process had no way of knowing the draft wasn’t a draft anymore. It deleted the message anyway. The first fixes proposed were reasonable-sounding and both wrong: Wait 30 seconds before deleting, or skip deletion if Cora had just sent the draft itself. Neither matched what had happened—the customer had sent it through Gmail, not through Cora, so there was no signal to check, and 30 seconds was only a guess about Gmail’s timing. What I pushed for instead was a rule that didn’t guess: Before deleting anything, ask Gmail directly whether it’s still a draft, and if Gmail can’t say for certain, delete nothing. Within hours of shipping that rule, it was tested for real: The same dangerous condition came up again, and this time the guard refused to proceed. I didn’t need to read every line of the fix. I needed to understand the system well enough to recognize that a plausible-sounding answer wasn’t a safe one. That’s what you contribute to an agentic workflow: not code, but discernment—knowing where to point the agent, when to stop it, and which of two reasonable-sounding plans will hurt you six months from now. Left alone, it doesn’t hold steady, but erodes. A codebase compounds from the ground up. If a person doesn’t compound alongside it, the two curves start to diverge: The system keeps getting more capable while the person’s ability to judge it keeps getting weaker. This isn’t just a casual observation. Researchers Margaret Mitchell, Avijit Ghosh, and Samir Passi reviewed the evidence on this in a recent paper and found a consistent pattern: Extended use of AI agents measurably erodes the vigilance, critical thinking, and domain skill that human oversight depends on. While AI agents are new, the phenomenon isn’t. It was called the “irony of automation” as far back as 1983, by a safety researcher studying human operators of automated factories and power plants. The more capable the automation, the more the human’s own skill erodes. Agents just made it move faster. Four ways I compound the human Discernment is built the same way a codebase is: one accumulated piece of understanding at a time. Here’s what that looks like day to day. None of these depend on Cora, /ce-explain, or any particular tool; they work with whatever agent you’re already pointing at your own codebase. 1. Open the files tab again and keep a list. Revisit a pull request you merged without reading. When you hit something you don’t recognize—a pattern, a library, or a call you wouldn’t have made—ask the model why it chose this approach. You don’t need to understand every line. Notice every place you don’t and keep those gaps as your syllabus. 2. Ask for the mechanics, not the diff. Most changes depend on existing code paths the diff never shows you. Ask where the process begins, what happens next, where the information goes, and which other systems touch it. A map of the whole journey is easier to reason with than a pile of changed lines. 3. Recover the reason the code can’t show you. Design choices that look needlessly complicated in isolation usually have an incident buried behind them—a fix for a failure that already happened once. Ask why: Why does this write to a log instead of acting immediately, why does this retry three times instead of once, why does this validate a field that looks obviously fine. The code shows you what the system does. The history explains why someone built it that way—and until you know that, you can’t tell whether removing the safeguard is a simplification or a regression waiting to happen. For me, that meant learning why Cora writes every intended action to a permanent log before acting on it. A database change once mixed up which record IDs mapped to which actions, corrupting hundreds of thousands of records overnight. Because the log of intended actions had survived, we could replay it and recover in two days instead of rebuilding from scratch. 4. Let the model quiz you without turning the quiz into a gate. I got this from Thariq Shihipar: After a long session, ask for a written explanation and a quiz on any change. He merges only after a perfect score. I let tests decide whether the work can merge; the quiz finds what I still need to learn. If I miss a question, I keep the miss on my list. ‘But I only care that it works’ The objection I hear most is some version of “I only care that it works”—and it’s also one I’m least equipped to wave off, because as a general manager, caring about outcomes over process is literally the job. My version of it is more specific: Product judgment comes from watching users, not from reading diffs. Some of my best calls came from watching somebody use Cora and feeling the wrongness of it. Reading the source code wouldn’t have gotten me there. But on an AI product, what looks like a taste question is really a mechanics question in disguise. Deciding what Cora should do with a 40-message thread means deciding how much context the model gets, how long the customer waits, and how much the request costs. If I don’t understand those tradeoffs, I can’t tell whether a proposed limit is a real constraint or just the first version that happened to work. Technical understanding doesn’t replace taste, but gives me what I need to apply taste to products I couldn’t otherwise imagine or evaluate. Turn the light on The tools that once felt like my edge are becoming easier to copy. Domain knowledge and the judgment to know where to point the machine at are not. Experienced people are the most exposed here—junior engineers run into unfamiliar things constantly, but if you already know a lot, “I know this” is always available as an excuse. So force it. Pick the task you have been routing around for years, then define a measurable version of it. Replace “get better at the back end” with “find where this request spends its time and take 50 milliseconds off it.” Replace “understand the front end” with “explain why this component renders three times.” The specificity makes the work possible, and the resistance you feel is useful information. In doing this myself, here are three things I’ve come to understand: There’s no substitute for wanting to learn. Even a strict gate can lose to a tired Friday afternoon, and /ce-explain was never a gate to begin with. It can’t make me want to learn—it simply takes away the excuse that I don’t have time to write the lesson myself. Knowing how to use the tool is not knowing the work. Learning how to use AI is worth doing, but learning the work it’s doing for you is a separate task, and the easier one to let slide.It’s tempting to spend all your attention on the harness around the model, the routing and the prompting, and forget that the point was the product. Understanding doesn’t stay once you’ve earned it. I do this most days now: one concept, pushed a little further than is comfortable. It makes the work less overwhelming, and more fun. AI can make us more human, but only if we keep choosing to stay in the work. 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. Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$9,000+ in credits for the tools we build with. Subscribe --- # A Split Verdict on Fable vs. Astra Hello, and happy Sunday. The models kept coming this week—Anthropic’s Fable 5.1 on Tuesday, OpenAI’s GPT-6 Astra on Thursday—and Katie Parrott compared the two in a report from our end-of-week camp for paid subscribers, where the team came away split. Between the releases, we kicked off our How We Write Now series with her guide to Compound Writing, her system for writing with AI, adapted from Kieran Klaassen’s Compound Engineering. As the tools accumulate, so does the question of how to learn them. Natalia Quintero delivered a report on Anthropic’s certification training that 10 Every staffers completed. We’ll be back in your inbox on Tuesday, September 8.—Kate Lee Was this newsletter forwarded to you? Sign up to get it in your inbox. How we work now Fable 5.1 vs. Astra: Where each came out ahead A model can impress you with its output and still frustrate you as a collaborator. With Fable 5.1 and GPT-6 Astra both launching this week, choosing between them means getting specific about what you want a model to do—and how you want to work with it. At our latest subscriber-only camp, we compared the two mega-models’ work side by side. As Dan Shipper noted, those comparisons help us articulate our standards for good work. A prettier app might lose to one that needs fewer clicks. A stronger draft might come from the model that’s harder to steer. Here’s where each came out ahead: We’re split on which one’s a better daily driver. Kieran Klaassen preferred Fable: It was easier to build on its work without asking it to undo unwanted additions. However, I found that on writing tasks, Astra was much easier to steer through a back-and-forth, while Fable needed more context up front. We weren’t looking for the same kind of collaborator. Fable apps needed fewer clicks. Senior editor Jack Cheng asked both models for an app to digitize his handwritten journals. Fable’s let him hold a page up to his Mac’s camera, press the space bar, and turn to the next one. Astra’s had a warmer visual style, more buttons, and more decisions between Jack and a scanned page. Dan preferred Fable’s simpler approach. Fable got the diagram right. Head of evals Mike Taylor showed a slide depicting the Compound Engineering loop that earlier models had struggled to lay out. Fable 5.1 produced a usable version. Astra nearly got there but added little red flourishes that made no sense to Mike. On this test, the extra decoration counted against it. Fable’s draft won me over. I showed both models’ attempts at an essay I’m calling “After Automation, Dan Is Wrong,” with Dan on the call. Fable’s version had more of the warmth and specific detail I wanted. Astra could be clearer and more plainspoken in our shorter writing tests but sometimes put two ideas together without explaining the connection. Both needed revisions. My preference for collaborating with Astra didn’t settle which prose I’d keep.—Katie Parrott We’ll bring the next round of experiments to a future camp for Every subscribers. Knowledge base “Vibe Check: GPT-6 Astra Is a Big Upgrade With Some Bad Habits” by Katie Parrott and GPT-6 Astra/Vibe Check: OpenAI’s new model is a significant leap in writing, computer use, and visual design. It drafted the first version of Every’s own review in about 25 minutes and scored 71 out of 100 on Every’s Senior Engineer Bench, up from GPT-5.6’s 56. But Katie and Dan find it overbuilds, wrapping simple tasks in landing page copy and struggling to judge when its own work is finished. Their verdict: Anthropic’s Fable 5.1, which launched earlier in the week, still has the better instincts for shipping a working product. “Vibe Check: Fable 5.1—Anthropic Is So Back (Again)” by Katie Parrott and Dan Shipper/Vibe Check: Anthropic’s Fable 5.1, tested by the Every team before it launched on Tuesday, could still handle the heavy coding jobs that made the original worth using, now in plain, readable prose instead of telltale “Claudeish.” Marcus Moretti clocked it matching Opus 5’s agent results in about 60 percent of the time and half the tokens. Kieran rebuilt a working version of Proof from a single prompt. The catch: 5.1 blows past prompted limits—in a brief that allowed eight to 12 supporting quotes, it returned 43, some found nowhere in the source. “Compound Writing: The Ultimate Guide” by Katie Parrott and GPT/Guides: After two years teaching AI to write like her, Katie is making the system open source. Compound Writing treats the model as a partner across a repeatable loop—ideate and interview, outline, draft, review, finalize—so each session compounds instead of starting cold. The core premise: Good writing comes from good ingredients and hard back-and-forth, not a clever prompt. “How an Every Staff Writer Developed Compound Writing” by Kaushik Viswanath/AI & I: This week’s AI & I reveals the story and philosophy behind Katie’s system. Natalia Quintero interviews her about how a $20-a-month ChatGPT subscription—picked up after a 2023 layoff, when Parrott couldn’t afford a career coach—grew into Compound Writing. The guide explains how the method works, and this conversation shows why she built it. 🎧 🖥 Listen on Spotify or Apple Podcasts, watch on X or YouTube, or read the transcript. “What We Learned From 15 Hours of Anthropic Certification Training” by Natalia Quintero/Every: A third of Every’s team took Anthropic’s new four-course certification—roughly 10–15 hours each—and the emphasis wasn’t on workflows but vocabulary: common definitions of skills, MCPs, and APIs, the scaffolding the industry still needs to align on. As an “AI 101,” it works, though the team agreed Anthropic’s documentation outclasses the videos. One course still runs on a Sonnet model no longer available in the API. “The Folder Is the Agent” by Kieran Klaassen/Source Code: Ahead of Kieran’s piece next week on compounding the human alongside the code, we republished his article from April on treating folders as agents. After three months chasing agent “swarms,” Kieran realized he could point a model at a directory with the right context, skills, and a CLAUDE.md to get a specialist. Change the folder, and you get a different one. “You can’t vibe orchestrate,” he finds—build it, use it, trust it, then orchestrate. Thesis Statements Read seven more predictions from people at the frontier in Thesis Statements, a collection of specific, contestable claims by builders and thinkers about the future of great human work with AI. Our work will be discovering the destination, not optimizing the route by Christine Choi, partner and head of brand communications at M13 Art school will be the best training for technical work by Hilary Gridley, product leader and writer of the newsletter Writerbuilder Progress will be measured by the depth of human wisdom by Sam Pasupalak, cofounder and CEO of Skyfall AI AI will become a mise en place for the mind by Micah Rich, head of AI education at Every Machines will meet us the way we meet each other by Victor Riparbelli, cofounder and CEO of Synthesia You’ll be paid for what you can feel but can’t explain by Emmett Shine, cofounder and designer of Little Plains AI will introduce a lower floor and a higher ceiling for excellence by Ben Tossell, founder of Ben’s Bites Join us at our inaugural Thesis: 2027 conference on November 5, 2026. Work at Every We’re hiring a senior manager, partnerships, and programs at Every. It’s a role for building and growing ambitious partnerships, programs, and commercial opportunities across the company—everything from sponsorships to the Builder Pack to platforms like Thesis. We’re looking for someone entrepreneurial: an excellent relationship-builder and strong operator who’s energized by figuring out new things rather than running an existing playbook. Know someone who’d be great—even if they’re not actively looking? Learn more and apply. Alignment Good mistakes. In a new study of AI in drug discovery, researchers asked models to predict molecular properties such as toxicity from a molecule’s structure. They then added AI-generated descriptions of the molecules to see whether the extra context improved the predictions. Those descriptions contained glaring hallucinations, yet some models performed better with the flawed text than with the molecular structures alone. Why might a wrong description still lead to a useful connection? The researchers suggest that the flawed text may nudge the model to consider counterfactuals that lead it to better predictions. An inaccurate description could give the model another way into the problem—like finding the right key for the wrong door. What interests me about this explanation is how it resembles creative thinking: We sometimes follow lines of thought that prove entirely wrong yet lead us to fruitful connections we wouldn’t have otherwise made. In work requiring originality, then, we might treat hallucinations as hypotheses to test, rather than errors to dismiss. My takeaway is to ask whether a wrong answer points toward a useful question—and then investigate what follows.—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—$0,000+ in credits for the tools we build with. Subscribe --- # The Folder Is the Agent Next week, we’ll be publishing a reflection from Cora general manager Kieran Klaassen on how human builders can keep compounding—rather than switching off—once Compound Engineering removes them as the production bottleneck. In anticipation, we’re republishing his April piece on the folder-as-agent approach that let him orchestrate 44 specialized agents sustainably. Read the full compound engineering guide and install the plugin.—Kaushik Viswanath Was this newsletter forwarded to you? Sign up to get it in your inbox. I spent three months trying to make agent swarms work. The idea of multiplying myself by coordinating multiple agents at the same time was a compelling pitch as the sole engineer building Every’s AI email assistant, Cora. If I could summon a fleet of AI agents, let them coordinate, and watch them produce work no single agent could match, it would relieve some of my overwhelm. I tried everything to make it work—Claude Code teams, agents dispatching tasks to other agents, orchestration setups where a lead agent managed a pool of workers. Many iterations, many burned tokens. But more agents didn’t make me faster. I’ve run parallel Claude Code sessions for months, which works when each agent has a clear task, and I’m directing the work. The swarm experiment was different: agents coordinating with each other, deciding what to work on, producing output I hadn’t shaped. When 10 of them finished simultaneously, I had 10 results to evaluate without enough context to know which ones I could trust. AI agents don’t have a speed limit, but the person managing them still does. I kept looking for a smarter orchestration layer—a better protocol or a tighter framework that would filter the output and tell me which result to trust. Then I stopped and looked at what was really doing the work. It was something I already had—a folder. A project folder with a CLAUDE.md/AGENT.md (the file that tells an AI how to work in your project), some skill definitions, and context accumulated through months of compound engineering—that’s an agent. The context that this folder gives an AI model makes the generalized model a specialist in whatever task or field you want it to excel in. I’m running 44 of these folders-as-agents across multiple projects now. Each one runs inside a specialized folder I’ve built and tested over months, and a dispatch layer I built on top does the routing between them. Here’s how it works. The agents hiding on your hard drive People hear “agent” and picture a Rube Goldberg machine—dozens of comically complex moving parts, each one triggering the next. But an agent is much simpler: a model with enough context so you don’t have to re-explain everything each time you open the chat. Here’s an example: All of Cora’s code lives in a project folder in the Every organization on GitHub. When I open that folder with Claude, Claude can see the code and the structure. But it doesn’t know my way of working or what I care about, which is why the folder also includes a CLAUDE.md file. The file tells Claude how I name things and how I structure tests. That’s an agent—not a fancy one, but an agent nonetheless. Just by pointing the model at this folder, which contains some of my personality, knowledge, and taste, the model can be a specialist in my codebase. Claude Skills—files that give the model specific capabilities—are an example of this “folder as agent” structure. Before anyone called them “skills,” people were already writing markdown files full of instructions and dropping them into project directories. My ~/cora/ folder goes further: Conventions and standards: The CLAUDE.md covers Rails conventions, deploy workflows, and database patterns. Institutional knowledge: The docs/developer-docs/ directory holds accumulated knowledge that any new agent inherits automatically, including architecture reports, the email processing pipeline, and the assistant system design. Operational memory: The docs/runbooks/ and docs/investigations/ capture operational patterns built from real incidents. Specialized agents: .claude/agents/ holds specialists I’ve refined over months: reviewers, planners, and the assistant-component-creator. When I point a model at this folder, it starts working with everything Cora knows about itself. The reading order I give to every new agent that touches Cora is the following: Read CLAUDE.md first, then the architecture document, then the assistant system report, then the assistant’s prompt, then the component creator agent. My Cora repository serves as a living memory system: conventions, runbooks, and specialized agents all layered so any new model instantly inherits how Cora thinks and operates. (All images courtesy of Kieran Klaassen.) ~/cora-agent/, another folder, is a completely different agent, though it runs on the same model. (I mostly use Opus 4.6, but also like GPT 5.4 and Gemini Pro 3.1.) Where ~/cora/ builds features, ~/cora-agent/ runs the operation. It has no app code, so it can’t accidentally modify production code while doing operations work. Instead, it has skills for: Querying AppSignal to check for errors and performance problems across Cora’s live system Tailing Render logs to watch server output in real time and catch issues as they happen Pulling from a Postgres read replica—a copy of Cora’s database—so it can query user data without affecting the live version Reading Intercom tickets so it can connect customer complaints to technical problems Correlating GitHub deploys to production incidents, tracing a break back to the specific code change that caused it  .claude/skills/ directory is a cockpit—a single place where the agent can see and interact with every system Cora depends on. Each external system Cora touches has a reference file telling the agent exactly how to talk to it. Its bin/ directory has Ruby daemons (background processes that stay running continuously) running continuously: a scheduler, an inbox processor that triages incoming issues automatically, and a health monitor that restarts stalled processes. Three postmortems live in docs/postmortems/. A dense deploy journal covers every Cora pull request from March through April. Just by changing the folder and not the model, I have a different agent. Point Opus at ~/cora/ and it’s a Rails engineer. Point it at ~/cora-agent/ and it’s an ops engineer who knows our incident history, our service topology, and exactly which Slack channel to notify. A morning with 44 agents Once you realize the folder is the agent, you can run as many as you want. I have a handful of specialized folders, but 44 agents running across them at any given time—several working inside ~/cora/ simultaneously on different tasks, others monitoring production from ~/cora-agent/, others handling orchestration. It’s the same folders, just different jobs happening in parallel. The obvious question is: Who manages 44 of them? For months, the answer was me, manually. I’d open a terminal tab, navigate to a project folder, start a Claude Code session, give it a task, open another tab, and do it again. I was the dispatch layer—keeping track of which agent was working on what, which tasks had finished, and which were stuck. It worked when I had five agents. At 10, I started forgetting what was running where. At 44, it was unsustainable. Bugs I knew were easy to fix sat untouched for days, and pull request reviews piled up. So I built a dispatch layer: a system that sits above the folders and routes work between them. There’s a Ruby daemon that watches a directory for spawn requests. When I ask it to orchestrate a task, it creates a lead agent, the lead breaks the task into subtasks and writes each one as a file, and the daemon picks those files up and spawns worker agents in the right folders. Workers report back by writing files. The daemon checks status every 60 seconds. There’s no need for custom networking or agent-to-agent protocol. As a result, I went from manually juggling terminal tabs to managing my entire engineering surface from one place. I interact with the dispatch layer through slash commands in Claude Code. Two do most of the work: Two commands that replace 20 terminal tabs The morning briefing: I type /hey into Claude Code to get a status report. For each project, the system checks what was completed, what errored, what’s blocked, and any new high-priority issues. This one command yields a complete picture of what needs my attention across Cora’s main codebase, the ops environment, and the orchestration system. The kickoff: I type /orchestrate to kick off a task—for example, /orchestrate “Fix GitHub issue #1765.” The system creates a lead agent, which breaks down the task and spawns workers in the right folders. Each worker inherits that folder’s full context—its CLAUDE.md, agents, and accumulated knowledge. Workers do the work. A pull request appears, and I review it. With the /orchestrate command, a lead agent delegates to specialized workers across contexts, and you watch the entire system think in parallel. Every agent gets a pane I can watch live in tmux (a terminal tool for running multiple sessions at once). A dashboard shows me a live map called an agent tree that shows every agent and its status—working, waiting, done, or error. Pull requests and GitHub issue comments arrive for asynchronous review. I process results when I’m ready, instead of when agents finish their tasks. The whole thing runs on a Ruby daemon with file-based messaging. The dispatch layer is not sophisticated infrastructure. The sophistication lies in the folders underneath it—each one a specialist built through months of learning from work. Anthropic’s own research backs up why this pattern works: An Opus lead agent with Sonnet sub-agents outperformed a single Opus agent by 90 percent on research tasks. But they also found that multi-agent systems burn 15 times more tokens than single-agent setups, and that most coding tasks have fewer parallelizable steps than research, which makes them harder to split across agents. The dispatch layer doesn’t replace me—it handles the tracking so that I still decide what work gets done and where it goes. What breaks at scale (and why you can’t vibe orchestrate) That morning walkthrough makes it sound smooth, but it isn’t always. The encoding bug was my favorite disaster. For weeks, agents would randomly crash mid-task, and the error message gave no helpful explanation. I dug through logs, checked API responses, and tested network configurations. The culprit turned out to be em dashes and curly quotes—characters from text I’d copy-pasted into prompts. My daemon was running US-ASCII encoding, which only recognizes plain English letters, so those special characters were crashing it. The frontier of AI-assisted development is full of problems like this: genuinely dumb, and shockingly hard to find. The harder ongoing challenge is context drift. With dozens of agents, some end up running stale versions of tasks or duplicating work that another agent already finished. The list of active agents grows, but I have to do manual cleanup. I don’t have a good automated solution yet—I prune regularly and accept that some tokens get wasted. This setup also entails a sneaky issue: agent stalls. An agent makes too many API calls too fast or gets stuck waiting for input, and its status stays on “working” indefinitely. You don’t notice until you check, and when you’re managing 44 agents, you don’t always check. These failures point to the biggest lesson I’ve learned: You can’t vibe orchestrate. Just like you can’t vibe code—you need plans before you start building—and you can’t vibe fix when things break in production, you can’t hand a folder to the dispatch layer and hope for the best. When I start a new project, I don’t immediately hand it to the dispatch layer. I set up the folder, build the agent, establish the flows—the compound engineering loop—and use them myself until they’re predictable. Only when I trust a flow do I hand it off to the dispatch layer and stop watching. If you skip this step, you’ll have agents opening pull requests for work you’ve already finished and filing duplicate issues. The order of work is key: Build it, use it, trust it, and then orchestrate it. Your folder is already an agent I started this whole experiment trying to build a swarm. I ended up with 44 folders, each one with specialized context built through months of work, connected by a dispatch layer. It’s not what I expected, but it works. You also have the building blocks to create the same thing. If your project has a CLAUDE.md and some files in .claude/, you have an agent. You just haven’t been treating it like one. Here’s an experiment for you: Look at your project folder. Is it a generic setup or a specialist? If it’s generic—if your CLAUDE.md is boilerplate you copied from someone’s blog post—spend 30 minutes making it yours. Add your conventions, your patterns, your opinions about how code should be written. Then try running two agents in separate git worktrees (separate copies of your codebase so they don’t interfere with each other) and notice where you slow things down. That’s where the dispatch layer needs to go. I’m one step into that myself. I’ve moved from manually orchestrating—opening terminal tabs, navigating folders, and starting sessions—to having a dispatch layer do that routing for me. The step after this is already arriving. Anthropic just launched Claude Managed Agents—a hosted service that handles sandboxing, state management, and tool execution so developers can focus on what their agents do rather than how to keep them running. The folder-as-agent pattern makes that kind of managed autonomy possible: a trusted, specialized environment the model can run inside without you holding its hand. The industry is spending a lot of energy on autonomous swarms. I spent three months there too, and found that for now, the answer is still just a folder. Go further Read Kieran’s comprehensive guide to compound engineering Install the compound engineering plugin Watch the recording from Kieran’s last compound engineering camp 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. Thank you to Katie Parrott for editorial support. Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$9,000+ in credits for the tools we build with. Subscribe --- # Vibe Check: GPT-6 Astra Is a Big Upgrade With Some Bad Habits Astra is worth the fuss. We’re still keeping Fable. For weeks, OpenAI has been previewing Astra’s math results and explaining why its cybersecurity capabilities required stronger safeguards. Now GPT-6 Astra is out, billed as the company’s most intelligent model yet. Astra gave us writing, consulting work, and designs we wanted to keep. Dan Shipper is enthusiastic about its computer use—operating software through the interface. But a beautiful first result isn’t always a finished product. Fable 5.1 still did better on the complicated apps we tested. Astra also had a habit of adding copy and interface elements the task didn’t need. We get into the successes and frustrations in our Vibe Check, including: The first draft of the review itself, which Astra wrote in one shot and Dan thought I (Katie Parrott) had written. Mike Taylor’s AI training curriculum, built from employee interviews and close to the course he wanted to teach. Kieran Klaassen’s cozy island, which came with a guided-breathing exercise he hadn’t asked for. Read the detailed comparisons and how the team’s findings change what we’d hand to Astra next. We’d try it for writing, consulting work, and visual prototypes. For a complicated product, we’d keep reaching for Fable 5.1. Read the Vibe Check Join us tomorrow at 12 p.m. ET for our latest camp, How We’re Working Right Now: Fable 5.1 and GPT-6 Astra. We’ll show how we’re using both models and answer your questions. The camp is for paid subscribers only. Upgrade to join the camp 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. Want to sponsor Every? Click here. Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$9,000+ in credits for the tools we build with. --- # 🎧 How an Every Staff Writer Developed Compound Writing Hello! I’m Kaushik Viswanath, the new managing editor at Every. In my first week here I’ve had the pleasure of getting to meet much of the Every team, including staff writer Katie Parrott. I couldn’t have asked for a better introduction to her work than the latest episode of AI & I, in which she’s interviewed by Every head of consulting Natalia Quintero about how she developed Compound Writing—a sophisticated approach for using AI as a writing partner.—KV When Katie Parrott was laid off from her job as an editor and ghostwriter at a crypto firm in 2023, she couldn’t afford a career coach. So she signed up for a $20-a-month ChatGPT subscription instead–a decision that turned around her career, and nearly everything else, including her mental health, and the way she approaches writing. Two years later, the Every staff writer has turned that process into an open-source plugin that teaches other writers to think, draft, and edit the way she does. On this episode of AI & I, Natalia Quintero talks with Katie, staff writer at Every, about how that improvised habit became Compound Writing, the codified writing system—and the plugin behind it—that’s the subject of Katie’s latest guide. It’s a conversation about what happens when you feed a model good ingredients instead of clever prompts, borrow the taste of writers you admire, and let AI handle the grunt work so you can fall back in love with the page. Watch on X or YouTube, or listen on Spotify or Apple Podcasts. You can also read the transcript. Here are the highlights: She turned to ChatGPT because she couldn’t afford a real career coach. After a layoff she found traumatizing, Katie turned to ChatGPT to think through her next move. It didn’t hand her answers so much as help her find her own: “Clarity, it turns out, doesn’t arrive gift-wrapped from a digital assistant or even a human coach,” she wrote in the essay that came out of the experience. “It’s something I had to dig out for myself, question by question and prompt by prompt.” Good writing starts with good ingredients, not clever prompts. Long before “context engineering” had a name, Katie was feeding ChatGPT the same foundational documents she’d built as a content marketer—audience personas, brand positioning, competitive differentiators—before she ever touched tone or word choice. That groundwork let her take on absurd freelance workloads: In a single two-week stretch, she wrote eight blog posts, three e-books, and dozens of social posts across LinkedIn, X, and Instagram. “The inputs are really what makes the writing unique,” she says. “The model already knows commoditized information—that’s not useful or interesting.” Writing with AI made her fall in love with writing again. For years, Katie says, writing felt like “such a slog”—she spent so much energy just assembling sentences that she couldn’t focus on what they actually said. Handing that grunt work to AI freed up the bandwidth for harder, more interesting questions. “Now with AI, I have the energy left over to spend more time wrestling with those harder, bigger-picture questions,” she says. “It’s brought back a feeling of exploration and discovery, both with the tool and with my own brain.” She calls it compound writing—and now it’s a plugin anyone can use. Ported from Kieran Klaassen’s compound engineering plugin, Katie’s compound writing system walks any writer through the brainstorming, outlining, drafting, and editing steps she uses herself, including review “skills” modeled on writers she admires—one based on Kurt Vonnegut’s rules of story structure, another on Alfred Hitchcock’s principles of suspense. Her thesis: Access will matter more than capability. Ahead of her talk at Thesis, Every’s conference on November 5, Katie warns of the risk that AI’s gains will compound only for those with the time and resources to experiment with the technology. “A much more compelling vision for an AI future,” she says, “is one where everyone is able to come along for the ride.” Timestamps: 0:00 A first look at Compound Writing 0:49 Meet Katie Parrott 1:27 Turning to ChatGPT after a layoff 6:28 How an AI conversation helped Katie say yes to Every 8:11 Becoming a one-person content agency with AI 11:16 What goes into Katie’s AI context files 15:43 Why good AI writing needs your research and experience 18:21 How AI made writing fun again 21:02 AI’s value beyond productivity 23:45 Using agents to tackle emails, appointments, and life admin 27:05 Inside Katie’s Codex career coach 32:15 Compound Writing: turning feedback into better drafts 38:58 Writing lessons from Vonnegut and Hitchcock, built into AI 42:45 Catching security flaws in AI-generated code 44:49 Who gets to benefit from AI? 46:52 Closing thoughts 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. Kaushik Viswanath is the managing editor of Every. 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—$9,000+ in credits for the tools we build with. Subscribe --- # Vibe Check: Fable 5.1—Anthropic Is So Back (Again) Anthropic is so back. The company just released Fable 5.1, the successor to the model we called the best coder in the world, Fable 5. After lackluster reception for its last two releases, Sonnet 5 and Opus 5, the new model had us all wondering where the next Anthropic release would fall. Bottom line: it’s a great model. It handles the big coding jobs that made the original Fable worth using, in language you can understand rather than needing a translator for Claudeish. Cora general manager Kieran Klaassen replaced the original Fable. Every’s head of evals Mike Taylor sends it his new projects. I (Katie Parrott, staff writer) now draft with it after finding Fable 5 too slow for writing. Every cofounder and CEO Dan Shipper moved his coding tasks over, though Codex remains his day-to-day workspace. The full Vibe Check shows what changed, including: Whole projects from one prompt. Kieran Klaassen rebuilt a working version of Proof, Every’s document editor. Mike built a simulated town of 25 AI characters with memories, daily routines, and conversations. Comparable agent results on about half the tokens. Spiral general manager Marcus Moretti tested its ability to power our internal Every agent against Opus 5. Fable 5.1 finished the work in about 60 percent of the time. Better long-form writing, weaker compression. It outperformed every model we’ve tested on writing a compelling introduction, but its X posts landed near the bottom of the models we’ve tested. More output than the brief allows. A request for eight to 12 exact quotes produced 43, including quotations missing from the source. At the highest effort setting, long-running sessions sometimes ignored requests to stop. Read the Vibe Check Can’t get enough of Fable 5.1? Join us for a special Fable 5.1 Camp this Friday, September 4 at 12 p.m. Eastern to hear more about our experience, plus share impressions and best practices with other Every subscribers. Register for Fable 5.1 Camp. Win more deals by shipping reliable webhooks for your customers Your customers want their agent workflows to be event-driven, so you’re losing deals if your API lacks reliable webhooks. Webhooks lead to deeper product engagement, stronger retention, and integrated workflows, but retries, ordering, and replay protection are harder than they look. Svix authored Standard Webhooks, the spec adopted by Anthropic, OpenAI, Google, Twilio, and Etsy. If you homebrewed your webhooks and are getting pinged at 4 in the morning for failed deliveries, this is for you. Svix handles everything: retries, idempotency, security, and compliance. Qualified startups get $12,000 in free credits—$50,000 if you’re a YC company. Get started for free Want to sponsor Every? Click here. Katie Parrott is a staff writer at Every. You can read more of her work in her newsletter. Dan Shipper is the co-founder and CEO of Every. You can read more of his work in Chain of Thought. 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—$9,000+ in credits for the tools we build with. --- # What We Learned From 15 Hours of Anthropic Certification Training Was this newsletter forwarded to you? Sign up to get it in your inbox. Fifteen years ago, I took my first online course on edX, a learning provider founded by MIT and Harvard. At the time, edX was cutting edge and I binge-watched a ton of courses. (I still love and recommend Michael Sandel’s course Justice, but that’s beside the point.) I found myself recalling that time when I took four courses earlier this summer to earn our team Anthropic certification. After working closely with the Anthropic team for more than a year as alpha testers of unreleased models, we wanted to take our partnership farther. I went into the certification process curious about what level of instruction they’d provide and how they’d define their own tools. What I came away with was new insight into the state of AI development and industry standards right now. AI development is still moving at a breakneck pace, but new releases no longer upend our work the way they used to. Anthropic’s Opus 4.5 and OpenAI’s GPT-5.5 marked a turning point as the models could reliably perform the tasks we provide, giving each subsequent release a dependable base to build on. The fact that Anthropic can even release a training course for its foundational tools like Claude Code and agent skills is a milestone for the AI era. (This time last year, I was constantly reworking the curriculum for our training sessions every three to six weeks when a new, more capable model came out.) More stable models have allowed people to build AI workflows around their individual roles and careers. Anthropic’s training takes the opposite tack—it teaches foundational concepts. But the greatest value of these courses may not be sparking new ideas for the tools we use day to day. Instead, they offer an opportunity for the industry to align around terms and definitions—a heavy lift on its own. Shared reference points, not playbooks To become Anthropic certified, companies are required to take four courses: Introduction to Agent Skills, Building with Claude API, Introduction to Model Context Protocol (MCP), and Claude Code in Action. The full course load takes roughly 10 to 15 hours per person. Each online training involves reading through text-based how-tos interspersed with short videos and sample exercises, much like the many online courses I’ve taken previously—including in those edX days. None of the four courses delivers a playbook for transforming workflows with AI—mapping workflows, identifying tasks ripe to streamline with AI, and codifying tasks into skills. Instead, they offer common definitions: This is what Anthropic says a skill is; this is what an MCP is; this is how an API works. Definitions may seem like a starting bid for a training, but they are critical when you’re creating the foundation for tools that you want hundreds of millions of people to use, which Anthropic is—this certification is literally AI 101. If Anthropic’s definition of an MCP diverges from an individual company’s, that difference could hurt effective AI implementation. Having a shared language is important when we’re still figuring out AI adoption as an industry. I felt the benefit myself. I’m not often building MCPs, so despite how often we use them at Every, my understanding only clicked into place when the course walked through the endpoints and logic underneath them. The training also gave our team a shared reference point. Getting roughly a third of the company to take this course catalyzed a conversation internally about how we learn. While the training is good, the Every team consensus is that Anthropic’s documentation, a publicly available collection of guides and resources for common use cases, is much better. If you really want to understand how Claude works, skip the videos—the documentation is the gold standard. One-size-fits-all training for a rapidly specializing field While the pace of change at the model level has slowed, the user experience of the software around AI models is changing faster than ever. Unfortunately, the courses reflected that. The Building with Claude API course uses a Sonnet model that’s no longer available in the API, and the MCP course doesn’t mention Anthropic’s own MCP builder skill. I don’t mean that as a criticism of Anthropic. It’s a symptom of how fast things are changing, and an occupational hazard when trying to capture a still-developing process for educational purposes. The courses also don’t take your role or experience level into account, or assess what you already know before moving into the material. Whether you’re a CFO, an engineer, or an intern, your experience working through certification is identical. This feels like a missed opportunity when AI is already very good at personalizing content to a viewer. But the bigger issue is that AI adoption has become increasingly specialized: The tools and workflows I use as an AI implementation leader look nothing like those of an engineer and or a hedge fund manager. The courses don’t account for that shift—none included examples grounded in actual workflows. A training built for hedge fund managers, for instance, could show a skill applied to a financial model. Instead, Anthropic has built a training program general enough to serve everyone—and that might explain the split in experiences across the 10 people on our team who went through the courses. Some found the selection of courses puzzling. Mike Taylor, head of evals at Every, thought the Building with Claude API course was long, technical, and, in his view, only relevant to developers. That sits oddly with the fact that most of the opportunity for AI tooling education is with non-technical people. “MCPs were already touched on in the API course, and you don’t need to know much about that unless you’re building one yourself. Even the developers I know aren’t building their own MCPs,” Mike says. A few like Becky Isjwara, head of social media at Every, found the certification training in general largely unnecessary. She has previously built and shipped usable web apps through vibe coding only and didn’t see how more specific technical information would change her results. “I think it just proves that anybody can code if they want to get their hands dirty and start building stuff,” she says. “You don’t need technical knowledge to ship anything.” By contrast, Yash Poojary, a growth engineer at Every, finished the API course and immediately proposed we build it into onboarding because it was so helpful. “There’s useful information for anyone going deeper or meeting the material for the first time,” says Lee Knowlton, an engineer. Already knowledgeable about the technical terms, he benefited from peeking under the hood at how Anthropic thinks about system design and performance. Plus, Lee found the section on prompt evaluation systems more compactly explained than anything he’d seen elsewhere. I myself learned a lot about MCPs. A valuable-enough training with more value still to come The courses haven’t fundamentally changed how we run the consulting practice, nor is it something I’d recommend to the time-poor executives we work with. But that’s less of a judgment on the quality of the courses and more of a description of where the technology is at. And most of the Every team still said they were glad to have taken the required courses. We now have a shared and in-depth understanding of how the labs define the key tools we build with every day. The training gave everyone a common vocabulary around AI’s core tools—and made the whole thing feel less intimidating. That’s exactly what the courses excel at and what makes AI education worthwhile even for a fast-moving industry. By that measure the Anthropic certification process succeeds. It just doesn’t go further than that, and right now, maybe no one can. Natalia Quintero is the head of consulting at Every. You can follow her on X at @NataliaZarina and on LinkedIn. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn. Thanks to Tom Matsuda for editorial support. Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$9,000+ in credits for the tools we build with. Subscribe --- # Our Agents, Ourselves Hello, and happy Sunday. When OpenAI folded Codex into ChatGPT in mid-July—in a move known as the merge—the coding tool became a general-purpose workspace, and the setup most knowledge workers had learned changed. So Katie Parrott rebuilt our guide from scratch: ChatGPT for Knowledge Work is a complete walkthrough of the merged app—16 workflows from the Every team, recast for what now lives in Chat, Work, and Codex, plus the new goals, projects, and scheduled tasks. And companies have the same problem, only bigger. In early June, Natalia Quintero and Mike Taylor answered questions from 400 executives on rolling out AI, then wrote up the 33 they couldn’t get to live for attendees. We’re sharing that Q&A publicly for the first time here.—Kate Lee Was this newsletter forwarded to you? Sign up to get it in your inbox. Knowledge base “Our ChatGPT and OpenClaw Guides Just Got an Overhaul” by Katie Parrott/Guides: Our Codex for Knowledge Work guide from May and OpenClaw guide from March got a full rewrite. Codex for Knowledge Work is now ChatGPT for Knowledge Work, updated for the merged app; the OpenClaw guide rethinks when a personal agent is worth running, and why a shared Every Agent may be the better call. Read these to update your ChatGPT and OpenClaw setups. “33 Questions Executives Ask About AI—Answered” by Natalia Quintero and Mike Taylor: Natalia, Every’s consulting head, and Mike, our new head of evals, answer 33 questions from 400 executives on how to adopt AI, covering strategy, winning over skeptics, tool selection, governance, and restructuring teams. Read this to see our advice to executives rolling out AI. “Benchmarks Don’t Know Your Job” by Katie Parrott/Context Window: Companies spend millions on AI but rarely test whether a model does their own work better than a cheaper one would. Our answer is KateBench, a copyeditor trained on 30,000 of Kate Lee’s edits, which shows how a high acceptance rate can still hide the edits a human has to redo. Also inside: a counterpoint to Andreessen Horowitz’s Olivia Moore on whether diminishing returns make cheaper models like Fable good enough; Cursor’s rebuilt Git hosting, and two new reliability benchmarks; the six-agent crew that tells Every designer Tyler Nishida’s family when there’s enough solar power to run the dryer; and links worth a click. “The Case for Cloning Your Coworkers” by Laura Entis/Context Window: Companies are starting to clone their coworkers—capturing the judgment of the people they depend on as reusable AI skills, a project Every is running on its own team. Also inside: a discussion of investor Stanley Druckenmiller admitting he used AI on a Wall Street Journal op-ed; Arielle Shipper’s self-improving Codex skill; a fresh batch of Thesis Statements from frontier builders; a signal on the enterprise opening for open-weight models; and the daily driver on which models the team is reaching for this week. Plus this week’s AI & I: Walleye Capital CEO Will England on why AI use is mandatory for his 400 employees. 🎧 🖥 Listen on Spotify or Apple Podcasts, watch on X or YouTube, or read the transcript. “I Tried the AI Model Built to Fix AI Writing” by Katie Parrott/Working Overtime: Katie tested Deft, a new model froma lab that pins the sameness of AI’s prose on how models are trained, not what they know. The output was genuinely less predictable, but also dense and prone to inventing facts. Read this to understand why AI writing all sounds the same and whether a new model can fix it. Thesis Statements Read seven more predictions from people at the frontier in Thesis Statements, a collection of specific, contestable claims by builders and thinkers about the future of great human work with AI. To work with AI, we’ll grow new senses by Alice Albrecht, AI researcher and founder The AI revolution will take so much longer than anyone is predicting by Gagan Biyani, cofounder and CEO of Maven The best businesses will use AI to revolutionize their companies, not automate them by Sam Gerstenzang, partner at Boulton and Watt The best leaders will focus on the messy work of unpredictable humans by Kit Krugman, chief people officer at Altana Offline devices will be like going to the gym for your brain by Craig Mod, writer and photographer Your AI tools will feel like part of your body by Yohei Nakajima, cofounder and general partner of Untapped Capital The minimum viable product will be for one person—or even one agent by Matt Van Horn, CEO and cofounder of June To turn these ideas into action, join us at our inaugural Thesis: 2027 conference on November 5, 2026. From Every Studio Monologue shows you it’s listening, right where you type Monologue, Every’s dictation app, released version 1.5.0 for Mac this week, with a new feature: the Dot, a small indicator that sits next to your text cursor, moves while you speak, and shows when Monologue is transcribing your words. If you move to another app mid-recording, the Dot follows your pointer so you can still see it. When you come back, it returns to where you started. When you’re not recording, it gets out of the way. After updating, choose “Try the Dot” to turn it on. You can hide it for a while, switch it off in particular apps, or go back to Classic. The release also fixes a problem for anyone using a non-QWERTY layout. Monologue used to paste your words by pressing Command-V, which isn’t the shortcut on those layouts, so dictation would enter the wrong thing or nothing at all. Monologue now asks your app to paste instead of faking the keystroke. Plus, notes recordings can now cap themselves at anywhere from 30 minutes to three hours. You can export a voice note’s original audio. Home is now called Dictations. Download or update at monologue.to. Alignment Proof indigestion. Terence Tao, one of the greatest living mathematicians and someone I have written about at length in Every, has concluded that his field faces a strange new problem: too many mathematical proofs. Normally, this would be exciting news and leave the optimists hoorah-ing for abundance. Mathematics has generally faced proof scarcity and depended on a few geniuses who painstakingly, or through divine inspiration, figure out what is true and what is not in our universe. More proofs should mean more progress. But AI is now generating more apparently correct proofs than mathematicians can verify, either because they cannot follow them or lack the bandwidth. Tao calls this “proof indigestion”—a backlog of proofs whose central ideas have yet to be extracted and made useful to humans. If this continues, a growing share of mathematical work will involve verifying and explaining proofs to others after AI finds the results. Recently, Tao spent several days digesting an AI-generated proof of Sendov’s conjecture, a longstanding problem about the roots of polynomials. Lech Mazur had produced a proof formalized in Lean, software that verifies proofs. The proof passed—all 90,000 lines of it—but was barely understandable to a human. Tao worked through it with AI, pen, and paper, and found the core idea. His version ran to about 15,000 lines and was, in his words, “remarkably elementary,” because it used surprisingly basic tools for a problem that had resisted experts for many decades. To make the AI proof useful, Tao had to turn it into something another human could understand, explain, and build on. That shows how the division of labor between humans and machines may change and how our job will be to translate the products of an alien intelligence into knowledge the rest of us can comprehend. The German mathematician Carl Friedrich Gauss called mathematics “the queen of the sciences” because every other STEM field is built on the language of mathematics. AI may soon generate materials and drugs that work before anyone understands why. I used to wonder what would happen if an alien superintelligence plopped down on Earth and handed us its scientific secrets, and vanished. I assumed we would catch up in no time, without having to discover everything ourselves. Proof indigestion suggests the opposite. We may be able to verify that the alien’s answers are correct and even use them, while spending years trying to understand why they work.—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—$9,000+ in credits for the tools we build with. Upgrade to paid --- # 33 Questions Executives Ask About AI—Answered Natalia Quintero, who leads Every’s consulting practice, has spoken with more than 100 companies about AI adoption, including the New York Times and the hedge fund Walleye Capital. In June, she and Mike Taylor—now Every’s head of evals practice—hosted a live webinar for 400 executives on how organizations can adopt and implement AI without stalling out. More questions came in than they could answer live, so afterward they wrote up 33 of them—covering strategy, winning over skeptics, tool selection, governance, and how to restructure a company for an AI-native future. We sent that document to the webinar’s attendees at the time and are making it public for the first time here.—Kate Lee When you put a room full of executives in front of two AI consultants and let them ask anything, you learn about where organizations are stuck with this technology. Here are all the questions that came up on our live session on June 2—from how to get skeptics on board to keeping context fresh. Every Consulting works with tech and finance teams to implement AI across their workflows, from strategy to training to building the actual tools. Strategy and organizational transformation Q: How do you get teams to think bigger about change? Not just getting the work done faster, but rethinking how the work is done? A: Give your most AI-curious staff permission to build ambitious projects. It’s easier to raise the ceiling than the floor. It’s easier for one AI-fluent person to create 10 good skills and do 10 times the work than it is to get 10 people to each create one skill or double their output. Once that’s in place, set a vision, designate AI champions, prove out high-value skills, then scale. Q: What does a good vision for AI adoption look like? A: AI is a tool, not a strategy. A good vision applies AI to your company’s strategic roadmap and allows you to tackle parts of it that were impossible before. For example: customer service. There’s effectively infinite demand for it, and it’s too expensive to staff the phones enough to get wait times down to a few minutes. Even then, the person that your customer talks to might not have the context the best customer representative has. AI is a great leveler here. It makes it cheaper to serve every customer quickly, it gives every representative full context by allowing them to search for it live, and it can pre-emptively answer questions before anyone gets on the phone. That’s what a good vision looks like: ambitious and finally affordable because of AI. Q: Do you need to convince skeptics? How do you get them over the hump of seeing value in adopting AI? A: Rather than focusing efforts on convincing skeptics, highlight AI champions. When AI champions, often skeptics’ own peers, demonstrate how they are getting value from AI tools, others start doing it out of practicality. Pair that with demos of new AI tools or skills that are relevant to your teams. I’d also encourage side projects. People with side projects are much further ahead on AI because they can take bigger risks than they can at work, by using tools that aren’t on the approved vendor list, and by pushing the limits of what works. Previously, a manager might feel uncomfortable about that. Now, I’d be disappointed if an employee didn’t have a side project, because it means they don’t have the space to experiment, play, and take bigger risks. Q: Is there a tension between using AI for productivity and using it to pursue bigger ambitions—and how do you think about the balance? There are two kinds of productivity: doing what you already do faster, and doing things you otherwise wouldn’t be doing. That second one is vision. You can’t only focus on productivity, but once you solve the productivity problem and automate what you already do, you’ll start looking for new things to do. Prioritize existing pain points for immediate value and place strategic bets on bigger products. Show it once, and it runs the process from then on Walk a Bot through a workflow the way you’d walk a new hire through it: the steps, the exceptions, the part where you check the invoice against the PO. It remembers, then runs the whole thing on its own, in its own browser, on its own computer in the cloud. Onboarding, reconciliation, outbound, release notes: pick the process nobody on your team wants to own and hand it over. Grok Bot, from the team behind SpaceXAI. Teach your first Bot Want to sponsor Every? Click here. AI fluency, training, and ways of working Q: What is AI fluency? What are the levels of AI? A: We think of them as these eight levels. Most people are in the first couple of levels—they use ChatGPT, or they co-work with AI using Gemini in Docs or Claude alongside Excel. Level three, agentic, is where knowledge workers are moving toward. Many are leveraging Codex, Claude Cowork, and Claude Code and using these tools more agentically. In order to do that, they need to adopt skills, and they need to learn how to work with agents and run multiple tasks at a time. Above that, it’s largely experimental. Engineers are way past the early stages of AI adoption—sometimes running multiple calls at once, and getting into orchestration (around Level 8), where a manager AI manages other AIs. Q: What is the most efficient way for teams or a company to use AI together? A: By creating shared skills, shared examples, and shared standards. The company should not end up with 1,000 people maintaining 1,000 private prompt folders. Start by turning the best recurring workflows into reusable skills, then make those visible, editable, owned by someone, and accessible to everyone. Q: What works best when teaching non-technical users how to use AI? A: Do not teach AI in the abstract. Give people tools that they can use their real work and have them build something useful in the session. The aha moment usually comes when they see AI produce an artifact they recognize, like a briefing, memo, spreadsheet, review checklist, customer response, or project plan. Q: What are good early wins or simple skills? A: The best early wins are boring and frequent: doing meeting preparation, call summaries, document review, first drafts of marketing content, research briefs, triaging your inbox, quality control checklists, and turning messy inputs into structured tables. If the task happens every week, has a known output, and a human can review it quickly, it is a good candidate for automation with AI. Q: How do you encourage reuse instead of everyone inventing their own prompts? A: Make reuse a visible management habit. Have demo days, office hours, a shared skill repository, and clear owners for the best workflows. Q: Is there value in building a centralized hub for AI knowledge inside a company, or does information move too fast for that to work? A: I don’t think one centralized AI knowledge hub really works—every document starts going out of date the moment it’s published, and there’s no good way to identify what needs updating. People are also at very different stages: Someone might know everything about skills but be behind on MCPs. Articles are valuable precisely because they’re timely––they were news when they were published. To turn them into a hub, you’d need another layer on top to review the content and keep it up to date, which is very resource-intensive and probably wouldn’t satisfy people anyway, since everyone has different opinions on what matters right now. A hard problem to solve, and not a huge payoff. Q: What are you seeing in human resources, marketing, legal, and other non-IT teams? A: The use cases are often very strong because these teams do a lot of language-heavy, context-heavy work. HR can use AI for onboarding, policy drafts, employee communications, and benefits questions. Marketing can use it for briefs, segmentation, creative variations, and research. Legal and compliance can use it for first-pass review and issue spotting, but with stricter human review. Tools, platforms, and technical infrastructure Q: What about organizations that can’t build frontier-level AI? How do you handle implementation if you need to buy? A: In organizations where you can’t build your own frontier tools, you can still create skills and connect into the software you already have. Even if you can’t build your own model, you’re still better off customizing how you use AI rather than waiting for a third-party vendor to add AI features for you because these vendors are often months behind. Q: How do you manage the number of platforms available? Do you recommend HR leaders go to Claude Code? How do you handle constant switching? A: We tend to recommend that you select one platform. Switching is expensive—you have to renegotiate contracts and train staff, and there are practical barriers, such as the fact that skills written for Codex might not work as well in Claude Code, and vice versa. As long as the model is from Anthropic or OpenAI, you’re fine. Or go with a third party like Cursor or Copilot that has access to both, which can lower switching costs. This issue is not fully resolved, because engineers in particular want the best model available and will adapt their processes to get it. Q: How can AI review designs in Figma? A: There’s a Figma MCP. Codex also has a built-in browser and annotations that are really good—Codex can control the Figma app directly. That’s typically how we’d do it. Q: Is it worth constantly switching between AI tools to stay on the cutting edge? I don’t recommend constant tool-switching for novices. Being a month or two behind the frontier is absolutely fine. Unless you’re an AI engineer or very deep into this, you won’t get much edge from switching—and anything genuinely good gets copied by the other labs within eight to 12 weeks. Q: What do you know about implementing AI today that wasn’t obvious a year ago? NQ: To use AI effectively, you still need to provide clear instructions and guidance. Clear thinkers, strong writers, and subject matter experts with an eye for excellence are best positioned to get value from it. MT: How fast things would move, and it keeps accelerating. Also, that AI would still not be great at writing: I thought writing was nearly solved and code would take longer, and it’s been the other way around. I also assumed everyone would be managing lots of AI agents. Instead, the predominant use case is one AI agent everyone uses that’s good at routing different tasks. Governance, security, and risk Q: How does AI governance differ in a heavily regulated environment where regulators want transparency and explainability? A: AI actually gives you more transparency. If you’re implementing through Claude, activity logs are saved through the enterprise plan. You can use AI to analyze those logs and generate reports. So you can provide more transparency this way, not less. Q: How can business teams pursue AI automation without making IT feel bypassed? A: Make IT a design partner, not the department of “‘no.”’ The business team should own the workflow and the definition of success; IT should own access controls, system architecture, and security review. Different tools require different levels of scrutiny. An AI assistant helping someone write is a very different proposition from a system that can access company databases. Treating every use case as equally risky can make it harder to move forward. Using AI is about understanding the potential upside and downside risks, and IT is already a resource for that. It’s an evolving conversation to explain business outcomes and collectively decide which protocols make sense for the business. Q: Do AI pitfalls vary by industry? A: There are universal pitfalls. AI adoption doesn’t succeed when it’s not clear who owns the process, executives have weak fluency in these tools, the tools are scattered, and a company does not rethink its workflows. What changes by industry are the constraints within which the AI adoption must take place. Finance and healthcare have more compliance, media has more judgment and brand risk, engineering has faster tooling cycles. But the adoption problem is basically the same: People have access to tools before they know how to incorporate them into their work. Q: What’s the discourse around token economics? How do you weigh value versus cost? A: For a brand-new task, something you’re innovating on, or something you’ll only do once, use the best model. The best model is often cheaper even when it’s the most expensive per token, because it saves time correcting mistakes, lowers the risk of bad outcomes, and usually gets the answer right faster without self-correcting. So almost all of your work should run on frontier models. Then, when it becomes a recurring task you do again and again, offload it to smaller models using a framework like DSPy, prompt optimization, or hill climbing to keep it working well at the smaller size. Q: How should companies think about data sovereignty, cost control, and dependency on one model or vendor? A: Do not over-engineer this on day one. Pick a secure enterprise platform, get the workflows right, and keep your important instructions, skills, evals, and data layer portable where you can. If compliance or data residency rules make the off-the-shelf tools impossible, then build a harness. But custom infrastructure is expensive, so the reason to build should be a real constraint, not driven by aesthetic preference. Measuring impact Q: How do you measure collaboration, output quality, and value from AI adoption? A: There is no single metric. Measure the benefits of AI adoption at the workflow level: cycle time, the quality of the output, how many errors there are, how often things need to be reworked, user satisfaction like NPS, and business impact in terms of traditional cost-benefit analysis. Also track reuse: how many people use a shared skill, how often it is improved, and whether it becomes part of the team’s normal process. Q: How should teams evaluate AI workflow performance over time? A: Start with a baseline before AI: how long a task took, to what standard it was being performed, at what cost, and with what common mistakes or errors. Then track whether the workflow actually improves after AI is introduced. For important workflows, keep a small eval set of real examples and rerun it whenever the prompt, model, or tool changes. Otherwise you’re just trusting vibes. Knowledge and context Q: How do you keep your AI’s understanding of the company accurate and up to date—and who owns that? Everyone’s experimenting with memory and file-storage solutions. In practice, people are solving it by putting the right context into GitHub repositories, but I don’t think that’s a great solution. Microsoft has Windows IQ, and Google has its own MCPs for Docs, but this is still not well solved. Q: What are best practices for knowledge-management debt and stale context? A: AI exposes knowledge debt, and it does not magically fix it. We would avoid starting with a giant knowledge-base project. Start with the 10 to 20 sources that matter most for a workflow, assign owners, add freshness dates, and prune aggressively. Context is not a warehouse where you dump everything you might need––every document needs to earn its place or it could be hurting more than helping. Who owns AI? Q: What balance works best between a dedicated AI team and broad organization-wide enablement? A: You need both. A central AI team should set standards, handle security and vendor decisions, maintain shared infrastructure, and help build the first few examples. But the distinct business teams need to own the workflows. If the central team owns every use case, it becomes a bottleneck, and if everyone builds alone, you get sprawl. Q: How do you handle AI crossing the borders between functions and departments? A: This is one of the real management questions. AI attacks the boundaries in org charts because the work itself was never as cleanly separated as the chart made it look. I would not try to solve that abstractly. For each workflow, define the business owner, technical owner, risk owner, and human approver. That is usually clearer than trying to redraw the org chart first. Q: If you were institutionalizing AI at a 200-to-500-person organization from scratch, where would you start? A: Start with the executives. Get leadership hands-on enough that they understand what is now possible, then pick two to three teams with painful, repetitive, high-value work. Map the workflow, build one useful skill or agent, prove it works, and use that as the internal example. The mistake is trying to “roll out AI” broadly before anyone can point to a concrete workflow that changed. Q: Do executives usually know what the highest-leverage automations would be, or do they have blind spots? A: They usually know the business pain, but not what’s easy or hard to do with AI tools. The best process is to start with the company’s goals, then ask where work is slow, expensive, inconsistent, or bottlenecked by scarce expertise. AI opportunities tend to show up where there is a clear output, a lot of context gathering, and human judgment at the end. Every Consulting—how we work Q: What is the shape of an Every consulting engagement? A: It varies, but the pattern is usually: executive alignment, discovery calls, workflow mapping, AI champion selection, hands-on training, skill or workflow building, office hours, and handoff. Sometimes that is a half-day executive session; sometimes it is a multi-month implementation. The common thread is that we help people build tools that solve a pain point, instead of making them sit through them to listen to presentations. Q: How does Every’s consulting inform product work and offerings? A: Clients show us where the tools break, where people get confused, what workflows actually matter, and what kinds of skills get reused. That feeds back into our writing, our products, and our own internal systems. Q: How are you using AI in your own consulting and client-development work? A: We use AI across the whole process: preparing for calls, finding patterns across discovery interviews, drafting proposals, creating training materials, building client-specific skills, and testing workflows. We also have an agent, Claudie, who supports our consulting practice with day-to-day ops. Q: How do you avoid dependence when outside AI experts or forward deployed engineers drive early wins? A: Pair every external builder with an internal champion. The deliverable should not just be a working tool; it should include the skill files, the evals, the decision log, the operating instructions, and a colleague who can modify it. Otherwise you get a great demo and no organizational capability. Natalia Quintero is the head of consulting at Every. You can follow her on X at @NataliaZarina and on LinkedIn. Mike Taylor is the head evals 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. Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$9,000+ in credits for the tools we build with. Subscribe --- # Our ChatGPT and OpenClaw Guides Just Got an Overhaul Was this newsletter forwarded to you? Sign up to get it in your inbox. We talk about AI progress like it’s a race between models. That’s the part with version numbers, and what you argue about over dinner. But the model is only one piece. It reaches your work through the app you open it in, the files and tools you let it touch, the instructions you’ve saved from last time, and the person keeping all of that from going stale. Any of those can change your results as much as a new model would—sometimes more. We rewrote two of our guides this week. The models didn’t change. The infrastructure around them that governs their behavior and capabilities did. These guides are written as much for agents as for humans, so share them with your agent and ask it: “What can we learn from this that we can adapt for how we work?” Knowledge work has a home in ChatGPT now When we initially wrote our Codex for Knowledge Work guide, the idea of using a coding-agent interface for something other than coding was so new that even OpenAI hadn’t built a dedicated home for it. Now it has. Quick questions stay in Chat, longer assignments move to Work, and software jobs go to Codex. For knowledge workers who don’t touch code, the vast majority of your tasks can be handled by Work. We’ve retitled the guide ChatGPT for Knowledge Work and rewritten it around that new setup. The guide keeps its 16 workflows, but recasts most of them for Work. The update also covers several features that didn’t exist when we wrote the original guide: Goals: Type /goal to turn an objective into a persistent goal with a definition of done. Projects: Choose between ChatGPT projects, which keep cloud conversations, files, and instructions together, and local projects, which give Work or Codex access to a folder on your computer. Scheduled work: Use Scheduled Tasks for recurring jobs in Work and thread automations for longer loops in Codex. Browser access: The app’s built-in browser has its own signed-in profile. Choose Chrome when a task needs your existing sessions, tabs, or extensions. Read ChatGPT for Knowledge Work Most AI tools stop at the summary Research is the easy part. The work is everything after: the report drafted, the spreadsheet updated, the recap posted in Slack, the follow-up actually sent. Grok Bot’s Bots do that part. Each one runs on its own cloud computer, signed in to your CRM, your ATS, your inbox, clicking and typing through the same software your team already uses. Give a Bot a job instead of a prompt, then check the result the way you’d check a coworker’s. Built by the team behind SpaceXAI. Put a Bot to work Want to sponsor Every? Click here. Our OpenClaw recommendation changed Our first OpenClaw guide focused on the appeal of a personal agent. A Claw lives in your messaging app, connects to tools you authorize, and keeps doing recurring jobs without a fresh prompt. For someone willing to maintain it, that setup can still be unusually useful. The update adds what we learned from running Claws ourselves. A stronger model still can’t log in when a credential expires. It can’t notice that an integration broke last week, or that a job you set up months ago should’ve been turned off. Putting the agent on a server keeps it running—but somebody still has to keep its tools connected, its permissions current, and its memory from filling up wtih stale instructions. For now, that somebody is a burden. That maintenance load only grows as a company adds people, so we’re trying something different with the Every Agent. It lives in Slack, so the whole company shares one agent—but each person works through their own connections and own context. A personal Claw can still make sense if you have recurring work specific to you, want control over its tools and instructions, don’t need company context, and are willing to maintain it. The updated guide helps you decide whether that tradeoff is worth it, then explains where Claws tend to break and how to limit their authority. Read the updated OpenClaw guide 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—$9,000+ in credits for the tools we build with. Subscribe --- # The Case for Cloning Your Coworkers Was this newsletter forwarded to you? Sign up to get it in your inbox. Inside Every In which Dan plots to clone us all For years, Every CEO Dan Shipper’s goal was to automate editor in chief Kate Lee’s editorial judgment. The data was there—he had more than 30,000 of her historical edits—but the models weren’t good enough to create a copyediting agent that approached her abilities. That changed with the launch of GPT-5.6. Now, before I file an article, I run it through KateBench, a skill that copyedits based on Kate’s historical edits. Only then does human Kate review the piece, accepting, modifying, or rejecting the agent’s suggestions. Tracked changes in Google Docs catalog those decisions and any additional edits she makes, then Codex rewrites the skill so it compounds. (For more on how KateBench works, read staff writer Katie Parrott’s writeup on how engineer Jannik Jung incorporates feedback to improve its performance.) The Kate copyediting agent makes suggested changes directly within the Google Doc. (All screenshots courtesy of the author.) KateBench takes work off Kate’s plate. It also democratizes her expertise—anyone on the team can get a Kate-level quality pass for anything they’ve written. “It’s weirdly hard and specific to copyedit that well,” Dan says. “She’s the only one who can do it at her level, and now that’s not true anymore.” KateBench self-improves by incorporating data on edits that were accepted versus rejected. The obvious next step—at least if you’re Dan—is to build a version of KateBench for everyone at the company. That way, COO Brandon Gell’s sharp user experience (UX) feedback, head of operations Arielle Shipper’s logistical brain, and head of social Becky Isjwara’s finger-on-the-pulse social positioning can be packaged and made accessible to the rest of us. Meanwhile, Brandon, Arielle, and Becky are free to focus on the higher-leverage projects that can get crowded out by requests from colleagues. But UX decisions make for a messier dataset than copyedits: “One big thing we’re going to explore over the next couple months is which kinds of work can be treated this way,” Dan says. Packaging people’s expertise into skills could give them time back and remove bottlenecks. The first test: Mike Taylor, who is now head of our evals practice, is building DanLens, a skill that clones and compounds Dan’s marketing instincts and knowledge of Every’s customers so we can apply those insights without clogging his calendar. Your next teammate has its own computer Scout handles research. Olivia reads every contract. Talent Scout screens new creators before you’ve had coffee. They aren’t apps you open, they’re Bots you text, each one responsible for a specific job. Grok Bot, from the team behind SpaceXAI, gives every Bot its own computer in the cloud, already logged into the tools it needs and still working when your laptop is closed. You build the team once, then message it the way you’d message a coworker. Meet the Bots Want to sponsor Every? Click here. Discuss “AI is a fact of modern life. People will use it to assist in their work and their writing, including with research, checking grammar, editing and more.”—Paul Gigot, opinion editor at the Wall Street Journal, in a statement. On Tuesday, billionaire investor Stanley Druckenmiller confirmed that “of course I used AI” to write his latest opinion column in the Wall Street Journal, which criticized Treasury Secretary Scott Bessent’s bond buybacks. “I was a B student in English, but an A+ in economics,” he told the Journal. “These are my ideas and I’ve been speaking about them for over 15 years, as anyone who knows me knows. Would I prefer that I was a great writer? Yes, but that’s not who I am.” In contrast to other news outlets like the Financial Times, which has publicly banned its columnists from using AI, the Wall Street Journal came to Druckenmiller’s defense. “The question for us is whether what we publish from contributors reflects an author’s original argument, and if the author has the standing and credibility to make it,” Gigot’s statement continued. “In Stan Druckenmiller’s case, we have had a relationship with him for many years, and nobody can doubt that his op-ed is his genuine opinion.” The entire spectacle caused a minor firestorm on X over whether a byline certifies authorship or simply ownership of an opinion. For Mike, what matters is whether the idea is any good, not whether it was written by AI. If you ban people with Druckenmiller’s experience and expertise from using LLMs, “we might not get that post, and then we don’t know what he thinks,” he says. “So many interesting things happen to people who can’t write.” Skill share Compound your Codex use These days, Arielle works almost exclusively in Codex. When the agent makes a mistake, she 1) fixes the immediate problem and 2) prevents it from happening again with a custom self-improve skill. Whenever Codex returns an incorrect result, Arielle supplies Codex with feedback about where it fell short and what a better response would have been. After it has all the necessary context, she runs the skill, which reviews the initial output, interrogates what went wrong, and suggests a targeted edit to Codex’s instructions so the issue is less likely to repeat. Say Codex drafts a Slack message that doesn’t sound like her. The self-improve skill might suggest updating Codex’s operating rules to state: Before writing or sending a Slack message, always read the context of prior messages in the thread or DM so that responses are contextual and acknowledge what came before it. She treats such missteps as data to funnel back into the agent: “Why didn’t that work? And what can that teach me about working with these tools?” she says. Download Arielle’s self-improve skill to build the same feedback loop into your own Codex setup. Thesis Statements Last week, we launched Thesis Statements, a collection of specific, contestable claims from builders and thinkers on the future of great human work with AI. Today, we have seven more predictions from people operating at the frontier: To work with AI, we’ll grow new senses by Alice Albrecht, AI researcher and founder The AI revolution will take so much longer than anyone is predicting by Gagan Biyani, cofounder and CEO of Maven The best businesses will use AI to revolutionize their companies, not automate them by Sam Gerstenzang, partner at Boulton and Watt The best leaders will focus on the messy work of unpredictable humans by Kit Krugman, chief people officer at Altana Offline devices will be like going to the gym for your brain by Craig Mod, writer and photographer Your AI tools will feel like part of your body by Yohei Nakajima, cofounder and general partner of Untapped Capital The minimum viable product will be for one person—or even one agent by Matt Van Horn, CEO and cofounder of June If you want to help move these ideas from arguments into action, join us at our inaugural Thesis: 2027 conference on November 5, 2026. Signal An opening for open-weight models What happened: A popular narrative is emerging that we’ve hit diminishing returns on model intelligence for many tasks. Case in point: Fable is the most capable model on the market,but businesses aren’t using it much, according to spending data from Ramp. One month after launch, it accounted for 6 percent of the Anthropic tokens purchased by businesses and 11 percent of model spend. Why it matters: Fable doesn’t guarantee that customer prompts and outputs won’t be stored. Because of that security risk, many big enterprises are barred from using Fable, partly explaining the dampened demand. Another probable factor: Model intelligence has outpaced our ability to use it. Adopting the latest frontier model “was a complete no-brainer from a price and quality perspective,” Mike says—until Opus 4.8. For $70 an hour at full API rates, Fable broke that trend. Recent model releases haven't fundamentally changed how Becky works. Fable is still the obvious choice for ambitious projects—Dan used it over the weekend to build an end-to-end app that lets remote agents control his computer autonomously. But most of his work requires far less intelligence. “I get no relative gain from Fable on 80 percent of my knowledge work tasks—it’s slower and more expensive without being better,” he says. What it means. This creates an opening for open-weight models, which processed 29 percent of the tokens routed through Vercel’s AI Gateway in June, up from 11 percent in April. The volume accounted for less than 4 percent of spend, a sign companies are already routing high-volume work to cheaper models. If most people don’t need frontier capabilities, open-weight AI developers can focus on training a competent, user-friendly model “and people will start using it because it’s going to be 90 percent cheaper than Fable,” Mike says. AI & I: Inside the $10 billion hedge fund where AI fluency is a job requirement Hedge funds live and die on having an edge. AI provides one, so its use is mandatory for all 400 employees at the $10 billion hedge fund Walleye Capital. On this episode of AI & I, we’re revisiting our conversation with the fund’s CEO and chief investment officer Will England. An AI maximalist, England foresaw how the technology would absorb operational tasks, freeing up knowledge workers to focus on bigger-picture, often more abstract problems and decisions. Watch on X or YouTube, or listen on Spotify or Apple Podcasts. You can also read the transcript. Here are the highlights: England has wanted to automate his job since the GPT-3 days. Back in March 2023, England watched one of his analysts demonstrate how AI allowed him to get more done more quickly. From that moment England knew AI would fundamentally reshape work for anyone who “think[s] for a living,” starting with himself. “If you can have a tool that makes you more effective, it’s the same thing as hiring someone to replace part of what you were doing so that you can move on to the next task,” he says. “Your context level shifts up.” He views AI as non-negotiable. Eschewing it is like refusing to use the internet in 1995 because it wasn’t perfect. “That’s just dumb and something I can’t understand,” he says. “As a hedge fund, we should be ashamed to leave money on the table by ignoring tools that make us faster, smarter, and more effective.” And as the models improve, the pile of money compounds. Results > effort. England sent out a firm-wide email that opened with, “I used ChatGPT to write this email, you should be using it too, and be proud of it.” His larger point: AI speeds up and simplifies many necessary tasks, allowing him to focus on risk evaluations, data strategies, and other big-picture questions affecting fund performance. “People have this insecurity that if I didn’t put my blood, sweat, and tears into it that somehow it’s not real,” he says. “But at the end of the day, results are what matter.” 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 The daily driver The models the team is using this week Andrey Galko, engineering lead: GPT-5.6 Sol for quick tasks, Opus 5 for everything else. “It’s pretty reliable on extra-high/max reasoning and costs much less in usage limits.” Becky Isjwara, head of social: Opus 5 and GPT-5.6 Sol (high) for strategy and social analytics, with Sol delegating tasks to Terra. Recently, she’s switched more work back to Opus 5. “I’ve been finding GPT-5.6 Sol has gotten a bit more verbose and slow.” Tyler Nishida, engineer: Grok 4.6 for most things as he finds it strikes the best balance between execution and cost. “Fable and GPT-5.6 Sol in headless mode have been enough to save me when Grok 4.6 gets confused.” Arielle: GPT-5.6 Sol (medium) for most tasks, toggling to high for more analytical work. Dan: Yet-to-be-released models from Anthropic and OpenAI that he’s testing, alongside Fable and GPT-5.6 Sol. Willie Williams, head of platform: A mix of Fable, GPT-5.6 Sol (extra-high and medium), and Grok 4.6. 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—$9,000+ in credits for the tools we build with. Subscribe