Ryan Carson runs Untangle, a B2B SaaS platform for family law firms, solo. No co-founder, no engineers, no plans to hire. He built it after his own divorce, raised $2 million to fund it, and told Claire Vo on How I AI that at his peak he had as many as 15 concurrent Devin agents writing code, generating roughly 40 pull requests a day. Carson is a five-time founder. He previously built Treehouse into a company of about 110 people that taught roughly a million students to code.

Here’s the number that matters more than 15: $20,000. That’s what Carson spent on Devin in a single month running that setup, and he told Lenny’s Newsletter flat out that it wasn’t viable. He now targets something closer to $5,000 a month per “engineer equivalent” of real output. His own conclusion, echoed across two separate interviews: producing more AI output isn’t the goal. “There isn’t a magic wand,” he said. “You can build faster, but whether you’re building the right thing, and doing it better, is something else.”

Subscribe now

That’s the honest disqualifier. Your business doesn’t need 15 agents, and it definitely doesn’t need a $20,000 experiment to find out it doesn’t. But underneath the spend is a coordination habit that costs nothing and works at any scale, including yours at two or three agents.

The folder and the paper list

Carson doesn’t track his agents with a dashboard. He tracks them with a folder system and a physical paper list, a card-based practice called Ugmonk Analog. Work gets sorted into folders by priority as it comes in. The paper list holds only the two or three things that actually matter today, regardless of how many threads are running in the background.

The mechanism is simple and it’s the whole point: pin the threads that matter, ignore the rest until they finish, and check the pile on roughly a 25-minute cadence rather than constantly. Out of that day’s pull requests, by his own estimate, only a handful are the ones that actually matter. Everything else waits for its turn. He estimates making 10 to 20 real decisions before lunch, and the paper list is what tells him which 10 to 20 those are.

This is a progression rule, not a discipline flex. An athlete doesn’t add load and range at the same time, because then a bad session tells you nothing about which variable failed. Carson doesn’t let agent count and attention span move together either. He can run more threads only because the register that tells him what’s real never grows past what one glance at a card can hold.

What it unlocks for a founder who’s never run more than one agent

You don’t need 15 threads to have this problem. The moment you run a second background agent while a third is still finishing yesterday’s task, you already have Carson’s problem at a smaller scale: work happening that you can’t fully account for. The fix isn’t a bigger brain or a better model. It’s an external register that exists outside the agents themselves, so the system that tracks the work can’t be corrupted by the work.

Claude Code gives you the coordination layer Carson had to build himself. Run claude agents and you get Agent View, a single screen for everything running in the background: what’s active, what needs your input, what’s done. Inside a session, /tasks shows you what’s running right now before you decide to move on. And /background (or its shorthand /bg) pushes a session behind so you can start the next one without losing the first, each running in its own isolated worktree, surviving your laptop going to sleep.

That’s the execution layer. It still doesn’t replace the paper list. Agent View tells you what’s running. It doesn’t tell you which three things matter today, and that judgment call is exactly the part Carson refused to hand off to software. A folder structure plus a running list, even a literal notebook, is what keeps you honest about priority while the tool handles throughput.

I wrote about this same pattern from the other direction in “A $12 Purchase, Treated Like a Big Decision”: an external register (a QUEUE.md file, in that case) is what makes delegated work auditable, whether the stakes are twelve dollars or twenty thousand. And when I described my always-on agent Hermes breaking under load, the fallback that actually held wasn’t a smarter agent. It was plain notes in a document I controlled. Carson’s paper list is the same idea wearing a different jacket.

The founder decision

This costs you almost nothing to adopt and it costs you real work later if you skip it. A running doc, a card system, even a whiteboard: pick one before you’re running three agents at once, not after. The habit is: two or three items visible at all times, everything else in a folder until it earns a slot, and a fixed check-in cadence instead of watching every thread live.

This is a founder call, not something to delegate. The agents can execute. Deciding which three things are real today is the one job that stays yours, at 2 concurrent threads or at 15.

Subscribe now

Carson’s most concrete proof point for why this matters is a small automation he calls the Watchdog: an agent that runs every morning at 9am, reads everything paying customers did the day before, pulls errors from Sentry, and checks whether a recent pull request already fixed each top issue before he even sees it. It works because he trusts the register around it, not because the agent got smarter. That trust is buildable in an afternoon. The $20,000 spend isn’t required to get it. The index card is.

Want more like this? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

I fed Claude Cowork a big, messy reference document for an upcoming trip and asked it to turn that into a real itinerary. Two passes later I had one: the first pass got me 90% of the way there, the second added exact timing around reservations I’d already made. That’s the return I’m chasing every time I open Cowork. A few minutes of setup for work I didn’t have to do by hand.

Two days later, I was mid-workout when two real questions came up: could I catch a Serie A match while I’m in Spain? What were my medical care options while traveling? I pulled out my phone, opened Cowork, and expected to pick up exactly where the desktop session left off. Nothing. No sign the itinerary existed. No history, no context, just a blank slate on my phone next to a finished project on my laptop.

My first instinct was to blame the tool: Cowork mobile just doesn’t sync with desktop. I checked before taking that at face value. Turns out I was half right. The real explanation is more specific, and a lot more useful to know.

Subscribe now

What Anthropic actually shipped, and the boundary it left in place

Anthropic didn’t skip this. I’ve already covered Cowork’s earlier move off the desktop; this is the next step in that same expansion. Cowork expanded to web and mobile in beta on July 7, 2026, and the beta finished rolling out to every paid plan on August 18, three days before my gym moment. Their own announcement is direct about it: “your sessions and files go where you go, on any device.” That’s a real, shipped feature live on every paid plan, not a roadmap promise. If you’re tracking Anthropic’s release cadence, none of this is a surprise, it’s confirmation they’re closing the gap they said they would.

The part that doesn’t travel is documented in their own support pages, not a bug I stumbled into. Cowork runs two kinds of sessions. Cloud sessions live on Anthropic’s servers and sync everywhere, including while your laptop is closed. Local sessions are anything touching a file on your machine, working through your browser, or relying on local computer use, and those “work through the Claude Desktop app” only, meaning the desktop app has to be open on that specific computer for the session to reach those files at all.

I’d dragged a large document straight into desktop Cowork. I can’t confirm with certainty it lived only on my machine rather than a connected drive, but it’s very likely, and that’s exactly the gap Anthropic’s own documentation describes. A public GitHub feature request on this exact gap puts it more bluntly than I would: “a Cowork session is locked to the physical device where it was started.” The same thread notes that Dispatch, Anthropic’s phone-to-desktop tool, “is a remote control for a desktop-bound agent, not true device continuity.” Dispatch has its own dated reliability complaints too, including reports of it failing to reach a desktop that’s sitting right there, running.

The one decision that determines whether your session travels

The fix isn’t complicated, and it’s entirely in your hands. It isn’t which app you open on your phone. It’s where the source file lives before you start.

Drop your reference material into a cloud-connected folder (Google Drive, or whatever cloud storage your Cowork account is linked to) before you start the session, and it’s a cloud session: it syncs to your phone, your laptop, the web, wherever you check it next. Drag a local file straight into the desktop app instead, and you’ve built a local session, tied to that one machine, reachable only when the desktop app is open there.

Dispatch is a different tool solving a different problem: it lets your phone push a new task onto a desktop that’s already awake, not resume a conversation that already happened. Worth knowing the boundary before you’re mid-trip counting on it. ChatGPT already advertises a fix for this exact gap with its own cross-device handoff, so the industry is clearly racing to solve it. Cowork isn’t there yet for anything anchored to a local file, but it already is for anything anchored to a cloud folder.

The founder call

This is a decision you make once, at the start of a project, not something you delegate to an assistant or revisit mid-trip. Before you start any Cowork session you might need away from your desk, drop the source material into your connected cloud folder first. It costs you nothing extra: same drag-and-drop, different folder.

If you’ve already started a project on a local file, know what you’re carrying: that session stays parked at your desktop until you’re back at that machine with the app open. Don’t count on Dispatch to bail you out mid-trip. It’s a real tool for a real job, waking up a task on a computer that’s already on, but it isn’t a substitute for the session you actually want.

It’s the same as mapping your route before a run, not turn by turn once you’re already out. The decision that matters happens before you leave home.

Where this leaves you

The itinerary Cowork built me on desktop was genuinely good, 90% there in two passes, the kind of result that makes the tool worth having open every week. The gap I hit wasn’t Cowork failing at something it promised. It was one architecture choice I made without thinking about it: a local file instead of a cloud folder.

Now you know which one to make. Put your source documents in a connected folder before the next Cowork session you might need on your phone, and the work follows you out the door, into the gym, and onto the plane.

Subscribe now

Want more like this? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

I built a skill to have Claude act like a travel agent: sort through flights and housing options for a business trip so I don’t have to. It took about twenty minutes to build inside Claude Code. Then I asked it for real prices, and it handed me ranges. “Flights typically run $280 to $420.” “Hotels in that area average $150 to $220 a night.” Directionally fine. Not one of those numbers was a price I could actually pay.

A founder with no room to spare in her week doesn’t have time to double-check every AI output before she trusts it. If the wrong kind of answer looks exactly like the right kind, she’ll act on it. This is the story of finding that gap in my own workflow, and the one thing that closed it.

Subscribe now

Why the skill only got halfway there

I asked Claude why it was giving ranges instead of real listings. The answer was specific: the booking sites it needed to check are JavaScript-heavy. Prices load dynamically after the page renders, and Claude Code’s native tools have no way to open a page and watch it load. Without a real browser, Claude was reasoning about what prices on sites like this usually look like, not reading what a specific site was showing that day. It sounded like a fact. It was a guess.

The fix wasn’t a better prompt or a smarter skill. It was giving Claude a browser. I installed Claude for Chrome, Anthropic’s browser extension (available on Pro, Max, Team, and Enterprise plans, Chrome only), and reran the exact same skill with the exact same request. This time Claude actually opened the booking sites, waited for the JavaScript to render, and read what was really on the page.

The output changed completely. Instead of a range, I got three specific housing options, each optimized against the criteria I’d given the skill, each with a real, current price and a direct link to go book it. Same skill, same prompt. The only variable that changed was whether Claude could see the live page. That’s the whole story: the last 20% of an agent skill, the part that makes it trustworthy rather than merely plausible, is often a tools problem, not a reasoning problem.

The question to ask about any AI answer

Here’s the part worth keeping past the travel use case. Watch for answers that feel too smooth for something checkable: a price, a seat count, a specific date. Treat that smoothness as a signal, not a coincidence. The fix usually isn’t asking it to try harder or rewriting the prompt three more times. It’s asking whether the agent can actually see the thing it’s describing. Static reasoning and live data are different jobs, and no amount of prompting turns one into the other.

Boris Cherny, who built Claude Code, has run this same pattern further than I have. Per his own account, he pairs Claude for Chrome with Claude Cowork and a travel connector to have Claude book flights and hotels directly: 8 flights and 5 hotels in one pass, with the browser doing the driving while he worked on something else. That’s a heavier setup than mine (Cowork orchestrating the whole session, a structured connector supplying flight data, and the browser still doing the site-by-site navigation), but it’s the same underlying bet: an agent is only as good as what it can actually see or reach.

One distinction worth keeping straight: Anthropic separately ships structured travel connectors for Expedia, Booking.com, and lastminute.com, which pull data through an API rather than a browser. That’s the official, structured path Anthropic built for travel specifically. Claude for Chrome is the general-purpose tool I reached for because Claude Code alone had no eyes on the page, and it applies to anything else with a JS-heavy front end: pricing pages, dashboards, internal tools with no API to speak to.

What to expect if you install it

A few things worth knowing before you install it. It’s slower than doing the search yourself. Every click, read, and page load Claude performs is a tool call, so a lookup that takes you thirty seconds by hand can take Claude a couple of minutes, and it burns through your plan’s usage limits faster than ordinary chat does. Neither is a dealbreaker for an occasional task like mine; both matter if you plan to run it constantly.

Claude blocks itself from acting on banking, investment, and a short list of other sensitive site categories by design. Travel sites aren’t on that list. Separately, security researchers disclosed a flaw in 2026, nicknamed “ClaudeBleed”, where a malicious extension could hijack Claude for Chrome’s permissions. Anthropic patched the disclosed issue. The mitigation that matters most for you: turn off “Act without asking” in the extension’s settings. That forces Claude to stop and get your confirmation before anything consequential happens, which is also, not coincidentally, exactly how I used it. Claude handed me links to review and buy. It never bought anything itself.

This week: if you’re on a Pro plan or higher, install Claude for Chrome and try it on one skill that depends on live data instead of static reasoning: a price check, an availability lookup, anything you already ask Claude to do that involves a page that changes. Keep “Act without asking” off. Let it hand you the link instead of the receipt.

