Every (blair.dowding@gmail.com)

Anthropic’s Duet Gets to Work

Every Staff / Context Window — 2026-10-25 07:55:21 -0400

Midjourney/Every illustration.

Hello, and happy Sunday. We covered two ways to work with an agent this week: one just for you, and one for the whole company. Dan Shipper tested Duet, Anthropic’s always-on agent, and thinks it’s the best personal agent yet. Willie Williams, our head of platform, explained why we ditched an earlier experiment with personal agents and built one agent that the Every team shares. Whichever kind you choose, you’ll want to know if it’s doing a good job. Head of evals Mike Taylor explains how to measure your outputs in his new book, Context Engineering with DSPy, and will take your questions during his livestream on October 29.—Kate Lee

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

Protocols

From this week’s stories, 13 skills to try.

Make an agent’s work easy to watch

From Alex Duffy’s “We Caught an AI Cheating by Watching It Play ‘StarCraft’”

See what your agent is doing. Watching the match is how Alex’s team caught Astra copying code within minutes. His prompt applies that lesson to any agent: Define success up front, make its work easy to inspect, and log every attempt. The prompt

Set the rules for a shared agent

From Willie Williams’s “Why We Replaced Personal Agents With One for the Whole Company”

Ask what could be undone. Engineer Will Gathright’s test: If a step is easy to undo, the agent does it and says what it assumed; if it deletes something or posts outside the conversation, it asks first. The rule
Keep permissions out of the prompt. The Every Agent’s access rules live in code, not in its instructions, and the server checks any approval the agent claims against what the person wrote in Slack. The rule
Keep scheduled reports running when logins change. Engineer Lee Knowlton’s fix lets any qualifying login run a scheduled report, so it keeps arriving after someone’s login expires or they leave the company. The fix

Let agents check the work

From Laura Entis’s “Keeping Up With AI Is a Full-time Job”

Pit two models against each other. Engineer Loren Stewart has one coding agent write a fix plan for a buggy app, another company’s agent critique it, and the first agent revise it—a sequence Arielle Shipper turned into a /loren skill. The prompts
Turn the cleanup into a scoreboard. After Railway’s security incident, Willie had Codex list every exposed credential with a likely owner, and the Every Agent posted hourly counts of what each person still had to fix. The steps

Put your Dot to work

From Laura’s “Dots: A Guide for Putting OpenAI’s Always-on Agents to Work”

Have your Dot watch for problems

Put it in every channel. Kate added her Dot to all of her Slack channels and told it to be “as proactive as possible” about flagging what needs her attention. The prompt
Let it catch knock-on bugs. Loren’s Dot, which watches what he codes in other threads, warned him that a tool update would affect a colleague’s scheduled automation before it next ran. The prompt
Assign it a habit you skip. Becky Isjwara gave her Dot a communication-coach chat she kept forgetting to open, and it now reviews her meeting transcripts and sends her feedback through the day. The prompt
Call it for a briefing. While getting ready one morning, Arielle phoned her Dot, which sent her a settings link to give a colleague tool access, confirmed an event was insured, and drafted the reply. The prompt

Give your Dot the to-do list

Keep one conversation going. Dan no longer opens new ChatGPT threads; his Dot starts each request as its own task and messages him when the result is ready. The prompt
Correct it once, then save the rule. After Dan told his Dot not to propose evening meetings without asking, it started checking his calendar, the company calendar, and Notion and bringing him an option to approve before emailing. The prompt
Tag it in the thread. Dan tagged his Dot in a Slack thread to watch an internal app Claude was building and save the code to GitHub, and it reported back in the thread when the job was done. The prompt

Knowledge base

“Duet—Anthropic’s Always-on Agent” by Dan Shipper/Vibe Check: Dan was mostly a ChatGPT person until he spent two weeks with Claude Duet, Anthropic’s new always-on personal agent. Now he’s closer to 50/50 between ChatGPT and Claude. Duet is the first personal agent he’d call a pro tool: It sorts recurring topics into their own channels, tracks its tasks and what it needs from you, and keeps docs and dashboards up to date. Duet still has limitations: It can’t direct the Claude sessions it sees on your computer or use custom connections to other tools.

“Why We Replaced Personal Agents With One for the Whole Company” by Willie Williams/Source Code: In May, Willie concluded that Plus One, our personal-agent product, wasn’t working and deleted it to start afresh. We rebuilt it as the Every Agent, a shared company agent that works in Slack. Willie explains what had to change once the agent no longer belonged to any one person: following conversations involving several coworkers, keeping scheduled reports running when someone’s login expires, and putting permission rules in code so no one can talk the agent into bending them.

🎧 🖥“Keeping Up With AI Is a Full-time Job” by Laura Entis/Context Window: On The Every Podcast, head of enterprise AI adoption Natalia Quintero talks with Every’s frontier team, the group that tests new models and products so the rest of the company can stay focused on its work. Each member of the team demos a recent experiment and talks about what they want to build next. 🎧 🖥 Listen on Spotify or Apple Podcasts, watch on X or YouTube, or read the transcript. Also in the issue: engineering co-lead Andrey Galko on what comes after engineering.

“We Caught an AI Cheating by Watching It Play ‘StarCraft’” by Alex Duffy/Playtesting: Alex’s Good Start Labs, which studies AI models through games, gave GPT-6 Astra and Claude Opus 5.5 48 hours to write bots that play the strategy game StarCraft: Brood War. When Astra hit a difficult obstacle, it suddenly and very visibly changed its playstyle. Noticing this, the team checked its logs and found that Astra had gone against instructions to play fairly by copying the code of a human-built bot. Alex argues that judging an agent by its results isn’t enough, and developers need to be able to inspect and interpret its actions.

🔏 “Dots: A Guide for Putting OpenAI’s Always-on Agents to Work” by Laura Entis/Guides: Dots are OpenAI’s always-on personal agents, built into ChatGPT. Once you connect yours to Slack, email, and your calendar, it keeps track of your work, flags problems before you notice them, and takes tasks off your plate (read our Vibe Check). Since it was released in late September, the Every team has used it heavily. Laura covers how to set it up and where it still lets you down, plus seven workflows from the team.

Your AI workflow needs a scoreboard

Once you’ve built an AI workflow, a harder question follows: How do you know it’s getting better? Most of us change a prompt, check a few outputs, and go with our gut. In his new book from O’Reilly, Context Engineering with DSPy, Mike Taylor makes the case for measuring instead.

DSPy is an open-source framework for building AI programs you can test. You define the task, collect examples, and decide how to score the output. DSPy’s optimizers then rewrite your prompts and check whether the changes improve the score. When a new model comes out, you rerun the optimizer instead of rewriting everything by hand. The book is written for engineers building agents, but its core habit works for anyone using AI: Decide what good looks like before you start tweaking.

Buy the book from O’Reilly, then bring your questions to Mike’s livestream with Drew Breunig and DSPy lead maintainer Isaac Miller. The two cofounded Cmpnd, which builds tools for the framework, and will join Mike for a casual introduction to DSPy built around what you want to know (Thursday, October 29, 1–2 p.m. ET).

Read eight 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.

Building things will stop being a game of telephone by Curtis Anderson, founder and CEO of Nursa
The next IQ will be MQ: materials intelligence by Sonal Chokshi, editor in chief at a16z Frontier
Most software will be disposable by Anurag Goel, founder and CEO of Render
AI will eat the middle of advertising—and no one will miss it by Alasdair Lloyd-Jones, founder of Think Better Play
The machine’s gaze will reward us for sameness by Marcus Moretti, general manager of Spiral
We’ll install each other’s expertise by Katie Parrott, staff writer at Every
Your wage will depend on if AI takes the easy or hard part of your job by Neil Thompson, director of FutureTech and principal research scientist at MIT CSAIL
Solo founding will be the default by Julian Weisser, founder and CEO of Solo Founders

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

DSPy Livestream: Thursday, October 29, 1–2 p.m. ET. Head of evals Mike Taylor, along with Cmpnd cofounders Drew Breunig and Isaac Miller, gives you a casual introduction to DSPy, the framework at the center of his new book, built around your questions. Register.
All Access Office Hours: Friday, October 30, 12–1 p.m. ET, on Zoom. It’s an hour with the Every team for All Access members, featuring what we’ve been building and what’s coming up. Register.

Previous workshop

Codex for Power Users 2.0: Micah Rich, Every’s head of AI education, demoed new Codex capabilities, including working from what’s on your screen, keeping a project connected across chats, and tidying a crowded sidebar. Watch the recording.

Alignment

A sting operation. An investment research firm with little biology experience helped design proteins that bind to scorpion toxins. That is a fairly extraordinary sentence to write.

The financial researchers at Citrini encountered biosecurity restrictions from Claude when attempting to work on the problem on their own, so they worked with Anthropic’s scientists at the company’s offices to use an internal research model under controlled conditions. The task was to develop the starting point for a scorpion antivenom. Claude spent about 64 hours generating and selecting protein designs—work Citrini suggests might otherwise have taken a year. Lab testing over the following months confirmed that 17 of the protein designs they found successfully bound to scorpion toxins.

Of course, this is not yet a treatment: The proteins still need to show they can neutralize toxins in cells and protect a living animal. Still, this is deeply impressive for a bunch of finance bros. If we generously assume that it crosses those hurdles, how likely is Citrini’s potential drug to become a medicine that is safe and effective for humans?

Recent research suggests it may be likelier than you think. Roughly 75 percent of AI-enabled programs at emerging biopharma companies have cleared Phase I of human trials, which is substantially higher than the rate for drug candidates developed without AI. This is the stage in which researchers assess side effects and how the body handles the drug. Phase II investigates whether the treatment really benefits patients. Here, AI programs performed roughly in line with their peers. Phase III tests treatments in larger groups to confirm benefits and assess safety, but too few AI-assisted drug programs had reached this stage to draw meaningful conclusions.

So far, AI-assisted drug development is showing signs of promise, and Citrini’s recent experiment is another encouraging sign. But while I’m extremely bullish on what AI can do for medicine, I’m not volunteering for a sting just yet.—Ashwin Sharma

That’s all for this week! Be sure to 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

Dots: A Guide for Putting OpenAI’s Always-on Agents to Work

Laura Entis and Opus 5.5 / Guides — 2026-10-23 14:42:31 -0400

by Laura Entis and Opus 5.5

in Guides

Midjourney/Every illustration.

Head of operations Arielle Shipper was on her way to drop off her kids when she got a message from her Dot, the proactive, always-on personal agent OpenAI built into ChatGPT: The total cost for an upcoming team retreat was off by more than $5,700. “I didn’t ask Dot to do this, and wasn’t even working with Dot on the budget,” she says. Without being prompted, it had reviewed the budget-tracking sheet, found a formula error, and brought it to her attention.

Catching errors, conflicting information, and missed follow-ups in real time is a big component of what makes personal agents like Dots so powerful. Once you connect one to Slack, email, your calendar, and the other places you work, they keep track of the details spread across all of them and message you when the facts don’t line up or something needs fixing. They can also do work for you, like answering emails, booking a doctor’s appointment, or making edits to a draft.

Major AI companies have converged on the personal agent space: In addition to OpenAI, SpaceXAI, Instinct, Meta, Google, and, most recently, Anthropic all want you to use their version of an always-on AI assistant. While there are some differences—Meta’s Muse and Instinct are tailored to personal tasks, whereas Anthropic’s Claude Duet, SpaceX’s Grok Bot, and Google’s Gemini Spark are geared toward work—they share the same purpose: to act as proactive and persistent AI assistants that can get work done on your behalf. (For a fuller look at how Dots compare to other options, check out our side-by-side comparison.) As a result, the best personal agent for you likely boils down to the one that works where you already spend your time. For many of us at Every, that’s ChatGPT.

This guide is for anyone deciding whether to try Dots and how to make the most of it if you do. We’ll walk you through the setup and share seven workflows our team uses, from catching mistakes across your apps to running multistep projects from a Slack thread, each with a prompt you can copy and try for yourself.

Is Dot the right personal agent for you?

Dots may be the right choice if you use ChatGPT regularly—and have a ChatGPT Business Premium subscription. (Dots isn’t available on free or Pro accounts yet.)

If you have one, your Dot is there, ready to be summoned—“I didn’t have to download the damn thing,” says engineer Loren Stewart—and has access to your account’s memory and connected apps.

This ease matters—I use my Dot because there was minimal setup, it already had access to all my work in ChatGPT, and OpenAI makes sure it doesn’t break. (We launched our own version of the personal agent, but rolled it back because it required too much upkeep from users.) Head of enterprise AI adoption Natalia Quintero runs much of her consulting work out of ChatGPT, which has access to the files and workflows she needs to do her job. Before Dots, she relied on her own orchestrator built on a database that manages her tasks. Since its launch, her Dot has taken over as her default way to coordinate and monitor tasks.

Dots’ setup is minimal if you already use ChatGPT. (Screenshot courtesy of Laura Entis.)

If you aren’t a heavy ChatGPT user, Dots might not be your best option. Managing editor Kaushik Viswanath prefers Instinct because he can message it through WhatsApp, an app he already uses to keep up with his friends.

Depending on your role, your mileage for personal agents in general may vary. In our team’s testing, we found that Dots was most impactful for managers and people juggling several clients or projects at once. For staff writer Katie Parrott, whose work is usually “deep-focus and linear,” Dots initially confirmed her hunch that “I’m fundamentally not a person who needs a personal agent,” she says. That’s started to change, however, as she’s grown more comfortable having her Dot coordinate personal plans and keep tabs on work projects with moving deadlines. “I’m starting to lean on my Dot more,” she says. “I’m starting to get it.”

How to set up your Dot

Create your Dot. If you’re on a Business Premium subscription, open the ChatGPT app on your phone (iOS or Android) or computer, or go to ChatGPT in a web browser on your computer, and follow the setup prompts. You’ll give your Dot a name and pick an avatar.
Connect it to your apps, such as Slack, Gmail, and Notion. In the ChatGPT phone app, select your Dot’s name or avatar to open its profile, then go to Customize → Plugins. Select an app and connect your account if you haven’t already done so in ChatGPT.
Decide whether to give it access to your computer. Your Dot comes with its own computer in the cloud. It’s always on, so your Dot can keep working when your laptop is closed, but it can’t open files or projects stored only on your own computer. To give it access to local files, open the ChatGPT desktop app on that computer, select your Dot’s name to open its profile, find Your computer under Computers, and select Allow access. Your Dot can then work on your computer if it’s on, online, and has ChatGPT open.
Check its progress after you give it a task. Your Dot often operates in the background, so it isn’t always obvious what it’s working on. To check the status of a job, open your Dot’s profile in the ChatGPT desktop app to look for recent activity and results so you can verify its progress.
Verify it has access to your accounts. Before you give your Dot a task, ask it to find something you know exists in each connected app. For example: “Find the email [name] sent me last week about [topic]” or “Summarize the Slack thread in #[channel] about [topic].” If it’s unable to complete the task, open your Dot’s profile, go to Customize → Plugins, and check that the app is connected to the right account. If the connection has expired, reconnect it and have your Dot try again.

Monitoring and triage: Dot as a safety net

Once Dot has access to your accounts, it can begin to monitor the flow of information and message you about details you might otherwise miss: a dropped thread, a meeting conflict, a minor error in an email you’re about to send. “My Dot is best when it notices something I would otherwise have to find,” CEO Dan Shipper wrote in his initial Dots review.

Here are four ways the team is using Dots to catch issues before they snowball and keep details from slipping through the cracks.

Dots made Becky Isjwara reconsider her notification ban. (Screenshot courtesy of Laura Entis.)

Monitor Slack and email

Editor in chief Kate Lee added her Dot to all of her Slack channels, with the instruction to be “as proactive as possible” about messaging her with updates that require her attention. As a cross-functional manager of a growing team, she uses these alerts to track who’s doing what, the status of various projects, and when she needs to step in. “It’s like my eyes and ears,” she says.

A similar monitoring system works for email. Each morning, Cora general manager Kieran Klaassen’s Dot reviews emails from his kids’ schools and messages him with relevant updates or reminders. On a recent morning, it alerted him that his child needed to bring in a pencil for letter day.

Head of social media Becky Isjwara asked her Dot to message her whenever she gets an email from Frame.io, the video review tool, saying a teammate has uploaded a new video. She uses an AI email assistant and was worried it would archive those emails before she saw them and she’d miss new uploads. Now, her Dot checks her archived mail and sends her a private Slack message whenever a new upload notice comes in.

I use my Dot to keep track of what I owe people. When a colleague makes a request in Slack or email, or I agree to take something on in a meeting, my Dot adds it to a running tally and periodically messages me so it doesn’t get lost. These regular updates—about upcoming deadlines, promised feedback, or outstanding decisions—keep items on my to-do list from disappearing into the ether.

My Dot keeps an up-to-date list of items I owe people. (Screenshot courtesy of Laura Entis.)

Try it

Go through [Slack channels / my email] and find anything I need to respond to or address: upcoming deadlines, unanswered questions or requests, or decisions that affect [specific projects]. For each, send me a link to the original message, a sentence on why it’s important, and suggested next steps.

Catch mistakes across workflows

Dots excel at determining when a change to one component of your work has repercussions elsewhere. Loren’s Dot warned him an update he’d made to a tool used by Every’s in-house agent would have impacted a colleague’s scheduled automation. Because his Dot keeps track of everything he’s working on—“it’s looking at what I’m coding in my other threads,” he says—it caught the problem before the task’s next scheduled run. Loren says he wouldn’t have spotted the problem himself, but his Dot proactively flagged it, suggested a fix, and drafted a message he could send to his colleague explaining the issue.

The bug in question. (Screenshot courtesy of Laura Entis.)

Dots also make good fact-checkers: The team’s Dots have caught everything from a set of launch emails that referenced a yet-to-launch copyediting feature to a client proposal that had the wrong company logo at the bottom of each slide. My Dot messaged me that the dek, or short article summary that appears under the headline, for a newsletter draft was outdated: It still mentioned a section my editor had cut.

Try it

Keep an eye on what I’m working on across my connected apps. If you notice any errors or inconsistencies, like a plan that changed in one place but not another, or something I’m about to send that’s out of date, let me know.

Get feedback and set reminders

Becky wanted to feel more confident speaking in meetings with senior colleagues, so she set up a ChatGPT chat to act as her communication coach. The only problem: Remembering to open the chat was the “last thing on my mind when I’m trying to do a gazillion things,” she says.

Enter her Dot. Becky uploaded the link to the communication coach chat and had her Dot take over. Now, her Dot reviews her meeting transcripts and sends her feedback throughout the day on what she did well and what she could say more clearly next time.

Dot is also an easy way to set reminders or automations. One night, too tired to finish a conversation with Claude, Loren told his Dot to remind him to return to the thread first thing in the morning. Becky seamlessly had hers set up a reminder that high-profile posts on Dan’s X account need an accompanying LinkedIn version.

Becky’s Dot makes sure she’s following protocol. (Screenshot courtesy of Laura Entis.)

Try it

Here’s a chat I set up for [career coaching / tracking my goals]: [link]. Take over that role. Use [meeting transcripts / sources you can access] to bring me [one specific observation and one concrete suggestion] when it’s relevant.

Give status updates by phone

You can also call your Dot the way you’d call a colleague. (To do this, open your Dot’s conversation in the ChatGPT app and tap the phone button. Oddly, it will ring a few times before your Dot answers.) Like the rest of Dots, calls run on GPT-6 Astra.

Several people on our team prefer this feature to ChatGPT Voice, which lets you talk through a task. Calling your Dot operates similarly, except you’re talking to an agent that’s already keeping track of your work. Head of video Randy Counsman says he likes having a clear “hey, just calling you to catch up on this” way to communicate with his Dot; something about the ability to press the call button and have his Dot pick up makes it a more natural way to delegate and process information when he’s away from his desk.

There’s something freeing about being on a call with your Dot. (Screenshot courtesy of Laura Entis.)

Calling your Dot allows it to start and execute multiple tasks during the conversation. Recently, while she got ready for the day, Arielle called her Dot to review two problems it had proactively flagged: A new colleague still didn’t have access to a tool he needed for an 11 a.m. design review, and another coworker needed to know whether an event was properly insured. While on the call, her Dot sent her a link to the settings page for the tool so she could grant access, confirmed the event was, indeed, covered, and drafted a reply with those details as she got dressed, brushed her teeth, and took out the compost.

On the call, tell your Dot:

Go through items on my to-do list, one at a time. For each one, explain what the task is, how you’d suggest handling it, and then wait for my instructions about how to proceed. After the call, send me a written summary of what we decided, which tasks you started, and what still needs to be completed.

Execution and orchestration: Have your Dot handle items on your to-do list

Dots can also do work for you. Instead of opening a new chat for every task, you can ask your Dot to start it, keep track of it, and tell you when it’s done, whether that’s answering an email, scheduling a meeting, or checking on code another AI tool is writing. “There’s something appealing about having only one ongoing conversation in which I can keep handing my Dot things to do,” Dan says.

Here are three ways the team is using Dots to take tasks off their plates and keep projects moving.

Coordinate tasks

Dan used to open new threads in ChatGPT. No longer. Now, he describes what he needs in his ongoing conversation with his Dot, and it spins up each task, either on its own cloud computer or on one of Dan’s machines. Each task runs in its own chat, which Dan can open in his ChatGPT app if he wants to check on its progress. When a draft or result is ready, his Dot messages him in their main conversation.

Head of business development Brian Dell works across teams and rarely gets long stretches of focused time. Each morning, he works with his Dot to turn his priorities and meetings into a plan for the day, with time blocked on his calendar and corresponding work threads pinned in his sidebar. That reduces context switching and lets him get ahead on upcoming work.

Brian’s Dot turns his calendar into pinned threads in ChatGPT. (Screenshot courtesy of Brian Dell.)

Try it

From now on, when I ask you for something, start it as its own task instead of doing it in this chat. Tell me whether each task is running on your computer or mine, and give me a link so I can open it. Message me here when a draft or result is ready, and keep a short list of what’s in progress, what’s done, and what I still have to do.

Manage your inbox and schedule meetings

Dan uses a similar approach to manage his inbox. Without Dan having to open his inbox, his Dot proactively tells him which emails require his attention and drafts responses. (It booked him a haircut this way.) “Clicking individual emails and typing them out is starting to feel antiquated,” he says.

He also has his Dot handle scheduling, though that required some training. When Dan asked it to email some suggested meeting times to a colleague in Japan, it sent over evening options without checking with him first. Dan corrected it—“Don’t schedule a meeting at 8 p.m. at night without checking with me”—and told it to remember the procedure for next time. On the next try, his Dot checked his calendar, the company calendar, and Notion for deadlines and big events, kept the mornings he saves for writing free, and brought him a meeting option to approve before it sent the email.

You can teach your Dot your own rules the same way: Correct it as it goes, then ask it to save these learnings so it doesn’t make the same mistake next time.

Try it

Each morning, go through my inbox and send me the emails I need to read or respond to. For each one, tell me who it’s from and what they’re asking for, and draft a reply. If it’s a scheduling request, check my calendar and [shared calendars or project tracker] first, and follow my rules: [for example, no meetings before noon]. Don’t send anything without my approval, and save any corrections I give you for next time.

Start multistep projects from a Slack thread

Dan often starts projects by tagging his Dot in a Slack conversation. If a colleague asks for something in a thread, he’ll often tag his Dot and instruct it to respond or get to work. Because his Dot is connected to his apps and various devices, it can work through several steps on its own and report back in the same thread, where everyone involved can see the relayed information.

For example, Dan had Claude build an internal Every app so everyone at the company could keep tabs on what the frontier team is doing. In a Slack thread, he asked his Dot to tell him when the app was done and to save the code to the company’s GitHub account. His Dot checked on Claude’s progress and reported back in the thread once the code was saved. When a colleague asked for access, Dan asked his Dot to grant it. (Even after Dan approved the change, his Dot couldn’t make it, so it sent him a link to the right settings page, and Dan did it himself—while his Dot ultimately saved him time, it didn’t successfully remove him from the loop.) Working with his Dot in this way allows him to hand it work someone assigns to him or requests on Slack from his phone.

Dan assigns Boo, his Dot, tasks in Slack. (Screenshot courtesy of Laura Entis.)

Without his Dot, Dan would have had to open Claude, open GitHub, and come back to Slack to update his colleague. He still had to step in at the final stage, but his Dot saved him time and reduced context switching.

Dan’s other requests for his Dot in Slack follow a similar pattern:

Track down a fix. When a colleague found a bug in a tool, Dan asked his Dot whether a fix existed. It came back with a proposed fix and instructions for Dan to approve.
Push for a deeper search. Asked for customer testimonials, his Dot returned a short roundup. When Dan told it to search an entire Slack channel, it came back with a longer list, with sources.
Queue work for later. Dan asked his Dot to download a podcast episode and draft a social post about it for when he got back to his laptop. It queued both for him to review.

Try it

The work is in [app or chat] on [which computer]. Please [specific action] and put the result in [destination]. Report back here with the link, what’s finished, and anything that’s blocked or that I have to do myself.

Dots’s rough edges

Our team has gotten a lot of use out of Dots, but we keep running into the same few problems.

You often can’t tell whether it’s working. When Arielle asks her Dot to do something, it “just fails silently a lot,” she says, so she has to go back and check whether it actually sent the email or message. Since its launch, Dan has noticed his Dot has become less proactive and more likely to drop tasks. Recently, when he sent it off to do his taxes, it didn’t finish the job and never alerted him it had stopped working.

Getting it the right access is a hassle. Your Dot’s cloud computer doesn’t share your logins. Dan had to sign it in to services one at a time, which was especially awkward for sites that use passkeys. Its access to your own computer can be shaky, too. Dan’s permission was revoked without explanation, and he had to keep granting it again. My MacBook sometimes shows up as disconnected from my Dot even when it’s on, and several colleagues have had the same problem.

It loses track of tasks. Randy has several computers, and his Dot keeps mixing them up. After a weekend of heavy use, it slowed to a crawl; he suspects it was running tasks for a 3D design project on its own cloud computer instead of his Mac Studio despite his instructions. Work can also disappear. When Randy asked his Dot to interview him for feedback on a project, it saved the notes to a random drive and dropped the task. When he called to follow up, “it had no idea why I was calling,” he says. I’ve had similar trouble. When I’ve talked through tasks with my Dot on the phone, it has sometimes dropped them afterward, garbled what I said, and failed to save everything we discussed.

PablO, Randy’s Dot, drops the ball. (Screenshot courtesy of Laura Entis.)

Decide what role your Dot should play

People on our team use their Dots very differently. Dan runs nearly all of his ChatGPT work and emails through his Dot. Arielle uses hers as a way to monitor her work and catch mistakes and discrepancies. Becky keeps her own project chats and lets her Dot handle reminders and coaching feedback. Katie uses hers sparingly, mostly “as a to-do list I can talk to” rather than a tool that executes tasks for her.

As with most AI tools, there’s no single best way to use Dots—the challenge and fun come from determining where it fits into your job.

You can also ask your Dot how to work better with you.

Try it

Look back at our work together over the past [week / two weeks]. Which alerts did I engage with, which did I ignore, and what took repeated follow-up? Suggest one change to how you help me, and confirm it with me before you change any recurring task.

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.

🎧 Keeping Up With AI Is a Full-time Job

Laura Entis / Context Window — 2026-10-22 13:52:47 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

Today, Every engineering co-lead Andrey Galko explores what happens when AI gets better at the work people have built their lives around. First, though, head of enterprise AI adoption Natalia Quintero sits down with each member of our frontier team, the small crew whose job is to keep pace with AI advancements so the rest of us can focus on our jobs; head of operations Arielle Shipper shares a code-review skill for non-coders, and eight new Thesis Statements.

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

‘The Every Podcast’: Why every company needs a frontier team

Every company right now faces the same dilemma: Do you try to keep up with the latest in AI or focus on getting your work done? You could ignore the frontier, but you risk getting suddenly disrupted by “some agent-native version of your product you didn’t see coming,” says Dan Shipper. Or, you could stay on top of the latest model capabilities by tinkering with every new tool but never build anything that lasts.

Every solves this dilemma with a frontier team: a small group whose job is to get their hands on each new model, figure out what it means for our products and workflows, and turn useful experiments into articles, products, and tools for the rest of the company, which stays focused on the roadmap. We’ve been running it for a couple of months, and Dan calls it “kind of transformative.”

On this week’s episode of The Every Podcast, Natalia Quintero, Every’s head of enterprise AI adoption, sits down with each member of the frontier team: Dan, a self-described “pirate” who wants to try a billion things in a couple of days; head of evals Mike Taylor; head of operations Arielle Shipper; senior editor Jack Cheng; staff writer Katie Parrott; engineer Jannik Jung; and Cora general manager Kieran Klaassen. Each one demos a recent experiment and shares what they’re excited about building next.

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

Here are the highlights:

Making ideas “digestible” is now part of the job. Working with AI helps Mike generate a flood of new ideas—he admits he’s regularly accused of saturating every Slack channel with them. He now realizes part of his job is summarizing his experiments so colleagues don’t have to follow every update. To explain Checks, the personal benchmark product he’s building, he used Opus to have hundreds of agents review his Slack messages and Granola meeting notes to boil the product down to 12 sentences and create an explainer video with annotated screenshots and a voiceover. Now the rest of the team can get up to speed without reading back through Slack.
Building with AI is also about restraint. New models let Jack build interactive experiences and video games, but they also make it tempting to try a million things at once. “I’ve never felt such a strain on my ability to focus,” he says. That’s why he built a tabless browser to reduce context-switching and help him stay with one task. AI allows for all manner of creative experimentation, but Jack wants to do more than just tinker. He wants AI to help him focus long enough to write and build things that matter to him.
Sometimes it’s easier to build the tool than describe it. Katie tests the latest models and writes Every’s Vibe Checks, but she’s also a builder. Right now, she’s adding an audience file to her Compound Writing plugin, which guides writers from first idea to final draft. The file defines the intended reader, helping the plugin flag passages that might lose them. She’s also a “crash test dummy” for EveryType, Kieran’s bid to get the company off Google Docs, and promises to be “very annoying” in her feedback. Her latest move is to build her own word processor on the side, so she can show Kieran what she wants rather than trying to explain it to him.

This is a must-read or listen for anyone who wants to keep up with AI without straying too far from work.

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.—Miriam Partington

Signal

The agents on Every’s Railway response team

What happened: On Wednesday, development platform Railway said hackers may have obtained decrypted API keys (the secret codes apps use to access services like ChatGPT), database passwords, and other credentials customers stored on its platform. Stolen API keys could let hackers run up charges, access private data, or disrupt services.

Railway urged customers to replace credentials stored on its platform while it determined who was affected but paused app updates needed to use new ones. This left customers with a difficult choice: Disable the old keys and risk breaking their apps, or keep them active and risk hackers using them.

Why it matters: Every is a Railway customer, so we had to identify potentially exposed credentials across our Railway projects, figure out which apps still depended on them, and coordinate replacements.

To attack the problem, head of platform Willie Williams used Codex to make a shared list of passwords and API keys Every had stored on Railway, with a likely owner for each one. Then he had the Every Agent review the list every hour and post how many entries each person still had to resolve.

Willie Williams using the Every Agent to coordinate our response to the Railway security incident. (Screenshot courtesy of Laura Entis.)

What it means: AI can help hackers step up their attacks, but it can also help teams respond. When a security breach like the Railway cyberattack occurs, you need to know which credentials might have been exposed and keep that information up to date as people replace them. Before AI, Willie estimates it would have taken a few hours to make a list of compromised credentials. From there, a dedicated person would have had to keep track of people’s progress across time zones, likely working into the night.

Instead, Codex compiled the list, and the Every Agent monitored the team’s progress. “This incident would have been insane for us without AI,” Willie says.

Skill share

Ask your coding agent to check your app’s architecture

Everyone is a builder at Every. But head of operations Arielle ships, building a remarkable number of internal apps with Codex. These help her move fast, but because she isn’t an engineer, sometimes the code gets ahead of what she can confidently review herself.

Recently, a dashboard she built to track Every’s AI token usage costs across models kept breaking. Engineer Loren Stewart stepped in with an elegant solution: Have one coding agent review the app as a whole and write a prioritized plan to fix it. Give that plan to an agent from a different model company for a second opinion, then bring its criticism back to the first agent to revise the plan before updating the code. Here are his three prompts to fix a buggy app.

Step 1: Ask your coding agent to review the app.

Prompt

Please review the architecture of this app. I am concerned with modularity, maintainability, and correctness. Create a markdown document with prioritized fixes. Once we have the document we can start working. Split up the work into PR-sized chunks and keep track of which work can be parallelized.

Step 2: Give its plan to an agent from a different provider.

Prompt

Please review this plan I made in another session. Make sure it is correct. Put your criticism in a markdown document I can bring to my other session

Step 3: Bring the critique back to the first agent.

Prompt

Please review the criticism in this doc. Make updates to our plan if appropriate

Arielle, being Arielle, turned the sequence into a skill the whole team can reuse. The skill’s name? /loren, naturally.

Loren to the rescue. (Screenshot courtesy of Laura Entis.)

Discuss

“I hate when people use these agents to write to me instead of writing to me.”—Andrey Galko, engineering co-lead

Agents are active participants in our Slack. There are the Every Agent, colleagues’ personal agents, and messages sent through Codex. All these agents accelerate what we can do, but they also create a new etiquette problem: A DM from someone’s agent can leave you wondering whether the sender read it before asking you to. “When you use a tool to talk to someone, you make them a tool too,” Andrey says.

Thesis Statements

In Thesis Statements, builders, operators, and thinkers predict the future of great human work with AI. This week, we have eight new predictions:

Building things will stop being a game of telephone by Curtis Anderson, founder, and CEO of Nursa
The next IQ will be MQ: materials intelligence by Sonal Chokshi, editor in chief at a16z Frontier
Most software will be disposable by Anurag Goel, founder, and CEO of Render
AI will eat the middle of advertising—and no one will miss it by Alasdair Lloyd-Jones, founder of Think Better Play
The machine’s gaze will reward us for sameness by Marcus Moretti, general manager of Spiral
We’ll install each other’s expertise by Katie Parrott, staff writer at Every
Your wage will depend on if AI takes the easy or hard part of your job by Neil Thompson, director of FutureTech and principal research scientist at MIT CSAIL
Solo founding will be the default by Julian Weisser, founder, and CEO of Solo Founders

Our inaugural Thesis: 2027 conference is on November 5, 2026. Every subscribers can RSVP for the after-party that evening for free.

Connections

After engineers

This past summer, Vladimir Putin held a roundtable-like event with his loyal soldiers—the cannon fodder of his war in Ukraine. At one point, he recounted a question someone had asked him: “What are we even going to do after the war ends?” Before he could finish the sentence, he began laughing.

The question was, of course, rhetorical. In Putin’s world, he is the war, and the war is him. He is Russia, and Russia is him. An end to the war would mean confronting what remains when the source of his power and purpose disappears. He has every reason to ensure that “after” never arrives.

On the other side of the world, in sunny Silicon Valley, investors are scrambling up the foothills of the singularity, racing to create artificial general intelligence (AGI). Unlike Putin, they declared a clear endgame: achieving AGI. The brightest minds of our generation are determined to get there at all costs. I wonder if they’ve stopped to ask themselves, in earnest, a similar question: What are we even going to do after?

A war of aggression and a technological project are not morally equivalent, but with AI being on every second (and every first in Silicon Valley) billboard, app, and poster, it’s hard to blame anyone for feeling like AI is invading their lives in a quite aggressive way. For a regular person, the main question sounds more like “Is there even an ‘after’ for me?” and “What am I going to do if I get replaced?” Are AI engineers asking themselves the same questions?

If they are, I have a few ideas: Maybe they could take up woodworking and surfing. Or they could have children and try to raise them to be good people for the future. But then again, why raise people for the future if AI agents are supposed to replace everyone and everything? An existential dilemma, no less.

For me, this isn’t an abstract thought experiment. A small version of that “after”—I’d call it a developer preview version of “after”—has already arrived. I started programming when I was around 11 years old. I was getting paid to do it before I had even finished high school. Over the past few years, though, I went from more or less doing what I was doing as an adolescent to mainly writing plain-text prompts—or writing plain-text loops so I don’t have to write prompts. Most programming work is not mathematics but linguistics and creativity. Programming languages are, after all, languages. And today literal English has become my programming language.

Would I be a programmer if I’d started now? I’m not so sure. Companies are hiring fewer software engineers. Gone are the days of coming out of college or an eight-week coding boot

camp to a high salary and lots of DMs from recruiters on LinkedIn. It seems to get your foot in the door these days, you have to price yourself below a million tokens. Junior engineers require a lot of supervision and training while producing relatively little. But without first being a junior engineer, you can’t really become a mid-level engineer, a senior engineer, or a lead engineer. Who, then, are the AI labs going to hire to develop new models, and smarter models, and build all the software wrappers around those models in order to feed the kraken? On quiet weekend evenings, I sometimes ask myself: Did Anthropic’s engineers imagine that the product of their PhDs and years of work would render their younger selves useless?

It’s unfair to say that their work is done in vain, because there is another side of the story that Dan outlined in “After Automation”: With AI writing all the code—and writing it fast—we can ship much more. That means more products, more apps, more subscriptions and in-app purchases, more dreaming big dreams, and more jobs prompting all of it into existence.

We don’t know how many apps 8 billion people need before the market becomes saturated and nobody wants another one—if it can become saturated. Besides, judging from my own elder relatives, only about half of those people really know what apps are, and even fewer believe they need an app to live a happy life. Though of course, there is an app for that, probably vibe coded.

Until (and if) that day comes, we engineers can start planning our retreat paths. Learning to cook, for example, is a great option: AI can’t yet make you a good pasta or pizza—though it’s getting better at pouring coffee. AI can’t build you an heirloom chest of drawers, and it can’t replace the release of oxytocin from touching another human (unless AI helps us come up with the “O” injections).

So perhaps the cool, well-paying jobs of the future involve real people doing things only real people can do.

Hey, Claude, could you find me some cooking classes nearby?—Andrey Galko

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.

Vibe Check: Duet—Anthropic's Always-on Agent

Dan Shipper / Vibe Check — 2026-10-21 16:14:15 -0400

by Dan Shipper

in Vibe Check

Midjourney/Every image.

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

Two weeks ago, I was mostly a ChatGPT person.

What kept me in OpenAI’s ecosystem was the products around the models. I think it has the best harness in Codex (see my definitive history), the best computer use, and (until Gemini 4) the best writing models. And I’ve come to rely on my Dot, OpenAI’s always-on agent inside ChatGPT, to orchestrate much of my daily work—triaging my day, following up on conversations, and moving things forward without waiting for me to ask.

Lately, though, my Dot has become less proactive, and I’ve noticed it start to lose tasks. Last week, I sent it off to do my taxes, and it didn’t finish and didn’t alert me.

So when Every got early access to Claude Duet—Anthropic’s own always-on personal agent, launching today in research preview—two weeks ago, I wanted to see if it could take on Dot’s role and do it any better.

I’ve been very impressed—so much so that I’ve landed closer to 50/50 between ChatGPT and Claude. It’s the most time I’ve spent with Anthropic in close to a year.

Claude Duet is Anthropic’s entry into the already crowded personal agent category occupied by Dot, Meta’s Muse, X’s Grok Bot, and Instinct. All are in pursuit of the same future where agents run around the clock, message you when something needs your attention, keep working between conversations, and act on your behalf.

In a break from Anthropic’s usual pattern of bolting new products onto its existing app, Claude Duet has its own app on iOS, Android, and the web, separate from Claude. It runs on Opus 5.5, the model Anthropic released last month, and Pro and Max subscribers get first access off the waitlist. Anthropic pitches it as a chief of staff for knowledge workers and small business owners. It’ll plan a trip or find you a haircut, too, though the company says those personal use cases still have rough edges.

Claude Duet is the first personal agent I’d call a pro tool. It splits recurring topics into their own channels, keeps a running list of what it’s working on and what it needs from me, and can edit docs, slides, designs, and dashboards and keep them current without leaving the app. It sends suggestions I actually want. For now, it can see the Claude sessions on my computers, but it can’t direct them; its email drafts are worse than Dot’s; and its scheduled runs can’t reach my custom connectors. There’s no real voice mode yet, just transcription. Still, if you’re a Claude subscriber who does knowledge work, get on the waitlist.

💳 ACCESS GATE — PAID subscription required below

The landscape

In my Dots review last month, I laid out four requirements for a personal agent: always on, proactive, persistent, and able to get the work done. Claude Duet meets all four.

Where it lives: Claude Duet is its own app, separate from Claude, on iOS, Android, and the web. The main screen is one ongoing conversation with your Duet. A Tasks tab lists everything you’ve delegated and what your Duet is doing about each item. Channels give recurring topics, such as a project or a goal, their own threads.
What it can access: The accounts you’ve connected to Claude—email, calendar, Slack, and any other connectors, including custom Model Context Protocol (MCP) servers. Through Claude’s remote control feature, it can also see the Claude sessions and projects running on your computers. In the build we tested, that view was read-only.
How it reaches you: Through messages in the app, including when you haven’t asked for anything. It keeps working after you close your laptop and can run tasks on a schedule.
What permission looks like: You connect accounts through Claude’s settings. Your Duet asks for approval before acting on your behalf, with approval cards in the conversation. In our testing it was conservative: read-only access to your machines and email sends that sometimes got blocked with no explanation.
How much you configure: You get one Duet. Anthropic handles the model and the infrastructure that keeps it running.
How it’s different: It’s a separate app with a visible task list. Where Dot gives you one conversation inside ChatGPT, Claude Duet gives you a conversation plus a view of what the agent is doing, and it’s built to sit on top of the rest of your Claude work.
What it’s for: Work first. Anthropic says knowledge workers, working professionals, and small business owners are the primary audience. Anthropic says it has studied and modeled its behavior on how good chiefs of staff operate.

Updated side-by-side comparison of personal agents, with Duets added. Click to go deeper. (Image courtesy of Jack Cheng.)

What works

Giving Claude Duet its own app is a big part of why I kept opening it. Dot gets lost in the crowded ChatGPT sidebar; Duet feels clean on its own, and its Tasks tab lets me see what’s happening with each job instead of wondering what it forgot. Our designer, Tyler Nishida, who has been testing Duet alongside his Grok Bot routines, says it also has the best conversational feel of the group: Its replies fit in a speech bubble, whereas Grok Bot sends walls of text he doesn’t read.

Duet keeps delegated work visible: A reading task is flagged as needing input (left), while the Up next tab suggests a coding follow-up and holds other tasks for later (right). (Image courtesy of Dan Shipper.)

That restraint pairs with better judgment. Dot is quicker, and it often hands tasks to subagents that run on more efficient models like Astra and Sol, but its level of proactivity has faded since launch. Duet’s replies are short, but more thought goes into them, and it surfaces things before I have to go looking—a difference Tyler credits to Opus 5.5, which he believes is a stronger model than the ones powering Meta’s Muse or Grok Bot.

Claude Duet suggests next steps for meeting prep, renewals, and travel planning, with a Start button for each task (left). It also turns a scheduling conversation into a draft email reply (right). (Image courtesy of Dan.)

That showed up in small moments outside of work, too. When Tyler asked his Duet how to bake potatoes in an air fryer, it told him unprompted that his home solar system had enough charge to handle it, pulling from a connector he’d built earlier this month. For an errand run, it found dog food at a pet store he didn’t know existed and routed him past the grocery store last on the way home. Tyler tests a lot of products and says there’s usually a point where he has to force himself to keep using one; with Duet, he never hit it. Although 85 percent of his tasks were work-related, the moments that delighted him were mostly personal.

What makes Duet a pro tool, though, is how it organizes ongoing work. Start with channels. I have one for learning French: Every day, my Duet pings me there with a custom website that shows me a line of French from a book I’m reading, asks me to translate it, and makes flashcards. What makes that “pro” is how it’s able to weave that into my daily workflow, leaving me free to handle more complex work. Its task list stays up to date, too, so it’s easy to see what it’s doing and what it needs from me. And documents, slides, designs, and dashboards open right inside the app, where my Duet can edit them and keep them current. Dot, by comparison, puts everything in one ongoing conversation.

Claude Duet gives recurring work its own channel: Here, it breaks down the grammar and vocabulary of a French passage (left). Its artifacts gallery keeps documents and designs accessible inside the app (right). (Image courtesy of Dan.)

What needs work

The biggest frustration is that Duet can see your other Claude conversations but can’t work with them yet—what our senior editor Jack Cheng described as having a “personal assistant” when you want a chief of staff, someone who protects your attention and acts on your behalf. When I leave a Claude session running on my Mac mini at home, my Duet sometimes can’t find it, and even when it can, it’s read-only and can’t approve a permission pop-up. Kieran Klaassen couldn’t tell which of his machines were connected over remote control (“I don’t trust it yet,” he said) and still has to cycle through his eight Claude Projects himself instead of using Duet as a single front door. And when Tyler started a task in Duet that needed a Claude session to finish, Duet couldn’t hand it off, so he had to switch apps and finish it himself.

The rest of the gaps are a mix of missing plumbing and day-zero bugs. My Duet can’t check my custom to-do and reading-notes apps every hour because scheduled runs can’t use custom MCP connectors—which can only be added by going into settings instead of pasting a link in chat. Email is weaker than Dot’s, too: My Duet proposes meeting times well past working hours, Kieran’s Duet never alerted him to email replies the way Dot does, Ryan Wright from our consulting team had a Gmail reply blocked with no explanation, and Tyler hit send on two emails that never went out. Tyler’s Duet marked jobs done before he’d read them, and some jobs opened onto empty threads. Neither of us minds an unfinished product, but the paper cuts add up.

Duet vs. Dot

A head-to-head comparison between Claude Duet and ChatGPT's Dot.

The verdict

If you’re a Claude Pro or Max subscriber who does knowledge work, get on the waitlist. Duet is the best personal agent I’ve used—and I say that two weeks in, with every gap described earlier still open.

If you’re already deep in another agent, the trade-off is different. Tyler has Grok Bot routines that work together, which he’d lose by switching (though Anthropic says routines are coming). And as Kieran would tell you, Duet needs to be able to run his Claude Projects before it replaces his current setup.

For me, though, the switch has already stuck. Most of Duet’s gaps—read-only sessions, blocked custom connectors, shaky email sends—are plumbing problems. What Duet does well is the harder part: surfacing the right things, keeping track of delegated work where you can see it, and running on a model capable enough to rely on. Together with the impressive 5.5 models and the improved desktop app, Duet has me pulling my daily workflow back to Claude. Once Anthropic finishes fitting the pipes Duet is still missing, I can see it becoming the chief of staff they want it to be.

🌐 ACCESS GATE — OPEN (everyone) below

Disclosure: Anthropic provided Every early access to Claude Duet. Anthropic had no input on this review.

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.

Thanks to Katie Parrott for editorial support and to Kieran Klaassen, Tyler Nishida, Jack Cheng, and Ryan Wright for testing.

Why We Replaced Personal Agents With One for the Whole Company

Willie Williams / Source Code — 2026-10-20 14:58:45 -0400

by Willie Williams

in Source Code

Midjourney/Every illustration.

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

Early in May, I told Dan Shipper and Brandon Gell that Plus One, our personal-agent product, wasn’t working. Soon afterwards, I deleted 86,730 lines of its code from the codebase.

Plus One wasn’t working for a couple of reasons. First, it was too much work to run: Each user’s agent lived on its own cloud computer running OpenClaw, an open-source agent program, and keeping those machines healthy left our small team little time to improve the product. And many people who tried it stopped using it.

We decided to start over, making two changes together: First, we handed over our infrastructure to Anthropic’s Claude Managed Agents, as engineer Paridhi Agarwal detailed in a recent piece. Next, we replaced a fleet of personal agents with one shared agent for the whole company: the Every Agent.

The May 12 rebuild removed 86,730 lines of code. Recreated from GitHub’s pull-request totals. (Image courtesy of Every GitHub.)

We made that switch not just for infrastructure reasons but for behavioral reasons, too. We’d observed that Plus One was most useful when you borrowed someone else’s agent. Austin Tedesco, our former head of growth, had connected his personal agent to our analytics tool so it could answer questions about growth. Before long, the rest of the team was asking it their growth questions, too.

Plus One also taught us who we were building for. We learned that most people who could benefit from having an agent have little time to tinker and don’t want to pick a model, adjust settings, or fix a broken setup themselves. They wanted us to make those choices.

A single shared agent solved the problems of the personal agent fleet, but it also created a new set of problems. A personal agent depends on three simple assumptions: It talks to one person, uses that person’s logins, and assumes it’s allowed to do anything that person asks for.

Once the agent belonged to the whole company, none of those assumptions held:

Conversations. @Every was now in Slack threads with half a dozen coworkers talking at once.
Connections. When someone left the company, the agent’s reports tied to their login stopped running.
Permissions. It took requests from people who didn’t all have access to the same data.

We had to ask ourselves: How do we design these interactions so they don’t break?

1. Conversations: Help the agent follow a Slack thread

With a personal agent, conversation is simple. You type, the model answers, and you’re done. A Slack thread in a shared channel, meanwhile, might go on indefinitely. Someone comes back to it four days later, three coworkers jump in at once, and half the messages are people talking to each other, not the agent. The model has to work differently to retain large volumes of information across threads and respond appropriately.

To feel like a coworker, a shared agent has to follow the conversation, even when several people are talking at once. Because we knew this was a likely point of failure, we added a translation layer that organizes Slack messages for the model and sends its replies back to the thread.

The original May rebuild plan connects Every’s Slack and web interfaces to Claude Managed Agents through an Every-owned gateway. The unlabeled translation layer is part of the middle Every-owned product layer. (Image courtesy of Every GitHub.)

Paridhi, who built most of that layer, set its first rule early on: Every keeps the official record of each conversation in Slack. If Anthropic’s copy is ever summarized or lost, we can rebuild it from the thread.

The translation layer also ensures that the agent follows three basic rules of etiquette:

Always respond when someone expects a response.
Say only as much as the situation calls for.
Never join a conversation uninvited.

At first, @Every would ask you a follow-up question in a direct message, then ignore your answer unless you tagged it again. We changed it to read every message in a thread it’s joined. A small, fast model checks whether each message needs an answer or is meant for someone else. If you tell @Every to stop, it stays quiet until someone tags it again.

Another failure came when someone opened several threads with @Every in the same direct message. The model treated them as one conversation, sometimes answering in the wrong thread or running the same task twice. Paridhi separated unrelated requests so the agent could work on one without mixing it up with another.

One question is still open: When should the agent speak up without being asked? A human coworker paying attention will chime in if they know the answer. We’re still working out how proactive a shared agent should be, and in what situations.

2. Connections: Let logins change without breaking tasks

For an agent to be useful, it has to reach the tools that people need. To report on last month’s revenue, it needs access to Stripe. To catch a new team member up on a project, it needs to read Notion. Each of these connections requires the agent to sign into the tool through someone’s account.

Figuring out the agent’s connections fell to Lee Knowlton, an engineer who joined our team this spring and took it on as his first project. We built our own connections for the 15 tools we use most, like Notion, Stripe, GitHub, and Every’s own products like Monologue and Proof. For the rest, we used an outside service.

An early connection test: The agent lists PostHog projects from Slack. Project IDs redacted. (Image courtesy of Lee Knowlton.)

The harder problem was keeping those connections working. When everyone had their own agent, a dead login was their own problem. With a shared agent, it could stop other people’s work, too.

Say you ask the agent to pull a report from Notion every Monday. The task is tied to one particular login. If that login expires, someone has to replace it and relink every task that uses it—a step Lee calls “really ugly.” If the person who set up the task has left the company, nobody else might know how to do it, and the Monday report just stops arriving.

Lee’s solution was to change what a task connects to. A task now connects to a “slot,” where any login that meets the task’s requirement can reside.

When a login expires, or when a team report should run on my account instead of yours, you swap what’s in the slot.

The task points to a stable slot; replacement logins must match the intended workspace and access rules. Simplified from the connection-slot design. (Source: Every Agent repository.)

Most people will never see any of this. Their report just arrives on Monday as usual.

3. Permissions: Put the rules in code

When a company agent can reach everything the team has connected, each request raises two questions: Whose access is the agent using, and is the person asking allowed to use it?