The actual lesson

The skill wasn’t hard to build. The real work was catching that its first answer was a guess, not a fact, and knowing which tool would fix it. That’s not a new idea for anyone who reads this publication regularly: an agent is only as good as what you let it see. This is just the version of it that showed up in my own workflow.

Subscribe now

Want more like this? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

A routine cloud migration turned into a hiring audit I didn’t mean to run. Here’s the cheap test to run before you hire anyone.

I wasn’t trying to build a hiring audit. I was trying to get my AI operations off my laptop.

Everything I run day to day, the content pipeline, the always-on automations, the whole stack, lived on one machine: mine. That’s fine until the laptop sleeps, needs a reboot, or I’m just not near it. So I stood up a copy of the same systems on a cloud server, expecting a few hours of setup and one straightforward win: uptime that doesn’t depend on my laptop lid staying open.

What I actually got was two things quietly breaking in ways that never threw an error, and a more useful realization sitting underneath both of them: everything that broke moving my systems from one machine to a second machine is exactly what breaks moving them from me to a second person.

Subscribe now

What actually broke, in one paragraph

Two things failed on the cloud server that had worked fine on my laptop for months, and neither one raised an alarm. A publishing script read text out of a markdown-parsing library and pushed it live; on the cloud server, that text started coming through with stray escaped-character artifacts, because the two machines had quietly picked up different versions of the same library months apart, with nothing pinning which one either used. A database migration relied on a config line pointing at “the latest version” of a database engine; my laptop had locked onto one actual version five months earlier, the cloud server pulled the identical tag fresh on migration day and landed on a different one, and a real backup restore failed outright because the two versions no longer agreed on internal structure.

Neither was a coding mistake. Both were assumptions nobody had written down: this text is always safe, this version tag always means the same thing. True on the machine that had been running quietly for months. False the moment a second machine touched the same code. Every fix went back into the source, not a patch on the machine where it happened to surface, because a patch fixes one machine and a source fix fixes the next one too. It’s the same blind spot I went looking for on purpose when I tested what’s actually load-bearing in my own CLAUDE.md.

The same shape kept showing up

Once I started actually running the full pipeline somewhere other than my laptop, instead of assuming it would work because it always had, I found more of the same problem, none of it in a library this time:

• Automation that assumed it always lived at one specific file location, and silently failed the moment it didn’t.

• A tool my process depended on that simply doesn’t exist outside my laptop’s operating system.

• A Claude Code quality check that pointed at one machine’s file layout and quietly stopped checking anything at all anywhere else, without ever saying so.

• A file-exclusion rule that had been silently swallowing brand assets nobody noticed were missing.

• Credentials that had only ever lived in one file on one machine, with no plan for how a second machine, or a second person, would ever get a working copy.

The Claude Code check is part of the same gated pipeline I wrote about in Graph Engineering: a graph only works if the gates actually gate. None of these threw an error either. Every one of them worked fine, silently, right up until something other than the original setup touched it.

What a second machine previews for you

I wasn’t testing for a new hire. I was testing for uptime. But every gap above is the identical shape of what happens the day someone besides you touches your systems, a contractor, a new team member, anyone who didn’t build the thing and doesn’t carry the assumptions you never wrote down.

A second environment and a second person fail for the exact same reason: an assumption that only ever had to be true once, on one machine, in one person’s head. You don’t need to hire anyone to find out where that’s going to hurt. You need a second environment.

The audit: run this before you write a job posting

Stand up a copy of your stack somewhere you have no muscle memory: a cheap cloud server, a second laptop, even a fresh browser profile if most of what you run is web-based. Then try to get it working using only what’s written down, not what’s in your head.

Five things worth checking while you’re there:

• Can it start from nothing? Reinstall or reclone cold. Any file path, config value, or piece of software that only exists on your machine, undocumented, is the first thing a new hire hits.

• Do your checks actually run elsewhere? A quality gate, lint, or automated check that silently passes because it can’t find what it’s looking for is worse than no check.

• Is a credential handoff possible? A secret that lives in one file on one machine with no documented way to get a second person a working copy isn’t a credentials system, it’s a single point of failure.

• Are your assets actually in the repo? A broad exclusion rule can quietly drop files nobody notices are gone until something tries to render them.

• Does anything point at “whatever’s current”? A dependency or config aimed at a moving target instead of a pinned version will eventually hand two people two different pieces of software running the identical line of config.

Whatever the second environment forces you to write down, keep it. A setup doc, a credentials handoff note, a pinned-versions list: that isn’t debugging cleanup, that’s the onboarding doc your first real hire needs on day one, written before you needed one.

This costs a weekend and a cheap server bill, spent on your own time, before anyone’s job depends on the outcome. Skipping it costs a new hire’s first week and their confidence in you, discovered on their clock instead of yours. Run it yourself, before the job posting goes up. You’re the only one who’s had months to build up the assumptions your systems are running on, so you’re the only one who can go find them.

I still don’t have a second person running any of this. But I know, concretely, more about what would break on their first day than I did before I ran this migration, and it cost me a cloud server bill and a weekend, not somebody’s actual first week.

Subscribe now

Want more like this? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

On the morning of August 6, four research requests landed in my queue within about four minutes of each other. Three were minor purchase decisions for my car: a console lockbox, a trunk privacy cover, and a $12.66 cargo organizer, the kind you’d normally decide on gut feel or skip investigating entirely because it’s not worth the attention. The fourth was whether to install GBrain, Garry Tan’s new memory layer for AI agents, alongside Hermes, the always-on agent framework I already run.

All four went through the identical pipeline: queued, delegated to a cheap subagent, researched, sourced, reviewed, delivered, and actioned by me. The cheapest of those decisions and the security-relevant architecture call got the same rigor. That’s not an accident of good discipline. It’s what happens when research stops being a decision about whether something is “worth” investigating and becomes infrastructure that runs regardless.

Subscribe now

The queue that doesn’t discriminate on stakes

Here’s the setup, and it’s simpler than it sounds. In my own Claude Code workspace, there’s a file called QUEUE.md. Every research request gets one entry: a question, why it matters (what decision it feeds), explicit success criteria as a checklist, and a status: Queued, In progress, Delivered, or Actioned.

The delegate that does the actual work is a named subagent called researcher. It runs on Haiku, not the expensive model I’m actually talking to, and its tool access is deliberately narrow: Read, Write, Glob, Grep, WebSearch, WebFetch. No write access outside its own findings file. No ability to send a message, make a purchase, or take any irreversible action. Its system prompt says the division of labor outright: “You do NOT make final decisions. You gather and organize so CJ and the main model can decide.”

Before a finding ever reaches me, it gets a second look from the expensive model, the same one I’m actually talking to in the main session. That review is cheap relative to redoing the research (it’s reading and judging, not searching and writing), and it’s the difference between “a cheap model said so” and something I can act on without re-verifying it myself. Once a finding clears that review, it lands as a dated markdown file in a findings folder, sourced and checklist-verified.

That constraint is the whole design. Research is high-volume and low-judgment: search, read, extract, summarize, cite. It doesn’t need the expensive model’s context window or its attention. What it needs is a cheap, fast, tool-limited worker that can run asynchronously while the main conversation keeps doing what actually requires judgment, which is scoping the right question up front and deciding what to do with the answer.

That’s the part most founders skip. Most people treat “research” as something they either do themselves, in the moment, or don’t do at all, because spinning up a proper investigation feels like it costs the same expensive attention as everything else on the to-do list. A queue plus a cheap delegate removes that false choice. The requests don’t have to be worked the moment they’re captured. They sit until there’s leftover token budget, and the pipeline processes them at identical rigor whether the stakes are a minor purchase or an architecture decision, because the pipeline was never told to weigh stakes in the first place.

What the GBrain evaluation actually found

The fourth request that morning asked the researcher to evaluate GBrain, Garry Tan’s open-source memory layer for AI agents, as a possible addition alongside Hermes, the always-on agent framework I run (confirmed to be NousResearch’s hermes-agent). The finding: GBrain isn’t a runtime at all. It’s a knowledge layer that sits on top of one, with no messaging or action-taking ability of its own. Hermes, meanwhile, carries a running list of publicly disclosed CVEs (Common Vulnerabilities and Exposures, the industry’s public catalog of known security flaws), several of which security researchers classify as architectural rather than patchable bugs.

Put those two facts together and the call wasn’t “reject GBrain.” It was “pause the whole installation,” because the actual exposure sat underneath the thing I was evaluating, not inside it. That’s a distinction I’d likely have gotten wrong on instinct alone, and it came from a request that got the exact same rigor as the other three in that batch.

An asynchronous cousin of a familiar pattern

If this setup sounds familiar, it should. Anthropic’s own engineering team documented something structurally similar in “How we built our multi-agent research system”: a lead orchestrator agent plans an approach and spins up several parallel subagents, each with its own context window, to do the legwork before returning condensed findings to the orchestrator. Same core idea: keep the reasoning-heavy model focused on scoping and deciding, let cheaper models do the volume work.

The difference is timing and control. Anthropic’s orchestrator-worker pattern is a live, in-session burst that converges within one interaction. My queue is deliberately decoupled in time. A request can sit as “Queued” for hours or days until there’s spare attention to work it, which is the entire point of treating this as a way to spend a session’s leftover budget rather than a real-time production step. And it carries a lifecycle state Anthropic’s system doesn’t need: Actioned. The delegate never gets to decide its own finding is sufficient. A second, more expensive model reviews the work before it’s ever marked delivered, and only I get to close the loop by marking it actioned.

Subscribe now

The actual takeaway

The pattern here isn’t “hire a cheap AI to do research.” Every founder using Claude Code already has that capability sitting unused. The pattern is building the queue: a durable, auditable file where questions get captured with real success criteria the moment you think of them, decoupled from whether you have the bandwidth to answer them right now. Once that queue exists, a cheap subagent can work it continuously, and the evidentiary bar doesn’t have to move based on how big the decision feels in the moment.

That’s the real unlock. Not that AI can research a trivial purchase. It’s that once research stops competing with your expensive model’s attention, you stop being the bottleneck that decides which questions are “worth” answering properly.

Want more like this? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

Days after Claude Opus 5 shipped on July 24, Boris Cherny, creator and head of Claude Code at Anthropic, sat down at Y Combinator’s Startup School and said his team had deleted 80% of Claude Code’s system prompt, the standing instructions loaded into every session before a user types a word. That’s Anthropic’s version of your CLAUDE.md. His reason wasn’t cost. “A lot of the stuff in the system prompt was correcting for these behaviors that the model should have known, but it didn’t. Now, Opus 5 just does it.”

Then he gave founders the version that applies to you: “For people that aren’t building agentic products, but you’re using Claude Code, every 6 months delete your Claude MD. Delete your skills. Delete your hooks. See what the model does and it might surprise you.”

That is the treatment for a disease I ran head-on into with Hermes, the Nous Research agent that markets itself as “the only agent with a built-in learning loop.” When I dissected it, I found roughly twenty accreted “pitfall” rules circling a single unfixed bug, two of them byte-for-byte identical.

The rule I took away: self-improving memory needs garbage collection. Lessons that only accumulate are technical debt living in the context window, taxing every future turn. Cherny’s talk is the same thesis, with Anthropic’s own production system prompt as the evidence.

Subscribe now

Every rule in your CLAUDE.md is a bet that the model is still weak there

You did not write “always run the tests before you commit” because it is eternally true. You wrote it because a model in March ignored the tests. The rule is a wager on a specific weakness at a specific moment.

Model upgrades settle those wagers silently. Nobody emails you when Opus 5 starts doing unprompted what your line 47 was compensating for. The rule stays and competes for attention with the instructions that still matter. My own CLAUDE.md runs about 1,600 tokens before I type a single word, and every one of them is competing with the actual task. Cherny has a name for this: “hobbling.” His words: “the model is able to do all sorts of things with today’s models that we have not yet realized... often what happens is the product gets in the way.” Your instruction layer is a product wrapped around a frontier model. It can hobble too.

Anthropic’s own remedy is mechanical. “You delete the entire system prompt and then bring it back line by line to figure out the impact of each individual line.” They do it on a cadence: “Every time that a new model comes out, we delete a bunch of the system prompt.” The result was not just cheaper. Per Cherny, “the model is actually a little bit more intelligent without these prompts.” Note his calibration, not the headlines that inflated it.

Cole Medin’s correction: ablation is an eval, not a deletion

Cole Medin ran the experiment before writing about it, on Archon, his own 23,000-star open-source project. His framing is the guardrail founders need: “He’s right, but only to an extent... Some of your AI layer genuinely has expired and you should be aggressive about cutting it. Some of it has not, and deleting that part costs you in ways that are surprisingly hard to notice.”