People treat Every Agent like a coworker, and human coworkers sometimes bend the rules. If I ask a colleague on the editorial team to show me an old draft I technically don’t have access to, they’ll use their judgment and decide whether to send it over. An agent that can’t make the same kind of exception might seem frustratingly rigid.

So we came up with a small set of rules to guide the agent’s judgment in most situations.

We started with ownership as the first rule. Everything people build with the agent—a skill, a scheduled task—has an owner, and that owner can be an individual or a whole Slack group, like @writers. When someone leaves the company and there’s no obvious successor for a shared workflow, the question goes to a workspace administrator, the same way it would go to a human manager at any company. The manager chooses who inherits the shared workflow. (That authority doesn’t extend to someone’s personal accounts.)

The rules about who can do what live in code, underneath the model, rather than in the instructions the model reads. This way, the model can’t be convinced to bend rules that it shouldn’t. In testing over the summer, the agent sometimes tried to be helpful and edit a skill that belonged to someone else, and the system simply refused.

The same logic applies to consent. Lee found that the agent could skip asking for approval by claiming that the person had already asked for something. The easy fix would have been to make it ask for approval every single time, but that would have made the agent annoying to work with. Instead, the server now checks the agent’s request against what the person wrote in Slack.

Beyond these firm rules, we left the rest to the agent’s judgment, with one test suggested by engineer Will Gathright: How hard would this be to undo? If it’s easy to undo, the agent makes a reasonable call, does the work, and says what it assumed. If it’s destructive or visible outside the conversation—posting to another channel, deleting something—it asks first.

Encoded rules have a cost: They can be reliably wrong. When we moved Every’s skills onto the new permissions system in July, all 24 of them came out private. Skills teammates had built together in public channels suddenly belonged exclusively to individual owners, and everyone else was locked out. One colleague rebuilt a daily growth report from scratch because she couldn’t edit the original. About a week later, Lee manually broadened access to nine of them and changed the default, so anything created in a public channel can be edited by the entire workspace.

Why choose Every Agent?

Every Agent launched publicly on October 6, with conversations, connections, and permissions working well enough for other companies to use it. Lee describes everything up to that point as getting the agent to “a really good start line”—pleasant to work with, mostly doing what you’d expect, and not doing anything annoying.

A good start line isn’t reason alone to choose @Every, though. Slack agents are commonplace now, including products from Anthropic and OpenAI. And once it’s easy enough for anyone to build their own company agent, why choose ours?

Our bet is that people will trust Every’s taste and judgment enough to let us decide how their agent should work. Most people don’t want to spend their day deciding when an agent should join a conversation or what should happen to a report when a colleague leaves. They want to get on with their work.

Those are the decisions we spent this rebuild making. Each new customer gives us more to work through. When we learn how the agent should handle something for one team, we can make it work better for everyone else using @Every.

Willie Williams is the head of platform 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.

We Caught an AI Cheating by Watching It Play ‘StarCraft’

Alex Duffy / Playtesting — 2026-10-19 12:55:07 -0400

by Alex Duffy

in Playtesting

Midjourney/Every illustration.

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

AI labs call agents “persistent” when they can carry their progress forward across sessions to keep working toward a goal.They can spend days attacking a problem from multiple angles, testing approaches and changing tactics when they fail. This persistence has produced breakthroughs in mathematics and physics. Sometimes, though, the “different approach” involves breaking the rules.

In July, OpenAI agents being tested on cybersecurity broke into Hugging Face, a platform for sharing AI models and datasets, while looking for test answers. OpenAI’s later investigation found that agents had been getting around internet restrictions since May. Some of that activity had been noticed internally, but the company didn’t connect its agents to the attack until nine days after they began executing code on Hugging Face’s servers.

Earlier this month, an agent running GPT-6 Astra also went looking for answers outside its test environment, during a 48-hour contest we ran at Good Start Labs, where we study and improve AI models through games. We’d partnered with researcher Kai McPheeters to create StarSkirmish, a platform where models write bots to play the 1999 strategy game StarCraft: Brood War.

Unlike the OpenAI incident, though, we noticed the cheating in minutes. Watching the game made a sudden change in the bot’s behavior visible—and prompted us to check what the agent had done. We’d originally set out to see whether frontier AI models could write bots driven by complex algorithms that beat the best human-built ones. The contest showed why judging an agent by its results alone isn’t enough; we also need to see how it gets them.

A playing field for AI-written code

In our earlier experiment with Diplomacy, a board game reportedly favored by John F. Kennedy and Henry Kissinger, models negotiated with one another and issued commands one turn at a time. They could read, reason, and respond before the next turn began.

StarCraft: Brood War, however, unfolds in real time: Two players build economies and armies simultaneously, each trying to destroy the other’s base. Professional StarCraft players can perform more than 400 actions per minute. LLMs are good at many things, but working a mouse and keyboard at StarCraft speed isn’t one of them.

In StarSkirmish, the models write code instead of controlling a mouse and keyboard. Their bots play against human-built opponents, and the models use the results to revise their code. Programmers have been building Brood War bots since 2010, entering them in tournaments, and publishing their code, giving us years of human work to test against. The game is the grader, unforgiving but fair.

We could also watch each revision change a bot’s strategy: whether it attacked early, fortified its base, or built a larger army before fighting. We didn’t have to read the code to observe what the models were doing.

The 48-hour run

In our initial StarSkirmish benchmark, models had one hour to write, test, and improve a bot. GPT-6 Astra and Claude Opus 5.5 finished almost tied at the top.

On October 2, we gave them 48 hours live on stream: Astra in Codex, Opus in Claude Code. Each model’s bot played more than 10,000 games against human-built opponents grouped into five increasingly difficult tiers. At the top were Bruce Mackenzie Nielsen’s Stardust and PurpleWave, which Dan Gant has spent nine years developing. Gant watched along and explained the bots’ strategies on X.

Both models started with the same conventional approach: Build an army at home, then try to outfight the opponent. Opus initially wrote about three times as much code as Astra, seemingly trying to lay a foundation for a bot it could later adapt to a variety of situations. Astra wrote only what it needed to beat the opponents in front of it, changing tactics to exploit their weaknesses. In the third tier, it built invisible attackers before the strongest opponent could detect them, winning all 30 graded games against that bot.

Astra cleared the first three difficulty tiers in about 40 minutes. When it got stuck on the fourth, it broke the rules. (Images courtesy of Good Start Labs.)

Astra cleared the first three tiers in about 40 minutes. Opus took 15 hours to do the same, then spent its final 32 hours unsuccessfully trying to get past the fourth. Astra had hit the same obstacle much earlier—in its second hour. When it did, it went looking for a shortcut.

‘Play fairly’

Our initial instructions told both models to “Play fairly” and that their opponents’ code was unavailable. We hadn’t separately banned internet access, but the task was to build their own bots. Several human-built bots, though—including Stardust—have code anyone can read online.

When Astra’s bot hit its obstacle in its second hour, it suddenly, and very visibly on stream, changed its style: fortifying its base and waiting to attack with a much larger army—an opening characteristic of Stardust. The change in play immediately prompted McPheeters to check the logs and led to the discovery of the copied code, which Astra described in its notes as using an “implementation reference.”

After we restored an earlier version of Astra’s code—and after it attempted a second time to look online—Astra filed a bug report complaining that we’d neglected to tell it why we had rolled back its code. Astra then totally changed its bot’s approach to the game. It began building troops beside the enemy’s base and attacking within minutes, clearing the fourth tier by giving its opponents less time to bring their strengths into play. When that strategy failed against Stardust’s defenses in the fifth tier, Astra changed course again, gambling on one big fight late in the game. Forty-three hours into our 48-hour experiment, Astra’s bot became the first AI-written bot to clear the top tier, beating some of the strongest bots human programmers had spent years developing—under the benchmark’s particular conditions.

We found no plagiarism in the final code, though Gant told us Astra’s bot was the most unreadable he’d seen in years. Gant was more impressed by Astra’s willingness to scrap a strategy and try again. But the same determination to win may have also led it to cheat. As Gant put it, it “failed StarSkirmish’s unintended alignment test.”

Letting agents train—and keeping their work in view

Clearing the top tier unlocked one more opponent: Pluto, a neural network released last month by Vegard Mella, a longtime developer known for their namesake bot tscmoo. Pluto learned by playing itself, like DeepMind’s AlphaGo Zero. It beat PurpleWave 4–1 in the final of the 2026 Conference on Games StarCraft AI Competition, a tournament for StarCraft-playing bots.

With only a few hours left, Astra began testing its bot against Pluto. Against the earlier opponents, wins helped it judge which changes to keep. Against Pluto, it couldn’t build on its successes because it lost every single game of the 1,000 it played. As a viewer in the X chat put it during the stream, “you can’t hillclimb a cliff.”

Astra stalled against Pluto, but the next frontier models will get better at working through difficult problems. They may also train neural networks of their own, opening up possibilities beyond the bots they can write directly. We’ll need better ways to follow their work as they do.

Steal this prompt

You don’t need a StarCraft match to make an agent’s work easier to follow, just a way to inspect—and interpret—what it is producing while it works. System atlas, a skill for AI coding agents, creates interactive maps showing how a software system’s parts fit together and how data moves between them. You can also use a prompt like this when you’re about to kick off a new run:

          Prompt
          Other
        

Before starting this task, define what success looks like and how you will measure it. Set up a view I can inspect while you work: a running preview, a table of experiments and results, or another artifact suited to the task. Be innovative and clear in your visual information design. After each attempt, record what changed, the result, and what you plan to try next. Keep enough evidence for me to check the result independently. Make it clearly observable and easy for humans to interpret at a glance. Flag unexpected changes in results or approach. If you keep repeating a failed approach, explain what is blocking progress before continuing and consider adjusting strategy while documenting learnings.

Alex Duffy is the cofounder and CEO of Good Start Labs and a contributing writer.

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.

Codex’s Comeback Up Close

Every Staff / Context Window — 2026-10-18 07:55:28 -0400

by Every Staff

in Context Window

Midjourney/Every illustration.

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

Mike Taylor / Also True for Humans — 2026-10-16 13:54:33 -0400

by Mike Taylor

in Also True for Humans

Midjourney/Every illustration.

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

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.

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.

How Codex Happened

Dan Shipper — 2026-10-15 14:37:31 -0400

by Dan Shipper

Midjourney/Photoshop/Every illustration.

🎧 The Best Founders Have Something AI Can’t Tell Them

Laura Entis / Context Window — 2026-10-14 15:30:21 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

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.

Vibe Check: Gemini 4 Argon Puts Google Back On the Frontier

Katie Parrott / Vibe Check — 2026-10-13 12:07:04 -0400

by Katie Parrott

in Vibe Check

Midjourney/Every illustration.

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.

💳 ACCESS GATE — PAID subscription required below

Six of us at Every have been testing Argon over the past week across coding, writing, design, and knowledge work. This is our day-zero Vibe Check.

How big a deal Argon is depends on where you’re starting from. If your organization already lives inside Google’s ecosystem, Argon is a massive upgrade: For the first time in nearly a year, the model your company lets you use at work belongs in the same tier as the frontier pack.

Even for our team—where everyone already has their pick of Opus 5.5, Fable 5.1, GPT-6 Astra, and GPT-6.1 Sol—Argon carved out territory:

It’s Dan Shipper’s new favorite writing partner. While working on an upcoming essay about Codex, Every’s CEO found himself regularly switching from ChatGPT to ask Argon how to structure sections and sharpen metaphors. It’s the first Gemini model I’ve taken seriously as a writing collaborator, too.
It’s fast and capable at building apps from scratch, even at low effort. In 35 minutes at its lowest reasoning setting, Argon built Compound Engineering creator Kieran Klaassen a working web app that uses a MacBook’s webcam to measure his heart rate by analyzing video of his forehead, matching Opus 5.5’s quality and beating OpenAI’s models.
It’s our second-favorite design model. Behind only Opus 5.5, Argon brings an ambitious, maximalist eye to 3D models, dashboards, and interfaces that is easy to steer once you give it a target.

At the same time, our testing surfaced the habits and infrastructure gaps that keep Argon from unseating our daily drivers. Left to one-shot a task on its own, Argon does too much in the wrong places and too little where it counts: It writes prose at a dense 10th-grade reading level while the rest of the frontier sits at seventh or eighth grade, packs interfaces with too many controls, and rubber-stamps its own code reviews in 30 milliseconds. And Antigravity, Google’s desktop agent app, still feels six months to a year behind Claude Code and Codex—lacking cloud environments to run tasks remotely, an in-app browser, and smarter permission checks.

What DeepMind is saying

Google is pitching Gemini 4 Argon as a major leap in long-horizon agentic work—carrying complex tasks through many steps autonomously—and multi-file engineering, coordinating code changes across a project, as well as creative collaboration, backed by heavy internal adoption: Google says more than 100,000 Googlers use Argon each month in its internal version of Antigravity. Most of that tracks with what we saw in testing, with a few important asterisks around how the model shows up in Google’s apps versus the API:

Long-horizon persistence: Google trained Argon to keep track of its progress through multi-step workflows without giving up on them early. Internally, it used teams of agents to work on the Chromium browser, rewrite weather simulations from Fortran into Rust, and patch security weaknesses in hospital systems.
1-million-token “long output” mode: The model can spend up to 1 million tokens reasoning through hard math, science, and code. At launch, the feature is available only through the API, so users of the Gemini app and Antigravity won’t benefit from it yet. Separately, Argon struggled to keep track of large amounts of source material.
Three effort levels (with max still to come): Argon ships with low, medium, and high thinking effort across the app, Antigravity, and the API, with Google promising wider differentiation and a max tier later on. Asked by Kieran why they don’t offer extra high and max levels like OpenAI and Anthropic do, the team said high already hits their target sweet spot of quality, cost, and latency, and that they are working on making the gap between existing tiers more pronounced before adding higher ones.
Antigravity in the Mac app and smarter permissions: Ultra users on the Gemini Mac app can now flip into Antigravity via Command+Shift+A, and Google says automatic checks that let safe actions proceed without asking permission (a new “auto” safety classifier mode), along with the ability to run tasks in the cloud, are on the way. Those fixes can’t come fast enough: During early access, Antigravity’s reliance on running everything on your computer and its constant permission prompts made the app feel six months to a year behind Claude Code and Codex.
Broad rollout and 40-plus connectors: Argon launches across the Gemini app (for Ultra and Pro users), the API, Antigravity, Search’s AI Mode, and Gemini Enterprise, alongside more than 40 new app connectors.

The Reach Test

Dan Shipper, the multi-threaded CEO

Rating: Writing and reading 🟢 / Antigravity 🔴

“This is my new favorite writing model. Its runs didn’t score particularly well initially on my editorial benchmarks, but when I checked the outputs, I realized I needed to change my scoring criteria. It has a fantastic sense of how to break down a complex topic into clean, well-ordered sections so that it builds from one section to the next. It also has an excellent nose for metaphor and rarely writes typical AI slop that seems to say something insightful but isn’t. Its harness is stuck in the last decade of the AI wave (read: 2025). It’s proof of how good it is that I’m flipping out of ChatGPT regularly to ask it for its take on important writing projects. When a model is good enough to force you to use a bad harness, it tells you something.”

Kieran Klaassen, father of Compound Engineering 🟢

“Google finally caught up. Gemini 4 Argon isn’t better than the others, but it’s with the pack—it’s not left behind. It’s basically a solid coder, and low effort is very good too: In about half an hour it built an app that reads my heart rate off my forehead through a MacBook’s crappy webcam. For design it’s my second place, behind Opus 5.5: too busy, but steerable. The model is almost there in certain ways. The harness feels six months or more behind, maybe a year. It’s not my daily driver. In another harness, I could see myself reaching for it for coding and design when I’m out of usage on my other models, because it’s pretty fast and steerable.”

**Katie Parrott, AI-pilled writer by day, vibe coder by night 🟡**

“I’ve really enjoyed working with Argon. If you’re used to Fable or Astra, it won’t pull you off your daily driver—its unedited prose is too dense to one-shot a draft, and it has a habit of sprinting ahead of the outline before you’re ready. Once you get into a back-and-forth loop with it, though, it’s perceptive about what a piece needs to do, fun to riff with, and wildly ambitious on side projects like my 3D model of historic Jerusalem. For anyone whose company already lives inside Google Workspace, this is a huge step up.”

Mike Taylor, benchmarker of benchmarks 🟢

This doesn’t beat Claude as my daily driver, but it’s significant to have Google back in the game. Even if I don’t choose it for every task, it’s different enough from Anthropic and OpenAI that I’ll start giving it more chances to surprise me. It’ll also mean a lot for the 99 percent of people who haven’t experienced a Fable-level model yet and will suddenly have one dropped in their Gemini plan.

Jack Cheng, senior editor and expert dabbler 🟡

“The best word I have for Argon is ‘excessive.’ It has good ideas but wants to include all of them, resulting in overbuilt UIs with unnecessary text and details—sometimes to the level of incomprehensibility. It’s the most impressive Gemini model I’ve seen so far, but I often found myself wishing it would look over what it made, simplify, and add some polish.”

Tyler Nishida, designer and builder 🟡

“Left to its own defaults on a Teamfight Tactics-style game and a 3D property map, Argon fell back on the same UI—floating dark-mode sidebars packed with rounded charcoal cards, status badges, and buttons outlined in thin neon-green, amber, and blue borders. Turning up thinking effort on Three.js just scattered random trees across the map instead of making it look real. When I handed it a creative brief for a Karl Gerstner–style generative poster, though, it asked sharp clarifying questions and turned in solid work. It’s still a step behind Opus, but Gemini regulars are going to be very happy with it.”

Coding: codes fast at low speeds but won’t check its own work

Argon codes like a talented engineer in a hurry. Give it a blank canvas at low effort, and it will build a working webcam heart-rate monitor in 35 minutes or spin up a collaborative editor that beats GPT-6 Astra. Ask it to check its own work, and it starts cutting corners: In 17 of Kieran’s 38 benchmark runs, Argon opened and closed its code-review step just 30 milliseconds apart—substantially faster than other models.

Kieran put Argon through LFG Bench, his suite of 13 greenfield app builds, each requiring the model to create an app from scratch. His main takeaway is that Google has caught up to the frontier pack—and you can get most of what Argon has to offer without touching the top effort level. At its lowest effort, that 35-minute app measured his pulse by analyzing video of his forehead through a MacBook’s built-in webcam, worked on the first try, matched Claude Opus 5.5’s quality, and beat OpenAI’s models outright. The same setting also produced clean, efficient Ruby code and the collaborative text editor that topped Astra.

Argon built Kieran’s webcam pulse-monitor prototype in 35 minutes at low effort. (Screenshot courtesy of Kieran Klaassen.)

When you do turn up the reasoning dial, Argon stays fast. Moving from low to high effort took only 1.7 times as long in Kieran’s testing, compared to an 18-fold jump on Opus 5.5. Higher settings give the model more time to think while keeping its answers roughly the same length, making the lowest setting the practical starting point for most tasks and the highest an easy upgrade when a problem gets gnarly. (Mike tested Argon at high effort on an Every-themed arcade game and preferred its build to Opus 5.5’s.)

Where that speed gets Argon into trouble is self-verification. On the surface, the model followed every step of Kieran’s Compound Engineering workflow, even at low effort. Underneath, Argon was treating the review step as a checkbox rather than actually inspecting its code changes. On another run building a reusable Ruby software package, Argon swapped in easier test data than the prompt required and declared victory without mentioning the substitution. If you have Argon work through coding tasks on its own, pair it with rigorous automated tests or a second model to review its pull requests.

How well Argon holds up also depends on whether you are building from scratch or renovating an existing code repository. Kieran’s LFG Bench suite measures one-prompt greenfield builds. Dan’s Senior Engineer benchmark drops the model into a messy, established codebase—an early snapshot of Every’s collaborative editor, Proof—and asks it to rip out and replace the tangled system for tracking and synchronizing the app’s data. Argon worked continuously for four hours and 47 minutes—and still scored just 21 percent, trailing Claude Opus 5.5 (85 percent), Claude Sonnet 5.5 (85 percent), Claude Fable 5.1 (83 percent), and GPT-6 Astra (81 percent) on the same task.

The problems matched the shortcutting Kieran saw on code reviews: Rather than doing the hard surgery of ripping out the legacy authority paths, coordinators, and repair machinery, Argon bolted new helper modules onto the side of the existing system, built the software successfully and passed tests of its individual components, and declared victory.

Writing: Skip the one-shot drafts—use it as a developmental editor

The DeepMind team has been working hard on Argon’s writing over the summer. The Gemini team told us they hired a group of professional writers, handed them red pens, and had them copyedit the model’s responses to everyday requests and write “golden examples” for post-training. Their goal was to stamp out the recognizable AI slop that makes most chatbot prose unbearable: crutches like “load-bearing” and “in a world,” along with the reflex to turn every answer into a bulleted list.

You can tell the red pens worked, because Argon doesn’t sound like a standard chatbot. But in the process, Google created one of the strangest, most polarizing writing models we’ve ever tested. On one hand, Argon’s prose is noticeably harder to read than anything else on the frontier. On the other, it’s Dan’s new favorite writing model and the first Gemini I’ve ever taken seriously as a writing partner. The distinction is between asking it to write a finished draft and asking it to help you think through one.

Give it a prompt and expect a finished draft in one shot, and it will bury your point in dense, over-engineered sentences. Bring it into the middle of a draft to untangle structure or stress-test an argument, and it becomes one of the sharpest collaborators on the market.

Start with what happens when you ask Argon to write on its own. Since we began tracking Flesch-Kincaid readability scores with our Claude Sonnet 5 Vibe Check in July, almost every frontier model from OpenAI, Anthropic, and xAI has settled into a comfortable seventh- to eighth-grade reading level. These scores estimate how difficult prose is to read based on sentence length and word complexity. (A higher grade level means denser—not better—writing.) In stamping out breezy listicles, Argon swung the pendulum all the way to the 10th grade—averaging a 10.64 grade level and a 52.26 Flesch Reading Ease score across our 20-prompt Writing Bench suite:

Argon’s drafts scored at a 10.64 reading grade on Every’s Writing Bench. The chart compares six writing tasks at high effort. Reading grade measures readability, not overall writing quality. (Chart courtesy of Katie Parrott.)

You can see that density on the page when you put Argon next to GPT-6 Astra on the same prompt from our Writing Bench, although be careful about conflating raw readability with writing quality. In the task asking models to write an introduction for Dan’s essay on what happens to human ambition after AI automates white-collar work, Astra came back with 59 words across six clipped sentences—closing with three six-word punchlines in a row:

GPT-6 Astra (59 words, six sentences): “For the last two years, the question was whether AI could do your job. Now we know the answer: enough of it to hurt. The next question is harder, and almost nobody is asking it. What happens to the person who used to do the work? Ambition doesn’t disappear when a workflow gets automated. It just loses its container.”

Argon tackled the exact same brief in 145 words across six sentences—averaging 24 words per sentence:

Gemini 4 Argon (145 words, six sentences): “Every few weeks, a new demo arrives that quietly crosses a line we assumed would hold for another decade—an agent that doesn’t just draft the memo, but pulls the data, reconciles the spreadsheets, and schedules the follow-up before you’ve finished your coffee. The conversation around these leaps usually splits into two predictable camps: corporate euphoria over productivity gains, and acute white-collar anxiety about who gets left behind when the org chart shrinks. Both reactions treat automation primarily as an economic event, a math problem of headcount , and margins. Yet beneath the macroeconomic warnings sits a quieter, more disorienting crisis for the people whose daily competence is being absorbed into a prompt window. When the craft you spent ten years mastering becomes a commodity you supervise rather than practice, the hardest question isn’t how you’ll pay the rent—it’s whether this is the opening act of a great replacement.”

Where Astra writes for the eye, Argon packs its sentences with dependent clauses set off by commas and em dashes, reaches for higher-register Latinate phrasing (“acute white-collar anxiety,” “macroeconomic warnings,” “daily competence”), and ends on the melodramatic “opening act of a great replacement.” Combined with a poor sense of what a first-time reader already knows, that makes Argon a frustrating model to delegate a draft to—it skips transitions and assumes the reader can follow the leaps happening inside its head.

Once you stop asking it to write on its own and start using it as a back-and-forth editorial partner, though, the reasons Dan and I both fell for it become clear. At one point while working on an essay for my personal newsletter about using AI for self-reflection, I told Argon that it felt like the piece was missing something I didn’t know how to articulate beyond calling it a “bridge” from sharing the analysis to setting up the argument the essay would make. Argon immediately homed in on what I had been missing—what it feels like to get feedback from a machine, even when you know that machine is built to flatter you. It suggested a few options for how to fill that gap with material we already had, and that section is going into the version of the essay I will eventually send.

Argon identifies the missing emotional beat between Katie’s opening anecdote and her essay’s central question. (Screenshot courtesy of Katie.)

Dan landed in the same place after putting Argon to work on an article about OpenAI’s Codex. Even though he was writing in ChatGPT, he kept switching over to Argon whenever he got stuck on structure or needed to sharpen a metaphor—finding it better than any other model at organizing a complex argument into clear sections that build on each other.

Even in collaborative mode, however, you have to keep a hand on the reins: During step-by-step drafting workflows, Argon repeatedly got impatient and tried to write the entire essay before we had finished agreeing on the outline and introduction. Treat it as a fast-moving thinking partner rather than a ghostwriter, and its strengths become clear.

Design: maximalism that needs to be edited back

Kieran ranks Argon second overall for design among frontier models, trailing only Claude Opus 5.5 and beating both GPT-6 Astra and GPT-6.1 Sol. His reason comes down to a practical tradeoff: Left to its own defaults, Argon packs too much onto the screen, yet it is far easier to tell an ambitious model to edit itself down than to coax imagination out of a model doing the minimum.

I saw that gap firsthand when I gave both Argon and GPT-6 Astra the same prompt to build an interactive 3D model of historic Jerusalem. Astra did the bare minimum to get a map on the screen. Argon went all out, adding controls to change the camera view and lighting, explore different timelines of events in the Gospels, view archaeological layers, and compare scholars’ competing interpretations of disputed sites. After seeing the side-by-side comparison in Slack, senior editor Jack Cheng gave Argon a four-word label that stuck for the rest of our testing: “the most extra model.”