His headline finding, straight off his own chapter list: architecture held up, conventions broke. And he shipped the procedure as a skill, ablate-ai-layer, in github.com/coleam00/skills, MIT licensed and agent-agnostic across CLAUDE.md, AGENTS.md, .cursor/rules and the rest. Install it in Claude Code with two commands:

/plugin marketplace add coleam00/skills
/plugin install skills@cole-medin

The skill’s discipline is the valuable part. Test it against something real, not a typo fix, because a trivial task tells you nothing. Run it more than once, because a stripped rule rarely fails in an obvious way.

Then read the result plainly. A rule that only holds up when it’s loaded is load-bearing: keep it. A rule the model follows either way is something the model already does on its own: cut it. A rule the model still breaks even with it loaded doesn’t need another sentence in your CLAUDE.md, it needs a hook or a test. And if a rule’s situation never came up in your test, that isn’t proof it’s safe to cut. It just wasn’t tested.

Medin also quietly corrects Cherny on scope. His default strips only the always-loaded set, because skills, subagents and path-scoped rules cost nothing until they fire, and hooks and permissions run as code and spend no attention.

What broke when I stripped my own repo

I ran it on this publication’s repo: CLAUDE.md plus four always-loaded rules files, deleted. The test task was generating a full 14-day social campaign for an already-published article, then comparing the result against the committed campaign we actually shipped.

I only got one clean run before the session crashed, so read what follows as one person’s experience, not a study. The pattern of what broke is still worth your attention. The number of runs isn’t.

The shape is the useful part. Most of a 304-line format spec came back unaided: the four canonical file names, the exact post header format, code-block wrapping, the day math, all four posting-time defaults, every character limit, and the no-email-addresses policy. The model did not need to be told.

What did not survive clustered into exactly three kinds of rule.

Local business facts the model cannot infer. My repo forbids publishing on Tuesdays because that is a sister brand’s day. Stripped, the model scheduled three Tuesday posts. Nothing in any world model could have supplied that.

Channel economics. “Personal LinkedIn is CJ’s highest-signal channel, every post must earn its slot” is a scarcity judgment, not a format fact. Without it, the model was generous by default and produced three personal posts instead of one.

Machine-readable contracts. Our character-count annotations get checked automatically by a script downstream, in an exact format. Stripped, the model produced richer, more informative annotations that would have broken that check. Better writing, broken pipeline.

One more finding cut against the rules layer rather than for it. The stripped run beat our committed baseline on two spec requirements, meaning those rules were not being fully honored even when they were present. Instruction bloat does not just cost attention. It hides non-compliance.

The test to apply

Line those three up and a pattern falls out. The rules that survive deletion are the ones encoding things the model has no way to know: your business constraints, your economics, your machine-readable contracts with downstream systems. The rules that die are the ones restating good practice the model already has. Cut those first.

And check your enforcement layer while you are in there. Writing this piece, I found my own .claude/settings.json carrying a permission allowlist for four Feb26-* article folders that never existed anywhere in the tree. I deleted it on the spot. Accretion is not just a prose problem.

Put it on the calendar. Every six months, or every time a frontier model ships, delete the layer and make it earn its way back one line at a time. I’ve started defaulting to whatever enforces it cheapest: a test if a test will catch it, a hook if it has to run automatically, an always-loaded line only when nothing else will do. That line is the expensive option. Treat it like one.

Want more like this? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

Subscribe now

Greg Isenberg published a video on August 3 called “Why Graph Engineering will 10x your Claude/Codex.” In it, he argues the AI workflow discourse has moved past prompt engineering (asking better questions) and context engineering (feeding the model better information) into something new: designing the work itself as a managed structure instead of one sprawling conversation. He calls it graph engineering, defines it as jobs connected by arrows with shared state moving between them, and walks through three levels of implementation, from sketching the workflow on a whiteboard to wiring up real orchestration tools like LangGraph.

It’s a useful framework, and Isenberg names Claude Code and Codex directly as the tools that make his middle implementation level (each step in the workflow writing its own file, leaving a paper trail) practical for solo builders and small teams. If you run either tool for real work, the video is worth your 25 minutes.

But here’s what founders should know before they treat this as a new thing to go learn: it isn’t new, and Isenberg didn’t coin it. That matters, because the accurate version of this story is more useful to you than the viral one.

Subscribe now

The term is two weeks older than the video

On July 18, Peter Steinberger, founder of PSPDFKit and creator of the open-source agent project OpenClaw, posted a one-line question on X: “Are we still talking loops or did we shift to graphs yet?” It reached roughly 2.9 million views and set off a wave of definitions and hot takes across the AI builder community. That’s the moment “graph engineering” crystallized as a term, continuing a naming lineage the builder crowd has been iterating through all year: prompt engineering, context engineering, harness engineering, loop engineering, graph engineering.

LangChain, the company behind the LangGraph orchestration framework Isenberg cites as his most advanced implementation tier, published its own blog post on this four days after Steinberger’s tweet, titled “3 Years of Graph Engineering with LangGraph.” Their line on it: representing agentic systems as graphs “isn’t new, we’ve been doing it for three years.” A separate piece from AI Builder Club made the same point specifically about Claude Code, arguing that Anthropic had already shipped the underlying pattern under a plainer name in its own “Building Effective Agents” guidance. Graph engineering is the label. The mechanism predates it.

So Isenberg’s video isn’t the origin of this idea. It’s a translation, moving a term that had been circulating hard among AI builders for two weeks into a format a much wider startup audience could absorb in one sitting. That’s not a knock on the video. It’s exactly the bridge move worth naming rather than hiding, and it’s the same move I try to make for you every week: cutting-edge builder discourse, translated into something you can act on without reading five Medium posts and a LangChain changelog first.

I already run this. So do you, probably, just not formalized

Here’s the part that matters most. This publication runs on exactly the structure Isenberg is describing, and I built it before “graph engineering” had a name.

My Claude Code setup breaks a full content pipeline (research, draft, QA, visual design, social campaign) into separate, specialized agents. Each one has one job. The research agent only researches and writes a brief. The drafting agent only reads that brief and writes a draft. It never touches social copy. The QA agent only fixes and reports. Nobody’s job bleeds into anybody else’s.

Between those agents sits a shared state file that tracks exactly what Isenberg means by “what does the system know so far”: which phase we’re in, which phases are done, where each agent’s output file lives, and a running log of every action taken. Every agent reads that state before it starts and updates it before it hands off. That’s the arrows connecting the jobs.

And between the major phases, I sit as a human-in-the-loop review gate. The system does not proceed from draft to QA, or from QA to publication, without my explicit approval. Nothing auto-advances across those checkpoints. That’s Isenberg’s “checker review, human approval” pattern, running as a hard rule rather than a suggestion.

Notice what this setup does not include: no LangGraph, no AutoGen, no workflow automation platform. It’s Claude Code, a folder structure, some markdown files defining each agent’s job, and a JSON file tracking state. That’s most of Isenberg’s Level 2 (file-per-step, reviewable paper trail) and pieces of Level 3 (explicit state schema, gated transitions), without adopting new tooling.

What to actually do with this

You are very likely already running an informal version of this. Maybe it’s a Zapier chain that moves a lead through three tools. Maybe it’s a set of saved prompts you paste into Claude Code in sequence for a recurring task. Maybe it’s a Slack workflow where you tag a teammate at each stage. All of those already have jobs, arrows, and something resembling shared state. What they’re usually missing is the naming and the discipline.

Three moves, in order of effort:

First, name your steps. Write down, in one line each, what happens at every stage of whatever repeatable AI-assisted task you’re running today. If you can’t name the steps, you don’t have a workflow yet, you have a habit.

Second, make each step write something down. A file, a doc, a ticket, anything durable. This is Isenberg’s Level 2, and it’s the highest-leverage move here: a paper trail you can review, compare, and reuse beats a chat log you’ll never scroll back through.

Third, put a human gate where a mistake would actually cost you something. Not everywhere. Just before the steps that are expensive to undo, like publishing, sending, or spending.

None of this requires you to learn LangGraph this week. It requires you to stop treating your AI work as one long conversation and start treating it as a system with named parts. The vocabulary just caught up to what disciplined builders were already doing. Now it has a name you can use when you explain it to your team.

Subscribe now

Want more like this? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

In May 2026, the team behind Bun, a widely used JavaScript developer tool, rewrote 535,496 lines of code in 11 days. Sixty-four Claude instances ran simultaneously. The bill came to roughly $165,000. Every test passed across every major platform. Three engineers doing this by hand would have needed about a year.

That is the headline number. Gergely Orosz (who publishes The Pragmatic Engineer and spent time inside Anthropic’s engineering org this summer) surfaced the more useful one.

Subscribe now

The Ratio Nobody Is Measuring

Orosz clocked the Bun rewrite at roughly 85% verification, testing, and fixing: about 15% actual implementation. That ratio comes from Orosz’s analysis of the Bun case study, not from an Anthropic internal data release. But the pattern it describes has corroboration from inside Anthropic. Thariq Shihipar, the engineering lead for Claude Code at Anthropic, is quoted in Orosz’s July 28 piece: “Few tokens are spent on actual implementation. Most are spent on discovery of unknowns, prototyping, mocking, and then in verification and testing.”

Most of the work in an AI-assisted coding workflow is not writing code. It is catching what the code got wrong.

This is not news to anyone running Claude Code at real throughput. The generation step is fast and keeps getting faster. The verification step does not compress the same way, because it is asking a different question: not “can we produce this?” but “is this actually correct?” Those are different cognitive tasks, and only the second one has a hard floor.

A 2026 survey of developers found that trust in AI-generated code fell 6% in a single quarter, even as AI now writes more than half of all code being shipped. More AI code, less confidence in it. The gap is widening.

Teams that treat AI coding as a generation problem (how do we get more output, faster?) are measuring the wrong thing. The metric that predicts quality over time is the verification ratio: of all the time your team spends on AI-assisted coding, what fraction goes into reading, testing, interrogating, and catching what came back wrong?

If you cannot answer that question about your own workflow, the answer is probably “not enough.”

Three Practices Orosz Documented That Transfer Directly

Orosz’s July 28 article covers practices inside Anthropic that are worth reading as a small-team playbook. The claims below come from the paywalled portion of his reporting: his observations, not Anthropic’s published policy. Treat them as strong directional signals. The underlying logic holds regardless of whether Anthropic enforces them precisely this way.

1. Team cap at two engineers per project. Orosz reports that Anthropic limits project teams to a maximum of two engineers. The logic is not about headcount savings: it is about review bandwidth. When Claude Code is doing a substantial portion of implementation, the human constraint on a project is not generation capacity; it is the ability to actually understand and verify what was generated. Two people can maintain shared context over a codebase. Three or four introduces coordination overhead that degrades verification quality. For a two-or-three person founding team, this is already your default. The insight is that Anthropic treats the two-engineer cap as intentional design, not a staffing constraint to grow past.

2. Product requirements before code, no exceptions. Orosz reports a requirement for a Product Requirements Document before significant work begins. This is not a waterfall planning relic: it is scope enforcement before any code generation starts. The failure mode in AI-assisted development is predictable: you give Claude Code a vague objective, it generates plausibly correct output in the direction of that objective, and you spend the next several hours debugging something that was technically responsive to your prompt but wrong for your actual requirements. Write down what you’re building before you start. One page: what does done look like? Skipping it is tempting because generation starts so fast. You end up with code that technically did what you asked but not what you actually needed.

3. Auto-reject without tests. Pull requests without tests get rejected automatically, Orosz reports. This is the structural enforcement of the 85/15 principle. To merge, you demonstrate that you verified. There is no exception path for moving fast. The Bun rewrite survived a pointed public challenge because of exactly this discipline: when Andrew Kelley, the creator of the Zig language, called Bun’s rewrite “unreviewed slop” in July 2026, Bun’s entire defense was its test suite. A 100% pass rate across all six platform targets, pre-merge, answered the criticism. Without that coverage, the criticism would have been unanswerable.

The Operational Shift

Fiona Fung, Anthropic’s Director of Engineering for Claude Code and Claude Cowork, described the org’s approach in a June 2026 post on the Anthropic blog: just-in-time planning instead of six-month roadmaps, engineers shipping real code in their first week, and Claude-assisted commits as the default across the engineering org. Orosz separately reported that 80% or more of all code deployed at Anthropic is written by Claude Code. These are deliberate norms, not emergent behaviors. Anthropic built the discipline explicitly.

For a two-person founding team, the same intentionality is the competitive advantage. The teams that scale cleanly are not the ones that generate more code faster. They are the ones that verify more carefully against a clear specification, with enough shared context to catch what the generation got wrong before it reaches production.