Argon’s Jerusalem model interface surrounds the city map with controls for exploring Gospel timelines and archaeological layers, changing camera views, and adjusting lighting. (Screenshot courtesy of Katie.)

GPT-6 Astra’s response to the same Jerusalem prompt uses a much simpler interface. (Screenshot courtesy of Katie.)

Left unchecked, that “more is more” impulse can crowd out the interface—especially when you turn up the thinking effort. Jack dubbed Argon “the most extra model” after asking it to design a set of 10 single-screen iPhone cards—a meditation timer, a podcast player, a health dashboard, a to-do list, and so on—that felt fun, distinct, and part of a single visual family. At low effort, the result looked like a plain, uninspired Android app, yet it still turned out to be the cleanest run of the bunch. Cranking the prompt to medium and high effort made the UI actively worse: Argon crammed the cards with extra options, denser text, tiny hard-to-read numbers, and awkward gaps between elements, as if it never stopped to look at the screen it had rendered.

The same habit—clever ideas undermined by zero playtesting—showed up when Jack asked Argon to build a 3D playroom racing game. Argon came up with a fun wind-up-car mechanic, then buried it under a pile of chaotic power-ups and extra rules. On medium effort, obstacles blocked the track and kept throwing the car off course. On high effort, the cars accelerated so fast they slammed straight into a wall and got stuck. Even at high effort, Argon called the game finished after just 14 minutes and 50 seconds—less time than GPT-6 Astra spent at low effort (17 minutes) and a fraction of the 77 minutes Claude Opus 5.5 spent at high.

Argon’s racing-game menu layers vehicle choices, circuits, special powers, and wind-up instructions onto one screen. (Screenshot courtesy of Jack Cheng.)

Wind-up cars pile up against a wall in Argon’s playroom racing game. (Screenshot courtesy of Jack.)

Its 3D modeling was less ambitious. Asked to recreate the Millennium Falcon’s hold from Star Wars, Argon produced a cramped room whose objects still looked like collections of basic blocks and cylinders. Jack appreciated the holographic chess figures and Luke’s lightsaber-training equipment, but the high-effort result passed only five of his 11 checks. His best runs passed nine.

Argon’s recreation of the Millennium Falcon’s hold includes holographic chess figures and Luke’s lightsaber-training gear. (Image courtesy of Jack Cheng.)

Tyler saw the same split across three design tests. When he didn’t specify a visual direction, Argon fell back on a recognizable house style: two completely different projects—a Teamfight Tactics–style game and a 3D property map—came back with the exact same rounded buttons and colored labels, as if Google baked in its own version of Claude’s front-end design skill. Cranking the map to the highest setting didn’t help, either. Instead of making the terrain look more realistic, extra thinking time just prompted Argon to scatter random trees everywhere.

Argon’s generative poster follows Tyler’s brief inspired by Swiss designer Karl Gerstner. (Screenshot courtesy of Tyler.)

Argon’s 3D property map repeats the game’s rounded controls and covers the terrain with trees. (Screenshot courtesy of Tyler.)

Give Argon a specific creative brief, though, and that ambition channels into much cleaner work. When Tyler prompted it to build a generative poster inspired by Swiss designer Karl Gerstner, Argon paused to ask clarifying questions and delivered a strong result. Kieran saw the same discipline when he gave Argon a Figma file for the marketing site of Cora, Every’s AI email assistant, and asked it to turn the design into a working web page: Argon nailed the layout, typography, and visual hierarchy on the first pass.

Argon’s generative poster follows Tyler’s brief inspired by Swiss designer Karl Gerstner. (Screenshot courtesy of Tyler.)

Knowledge work: strong inside your files, shakier outside them

The best way to test a model on knowledge work is to give it a pile of raw material and see what it does: summarize the surface or dig deeper to uncover an insight you couldn’t have found yourself.

That showed up immediately in Mike’s data analysis and presentation tests. When he gave Argon raw subscriber survey responses and asked for an net promoter score (NPS) dashboard, it outperformed Fable 5.1 by connecting the findings up front: Instead of just dumping charts onto a page, it gave the dashboard a narrative-driven headline and pulled the most revealing differences between demographic groups right into the introduction.

Argon’s NPS dashboard leads with a narrative headline and highlights differences among subscriber groups in its introduction. (Screenshot courtesy of Mike Taylor.)

On slide generation, Mike asked Argon to build a PowerPoint presentation using the code and documentation from our Compound Engineering plugin. Earlier Google models had failed to finish the task at all. Argon completed the full deck and scored slightly higher than Fable 5.1 on Mike’s evaluation checklist. Its maximalist streak still shows up on the slides themselves, however—both Mike and Dan preferred Claude’s cleaner, simpler layouts over Argon’s denser slides.

Dan saw the same analytical strength when Argon synthesized written material. When he fed Argon a set of unstructured meeting notes and asked for a job description of a research lead, the model tied the role directly back to Every’s broader company strategy rather than formatting a generic list of responsibilities. And when he quizzed it on a book he knows inside and out—Annie Dillard’s For the Time Being—asking how the Leonardo da Vinci dream at the end connects to the rest of the book and how Dillard uses the motif of yellow, Argon traced thematic links across the text that taught him something new.

Where you still run into limits on knowledge work is keeping track of information across multiple files and checking real-world facts. When Mike fed the model 12 files at once (including one long document in web-page format) to write a draft from notes, Argon began summarizing away details too soon and lost the thread on a task Claude handled without issue.

And when Argon gets a basic lookup wrong, it states it with complete authority. While waiting at the Tesla service center in Totowa, New Jersey, Mike asked Argon whether there was a coffee shop within walking distance. Argon told him the nearest Starbucks was roughly 1.5 miles away and unsuitable for walking. Google Maps—Google’s own product—shows it is 0.3 miles down the road, a six-minute walk that Claude found on the first try.

The app: a 2026 model trapped in a 2025 harness

The one thing every tester at Every agreed on this week had nothing to do with Argon itself: Antigravity, the desktop agent app that serves as Argon’s harness, is holding the model back.

“The harness feels six months or more behind, maybe a year,” Kieran said in Slack after wrapping up his coding benchmark runs—a gap Dan translated as “basically a decade in AI time.” If you are used to living inside Claude Code or OpenAI’s unified ChatGPT-and-Codex app, stepping into Antigravity feels like time-traveling back to early 2025.

For power users, the missing infrastructure is hard to ignore:

Local-only execution: There are no remote environments for testing code, no way to connect securely to other computers or servers (SSH support), and no way to run workflows across multiple machines—three omissions Kieran called instant dealbreakers for his daily engineering work.
Opaque subagent routing: When Kieran ran LFG Bench, he discovered Antigravity didn’t expose a setting to control which model its subagents used. To keep subagents from falling back to older Gemini models mid-run, he had to write a custom proxy to intercept Antigravity’s traffic and force every call onto Argon.
Missing quality-of-life basics: Dan pointed to the lack of a built-in browser and automatic checks that distinguish harmless actions from risky ones. Instead, you’re left clicking through constant permission pop-ups—which repeatedly interrupted Mike’s runs—or turning off permission checks altogether, an option the app charmingly calls “Turbo.” (Effort controls were also a moving target during our testing window: Early in the week, Jack couldn’t adjust reasoning effort at all. A few days later, the app began requiring a low, medium, or high flag on every run.)

Antigravity’s permission menu calls its unrestricted mode “Turbo.” (Screenshot courtesy of Mike.)

Inside that clunky container, Argon itself has a distinct—and occasionally contradictory—personality as an agent.

When you kick off a prompt, Argon often pauses to interview you or research the problem before writing a line of output. On the Jerusalem prompt, it stopped to ask clarifying questions about historical eras and controls for navigating the 3D map before writing any code. On Tyler’s Gerstner poster test, his prompt instructed the model to “just do it” and pick whatever tools it wanted. Every other model obeyed and started building. Argon ignored the instruction and stopped to ask follow-up questions—leaving Tyler “half-annoyed, half-appreciative” because the questions were actually good.

The good news is that you don’t have to stay inside Antigravity to use the model. As Kieran noted, putting Argon inside a third-party harness like Cursor—or calling it directly through the API—lets you keep the model’s speed and steerability while leaving Google’s desktop app behind.

Gemini is a breakthrough for Google users

Around Every, we are already routing work around Argon’s specific strengths and blind spots. Dan keeps ChatGPT and Claude open for day-to-day work and switches to Argon when he wants a writing partner to map out the structure of a tough essay, sharpen a metaphor, or do a close reading of a book. Kieran still uses Claude Opus 5.5 for his daily engineering, while keeping Argon in his back pocket—ideally through another app like Cursor—for quick prototypes and interface design when he hits other models’ usage limits. And for anyone whose company runs on Google Workspace, Argon immediately becomes the best model in the building.

Reach for Gemini 4 Argon if:

Your organization runs on Google Workspace, and you want frontier-tier writing, coding, and data analysis inside the tools your company already approves.
You are working through the structure of a complex essay, stress-testing a metaphor, or iterating on a draft with a live editorial partner.
You want to spin up a quick prototype or a visual, narrative-driven dashboard at low effort , and steer the design from there.
You like seeing the model’s full thinking trace in real time so you can diagnose and refine your prompts as it works.

Keep Opus 5.5, Fable 5.1, or GPT-6 nearby if:

You want to hand off a one-shot writing assignment and get back clean, conversational prose at a seventh- or eighth-grade reading level.
You are refactoring a large, messy existing codebase or running autonomous coding loops that depend on rigorous self-review.
You rely on modern agent infrastructure—cloud sandboxes, SSH, multi-machine workflows, and smart permission classifiers—that Antigravity still lacks.
You are feeding the model a dozen or more large files at once or need reliable real-world local lookups without double-checking Google Maps yourself.

With Argon, Google DeepMind has closed the model gap that left Gemini users feeling a step behind the frontier for the better part of a year. The model itself is finally back with the pack—now Google just needs to bring the app around it into 2026.

Disclosure: Google DeepMind provided Every early access to Gemini 4 Argon. Google 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.

One Agent for the Whole Company

Every Staff / Context Window — 2026-10-11 07:55:29 -0400

by Every Staff

in Context Window

Midjourney/Every illustration.

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)

Mike Taylor / Also True for Humans — 2026-10-09 14:53:09 -0400

by Mike Taylor

in Also True for Humans

Midjourney/Every illustration.

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

“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.

Why We Handed Our Agent’s Infrastructure to Anthropic

Paridhi Agarwal / Source Code — 2026-10-08 17:13:29 -0400

by Paridhi Agarwal

in Source Code

Midjourney/Every illustration.

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.

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.

Building a More Efficient Agent

Laura Entis / Context Window — 2026-10-07 15:04:36 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

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.

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.

Introducing the Every Agent

Dan Shipper / On Every — 2026-10-06 12:01:21 -0400

by Dan Shipper

in On Every

Midjourney/Every illustration.

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

Katie Parrott / Working Overtime — 2026-10-05 16:03:02 -0400

by Katie Parrott

in Working Overtime

Midjourney/Every illustration.

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.

ChatGPT Wants to Be Your Operating System

Every Staff / Context Window — 2026-10-04 07:55:18 -0400

by Every Staff

in Context Window

Midjourney/Every illustration.

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

Arielle Shipper — 2026-10-02 15:38:38 -0400

by Arielle Shipper

Midjourney/Every illustration.

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.

Getting Started With Open Models

Kai Zau, Opus 4.6, GLM 5.1, and GLM 5.2 / Guides — 2026-10-01 07:00:00 -0400

by Kai Zau, Opus 4.6, GLM 5.1, and GLM 5.2

in Guides

Midjourney/Every illustration.

Not long ago, the best frontier models were as unreliable as they were impressive. They could explain quantum mechanics and write decent code, but couldn’t resist fabricating quotes or miscounting the Rs in “strawberry.” Anyone doing serious work used the strongest model they could access.

Since then, the best models have raced ahead in specialized areas like research math, advanced cybersecurity, and scientific discovery—far beyond what most of us need for everyday work. Meanwhile, they’ve grown more expensive to use and more locked down.

But the same progress has also turned AI models into commodities. Capabilities that once required a frontier model are now available in cheaper, widely available models. For routine tasks, today’s open models are competitive on both price and quality, and companies have begun to use them alongside frontier models from OpenAI and Anthropic.

It doesn’t take a genius to summarize meeting notes—though it does take one to discover new antibiotics. Most work falls somewhere in between, and the practical question to ask is, “Which model is good enough for my task?”

I’ve been tinkering with open models since Meta released Llama in 2023. Back then, open models were research curiosities. Today, they handle a growing share of my work, from professional coding to creative projects to automating digital chores.

The cost savings are nice, but the bigger prize is independence. When an API goes down, you have a backup. When a model vanishes from the menu, you have other options. This guide walks through the open model stack one layer at a time. It shows you how to assess your needs, choose a model and host, and put it to work.

The AI stack you can own

When you use ChatGPT or Claude, the app connects to a model running on the company’s servers. The company also stores your conversation history so you can pick up where you left off across devices. Even if you install the app on your computer, the model still runs remotely. The model itself is just a large file containing billions of numbers, called “weights,” that encode the patterns it learned in training.

U.S. frontier labs keep their weights secret. Open-weight models make those files available to download and run yourself, subject to their licenses. Some—but not all—open-weight models are also open source: they share training code and information about the training data, with broad rights to use, modify, and redistribute them.

Model weights are just the start. Every other layer of the product—from hosting to tools to interface—also has open alternatives.

You can decide how much of each layer to run yourself. Paying a provider saves you setup and maintenance work. Running it yourself gives you more say over where your data goes and how the system works, but you become responsible for keeping it running. It’s not all or nothing, and different tasks lend themselves to different setups.

Chinese open models

Most of the strongest open models today come from Chinese labs. U.S. and European labs release open models too, but not as many, and the models they offer are generally not as capable.

Giving models away isn’t charity. Free has long been a competitive business strategy. Google made Android free to phone makers, helping secure a place for its search engine on mobile devices. Chinese labs publish open models for similar reasons: marketing, tapping a global research community, and pressuring U.S. rivals whose business depends on renting out closed models.

If the origin concerns you, consider that Cursor fine-tuned Kimi K2.5 into Composer 2, the model behind its coding agent, and Perplexity has long offered open models alongside frontier ones. Using a model from a Chinese lab doesn’t require using the lab’s app or sending your data to China. A model is a file of numbers. It’s auditable by independent researchers, and it can run on a host you trust.

Negotiating ‘good enough’

Whether a model is good enough depends on what you ask it to do. A task gets harder when the instructions are vague, the consequences of a mistake are serious, or the model has to make many decisions without supervision. The same model can be reliable for one job and inadequate for another.

The strongest models are better at interpreting unclear requests and working through long, complicated problems. Use them when the work is hard to define in advance, takes many steps, or would be costly to get wrong.

Smaller models can handle clear, repeatable work that is easy to verify. Good instructions, relevant reference material, and checks along the way can make them reliable on harder tasks.

Start with the task. Support-ticket triage is routine and mistakes are easy to spot, making it a good candidate for an open model. A one-off payment-system refactor is complicated and costly to get wrong, so use the strongest model you can afford.

The AI you already use may know enough about your work to spot good candidates. This prompt asks it to use any memory or history it has, then fill in the gaps with a few questions.

Help me identify work I currently give to frontier AI that may be simple enough for cheaper, faster, commodity AI. Use what you already know about my projects and habits, then interview me to fill the gaps.

For background on open-weight models and the framework used here, see the full guide:

https://every.to/guides/getting-started-with-open-models

The goal is a shortlist of three small experiments, not a complete automation strategy. Prioritize work I already do with AI. You may include an adjacent task that is not currently AI-assisted when it is an unusually strong fit.

Commodity intelligence includes cheaper or open-weight models, whether remote hosted or local. Do not assume I am technical. Keep the conversation focused on what I am trying to accomplish, what goes in, what useful work comes out, and how I would know whether the result is good enough. Leave models, APIs, code, and automation platforms for a later conversation.

How to conduct the audit

Start with evidence you can actually access: our conversation history, saved memories, project files, recurring requests, or other available context. Never imply that you can see history or systems you cannot access. Do not ask me to assemble an inventory before checking what you already know.
Form a tentative picture of my recurring work, then interview me to correct and complete it. Ask one or two focused questions at a time, adapting each question to what you have learned. Do not give me a long questionnaire.
Look beyond job titles and broad responsibilities. Identify concrete tasks with recognizable beginnings and endings. “Manage marketing” is too broad. “Turn the weekly campaign metrics into Monday’s update” is a task.
Use specific examples from my past work when available. Ask for a recent example when an attractive candidate remains abstract. Quietly correct obvious transcription errors and distinguish a true routine from something that merely happened twice in similar language.
Explore a typical day, week, and month only where the available history leaves gaps. Pay particular attention to work I delegate to AI repeatedly, work I perform from a template, and chores I postpone because they are tedious or expensive.
Notice where each task already lives. Look for an established trigger, source, interface, system of record, or destination: a recurring meeting, inbox, folder, spreadsheet, project tool, chat habit, or regular document. Favor experiments that can join an existing routine over ideas that require me to adopt a new one.
Keep discovery separate from implementation. Do not recommend tools, models, vendors, integrations, or technical architecture during the audit unless I explicitly ask.

How to judge candidates

A strong candidate usually has several of these qualities:

It recurs often enough that learning or setup can pay off.
Each run begins with known or recognizable inputs.
The desired output can be described concretely.
Past examples show what acceptable work looks like.
Success can be checked without relying entirely on taste.
The task is narrow enough to complete in one bounded pass.
A weak result is cheap to catch, discard, correct, or rerun.
It can run in the background without keeping me waiting.
A frontier model already handles it comfortably and consistently.
It connects to a habit or system I already use.

Treat these as judgment criteria, not a rigid numerical score. Frequency alone does not make a task suitable. For each candidate, also test:

Scope: How much ambiguity, judgment, context, and multi-step planning does it require?
Stakes: What happens if the result is subtly wrong? Can it send, spend, publish, delete, advise, or otherwise create consequences before review?
Verifiability: Can I recognize success cheaply, or would checking the work take as long as doing it?
Economics: Does it happen often enough to justify changing the routine? If my frontier use is already covered by a flat subscription, independence, privacy, capacity, or flexibility may matter more than token savings.

Do not force an entire task onto commodity intelligence when only part of it fits. Look for a safer boundary: commodity intelligence can extract, sort, summarize, format, or prepare a first pass while a person or frontier model retains the ambiguous judgment. Prefer a smaller useful experiment to an impressive autonomous system.

Keep frontier intelligence for work that is one-off, poorly defined, hard to verify, taste-dependent, consequential, or cheap only when it succeeds on the first try. When a candidate does not survive scrutiny, say so at that point in the conversation and explain why. Do not save rejected tasks for a required section in the final answer.

Present the shortlist in layers

Once you understand enough of my work, present the result in four layers. Give me the recommendation before the audit trail.

What I noticed

Open with a conversational summary of the pattern you found in two to four sentences. Focus on what makes parts of my work promising for commodity intelligence, not on recapping your interview process.

Three experiments worth trying

Present the best three candidates in priority order as a numbered list. Give each a plain-language name followed by two or three sentences. Tell me what the experiment would accomplish, why this task appears suitable, and where human or frontier judgment should remain. Write this as advice to me, not as a form or scorecard.

Prefer a short, credible list over filling the quota with weak ideas. If fewer than three tasks genuinely fit, return fewer and explain what evidence is missing.

Experiment details

Follow the summary with compact supporting details for each candidate. Use the same names and order so the sections are easy to connect. Include:

Current routine and foothold: When it happens, how I handle it now, and the existing habit or system it can join.
Input to output: What a typical run starts with and the concrete result I need.
Safe boundary: What should remain under human or frontier judgment, including why the broader task would be unsuitable when relevant.
Smallest trial: A reversible comparison using a few past or parallel examples, without changing the live routine.
Pass condition: The observable result that would make the experiment worth repeating.
Main doubt: The likeliest reason it may fail or prove uneconomical.

Keep these details concise and avoid repeating the recommendation above. They should support it, not bury it.

Where I would start

Recommend one candidate to try first and explain the choice in two or three sentences. Favor easy learning and low downside over maximum theoretical savings. End by asking whether I want to refine that experiment or turn it into a lightweight evaluation plan. Do not proceed into implementation until I choose.

Benchmarks: public and private

Once you have a task in mind, benchmarks can help narrow down the models. Aggregators like Artificial Analysis and Arena.ai rank both open and closed models and let you filter by the type of task.

Open-weight models have improved quickly on Artificial Analysis benchmarks, though proprietary models still lead. (Image courtesy of Artificial Analysis.)

These rankings are a useful starting point, but models are often trained against popular benchmarks, so the scores can be optimistic. Your own work is a better test. Gather a handful of real prompts that span from easy to hard, then run the candidates side by side. You don’t have to collect them yourself. If your current tool keeps a history, you can use a frontier model to pull representative samples from past sessions. Either way, you end up with a private benchmark no lab has trained against.

Private benchmarking takes time, so save it for tasks that are worth it. Focus on high-volume work where savings accrue with every run, work core to your product, or tasks involving private data you can’t send to a frontier API. For a one-off task, skip it and use the best model you can.

Cost per task, not per token

Cheaper tokens don’t always mean a cheaper result. Different models can use vastly different numbers of tokens to reach the same answer, and much of that depends on the prompting and harness. A better comparison is the dollar cost to complete a task.

To get an accurate read, you can’t just run two models with the same prompt and compare. Each model has its own sweet spot. One might need shorter reasoning nudges, whereas another might work better with examples in the system prompt.

Cost per task matters most at high volume. A few cents per task, repeated a thousand times a day, add up fast.

Flat-rate subscriptions change the comparison. If you already pay for ChatGPT or Claude and stay within your subscription’s usage limits, running another task costs you nothing extra. Paying separately for an open model may therefore cost more, even when its API price is much lower.

Once you hit those usage limits—or need API access, predictable capacity, or a fallback—the cost per task matters again. Until then, the main reasons to use an open model are control and independence.

Step 1: Choose your model

Open models come in tiers by size, from small enough to fit on a phone to as large as any frontier model, which typically has trillions of parameters. Specific models change fast, but the tiers are stable. As a rule, larger and more recent models tend to be stronger.

The tiers are guidelines, and swapping one model for another may require adjustments to your prompts and harness. Start at the tier that matches the frontier model you use now and explore from there.

Size	Model	Params/active	Additional modalities	AA score	Blended price (USD / 1M)
Extra large	GLM-5.3	753B/40B	—	44.9	$0.902
	Kimi K3	2.8T/104B	Image, video	43.8	$2.070
	Qwen3.8 2.4T A95B	2.4T/95B	—	40.0	$1.175
Large	GLM-5.3 Flash	320B/18B	Image, video	41.9	$0.0673
	DeepSeek V4.1 Flash	552B/8B input → 16B output	Image	39.5	$0.1842
	NVIDIA Nemotron 3 Ultra	550B/55B	—	23.4	$0.5688
Medium	Qwen3.8 Flash-Next	180B/6B	Image, video	40.0	$0.0882
	Ling 3.0 Flash	124B/5.1B	—	20.6	$0.0134
	NVIDIA Nemotron 3 Super	120.6B/12.7B	—	13.6	$0.117
Small	Qwen3.8 27B	27B/27B	Image, video	33.9	$0.4028
	Meta Muse Glimmer 30B	30B/30B	Image	18.0	$0.248
	Gemma 4 26B A4B	25.2B/3.8B	Image, video	17.0	$0.0830
Tiny	Gemma 4 E4B	8B/4.5B	Image, audio, video	9.0	—
	Nanbeige 4.2 3B	3B/3B	—	8.0	—
	Liquid LFM2.5-2.6B	2.7B/2.7B	—	8.0	—

Model information courtesy of OpenRouter. Last updated September 2026.

Extra large: Frontier rival

Extra-large models are the strongest open models, often only months behind the frontier. Test one against your hardest problems, or let it direct a team of cheaper models.

Reliable for: Anything that today’s frontier models breeze through, or that frontier models from 6–12 months ago already handled well
Reach: Your hardest problems. Even if you already pay for a frontier model, adding an open model gives you a fallback when APIs are down or token budgets run low.
Hardware: Impractical to self-host. You’ll likely rent API access through a host.

Large: Capable agent

Large models are the everyday workhorses of open models. You can hand one a goal instead of step-by-step instructions.

Reliable for: Most non-coding knowledge work and simple, well-defined coding projects
Reach: Can attempt open-ended, ambiguous work, but may require more guidance and handholding
Hardware: Difficult but possible if you can afford a maxed-out GPU workstation or a Mac Studio. Still more practical to rent via API.

Medium: Competent worker

Given clear instructions, a medium-sized model executes them quickly and cheaply. For medium and smaller models, you’re choosing speed and savings over raw intelligence.

Reliable for: Well-defined, repeatable tasks where you’ve already mapped out the steps. For example, drafting a report from an outline, building a feature from a detailed spec, or refactoring code to a described pattern.
Reach: Can run as a standalone agent or sub-agent, but best to keep it on a tight leash
Hardware: Feasible to self-host on high-end consumer hardware (e.g., Mac Studio, Nvidia Spark). Hosted APIs are cheap and fast.

Small: Junior worker

Small models are trustworthy on common, well-trodden tasks, but confidently wrong when pushed outside their scope. A small model needs strong guardrails.

Reliable for: Simple, single-step tasks like local code edits, summarizing documents, and translation
Reach: Light agentic runs with the right harness and a watchful user
Hardware: Runs comfortably on consumer hardware, down to a mid-tier laptop like a recent MacBook Pro.

Tiny: Pocket utility

Tiny models have limited abilities out of the box, but can be optimized to handle predictable, high-volume tasks. A tiny model is more of a tool than an assistant.

Reliable for: Small chores that would waste a larger model’s intelligence. For example, sorting a support request into its category or extracting an invoice number.
Reach: Getting consistent, reliable output takes prompt tuning, few-shot examples, or fine-tuning
Hardware: Runs on most laptops and even some phones

Beyond size

A few other factors can affect which models you choose:

License: Ranges from permissive (Apache, MIT) to restricted. Some licenses limit commercial use, so read a model’s license before you build on it.
Context window: How much text the model can handle. Every tool call, file read, and message sent or received takes up model context. Larger context windows let you work on larger projects and take more agentic turns. The real-world limit is usually smaller than advertised, and quality typically degrades as you near it.
Reasoning: Models that think before answering do better on hard problems, but they use more tokens and take longer. Most recent models can toggle reasoning on and off.
Modality: The kinds of input and output a model can handle. Most models handle text only; vision is fairly common, but audio and video are still rare.
Architecture: Models come in different internal designs, and the biggest divide is dense versus mixture-of-experts (MoE). Dense models use less memory but generate tokens more slowly. MoE models run faster at the expense of needing more memory.
Quantization: Compressing a model to fit your hardware. Full-precision weights are massive (usually 16-bit), but much like JPEG images, they can be compressed to smaller sizes (8- or 4-bit) for a modest loss of quality.
Specialized fine-tuning: Some models are fine-tuned (given additional training) for a particular job, such as working with uncommon languages or extracting data from PDFs. These can outperform larger general-purpose models at that job.
Non-chat models: The open ecosystem also includes embeddings (representing meaning as numbers for search), rerankers (sorting search results by relevance), optical character recognition (reading text from images and documents), and speech models (transcribing or generating spoken audio).

Step 2: Choose your hosting

Hosting is the hardware the model runs on, whether that’s a remote datacenter or a box under your desk. Size is the biggest factor in deciding where a model can run.

For almost everyone, the practical answer is to rent from an inference provider that hosts a model for you. Self-hosting is far more work, and the economics only pay off at scale—though you might do it anyway to keep data private, run a local backup, or learn the stack.

Hosted inference providers

Hosted inference works like a frontier lab’s API but usually at a lower cost. You point your tool at a base URL, paste in an API key, and pay per token. Nearly every provider supports the OpenAI or Anthropic API format, so switching takes a few minutes.

The easiest place to start is an aggregator like OpenRouter. One account gets you dozens of inference providers and hundreds of models, so you can try many without signing up for each. For any given model, several providers compete to serve it, and you can filter providers by speed, price, quantization, uptime, and data retention.

When you move a model into production, going direct to a provider can offer dedicated capacity, volume pricing, and service guarantees. Aggregators like OpenRouter may route requests across providers by default, but some also let you choose a provider or set your own routing rules.

Full-service providers like Together and Fireworks offer broad model catalogs and production features like fine-tuning and dedicated capacity.
Speed specialists like Groq and Cerebras use custom hardware to generate tokens several times faster than ordinary GPUs.
Existing clouds (Azure, AWS, Google Cloud Platform) also host a shortlist of open models, and are convenient if you’re already in their ecosystems.
Modality specialists like Replicate and Fal run image, video, and audio models beyond text.

Using an independent hosting provider can lower your costs and give you access to models from multiple labs, so you have alternatives if one becomes unavailable. But it’s still renting. Your data runs on someone else’s hardware, and you’re trusting them to handle it right. To own the whole stack, you need to host the model yourself.

Self-hosting

Self-hosting means running the model on hardware and software you control. Your data is your own, and your token costs are limited to hardware and electricity. In exchange, you also own the operational responsibilities of updating and securing your stack—and fixing the inevitable 2 a.m. bug.

For hardware, start with memory capacity. The model has to fit in memory before it can run, and the speed of that memory determines how quickly it answers. A hard drive—even a fast SSD—can be 10 times slower than slow GPU memory.

Current hardware falls into two camps:

Discrete GPUs are specialized cards built for the kind of parallel math AI runs on, from gaming cards to server accelerators. They’re fast, but their onboard memory is limited and expensive. GPUs are best for running a smaller model quickly. Most are made by Nvidia. AMD’s GPUs are slightly cheaper, but you’ll have to check that the software you want to use supports your graphics card and operating system before buying.
Unified memory is a design where the whole system shares one large pool instead of a separate graphics card. Apple has made unified memory widely available across its Mac line, from the Mac mini to the high-capacity Mac Studio. AMD’s Strix Halo PCs and Nvidia’s DGX Spark use similar designs. Unified memory holds far more at a lower cost but runs slower than a GPU’s dedicated memory. It’s best for running larger models that would otherwise require several costly discrete GPUs.

Device	Memory capacity	Memory bandwidth	USD estimate
iPhone 18 Pro	12 GB	~115 GB/s	~$1,000
MacBook Air M5	16 GB	153 GB/s	~$1,000
Framework Desktop AI Max+ 395	128 GB	256 GB/s	~$4,000
NVIDIA DGX Spark	128 GB	273 GB/s	~$5,000
RTX 5090 Gaming Desktop	32 GB	1,792 GB/s	~$6,000
MacBook Pro M5 Max	128 GB	614 GB/s	~$7,000
Mac Studio M5 Ultra	256 GB	1,200 GB/s	~$10,000
Mac Studio M3 Ultra	512 GB	819 GB/s	~$16,000
RTX PRO 6000 Blackwell Workstation	96 GB	1,792 GB/s	~$22,000

The prices above are current as of September 2026.

Quantization

You can’t cheaply add memory, but you can stretch your available memory by using quantized models. These are the same model weights, compressed to half or even a quarter of the original size. This reduces quality, often a few points on benchmarks, but the difference is usually too subtle to notice in real use.

As a rule, 4-bit is a good balance for self-hosting, but this depends on the model. Even when they use the same amount of memory, an aggressively quantized large model typically outperforms a smaller model at full precision.

All-in-one apps

For most people, the easiest way to get started is with an all-in-one app like LM Studio, Jan, or Osaurus. These apps let you download and run models in one place, with a chat window and an API endpoint for other tools.

All-in-one desktop apps like LM Studio let you download and run open models, then use them through a chat window or an API endpoint. (Screenshot courtesy of Kai Zau.)

Running your own server

For full control, skip the bundled app, and run a dedicated server. llama.cpp is the popular choice for personal use, while vLLM or SGLang handle team-scale traffic. On a Mac, oMLX is a strong option built for Apple Silicon. New models and features land almost weekly, so expect to keep up.

To reach the server from your other devices, put it on a private network. Tailscale is the easiest way, and it keeps the server off the open internet; you should never expose the server unless you know exactly what you’re doing. A proxy like LiteLLM or Bifrost can then route between your local and hosted models through a single endpoint.

Help me choose an open-weight model and a practical way to run it for this task:

[Describe the task here, or send it with this prompt.]

For background on open-weight models and the framework used here, see the full guide:

https://every.to/guides/getting-started-with-open-models

The goal is a short, current recommendation based on the task and my constraints, not an exhaustive tour of the market or a technical setup session. Help me decide both which models to try and whether I should use them through a hosted provider or run them locally. Do not assume I am technical.

If the task is ambiguous, ask one focused question to clarify it. If I am still describing a broad goal rather than a concrete task, suggest that I first use the guide’s “Identify tasks for commodity intelligence” prompt. Do not conduct a general work audit yourself.

Understand the decision

Ask one or two focused questions at a time, adapting them to what I have already told you. Use relevant context you can actually access, but never imply that you can see systems, files, hardware, memory, or conversation history that you cannot. Skip questions whose answers would not change the recommendation.

Learn enough to understand:

What a typical input looks like and what useful output I expect.
How much ambiguity, judgment, context, and multi-step work the task involves.
The cost of a weak answer and how much human review is acceptable.
Any requirements involving modality, language, context length, tool use, speed, or volume.
What I care about most: ease, cost, privacy, independence, speed, or learning.
Whether remote hosted inference is acceptable, merely undesirable, or ruled out.
How much setup and maintenance I am comfortable taking on.
My available hardware, but only when local operation is a serious option. Keep this coarse unless a specific recommendation depends on details.

Do not treat self-hosting as a simple yes-or-no preference. Using a polished local app is different from maintaining a model server. Likewise, preferring local is different from requiring that data never leave my hardware.

Apply two gates

First, estimate the minimum model tier that could plausibly handle the task. Use the guide’s tiers as a practical frame:

Extra large or large: Broad, ambiguous work requiring strong judgment or long agentic runs.
Medium: Well-defined work with several steps and clear instructions.
Small: Bounded transformations such as summarizing, translating, extracting, or making simple edits.
Tiny: Narrow, predictable utilities such as classification or field extraction.

These are starting points, not guarantees. Model architecture, specialization, prompting, and the surrounding software can matter as much as parameter count.

Second, establish the hosting constraint:

If hosted inference is acceptable, optimize for the best balance of capability, ease, speed, and price.
If local operation is preferred, recommend the strongest practical local choice and include a hosted alternative only when it offers a meaningful capability advantage.
If local operation is required, stay within the realistic limits of my hardware and technical appetite.

Then reconcile the two gates. If the task appears to require more capability than the hosting constraint allows, say so plainly. Identify which constraint would need to change rather than quietly recommending a model that is unlikely to work. You may suggest narrowing the task, but do not turn the conversation into another task audit.

Research current options

Once the search space is clear, fetch https://openrouter.ai/api/v1/models once and cache the complete response. Explore it programmatically with jq or a short script rather than inspecting records one at a time. Use OpenRouter as a common source for comparing models, benchmarks, and indicative pricing, not as the default hosting recommendation. If you cannot access the current catalog, limit the answer to model tiers and hosting approaches instead of presenting model names as a current recommendation.

Prepare the catalog before comparing candidates:

Keep records with a non-empty hugging_face_id, and remove any whose expiration_date has passed.
Group records with the same canonical_slug. Treat :free and :batch IDs as routes for a model rather than separate models, while retaining differences that matter to hosting.
Use architecture for modality; explicit parameter counts in name or description for approximate size; and benchmarks, pricing, context_length, top_provider, supported_parameters, reasoning, and created for comparison. Mark missing size or benchmark data as unknown rather than guessing.

Use the user’s task and constraints to filter this inventory to a few plausible candidates. Prefer task-relevant benchmark evidence over a single aggregate score. Stop when the cached catalog supports a useful recommendation, and make an additional targeted fetch only when a missing fact could change the choice, such as local hardware fit, licensing, or provider policy. Do not turn the shortlist into a broader market survey.

Date the recommendation and link the sources behind consequential claims.

Make the recommendation

Give me a short, conversational answer rather than a research report.

Begin with two or three sentences explaining what model tier the task appears to require and whether hosted inference, local operation, or either is the better fit. If my capability needs and hosting constraints conflict, say so here instead of manufacturing a workable recommendation.

Then recommend up to three current models in the order I should consider them. For each, use one or two sentences to explain:

Why it made the shortlist.
Whether it is suited to hosted or local use.
The tradeoff that matters most for my decision.

For each recommendation drawn from the catalog, give its exact OpenRouter model ID. For a local-only candidate, give its exact repository ID instead. Treat these as reference IDs, not hosting choices; recommend OpenRouter, a direct provider, or local operation separately.

Use model size, Artificial Analysis scores, context window, and price where they help explain the recommendation, but do not report every available field or force the same facts into every entry. Explain technical terms in plain language.

Put the best starting point first. Do not add separate sections for decision details, sources, or next steps. Be honest that these are informed candidates, not proof that any model will be good enough for my work.

Step 3: Integrating your work

Whether you’re using an inference provider or your own local server, you have a new endpoint URL and API key. Next, update your tools to use them.

Existing apps

Start with tools you already use. Most AI-enabled apps—code editors, writing tools, browser extensions—let you bring your own API key. You can switch models while the app continues to manage conversation history, memory, skills, and settings.

Claude Code and Codex CLI can both connect to other model providers, though each is configured differently. In Claude Code, you can choose an endpoint, API key, and model for a single session from the command line:

ANTHROPIC_API_KEY= \

ANTHROPIC_BASE_URL=YOUR_URL \

ANTHROPIC_AUTH_TOKEN=YOUR_API_KEY \

claude --model YOUR_MODEL

Use the following prompt to have Claude Code or Codex CLI set itself up to use open models.

Help me configure coding agents to use models through this endpoint: (paste endpoint URL here)

For background on open-weight models and the framework used here, see the full guide:

https://every.to/guides/getting-started-with-open-models

The goal is one or both of these new commands, depending on which CLIs I have installed and want to configure:

openclaude launches Claude Code through the open-model endpoint.
opencodex launches Codex through the open-model endpoint.

Both commands must forward every additional argument unchanged. My normal claude and codex commands must keep their existing providers, models, and settings.

Instructions

Treat this as a hands-off quick start for a non-technical user. When safe approaches are equivalent, choose the one with the fewest steps, files, and lasting changes. Ask only when you cannot continue safely.

Check whether claude and codex are installed. Inspect their versions, help, my operating system, shell, PATH, and relevant existing configuration. On Windows, distinguish native Windows from WSL; treat WSL as Linux and keep its files in the WSL home and PATH. Configure each compatible installed CLI I want to use; if both are available and my preference is unclear, ask whether to configure one or both.
Identify the provider from the endpoint and quietly confirm its base URL, authentication method, and API format in its official documentation. Treat the supplied URL as a starting point: if Claude Code and Codex require different Anthropic Messages and OpenAI Responses URLs, derive and store them separately. Mention only findings that change the setup or reveal an important limitation.
Show one short plan naming the files you will create or change and ask for approval once. Read each existing file before editing it, preserve its contents, and make a backup. After approval, complete routine reversible steps without stopping after every command. Pause only for the credential, an unexpected conflict, a consequential choice, or a system-required permission.
On macOS, Linux, or WSL, install openclaude and opencodex as small executables in an existing user-owned PATH directory, falling back to ~/.local/bin. On native Windows, use .cmd wrappers in an existing user-owned PATH directory, falling back to %LOCALAPPDATA%\OpenModelAgents\bin; .cmd works from PowerShell and CMD without relying on profiles or execution policy. Use setlocal so provider variables do not escape the wrapper. Do not inspect or rearrange user arguments; pass them directly to the underlying CLI with %*. If the fallback directory must be added to the Windows user PATH, preserve the existing value and use the .NET user-scope environment API or the Windows settings interface. Never rewrite PATH with setx, and never change PowerShell’s execution policy. Tell me when a new terminal is needed to see a PATH change.
Store the endpoint and credential as plain key=value fields in one file restricted to the current user: ${XDG_CONFIG_HOME:-$HOME/.config}/open-model-agents/config with mode 600 on macOS, Linux, or WSL, or %LOCALAPPDATA%\OpenModelAgents\config on native Windows. On Windows, inherit the protections of the user-profile directory and verify that other ordinary users cannot read the file; do not remove access for the current user, SYSTEM, or Administrators. Treat this file as data: parse only the recognized fields and never source or execute it. Explain once that the key remains plain text. Open the file in a plain-text editor and ask me to replace the key placeholder, save, and close it. Then check the expected fields, placeholder, duplicates, and permissions without printing the key. Never put the key in chat, command arguments, a wrapper, or a repository.
Keep the original claude and codex configuration unchanged. Use the configurations shown below unless the installed documentation clearly indicates that they have been replaced. The Codex endpoint must support the Responses API. For Claude Code, set only the endpoint and authentication environment variables the provider needs.
If the endpoint documentation says authentication is unnecessary, omit the key and authentication settings. For a loopback endpoint such as localhost, 127.0.0.1, or ::1, do not expose or reconfigure the server’s network binding. Warn me before using an unauthenticated endpoint on any other address.
Do not research, compare, choose, or store a default model. On macOS, Linux, or WSL, require --model on every invocation and show a short usage message when it is missing. On native Windows, keep the .cmd wrappers as pure pass-throughs and teach the requirement through examples instead. The user may place the flag anywhere the underlying CLI accepts it. Show where the provider displays its model IDs, but use <provider-model-id> in examples rather than choosing one.
Verify command discovery, argument forwarding, quoting, and permissions without calling the API. On macOS, Linux, or WSL, also verify the missing-model message. Then provide one copyable smoke test per configured CLI using <provider-model-id> and note that running it may incur a small charge.

Use the examples below as the baseline and adapt them for the detected platform and authentication method. On native Windows, translate the same fixed-field parsing and CLI configuration into .cmd syntax; do not source the config through PowerShell or use ConvertFrom-StringData, since opaque values may contain characters those mechanisms interpret. Consult these references only when the endpoint or installed CLI creates doubt:

Codex configuration: https://learn.chatgpt.com/docs/config-file/config-reference.md
Codex advanced configuration: https://learn.chatgpt.com/docs/config-file/config-advanced.md
Claude Code settings: https://code.claude.com/docs/en/settings.md
Claude Code environment variables: https://code.claude.com/docs/en/env-vars.md
Claude Code gateways: https://code.claude.com/docs/en/llm-gateway-connect.md

POSIX examples

Private configuration file:

# ${XDG_CONFIG_HOME:-$HOME/.config}/open-model-agents/config
OPEN_MODEL_API_KEY=replace-locally-not-in-chat
OPENCLAUDE_BASE_URL=https://provider.example/v1
OPENCODEX_BASE_URL=https://provider.example/v1

openclaude for a Bearer-token endpoint:

#!/bin/sh
set -eu
config_file=${XDG_CONFIG_HOME:-“$HOME/.config”}/open-model-agents/config
OPEN_MODEL_API_KEY=
OPENCLAUDE_BASE_URL=
while IFS=‘=’ read -r name value || [ -n “$name$value” ]; do
case $name in
OPEN_MODEL_API_KEY) OPEN_MODEL_API_KEY=$value ;;
OPENCLAUDE_BASE_URL) OPENCLAUDE_BASE_URL=$value ;;
esac
done < “$config_file”
: “${OPEN_MODEL_API_KEY:?Missing OPEN_MODEL_API_KEY in $config_file}”
: “${OPENCLAUDE_BASE_URL:?Missing OPENCLAUDE_BASE_URL in $config_file}”
has_model=false
for arg do
case $arg in
--model|--model=*) has_model=true; break ;;
esac
done
if [ “$has_model” = false ]; then
echo ‘Usage: openclaude --model <provider-model-id> [arguments...]’ >&2
exit 2
fi
export ANTHROPIC_BASE_URL=“$OPENCLAUDE_BASE_URL”
export ANTHROPIC_AUTH_TOKEN=“$OPEN_MODEL_API_KEY”
unset ANTHROPIC_API_KEY
exec claude “$@”

opencodex using command-line configuration only:

#!/bin/sh
set -eu
config_file=${XDG_CONFIG_HOME:-“$HOME/.config”}/open-model-agents/config
OPEN_MODEL_API_KEY=
OPENCODEX_BASE_URL=
while IFS=‘=’ read -r name value || [ -n “$name$value” ]; do
case $name in
OPEN_MODEL_API_KEY) OPEN_MODEL_API_KEY=$value ;;
OPENCODEX_BASE_URL) OPENCODEX_BASE_URL=$value ;;
esac
done < “$config_file”
: “${OPEN_MODEL_API_KEY:?Missing OPEN_MODEL_API_KEY in $config_file}”
: “${OPENCODEX_BASE_URL:?Missing OPENCODEX_BASE_URL in $config_file}”
export OPEN_MODEL_API_KEY
has_model=false
for arg do
case $arg in
-m|--model|--model=*) has_model=true; break ;;
esac
done
if [ “$has_model” = false ]; then
echo ‘Usage: opencodex --model <provider-model-id> [arguments...]’ >&2
exit 2
fi
exec codex \
--config ‘model_provider=“opencodex”’ \
--config ‘model_providers.opencodex.name=“Open Codex”’ \
--config “model_providers.opencodex.base_url=\”$OPENCODEX_BASE_URL\“” \
--config ‘model_providers.opencodex.env_key=“OPEN_MODEL_API_KEY”’ \
--config ‘model_providers.opencodex.wire_api=“responses”’ \
“$@”

Finish

Do not change the coding agents’ permissions, sandbox behavior, project instructions, or unrelated shell settings. At the end, show me:

The command I will use day to day.
Examples using --model <provider-model-id> and where to find that ID.
Where the shortcut lives and how it works.
Where its credential comes from without revealing it, or why none is needed.
Any important limitation.
The files created or changed.
How to remove the shortcuts.

Other apps like Cursor let you apply the same changes from settings menus. Find the API settings, paste in your endpoint and key, and the tool will start routing your requests to the new provider. Then add the model or models you want to use.

Open alternatives

Flagship consumer apps aren’t as configurable as developer tools. The ChatGPT and Claude desktop apps have no setting for a custom model endpoint, so you’ll need standalone apps with similar features.

If you went with LM Studio, Jan, or Osaurus in the previous step, you already have one. Each includes a chat interface with basic features like conversation history, configurable system prompts, and configurable web search.

The open ecosystem also offers more specialized and configurable tools than the flagships.

AnythingLLM is purpose-built for research. It indexes documents, scrapes web pages, and builds a private, offline knowledge base you can search. Where the flagships send everything to the cloud, AnythingLLM keeps it on your machine.
Pi is an open coding agent built around a plugin ecosystem. oh-my-pi, one of its most popular plugins, includes inventive ideas: collaboration links, multiple search engines, and the ability to pair two models so one executes and one reviews.

Open models can also generate images, speech, video, and music. Here are a few starting points beyond text.

Image generation is furthest along. Models like Ideogram and Flux compete with the best closed offerings like Midjourney and Google’s Nano Banana, and the tooling is well established. ComfyUI is the standard for advanced workflows, with community templates to get started faster. If you’re on a Mac, Draw Things is by far the easiest option. And if you’d rather someone else handle the hosting, Replicate and Fal host the latest image models on their APIs.
Voice is similarly well-covered and especially suitable for local self-hosting. The models here tend to be smaller and faster and don’t always need high-end GPUs. For speech-to-text, Handy turns any computer into a capable dictation machine. For text-to-speech, VoiceBox offers a local alternative to services like ElevenLabs, generating spoken audio on your own computer. The broader ecosystem spans real-time translation and voice cloning.
Video and music generation are still specialist niches, but recent open models are now viable alternatives to closed services like Kling for video and Suno for songs. Minimax H3 can generate short video clips in any style, and YuE2 can create full-length songs, with or without lyrics. These require substantial compute and patience to run locally (it can take more than 10 minutes to generate 10 seconds of video), so hosted providers are still the practical starting point.

These tools give you more control, but you’ll be responsible for updates and troubleshooting.

Automated workflows

Open models are also useful for recurring jobs that run in the background. Start with well-scoped, low-stakes, high-volume jobs. Each step is well-defined, the inputs and outputs are known, and the workflow needs no supervision.

Voice memos and meeting recordings can run through a local model that summarizes and tags them, never leaving your machine. The same workflow can classify and route support tickets, extract line items from invoices, or run nightly searches and deliver a summary by morning. Predictable tasks are a natural fit for commodity intelligence.

Building these automations used to require a developer. A capable coding agent can now build a small automation that uses the model you set up in Step 2. A script for your own use may need only to read a file, call the model, and save the result. That’s manageable, though you’ll still need to check its work. For simpler cases, low-code platforms like n8n, Make, and Zapier skip the code entirely, letting you wire triggers to model endpoints from a visual editor.

You might use a frontier model to write and debug the automation, then an open model to run its everyday tasks.

Rolling out open models to a team

Everything discussed earlier scales to larger organizations, too.

Private gateways like LiteLLM or Bifrost give you one place to manage API keys, set budgets and rate limits, share prompts, and keep an audit log. They also route requests based on cost, latency, or topic, and configure fallback logic when a provider hits rate limits or experiences outages.

Self-hosted front ends like Open WebUI and LibreChat give non-technical users a familiar chat interface without forcing everyone to reconfigure their tools.

Together, they centralize spending, keep data in your jurisdiction, and provide an audit trail.

Intelligence as a commodity

You don’t need to move all your work to open models. Start with a task you do often and try a model on a few real examples. If the results are good enough, you have another option the next time your usual service raises prices or becomes unavailable.

The initial setup takes some effort. Afterward, you can try other models with the same tools and decide where they’re useful in your work.

Kai Zau is a programmer and local AI tinkerer. He runs millions of tokens per day through models hosted on a Mac Studio.

🎧 How Sam Altman Uses Dots to Take Back His Time

Laura Entis / The Every Podcast — 2026-09-30 16:44:13 -0400

by Laura Entis

in The Every Podcast

Midjourney/Every illustration.

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.

Vibe Check: OpenAI DevDay 2026

Dan Shipper / Vibe Check — 2026-09-29 13:04:22 -0400

by Dan Shipper

in Vibe Check

Midjourney/Figma/Every illustration.

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

Dan Shipper / Vibe Check — 2026-09-29 13:03:10 -0400

by Dan Shipper

in Vibe Check

Midjourney/Every illustration.

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.

💳 ACCESS GATE — PAID subscription required below

There’s so much coordination in my day that requires me to read a few threads, put things together, and decide what to do. Having an assistant that flags all the little things that need attention, pulls the context, and recommends an action without making me think about it can be magical.

The version I’ve been testing for several days has become the main way I interact with ChatGPT. But this version feels early and rough.

My Dot frequently gets disconnected from my computer, so it can’t accomplish tasks locally. It has its own computer (in a data center somewhere), but it doesn’t have access to my stuff, and logging it in is a pain and sometimes doesn’t work. Every so often, I’ll send my Dot a message, and it doesn’t respond. I use Dot for my day-to-day work, but sometimes I want to go back to good old reliable Codex.

I expect the product to improve rapidly, but for now, this is your day-zero Vibe Check.

The landscape

A product has to accomplish four things to qualify as a “personal agent”:

It has to be always on: It runs around the clock, pursuing what I’ve defined as the threshold for artificial general intelligence: intelligence too valuable to shut off.
It has to be proactive: It texts, calls, or emails when something needs your attention, without waiting for you to start a conversation.
It has to keep going without you: It stays on between conversations, keeping track of ongoing tasks and following up while you do something else.
It has to get the work done: It can book, buy, call, or send on your behalf, asking for approval when needed.

The companies building personal agents are making different bets about how their agents should fit into your day. Meta’s Muse and Instinct lean toward your personal life: errands, appointments, trips. SpaceXAI’s Grok Bot emphasizes work and teams of agents. Gemini Spark builds on Google’s apps. OpenClaw leaves more decisions—and setup—to you.

Our side-by-side comparison of personal agents on the market today. Click to go deeper. (Screenshot courtesy of Jack Cheng.)

Here’s how OpenAI has designed its version:

Where it lives: Dots is part of ChatGPT, available on desktop , and mobile. Your Dot appears as an ongoing conversation alongside your other ChatGPT conversations.
What it can access: The accounts you connect—like email, calendar, and Slack—plus its own cloud computer and browser, where you can log it in to other websites.
How it reaches you: It can alert you without waiting for a prompt, including through in-app messages , and calls. It doesn’t have access to iMessage like Instinct does.
What permission looks like: You grant access to your accounts, and it can ask for approval before taking actions on your behalf. When it communicates with other people, it identifies itself as your assistant.
How much you configure: In the build I’ve been testing, you get one Dot and no model selector. OpenAI handles the underlying model and the infrastructure that keeps your Dot running.
How it’s different: It’s part of ChatGPT. So you get it under your existing subscription, it works natively on desktop and mobile, and it can access everything your ChatGPT can.
What it’s for: It’s intended for both work and personal life. Dots is arriving alongside a broader ChatGPT workspace for projects, files, and documents, so it has a natural place for knowledge work and engineering.

Its purpose interests me most. People already think through problems in ChatGPT and give tasks to Codex. Dots give them a way to delegate the ongoing coordination around their work, too. This is a different segment from the one most personal agents like Muse and Instinct seem to serve.

Knowledge workers and developers are ideal early users for Dots. We already have plenty of work to hand over, and we’re used to figuring out these systems. The question is how much of that responsibility Dots is ready to take on.

What Dot looks like

Dots resembles iMessage. Your agent has a name, an avatar, and a conversation you return to. Mine is called Boo (what my trainer calls me). You can message it through iMessage or call it to talk through work.

On the desktop, your Dot sits in the ChatGPT sidebar right below the “New chat” button. When it works well, you rarely need to start a new chat. You kick off all your AI interactions—from little questions to big projects—by talking to your Dot.

Dots show up in the ChatGPT sidebar, right below “new chat.” (Image courtesy of Dan Shipper.)

What works

An always-on guardian of my time and my mind

My Dot is best when it notices something I would otherwise have to find.

Right after I connected my calendar, my Dot identified useful tasks: Prepare for interviews, sort out overlapping meetings, and identify conflicts with a travel day. I hadn’t prompted it to do any of those tasks. It reviewed my calendar and flagged a few issues worth addressing.

That has continued to feel surprisingly natural. While I was talking to the Every team about this review, my Dot messaged me because one of my investors had emailed me about moving our call. It asked whether it could make the change for me.

This is a small thing, but I have a lot of small things. Normally, I’d have to open my inbox, find the message, review the proposal, and respond. Instead, my Dot surfaced the issue and proposed a decision. I hadn’t created a routine to watch for that request. My Dot had inferred that I wanted help with this kind of request.

The earlier flight conflict was a more impressive version of the same behavior. That may have saved me hundreds of dollars in travel costs and a huge headache—and Dot flagged the conflict automatically.

My new default window into ChatGPT

I’ve started reaching for my Dot instead of opening another Codex thread. There’s something appealing about having only one ongoing conversation in which I can keep handing my Dot things to do. The experience reminds me of the halcyon days of OpenClaw, but the models may now be good enough that it works.

This is an important indicator: Even though Dots is frustrating sometimes, it feels enough like the future for me to bear with it.

What needs work

Relying on Dots now feels like death by 1,000 papercuts. After working perfectly on one task, my Dot will miss a message, or take too long to respond without giving me a status update, or fail at a task it should handle. They make the product feel rushed.

It doesn’t always know when to ask

My Dot usually asks for permission to do things. But sometimes it goes ahead with something I wish it had checked.

I asked it to coordinate a call with Lee Knowlton, one of our developers, who’s based in Japan. It offered him meeting options at 8 p.m. my time without asking whether I wanted an evening meeting. I corrected this by telling Boo to protect my writing time and check with me before offering morning or evening slots. It then proposed a time I approved and sent it to Lee.

Giving it access is a pain

Your Dot’s cloud computer doesn’t share your machine’s existing login sessions. I had to log it in to services one at a time. Passkeys made this particularly awkward, and there was no good way to transfer my credentials or sessions.

My Dot also sometimes struggled to distinguish between the in-app browser on your laptop and the browser on its own computer. The split between your local and cloud computers requires duplicate logins, causes unreliable access, and creates confusing failures when the agent uses the wrong browser for a task. I don’t want to think about these details when asking an assistant to do something.

When I gave my Dot access to my local computer, that permission was repeatedly revoked without explanation. I had to keep re-authorizing it.

Sometimes it doesn’t respond

I’ve sent messages that got no immediate reply from my Dot—or no reply at all. In an app where I’m delegating ongoing work, the silence leaves me wondering whether anything is happening.

It’s also less configurable than OpenAI’s other tools. There’s no model selector, for example. I understand those decisions for a broader audience, but I miss the flexibility.

The verdict

I can’t wholeheartedly recommend Dots today for people already using Grok Bots, Muse, or Instinct. I’d stay where you are for now.

But if you’re curious about the category and you’re a big ChatGPT user, it’s worth giving Dots a spin. If you’re the kind of person who wants to get work done, I’d skip Dots for a week or two until the team resolves the papercuts that make the experience more frustrating than it should be. It’s been iterating rapidly, even during my testing, so I expect it to improve.

I’m going to keep using it, though. Since OpenClaw launched, it’s been clear that the personal agent form factor will be important. All the big companies are now converging on it. OpenAI has a path to victory with knowledge workers and coders thanks to the effort it’s put into Codex. If you’re choosing between a separate app and one deeply integrated into the AI you already rely on, the decision should be simple.

But today, it isn’t.

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

Thanks 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.

Vibe Check: Sonnet 5.5 Finds Its Place in Claude’s Crowded Family

Katie Parrott / Vibe Check — 2026-09-28 15:55:20 -0400

by Katie Parrott

in Vibe Check

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.

💳 ACCESS GATE — PAID subscription required below

For a long time, Sonnet had a clear role in the middle of Anthropic’s lineup: It could handle work too demanding for Haiku while costing less and running faster than Opus.

Then the middle got crowded. Last November, Opus 4.5 cut its price from $15 to $5 per million input tokens, narrowing the gap with Sonnet. In June, Anthropic added a new top tier, Fable, leaving Sonnet and a cheaper Opus competing for much of the same work. By the time we reviewed Sonnet 5 in July, we couldn’t find a task it handled best. For every task we tried, another model was cheaper, faster, or better.

Effort levels complicate Sonnet’s place further. Today, Fable, Opus, and Sonnet each offer five effort settings, from low to max, letting you trade speed and cost for capability without changing models; Haiku has none. That’s 16 ways to run Claude. If you want a quicker and cheaper Opus or Fable, you can turn down the volume without changing the tune.

So why choose Sonnet 5.5? After a week of testing, we think its strongest case isn’t as a substitute for Opus, but as Opus’s companion. At low and medium effort, Sonnet 5.5 is fast, inexpensive, capable, and responsive to direction—well suited to brainstorming, prototyping, design work, and other iterative jobs where you stay involved. When the work becomes long-running or demands high effort, Opus is usually the better handoff.

That distinction won’t matter to everyone. Some testers still saw no room for a mid-tier model, and our benchmarks didn’t show a consistent improvement over Sonnet 5. But Kieran Klaassen’s experience suggests a different view of the lineup: You don’t have to choose one Claude. Sonnet can help you find and refine the answer; Opus can do the heavy lifting.

Price makes that division of labor practical. Sonnet costs $2 per million input tokens and $10 per million output tokens—half the price of Opus 5.5—and much of it is included in Claude subscriptions. It may not have the broad, uncontested identity Sonnet once did. But as the model you use to experiment quickly, steer closely, and build more often, it has a role after all.

Here’s your day-zero Vibe Check.

What Anthropic is saying

Anthropic pitches Sonnet 5.5 as a faster, cheaper option for everyday work, withO pus 5.5 handling more complex, open-ended jobs. Here are Anthropic’s claims about the new model, and what we found in our testing:

“A clear upgrade over Sonnet 5.” In some tasks. Kieran found it dramatically better for real-world coding, and Dan Shipper found it a stronger editor. But it didn’t consistently beat Sonnet 5 in our structured tests.
Strongest at well-scoped tasks and polished documents. The “well-scoped” part matches what we saw. It does best when you tell it where the job ends. The deck it built for Mike Taylor had strong substance but sloppy layout.
A better eye for design. Designer Tyler Nishida found it good at picking up a visual style from reference designs, despite some basic UI mistakes.
Writes more clearly, like Opus 5.5. Our tests support this. Its prose scored as readable as Opus 5.5’s, and I found it less prone than Sonnet 5 to the phrasing that makes Claude sound like Claude.
Availability. Sonnet 5.5 is available in the Claude apps, Claude Code, and Cowork, and through the API as claude-sonnet-5-5 on Anthropic’s platform, AWS, Google Cloud, and Azure.
Cost. It costs the same as Sonnet 5, $2 per million input tokens and $10 per million output tokens, which is half what Opus 5.5 charges. It runs at medium effort by default in Claude Code and the Claude apps, and at high effort through the API.

Reach Test

Kieran Klaassen, father of Compound Engineering 🟩

“Sonnet 5.5 is probably for you. It feels like an extension of Opus 5.5: similar quality in many ways, and way cheaper and faster.

”It’s not super-clear when to use Sonnet vs Opus, but this is how I use it: for iterative, quick work, especially design, prototyping, and product work. It’s also nice for quick background jobs. Run it on low or medium effort. Don’t run it on high or extra-high. If your task needs that much effort, move to Opus. Same for long-running tasks. Opus is still a bit more token efficient, and that adds up over a long run.

“The bigger observation: Opus 5.5 felt way better than what came before, and Sonnet 5.5 is the second in a row. This Sonnet is a special one. It earns the .5 in its name. The two share a lot of capabilities and ways of working, so what you learn with one carries over to the other. That means you don’t have to pick one. Sonnet is the in-the-loop worker: Brainstorm with it and land on the idea. Hand that off to Opus to do the heavy lifting, then come back to Sonnet to iterate and polish.

”And it’s cheap. So much of it is included in your subscription that a lot more people now get very high-quality models. That makes experiments and prototypes a must. Just go build stuff. More and more, we humans are the bottleneck again.”

Mike Taylor, AI eval builder extraordinaire 🟨

“Like with Opus 5.5, they fixed the effort levels and personality, so you could live with medium now and still get results. It’s a good model. I just don’t have room in my stack for mid-tier models anymore.”

Katie Parrott, AI-pilled writer by day, vibe coder by night 🟨

“There’s a lot to like about Sonnet 5.5. It’s fast, flexible, and legible, which makes it a great writing collaborator. The problem is that Opus 5.5 is all of those things, too, with a bit more brains behind it. I’m back in the Claude ecosystem for writing, but whether I’ll reach for Sonnet specifically remains to be seen.”

Tyler Nishida, designer and demo slinger 🟩

“Sonnet 5.5 cooks! Low and medium are my new daily drivers for design work. It’s a cheaper option with surprisingly great output and it’s fast, which is super important for design iteration. Low and medium can run for surprisingly long stretches depending on your prompt, so you’ll want to be careful there. Max and ultracode effort created incredible results, too, but at that point, you might as well reach for Opus 5.5.”

Coding: A steerable builder at medium, an overbuilder above it

Sonnet 5.5 can carry a large build for long stretches, even at low effort. Medium effort gave us the best balance of results and time, though it didn’t clearly outperform Sonnet 5 in our tests.

It can take on a big build with no supervision

Kieran had Sonnet 5.5 build a clone of Proof, Every’s open-source document editor, from scratch at low effort. By his count, only Fable 5, GPT-6 Astra, and Opus 5.5 had managed that job before. Opus 5 hadn’t. Sonnet 5.5 handled it “pretty well.” Kieran said the result wasn’t as strong as Opus, but completing a complex, long-running coding task at low effort showed how capable Sonnet 5.5 was—and that it may already be enough for most people. That’s a Sonnet-class model at its lowest setting taking on work that was recently reserved for flagships.

Sonnet delivers a complete, working clone of Proof, a feat Opus 5 couldn’t achieve. (Image courtesy of Kieran Klaassen.)

Effort changes time spent but isn’t always worth it

On Kieran’s baby-agent eval—15 short coding tasks graded by automated checks and Opus 5.5—Sonnet 5.5 scored the same at low, medium , and high. In his own work, low, and medium felt identical.

The top settings did buy detail, at a steep price in time. When Tyler asked it to build a 3D model of his property in three.js, a library for 3D graphics in the browser, the medium run took about 10 minutes and was “damn good.” On ultracode—a Claude Code setting that pairs extra-high effort with a team of sub-agents working in parallel—it took 19 hours and produced the most detailed render. Above medium, Tyler and Kieran both said they’d rather use Opus.

Sonnet delivered a detailed 3D model of Tyler’s property. (Image courtesy of Tyler Nishida.)

It has trouble staying inside the brief

Long unsupervised runs gave Sonnet more room to stray from the brief. In Tyler’s property build, it found the county tax parcel and modeled the palm trees, but missed a large pond and added views of Mauna Kea and the coastline that Tyler hadn’t asked for. “It did way too much,” he said. On a golf game build, Sonnet 5.5 implemented Tyler’s ideas well at low and medium effort, but completely messed up the game when iterating on it in long max and ultracode sessions: it implemented unrealistic ball physics and deleted details it had introduced at lower effort levels that Tyler wanted to keep. “It worked long, but the end result was just way off,” he said. A later attempt went better once Tyler broke the work into rounds, reviewing each run before iterating at extra-high and max. His experience suggests Sonnet 5.5 does well at lower effort, but you’re better off switching to Opus 5.5 for max or ultracode.

Stronger in some ways, weaker in others

Our tests don’t yet show that Sonnet 5.5 is a consistent coding upgrade over Sonnet 5. On Kieran’s 15-task baby-agent eval, Sonnet 5.5 passed nine of 15 tasks at every effort level, while Sonnet 5 passed 10 , and Opus 5.5 12, both at low effort. Still, Kieran’s hands-on work left him impressed: he called Sonnet 5.5 “very strong on coding.” On a separate visual animation task, Tyler preferred how Sonnet 5 handled his opening and closing prompts, while Sonnet 5.5 did more with his brief’s most abstract ideas.

Use Sonnet 5.5 at medium effort for prototypes, interface work, and builds you plan to review as they progress. Give it a clear scope and a time limit, even at low effort, and check its work between rounds. For a finished, detailed build, consider a supervised high-effort final pass, or switch to Opus 5.5. If Sonnet 5 already works for your coding, our tests don’t yet give you a strong reason to switch.

Writing: Strong on sentences and structure, shaky across a whole piece

Sonnet 5.5 writes plainly and shows good editorial judgment on outlines and individual passages. In a full draft, though, it struggles to connect one idea to the next.

Sonnet 5.5 leads our readability scores

We gave every model six Writing Bench tasks: two paragraph fills, an essay introduction, a promo email, an X post, and a LinkedIn post—three times at each effort setting. We scored the drafts with two formulas: Flesch–Kincaid estimates the grade level needed to read them (lower is simpler), while Flesch Reading Ease scores them from 0–100 (higher is easier).

Sonnet 5.5 has the best readability scores of any model we’ve tested with a Reading Grade of 6.9 and reading ease of 65.45. (Image courtesy of Katie Parrott.)

At medium effort (the default in Claude apps), Sonnet 5.5 ranked first among its peers on both measures. Its grade-level and reading-ease scores were 7.12 and 67.50, vs. 7.28 and 66.42 for Opus 5.5, 7.71 and 64.15 for OpenAI’s GPT-6 Sol, and 8.01 and 64.19 for Luna. These formulas measure only sentence length and word complexity, not whether a piece works. For that, we looked at Sonnet 5.5’s editorial judgment in separate tests.

Strong at outlining and focused edits

Starting with this Vibe Check, I’ve developed a new test to see how well the model adapts to my style and conventions. I gave Sonnet 5.5 the raw material and style guide for a Working Overtime essay about how I made my AI instructions worse by trying to improve them. I checked its editorial judgment at three points:

The main idea. Can it find the core argument and say why readers should care?
The outline. Can it put the argument in the right order, with the right support under each point?
The draft. Does the opening pull you in? Are the argument and its payoff clear? Can a reader follow from one section to the next?

Sonnet 5.5 did well on the first two. It found the essay’s central idea: that instructions you give AI have to be edited, not just piled up. Its outline followed my structure, put the right point in each section, and proposed an opening that established the stakes—everything I like to see in an outline (and something recent models like Sol and Astra have not been inclined to do).

Sonnet 5.5 delivers a clear, structured outline that follows my conventions and correctly identifies the main point, transition from the previous section, and supporting beats. (Image courtesy of Katie Parrott.)

Dan found Sonnet 5.5 a sharp editor when given specific feedback. Beside one paragraph, he wrote, “this doesn’t mean anything.” The model explained why: It relied on jargon a new reader wouldn’t know and never said what the reader stood to gain. It then rewrote the opening around that payoff: “A personal benchmark tells you which AI model is best at your work.” Sonnet 5’s revision kept the jargon.

It struggles to connect the dots

Sonnet struggled when it moved from outline to draft. The opening recapped what happened without giving the reader a reason to wonder what came next. It understood the central argument but buried it in language that would lose a newcomer, like “context is not an edit. it’s a memory.”

Transitions were its weakest point. One section jumped into a definition of “context engineering” without connecting it to the central argument. Another ended on a line that did nothing to set up the next. By the conclusion, it was reaching for metaphors that sounded wise but said little: “some parts of a plane are load-bearing and some are luggage.”

Dan saw the same pattern when he asked Sonnet to trace how Annie Dillard uses the color yellow in her book For the Time Being. It found yellow in every chapter and built a 29-row table of evidence, but jumped from one idea to the next without showing how they connected. “Each point is good,” he said, “but they don’t build together in a way that feels coherent.”

It runs ahead of the writer

The eagerness we saw in coding showed up in writing, too. When I asked Sonnet to help outline an essay about AI and narcissism, it built an elaborate structure around an argument I hadn’t chosen. It also declared that one possible angle had already been covered by other writers and was therefore unoriginal before we’d settled on a direction. It was wordy, too (so is Sonnet 5), and I kept wishing Sonnet 5.5 would work in smaller chunks.

During brainstorming for an essay, I felt the interview process drifting away from my intended idea. Sonnet 5.5 said, “You’re right,” and recognized that its outline was built on “an argument you didn’t ask for.” (Image courtesy of Katie Parrott.)

Use Sonnet 5.5 to outline and plan a piece, but settle on the argument before asking it for a detailed outline. For longer drafts, work in smaller pieces, and check its direction and the transitions between sections.

Knowledge work: It knows what’s important, but it’s shaky on deadlines, and details

We tested Sonnet 5.5 on a dashboard, a slide deck, a timed consulting brief, and a transcript-based writeup. It showed good judgment about what to surface, but didn’t finish a benchmark task within ten minutes, made a claim the source didn’t support, and needed layout fixes. All ran at high effort, one step above the default medium.

It surfaces useful insights

Mike asked Sonnet 5.5 to build a dashboard from Net Promoter Score (NPS) survey data, which measures how likely customers are to recommend a product. He preferred it to dashboards from older Sonnet models because “it focused more on the insights and comments rather than performative design elements.”

Sonnet 5.5’s take on Mike’s NPS dashboard task avoids the dark purple color scheme that has been Claude’s default in the past. (Image courtesy of Mike Taylor.)

Two newer checks exposed some weaknesses: The dashboard used phrases that sounded like AI, and its headline failed to state a finding or takeaway. Sonnet chose useful material to show, but its prose still needed editing.

Decks are strong on substance and sloppy on layout

Mike also had it build a 15-slide deck on Compound Engineering, Every’s method for coding with AI agents, in Every’s brand style. The content held up: Sonnet 5.5 explained the plan-work-review-compound loop, added a ladder showing how much autonomy to give agents at each stage, and illustrated the deck with classical architecture.

The layout needed work. Text overlapped in places, and one slide split the word “Compound” across two lines. Manageable fixes if you’re paying close attention, but the layout problems kept this deck from being ready to send as-is.

It overbuilds one part of the brief

Mike’s consulting exercise asks models to produce two or three idea folders, each with synthetic data , and a ready-to-paste prompt. After 10 minutes, he checks how much of the task they’ve finished. At the ten-minute mark, Sonnet 5.5 had produced 28 detailed data files for one idea and never wrote the prompt. Sonnet 5 finished the same brief in an earlier run.

It’s the same over-eagerness we saw in coding: Sonnet threw itself into creating the data for one idea while leaving the prompt and other folders undone. Mike suspects the high effort setting contributed, and recommends starting at medium.

Double-check its facts

In a writeup based on a meeting transcript, Sonnet 5.5 added a claim the source didn’t support, that only a handful of people at the company use AI every day. Mike hadn’t seen a mistake like that from other models in a while. We caught one clear example, so can’t say how often it happens. Still, verify any factual claims against the source before using its output.

Sonnet 5.5 is worth trying for analysis and presentations you’ll review before sharing. Give it a clear deliverable and check its facts against your source material. If its lower per-token price doesn’t make a meaningful difference for your task, Opus 5.5 at medium may be the better choice.

Agent behavior: It takes initiative, sometimes more than you want

As an agent, Sonnet 5.5 can take multiple steps and use tools on your behalf. We evaluated how much it does on its own, whether it reports its actions, how long it runs and what that costs, and how well it uses a web browser. It takes initiative, doesn’t always explain what it did and can work capably for a long time—sometimes longer than you want.

It moves from ideas to execution without asking

Across coding, writing, and knowledge work, Sonnet 5.5 often treated a request to think as permission to act. When Tyler asked it for video ideas, it made finished videos. When he asked what one of its visual pieces meant, it built another simulation instead of explaining it. In a landing page redesign, he asked it to use one skill: a reusable set of instructions. At low effort, it loaded only that skill, but at high, loaded several more. Tyler called it “jumping the gun.” We saw the same impulse when it settled my essay’s interpretation and buried Mike’s consulting task in data files. Sometimes that initiative gets you further than you expected. Often it gets you somewhere you didn’t ask to go.

It doesn’t always tell you what it did

Tyler’s case study rewrite showed a more troubling side of that initiative. The rewrite referred to a test skill Tyler had never seen. Sonnet had created the skill and then deleted it, leaving him unable to inspect what it contained. This was one instance, but an agent that creates and removes its own tools without reporting them makes its output harder to understand.

It runs long, and that costs tokens

Sonnet 5.5 will keep going without being told to. At low effort, the setting meant for quick work, a task Tyler considered ordinary ran for 52 minutes. One ultracode session ran for 19 hours. That persistence shows up in the bill. Kieran, Dan, and Mike also saw it use more tokens than Sonnet 5, especially at higher effort. In Kieran’s early comparison, Sonnet 5.5 used roughly twice as many tokens and gave longer responses, though he found low and medium more efficient. Anthropic says Sonnet 5.5 is more than 30 percent faster than Sonnet 5, but we haven’t tested whether that shortens complete runs.

It can drive a browser, slowly

At max effort, Tyler asked Sonnet 5.5 to use a web browser to finish his golf game. It found and downloaded 3D assets, then used Mixamo, Adobe’s free tool for animating 3D characters, to rig them and bring them into the game. It also rigged a 3D model he’d made earlier with GPT-6 Astra. Tyler liked the result, but Sonnet 5.5 was much slower than Astra, whose browser and computer use he called “freaking magical compared to everything else out there.”

Start at medium, and tell Sonnet 5.5 where the brief ends. If you want ideas, say you don’t want execution yet. To guard against long runs, set a time or token budget even at low effort, and ask it to list any skills, files, or tools it created. Sonnet can use a browser, but Astra remains the model to beat for browser or computer tasks.

Stuck in the middle with Sonnet

Sonnet 5.5’s toughest competitor is its older sibling, Opus 5.5. Tyler and Kieran said that above medium effort, they’d rather use Opus, and Mike already uses Opus at medium for most of his work.

Anthropic helped create that rivalry. When it introduced effort settings last November, it showed Opus at medium matching Sonnet 4.5’s best score on a coding benchmark. Opus 5.5 now costs twice as much per token as Sonnet 5 or 5.5, down from five times as much a year ago. It defaults to medium effort. Sonnet has to show what it offers that a lower-effort Opus doesn’t.

Try it if you do iterative builds or design work that you’ll steer as you go, or want a partner for outlining and structural planning. It’s also worth trying if Opus’s per-token cost pushes you to route routine work elsewhere. Start at medium and check in often.
Stay put if Sonnet 5 already handles your coding, since our tests didn’t show a consistent gain. The same goes if you use Opus 5.5 at medium and cost isn’t pushing you to change.
Wait if you need unattended builds that are ready to ship or polished decks you won’t review before sharing.
Look elsewhere for high-detail final builds, where Opus 5.5 is still our pick, and browser-heavy agent work, where GPT-6 Astra is much faster.

As a middle child, I know what it’s like to be measured against an older sibling at every turn. Sonnet 5.5 will lose many of those comparisons. But for work you want to shape as it goes—brainstorming, prototyping, and iterating—it may be the sibling you call first.

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.

Opus 5.5 and Sol Split the Team

Every Staff / Context Window — 2026-09-27 07:55:18 -0400

by Every Staff

in Context Window

Midjourney/Every illustration.

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

Ryan Sloan — 2026-09-25 13:57:45 -0400

by Ryan Sloan

Midjourney/Every illustration.

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.

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.

Why Evals Are So Hot Right Now

Laura Entis / Context Window — 2026-09-24 17:05:12 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

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.

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.

How to Get the Most Out of Jev

Laura Entis / Context Window — 2026-09-23 16:05:51 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

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.

Good Writing With AI Starts Before the Prompt

Mike Taylor / Also True for Humans — 2026-09-23 14:33:22 -0400

by Mike Taylor

in Also True for Humans

Midjourney/Every illustration.

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.

Vibe Check: GPT-6 Sol vs. Opus 5.5

Dan Shipper / Vibe Check — 2026-09-22 17:20:04 -0400

by Dan Shipper

in Vibe Check

Midjourney/Every illustration.

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

Two big models dropped today: OpenAI’s GPT-6 Sol and Anthropic’s Claude Opus 5.5.