The protocol is not complex: one PRD before you start, one test requirement before you merge, one human reviewer per change. That covers the three practices Orosz documented. The math works at two people. It starts to break down as you add more.

You do not need Anthropic’s infrastructure to run this. You need the discipline to treat verification as the work, not the check at the end of the work.

Subscribe now

Want more like this? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

I was standing in a room full of half-packed boxes, phone in hand, trying to log that kitchen box number seven was sealed. My agent would not record it.

For weeks, the workflow had been genuinely good. Hermes named and numbered every box, tracked where I was in the sequence per category (multiple kitchen boxes, multiple art boxes, several for the office), and kept the whole thing straight over Telegram while I did the physical work. That tracking was the entire point. Then, at the height of the move, days of packing and hauling in a row, it started to freeze, go non-responsive, or return a troubleshooting message about how it could not record even a minor update.

I complained to it. Repeatedly. I asked it to look at itself and fix the problem. It insisted nothing was wrong. So I fell back to plain notes in a document and lost the automated box-naming and sequence-tracking that made the thing worth running at all.

Subscribe now

The tool and the promise

The agent is Hermes, built by Nous Research. If you have read my earlier field reports, you know it well. Hermes bills itself as “the only agent with a built-in learning loop,” one that “creates skills from experience, improves them during use,” and builds a deepening model of who you are across sessions. The GitHub repo tagline is “the agent that grows with you.”

That loop is genuinely novel in an open-source agent at this scale, and I have said so. It is also the exact mechanism that broke. In “The Agent That Learns From You”, I flagged the honest gap up front: Hermes evaluates its own success, and it almost always concludes it succeeded. I wrote that for anything high-stakes, this is the thing to watch. The move inventory was the highest-stakes task I had ever put on it. This is that case, live. Consider it chapter two.

None of this surprised me. In “I Used Hermes Every Day for 2 Weeks”, the through-line was that the learning loop is only as good as the feedback signal. This is simply a third place that signal breaks, and the first one I caught down at the primitive level.

What Claude Code found

I ran two rounds of Claude Code to diagnose it. The second round produced the root cause. The learning loop had been doing exactly what it advertised: learning. Every time a write failed, it appended another “pitfall” rule to the skill. It had accreted about twenty of them, including two that were byte-for-byte identical, all circling the same unfixed problem.

Not one of those rules questioned the premise. The agent kept optimizing the symptom (”the patch failed, add a rule about patching”) and never once asked the actual question: should it be using patch for this at all? A learning loop without root-cause reasoning only ever ADDS. It never REFACTORS. So instruction debt compounds, turn after turn, until behavior degrades.

It got worse than bloat. The failed patch retries had corrupted the data itself, injecting stray pipe characters and even leaking read_file line numbers into the inventory. The agent was editing its own long-lived memory with a tool that, on failure, left partial garbage behind instead of failing cleanly. It leaned on the model to be careful rather than making the persistence layer safe by construction.

The failure was invisible until it was not. It worked for weeks, quietly accruing corruption and instruction bloat, and then fell over during the actual move, at the exact moment I needed it. Quiet degradation of a self-improving system is the whole story here.

The one-line fix

The fix was not a better prompt. It was not a bigger model. It was choosing a different tool.

patch applies a change by finding and matching surrounding text inside the current file. It is fuzzy (it relies on string-matching), stateful (it depends on exactly what the file contains right now), and order-dependent (earlier edits change what later anchors match against). Point that at repetitive, growing, structured data and the anchors start colliding. The match goes ambiguous. Retries make it worse.

write_file writes the whole intended contents in one shot. It is atomic (it succeeds wholly or not at all), idempotent (run it again and you get the same result regardless of prior state), and needs no anchors to find its place. Same model, same data, same task. One tool corrupts itself over time. The other does not. The fix lived in the architecture, not the intelligence.

Two things in Nous Research’s favor

Two things in Hermes’s favor before the takeaways. First, patch failing on ambiguous anchors was correct fail-safe behavior. A tool that refuses to guess when a match is ambiguous is doing its job. The bug was using that tool for this job, not the tool’s caution.

Second, the observability was genuinely strong. The only reason Claude Code untangled this in a single pass, separating “laptop asleep” from “skill corrupting data” from “gateway down,” was that the logs, the pmset history, and the gateway state were all there to read. Good telemetry is what made a quiet, compounding failure debuggable at all. Nous Research earned that credit.

Subscribe now

Five rules I am taking with me

1. Do not use fuzzy text-matching as a database. Repetitive, growing structured data plus LLM string-matching guarantees anchor collisions. Use a keyed store, or at minimum atomic whole-file rewrites.

2. The primitive is an architecture decision, not an implementation detail. Which low-level tool an agent uses to persist state decides whether it can corrupt itself. That choice belongs to whoever designs the stack, not buried in a config.

3. Agents should fail loudly, not creatively. When its tool was blocked, this one improvised toward writing code to bypass the tool. Guardrails should push an agent to stop and surface the problem, not route around its own safety.

4. Self-improving memory needs garbage collection. Lessons that only accumulate are technical debt living in the context window, taxing every future turn. A loop that adds but never prunes compounds until behavior rots.

5. Human-in-the-loop does not compose with unattended channels. A consent-gated fallback that, in my setup, timed out at sixty seconds is reasonable when a human is watching. Over Telegram, while I was carrying boxes, it became a silent hang with no path to succeed. Design consent for the latency of the channel it runs on.

I shipped the write_file switch and I do not yet know how well it holds up. That honesty is the point. The category is still right: self-improving agents are where this is going, and I am still betting on it. But a learning loop is only as good as the primitive underneath it, and that is a choice you make on purpose, before the boxes pile up.

Want more like this? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

In July 2026, Alex Lieberman posted on X: “I built a content machine. It turned me into a one-person media company, has driven tens of millions in pipeline for @tenex_labs, and is allergic to AI-slop.”

Lieberman sold Morning Brew to Business Insider for roughly $75 million in 2020. He knows content at scale. His current company, Tenex Labs, is an applied AI consultancy, and the content operation powering it is a six-step Claude workflow he detailed on the "How I AI" podcast (Lenny's Newsletter network, July 20, 2026), later documented by ChatPRD. The workflow is specific, on the record, and replicable.

Here is every step.

Subscribe now

The 6-Step Claude Workflow

Step 1: The Oracle

The Oracle eliminates blank-page friction before it starts. Connected via API to Lieberman’s Slack, Notion, Gmail, Linear, and social feeds (X and LinkedIn), it scans seven days of internal and external signals each day and surfaces 15 ranked content ideas. Unused ideas land in a Notion database called “The Vault.”

The founder never decides what to write about from scratch. The system brings options. Decision fatigue is removed from the creation loop entirely.

Step 2: The Interview Panel

Six AI interviewer personas (Tim Ferriss, Joe Rogan, Barbara Walters, Howard Stern, Michael Barbaro, and Larry King) interview Lieberman on the selected idea. He responds via voice-to-text using Wispr Flow. That transcript becomes the raw material for the draft.

Lieberman’s take on AI slop is direct: “AI slop is hilariously people just pointing the finger at themselves and saying, ‘I’m not intelligent enough.’” His argument is that slop is a failure of the interview step, not the drafting step. Generic output starts with generic input. The panel forces real opinions before Claude writes a single word.

Step 3: Voice Codification

Three Markdown files define who Lieberman is as a writer:

• style-guide.md captures identity and role

• voice-guide.md analyzes top-performing posts and codifies hook formulas and language patterns, including what he calls “self-deprecating confidence”

• content-lessons.md logs past AI mistakes to prevent repetition

The core instruction given to Claude at this step: “Write like you’re texting a friend.”

These files are not prompts. They are persistent context. Claude does not receive a new style brief on each draft. The voice is already encoded.

Step 4: Drafting

Claude generates the draft calibrated to the voice files. No additional tooling at this step. Output quality is a function of the interview transcript and the depth of the voice files. The work is already done before the draft begins.

Step 5: The Writer’s Council

Four scoring personas evaluate the draft: David Perell, Sean Puri, Morgan Housel, and an “AI slop allergist” character. Each scores the draft 1 to 10. If the aggregate score falls below 9, a revision loop triggers automatically and runs until the threshold is met or Lieberman intervenes manually.

This is a quality gate with teeth. The draft cannot exit this step below standard.

Step 6: The Lessons Loop

After publication, the system runs a diff between Claude’s final draft and the version Lieberman actually published. It extracts generalizable lessons, requests permission to append them to content-lessons.md, and the next draft benefits from what the previous one revealed.

Repurposing follows Gary Vaynerchuk’s content pyramid model. The published piece becomes tweets, LinkedIn posts, and downstream formats.

Subscribe now

Encoded Judgment Compounds. One-Off Prompting Does Not.

Most founders who use Claude for content start fresh every time. A vague style note, a generic draft, a light edit, and a shrug when it does not sound like them. The problem is not Claude. It is architecture.

Lieberman’s system inverts this. Voice, quality standard, and idea sourcing are encoded once and applied at scale. The voice files accumulate editorial history. The Writer’s Council holds every draft to the same bar. The lessons loop feeds the system’s memory back in after each piece is published.

By post 100, the context going into each new draft is richer than anything a founder could reconstruct in a one-off prompt. The first draft the system produces is solid. The hundredth is substantially better because 99 rounds of feedback are already codified in content-lessons.md.

Lieberman has scaled this beyond himself. The Tenex Creator Cup is a month-long employee challenge with a point system, a $5,000 prize pool, and editor’s picks, designed to convert every hire into a content creator using the same framework. His stated rationale: one employee’s content presence is worth a recruiting agency fee. The personal workflow became company infrastructure.

He is also explicit that this took serious investment to build. His own writing on AI transformation puts it plainly: becoming AI-first requires hundreds of hours of rebuilding workflows. Companies that cut marketing teams expecting AI to replace them now lack the people needed to lead the AI work. The system is a capital investment in reusable infrastructure. Not a shortcut.

What Founders Can Steal First

If you are running content without a dedicated team, Lieberman’s workflow points to a clear build order.

Voice files first. One afternoon of writing style-guide.md and voice-guide.md changes every Claude output you produce from that day forward. Highest leverage, lowest technical barrier. If you take one thing from this article, take this. The voice file is infrastructure, not a prompt, and it pays dividends on every piece you write.

The lessons loop second. After you edit a Claude draft, capture what you changed and why. Append it to a content-lessons.md file. You are already doing the editorial thinking when you edit. The only habit change is writing it down for reuse.

Voice-to-text input third. Wispr Flow or any equivalent voice-to-text tool changes the quality of raw material going into the draft. Speaking real-time answers to interview questions produces more authentic source material than typing crafted prompts. The Interview Panel step only works if the input is genuine.

The Oracle and Writer’s Council when you are ready to build. Both require real setup time. API connections for the Oracle, persona scaffolding for the Council. You can approximate the Council faster: prompt Claude to evaluate its own draft against specific named criteria before you read it. That alone closes a significant portion of the quality gap.

The full system took serious investment. The first layer (voice files plus a running lessons log) takes a day.

The Stakes

Content at scale used to be a headcount problem. A writer, an editor, a distribution function. Lieberman’s documented result (one person, tens of millions in pipeline, allergic to AI slop) makes the case that it is now a systems problem. Build the right architecture and the headcount argument dissolves.

This is the shift Agilito has been pointing at: Claude is not a productivity feature you bolt onto an existing workflow. It is an organizational architecture question. Lieberman’s six steps are evidence at scale, from a founder whose previous media company sold for $75 million and who chose to build the next one on six Markdown files and a quality gate.

The workflow is on the record. Start with the voice files.

Want the tactical implementation? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

Tyler Folkman, Chief AI Officer at JobNimbus, ran a controlled experiment on July 26, 2026. He wanted to cut AI coding costs by handing off from a frontier model to a cheaper one mid-task: the frontier model explores and plans, the budget model executes. Three Python repair tasks. Multiple passes. Every dollar logged.

The “cheaper” route cost 4.1x more.

Sol (OpenAI’s frontier coding model) alone: 4 of 6 passing runs, $2.74 total. Sol-to-Kimi handoff (Kimi K2.7 Code, Moonshot AI’s open-source model): 3 of 5 passing runs, $11.12 total. One failed run on the chess-reporting task alone hit $7.52, which is 2.7x Sol’s entire six-run total.

This is not an argument against AI handoffs. It is an argument against incomplete ones.

Subscribe now

What Folkman Was Replicating, and What He Skipped

The experiment was modeled on Stencil’s published “prewalk” workflow, which Northeast Times had covered five days earlier. Stencil’s claim: 97% of Sol’s pass rate at 61% of the cost on SWE-Bench Pro. The strategy is sound in principle. Let the expensive model front-load the thinking, then hand off to a cheaper executor.

The full Stencil prewalk involves specific scaffolding: a hidden planning instruction, a bounded todo list, instruction pruning before the switch, and executor steering embedded in the cheaper model’s inherited context. Folkman deliberately simplified. His handoff triggered as soon as Sol made a valid file edit, with no pruning, no bounded todo, and no executor steering.

That omission is the story. Stencil’s approach may achieve what it claims. Folkman’s version skipped the parts that prevent context bloat and token waste. The failure is not “handoffs don’t work.” The failure is “handoffs without the scaffolding cost more than no handoff at all.”

Three Variables That Compound into a Cost Multiplier

Folkman’s data exposes three variables that interact to turn a cost-saving strategy into a budget blowout.

1. Task-type variance. The same handoff that cost $0.63 on transaction-reconciliation work hit $7.52 on chess reporting. A 12x swing in a single variable. The frontier model’s planning advantage is task-specific. Tasks with a front-loaded exploration phase followed by straightforward execution are candidates for handoffs. Tasks where complexity runs throughout the work are not.

2. Trigger timing. Folkman’s switch happened at 658 seconds into the task, after Sol had done substantial reasoning. The cheaper model inherited a long conversation and burned tokens consuming it before producing any useful output. Trigger too early and you lose the planning benefit. Trigger too late and you pay for context the cheaper model doesn’t need.

3. Context size at switch. Every subsequent exchange in the inherited conversation carries the weight of Sol’s full reasoning history. Kimi was paying, in tokens, for thinking it hadn’t done. Stencil’s workflow prunes that context before the switch. Folkman’s version didn’t, and that omission is load-bearing.

These three variables interact. Good task fit with poor timing still blows the budget. Perfect timing with an unmanaged context still costs more than staying single-model. Evaluating a handoff by comparing two model price tags measures the wrong thing.

The Rework Tax

API cost is the visible line item. Rework cost is invisible until it compounds.

Folkman’s related framework distinguishes “output latency” from “work latency.” Output latency is how fast the model responds. Work latency is the time until the output is actually usable: after review, after catching failures, after correcting errors a cheaper model produced because it lacked the context to do the job right.

A useful calibration: at $150/hour, 20 minutes of rework per AI task costs $50. Ten occurrences per week runs to roughly $26,000/year in hidden labor, before accounting for delayed decisions and cascading timelines.

METR’s survey of 349 technical workers found median users reported a 3x perceived speed gain, but only a 1.4x to 2x improvement in the actual value of their work. DX Research puts measured productivity at 7.76% PR throughput, not the 3-10x that vendors claim. The gap between “the model responded” and “we shipped something that works” is where the real cost lives, and that gap widens when the executing model is working from incomplete context.

The enterprise data confirms the pattern at scale. Uber burned its entire 2026 AI coding budget in four months. By March, 84% of their engineers had adopted Claude Code, with roughly 70% of committed code coming from AI. Uber’s COO noted publicly that token usage did not correlate directly with useful features shipped. Microsoft instructed engineers in a major division to stop using AI coding tools because the bills became untenable. The same measurement error, at larger scale: optimizing for throughput instead of work produced per dollar.

The Framework: When Single-Model Wins, When Handoffs Can Work

The Stencil prewalk is not a myth. It works because the implementation addresses the three variables above explicitly. A 97% pass rate at 61% of the cost is achievable when task type fits the model, the switch triggers before the expensive model’s reasoning becomes a liability, and context is pruned before handoff.

That is a narrow set of conditions. For most tasks on most teams, single-model is the right default. A multi-model workflow should require evidence on all three variables, not just a favorable comparison of per-token prices.

The signal from Folkman’s experiment and Stencil’s benchmark, read together: the strategy works when it is fully implemented. The version that is cheaper to build, the handoff without scaffolding, is the version that costs more to run.

Subscribe now

How to Calculate Your Handoff TCO Before You Optimize for Model Price

Before you implement any multi-model coding workflow, run this check.

Define task-type fit first. Run the target task class through the expensive model alone and measure cost and quality. Then run it with a handoff, triggering at different points. If the handoff version doesn’t beat the single-model version within three passes, the task type isn’t suited to the strategy. Stop there.

Measure total cost per passing outcome, not cost per token. Count failed runs. Count review time. Count rework. At $150/hour, 20 extra minutes of review per task adds $50 of labor that doesn’t appear on your API bill. If you’re running 10 of these tasks per week, that’s $26,000/year that shows up nowhere in your model cost comparison.

Size the context window at your planned switch point. If the conversation at handoff trigger is already 10,000 tokens, calculate what the cheaper model will spend consuming that before generating useful output. Stencil’s scaffolding prunes this aggressively. If you are not pruning, you are paying for it. Factor that cost into the comparison before you commit to the routing strategy.

The model on the right side of the handoff is not the expensive variable. Measuring what it costs to get there, in full-loop terms, is the work.

Want the tactical implementation? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

Anthropic ran a webinar where Austin Lau, a growth marketer on the company’s own team, walked through how he actually uses Claude Cowork week to week. Not a demo reel. The real operating rhythm of the people who ship the model, using the product they build to run their own marketing.

That is worth pausing on, but not for the reason you might expect. It is not a surprise that Anthropic runs its growth function on agents. It is validation. Building your business around AI-orchestrated workflows is the thesis this whole publication runs on, and here is the model maker documenting the exact pattern from the inside. When the company closest to the frontier publishes its playbook, the move is not to be impressed. The move is to steal it.

So here is the steal. Austin demoed three Cowork workflows. I am going to give you each one, then the one-person version, because you do not have a growth team’s stack of connected ad accounts, and you do not need it. The marketing specifics are incidental. The shape is the payload.

This is the same format I used when Fiona Fung described how the Claude Code team operates without a roadmap: named Anthropic person, reproducible pattern, founder translation. If you are new to Cowork itself, here is where I first got convinced.

Subscribe now

Workflow 1: The scheduled briefing that pulls overnight

Austin’s first workflow is a scheduled Cowork task that pulls from Slack, Gmail, and the ad platforms overnight, so the day’s priorities are waiting when he sits down. Cowork keeps working when he does not. That is the official pitch for the product (”Claude works when you don’t. Close your laptop, Claude Cowork keeps going.”), and this is what it looks like in practice: an unattended overnight pull that turns into a single digest by morning.

To make it concrete, picture a task set to run before you wake, connecting your sources, and dropping a short bucketed summary at the top of your inbox by 6am. That specific time and structure is my illustration of the pattern, not Anthropic’s stated setup. What is sourced is the shape: scheduled, unattended, overnight, priorities waiting at your desk.

The founder translation. You do not have a Google Ads and paid-social stack to mine. You have something better, because it is yours: Gmail, Stripe, and one analytics or support inbox. Build one scheduled Cowork task that connects those via MCP connectors and pulls them overnight into a single digest. New revenue, refunds, churn signals, the three emails that actually need you, one anomaly worth watching. The connected accounts are interchangeable. The primitive is Cowork’s scheduled tasks plus connectors, and the win is that you start the day reading a briefing instead of assembling one.

Most founders spend the first hour of the day manually reconstructing what happened while they slept. This deletes that hour. It is the single easiest of the three to stand up, and it pays off the first morning.

Workflow 2: The audit that proposes and waits for you

The second workflow is the one to internalize deepest. Austin’s Cowork task mines the Google Ads account for search terms, flags negative keywords with its reasoning, and then waits for his approval before changing anything. It does not act. It proposes, explains why, and stops at the gate.

This maps directly onto a load-bearing Cowork feature: “Claude asks before acting.” You set permissions so the agent handles the analysis autonomously but pauses for a human on anything consequential. The agent does the tedious, high-volume reasoning. You keep the decision.

The founder translation. Forget Google Ads. This pattern generalizes to any recurring decision where you want a reasoned recommendation but not autonomous action. Lead triage: the agent scores yesterday’s inbound and proposes who to reply to first, with reasoning, and waits. Spend cleanup: the agent flags subscriptions and vendor charges that look dead, explains the evidence, and waits. Inbox routing: the agent proposes which messages become tasks and which get archived, and waits.

The reusable move is always the same. Flag with reasoning, wait for approval. This is the most transferable idea in the entire playbook, because it resolves the thing that actually stops founders from delegating to agents: the fear of an agent taking an irreversible action on your account. An approval gate removes that fear without removing the leverage. The agent still does the work. You still hold the pen on anything that changes the world.

If you build one thing from this article, build an approval-gated audit of whatever recurring judgment call eats your week.

Workflow 3: The dashboard you open instead of rebuild

The third workflow is a live reporting dashboard the whole team can open, with drill-down by channel. The point Austin makes is subtle and it matters: the team opens the dashboard instead of re-pulling fresh numbers every time someone asks. The reporting stops being an errand. It becomes a surface that is already there.

One note if you go this route today: Cowork’s live artifacts are currently desktop-only, so the always-fresh dashboard lives on the desktop app for now. Web and mobile can start, steer, and review tasks, but the live-artifact surface has not reached them yet.

The founder translation. You almost certainly rebuild the same spreadsheet every week: pull the numbers, paste them in, reformat, repeat. Replace it with a recurring report you open rather than rebuild. The distinction between this and Workflow 1 is worth holding onto. The briefing is a fresh daily push about what needs attention right now. The dashboard is a standing pull you consult when you want the current state of the business. One wakes you up to today. The other answers “how are we doing” without a manual rebuild.

Austin’s team also talked about knowing when to use Cowork versus when to just open regular Claude. Same instinct applies to you. Cowork is for the standing, scheduled, multi-step work. A one-off question is still just a chat.

The bonus pattern: encode your voice once (this one is Claude Code)

Worth naming, because it completes the picture, but keep the source straight. In a separate marketing write-up, Austin describes a custom /rsa slash command he built in Claude Code, not Cowork. It cross-references three Agent Skills he wrote, holding Anthropic’s brand voice, product accuracy, and ad best practices, then outputs finished copy. His line: what used to take 30 minutes per ad now takes 30 seconds.

The founder translation. Build one Skill that holds your positioning, voice, and brand rules, so every copy task is on-brand and validated by default instead of re-explained each time. You encode the judgment once. Every future generation inherits it. Different product, different source, same lesson as the other three: put the standing knowledge into the system so you stop repeating yourself to it.

What to take from Austin

None of these three require a growth team. They require the recognition that the frontier company runs its own house on scheduled pulls, approval gates, and standing dashboards, and that every one of those shapes fits a business of one.

Pick the approval-gated audit first. It is the pattern that turns an agent from a thing you supervise nervously into a thing you actually delegate to. Then add the morning briefing, because it pays off the next day. The dashboard can wait until the first two are habit.

Anthropic put its playbook on the record. You can put all three on next week’s calendar without asking anyone’s permission.

Want more like this? Subscribe to get it delivered.

Subscribe now

Questions? Leave a comment below or connect on LinkedIn.

On June 12, 2026 at 5:21 PM Eastern, Anthropic received a US Commerce Department directive under Secretary Howard Lutnick’s export-control authority. Within hours, Fable 5 and Mythos 5 were disabled for every user on the planet, including US-based ones, because the order restricted access by any foreign national inside or outside the United States. Anthropic said publicly it had no choice. Opus 4.8 stayed up. Fable and Mythos went dark.

The suspension held for nineteen days. Anthropic characterized the affected models as “deployed to hundreds of millions of people.” A critical-infrastructure carve-out came June 27. Full restoration came July 1, after Anthropic agreed to “proactively detect and address security risks” going forward. Developer security firm Snyk’s post-mortem put the lesson bluntly: model redundancy is now a resilience requirement, not just a cost or performance consideration.

Subscribe now

If your product hard-coded Fable 5 into any surface, you spent those nineteen days finding out what your fallback plan actually was. Or discovering you did not have one. Anthropic’s own statement, notably, offered no migration path. The vendor could not tell you what to use in the meantime. And the trigger was not a bug or a rate-limit spike. It was a policy decision made in Washington on a Friday afternoon.

The Hermes field report already made the case for OpenRouter as the routing layer for anything real. That framing was mostly about switching cost and model choice. The Fable ban is what makes it about resilience.

OpenRouter runs on two layers of failover. The first is provider-layer, and it is on by default. If the provider serving your chosen model returns errors or rate limits, OpenRouter routes to the next provider inside a short outage window. The second is model-layer, and it is opt-in. You configure a fallback list per call, so if the primary model itself refuses or disappears, the router walks down your list. Provider-layer would not have carried you through the Fable ban, because Fable itself was gone from every provider. Model-layer would have, because it swaps the model, not the vendor.

Honesty check before the payload. The routing layer is not immune either. OpenRouter itself went down twice in February 2026, for 38 minutes and 35 minutes, caused by a third-party caching layer failure. The post-mortem added circuit breakers. Redundancy of routers matters too.

The Open Frontier Caught Up in Time

The reason a fallback strategy is actually viable now is that the alternatives are good enough to use in production. A year ago, that was not true. The gap between frontier models and the next tier was closer to ten benchmark points than one. GLM 5.2, from Z.ai, released one day after the ban started, lands within one point of Opus 4.8 on standard coding evaluations, at roughly one-fifth the price. The fallback slot went from theoretical to credible almost exactly when it was needed.

Two more names worth keeping. Kimi K2.7 Code, from Moonshot AI, launched the same day as the ban and is built specifically for multi-step coding tasks. DeepSeek V4 Pro benchmarks close to Sonnet 4.6 on coding evaluations, and OpenRouter describes its faster sibling as “frontier-class agentic coding at lowest cost.”

OpenRouter’s own June 2026 recommendation post connects the dots directly. It calls the Fable ban a “geopolitical tailwind” for GLM 5.2’s arrival. Worth noting: the company running the routing infrastructure explicitly tied the political event to the model it now recommends as a fallback.

One flag before you build on any of these. GLM 5.2, Kimi K2.7 Code, and DeepSeek V4 Pro are all from Chinese labs. If that creates a compliance problem at your company, NVIDIA Nemotron 3 Ultra is the US-built alternative OpenRouter names in the same post. Pick based on your legal review, not your Twitter feed.

Check Your Stack

The Fable ban is over. The lesson is the checklist, not the outcome of this specific incident. Six moves any founder can make today.

1. Inventory the model calls in your product. List every surface (chat, background jobs, agent tools, test runs) and every model string. If any surface names Fable 5 or Opus 4.8 with no fallback, that surface has a single point of failure.

2. Route through OpenRouter (or an equivalent) for one non-critical workflow this week. Not the whole product. One workflow. Prove the plumbing works before you need it.

3. Name your two backup models in writing. A defensible pair for coding surfaces: GLM 5.2 and Kimi K2.7 Code. For chat: Sonnet 4.6 and DeepSeek V4 Pro. Revisit quarterly.

4. Configure a model-layer fallback list, not just provider failover. Provider-layer is automatic. Model-layer is opt-in. Wire it once, in writing, before you need it.

5. Run a monthly “route around the primary” drill. Force one workflow onto the backup model for a day. If prompts or output formats break under the swap, you find out on your schedule, not the government’s.

6. Watch the routing layer itself. OpenRouter is a single point of failure too. Know what “OpenRouter down” looks like in your dashboards, and how you would bypass it for anything that changes data.

Nineteen days is a survivable outage window if you planned for it. It is a company-ending one if you did not.

Subscribe now

Want the tactical implementation? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

Armmand Hosseini, a Customer Success manager at Ramp, needed a dashboard to track his clients while traveling. He built it with Claude Cowork, starting the session on his laptop. Then he closed the laptop. He checked on the dashboard from his phone while waiting at baggage claim. “It just held the thread,” he told Anthropic.

That scenario describes something genuinely new as of July 7. Not because mobile task management did not exist before: the April Cowork article covered Dispatch, which let you assign tasks from your phone while your desktop executed them. Your computer still had to be running. The July 7 update removes that dependency. The session runs in Anthropic’s cloud. The desktop is optional for cloud-based work.

This is what that shift means for a founder who wants to put Claude in front of people who are not engineers.

Subscribe now

What Changed on July 7

Anthropic expanded Cowork to web (claude.ai) and mobile. On iOS and Android it lives in the sidebar of the existing Claude app — there is no separate download. The rollout is currently in beta for Max plan subscribers only. Pro, Team, and Enterprise access is described as “in the coming weeks” from July 7, but no specific date has been confirmed. If you are on Pro and wondering why you cannot find it: that is why.

Three things are genuinely new.

The execution host moved to Anthropic’s cloud. Standard Cowork sessions on web and mobile now run on Anthropic’s infrastructure rather than on your machine. Background execution was already available in the Routines preview, which previously ran “whether your laptop is open, closed, or off.” July 7 extends that to standard web and mobile Cowork sessions across the board. From Anthropic: “Start a task at your desk, check on it from your phone, and pick up the finished output anywhere.”

The mobile interface became a full session rather than a relay. Dispatch in the April article was phone-as-remote-control-of-your-desktop. This update makes the desktop optional for cloud-runnable work.

The interface unified. Chat and Cowork now share a single home tab on web and in the desktop app, with projects and artifacts shared across surfaces.

What did not change: local file access, browser control, computer use, and live artifacts still require the desktop app. If the workflow needs Claude to navigate a browser on your machine or access files that live locally, the desktop stays in the picture.

Two Remote Controls, Two Audiences

The May 2026 article on Claude Code Remote Control described one version of pocket access: CLI Remote Control, still in research preview, lets a developer drive a Claude Code session from their phone. The machine runs the session; the phone is the steering wheel.

Cowork web and mobile is a different mechanism for a different person.

CLI Remote Control: developer tool, research preview, your machine executes. Cowork web/mobile: non-developer tool, beta, Anthropic’s cloud executes.

Different execution hosts. Different audiences. Both now reachable from a phone.

The useful frame for a founder: one of these belongs in the hands of engineers and technical leads who already run Claude Code. The other belongs in the hands of anyone on your team who does structured knowledge work: operations, content, finance, account management. The July 7 expansion closes the surface gap that kept the second group desktop-dependent.

One practical note for Max subscribers: Anthropic doubled Cowork usage limits through August 5, 2026. If you have been holding back on running larger Cowork experiments, this is the window.

The Usage Data Validates What Was Already the Argument

Anthropic released usage data alongside the July 7 announcement. The headline number: "more than 90% of it wasn't software development." Business operations and content creation together account for "roughly half of all usage," per the Anthropic blog. Tech press reporting on the usage data puts the breakdown at approximately 33% business operations, 16% content creation, and 9% coding.

This is not a surprise. It is a confirmation.

The April and June Cowork articles made the case that Cowork was a tool for the full organization, not just engineering, and that the high-value use cases were the operational and content workflows that make up the majority of a company’s knowledge work. Anthropic’s data, drawn from what tech press analysis reports as 1.2 million sessions across 600,000-plus organizations, confirms that pattern at scale.

The mobile expansion was not a coincidence. The people doing business operations are not at a desktop all day. They are in meetings, traveling, between calls. The July 7 surface change matches the tool to where the work already was.

Which Tool Goes to Which Person

For a founder deciding where to invest attention this week:

If you have developers or technical leads already running Claude Code, point them toward Claude Code Remote Control when it graduates from research preview. Today they can already drive a CLI session from a phone or browser. That is their surface.

If you have non-technical team members doing business operations, content, analysis, or client work, Cowork web and mobile is their surface — once it reaches your plan. For Max subscribers it is available now. For Pro, Team, and Enterprise, the rollout is described as “coming weeks” from July 7. When it arrives: they do not need Claude Desktop, they do not need to understand what a model is, they need a browser tab or the Claude app sidebar, a connection to Google Drive or Slack, and a task to hand off.

The human approval mechanic matters for both audiences. When Claude reaches a decision it cannot resolve alone, the prompt goes to the phone. From Anthropic: “When Claude reaches a call only you can make, it asks, and the question reaches your phone.” The team member stays in the loop without staying at a desk.

That is the practical shift July 7 made. Cowork was already the right tool for non-developer team members. Now it follows them.

Subscribe now

Want more like this? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

Imagine your Claude Code agent session running unattended for an hour. No errors in the terminal. No crash. Just a dialog sitting there, waiting for a response that will never come, because the auto-continue behavior that would have resolved it was disabled in a changelog line on July 3. The session never recovers. The task never finishes.

That is the failure mode Anthropic shipped in v2.1.200. It is entirely invisible until it hits.

Subscribe now

What Actually Changed

Two things changed in v2.1.200. They are related but distinct.

The rename. The permission mode previously labeled “default” is now labeled “Manual” across the CLI, VS Code, and JetBrains. The official changelog wording: “Changed the ‘default’ permission mode to ‘Manual’ across the CLI, --help, VS Code, and JetBrains; --permission-mode manual and "defaultMode": "manual" are accepted alongside default.”

This is clarifying, not behavior-changing. The default mode has always required explicit approval for file edits, shell commands, and network requests. It only ran reads without asking. What changed is that Anthropic is now calling it what it always was. If you were running in “default” mode and believed that meant Claude would handle things automatically, v2.1.200 corrects that assumption. The label now reflects what the behavior has always done.

The AskUserQuestion change. This one is operational, and it is the real stall risk. The changelog: “Changed AskUserQuestion dialogs to no longer auto-continue by default; opt into an idle timeout via /config.”

Old behavior: when Claude needed clarification mid-task and no one responded, the dialog would auto-continue after a timeout, selecting the highlighted option. New behavior: it waits indefinitely. In an unattended session or a CI pipeline, this is a silent freeze with no error, no notification, and no recovery path. The task stops. Your pipeline stalls.

The Two-Minute Checklist

Before your next long-running Claude Code session, check two things.

1. Verify your permission mode setting.

Your default lives in ~/.claude/settings.json. Open it and look for:

{
  "permissions": {
    "defaultMode": "manual"
  }
}

If you have a project-level override, check .claude/settings.json in the project root as well. The six modes available:

ModeRuns without askingUse whendefault (labeled “Manual”)Reads onlyNew installs, sensitive reposacceptEditsReads + file edits + common filesystem commandsActive iterationplanReads only, proposes before any changeExploring before committingautoEverything, with background classifierLong tasks, reduced prompt fatiguedontAskOnly pre-approved tools (allow rules)Locked-down CI and scriptsbypassPermissionsEverything, no checksIsolated containers and VMs only

For headless or pipeline runs, set the mode at invocation: claude -p "your prompt" --permission-mode acceptEdits. For VS Code, the setting is claudeCode.initialPermissionMode.

If you are mid-session and want to switch modes without restarting, Shift+Tab cycles through: default (Manual), acceptEdits, plan.

2. Restore AskUserQuestion auto-continue for unattended sessions.

Inside any Claude Code session, run /config and set an idle timeout. A 60-second value works for most interactive use; 5 minutes gives pipeline runs more room to breathe. Without this, any session that hits an AskUserQuestion dialog will wait indefinitely.

For fully non-interactive sessions running with the -p flag, note that repeated permission blocks abort the session entirely. There is no user to prompt. Set --permission-mode acceptEdits or --permission-mode bypassPermissions (for isolated environments only) at the start of the invocation.

The Same Week, Anthropic Did the Opposite

One week after the manual-default rename, v2.1.207 removed the CLAUDE_CODE_ENABLE_AUTO_MODE opt-in requirement on Bedrock, Vertex AI, and Foundry. Auto mode is now available on those platforms without any flag.

Read together, the two moves signal a deliberate design philosophy: be explicit about what “default” means for new and unaware users; reduce friction for enterprise operators who have actively chosen more autonomy. The safety architecture does not change. The labeling gets more honest, and the access path for operators who have earned trust gets shorter.

That is not contradiction. That is precision.

What This Signals

Anthropic did not publish a blog post for v2.1.200. No announcement, no press release. Just a changelog line. That is not carelessness. That is a considered choice to let the behavior speak without marketing it.

The rename and the AskUserQuestion change align with where OWASP LLM Top 10 and NIST IR 8596 are pointing: human-in-the-loop checkpoints for consequential AI actions. Anthropic did not cite either framework. They did not need to. The direction is consistent: human approval should be the default; automation should be deliberate.

This is what responsible operator practice looks like at the tool level. Not blocking capability, but making the capability choice legible. The argument I have been making since the start of Agilito Accelerator is that the AI-native workflows worth building are the ones transparent about what they are doing and when they need a human. v2.1.200 is a small changelog entry that reflects exactly that.

The two things to do today: check your permission mode settings and restore your AskUserQuestion idle timeout if you run unattended sessions. Those two changes take two minutes. They are the difference between a session that completes and one that waits forever.

Subscribe now

Want more like this? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

Fiona Fung manages the Claude Code and Cowork teams at Anthropic. Boris Cherny, Head of Claude Code, reports to her. He’s the one who stopped writing prompts in favor of building loops. Before Anthropic, she spent 25 years at Microsoft on Visual Studio and TypeScript, then at Meta where she started Facebook Marketplace (now over $100B in annual GMV) and led integrity and safety at Instagram. When Lenny Rachitsky asked her on June 21 how her team actually operates, she did not lead with the “engineers ship more code” line every writeup fixated on.

She led with the frame that matters: coding is no longer the bottleneck. Verification is.

That is not news to anyone who has been building with Claude Code across roles. It is validation from the person managing the team that ships the tool. And the operating playbook Fung described on the show is not an engineering-org curiosity. It is a founder playbook, formalized inside Anthropic before most companies notice the ground has shifted.

I recently audited my own Claude Code use across research, sales, ops, and writing. Fung’s team is running the professional-scale version of the same idea. Four practices from the interview travel directly.

Subscribe now

1. Hire for two profiles only

Fung told Lenny the team hires two archetypes and effectively nothing in between. Profile one: creative builders with product sense who own a feature end to end. Profile two: deep systems experts who catch what the agents get wrong on complex components and understand distributed-system failure modes. Raw coding speed no longer differentiates candidates.

The founder translation. The middle of your headcount plan (generalist operators, seasoned execs who “manage a function,” coordinators who move work between people) is where agents absorb the job first. What survives is the person who can go zero to one with agents on a whole product surface, and the domain-depth expert whose judgment is the verification layer for everything the agents produce.

If you are hiring right now, look at your open roles and ask which archetype each one is. If the honest answer is “neither, but they will run a team,” you are hiring what your own agents will make redundant inside a year.

2. Pairwise programming lunches

Fung said her team started to feel isolated as engineers spent more of the day working alone with their agents. She called it a “lonely experience.” Her fix was pairwise programming lunches, which she compared to children’s parallel play. Two engineers sit side by side, each working with their own agents on their own tasks, not the same problem. Just present in the same room.

Her framing: “When we do pairwise programming, we actually learn so much from each other. Every time I watch someone work, I learn something myself as well.”

The founder translation. Every team living in Claude Code all day loses its apprenticeship channel by default. The best prompt patterns, subagent tricks, CLAUDE.md conventions, and /loop workflows get invented solo and never spread. Founders should install a low-cost ritual (coworking blocks, screen-share Fridays, “watch me run this” sessions) where operators watch each other run agents. This is the new apprenticeship, and it does not happen unless someone puts it on the calendar.

3. Managers start as ICs

Every manager on the Claude Code team, including new hires from outside, starts as an individual contributor. They ship in the codebase before they take on management responsibilities. Fung’s stated purpose is to understand what it is actually like to be an engineer on the team, learn the product, and build rapport before leading it.

The founder translation. This is the anti-abstract-manager rule. If your VP of anything (sales, ops, marketing, product) cannot ship a real artifact using Claude Code, they cannot delegate to agents well and they cannot spot when a report is running the wrong prompt. “AI adoption” from a leader who does not build in the tool is a status report, not a strategy.

Apply this to yourself first. Every founder I know who has real leverage from Claude Code went through their own IC phase in it: prompts they wrote, agents they shipped, workflows they broke and rebuilt. The ones running dashboards of “AI usage” without a single agent they built themselves are watching a metric, not running a company.

4. Monthly planning replaces the six-month roadmap

Fung’s team keeps six-month themes stable but decides specific features in monthly windows. Lightweight spreadsheets, no formal roadmap doc. She said she is even automating the spreadsheets away to keep process overhead near zero.

The founder translation. The quarterly roadmap becomes fiction the moment your ship rate lifts. What you committed to in April is a backlog your own agents have already made obsolete by May. Themes stay stable (”we are building the checkout surface this half,” “we are landing enterprise this quarter”). Feature commitments compress to a month. The planning cadence has to match the execution cadence.

This is the practice most founders resist, because monthly planning looks like less rigor. It is actually more rigor, because you stop writing checks against a future you cannot see. You are shipping against what your team and its agents can actually build in the next four weeks, then re-planning on real information.

What to take from Fung

Every practice on this list is something a founder could install this week. None require Anthropic’s headcount or Anthropic’s compute budget. What they require is the same recognition Fung led with: coding is no longer the bottleneck.

Once you accept that, the second-order questions get sharper. Who verifies the output. Who catches what the agents miss. How new hires learn a workflow that used to live in someone else’s head. How you plan against a shipping cadence that stopped fitting on a Gantt chart.

The person shipping Claude Code and Cowork professionally is running the same playbook we have been running. She has just formalized it faster and put it on the record. If you are building an AI-native company, steal the formalization. The hiring rubric, the pairwise ritual, the manager-as-IC rule, and the monthly planning window are four line items you can put on next week’s calendar without asking anyone’s permission.

Want the tactical implementation? Subscribe to get it delivered.

Subscribe now

Questions? Leave a comment below or connect on LinkedIn.

You set Claude Code loose on a real task. Research three competitors, summarize findings, draft a briefing doc, flag gaps. You step away. An hour later, you come back to find it busy. Files look populated. Output exists. But you dig in and realize it finished a draft and stopped. The competitor research is thin. The gaps section is missing entirely. The agent declared done at the easiest checkpoint it could find and called it complete.

This is not a bad prompt. You wrote the task clearly. Something else failed.

Tyler Folkman, The AI Architect (20,000+ subscribers), put a name to it in a piece called “Your AI Agent Doesn’t Need Better Prompts. It Needs a Goal.” His diagnosis: most agent failures get blamed on prompting when the real problem is that there is no persistent goal for the agent to check against. The prompt resets every turn. The goal does not follow along.

That distinction is the whole game.

Subscribe now

Three Ways Agents Lose the Thread

Before the fix, understand the failure modes. Folkman identifies three.

Goal narrowing. The agent converts a broader task into a narrower, easier one. You specify “draft, review, fix, and validate.” The agent treats it as “write a decent draft.” It did not fail to execute. It executed against a shrunken version of the goal, silently. By the time you notice, it has moved on.

Activity masquerading as evidence. The agent runs commands, generates output, observes results, but never checks whether those results satisfy the original requirements. It produces the appearance of work without closing the loop on whether anything is actually done. Folkman’s frame: “A loop without a durable goal is just an expensive retry button.”

Early stopping at clean checkpoints. The agent hits a natural pause point: a file written, a test passing, a section complete. It declares done. Clean state gets mistaken for done state. The original scope is still half-finished.

Every one of these is a loop problem, not a prompt problem. As Folkman writes: “That is not a prompting failure. That is a harness failure.”

The Framework: Four Layers

Folkman’s fix has four layers.

Prompt. The instruction for each individual turn. This is where most people focus all their energy. It is also the wrong place to solve for completion. The prompt resets every turn. Whatever definition of “done” you embed in it disappears as the conversation continues.

Goal. A durable contract that persists across turns. Not inside the prompt. Separate. Explicit. Written down before the run starts and available at every step.

Loop. Repeated pressure comparing the agent’s current state against the goal. Every turn, the loop asks: have we met the completion criteria? If not, keep going. Without this, the agent exits at the first convenient stopping point.

Harness. The structure that makes the loop enforceable. The infrastructure that holds the goal outside the prompt, survives context resets, and ensures the loop actually runs.

Folkman builds his harness with Pi, an open-source agent runtime with 66,900 GitHub stars (MIT license, actively maintained at pi.dev). The framework is not Pi-specific. You can implement all four layers inside Claude Code right now.

How to Build This in Claude Code

Claude Code does not have a /goal command. What it has is CLAUDE.md: a persistent file the agent reads at the start of every session and at every /loop checkpoint. That is your goal layer.

Before you run anything, create a goal file alongside your task. Not in the prompt. A separate file called GOAL.md or whatever name fits the project. Write the completion criteria as a checklist:

TASK: Competitive research briefing
DONE WHEN:
- [ ] Three competitors analyzed (Acme, Beacon, Crest)
- [ ] Each entry covers pricing, positioning, differentiation
- [ ] Gaps section lists at least two open questions
- [ ] Single output file delivered to /reports

Then add a checkpoint instruction in CLAUDE.md, or at the start of your /loop run: “Before reporting complete, read GOAL.md and verify every item is checked off. Do not stop at a clean checkpoint if any item is unchecked.”

That instruction is Folkman’s Loop layer. The goal file stored outside the prompt is the Goal layer. The fact that it lives on disk and survives context resets is your Harness.

This eliminates goal narrowing by design. The agent cannot quietly shrink the task if the original scope is written down in a file it must check before finishing. It eliminates early stopping because “all tests passing” does not count as done if three checklist items are still unchecked. It short-circuits activity masquerading as evidence because the completion criteria are specific outputs, not activity signals.

The minimum viable version: write down what done looks like before you run anything. Not in the prompt. In a file. Make it a checklist with explicit conditions, including count where count matters.

Folkman’s full piece is worth reading if you run agents at any scale. His engineering framing translates directly to how Claude Code sessions drift. The founders getting the most leverage from long-horizon runs have already arrived at this instinctively: the separate goal file, the explicit checklist, the checkpoint instruction. Now there is a framework to make it deliberate and repeatable.

Subscribe now

Want more like this? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

Boris Cherny, Head of Claude Code at Anthropic, said something on the Acquired Unplugged podcast that I’ve been circling around for months: “I no longer write prompts for Claude. There is a loop running that prompts Claude. My job is to write the loop.”

Read that sentence again. He doesn’t prompt Claude. A loop prompts Claude. His job is writing the loop.

I’ve been building toward this exact model with Claude Code, and hearing Cherny articulate it that cleanly was one of those moments where everything clicks into focus. Not a surprise: a confirmation. The architecture I’ve been working with has a name. Someone who built the tool from the ground up just named it.

The moment isn’t isolated. In the same week of June 2026, Addy Osmani from Google published “Loop Engineering,” framing the shift as “replacing yourself as the person who prompts the agent. You design the system that does it instead.” Claire Vo, Founder of ChatPRD and CPO at LaunchDarkly, followed the next week in Lenny’s Newsletter with a full taxonomy of loop types and concrete walkthroughs. Three credible, independent operators: same week, same conclusion.

When that happens, it’s not coincidence. Something has shifted at the architecture level.

Subscribe now

What loops actually change

Prompting is reactive. You open Claude Code, describe a task, wait for output, react to what comes back. You’re present for every iteration. Your time is the constraint.

Loops remove that constraint. You define the trigger, the context, and what done looks like. The agent handles the rest on whatever cadence you set. Your time isn’t in the loop anymore.

Cherny described the progression in a June 2026 interview with The Neuron: “The interface shifted from source code, to agent, to loop or routine.” Each step multiplies what gets done. At Fortune Brainstorm Tech that same week, he put the scale into concrete terms: “This morning I was managing maybe a few hundred. Some days it’s thousands, or tens of thousands.” That’s not possible if he’s typing prompts. The loops are doing the prompting.

Claire Vo’s taxonomy gives this four concrete shapes. Each has a different trigger type. Here’s how they map to founder work.

Four archetypes, four triggers

Heartbeat: always watching

A heartbeat loop fires on a recurring interval: every five minutes, every hour, continuously. No event triggers it, no fixed time constrains it. It runs.

Use case: a loop that checks your support queue for unresolved tickets older than four hours and surfaces them in Slack. No dashboard, no reminder, no one tasked with checking. The loop watches. Your attention is only needed when it flags something.

This is the lightest entry point into loop thinking: take any condition you wish someone were always monitoring, and write a loop that is.

Cron: scheduled execution

A cron loop fires at a defined time. Same hour, same day, reliably. Claire Vo’s example from her Lenny’s Newsletter framework: a daily Claude Code loop running at 10:15 a.m. that identifies pull requests open longer than 12 hours. It either resolves them via sub-agents or pushes a prioritized summary to Slack. Claude Code’s /loop command is built for exactly this pattern.

For founders shipping product: this is your weekly competitor scan, your end-of-sprint documentation pass, your recurring changelog draft. You write it once. It runs without you. The value isn’t the output alone, it’s that you never have to remember to trigger it.

Hook: event-driven

A hook loop fires when something happens. A new GitHub issue, an inbound webhook, a commit hitting a specific branch. The external event is the trigger.

Cherny described this at Fortune Brainstorm Tech: hundreds of Claude instances monitoring Twitter feedback, GitHub issues, and Slack, firing on new events to triage product signals and generate ideas. Each fires at event speed, not human speed.

For founders: a hook on inbound leads that qualifies and drafts a first response before the notification hits your inbox. Or a hook on new GitHub issues that auto-labels, checks for duplicates, and assigns priority. You get the signal. The triage is already done.

Goal: run until done

A goal loop doesn’t have a fixed trigger or a fixed task. You define an outcome. The agent runs, evaluates whether it’s reached the outcome, and keeps going until it has. Claude Code’s /goal command is built for this.

Claire Vo’s example: a weekly Codex loop that scans your GitHub history for missing agent skills, spawns sub-agents to build and validate each one, and terminates only when all identified gaps have passing tests. You set the destination. The loop finds the path.

Vo’s caution is worth quoting directly: goal loops are “the hardest to write well, and where most people burn tokens for nothing.” The success criteria must be explicit. “Improve the docs” is not a goal. “All public API methods have at least one usage example with verified, runnable code” is a goal. The precision isn’t optional.

Pick one loop

Don’t start with the architecture. Start with one task you run manually on a schedule.

That’s your cron loop. Write it. Run it. Let it work for a cycle.

The mental model shift happens on its own once you have one loop working. You stop thinking about Claude Code as something you operate and start thinking about it as something that operates. That’s the leverage Cherny is describing. It’s available now, in Claude Code, with one loop.

Cherny’s progression: source code to agent to loop. You don’t have to jump to the top. You just have to take the next step.

Subscribe now

Want a walkthrough of setting up your first cron loop in Claude Code? Subscribe to get it when it drops. Questions? Leave a comment below or connect on LinkedIn.

Eddie Kim, co-founder and CTO of Gusto, just told Claire Vo on her show How I AI how his team built Gusto Cofounder, the company’s new AI teammate for small business owners, in 10 weeks flat. No Jira. No Figma. No standups, no retros, no written specs, no product manager. The team was five people: Kim, three engineers, and a designer named Katie who had never written production code before this project and ended up shipping at the 94th percentile for code volume across Gusto’s entire R&D org.

This is the part of the story everyone wants to repeat at the next founder dinner: look how much they cut. It’s a worse story than the one underneath it, which is that the cuts only worked because of three specific things they kept. Cut the same seven items without the three substitutes and you don’t get speed. You get chaos with extra steps.

I’ve been arguing for a while that the AI-native team isn’t leaner because it has fewer humans. It’s leaner because it has fewer artifacts standing between intent and shipped code. Gusto just ran that experiment at company scale, inside a business doing over $1 billion in trailing revenue and serving more than 500,000 small businesses, on a product line with real payroll and compliance stakes. This wasn’t a hackathon. The discipline held under real pressure, and that’s what makes it worth a founder’s attention.

Subscribe now

What got cut, and why each cut was actually a bet

Jira, Figma, specs, standups, retros, Slack threads, the PM role. Seven coordination mechanisms, gone. Each one exists in a normal company to solve a real problem: Jira tracks what’s being worked on, Figma aligns on what something should look like before it’s built, specs capture decisions so they survive a re-org or a hire, standups surface blockers, retros capture lessons, Slack threads hold the ambient context of who’s doing what.

Kim’s team didn’t decide those problems no longer mattered. They decided Claude Code could solve all of them more cheaply than the artifacts could, as long as the team replaced the coordination function of each tool with something faster. That’s the distinction founders skip when they read this story and think “we should just delete our Jira board.” Deleting the artifact without replacing the function it served is how a 5-person team turns into five people building five different products.

What got kept: the three things that make the cuts safe

Perma-Zoom. The team ran one continuous video call for the entire 10-week build, instead of standups, retros, and Slack threads. It’s a strange-sounding habit until you realize what it’s actually replacing: not meetings, but the async coordination tax of writing status updates, reading other people’s status updates, and reconstructing context after time away from the codebase. A standup is a once-a-day snapshot. Perma-Zoom is closer to ambient peripheral vision, for the humans and for Claude Code working alongside them, of what’s actually happening in the code right now. You lose the meeting. You don’t lose the visibility a meeting was trying to provide.

Trash-can PRs. This is the team’s replacement for product docs and specs. Instead of writing a planning doc to debate a feature decision, an engineer would have Claude Code write a real, working pull request. If the idea didn’t hold up, the PR got closed and abandoned, no ceremony, no loss aversion. As Lenny’s Newsletter put it, this is “how to write, review, and delete a full PR as a product decision instead of a planning doc.” The reason this works is entirely about cost: when Claude Code makes a working PR cheap to produce, throwing one away stops feeling like sunk cost and starts feeling like a discarded sketch. A spec document took hours to write and felt expensive to abandon. A real PR, generated in minutes, doesn’t carry that same gravity, even though it’s a more concrete artifact than the doc ever was.

Eval-first debugging. This was Kim’s personal workflow for fixing real customer-reported bugs, and per the ChatPRD recap of the episode, it ran in a consistent sequence: take the bug report, have Claude Code write a failing test that reproduces it, generate a fix, confirm the test now passes, open the PR. The order matters. The team built the failing test before attempting a fix, which turns debugging from “try something and see if it feels right” into a loop with an actual verification gate. That’s eval-first thinking applied to the most boring, constant work an engineering team does: fixing what’s broken.

Three patterns, three different problems solved: ambient visibility instead of status meetings, cheap real artifacts instead of expensive hypothetical ones, and verifiable loops instead of guesswork. Take away any one of the three and the deletions upstream stop being safe.

The same pattern shows up in my own system

I’ve been running something structurally similar in the Agilito Accelerator publishing workflow, and reading Kim’s framework made the parallel hard to miss.

Perma-Zoom’s function is ambient visibility without status meetings. In this system, every article has a workflow_state.json file that every agent updates after every phase: research, drafting, QA, enhancement, social. Any agent, or me, can read the current state of any article at any moment without holding a sync call about where things stand. Same underlying function, different artifact.

Trash-can PRs’ function is making real artifacts cheaper to discard than planning documents. The article-writer agent produces a full draft in one pass from a research brief. If the angle is wrong, the draft gets revised or scrapped with no loss aversion, because it cost one agent run rather than days of human writing time. The mechanic is identical to Kim’s: cheap-to-produce real artifacts replace expensive-to-produce planning documents.

Eval-first debugging’s function is a verification gate that replaces guesswork. I wrote about a version of this in a previous Agilito Accelerator piece (”My Agents Were Silently Breaking Things. These 4 Moves Changed That.”): output gets checked at three layers, the source instruction itself, a QC review gate, and a pre-publish gate, with linters checking what was produced rather than trusting that the instruction was followed. Same principle as Kim’s eval-first loop: verify the artifact, not the intention.

I’m not claiming these are the literal same mechanics. There’s no continuous video call in this setup. But the underlying coordination functions are parallel, and that’s what Kim’s framework actually describes: functions that teams need regardless of what artifacts they use to fulfill them.

What this means if you run a small team

Here is the transferable recipe, as concretely as I can put it.

Step 1: Name the function before you delete the tool. For every tool you want to cut, write one sentence describing what coordination problem it solves. “Jira tracks shared work-in-progress state.” “Standups surface blockers before they compound.” That sentence is what you need to replace, not the tool itself.

Step 2: Replace each function with something cheaper to produce. Kim replaced spec documents with Claude Code PRs. He replaced standups with Perma-Zoom ambient context. The replacement artifact must be cheaper to create AND cheaper to abandon than what it replaces. If it isn’t cheaper to abandon, you’ve just built a new form of loss aversion.

Step 3: Build a verification gate before you expand the scope. Don’t scale a workflow that doesn’t close the loop. Kim’s eval-first sequence means no fix ships without a test that confirms it. If you cut QA processes without a gate that catches what QA was catching, you haven’t streamlined anything. You’ve just deferred the cost.

Kim, asked in this episode to define the tool his team was building with, described an agent as something like an AI SDK running somewhere in the cloud that can look up files and call tools. No mystique. That’s the right register for a founder audience: a tool you can reason about and build a real workflow around. Gusto didn’t get lucky with a clever team. They got disciplined about which three things were load-bearing, deleted everything else, and shipped a regulated product line in ten weeks because of it, not in spite of it.

The question isn’t whether you can cut things. It’s whether you’ve built the three things that would make cutting them safe.

Subscribe now

Want more like this? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

One sentence in one agent’s instructions silently corrupted output across 13 of 22 published articles. The sentence said to concatenate citation superscripts: produce <sup>1</sup><sup>2</sup><sup>3</sup> for adjacent footnotes. Those rendered as one garbled number. Citations 1, 2, 29, 34 became “122934”. No code bug. No model failure. A bad instruction propagated to every output the agent had ever produced.

The full arc is in the previous piece, The Missing Footnote. This piece is about what that case means for anyone building with agents. The article-writer subagent had been making the same mistake on every article it had ever written, and nobody noticed because nobody read the agent’s instructions the way they read code. You have no compiler for prompts. That reframes debugging.

Subscribe now

The Compiler Gap

Code is built on guarantees prompts don’t have. It’s deterministic: same input, same output, reproducible bugs. It’s type-checked, so the compiler catches a whole class of errors before runtime. It’s version-controlled, with authors and diffs and commit messages. It’s blame-able. When something breaks, you can trace which line, which commit, which person.

Prompts have none of that by default. They’re probabilistic: same input, different outputs, bugs that drift. No static analysis. No type system. No linter. They often live outside the repo, edited inline in a chat window or a Notion doc, untracked. Their failures don’t produce stack traces. They produce subtly wrong outputs that the agent confidently asserts are correct.

A buggy function throws. A buggy prompt ships polished, plausible output that happens to be wrong. The garbled “122934” looked like a number. It rendered. It published. A downstream linter caught it, not an upstream stack trace.

Why This Scales Badly

Chat AI hides this problem. You tweak each conversation, correct bad patterns mid-thread, pay the friction per-conversation. The cost is invisible everywhere else.

Agent systems amplify it. One prompt runs thousands of times. A bad pattern gets baked into every output, silently, until something downstream notices. The article-writer’s bad sentence corrupted 13 articles before it surfaced, and nothing would have stopped it at 13.

That cuts both ways, and the cutting-both-ways part is the founder insight. The same property that makes one bad sentence corrupt a thousand outputs makes one good sentence improve a thousand. The leverage is identical. Discipline determines which direction it points. Founders who don’t develop that discipline aren’t building leverage. They’re scaling drift.

Treat Prompts As Code

The Agilito framework has four moves. None of them are clever. All are imported wholesale from how senior engineers treat code.

1. Version and review prompts like code. Prompts live in the repo. They get diffed in PRs. They have authors and commit messages. If your agent’s instructions live in a chat window or a Notion doc you edit inline, you have no history, no review, no rollback. Move them to a file. Review them the way you’d review a database migration.

2. Build linters on output, not on prompt text. You cannot statically analyze “write the citations concatenated” as wrong. The instruction reads fine. The bug is in what it produces. The citation-lint tool from the Missing Footnote case doesn’t know what the prompt said. It knows what a well-formed article looks like, and it fails when an article doesn’t. Check the artifact, not the recipe.

3. Defense in depth at three layers. Because the model is probabilistic, one barrier isn’t enough. The Missing Footnote fix wired the check into three places: the source instruction (so the defect stops being created), the QC review gate (so it gets caught anyway), and the pre-publish gate (so it never ships). Any one would have caught the bug. All three together make it structurally impossible to ship.

4. Encode lessons to persistent memory. The agent maintains a memory directory of durable lessons, one fact per file. When a class of bug is fixed, the lesson goes into memory so future sessions don’t re-learn it. Chat AI is amnesiac by default. Agent systems get more reliable each time they’re used, but only if you encode the lessons. Persistent file-based memory turns one-off fixes into compounding knowledge.

When Output Goes Bad, Edit The Agent

This is the through-line from the Missing Footnote piece, and it’s the operational verb of the whole framework: fix the system, not the output.

When an agent produces something wrong, the cheap move is to edit the output. Patch the article, fix the slide, rewrite the email, ship it. Don’t. Edit the agent. Otherwise you fix the same bug in the next fifty outputs too. The whole point of building with agents is that each instruction runs thousands of times. That cuts both ways.

Three steps for triaging an agent failure.

First, assume the root cause lives upstream in the agent’s instructions, not in the model. Model quality matters less than instruction quality at the margin most founders operate at. If the output is consistently wrong in the same way, it’s almost never the model. It’s the prompt.

Second, read the prompt the way you’d read a function’s source. Look for sentences that constrain output shape: format, structure, separators, counts, fields. Those are the load-bearing sentences. The bug is almost always in one of them. The citation defect lived in a single sentence about adjacent superscripts. It read fine in English. It was wrong in markdown.

Third, fix at the source AND add a check at the output. Don’t trust that one fix will hold across thousands of runs. The model is probabilistic. Your verification can’t be.

Prompt Taste

Founders building with agents need to develop prompt taste: the ability to read instructions for hidden bugs the way senior engineers read code for hidden bugs. It’s learnable. It’s not optional if your agents ship to customers.

The leverage is not in writing cleverer prompts. It’s in treating the ones you already have as the load-bearing source code they actually are. Version them. Review them. Lint their output. Gate them at multiple layers. Encode the lessons. That’s what makes agent systems compound. Otherwise you’re running the same chatbot a thousand times and hoping nothing drifts.

The one good sentence improves a thousand outputs. So does the one bad sentence. Which one you’re shipping is a question about your infrastructure, not your model.

Want more like this? Subscribe to get it delivered. Questions? Leave a comment below or connect on LinkedIn.

Subscribe now