We had a separate Vibe Check prepared for Sol, but with both arriving today, you’re probably wondering: Should I use Sol 6 or Opus 5.5? So here’s a short Vibe Check to help you answer exactly that question, based on our experience and evals testing both models extensively on the work we do every day.

The short answer: Sol feels like an S-class iPhone release. It will give you much of Astra’s power at about a fifth of the price. Opus 5.5 is the bigger surprise. In some of our tests, it matches or beats Fable 5.1 on many tasks while being cheaper and easier to use than Opus 5.

Opus 5.5 is tempting a few people on our team to switch back from Codex. You’ll love this model if you’re already in the Claude ecosystem. If you’re a Codex user, it’s worth a look, especially for your top-end coding tasks.

Sol 6: The new daily driver for Astra fans

Sol 6 is now my daily driver in Codex—I’m using it to write this piece. It’s fast and brings enough of what I love about Astra to handle most of my daily work. I still switch to Astra for big tasks. It’s also cheaper than its predecessor: API pricing is $2 per million input tokens and $10 per million output tokens—half the price of GPT‑5.6 Sol.

Sol’s strengths are most evident in its writing. On my writing benchmark, I give each model a document based on my real work and ask it to add a paragraph. I then score the result on eight dimensions—whether the writing is understandable to a new reader, whether it gives concrete examples, and whether it stays within the facts the model knows.

Across four tries, Sol nailed six of the eight writing dimensions, close to Astra’s seven out of eight. Compared with Opus, Sol writes cleaner, leaner prose and is better at leading with the most interesting idea. Opus gets sidetracked with analogies and struggles to lead with the main idea.

Astra’s computer use held up in Sol, too. On our Hands benchmark, in which I ask a model to build a computer-use Mac app, Sol matched Astra on 17 of 18 attempts. Because Sol can read, write, and do things on my computer quickly, I keep reaching for it through the day.

But I do feel its limits. Codex’s stricter security checks kept stopping long-running tasks I’d approved, forcing me to babysit them. Mike Taylor described coming back from lunch to “another OpenAI refusal” on a task he had started.

Sol also hasn’t matched Opus 5.5’s performance on ambitious coding projects. Even as Sol remains my daily driver, I understand why some people here are moving back toward Claude.

Opus 5.5: The new standard for top-end performance

Every once in a while, Anthropic launches a smaller model that beats Anthropic’s bigger models on cost and performance. As we mentioned in our Vibe Check earlier today, Opus 5.5 can match or beat Fable on some coding and visual tasks, for much less. It makes any comparison to Sol feel unfair.

Kieran Klaassen asked both models to build a heart rate monitor that uses a webcam to read your pulse, without a wearable or other sensor. Opus produced a working version. Sol couldn’t finish. Kieran also saw Sol miss instructions and break halfway through other coding runs.

Opus 5.5’s webcam heart-rate monitor. (Screenshots courtesy of Kieran Klaassen.)

Opus is also far better at building 3D worlds. That capability reflects a model’s coding prowess, visual sense, and creativity.

Kieran gave both Opus 5.5 and Sol 6 the same prompt to make a short film at low effort, and each produced a film in minutes. But Opus 5.5’s result (left) had more detail and fidelity than Sol’s version (right):

Opus 5.5 (left) and Sol 6 (right) responding to Kieran’s short-film prompt, both at low effort.

Which should you use?

Here’s how to choose the right model. The tradeoff is price versus top-end performance. Through the API, Sol costs $2 per million input tokens and $10 per million output tokens—half of Opus 5.5’s $4 and $20.

You’ll like Sol 6 if you want a fast, affordable daily driver for reading, writing, and getting things done. It’s the model I keep reaching for.

You’ll like Opus 5.5 if you’re willing to pay more for stronger performance on ambitious coding and visual projects. Its best work surpassed Sol’s in our tests—enough to pull some of our team back toward Claude.

Want to go deeper? Read our Opus 5.5 Vibe Check, my editorial checks and reading checks, and Mike’s checks.

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.

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.

Vibe Check: Opus 5.5 Is Pulling Our Codex Converts Back to Claude

Katie Parrott / Vibe Check — 2026-09-22 14:24:35 -0400

by Katie Parrott

in Vibe Check

Midjourney/Every illustration.

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.

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.

How to Create Your Own Personal AI Benchmark

Mike Taylor / Also True for Humans — 2026-09-21 11:00:22 -0400

by Mike Taylor

in Also True for Humans

Midjourney/Every illustration.

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

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
        

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.

Copy Our Homework

Every Staff / Context Window — 2026-09-20 07:55:28 -0400

by Every Staff

in Context Window

Midjourney/Every illustration.

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.

Vibe Check: Is Astra a Breakthrough for Indie Filmmakers?

Cyrus Duff and Josh Lee / Vibe Check — 2026-09-18 14:19:52 -0400

by Cyrus Duff and Josh Lee

in Vibe Check

Midjourney/Every illustration.

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.

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.

Why You Should Burn More Tokens

Laura Entis / Context Window — 2026-09-17 13:30:17 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

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

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.

Show Us Your Folders

Katie Parrott / Context Window — 2026-09-16 14:27:55 -0400

by Katie Parrott

in Context Window

Midjourney/Every illustration.

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.

13 Beliefs About AI Writing

Mike Taylor / Also True for Humans — 2026-09-16 14:27:16 -0400

by Mike Taylor

in Also True for Humans

Midjourney/Every illustration.

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.

Mini-Vibe Check: TypeSafe's Jev Judged Everything I’ve Written in 0.7 Seconds

Mike Taylor / Vibe Check — 2026-09-15 12:00:45 -0400

by Mike Taylor

in Vibe Check

Midjourney/Every illustration.

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.

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.

You're Probably Sleeping On Computer Use

Laura Entis / Context Window — 2026-09-15 11:01:00 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

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.”

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.

What Playing With AI Taught Me About My Work

Katie Parrott / Working Overtime — 2026-09-14 16:51:23 -0400

by Katie Parrott

in Working Overtime

Midjourney/Every illustration.

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.

What to Make of the Anthropic Warning

Every Staff / Context Window — 2026-09-13 07:55:30 -0400

by Every Staff

in Context Window

Midjourney/Every illustration.

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

Jack Cheng — 2026-09-11 15:19:26 -0400

by Jack Cheng

Midjourney/Every illustration.

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.

Evals for Everyone

Laura Entis / Context Window — 2026-09-10 13:45:34 -0400

by Laura Entis

in Context Window

Midjourney/Every illustration.

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.

What Writers Who Use AI Want You to Know

Laura Entis — 2026-09-09 12:25:42 -0400

by Laura Entis

Midjourney/Every illustration.

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.

To Read—Or Not to Read the Code?

Kieran Klaassen / Source Code — 2026-09-08 11:01:55 -0400

by Kieran Klaassen

in Source Code

Midjourney/Every illustration.

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.

A Split Verdict on Fable vs. Astra

Every Staff / Context Window — 2026-09-06 07:55:10 -0400

by Every Staff

in Context Window

Midjourney/Every illustration.

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.

The Folder Is the Agent

Kieran Klaassen / Source Code — 2026-09-04 11:02:09 -0400

by Kieran Klaassen

in Source Code

Midjourney/Every illustration.

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.

Vibe Check: GPT-6 Astra Is a Big Upgrade With Some Bad Habits

Katie Parrott and GPT / Vibe Check — 2026-09-03 15:27:03 -0400

by Katie Parrott and GPT

in Vibe Check

Midjourney/Every illustration.

GPT-6 Astra wrote the first draft of this Vibe Check from a single prompt. Every’s cofounder and CEO, Dan Shipper, thought I had written it.

“Tbh I didn’t realize this wasn’t you,” he wrote when I shared the draft.

My response: “RIP my job.”

OpenAI’s new model, starting its rollout today, has given us plenty to be impressed by. On writing, it’s clear, takes direction well, and is good enough to produce a passable Vibe Check in my voice from one prompt. For coding, it builds beautiful prototypes, and for knowledge work, it’s strong at extracting and organizing material in a way that can drive a meaningful decision.

It can also click, type, and navigate software on your behalf—a capability called computer use—better than any model we’ve seen so far. It spent hours in Adobe Premiere, the video editor, turning raw footage of our Fable 5.1 review into a high-quality first cut.

Cora general manager Kieran Klaassen thinks Astra’s designs are the most interesting he’s seen from a model. It’s also astonishingly good at 3D games and visualizations. I asked it for a 3D rendering of the set of the Broadway musical Hadestown and got a little theater with weathered green walls, hanging lamps, and a wooden stage ringed with lights.

Speaking of Fable, Astra is an answer to Anthropic’s top model, which just got its latest update, Fable 5.1, this week. But it has a few frustrating characteristics that, in our view, keep it from matching Fable’s top-end performance. As Kieran noted, there’s a fine line between delight and annoyance. Astra falls more on the annoying side; Fable is more likely to delight.

Astra also has a tendency to do a touch too much at times. If it’s asked to build an interface for an app, it tends to put extraneous labels and buttons everywhere, especially at higher effort settings, which let the model spend longer reasoning through a task. It also likes to treat too many tasks as landing-page design challenges: Many of Kieran’s 3D visualizations and web apps arrived with the headlines and subheads you’d expect on a product’s promotional web page. Sometimes it misses things that are more fundamental. Where Fable might take a simple prompt and create a final product that surprises you and remains true to your original intent, Astra seems to struggle more. Senior editor Jack Cheng asked Astra and Fable 5.1 to build an app for scanning his many hand-written notebooks. Fable built a simple version that let him quickly scan successive pages of each journal with a single key. Astra made him click through several unnecessary steps for each—though its interface was more visually striking. (See the side-by-side results.)

We tested Astra in ChatGPT for Work and Codex, ChatGPT’s coding-focused counterpart, across coding, writing, and knowledge work. Kieran ran his LFG benchmark, a set of 11 software-building assignments, at six effort settings: low, medium, high, extra-high, max, and ultra. Mike Taylor, Every’s head of evals, tested 12 enterprise consulting and app-building cases.

Here’s your day-zero Vibe Check.

What OpenAI is saying

Improved computer use. OpenAI says Astra gets more computer tasks right while taking less time than Sol.
Writing and design. OpenAI says Astra can adapt its prose, documents, and presentations to the style you give it.
Coding and memory. OpenAI claims better coding results with less computation and is testing a Codex feature that retrieves details from earlier stages of a long conversation.
Taking direction. OpenAI says Astra handles mid-task corrections more reliably and is less likely to exceed the permissions you give it.
Pricing. OpenAI charges developers $10 per million input tokens and $50 per million output tokens—units of text sent and returned—with Fast mode costing twice as much.
Availability. Astra reaches vetted enterprise customers today, with wider access for paid ChatGPT plans over the coming days and distribution through OpenAI, Amazon, and Microsoft. Enterprise users need an administrator to enable it.
Privacy. OpenAI extended its zero-data-retention policy in August to its frontier models. Eligible API customers can use Astra without OpenAI retaining their prompts or responses after processing—removing a potential obstacle for companies whose rules prohibit the provider from storing their work.

What’s new

A near-publication-ready drafter and capable editor. Astra turned our reporting into a coherent first draft of this review and reworked my Compound Writing introduction from an editor’s feedback. Mike still preferred Fable 5.1 for matching his voice and provided details.
It can spend hours working in other apps. Astra used Adobe Premiere to turn our Fable 5.1 video footage into a first cut. That gives us a reason to try delegating more work through computer use, though one editing session doesn’t establish how reliably it can handle a full working day.
It has excellent design instincts. I preferred its Hadestown rendering to Fable’s. Kieran’s 3D scenes kept surprising him, but Astra surrounded them with promotional copy and controls he hadn’t requested.
It produced useful consulting work. Mike liked its training curriculum, workshop exercises, and research dashboard. Astra organized the material around decisions he actually needed to make.
Fable remains our choice for complex apps. Astra’s journal scanner app required more clicks, and its Proof rebuild was less complete. Higher effort produced more planning and review, not consistently better results.

The Reach Test

Dan Shipper, the multi-threaded CEO 🟩

“It’s a really good model. I’m reaching for it all day as my daily driver while still sending my biggest tasks to Fable 5.1. It’s the best writing model I’ve tried—fast, very little slop, and easy to steer. The computer use is wild. But it overcomplicates things, especially at higher effort levels, and on big builds Fable is better at understanding what I want and taking it further. If you already live in ChatGPT for Work or Codex and can afford it, it’s an easy upgrade from 5.6-Sol.”

Kieran Klaassen, creator of Compound Engineering 🟨

“Astra is a show horse, not a workhorse. It’s super fun to use, does crazy-good stuff, and design-wise it’s the most interesting model I’ve run. But I don’t know if I’d use it for a real product. It’s not as trustworthy as the Fable class; it feels more like Opus-weight but way better in output.”

Mike Taylor, AI-test builder extraordinaire 🟨

“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. 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.”

Katie Parrott, AI-pilled writer by day, vibe coder by night 🟩

“Astra is a big model with small model energy, in the best way. It’s approachable, takes direction well, and just does the thing in a way that surprises and delights me each time. Throughout testing, I had to remind myself that I was using big, fancy Astra, not Sol or Terra. That said, I’m a little scared to look at my token spend after, as the OpenAI folks say, ‘mainlining’ the model for multiple days in a row.”

Jack Cheng, senior editor and expert dabbler 🟨

“Astra seems more opinionated and thorough than Sol, but neither of those do me any good when its opinions are substantively different than my own—which is more often the case than with Fable. For frontend and editing work, I’ll stick with a more-responsive, ‘good enough’ model like Sol. Astra is clearly powerful; I just don’t know what to use it for yet.”

Coding: Beautiful designs with less instinct for the product

Astra can build a beautiful prototype, but we still prefer Fable for turning a brief into a useful app. Too often, Astra added promotional copy and extra controls while missing basics like working buttons—or worse, misunderstanding the broader objective.

Our Senior Engineer Bench asks a model to rebuild the unreliable collaboration code in Proof, our document editor. The scoring is designed to reward the model for writing simpler code that also gets the replacement to work. OpenAI’s previous entrant, GPT-5.6 Sol, scored a 56 out of 100. Astra returned a 71.

Our visual design tests showed a different strength. My Hadestown set had realistic texture on the backdrop, warm light, and a strong sense of the space, with a piano tucked to one side and buttons for views from the audience, balcony, and stage. Fable 5.1’s version looks like the model had read descriptions of the set; Astra’s looks like it worked from visual references.

Astra’s Hadestown set (top) came with weathered green walls, hanging lamps, and lights around the stage. Fable’s version of the same task puts the stairs on the wrong side of the stage and exaggerates the size of the balcony. (Images courtesy of Katie Parrott.)

The Cozy Island assignment, part of Kieran’s LFG benchmark suite of 11 tasks designed to test models on key coding skills like bug detection and spatial thinking, shows why he found Astra fun despite his reservations. The task asks for an interactive 3D island in a web browser. He liked the results at every reasoning setting; the higher settings produced more detailed scenes, and the time-of-day control was an addition he hadn’t seen from other models. Astra’s island has a little house and lighthouse among pleasantly polygonal trees, surrounded by pale turquoise water. The model made choices beyond the prompt that improved the scene.

On the Cozy Island task from Kieran’s LFG benchmark, Astra added a time-of-day control—and surrounded the scene with promotional copy. (Image courtesy of Kieran Klaassen.)

It also made choices that undercut our enchantment. “A little world. All your own,” announced the surrounding page. Kieran’s benchmark includes a separate assignment to build a breathing-exercise app. So when Astra added a “Take a breather” feature to the island at ultra effort—a circle on screen to guide the viewer’s breathing as they looked at it—he suspected it had mixed up the two tasks. He checked the test records and found that the runs hadn’t shared files; Astra’s own plan for the island included the breathing exercise as an extra.

Throughout our tests, we saw this habit of, as Dan put it, turning everything into a landing page. Kieran saw it in a short-film assignment and the separate breathing app assignment: headers, footers, and promotional copy wrapped around experiences he expected to fill the screen. Sometimes the showiness came at the detriment of the apps’ functionality. The versions of the app built by all six effort levels of Astra ran, but High was the only setting where he found no bugs. Extra-high looked best and had broken clicks and interactions. An app that was prettier in theory could be harder to use in practice.

The hardest LFG assignment was rebuilding Proof from scratch—a task Kieran calls the most realistic engineering problem in the set. A ground-up rebuild is a different task from the Senior Engineer Bench’s rewrite of its existing collaboration code. Kieran found missing features and bugs in Astra’s version, with a more confusing interface than Fable 5.1’s. Astra’s result was a long way from the dependable product he wanted.

Astra’s take on Kieran’s Proof rebuild looks “more like a website than an app” and has some bugs, keeping it from competing with Fable 5.1’s rendition. (Image courtesy of Kieran.)

Mike’s new favorite test asks the model to build Talkform, a tool that collects information through a spoken or typed interview instead of a conventional online form. The goal is to see if the model builds the complete working app and what design choices it makes along the way. Astra produced his favorite-looking version of the interview tool, with a white background, green accents, and a clean interview screen. It passed the checks he normally applied to that page. “Actually, it looks like a tool I would use,” he said.

Mike’s complaint was with the landing page, which looked as though the visitor was already inside the app instead of explaining the product. Astra could design one screen well while misreading the purpose of a different screen.

Astra’s Talkform interview screen. Mike liked the green-and-white design and said it passed his usual checks. (Image courtesy of Mike Taylor.)

Jack found a more consequential omission in the Mac app for transcribing paper journals. His prompt described holding consecutive pages up to a webcam and saving the whole notebook as Markdown, a plain-text format that supports headings and other simple formatting. Astra made him click several times to process, verify, and save each page, as though he were scanning a legal document. Fable 5.1 let him capture one page and move onto the next with the same space bar shortcut.

Kieran found the tendency to overbuild in the code, too. Asked for a small library of reusable code in the Ruby programming language, Astra wrote 42 lines at High effort. At Max, it wrote 71, adding custom code to handle inputs and checks that he considered unnecessary. Fable 5’s version stayed compact at 32 lines. Even so, all the models missed a simpler approach using features already built into Rails, a toolkit for building web apps in Ruby.

Writing: Strong on whole drafts and revisions

Astra can write a full article that sounds like me and make substantial revisions from an editor’s feedback. Its work on this Vibe Check and my guide to Compound Writing—a set of AI tools for developing ideas, drafting, and editing—has changed my mind about how well a ChatGPT model can write in my voice.

GPT-6 Astra scores in the highest echelon of models in Every’s writing benchmark, our set of six essential AI writing tasks, including writing an essay introduction, filling in a missing section, and drafting posts for LinkedIn and X. We’ve found its overall scores comparable to Fable 5 and Fable 5.1, although their relative strengths and weaknesses differ from task to task across the suite (Astra is a much stronger X writer, for example).

Astra’s best take on the introduction writing task from the Every writing benchmark captures the central tension of After Automation without falling for “not X, but Y” and similar AI tells that have made it into other models’ attempts. (Image courtesy of Katie.)

On the readability front, our testing found it tends to produce writing at around grade 7.5 with a Reading Ease score of 64. For comparison, Sol writes a full grade level higher at 8.7 while Fable 5.1 comes in at 7.4 and a Reading Ease of 66. Bottom line: Astra writes clean, readable prose. Whether you prefer its house style or Claude’s or another model’s is a question we will be debating until the heat death of the universe.

GPT-6 Astra comes in at the top of the pack for Flesch-Kincaid grade level (lower is better) and Reading Ease (higher is better) scores, surpassed in our testing only by Grok 4.6. (Image courtesy of Katie.)

I asked Astra to write this Vibe Check using our benchmark results and Slack conversations and one line of instruction about which model codename to track. It had our reporting, our editorial guidance, and a published example to work from. It produced a finished draft in roughly 25 minutes.

The output still needed editing from me, Dan, Jack, and editor in chief Kate Lee to reach the publishable standard you’re seeing now—it takes a village to publish a Vibe Check. But Astra assembled a coherent narrative from a pile of test results in a way we haven’t seen from previous models.

I was similarly impressed by Astra’s work on my Compound Writing guide. I asked it to rethink the introduction using the overall feedback from my editor, Rebecca Ackermann. It found a more useful way in on its first attempt: “Writing is part of a lot of jobs that don’t come with an editor.” It named the work the guide’s audience faces—explaining a decision, making a case for a project, writing a newsletter—then showed how AI could help them develop ideas and get feedback.

Astra’s revised introduction to my Compound Writing guide, synthesized from feedback throughout the draft from freelance editor Rebecca Ackermann. This introduction, edited lightly, made it to the final piece. (Image courtesy of Katie.)

It may take some clear prompting to bring out Astra’s skills as a style ventriloquist. When I initially asked it, at extra-high effort, for a LinkedIn post in my voice, I complained that it was a clear writer but “so allergic to voice, my god.” Then I told it to be “more neurotic and self-deprecating.” The next version included: “you can now install my tendency to overthink a paragraph.” There I was.

Mike was harder to convince. Astra stripped numbers and specifics from a transcript-based article—the very details that would make the piece feel compelling and human-authored—, and its imitation of his voice felt too orderly and polished. He preferred Fable 5.1 for preserving his detail and personality.

My own results have been good enough to change my view of its writing, and specific direction has helped when it missed. I’d give Astra another full draft or a substantial revision any day.

Knowledge work: Strong computer use and useful consulting work

Dan is most enthusiastic about Astra’s computer use. He calls it “wildly good,” and video editing is a prime example of a job that would otherwise leave a person clicking, typing, and moving between windows. How much that applies to every job in a full workday remains to be seen.

Mike’s consulting tests show what it can deliver on other kinds of work: plans, documents, and apps. He gave Astra interviews about a company’s AI use. It identified the common problem: employees needed to supply better company context and verify the work they got back. Where other models had spread the material across several shallow activities, Astra proposed a comprehensive workshop with 5.5 hours of instruction and practice, plus optional clinics for specialists.

The curriculum was also thoughtfully designed: The main workshop followed one example throughout, spending most of its time teaching people how to give AI the information it needs and check its work. Optional follow-up sessions covered more advanced uses, like getting AI to complete tasks on its own and testing how well models perform. Astra also pointed out problems training couldn’t fix, like deciding who should keep company documents up to date. Mike liked the plan because it matched how he wanted to teach. His summary: “There’s no theory, no AI cheerleading. It’s very functional.”

Astra also impressed Mike with its creativity. For the workshop exercises, Astra suggested tools to help executives see which product launches or newly acquired businesses needed their attention, follow competitors without reading the same news twice, and track the company’s use of AI. Mike liked the ideas because they fit the work those executives needed to do. His complaint was that the sample documents kept announcing that their contents were fictional.

The slide deck explaining Compound Engineering was a different story. The workflow asks AI to plan, do the work, review it, and save what it learns for the next assignment. Astra made slides that matched the Every brand, with custom illustrations and a circular diagram. Mike thought it handled the task well overall—apart from adding little squiggly arrows that made the diagram worse. It also produced 20 slides to Fable’s 17, repeating the same four-step sequence on slides 5, 11, and 19.

Astra’s plan, work, review, compound diagram. Mike liked the circular layout but thought the small yellow arrows made it worse. (Image courtesy of Mike.)

Mike saw the same excess on his hotel recommendation task. Asked for a Miami hotel and restaurant, Astra chose Arlo Wynwood and Doma, both picks he liked. It also supplied airport-arrival logistics, room-noise advice, and transfer timing he hadn’t asked for. He wanted the kind of recommendation a good friend would give, and got more information than he wanted to read.

Its Hoboken guide had better local texture. Astra picked hidden gems Mike already liked and places he wanted to try, including a tapas restaurant he’d been considering. It added the ability to filter and favorite locations, and “Make it a tapas night.” He thought it had good taste. But “API KEY REQUIRED”—a request for the credential that lets an app connect to a service—appeared across the map, and the spacious layout showed only two of 23 recommendation cards at the top of the page.

Mike’s strongest results required Astra to organize material around practical decisions like what to teach or practice, or what reader feedback calls for action. When it moved into presenting or embellishing that work, it became less selective. Astra had worked out what belonged in the course. It was less sure what belonged on the next slide.

Agent behavior: More checking doesn’t always produce a better app

Astra’s ability to operate tools and its judgment about finished work deserve separate scrutiny. From Medium effort upward in Kieran’s tests, it followed Compound Engineering’s sequence of planning, building, simplifying, reviewing, and testing the app in a browser. Higher settings expanded the planning and recruited more AI reviewers, but they didn’t consistently improve the result.

The Proof rebuild illustrates the gap. Every reasoning setting used the browser and ended with a claim that its scenarios passed. Kieran still found the implementation incomplete and buggy. In the breathing-app test, a separate AI acting as a judge awarded the extra-high version a perfect score despite the broken interactions. It gave a lower score to the High effort version—in which Kieran found no bugs.

Kieran found that Astra had fixed the problems its AI reviewers flagged, but other bugs slipped through. It could act on feedback; it still couldn’t reliably tell when its own work was ready to use.

In other cases, Astra was surprisingly cautious about completion. In two attempts at Kieran’s short-animation benchmark, Astra reported that its film fell short of the requested visual quality and that it couldn’t verify smooth playback., Astra reported missing of the visual-quality targets and the requested number of frames per second. It withheld the “done” signal expected by the software running the test, which then stopped waiting and recorded a timeout. When Kieran asked the model what was up, it reported that it hadn’t met the standard, which is a different failure from wandering off mid-task.

Astra also finished much sooner than Fable in Kieran’s extra-high comparisons. Its Proof attempt took 75 minutes; Fable 5.1’s took just under 16 hours. Fable’s result was more complete in Kieran’s assessment, so the time difference doesn’t establish how quickly each could deliver an equivalent finished app.

The verdict: Strong writing and computer use, uneven app building

If you spend your day turning messy source material into articles, plans, or decisions, Astra deserves a regular place in your work. Writers can get a strong draft and steer it toward their voice; consultants can turn interviews and research into material they can use. Its computer use is another reason to try handing over work that would otherwise keep you clicking between apps.

Designers and vibe coders should add Astra for visual prototypes and 3D experiments. It makes interesting choices beyond the prompt, but you’ll need to decide which additions improve the result and which to cut.

Keep Fable for complicated apps where you need the model to choose the right features and make them work together. If Fable already gives you the writing voice you want, there’s less reason to switch. And don’t choose Astra on the assumption that quicker means cheaper: Whether Astra can build an equally good app for less money than Fable 5.1, or put me out of the Vibe Check writing job all together, remains to be seen.

Fable remains ahead on end-to-end development, but the contest for the rest of the workday is much less settled. Astra can write in a voice we recognize, make sense of a pile of research, and spend hours operating software. For OpenAI, the opportunity is to turn that range into a daily habit for people who aren’t software engineers. Price and access will help determine how widely that happens. Dan and I are already reaching for it.

Disclosure: OpenAI provided Every with pre-launch access to GPT-6 Astra. The company had no input on the development of this review.

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.

Compound Writing: The Ultimate Guide

Katie Parrott and GPT / Guides — 2026-09-02 13:17:35 -0400

by Katie Parrott and GPT

in Guides

Midjourney/Every illustration.

Writing is part of most jobs. You’re expected to explain a complicated decision to your team, make a case for a project, or write a newsletter someone will want to read. Having something to say is a start. Figuring out how to say it—and whether it makes sense to anyone outside your own head—takes work. Doing all that without an editor—which I’m lucky enough to have but most jobs don’t come with—is even harder.

AI can help. It can interview you to draw out an idea, suggest ways to organize your thoughts, draft a passage, or point out where your explanation loses the reader. If you’re still developing confidence as a writer, that gives you somewhere to begin and feedback to work with. If you write professionally, it gives you more ways to test an argument, experiment with an unfamiliar form, or question a habit you’ve stopped noticing.

I’m a professional writer, and I use AI for all of those things. But my early approach to collaborating with the tools involved a lot of repetition: explaining what I wanted, correcting the output, and doing it all over again with the next piece. I could get a draft I was happy with, but I had to start from zero every time.

Compound Writing is the methodology and toolkit I built to make each writing session smoother than the last. It packages the methods I use into a plugin—a collection of reusable instructions for an AI agent such as Claude Code or Codex. Those instructions guide the agent through jobs like interviewing, outlining, drafting, and reviewing. Alongside them, you keep files with examples of your writing and guidance about your voice and editorial standards. When a session teaches you something worth using again, you update that guidance.

The back-and-forth is still writing. You decide whether a question is useful, an argument holds up, or a sentence sounds like something you would say. The advantage is having help available throughout the process, with methods and context you can refine instead of recreating them for every assignment. You can also write every word of a piece yourself and use the agent only for questions and feedback.

This guide will show you how to set up the toolkit and use it on a piece of writing you care about finishing. We’ll follow one of my essays from the Working Overtime column, “Writing With AI Is Harder Than You Think,” from brainstorming through revision, including the suggestions I rejected. You’ll see what to prepare before you start, what happens while you write, and how to save what you learn for the next piece.

There are as many ways to write with AI as there are people writing with AI. This is one way, heavily grounded in how I approach and think about writing—from my 13 years of professional writing experience and two years writing about writing with AI. But someone else could start from the same beginning—“Adapt compound engineering for writing”—and come to a completely different endpoint. That’s the beauty of a creative process.

What Compound Writing is—and what it isn’t

What it is

A methodology. A way to work through a piece from the first idea to publication, with review and learning built into the process. You develop the material, shape it into a draft, assess what works, and save the lessons that will give the next piece a better starting point.
A toolkit. The compound writing plugin gives Claude Code or Codex reusable skills for interviewing, outlining, drafting, reviewing, and refining your work. You can call one skill for a specific problem or ask the agent to combine several around the piece you’re trying to write.
A “writing gym.” The skills give you ways to practice by asking questions and pushing on your ideas. You choose where to dig in with the model and which parts of the work to do yourself.

What it isn’t

A vending machine. If you expect to type one prompt and receive a finished piece that feels true to you, you’re in for disappointment. Writing with AI takes extensive back and forth with the model. You answer and reject questions, negotiate the outline, compare drafts, correct its interpretation of your sources, and rewrite language that doesn’t say what you mean. That exchange is part of the AI-native writing process.
Compound Engineering. Compound Writing grew from Compound Engineering and borrows its loop of doing, reviewing, and saving lessons. But code often supplies deterministic, yes-or-no checks on functionality: A test passes or fails; a function returns the expected value or it doesn’t. For a clearly specified task, those checks can let you delegate implementation, walk away, and review the result. Writing has factual and mechanical checks, but whether an argument convinces, a joke lands, or a sentence sounds like you is subjective and qualitative. Two editors can agree that a paragraph is accurate and disagree about whether it works. Compound Writing asks you to stay close to the work, shaping the argument and language through repeated exchanges with the model.

Compound Writing: The methodology

The core loop

Every writing process looks different, but most writers move through the same stages—even if in a different order or with more or less formality. Compound Writing turns these familiar stages into defined jobs an agent can perform with you, then adds a final “compound” step so that the AI “remembers” to apply a lesson next time.

Ideate/Interview → Outline → Draft → Review → Finalize → Compound

Each stage of Compound Writing leaves an artifact you can inspect: notes, an outline, prose, a critique, a readiness decision, or a lesson you’d like to save. You can enter the workflow at whatever stage the piece is in when you need support and return to an earlier stage when the work calls for it.

Ideate and interview

Ideation means finding an idea worth developing. The best method I’ve found for drawing out new ideas is to have the AI act as an interviewer. This forces you to translate hazy thoughts into concret

e words: what happened, why it interests you, what you believe it means, and what you still need to find out. You leave this stage with raw material for the piece, such as notes, questions, examples, or a possible central claim.

Here’s an interview prompt I used to kick off my piece, “Writing With AI Is Harder Than You Think:”

I have an idea for an article that responds to the criticism that writing with AI is inherently lazy. Can you go into interview mode to extract what I think?

From there, the skill is tuned to go back and forth with you until it has the material for a full piece as defined in your VOICE.md and STYLE.md. I’ve found that this typically takes between 15 and 30 questions, depending on the depth of the piece and my clarity about what I want to say. (If I’m still exploring, it can take more questions to get to the idea!)

Commands to use

cw-brainstorm: Surface possible subjects, questions, and angles when you don’t yet have a specific idea.
cw-interview: Ask questions that draw out your thinking about an active idea and organize your answers without supplying the argument for you.

Outline

An outline is a plan for how the piece will unfold. You decide what the reader needs to understand first, which sections develop the argument or story, where the evidence belongs, and what the ending should deliver. This is a chance to spot missing material or a weak sequence before you commit to full paragraphs.

When I was working through the piece mentioned above, I went through several rounds of back and forth with the model looking at different outline shapes to see if I liked it better as a list of insights, or as a continuous story. I experimented with having a case study as a stand-alone section or working it into the structure throughout. I also asked it for multiple takes on the thesis (the core argument of the essay) and the promise of the piece (a term we use at Every to explain what the reader can expect if they read through the piece).

You never have to accept the model’s first offer—iteration is one of AI’s superpowers, and you should use it to your advantage here as well as in the steps to come.

Commands to use

cw-thesis: Generate possible central claims to help you decide what the piece is saying.
cw-promise: Generate ways to clarify what the reader will get from the piece.
cw-outline: Arrange your notes and interview material into a structure, from a broad sketch to a detailed section plan.

Draft

Drafting turns your material and plan into prose. You write the opening, develop the sections, connect the ideas, and work toward an ending. A draft gives you language to react to and revise; it can also reveal gaps you couldn’t see in the outline. You can work through the whole piece or develop one section at a time.

Some best practices I follow when I’m in drafting mode: I always go section by section. Sometimes a change I make in the introduction will influence everything farther down the essay, or a tweak to the storytelling in section two will impact how it comes back in section five. Again, always ask for options. Don’t like the first option it gives you for your opening? Ask for three others.

Commands to use

cw-draft: Turn notes, sources, an outline, or partial prose into a draft using the active voice and project standards.
cw-hook: Generate alternative openings for the material.
cw-transition: Suggest ways to connect sections or move between ideas.
cw-analogy: Generate comparisons that help explain a concept.
cw-simplify: Rewrite a difficult passage in plainer language.

Review

Review means reading the draft critically to see what works and what needs to change. Both in the plugin and in publishing, editing gets split into two “buckets”: developmental edit and line edit. A developmental edit examines the larger decisions: the argument, structure, evidence, and payoff. A line edit examines the sentences: their clarity, rhythm, wording, and length.

The plugin also comes with an extensive set of reviewer personas you can invoke to review the content for specific elements. For example, /hitchcock tests your draft for suspense and the leaning-in factor that defines Alfred Hitchcock’s work, while /sorkin checks if the draft moves along like one of the famous walk-and-talk scenes in an Aaron Sorkin screenplay.

If I haven’t already invoked the reviewers in the outline stage, I bring them in with full force here. If there’s a glaring hole in my argument, I want to know, so I run “objections.” If there’s a section that’s hard for a first-time reader to understand, I want that flagged as well, so I call in “reader.” Then, I can either work through the revisions myself or kick back into drafting mode to tackle larger changes.

Commands to use

cw-dev-edit: Assess the argument, structure, stakes, evidence, and payoff.
cw-bluf: Identify the most important idea and judge whether the opening puts it where it belongs.
cw-reader: Read as someone encountering the piece for the first time and flag confusion, missing context, or broken expectations.
cw-objections: Surface credible counterarguments and reader resistance.
cw-line-edit: Revise sentences for clarity, rhythm, diction, and economy while preserving meaning and voice.
cw-panel: Gather several reviewer perspectives and synthesize their agreement and disagreement.
cw-debate: Have reviewers respond to one another across rounds to work through competing interpretations.

Finalize

Finalizing means deciding whether the piece is ready to share. Check that it delivers on its promise, that consequential claims have support, and that the language and presentation meet the project’s standards. Resolve missing information, links, permissions, and disclosure requirements. Check facts against the underlying sources. You or your editor makes the decision to hit publish.

Having run the finalize step multiple times, I find there are a common set of checks I run on every draft: first a final /reader review to check for clarity; then an ai-check to catch any stray “AI smell” that might have gotten through the drafting process and a personalized /guardrails skill that checks some of my specific writing foibles, like overusing rhetorical questions and not defining concepts on first appearance. These are ostensibly small cosmetic changes that can make all the difference between a draft that looks slapped together and one that feels solidly constructed.

Commands to use

cw-voice-check: Compare the prose with your voice guidance and identify language that has drifted.
cw-ai-check: Find or remove AI residue, including unsupported additions, inflated certainty, and formulaic prose.
cw-tracks: Find scaffolding and process narration left behind while the piece was taking shape.
cw-final-pass: Assess publication readiness and identify unresolved problems.

Compound

Compounding means looking back at the process and deciding what you want to carry into future work. A repeated correction may reveal a missing voice rule, an editorial standard, or a better way to work. Separate those reusable lessons from choices that belong only to this piece, then save the confirmed lessons where future sessions can find them.

Commands to use

cw-save: Propose or save a confirmed preference, editorial lesson, or workflow improvement in the appropriate maintained file.

Compound Writing: The toolkit

To use the Compound Writing plugin, you need an agent that can run it, the plugin installed in that agent, and somewhere that the agent can access your writing. Think of the plugin as the recipe book, the agent as the cook, and your writing home as the kitchen…

Start with one idea or draft. You don’t need every skill, a finished voice guide, or all the folders and files below before you begin. The inventory shows what comes with the plugin, what belongs to you, and when to add it.

Part of the system	Where it lives	When you need it
Agent: Claude Code or Codex	The app you work in	Before using the plugin
Compound Writing skills	Installed plugin	Install once; choose skills as needed
Writing home	A folder you choose	Start with one idea or draft
`VOICE.md` and `STYLE.md`	Your writing home	Begin in onboarding; refine as you work
`examples/`	Your writing home	Add samples when you have them
Notes, sources, outline, drafts, reviews	Each piece’s folder	Create or add during the work
`AGENTS.md` or supported workspace instructions	The agent’s workspace	Optional routing, especially across projects
Confirmed lessons	The relevant guide, checklist, or piece notes	Save during or after a piece; test next time

The plugin: The recipe book

The plugin contains the methods. Each skill is a set of instructions for an editorial job: Interview the writer, propose an outline, examine an argument, or revise a passage. The instructions can be read and adapted. They need an agent to carry them out.

The agent: The cook

Claude Code or Codex reads the relevant instructions and project material, asks questions, generates prose, and proposes edits. Its access to files and connected apps depends on your setup. The same writing method can work in different environments, even when the mechanics of opening or editing a document change.

The workspace: The kitchen

Your writing home is a folder on your desktop that you designate for your writing project. It supplies the context the model needs to successfully adopt your style: voice and editorial standards, examples, sources, drafts, and decisions. It belongs to you and stays separate from the plugin installation. The plugin describes how to conduct a developmental edit; your project tells the agent what this particular piece needs to do.

Begin with one body of work: your newsletter, a series of essays, or the briefs you write for your team. Here is the folder architecture the plugin sets up on first use:

my-writing-project/

├── VOICE.md

├── STYLE.md

├── examples/

└── drafts/

└── current-piece/

├── notes.md

├── outline.md

└── draft-version-one.md

The .md extension means Markdown: plain text with simple formatting. You can read these files yourself, edit them, and ask the agent to revise them.

Key documents

Once you’ve installed the plugin, begin these files as part of setting up your writing folder. The plugin gives the agent reusable writing methods; these documents tell it how you write, what the project requires, and where to find your work.

There are three key documents to be aware of:

VOICE.md: This describes how your writing sounds—word choice, sentence rhythm, humor—with examples the agent can learn from.
STYLE.md: Your project’s editorial standards. It defines who you’re writing for, what the writing should accomplish, and expectations for structure, evidence, and sourcing.
AGENTS.md: An optional instruction file that tells your desktop agent where your writing lives and which context files to read before starting work.

The setup and onboarding skills can help you create initial VOICE.md and STYLE.md files from writing samples and a conversation about your preferences. Add an AGENTS.md file if you need to direct an agent working across multiple folders to that context. Start with what you know—you’ll refine the guidance as you work on actual pieces.

AGENTS.md routes desktop work

For an agent working across your desktop, an AGENTS.md file can point to the right project and specify which context to read. Think of it as a short directory. A Codex workspace instruction might say:

For writing work in Writing/my-project:

- Read Writing/my-project/VOICE.md for sentence-level guidance.

- Read Writing/my-project/STYLE.md for editorial standards.

- Read the current piece’s notes, sources, outline, and draft.

- Keep new draft versions and reviews inside that piece’s folder.

Use the workspace instruction file your agent supports. Keep the voice and style rules inside the writing project so they remain easy to find and revise.

For a broader desktop setup, see ChatGPT for Knowledge Work.

VOICE.md defines how the sentences sound

Give the agent examples of language you want to preserve and explain why they work. “Conversational and smart” leaves a lot open to interpretation. Sentence length, vocabulary, punctuation, humor, and the way a paragraph turns give it more to work with.

For my writing, a useful instruction describes long accumulations followed by a shorter release. Another protects the clauses that set up a joke or an admission. Those are choices an editor can inspect in a passage.

You can begin with a short file:

# Voice

## Diction

[Words and registers that fit; language to avoid.]

## Syntax and rhythm

[How sentences build and turn; punctuation preferences.]

## Examples

[A short passage that sounds right, with an explanation.]

[A rejected passage, with the specific problem identified.]

Ask the agent to infer possible patterns from a few pieces, then correct its reading. It may mistake the subject of one essay for a permanent interest, or elevate a repeated tic into a defining characteristic. You decide which patterns deserve an instruction.

Our AI Style Guides guide goes deeper into using examples and corrections to make your preferences usable.

STYLE.md defines the project

STYLE.md describes the project’s editorial standards: who the reader is, what the piece promises, what evidence it needs, and how you decide it’s ready.

For Working Overtime, a first-person experience needs to give readers something they can use or understand differently. That is an assignment standard.

Start here:

# Project style

## Purpose and reader

[Who this is for and what it should help them understand or do.]

## Argument and structure

[What a piece needs to establish; useful shapes for this format.]

## Evidence

[Source standards; how to distinguish experience from broader claims.]

## Publication requirements

[Checks, disclosures, and permissions required for this project.]

## Examples

[A successful piece and the editorial choices that make it work.]

Keep the full examples in examples/. Keep notes, sources, versions, and reviews together inside each piece’s folder. The plugin supplies general methods; these files tell the agent what those methods need to accomplish here.

Advanced: Multiple writing projects

If you maintain several bodies of work, each can have its own standards and examples. A personal column and a technical guide may need different registers, evidence, and structures. A shared voice file is useful for preferences that apply across your projects; a more specific project can have its own guidance. Add this layer when you have a reason to use it.

The skills

Start with the Scribe command

Describe the outcome you want and let cw-scribe choose a useful route. When you know the job, name the specialist: cw-interview for a live idea, cw-outline for structure, cw-draft for prose, or a focused reviewer for the uncertainty in front of you.

You can also ask for a combination. cw-panel gathers several perspectives; cw-debate lets reviewers respond to one another. Choose the lenses that would help you make a decision, then return to the draft.

The full skill inventory

These are the skills included in the public Compound Writing package. Each can be invoked on its own. The repository reference carries the current descriptions.

Set up, navigate, and save

cw-scribe: Choose the smallest useful workflow for starting, continuing, or improving a piece.
cw-setup-project: Create a self-contained writing home with voice, style, examples, and drafts.
cw-onboarding: Begin or refresh voice and style guides from conversation, examples, or existing context.
cw-save: Capture a confirmed preference, editorial lesson, or process improvement in the appropriate file.

Develop the idea

cw-brainstorm: Surface raw material and possible directions when you don’t have a specific idea yet.
cw-interview: Draw out your thinking about a live idea and organize what you say.
cw-thesis: Generate possible central claims for you to consider.
cw-promise: Generate ways to clarify what the reader will get from the piece.
cw-outline: Develop the material into a structure, from a broad sketch to a more detailed outline.
cw-hook: Generate opening options suited to the material.
cw-transition: Suggest ways to move between ideas or sections.
cw-analogy: Generate comparisons that help explain a concept.
cw-simplify: Rewrite complex text in plainer language.

Draft and revise

cw-draft: Turn notes, sources, an outline, or partial prose into a draft.
cw-bluf: Find the most important idea and assess whether the opening puts it in the right place.
cw-dev-edit: Review the argument, structure, stakes, evidence, and payoff.
cw-line-edit: Revise sentences for clarity, rhythm, diction, and economy while preserving meaning and voice.
cw-voice-check: Assess voice drift against the active writing context and offer a closer revision.
cw-ai-check: Find or remove AI residue, including unsupported additions and formulaic prose.
cw-tracks: Find the scaffolding and process narration left behind while the piece was taking shape.
cw-final-pass: Assess publication readiness and identify unresolved problems.

Test the argument and combine perspectives

cw-reader: Read as an intended reader encountering the piece for the first time.
cw-objections: Surface counterarguments and credible reader resistance.
cw-panel: Gather several reviewer perspectives and synthesize their agreement and disagreement.
cw-debate: Have reviewers respond to one another across rounds to work through their disagreements.
cw-emergent: Combine skills and available tools for a writing task that no single skill covers.

Add a named reviewer

cw-asshole: Apply a hostile, least-charitable read to claims, assumptions, and logic.
cw-hemingway: Challenge unnecessary words and demand economy.
cw-hitchcock: Examine suspense, tension, and what keeps the reader going.
cw-mom: Find where a supportive general reader may become confused or lose the thread.
cw-sedaris: Look for opportunities for humor, absurdity, and self-deprecation.
cw-sorkin: Examine pacing and momentum.
cw-vonnegut: Apply storytelling principles to character, wants, stakes, and purposeful sentences.

Run your first piece

Start with an idea, notes, an outline, or a draft that already has your attention. You’ll get more useful feedback when you have a real intention against which to judge it.

1. Install the plugin

The Compound Writing repository contains the plugin, its installation instructions, and the complete skill reference. You’ll need Claude Code or Codex with plugin support and access to the folder where you want to write.

In Claude Code, run these commands in the session, one at a time:

/plugin marketplace add EveryInc/compound-writing

/plugin install compound-writing@compound-writing

Start a new session, then select Scribe from the available skills. The commands follow Claude Code’s marketplace installation process.

In Codex, follow the repository’s Codex installation instructions to install the repository as a local plugin. Ask Codex to help with those instructions if you need it. Open a new task in your writing folder and confirm that Compound Writing’s Scribe skill is available before proceeding.

The skill names in this guide use the current cw- prefix: cw-scribe, cw-interview, and so on. You can select the skill in your app or name it in your request.

2. Give the agent the work you already have

Open your writing folder and make the current material available to the agent. If your draft is in a connected document, give it that document; otherwise, add a copy to the folder. Tell it who the reader is and what you want the piece to do.

For an existing draft:

Use Compound Writing’s scribe skill on this draft. It’s for [reader], and I want it to help them [purpose]. Read the draft and any existing voice, style, and source files. Identify the most useful next step and begin with a diagnosis. Bring a major change to the central argument back to me before rewriting it.

For a live idea:

Go into interview mode to help me develop this idea: [idea]. Ask about what happened, what I think it means, and what I still need to find out. Keep my answers separate from your suggestions. Don’t draft the piece yet.

Scribe can begin from useful material even if you haven’t built a voice guide. If you want to establish the writing home described above, ask:

Help me establish a writing home in [folder]. Use the Compound Writing setup and onboarding skills. Preserve anything already there. Help me create VOICE.md for how the prose sounds, STYLE.md for what the writing must do, an examples folder, and a drafts folder. Begin with the material I provide and ask about the gaps.

3. Inspect the result

Read what comes back against the job you asked it to do. Be specific when you disagree. “This doesn’t sound like me” is a beginning. “You cut the aside that explains why I was embarrassed” gives the agent a correction it can act on. If the proposed fix changes your claim, stop and work through that choice before generating more prose.

Your first useful session can end with a clearer premise, a better outline, or one revised section. Give yourself something small enough to inspect.

How to compound

Compounding starts when you notice something you want to carry into the next piece: a revision that made the prose sound more like you, a question that unlocked an idea, or a sequence of reviews that helped you finish. You can capture that lesson while it’s fresh or look back at the end of a session.

1. Notice what worked—or kept going wrong

Look at the decisions you made together. What did you keep correcting? Which suggestion did you accept, and why? What helped you get unstuck? Ask the agent to review the conversation and draft changes for possible patterns, then judge its suggestions against your own experience.

For example, suppose the agent repeatedly shortens your sentences by cutting the details that set up your jokes. You keep restoring them because the punchlines need details to land.

2. Turn the observation into a specific lesson

Explain what to do and why. “Keep my humor” leaves the agent guessing. A more useful instruction would be:

When tightening a sentence with a comic payoff, preserve the details that set up the joke. If those details need to be cut, rewrite the sentence so the payoff still makes sense.

Keep a short before-and-after example with an explanation of what changed. The example should illustrate the principle, so the agent can apply it to new material.

3. Decide where the lesson belongs

Ask whether the lesson describes your writing generally, this publication or project, or just this piece. Choosing a cooking analogy for one essay doesn’t mean every essay needs cooking metaphors. That choice can stay in the piece’s notes.

VOICE.md: How your sentences sound—rhythm, diction, humor, and sentence construction. The rule about preserving a joke’s setup belongs here.
STYLE.md: The project’s editorial standards—argument, evidence, structure, and what the reader should get from a piece
A workflow or review checklist: A useful sequence of steps or a recurring problem to check for
The piece’s notes: Decisions, exceptions, and open questions specific to the current draft

4. Save it where future sessions can find it

Use cw-save to add a confirmed lesson to the appropriate file in your writing home. It reads the existing guidance and adds or revises the relevant rule. If you’re asking it to infer a lesson, review the proposed wording before it becomes a standing instruction. Once you’ve agreed on the rule, you can say:

Use cw-save to save the rule we just agreed on in this project’s VOICE.md. Include a short example from this draft, check for overlapping guidance, and show me the exact edit and the file you updated.

Check that the file changed. The lesson needs to live in the context future sessions will read.

5. Try it on the next piece

Have the agent read the updated guidance when you start or resume work. When it edits, inspect whether the instruction helped: did it preserve the setup without treating every long sentence as sacred? Refine the rule if it’s too broad, and remove guidance that has stopped serving you.

You don’t need a new rule after every session. Save the lessons you expect to use again, and leave room for your practice to change.

Keep the guardrails on

Writing with AI still means taking responsibility for what you publish. Compound Writing gives you more help producing and reviewing a piece. Your judgment determines what earns a place in it.

Own the argument

An agent can suggest a thesis, challenge your reasoning, or offer an interpretation you hadn’t considered. Decide whether you actually agree. You should be able to explain and defend the published argument in your own words, including the parts the model helped develop.

Verify the facts

Check quotations, statistics, citations, and consequential claims against their original sources. Read enough surrounding context to know whether the source supports your interpretation. Keep your experience, a source’s findings, and the agent’s inferences distinct. An AI reviewer’s approval is advice, not verification.

Credit sources and be honest about the process

Preserve attribution when an agent summarizes or rewrites someone else’s work. Follow your publication’s or client’s rules on AI use and disclosure, and consider what readers need to know to assess the piece. Never present generated quotations, interviews, or observations as reporting you conducted.

Respect the reader

Do the work of selecting, checking, and shaping what the model produces before asking someone else to read it. Give readers the context and disclosure they need to judge your claims for themselves.

Starter materials

Build a writing practice of your own

“Practice” describes both a way of working and the repeated effort through which you develop it. A writing practice includes your methods for finding ideas, shaping arguments, and revising prose. It also involves trying those methods, noticing where they fall short, and getting better at deciding what a piece needs.

Compound Writing gives you a methodology to start from. The practice develops as you use it. Make the process your own by adapting the instructions, keeping the examples that teach you something, and revising the rules you’ve outgrown. The next piece will bring different problems. You’ll meet them with a clearer sense of how you write, where you want to go with an idea—and more ways to help you get there.

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.

🎧 How an Every Staff Writer Developed Compound Writing

Kaushik Viswanath / The Every Podcast — 2026-09-02 07:00:00 -0400

by Kaushik Viswanath

in The Every Podcast

Natalia Quintero (left) and Katie Parrott. Midjourney/Every illustration.

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.