👋 Welcome! I’m Daniel Williams. I write Claude Code for Non-Coders for senior technical professionals who built their careers on technical judgment, stopped writing code years ago, and are now figuring out how AI and coding agents will change their work.

The goal is to keep you as the operator, not the AI’s assistant (”reverse-centaur“), by helping you decide which tasks to automate and which require the judgment that made you valuable in the first place.

I advise clients on AI tools, strategy, and human resilience at dewilliams.co. This newsletter is where I document the patterns, commands, and operator habits that help you grow from babysitting prompts to building reliable systems.

Join 34,000+ senior technical professionals learning the operating discipline that keeps your judgment valuable.

SUBSCRIBE

Thursday · the setup habit that keeps you the operator, not the one paying for the model’s bad memory.

tl;dr: If you hit your usage limit frequently, the cause is almost never the price. It is your setup, and specifically one file: the CLAUDE.md that the agent reads on every turn. Most people are running with no CLAUDE.md at all, or with one that has bloated into a wall of text that burns tokens and buries the few instructions that matter. A lean version of that file, plus a couple of habits, is the difference, and it works the same whether you use Claude Code or Cowork. I have not hit a limit since November.

A friend texted me last week that she is done with Claude. It interrupts her work every day by hitting her usage limit, and she is about to move everything to Gemini. She is not the only one; I have heard the same complaint more than once lately, each time from a sharp person who is not doing anything obviously wrong.

Before you cancel anything, look at what Anthropic just did: they made the limits more generous, not less. In May, they doubled the short five-hour window on every paid plan and removed the peak-hour throttle that used to quietly cut your quota in half during busy stretches. A week later, they added another 50% to the weekly cap, a bump that runs through mid-July. If your wall got higher and you are still slamming into it every single day, the wall is not the problem. Something on your side is spending the budget faster than it should.

The first thing to understand is that it is one budget. The same allowance is shared across Cowork, the chat app, and Claude Code. Burn tokens carelessly in one, and you lose capacity in all of them. So the question is not “how do I get more limit.” It is “what is quietly emptying the tank,” and for most people the answer is the file that is supposed to prevent exactly that.

In Claude Code and Cowork, the CLAUDE.md file is a plain-text file that sits in your project, is read into the agent’s memory at the start of the work, and is referenced as it goes. This is true whether you work in Claude Code from a terminal or in Cowork without ever touching a command line: both read that same file, and setting it up well pays off identically in either, so nothing here depends on which one you use. It is where you tell the agent what this project is, how you like things done, and what to leave alone, so it stops guessing and stops asking. It is the single highest-leverage thing in your setup, which is also why it is the single most common thing people get wrong, in two opposite directions.

The first way is to have no CLAUDE.md at all. This is where my friend was. With nothing to orient it, the agent re-derives your project from scratch every session: it reads files it has read before, re-explains its own reasoning, asks you things you already answered last week, and rebuilds context you could have simply handed it. Every one of those moves costs tokens out of the shared budget, and you pay that cost again every time you start. It feels like the tool is being inefficient. It is, but you are the one who left it blindfolded.

The second way is the one almost nobody warns you about, and it is worse because it looks responsible. You add a CLAUDE.md. It helps, so you keep adding to it. Every preference, every past mistake, every edge case, every “make sure you always” gets pasted in until the file is a thousand lines of accumulated rules. Here is the trap: that file is loaded on every turn. A bloated CLAUDE.md is not a one-time setup cost. It is a tax you pay on every message you send, forever. And it does a second kind of damage that has nothing to do with tokens. When the handful of instructions that actually matter are buried in hundreds that rarely apply, the model’s attention spreads thin, and the important ones get missed, the same way the middle of a long document is where things quietly fall through. The file you built to make the agent reliable is now making it both expensive and unreliable.

I know this one because I did it to myself. The project file for this newsletter grew, as they all do, into a wall of voice rules, structural notes, and reminders, and it rode along with every request, whether the task needed it or not. So I cut it down. I shrank it to a short index that says what the project is and points to the few things that matter, and I moved the detailed material into separate documents that the agent only opens when the work actually calls for them. The instructions did not disappear; they just stopped being loaded when they were not needed. The file went from something I paid for on every single request to something so lean I stopped noticing the cost.

That is the whole fix, and the rule of thumb is simple: a good CLAUDE.md is a short index, not a warehouse. Put in the things that are true on every task, what the project is, the handful of commands or conventions you rely on, the clear “do not do this” lines, and leave out everything that is only true some of the time. The detail does not have to live in your head or in the agent’s memory every turn; it can live in other files the agent loads on demand. Lean and pointed beats long and complete, every time, because the agent reads the lean one on every turn, and you want every turn to be cheap.

You do not even have to read the file yourself to find out which problem you have. The agent can check for you. Open your project in Claude Code or Cowork and paste this:

Check my CLAUDE.md setup for this project. I don't write code, so explain in plain 
language.

1. Look for a CLAUDE.md in this project, including any in subfolders.

2. Tell me what you find: none, one, or several, and roughly how long each one is.

3. Give me a plain read: is it missing, about right, or bloated, meaning a long wall 
of rules that loads on every single turn?

Don't change anything yet. Just tell me where I stand.

That is the diagnosis, and most of the time, it is the whole reveal. Neither having no CLAUDE.md nor having a thousand-line one is right. Once you know where you stand, the first pass is safe to do yourself, and the agent can do it for you. Paste this:

Now help me improve my CLAUDE.md. I don’t write code, so explain each step in plain language, show me the change before you make it, and don’t touch any file until I say go.

Now help me improve my CLAUDE.md. I don't write code, so explain each step in
plain language, show me the change before you make it, and don't touch any
file until I say go.

1. If I don’t have a CLAUDE.md, draft a short one: what this project is, the few 
commands or conventions that are true on every task, and any clear “don’t do this” 
lines. Keep it to about a screen. 

2. If mine is bloated, propose a trimmed version: a short index that keeps only what’s 
true on every task, and move the rest (detailed rules, style notes, anything only 
sometimes relevant) into separate files the agent opens only when the work calls for 
them. Nothing gets deleted, only relocated.

3. If mine is about right, tell me the one or two lines to tighten, and leave the rest 
alone. 

4. Show me a before-and-after, say in plain language what you moved and why, and keep a 
copy of the original so I can undo it. Then wait for my go.

That gets you to a lean, pointed file, which is most of the win: the agent reads a short index on every turn instead of a wall of rules. The deeper move, where each rule should actually live across your whole account, a single project, and individual folders, so the right guidance loads only when it is relevant, is what next Tuesday’s paid lesson takes apart, and it teaches that whole config layer by putting it to work in a real build: an agent that captures your work wins and turns them into your next performance review, Build the Agent That Tracks Your Wins and Gets You Promoted. This Thursday gets your file lean. Tuesday builds the full architecture into something you will use every week.

A few habits sit alongside the file and matter almost as much. Start fresh with brief sessions instead of dragging a giant old conversation forward, because a long history is its own bloated context you reload with every message. Use the right model for the job: I still reach for Gemini on the work it is genuinely better at, like parsing an image, a first pass at research, or a quick factual question, and I keep Claude for my primary and agentic work, where the details have to be right, and I have watched it catch errors other models confidently shipped. None of that is about using the tool less. It is about not making it carry weight it does not need to carry.

The limits will keep moving. They went up this spring, and they will change again, and none of that is yours to control. Your architecture setup is. Before you switch tools over a wall you hit every day, find out which one the wall actually is, the tool or your setup, and then go fix the file.

And this is bigger than Claude versus Gemini. There is a newer model or a shinier tool every few weeks, and the temptation, the moment yours frustrates you, is to jump. But every one of these tools rewards the same thing: learning how it actually works and setting it up to work for you. Switch before you have done that, and you do not escape the problem. You carry it to a tool you understand even less and rebuild it there from zero. The people who get the most out of AI are almost never the ones with the newest tool. They are the ones who learned the architecture of the tool they already have. The file is the smallest, fastest example of that; the habit is the whole game.

The discipline of deciding what your agent should know up front and encoding it where it belongs, rather than re-explaining it every session, is the same discipline that separates people who operate these tools from people who are operated by them. Configuration is the part of the stack you actually own; the paid deep dive on that is Stop Treating MCP as Tools. It’s Your Architecture. New here? Start with the map: Start Here: The Claude Architecture.

So before you switch, which will cost you a month of relearning, run that check first. The wall you keep hitting is almost never the one they sell you. It is the one you built, and it is the one you can fix.

SUBSCRIBE

Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.

Claude Code for Non-Coders publishes on Tuesdays and Thursdays. If you found this useful, share it with someone who’s about to rage-quit a tool over a wall they built themselves.

Share

👋 Welcome! I’m Daniel Williams. I write Claude Code for Non-Coders for senior technical professionals who built their careers on technical judgment, stopped writing code years ago, and are now figuring out how AI and coding agents will change their work.

The goal is to keep you as the operator, not the AI’s assistant (”reverse-centaur“), by helping you decide which tasks to automate and which require the judgment that made you valuable in the first place.

I advise clients on AI tools, strategy, and human resilience at dewilliams.co. This newsletter is where I document the patterns, commands, and operator habits that help you grow from babysitting prompts to building reliable systems.

Join 34,000+ senior technical professionals learning the operating discipline that keeps your judgment valuable.

SUBSCRIBE

Architecture Series · Domain 2 · Capstone · Household Operations Agent

The money and attention in AI are focused on the enterprise. Copilots for the sales team, agents for the support queue, six-figure contracts for systems nobody on the floor quite trusts yet. Meanwhile, the highest-value thing you can build with these same tools is sitting in your own house, and almost nobody is building it. Not because it’s hard. Because it’s unglamorous: the furnace filter that’s been overdue for three months, the subscription that quietly renewed for another year, the recurring tasks nobody is tracking until something lapses. This weekend, I built an agent that runs all of that locally on my own machine. The point of this lesson is that you can build one too, by the end of this one.

The harder part isn’t building it. A flashy version takes an afternoon. The harder part is building one you would actually trust with the job, and that is the whole difference between a demo and a tool you rely on. That difference comes down to five decisions, the same five this domain has spent five lessons on. This is the Domain 2 capstone: the lessons, wired into one thing you can run.

This is a paid Architecture lesson. The full build, the five decisions, and the paste-in prompt to build your own are below for subscribers.

SUBSCRIBE

Read more

👋 Welcome! I’m Daniel Williams. I write Claude Code for Non-Coders for senior technical professionals who built their careers on technical judgment, stopped writing code years ago, and are now figuring out how AI and coding agents will change their work.

The goal is to keep you as the operator, not the AI’s assistant (”reverse-centaur“), by helping you decide which tasks to automate and which require the judgment that made you valuable in the first place.

I advise clients on AI tools, strategy, and human resilience at dewilliams.co. This newsletter is where I document the patterns, commands, and operator habits that help you grow from babysitting prompts to building reliable systems.

Join 33,000+ senior technical professionals learning the operating discipline that keeps your judgment valuable.

SUBSCRIBE

Thursday · the build, part two of pointing this at what matters.

tl;dr: Last week, I described the health agent my family has run for six months. Enough of you asked for the build, so here it is: one SQLite file, a few skills, an MCP bridge to Telegram, and a small web app. None of it is exotic. I put a clean starter on GitHub you can clone, or there’s a prompt at the end you can paste into Claude Code to build your own from scratch this weekend, plus the one unglamorous fix that’s the actual difference between a clever demo and something a family uses for half a year.

When I described the health agent my family runs last week, I said I’d walk the full build in a follow-up. The comments made it clear what most of you wanted, and it wasn’t a treatise on architecture. It was the parts list and the wiring, for your own families, not your jobs. So that’s what this is.

Here’s the part I want to get across before any of the pieces: the build is not the hard part. I put the first working version together over a weekend. The hard part was a design decision I got wrong at first and had to correct, and the one boring script almost nobody writes about. The components themselves are simple and the same four every time.

At the center is one record. A single SQLite file, which is just a database that lives as one file on your own machine, no server to rent and no account to create. A short schema file defines the tables: who the users are, and then a table for each thing you actually track. In our case, that’s blood pressure and weight, sleep, workouts, and a log of medications, symptoms, and any reactions. Yours will be different, and that’s the point: you define the record around what your family needs, not around what some product decided to measure. Everything else in the system is either a way to put data into that file or a way to look at what’s in it.

The skills are the routines that the agent already knows how to run. In Claude Code, a skill is just a short instruction file you drop in a folder, written in plain English, and from then on, the agent has it on tap. I keep three, and walking through them shows how little of this is actually code.

The first delivers the day’s workout. I message the agent, and it pulls that day’s plan from the database, looks up what I actually lifted last time, applies the progression, and sends back the session already adjusted: if last week’s reps held on a compound lift, the weight goes up about five pounds; if a set broke down, it holds me there instead of pushing. My wife trains on a different rule, a three-week cycle with a deload week built in, and the same skill knows to treat her plan differently from mine. Then it sends a second message right behind the first: a pre-filled logging sheet, one line per exercise with today’s target already entered, ready for me to edit.

The second skill closes that loop. After the workout, I send back what I actually did in shorthand, a line like “115# 5 5 5 5 felt strong” and a cardio line at the end. The skill reads it, matches each line to the right exercise, and files every set into the database, the weights, the reps, and the note about going heavier next time. Then it writes back a recap so I can confirm it caught everything. I never open a form. I type one message between sets, and the record updates itself.

The third scores sleep data. I send the night’s numbers, when I went down, when I woke, the total, and the sleep stages if my watch caught them, and the skill logs them against a six-week plan that walks my target bedtime earlier in stages. It works out which phase I’m in, whether I hit that night’s target, and sends back the summary, plus how many of the last seven nights I’ve actually hit. The seven-night number is the one that changed my behavior, because a single bad night is easy to wave off, and a three-out-of-seven week is not.

None of these runs longer than a page of plain English. You are not programming; you are writing down, once, the thing you would otherwise re-explain every morning, and handing it to something that runs it the same way every time.

The bridge is what lets the agent reach beyond the chat window. The database is easy because it’s a local file that the agent can read and write directly. The piece people miss is messaging: I want to log from the gym or a hotel, not from my laptop. That’s an MCP, a small plugin that connects Claude Code to an outside service, in this case, Telegram. With it installed, the agent can read and send Telegram messages, so my phone becomes the way in.

And then two front doors, because capture and review are different jobs, and I stopped trying to make one surface do both. Telegram, plus Claude Channels, so I can reach the agent from anywhere, is the door I use all day: I talk, and it logs. The web app is the other door, a small Python server that reads the same file and draws the charts, the one I open when I want to sit down and actually look at a trend. The app didn’t disappear when the agent arrived; its job just got smaller and clearer. One record, a few skills, one bridge, two front doors. That’s the whole machine.

The design decision I got wrong was thinking the app could be everything. I built the web UI first, with its forms and charts, and it was good at showing and terrible at capturing. Logging meant stopping, opening it, and typing into fields, and that friction is exactly where the data quietly went stale. The fix wasn’t a better app. It was matching the interface to the job: talk to capture, sit down to see. The moment logging became a sentence I could fire off between sets, the record stopped having holes. If you take one thing from this build, take that, because it’s the part that decides whether you’re still using the thing in six months.

Which brings me to the least glamorous and most important part of the whole write-up, because no course teaches it, and it’s a real reason mine is still running. It’s a few lines in my shell startup file that kill any stale messaging-plugin processes whenever I open a new terminal. Without it, an old session hangs around and quietly swallows incoming messages, and you don’t notice until you realize the agent stopped answering your phone two days ago. It isn’t interesting. It’s the difference between a weekend demo and infrastructure your family relies on. Build the fun part first, then spend the extra hour making it durable.

One line I won’t move on, same as last time: the agent does not diagnose and does not treat. It keeps the record honest and organized, so the people with the medical training have something real to work from. The doctors do the medical work. The agent’s whole job is to make sure a good appointment runs on good information, which is the thing most families walk in without.

There are two ways to start, and you type neither one in by hand. You direct an agent, which is the whole premise of this newsletter. The fast way: I put a clean starter on GitHub at github.com/danieleugenewilliams/health-fitness-agent. It’s the skeleton, the schema, the web app, and the three skills, with every bit of my family’s data stripped out; the database and personal files are git-ignored and never leave your machine. Clone it, open it in Claude Code, and tell the agent to walk you through the Telegram setup and adjust the tables to what your family tracks.

The build-your-own way, if you’d rather shape the record around your family from the first table, is to open Claude Code in an empty folder and paste this. It points the agent at the same repo for guidance, then has it build a version customized to you:

You're helping me build a private health record for my family. Everything
stays local on my machine; no accounts, no cloud. I don't write code, so
explain each step in plain language and stop when you need input from me.

Use this repo as your reference for how the pieces fit together, but build
mine customized to my family rather than copying it as-is:
https://github.com/danieleugenewilliams/health-fitness-agent

1. Ask me who the users are and what each person wants to track. Then design
   the SQLite database and schema around that. Treat the repo's tables as a
   menu (workouts, sleep, blood pressure, weight, medications, symptoms) and
   add, drop, or rename tables so they fit my family. Run it to create the DB.
2. Build the small Python web app (server.py) the way the repo does: a local
   dashboard with charts on localhost:8000, reading and writing that same
   database, keeping the last 30 backups automatically.
3. Set up the skills as slash commands in ~/.claude/commands/, based on the
   repo's versions: one that sends a daily workout with progressive overload,
   one that logs a shorthand reply, one that scores a sleep note. Adapt them
   to our names and routines.
4. Install the Telegram MCP so I can message the agent from my phone. Walk me
   through creating the bot, and ask me for each person's Telegram chat ID
   rather than assuming any.

Go one step at a time. Don't move on until I confirm.

The structure is the same whether you track blood pressure or blood sugar or a toddler’s feeding schedule; tell the agent what your family actually tracks and let it shape the tables around that. When it’s running, harden it with one more paste:

Make this durable. Add one thing to my shell startup file (~/.zshrc): a
hook that kills any stale Telegram-plugin processes when I open a new
terminal, so old sessions don't silently swallow messages. Show me the
exact lines and explain what they do.

That’s the build. A file, a few skills, a bridge, two doors, and an hour of unglamorous hardening. If you want the operating discipline underneath it, the reliability habits that keep an agent honest when it’s touching something that matters, that’s what the Architecture track is for. But you don’t need it to start this weekend.

I asked last time what you’d build for the people you love, and the answers in the comments were better than anything I’d have guessed. So I’ll ask the more practical version now: if you build this, what’s the first table you’re going to make, the thing your family keeps losing track of? Tell me, and tell me how it goes. I read all of them.

Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.

Claude Code for Non-Coders publishes on Tuesdays and Thursdays. If you found this useful, share it with someone who’s trying to build something for their own family.

👋 Welcome! I’m Daniel Williams. I write Claude Code for Non-Coders for senior technical professionals who built their careers on technical judgment, stopped writing code years ago, and are now figuring out how AI and coding agents will change their work.

The goal is to keep you as the operator, not the AI’s assistant (”reverse-centaur“), by helping you decide which tasks to automate and which require the judgment that made you valuable in the first place.

I advise clients on AI tools, strategy, and human resilience at dewilliams.co. This newsletter is where I document the patterns, commands, and operator habits that help you grow from babysitting prompts to building reliable systems.

Join 33,000+ senior technical professionals learning the operating discipline that keeps your judgment valuable.

SUBSCRIBE

Architecture Series · Domain 2 · Lesson 2.5 · Built-in Tools (Grep, Glob, Edit)

When your coding agent flails on an unfamiliar codebase, every instinct says to give it more: a bigger context window, a vector index, a few more files pasted into the prompt. The most widely used coding agent in the world was built on the opposite instinct. Anthropic put RAG and a local vector database into early versions of Claude Code, tested it, and tore it out. Boris Cherny, who created Claude Code, said so plainly: “We found pretty quickly that agentic search generally works better.” A colleague in the same thread added that it “outperformed [it] by a lot, and this was surprising.” The tool millions of engineers now use to understand code does not read the codebase. It searches for it.

That is the spine of this whole domain, and it arrives at the layer you already have. Each Domain 2 lesson has covered one part of how your agent uses tools: how it picks the right one, what it does when one fails, how many it should have, and which servers you connect to. This week is about the tools that ship before you connect anything, the ones most builders treat as beginner plumbing and use wrong: Grep, Glob, Read, Write, Edit. Used with precision, they are how an agent finds the one thing that matters without drowning in everything that doesn’t. Used carelessly, they are how your context window and your invoice both blow up.

This is a paid Architecture lesson. The full lesson, with the research behind it and the operator habits, is below for paid subscribers.

SUBSCRIBE

Read more

You became the training data

Meta spent this spring capturing how its employees work, down to the keystroke. The program, the Model Capability Initiative, recorded mouse movements, clicks, keystrokes, and periodic snapshots of employees’ screens, all to train AI agents to perform computer tasks the way its people do (Fortune). The workers were not using the tool. They were the raw material for it. After weeks of backlash, Meta scaled the program back, adding a 30-minute pause button and a way to request an exemption, though by then some employees had reported the monitoring chewed through a month of home internet in a matter of days (Platformer, HR Grapevine).

You know the rule from a decade of free apps: if you aren’t paying for the product, you are the product. The workplace version is worse. Here, the employee is paid for salaried hours and is still the product. The tool arrives as a perk; the worker feeds it simply by doing the job in front of it, and the agent it trains gets pointed back to that same job. The model isn’t doing the controlling. The employer is: it sets the timeline, chooses the purpose, and owns the recording. If you are a senior professional wondering how an agent learned the shape of your work, the answer is increasingly that someone watched a person do it and trained on the tape. The model is downstream. The decision to harvest the work and to aim the result back at the worker is upstream. That is the part to watch.

Open weights crossed the frontier. You still can’t run them.

The open models caught up this month. MiniMax M3, released June 1, edged GPT-5.5 on SWE-bench Pro at 59%, with a one-million-token context window and native multimodal input (TechTimes). Zhipu’s GLM-5.2 followed under an MIT license. On the benchmarks that track real work, the gap between open and closed has narrowed to single digits (ETF Trends).

The catch is that “open” no longer means “yours.” MiniMax M3 is a 428-billion-parameter model; GLM-5.2 is 744 billion (Artificial Analysis, MarkTechPost). Both are mixture-of-experts designs that fire only a slice of those weights per token, 23 billion for M3 and roughly 40 billion for GLM, but you still have to hold the entire model in memory to run it at all. You can download the weights for free, but you still cannot run them on your laptop or on most common machines. So the thing that actually gates your access isn’t the license, and it isn’t even the price of a GPU, which keeps falling. It’s whether you know how to stand the model up: how to shard it across hardware, quantize it without wrecking its quality, serve it, and keep it serving. That is infrastructure knowledge, and most people who cheer the open-weight headlines don’t have it. Sovereignty via open models is real, but it belongs to the operator who can do the work, not the one who can find the download link. The controller in this story is your own skill, and it is the one controller on this list you can actually acquire. That is the whole project of the paid Architecture series, and the most recent lesson makes the same move one layer down: your MCP setup isn’t a box of tools, it’s your architecture. Open weights are a promise you cannot collect on until you learn how: the model is free, and the skill to run it is the price. I’ll take that build apart in a few weeks.

Grok said yes. Anthropic said no.

The starkest version arrived in a courtroom filing. The Pentagon’s AI chief stated under oath that Elon Musk’s Grok was used throughout the Iran war, helping direct more than 2,000 munitions to 2,000 targets in 96 hours as part of Palantir’s Maven Smart Systems (The Hill, The Debrief). Investigators believe AI-assisted targeting was likely behind a strike on an Iranian girls’ school that killed roughly 175 people, most of them children. Grok is the model serious operators trust least, and it was handed the highest-stakes job there is. That was not a verdict on its capability. Which model goes to war is decided by which company will say yes to the state, and this week showed both sides of that bargain.

Grok said yes and got the contract. Anthropic said no. It refused to let the military use its models for unfettered weaponry and surveillance, and for that, it was made the first US company branded a “supply chain risk,” had federal agencies ordered off its models, and this month watched the government pull Fable 5 and Mythos 5 from every customer worldwide (Inquirer). Anthropic is now suing; the Lutnick letter threatening criminal penalties is public, and the legal basis is looking shaky (Bloomberg, Gizmodo). The Grok disclosure, fittingly, came out through the environmental lawsuit over xAI’s Colossus data center in Memphis, the same facility I noted last week runs the compute under Claude.

So here is the controller most operators never price in. The model you trust most can be switched off worldwide by a letter from one official. The model you trust least can be sent to war. Neither outcome was decided by a benchmark; both were decided by which lab complied. Two weeks ago I argued you don’t have sovereign AI, only a single-layer bet. This is the layer beneath all the others: a government deciding which model is allowed to exist at all.

The knowledge you acquire in how to architect AI systems, not just the software and models, but increasingly, also hardware, will set you apart. Start with the map: The Claude Architecture Series.

Claude Code for Non-Coders publishes Tuesdays and Thursdays. Weekend Dispatch covers the week’s biggest AI developments through a builder’s lens.

Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.

SUBSCRIBE

👋 Welcome! I’m Daniel Williams. I write Claude Code for Non-Coders for senior technical professionals who built their careers on technical judgment, stopped writing code years ago, and are now figuring out how AI and coding agents will change their work.

The goal is to keep you as the operator, not the AI’s assistant (”reverse-centaur“), by helping you decide which tasks to automate and which require the judgment that made you valuable in the first place.

I advise clients on AI tools, strategy, and human resilience at dewilliams.co. This newsletter is where I document the patterns, commands, and operator habits that help you grow from babysitting prompts to building reliable systems.

Join 33,000+ senior technical professionals learning the operating discipline that keeps your judgment valuable.

SUBSCRIBE

tl;dr: I built my family a health system that tracks our training, our sleep, and the medications, symptoms, and reactions that matter, then made it something we just talk to over Telegram. The payoff wasn’t convenience. It was the best shape of our adult lives, and walking into our doctors’ offices as informed partners instead of guessing.

It’s a little before seven, and my phone buzzes. Not an email. A message from an agent I built, with the day’s workout for my wife and me, the weights nudged up from last week. I send back what I actually did. I log my morning blood pressure, and that I took my medication. My wife logs hers. We note one of our sons’ medications for the day. None of it takes longer than it takes for the coffee to brew.

That routine has run for about six months. It saves time, but that isn’t why it matters. It matters because it gave us something no one ever actually hands a family: a clear, continuous record of our own health, and the consistency to act on it.

The reason we got serious is that we were sitting across the breakfast table. We have two sons, nine and seven, and they get bigger and stronger every week. We wrestle and train jiu-jitsu, we race, we spend whole days outside doing things that demand something of a body. I want to keep up with them for a long time. My wife and I are in the best shape of our adult lives right now, and it isn’t because we found a magic program. It’s because we finally stayed consistent, and the agent made consistency automatic instead of something I kept restarting.

On that side, it behaves like a patient trainer. It holds the plan, adds five pounds to a lift when last week’s reps held, eases off when they didn’t, and keeps me on a six-week sleep schedule I would never hold on my own. Sleep turned out to matter as much as the lifting. None of these is a hard idea. Doing them every day for months, without a system catching the gaps, is the part that almost everyone fails at. We stopped failing it.

The quieter half of the record is the one that matters most. For one of my sons and me, we track medications, symptoms, and any reactions in one place. When we sit down with my wellness doctor or with his pediatrician, we don’t reconstruct the last two months from memory. We bring the record.

That sounds small until you see how the rest of it goes. Patients forget somewhere between 40 and 80 percent of what a doctor tells them, often before they reach the parking lot, and recall only about half of the decisions made in the room (AARP). It isn’t a discipline problem; it’s how memory works under stress. And the visits keep getting shorter: 68 percent of patients say their appointments feel rushed (PartnerMD), while the actual management of anything ongoing happens in the weeks between visits, when no one is taking notes. The record is how we stopped losing those weeks.

A few weeks ago, the agent (I call it “Othellobot”) did something a logbook never would. It flagged that my blood pressure had climbed well above my usual range and, without being asked, connected it to a stretch of poor sleep stacked on a stressful week. That is not a diagnosis. It is the kind of pattern I would have felt vaguely and then half-described to my doctor months later. Seeing it written down changed what I did that week and gave my doctor something concrete to work with.

I want to be precise about what the agent does and does not do here, because the line matters. It does not diagnose anything. It does not treat anything. The medication and the doctors do the medical work, and I would never hand that to a model. What the agent does is humbler, and it turns out to be rare: it keeps the data honest and organized so the people with the medical training have something real to work from. A good appointment runs on good information. Most families walk in without it. We stopped having to.

The part other builders will recognize is how the interface evolved, because I got it wrong at first. I started with an app. I built a local tool with a web UI, charts, and a database underneath, all of it. It works, and I still use it: it’s where I go to view the charts, scan for trends, or fix a record by hand. What it was bad at was capture. Logging meant stopping what I was doing, opening the app, and typing into forms, and that friction is where the data quietly went stale.

The change came when I stopped asking the app to be everything and let the agent take the part the app was worst at. Skills for the routines I run often: an MCP so it can access the data; Telegram and Claude Channels so I can message it from my phone, from the gym, from the kitchen, from a hotel on a work trip. Now I capture by talking. I tell it what happened, or ask what the last month looked like, and it logs, updates, analyzes, and answers. The app didn’t die; its job got smaller and clearer. The agent is for capturing and asking from anywhere; the app is for sitting down and seeing. The lesson, if there is one, is to match the interface to the job rather than forcing a single surface to do both.

If you want the shape of it, the pieces fit like this, and I'll walk through the full build in a follow-up. At the center is one small database, a single file that holds everything: the workouts, the readings, the sleep, the medication log. Everything else is a way in or a way to look. The skills are short, named routines the agent already knows: one delivers the day's workout with the progressive overload already worked out; another reads my shorthand reply and files it; a third scores a sleep note against the plan. An MCP is the bridge that lets the agent actually reach things, the database and Telegram itself, rather than just talk about them. Channels and Telegram are how I reach the agent from anywhere. And the web app reads that same file, so what I capture by talking shows up in the charts I sit down to read. One record, a few skills, one bridge, two front doors. That's the whole machine, and none of it is exotic.

Pull back, and the story is bigger than my household. A good personal trainer runs $50 to $100 an hour; add a nutritionist, a sleep coach, and someone to keep the whole record straight, and you are past what most families spend on anything but the mortgage. A personalized, always-available picture of your health, consistent enough to actually change it, has simply never been something most people could afford. The industry sees the gap now: 2026 is the year health systems and startups race to sell you an AI health companion, with firms like BCG reporting that consumers are ready and most executives expect it to pay off (BCG). The difference is that you don’t have to wait for their version, rent it month-to-month, or hand your family’s most private data to a company to get it. The cost of building your own just fell to about an evening of work for someone who knows how. That is what it looks like, in concrete terms, when the cost of expertise collapses. Not a chatbot you subscribe to. A parent at a kitchen table, building the thing a care coordinator used to provide.

I have spent a lot of this newsletter on keeping your skills valuable as the work changes, and I still believe that is the foundation. But it was never the point. The point is what you do with the room it buys you. For me, so far, it has been staying strong enough to wrestle my boys for as many years as they will let me, and showing up to our appointments with something better than a guess. If you can build, the most interesting question is not how to defend your career with it. It is what you would build for the people you love. I would genuinely like to hear what that is for you.

Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.

Claude Code for Non-Coders publishes on Tuesdays and Thursdays. If you found this useful, share it with someone who’s trying to understand why their agent does what it does.

SUBSCRIBE

👋 Welcome! I’m Daniel Williams. I write Claude Code for Non-Coders for senior technical professionals who built their careers on technical judgment, stopped writing code years ago, and are now figuring out how AI and coding agents will change their work.

The goal is to keep you as the operator, not the AI’s assistant (”reverse-centaur“), by helping you decide which tasks to automate and which require the judgment that made you valuable in the first place.

I advise clients on AI tools, strategy, and human resilience at dewilliams.co. This newsletter is where I document the patterns, commands, and operator habits that help you grow from babysitting prompts to building reliable systems.

Join 33,000+ senior technical professionals learning the operating discipline that keeps your judgment valuable.

SUBSCRIBE

Architecture Series · Domain 2 · Lesson 2.4 · MCP Server Integration

tl;dr You didn’t write the GitHub MCP server, but you wrote the config that connects it, and that config is the architecture layer where your scoping, credential, and surface decisions get enforced or quietly leak. Four decisions live there: whether to build or connect, where the config lives, what the model is allowed to call, and how the server talks to your agent. Treating any of them as plumbing is how credentials end up in your Git history, and how read-only data drains your token budget. This is Lesson 2.4 of the Claude Architecture series.

On June 30, the HTTP+SSE transport that a generation of remote MCP servers were built on goes dark, fifteen months after the protocol spec deprecated it. None of those servers changed. The people who connected them all have to. This is the lesson Domain 2 has been pointing to since L2.1: the agent reliability you keep wishing for is sitting in the surfaces you wrote and can edit, and this week the surface is the integration config that most builders paste in without reading.

When I look at how most people wire these servers up, the pattern is the same: the server is fine, the config is the liability. Credentials sitting in a version-controlled file. Read-only data exposed as tools, billing the context window on every turn. A transport line that’s about to break. The full lesson below walks through the four decisions that live in that config, why each one is an architecture decision rather than a setup decision, and what getting them wrong costs you as the model and the price tier underneath you keep moving.

This is a paid Architecture lesson with the config patterns and examples below for subscribers.

Subscribe now

Read more

The meter comes on Monday

On June 15, Anthropic stops subsidizing your agents. Starting Monday, programmatic use splits off the flat subscription into its own metered pool: the Agent SDK, claude -p headless mode, and Claude Code GitHub Actions all bill against a separate credit at full API rates, $20 for Pro, $100 for Max 5x, $200 for Max 20x, none of it rolling over (TechTimes, Vibe Coder). Chat, interactive Claude Code in the terminal, and Cowork stay on your plan. The unattended stuff, the cron jobs, and the SDK loops do not.

The reporting frames this as Anthropic’s third billing fix this year, and the pattern tells you what’s actually happening: agents burn compute at a rate flat-rate plans were never built to carry, and the company has stopped pretending otherwise. The subsidy was never the product. It was a customer-acquisition loss that the unit economics finally caught up to.

The hidden cost of a sloppy agent just became a visible line item. The operator who lets a sub-agent re-read the whole repo on every call, who never caps the loop, who fans out twenty tool calls where three would do, starts paying for that design Monday. I covered one lever against exactly this on Tuesday: an agent carrying too many tools with too little scoping spends tokens on calls it never needed to make (Lesson 2.3: AI Prices Are Going Up. Your Architecture Is Your Hedge.). The operator who tightened that months ago barely notices. The meter doesn’t punish usage. It punishes architecture you never tightened.

OpenAI is selling dollars for forty-five cents

OpenAI is cutting token prices in the same week, and for the opposite reason. It’s bleeding share, ChatGPT’s slice of generative-AI web traffic fell from 77.6% to 53.7% in a year, with more firms on the Ramp index now paying Anthropic than OpenAI, so it’s dropping developer prices to pull enterprise back (Crypto Briefing, Startup Fortune). It’s doing this while running a negative 122% operating margin, losing $1.22 for every dollar it earns, eleven days after filing confidentially to go public (IndexBox).

The naive read is that this is good news, cheaper tokens for everyone. Read it as what it is: a price set below cost to buy market share, by a company about to owe public shareholders a path to margin. That discount has an expiration date built into the IPO it’s filed against.

So if you architect your system around OpenAI’s subsidized June price, you’ve handed a soon-to-be-public company the dial on your cost structure. The day the road show needs to show margin, the price corrects, and your build reprices with it. That makes a cheap token you depend on a lock-in you volunteered for. Don’t chase whichever vendor is bleeding hardest this quarter; build so your design survives the day the bleeding stops.

Sovereignty is the architecture, not the vendor

Put the two price moves next to each other, and the lesson stops being about price at all. One lab is raising the cost of agentic compute toward its true number; the other is cutting it below cost to take share. Neither price is the real one, and building on either as if it were permanent is the mistake. The hedge that survives both is the same hedge: a token-efficient, model-agnostic architecture you can repoint without a rebuild.

This stopped being theoretical this week. Anthropic launched Fable 5 on June 9 and pulled both Fable 5 and Mythos 5 offline for all customers worldwide by June 12, complying with a Commerce Department export order while disputing its rationale (CNBC, Fortune). Seventy-two hours, flagship to dark, on one official’s letter. And the compute under Claude itself runs on hardware you don’t control: Anthropic pays xAI $1.25 billion a month for the whole of Colossus 1 in Memphis, a contract now folded inside the SpaceX entity that went public Friday (TechCrunch).

So sovereignty isn’t running open weights because it feels principled, and it isn’t picking the one correct model. It also isn’t free. Move your stack onto open weights to escape the meter, and the cost doesn’t disappear; it relocates: off the subscription line and onto your energy bill, the GPUs you now rent or run, and the power they pull. An agent that was wasteful on the API is just as wasteful on your own hardware, paid in kilowatt-hours instead of credits. Efficient architecture is the one variable that carries across every regime, the metered API, the subsidized one, and the self-hosted box, which is why your design, not your vendor, is what sovereignty actually rests on. The test is whether your system can absorb a doubled price, a vanished model, or a move to your own iron as a config change instead of a fire drill. Last week, I argued you should build so you can leave. This week, the bill arrived twice. The operator who tightened the architecture early reads all of this as news rather than as an emergency.

New here? The build behind these dispatches lives in the paid Architecture track. Start with the map: Start Here: The Claude Architecture.

Claude Code for Non-Coders publishes Tuesdays and Thursdays. Weekend Dispatch covers the week’s biggest AI developments through a builder’s lens.

Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.

LEADERBOARD

The U.S. bet on concentrated frontier capability: a small number of well-resourced labs, centralized compute, closed-weight models, and premium pricing. China bet on distributed infrastructure across the stack: open-weight models, compute spread across the country, integration into industrial systems, and an architecture designed for breadth rather than peak capability. Both paths exist. Both paths produce real value. The contrarian read is that the distributed path produces more innovation over time, not less, because innovation comes more from breadth of participation than from concentration of resources. That’s the structural argument underneath this piece. Most enterprise stacks haven’t recognized which path they’re on, and U.S. policy in 2022 made the same mistake: it treated sovereignty as a single-layer binary.

What China Built on the Distributed Path

In October 2022, the Biden administration imposed semiconductor export controls aimed at slowing Chinese access to the chips needed for frontier AI training. The H800 restrictions followed in 2023. The Trump administration shifted its approach in 2025 toward strategic licensing of advanced chips with volume caps, a 25% tariff on advanced computing chips, anti-distillation enforcement against Chinese firms that extract capabilities from U.S. models, and direct Trump-Xi negotiations on reciprocal tech access. The mechanics changed across administrations. The underlying bet didn’t. Both bet that targeting Chinese access at the hardware layer would contain China’s rise in AI. By March 2026, the U.S.-China Economic and Security Review Commission was reporting that 80% of U.S. AI startups now use Chinese open-source models. Qwen passed Llama in cumulative Hugging Face downloads. DeepSeek’s R1 release knocked $600 billion off Nvidia’s valuation in a single day. The dependency the policy was meant to prevent ran in the opposite direction.

The export controls didn’t make China lose. They forced China onto a different path. China launched the East-Data-West-Computing initiative in 2022 as a national infrastructure project. The result, four years later, is a high-speed optical network spanning 55,000 kilometers and 40 cities, organized around 8 major computing hubs and 10 data center clusters. The architecture is deliberately distributed: western regions, with four times the renewable energy capacity of eastern ones, handle AI training and batch inference. Eastern hubs handle low-latency applications. Compute moves to where the power is, not the other way around. The choice isn’t only an environmental one. It’s an architectural commitment to a system that can’t be controlled at a single point.

Above the compute layer, the open-weight model strategy did what the export controls were designed to prevent. Alibaba’s Qwen, DeepSeek, Moonshot AI’s Kimi, MiniMax, and ByteDance’s Doubao all reached near-frontier capabilities without the chip access that U.S. policy was trying to deny. Each is open-weight, deployable on whatever compute is available, and substantially cheaper to run than closed-weight U.S. equivalents. Cost per inference runs between one-sixth and one-fourth of frontier U.S. rivals. The 80% adoption number among U.S. startups isn’t an ideological choice. It’s a price-performance choice, and the architecture choice flowed from the constraint that produced it.

Down at the application layer, China is integrating AI into smart factories, supply-chain optimization, and public infrastructure. The Ordos region of Inner Mongolia was transformed from a ghost city into a renewable-energy and computing hub. The deployment pattern is industrial rather than consumer Internet. The U.S. concentration plays out in coastal tech metros and white-collar software products. The Chinese distribution system operates across manufacturing, logistics, and public services nationwide. The two paths produce different kinds of growth: knowledge-work productivity in one, industrial throughput in the other. The asymmetry compounds over time.

The Sovereignty Spectrum Across Five Layers

Sovereignty operates on a spectrum, not a binary, and it exists across five layers. No stack is fully sovereign anywhere. China still depends on TSMC for some chip production. The U.S. labs depend on Nvidia, which depends on TSMC, which depends on ASML. Every enterprise depends on something it doesn’t control. The question isn’t whether you’re sovereign or not sovereign. It’s how high on the spectrum you are at each layer, and which layer has the most room to climb.

Compute is commoditizing fast. Distributed networks, alternative chip strategies, multi-provider routing, and small-model local inference are all spreading. Five years from now, compute sovereignty will be table stakes rather than a source of differentiation. The China example proves you can build a competitive AI economy without owning the leading-edge chip; the U.S. example proves you can build it with one. The compute layer is becoming a substrate you choose between rather than a moat anyone holds.

Model is commoditizing too, faster than most U.S. enterprises expected. Open-weight models catch up to frontier capabilities in months. Switching costs are dropping. Qwen passing Llama in downloads is one data point; the larger pattern is that no model lead lasts as long as the previous one did. Frontier capability is still real, and there are still tasks where the latest closed-weight model produces meaningfully better output. But that lead is shrinking on a clock measured in releases, not years. Building a stack that assumes you can swap models is a stronger architectural position than building one that assumes you can’t.

Architecture is the layer where most of the recent CC4NC writing has lived. MCP, hooks, deterministic specifications, the Outcome Engineer test, and agent portfolio governance. These patterns are becoming public knowledge as fast as they’re being developed. Compliance is folding into architecture, and outcome specification is one of the most important skills to acquire. The architecture layer is becoming a commodity because the patterns are no longer secret. Sovereignty here is about whether you’ve implemented the patterns, not whether you can name them.

Interface is converging on open standards. Headless platforms, MCP, portable agents, vendor-neutral protocols. Salesforce launched Headless 360 in April, featuring 60-plus MCP tools and 30-plus coding skills, and working with Claude Code, Cursor, Codex, and Windsurf. The pitch from Parker Harris was direct: “Why should you ever log into Salesforce again?” Notion shipped its developer platform on May 13 with Workers, Database Sync, an External Agents API, and a CLI for coding agents. ServiceNow opened its MCP Server to any AI agent, including ones a customer brings. Atlassian Rovo, Snowflake Cortex, and HubSpot have all added MCP access. The interface war that seemed set to be fought among Agentforce, Notion AI, Now Assist, and the frontier-lab agents is being settled by openness instead. The platforms went headless because customers chose Claude and ChatGPT over their own agents. Holding the interface didn’t matter if the agent battle was lost; what mattered was holding the data relationship.

Data is the layer that will matter most in five years, and it’s where the spectrum gets the most interesting. When it’s fresh, unique, and tied to ongoing operations, data doesn’t commoditize the way compute, models, architecture, and interface do. Your customer interactions this quarter, your operational telemetry from the last month, your domain context that nobody else has access to: these are yours alone and can’t be reproduced. Stale data, public data, or data that’s been published or leaked does commoditize. The advantage isn’t “data” generically; it’s the data that stays fresh, proprietary, and operationally meaningful. Below that threshold, data is just another resource that can be sourced elsewhere.

The SaaS market is learning and executing on this in real time. The platforms went headless at the interface layer specifically because they recognized the data layer is the moat they actually hold. Salesforce, Notion, ServiceNow, and the rest will lose the agent battle. That’s already happened. They’re betting they can keep the data relationship by exposing it through MCP rather than locking it behind a proprietary chat UI. From the customer’s perspective, this is a mid-spectrum move: you can now bring your own agent to data that lives on the vendor’s infrastructure. You’ve climbed the spectrum at the interface layer. You haven’t climbed it at the data layer, because exit costs are real, the vendor controls the MCP surface, and the data is still hosted somewhere you don’t own.

The mistake to avoid: don’t confuse “I can bring my own agent” with “I have data sovereignty.” Bringing your own agent is the interface-layer win. Owning and hosting your data is the data-layer climb, and most enterprise stacks haven’t started it. Five years from now, when the other four layers are commodities, the question every senior person reading this will be answering is whether their organization’s data still lives on infrastructure they don’t control.

Accenture’s recent Sovereign AI: Own Your AI Future report quantifies the gap. A survey of 1,928 organizations across 28 countries found 60% have applied sovereignty oversight to data, 46% to infrastructure, 35% to security and governance, 32% to applications, and just 22% to AI models. The data and infrastructure work is underway. The model and application layers, where AI-era sovereignty actually lives, are where most enterprises haven’t started.

The GPU-Poor Paradox

The intuition is that more resources buy more sovereignty: GPU-rich means you self-host, GPU-poor means you’re API-dependent. The actual dynamic runs the other way. Constraint at the compute layer pushes you up the spectrum at the other four.

The GPU-poor consultant who built her stack on a frontier API, open-weight fallbacks, portable specifications, and open-standard interfaces has greater aggregate sovereignty than the GPU-rich enterprise that self-hosts one model and ties every prompt to its quirks. The consultant can swap models, change providers, port her specifications, and route work across compute substrates. The enterprise has top-spectrum compute sovereignty and bottom-spectrum sovereignty at everything else. China ran this paradox on a national scale: export controls denied access to top-spectrum compute, and the response was to climb the spectrum in the other four layers harder than they otherwise would have. DeepSeek’s $5.6M training run that knocked $600B off Nvidia’s valuation is the same paradox at the model layer: constrained access produced a leaner architecture that traveled further than the better-resourced incumbents.

I run this newsletter, and most of my clients work with Claude, a frontier model from a U.S. lab. Frontier models do things that distributed alternatives still can’t, and any senior practitioner who pretends otherwise is selling something. The argument isn’t that the concentrated path produces nothing; it’s that the concentrated path has a shorter half-life on any given lead, and the distributed path produces more participants who can build, which compounds over a longer horizon. The reader’s job is to know which path each layer of their stack is on and to climb the spectrum where the exposure is highest.

Your Multi-Layer Sovereignty Test

Not every workload needs to be sovereign. Accenture’s research suggests roughly one-third is the right share for most organizations; the rest can run on the global mix. The test isn’t whether you’ve made everything sovereign. It’s whether the third you have made sovereign is the right third, and whether your sovereignty score on that third matches the stakes.

Map your stack to the five layers and ask one question per layer. Each answer is graded, not binary. Aim for movement, not perfection.

Compute. Do you have any leverage on substrate, or are you fully API-dependent on a single provider?

• Low-spectrum is a single compute provider, whether it be local inference, public cloud, or frontier lab.

• Mid-spectrum looks like multi-provider routing, fallback compute, and local inference for some workloads.

• High-spectrum looks like the ability to move workloads across providers and substrates without rebuilding your stack.

Model. Can you swap to a different model and keep working?

• Low-spectrum is prompts tightly coupled to one model’s quirks.

• Mid-spectrum is portable specifications that work across closed-weight providers.

• High-spectrum is specifications that survive a swap from closed to open-weight, or from a U.S. lab to a Chinese one, without the output collapsing.

Architecture. Is your specification layer (context, hooks, MCP, skills, agent portfolio governance) something you own, or is it locked to a vendor’s tools?

• Low-spectrum is a stack built inside one vendor’s frameworks.

• Mid-spectrum is patterns you’ve implemented yourself but haven’t tested against different runtimes.

• High-spectrum is an architecture that survives a runtime swap because the patterns are vendor-neutral.

Interface. Can users and agents reach your system through open standards, or is access mediated by a proprietary UI?

• Low-spectrum is vendor-locked chat surfaces.

• Mid-spectrum is MCP access alongside the vendor’s UI.

• High-spectrum is open-standard access with the vendor’s UI as one option among many.

Data. Do you own and host your data, or does your operational data live in third-party platforms you can read but not control?

• Low-spectrum is customer and operational data trapped in SaaS platforms with real exit costs.

• Mid-spectrum is MCP access to that data, plus active export pipelines you maintain.

• High-spectrum is data you own, host, and can move without permission. This is the layer I believe will see ROI grow over time.

Find your lowest-spectrum layer. That’s the exposure. The highest-leverage move this quarter is to climb that layer one notch.

What This Asks of You

The U.S. didn’t lose. The export controls produced an unintended outcome at the national scale, and the same single-layer error is being made in most enterprise stacks right now. You’re not sovereign because you self-host. You’re not sovereign because you run open-weight. You’re not sovereign because you can bring your own agent to a SaaS platform. You’re sovereign to the extent that you can move at each of the five layers when the conditions change, and the path you’re on determines how durable that movement is. The concentrated path produces real capability and real fragility. The distributed path produces breadth and the patience that compounds.

The exercise to run this quarter: pick the layer where your sovereignty score is lowest and identify the highest-leverage move to climb it one notch. If it’s data, start an export pipeline from the SaaS platform that holds most of your operational data. If it’s an interface, integrate MCP access into a single system that’s currently locked into a vendor UI. If it’s compute, set up multi-provider routing for one workflow. The move doesn’t need to be all-or-nothing. The point is to start the climb at the layer where you’ve been most exposed.

China didn’t wait for permission to build sovereign AI. The export controls made sure of it. Your path is being decided right now, whether you know it or not. The good news is that the decision is yours, and the climb is achievable. The bad news is that the layer where you’ve been least sovereign is the one most likely to determine where you end up.

Subscribe now

The portable layer this piece is about, the config you can hand to a different model tomorrow, is the paid build: Stop Treating MCP as Tools. It's Your Architecture. New here? Start with the map: The Claude Architecture Series.

Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.

Claude Code for Non-Coders publishes on Tuesdays and Thursdays. If you found this useful, share it with someone whose stack is on one path or the other.

Leaderboard

👋 Welcome! I’m Daniel Williams. I write Claude Code for Non-Coders for senior technical professionals who built their careers on technical judgment, stopped writing code years ago, and are now figuring out how AI and coding agents will change their work.

The goal is to keep you as the operator, not the AI’s assistant (”reverse-centaur“), by helping you decide which tasks to automate and which require the judgment that made you valuable in the first place.

I advise clients on AI tools, strategy, and human resilience at dewilliams.co. This newsletter is where I document the patterns, commands, and operator habits that help you grow from babysitting prompts to building reliable systems.

Join 33,000+ senior technical professionals learning the operating discipline that keeps your judgment valuable.

SUBSCRIBE

Architecture Series · Domain 2 · Lesson 2.3 · Tool Distribution & tool_choice

tl;dr Your agent has too many tools and not enough scoping. Selection reliability is a tool architecture problem, not a model problem. The fix is fewer tools, tighter scoping, and control at the call level. As token prices rise, the architecture discipline is one of the few levers that survive every deployment choice. This is Lesson 2.3 of the Claude Architecture series.

If your coding agent’s bill went up this quarter and you’ve been wondering whether to switch models or wait for the next price cut, the answer to both is the same. Don’t. The next model will cost more, not less. The price cuts you remember belong to a phase of the market that ended in early 2026, and they aren’t coming back on the schedule you expected.

The lever you have is the one you built into your agent’s tool surface, and most of you built it carelessly. Your agent has too many tools and not enough scoping, which is an operational failure that nearly every builder (including me) has shipped to production. It is also a budget-buster that is about to bite harder as pricing reverses. Both are architectural problems. Neither is fixed by picking the next model.

The Architecture Series has been working through Domain 2, one selection lever at a time. Tool descriptions tell the agent which tool to pick. Error responses specify what to do when the selected tool fails. This lesson identifies the third lever: which tools the agent gets to choose from in the first place. Get that wrong, and the first two levers cannot save you, and the budget you wrote into your AWS or Anthropic invoice cannot save you either.

The Visible Cost

The cost is already in your bill, even if you haven’t traced it back to architecture yet. A single MCP server can burn tens of thousands of tokens on tool definitions before the user types a single character. GitHub’s official MCP server alone consumes about 42,000 tokens per call just for the schemas of the tools it exposes. A typical multi-server setup (GitHub for source, Slack for comms, Sentry for errors, Grafana for metrics, Splunk for logs) stacks roughly 58 tools and 55,000 tokens of definitions in your context window before the agent has heard a word of your prompt. That works out to 25-30 percent of a 200K context window spent on tools, during a call where most of the surface area was never going to be used.

Then there’s the accuracy collapse. Bloat the menu past 30 to 50 tools, and tool selection accuracy falls off a cliff: 43 percent to under 14 percent in measured tests. Seven out of eight picks were wrong, on a task that should be a one-shot lookup. The agent isn’t broken. The model isn’t getting dumber. The tool surface is the bottleneck.

Most builders I talk to are running 50+ tools across stacked MCP servers without realizing how much it costs them. The bill keeps climbing. The agent keeps hesitating. The next model release will not fix either one because neither one is a model problem.

Tool Architecture Has Three Levers

Read more

Anthropic shipped Claude Opus 4.8 on May 28, and the notable part is how little changed. It costs the same as 4.7 ($5 per million input tokens and $25 for output), and Anthropic calls it “a modest but tangible improvement.” The headline feature isn’t power. It’s honesty: 4.8 is about four times less likely than 4.7 to let a flaw in its own code pass unremarked, and it flags its own uncertainty instead of bluffing through it (Anthropic). The company’s own roadmap note says the next priority is cheaper models at Opus-level capability. The leaps are becoming refinements.

For two years, the operating assumption was that the next model would be the one that changed your work. That assumption is quietly expiring. When a flagship release leads with candor about its own mistakes rather than a new capability, the frontier has stopped sprinting. I called 4.7 an advisor rather than an executor back in April (the regression isn’t in the model); 4.8 is the same advisor, now willing to tell you where its work is thin.

That changes the question you bring to a new model. Not “how much smarter is it,” but “is it honest enough to trust in something that matters.” Model capability has always been the story. Model trustworthiness is what we’re tracking now.

The money got loud

While the models inched, the money sprinted. SpaceX filed its public S-1 on May 20 and starts trading June 12 at roughly $1.75 trillion (CNBC). OpenAI filed confidentially around May 22, targeting a September listing above a trillion dollars while still losing about $1.22 for every dollar it earns on $2 billion a month in revenue (CNBC). Anthropic filed its own confidential S-1 on June 1, days after raising $65 billion at a $965 billion valuation (NPR). Three of the largest IPOs in history were queued inside three weeks.

The roadshow will sell this as acceleration. Read it the other way. Companies file to go public when the land-grab is maturing into a business that needs public capital and owes shareholders predictable returns, not when the next breakthrough is around the corner. The clearest tell came before the filings: more than 600 current and former OpenAI staff had already sold $6.6 billion in shares on the secondary market (TradingKey). The people with the best information are trimming exposure while the public message stays “we’re still early.”

I’m not telling you what to do with a brokerage account; this isn’t that newsletter. It’s a signal about the industry, not your portfolio. When the people building these companies are cashing out, be skeptical of the “we’re still early” story they’re telling everyone else.

Build so you can leave

If the models are commoditizing and the labs are filing to go public, the operator’s move is to make sure you can walk out the door. A trillion-dollar valuation prices in durable pricing power, and pricing power requires switching costs. The thing that erodes switching costs is open-weight models getting good enough to run yourself. DeepSeek V4 and Qwen 3.6 already turned frontier-adjacent intelligence into something you can host, and the gap to the closed models keeps narrowing. Every closed-model IPO is, underneath, a wager that open weights stay second-rate.

Sovereignty here isn’t about running open-source locally because it feels principled. It’s narrower: can you hand your architecture to a different model tomorrow without rebuilding it from scratch? If yes, the labs’ pricing power doesn’t reach you. If no, you’re renting your leverage from whichever vendor you hardwired, and the rent goes up the moment public shareholders start asking for margin. Build model-agnostic now, while it’s a design choice and not a fire drill.

I’m taking this all the way on Thursday: why China didn’t wait for permission to build its own AI stack, and what model sovereignty means for the systems you’re standing up this year.

When the model commoditizes, the architecture is what stays yours, and that's the paid build: AI Prices Are Going Up. Your Architecture Is Your Hedge. New here? Start with the map: The Claude Architecture Series.

Claude Code for Non-Coders publishes Tuesdays and Thursdays. Weekend Dispatch covers the week’s biggest AI developments through a builder’s lens.

Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.

SUBSCRIBE

If everybody can be a software engineer, software engineering is no longer the scarce skill. The thing that was the gate, the ability to translate intent into working software, is becoming abundant. When something scarce becomes abundant, the value doesn’t disappear. It moves. The question for any senior career built on the old gate is where the value moves to, and whether you’re already standing where it lands.

The role on the other side of that move now has a name. The frontier labs are calling it the Forward Deployed Engineer, paying $10K a day to deploy agents inside customer organizations. OpenAI launched a $4 billion deployment company and acquired Tomoro to staff it with 150 FDEs. Anthropic raised $1.5 billion with Blackstone and Goldman Sachs for the same play. Aaron Levie at Box calls it the fastest-growing role at companies like OpenAI and Anthropic. The Weekend Dispatch covered the external version two weeks ago: a $5.5 billion bet that the right answer for AI deployment is consultants sitting inside your company at $10K a day.

The external bet is real. It is also incomplete. External FDEs can customize the deployment, but they cannot make your team trust the system, improve your data hygiene, or capture the institutional context that determines whether the agent is solving the right problem. That work is internal. It lives with the senior person who knows what good looks like in the organization. Call it the Outcome Engineer: the person inside your company who specifies what the software should do precisely enough that the agent builds it correctly, reliably, repeatably, without continuous interpretation and correction. Becoming one is the move Naval didn’t name.

I had to become an Outcome Engineer before I knew the role existed. When I first started working seriously with coding agents, nearly every interaction was probabilistic. I would describe what I wanted, the model would interpret my intent, and something would come back: usually impressive-looking, often close to what I had in mind, but shaped by the model’s best guess about the gaps between what I said and what I meant. The output varied from session to session on the same problem. The same prompt delivered different results depending on how much context the model had, which model I was using, and what I’d said in the first ten messages of the conversation. I thought this was the nature of the tool. It is not. It was the nature of where I was in the process.

This is what practitioners now call vibe coding. You’re expressing intent and hoping the model’s interpretation of that intent is close enough to be useful. Sometimes it is. Over time, though, you notice something: the results are uneven in ways you can’t fully explain, you’re re-explaining your preferences in every session, and the impressive-looking output sometimes collapses under examination. You’ve built something that works until it doesn’t, and you can’t always tell in advance which one you got.

The transition out of that layer doesn’t happen at once. It happens as you accumulate the infrastructure that makes outcomes repeatable: briefing documents that give the model your context before you’ve typed a word, rules that encode the preferences you’d otherwise re-explain, skills that specify the exact procedure for tasks you run more than once, commands that invoke those procedures without ambiguity. None of this is about complexity. The setups I run now are simpler than the elaborate “multi-agent” architectures I built a year ago and subsequently dismantled. What they are is precise. The model doesn’t interpret; it follows. When I specify the outcome I want, I get that outcome, or I get a failure I can diagnose and correct. That’s context engineering: building the layer beneath the model that makes its behavior deterministic rather than probabilistic.

The test I use is simple. Can I hand this to a different model with similar capabilities tomorrow and get the same result? If yes, I’ve engineered the outcome. If the result depends on this specific model, this specific session, or this specific phrasing, I’m still vibe coding with better vocabulary.

The Distance Between Layers

The career structure that felt like advancement is now the source of exposure. Software development as a profession has historically organized itself into layers of abstraction. You start writing code. As you grow more senior, you move toward reviewing code, designing systems, and managing the people who write the code. Each layer felt like an advancement: more responsibility, more distance from the implementation details. Seniority looked like an abstraction. That pattern wasn’t wrong for most of the last thirty years. It described how technical careers actually worked.

The problem is that the layers between you and value creation are now a different kind of exposure than they used to be. Each layer of seniority added distance from the output. Writing code puts you one step away. Code review added another. Managing a team that did the reviewing added a third. Each layer felt like safety, and each is now the thing that can be removed without the output stopping, because the output keeps coming regardless of who’s in the middle.

Block is the public case. In March 2025, Jack Dorsey cut about 1,000 workers and explicitly demoted 200 managers out of their leadership roles. In February 2026, Block announced cuts of roughly 4,000 jobs, about 40 percent of the workforce, with the stated goal of flattening the org, building smaller and more focused teams, and mandating AI fluency in performance evaluations. Dorsey predicted most companies will make similar cuts within a year. The layers are being compressed, not from the top but from the bottom, and the people who understand this earliest have the most time to reposition.

The dynamic isn’t specific to developers. The same compression is happening at the consulting layer, where the partner whose value lies in translating client needs into project scopes is being asked to produce what the agent could have produced on its own. The product management layer is feeling it, where the PM whose value was aligning stakeholders around a roadmap is being asked whether the alignment work would survive an agent that surfaces the same options. Every layer in which the job description involves translating intent into something an agent could produce is exposed. The layer matters less than the gap between you and the outcome. If the gap is greater than zero, someone will ask whether it could be removed.

The repositioning isn’t about writing more code faster. Developers who respond to this moment by accelerating code production are running toward the disruption rather than away from it. The repositioning is about moving toward outcome specification: becoming the person who defines what the software should do, at a level of precision that an agent can execute against without filling in gaps you didn’t intend. That’s a recognition that the scarcest cognitive skill in a world where code-writing is abundant isn’t the ability to produce code. It’s the ability to specify outcomes precisely enough that the right code gets produced without continuous interpretation and correction.

The timeline on this is shorter than most developers are accounting for. The ones who are repositioning now, who are learning to work at the outcome layer, are building a durable skill while the layer below them is still in transition. The ones who wait for the transition to complete before deciding what to do about it are making a calculation that has historically not worked out well.

The Same Destination From Two Directions

The CC4NC reader, who has never written a line of production code, and the developer, who has spent twenty years doing exactly that, are converging on the same skill set from opposite directions.

The non-coder is arriving at outcome engineering because they’ve discovered that expressing vague intent to a coding agent produces vague results. The better they get at specifying what they want in plain language, with constraints and explicit success criteria, before the session starts, the better the output gets. They’re learning that precision in the brief is the leverage. They’re becoming Outcome Engineers without ever touching a syntax error.

The developer is arriving at the same place from the other direction. They know precisely what they want at the code level, but they’re learning that articulating that precisely enough for an agent to execute reliably, without babysitting the session, without fixing the agent’s interpretation of their intent, requires a different kind of specification than they’re used to writing. Something more like a contract with the agent: here is the outcome, here are the constraints, here is what “done” means, here is how to tell if you got it wrong before it reaches me. The specification is the work. The code is the artifact produced once the specification is sufficiently well-defined.

Aaron Levie has been describing the role for months. “You need humans to go implement this stuff inside the organization. Those are the engineers of the future, if you’re not just building software that is an application.” That description maps directly to the Outcome Engineer. Levie is hiring for it externally at the frontier labs and internally at Box. Every senior technical person reading this is being hired for some version of it, whether the title catches up or not.

An Outcome Engineer is someone who can specify the target precisely enough that the gap between specification and output is not filled by the model’s best guess. It’s the same role arriving from two very different backgrounds, and the path from either direction runs through the same set of skills.

What This Asks of You

The transition Naval was pointing at is real on the access side and incomplete on the value side. The completed version is this: you were hired for the code you could write. You’re hired now for the outcomes you can specify well enough that an agent can produce them without filling in the gaps. The senior people who make this transition early are the ones to whom the next wave of FDE-style work falls. The ones who don’t are the ones whose layer keeps getting compressed.

The objection worth handling is that AI will eventually do outcome engineering too. The model will read the user’s mind, infer intent without specification, and fill in the gaps with judgment rather than guesses. That may come, in some narrow domains, on some timescale. It hasn’t come yet, and what is clear from current practice is that the human context, the institutional knowledge, the read on what success actually looks like for this customer, in this market, this quarter, is the part that doesn’t outsource cleanly to a model trained on the average of the internet. For now, outcome engineering is a human role that an agent executes against.

The exercise to run this week: pick one recurring task you currently do in agent sessions. Write the outcome specification, what you want, what constraints apply, what “done” means, how to tell if it went wrong, precisely enough that a fresh session with a different model would produce the same result. Then run it against a different model. The gap between what you specified and what came back is the work that remains.

Subscribe now

Becoming the rarer thing is what the paid Architecture track teaches, end to end. New here? Start with the map: The Claude Architecture Series.

Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.

Claude Code for Non-Coders publishes on Tuesdays and Thursdays. If you found this useful, share it with someone who’s still writing code instead of specifying outcomes.

👋 Welcome! I’m Daniel Williams. I write Claude Code for Non-Coders for senior technical professionals who built their careers on technical judgment, stopped writing code years ago, and are now figuring out how AI and coding agents will change their work.

The goal is to keep you as the operator, not the AI’s assistant (”reverse-centaur“), by helping you decide which tasks to automate and which require the judgment that made you valuable in the first place.

I advise clients on AI tools, strategy, and human resilience at dewilliams.co. This newsletter is where I document the patterns, commands, and operator habits that help you grow from babysitting prompts to building reliable systems.

Join 33,000+ senior technical professionals learning the operating discipline that keeps your judgment valuable.

SUBSCRIBE

tl;dr If your tool fails and the agent recovers gracefully, you built a tool. If your tool fails and the agent hallucinates a workaround, you built a trap. The fix is structured error responses that name the error category and action, leaving no room for improvisation. This is Lesson 2.2 of the Claude Architecture series.

If your tool fails and the agent recovers gracefully, you built a tool. If your tool fails and the agent hallucinates a workaround, you built a trap.

The trap is expensive in two stacked ways. The wasted calls alone burn through your budget as the agent retries, replans, and escalates. The higher cost is the recovery the agent invents on top of the failure, which sounds reasonable, and which the agent will run against your live system. Models are getting better at sounding reasonable. They are also getting more expensive per call, and the gap between “smarter” and “cheaper” is widening with every release. The path to keeping costs sane is not waiting for the next model. It is architecting your agent so it never has to improvise in the first place.

You have seen the trap close. A tool returned “file not found,” and the agent created the file from scratch. Or it returned “authentication failed,” and the agent looked for a different endpoint that wouldn’t require credentials. Or it returned an empty list, and the agent retried three times before escalating, convinced it had hit a transient outage when the actual story was that the customer didn’t exist.

None of those were model failures. Each one was an error response that left the agent enough ambiguity to be creative, and Claude did what coding agents do at the edges of ambiguity. It filled in.

None of those are hypothetical, either. Last July, Replit’s AI agent deleted the production database of SaaStr founder Jason Lemkin during a code freeze, wiping data on 1,200 executives and 1,190 companies. The agent later confessed it had been “panicking in response to empty queries.” The same month, Google’s Gemini CLI overwrote a product manager’s files after misinterpreting a silent mkdir failure as success, then admitted: “I have failed you completely and catastrophically.” In December 2025, Amazon’s own coding agent autonomously deleted and recreated a live production environment, taking AWS Cost Explorer offline for 13 hours. Different vendors. Same pattern. Each agent read an error response that did not tell it to stop and filled in what it left blank.

The job most builders think they’re doing when they format errors is “return useful diagnostics.” The job they’re actually doing is closing the gap so the agent can interpret what an error means. The error response is part of your agent’s architecture, not the leftovers after the architecture failed.

Two Failures, Only One You Care About

A protocol error occurs when the JSON-RPC call itself fails: a malformed request, a transport timeout, or a broken pipe. The MCP transport catches these. The agent never sees them. You do not write code to handle this case.

An application error is the other thing. The tool ran, the response came back, and the operation failed logically. The customer record didn’t exist. The refund amount exceeded a threshold. The API key was rejected. The agent sees this response and decides what to do next. This is the response you write, and this is the response the agent will improvise around if you let it.

MCP gives you one flag, isError: true, to mark the response as an application error. The flag is necessary. The flag is not the fix. Setting isError: true and returning the string “something went wrong” leaves the agent exactly where it was before: trying to figure out what to do with a vague failure. The structure of the response is the fix. The flag is the envelope it comes in.

The Four Categories

Application errors come in four shapes, and each shape demands a different next move from the agent. Get this mapping wrong, and the agent’s behavior gets worse the harder it tries.

Read more

👋 Welcome! I’m Daniel Williams. I write Claude Code for Non-Coders for senior technical professionals who built their careers on technical judgment, stopped writing code years ago, and are now figuring out how AI and coding agents will change their work.

The goal is to keep you as the operator, not the AI’s assistant (“reverse-centaur”), by helping you decide which tasks to automate and which require the judgment that made you valuable in the first place.

I advise clients on AI tools, strategy, and human resilience at dewilliams.co. This newsletter is where I document the patterns, commands, and operator habits that help you grow from babysitting prompts to building reliable systems.

Join 33,000+ senior technical professionals learning the operating discipline that keeps your judgment valuable.

SUBSCRIBE

Trump killed the AI safety executive order on May 22 after three CEOs called him. The U.S. is so distracted with “winning” the AI race against China that it has yet to develop a unifying vision for using AI to rebuild a decaying homeland.

The order would have set cybersecurity standards and vetted frontier models for the companies most likely to ship the systems that need them. Zuckerberg, Musk, and Sacks called the President personally over the weekend, and by Monday, it was dead (NBC News, Washington Post, Axios). Their argument is the standard anti-regulation line: that regulation slows U.S. competitiveness relative to China. The federal AI agenda is comprehensive on the offense side: the Genesis Mission (November 2025 executive order mobilizing DOE supercomputers for scientific discovery, Apollo-framed), America’s AI Action Plan titled “Winning the Race” (July 2025, ninety-plus federal actions across innovation, infrastructure, and diplomacy), the Presidential AI Challenge for K-12, and AI.gov as a unified portal. Every initiative is organized around that one frame.

“Winning the AI race” has never been defined in concrete terms. More powerful models than China? Owned by whom? Deployed where for what purpose? Until those answers come, “winning” is whatever the loudest CEO needs it to mean. There is nothing in the federal agenda about how AI should serve communities beyond the dominant labs, nothing about rebuilding industries that have lost their footing, nothing about who gets crushed as competition accelerates.

The “regulation kills innovation” argument collapses on inspection as well. China issued more national AI standards in the first half of 2026 than in the previous three years combined. Cybersecurity Law amendments took effect on January 1, with maximum fines increased twentyfold (from RMB 500K to RMB 10M). AI safety sits alongside pandemics and cyberattacks in China’s National Emergency Response Plan. That regulatory expansion happened while DeepSeek V4 and Qwen 3.6 shipped, 35,000 smart factories went online, and the distributed compute network expanded to 1,243 miles of fiber. Dan Wang’s Breakneck calls this the difference between an engineering state and a lawyerly society. China builds at scale because the state functions as an engineering project organized around a unifying vision; the U.S. has become a lawyerly society where industry and government argue over process while the energy for building atrophies.

Without that vision, the U.S. fills the vacuum with chaos and capture. PE-backed data centers run roughshod over local communities. Frontier labs (most, not all) chase consumer engagement loops and enterprise contracts where the next quarter’s revenue lives. Congress has passed no binding AI statute. The executive branch just killed the only proposed one. The judicial branch applies twentieth-century consumer protection law to twenty-first-century technology. All three branches are asleep at the wheel and ignorant of how AI could be deployed for society's benefit. The three CEOs aren’t the cause of the dysfunction, but a symptom of it. They showed up to exploit the dysfunction at the public’s expense.

A unifying vision would be specific about what AI is for, and what it isn’t. The country has problems that have caused infrastructural decay for generations: roads and bridges that should have been rebuilt twenty years ago, manufacturing capacity that hollowed out, agricultural supply chains running on aging logistics, regional health systems that can’t staff themselves, and public schools operating on twentieth-century models. AI could accelerate work on each of them. Instead of eliminating regulation, use AI to speed up compliance and validation. Environmental review, permitting, safety certification. The legal scaffolding that takes a decade on a bridge or transmission line is exactly the workload AI is good at. Builders are already doing this without federal direction. @notesofanomad built ConstructBuddy to automate county and city plan review, exactly the bottleneck that slows local infrastructure to a crawl. The same pattern applies to every permit, certification, and environmental review the country needs to speed up. The people learning to operate AI deliberately are exactly those needed to build it. The choice the killed EO presented (regulate or don’t) is a false binary. The real choice is developing innovative AI solutions that comply with regulation while delivering value at the speed the country, society, communities, and its people actually need.

Dan Haylett’s piece on the hidden losses of retirement is the most accurate description anyone has written of what AI displacement does to senior technical professionals a decade early. Retirement has thirty years of vocabulary for this graveyard. AI displacement has none.

I found Dan Haylett’s piece from May 6 very interesting. Retirement, in Haylett’s phrase, isn’t one loss; it’s “ten things in a trench coat”: identity, status, mastery, tribe, structure, progress, stimulation, purpose, validation, the future tense itself. The financial industry sells retirement as a destination of freedom and choice. Haylett, who plans retirements for a living, calls it a five-year graveyard most people walk into with no emotional preparation at all.

Those losses describe AI displacement exactly. They’re what gets stripped from a senior technical professional when a transformation program closes their role at fifty-five. Block’s restructuring this spring cut 4,000 jobs and demoted 200 managers as part of a 40% workforce reduction. No retirement parties, no gold watches, no language at all. The retirement industry has a thirty-year vocabulary for what these professionals are about to feel. The AI displacement industry has none. Same losses, different rituals, no support on the other side.

Haylett gives flourishing retirees four operator disciplines:

• name losses out loud,

• build a self that isn’t subcontracted to your job title,

• find new tribes on purpose,

• invent your own nexts

These overlap almost exactly with what this newsletter has been teaching senior technical professionals through the AI transition. The fifth one, learn to spend, is retirement-specific. The first four are the operator-discipline that this newsletter has been arguing for. Haylett’s clients start the work at sixty-five. The CC4NC reader can start much earlier.

If you’re a senior technical professional reading this, you’re walking toward one of two graveyards. The retirement version is well-documented; Haylett can name every loss and give you the playbook. The AI displacement version is the same loss inventory arrived at involuntarily, in a culture that doesn’t yet have rituals for what’s actually happening to you. The work of building the self that survives both is the same work. Starting early in your career with intent beats starting at sixty with regret.

Even a planned exit walks through Haylett’s graveyard. I planned mine for nine years, executed it at 45 in August 2024, and still spent eighteen months hedging on what I had become.

The plan started in 2015. My wife left her data engineering job in 2020 to homeschool our sons full-time. I left mine four years later. By every spreadsheet measure, this was a textbook deliberate transition. I still walked into every one of Haylett’s ten losses.

The texts from former colleagues thinned to nothing within six months. I started introducing myself as a “semi-retired consultant,” then a “fractional executive,” then an “advisor.” While technically accurate, none of them described who I had become and my transition from nearly 25 years as a consultant to who I am today: a writer. But “writer” felt exposed in a way that “consultant” never had, so I hedged for over a year.

The evidence slowly built over time. Seventy-plus published pieces. Thirty-three thousand subscribers who showed up for the writing, not the consulting. A backlog of pieces I couldn’t stop adding to. My wife noted I was less stressed than I’d been in twenty+ years of consulting. The honest description (”I am a writer”) was always available. I needed time to let go of my former identity to say it out loud.

If you’re a senior technical professional planning your own exit (or being shoved through one by an AI rollout you didn’t choose), phase 1 is planning the exit itself. Phase 2 is the hedging that comes after: the year-plus you spend introducing yourself as something you used to be, and the work of defining your new identity. That’s the part Haylett can’t fully prepare you for because you have to walk through it to know. Start naming what you’re becoming now, before the exit forces the question.

Anthropic launched Claude for Small Business on May 13. Day-one demos are easy and real. The durable value requires the same operator-discipline work enterprises have been failing at for two years: clean data underneath and deliberate choices about which processes, friction points, and problems are actually worth automating.

Claude for Small Business ships with fifteen agentic workflows and fifteen skills across finance, sales, marketing, and operations. The connector list is comprehensive: QuickBooks, PayPal, HubSpot, Canva, DocuSign, Google Workspace, and Microsoft 365. The promised use cases are real: payroll planning that reconciles QuickBooks with incoming PayPal payments, monthly close that reconciles books against settlements, lead triage from HubSpot, and campaign performance analysis. I’ve connected my stack and automated about half of my finance processes. The demo works.

The day-one demo is not the durable value. The durable value requires two pieces of operator work, which the announcement leaves to the owner. First, the data substrate has to support what the workflows assume. A QuickBooks account where invoices have been categorized inconsistently for three years produces a reconciliation that doesn’t reconcile. A HubSpot deal pipeline where half the records are missing close dates produces a triage that triages nothing. Second, the owner has to pick which of the fifteen workflows are actually worth running against their specific business. Not every workflow fits every owner. The friction points that matter (where time is bleeding, where errors cost money, where the owner’s judgment is being applied to work an agent could carry) are the ones to automate. Toggling everything on and hoping for productivity is the SMB version of the enterprise AI buildouts that haven’t shown bottom-line impact.

McKinsey and HBR have been naming this same problem at the enterprise level for two years. The State of Organizations 2026 report and the Last Mile diagnosis both land on the same conclusion: 88% of organizations deploy AI somewhere, 86% of leaders aren’t ready to embed it in day-to-day operations, and the productivity gains get reabsorbed into low-value work because nobody redesigned the roles, the substrate, and the workflow to target the freed time. Claude for SMB is that problem at smaller scale and lower price. Twenty dollars a month for Claude Cowork is cheap; the operating-discipline cost to extract recurring productivity from it is the same shape of work the enterprise has been trying to crack.

CC4NC has been teaching this same pattern at the code level. The tool can’t outperform the operating discipline that fed it data and chose its targets. The architecture you build over time (clean data, documented processes, deliberate choices about which workflows actually solve your real problems) is what makes the AI work or fail. The agents amplify what’s there. They don’t fix what isn’t.

Claude Code for Non-Coders publishes Tuesdays and Thursdays. Weekend Dispatch covers AI developments that I find interesting and typically share with friends and family.

Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.

LEADERBOARD

👋 Welcome! I’m Daniel Williams. I write Claude Code for Non-Coders for senior technical professionals who built their careers on technical judgment, stopped writing code years ago, and are now figuring out how AI and coding agents will change their work.

The goal is to keep you as the operator, not the AI’s assistant (“reverse-centaur”), by helping you decide which tasks to automate and which require the judgment that made you valuable in the first place.

I advise clients on AI tools, strategy, and human resilience at dewilliams.co. This newsletter is where I document the patterns, commands, and operator habits that help you grow from babysitting prompts to building reliable systems.

Join 33,000+ senior technical professionals learning the operating discipline that keeps your judgment valuable.

SUBSCRIBE

On April 28, a Cursor AI agent running Claude Opus 4.6 deleted PocketOS’s production database in nine seconds. It found an unscoped Railway CLI token, guessed at an API call, and wiped prod plus three months of backups. The agent’s post-mortem, when asked to explain itself, was a confession: it had violated its own instructions, guessed rather than verified, and acted without being asked.

That was the second such incident in a year. A Replit agent did the same thing in July 2025, taking out a SaaS company’s live database during a code freeze and wiping data for over 1,200 executives and 1,190 companies. Both agents apologized in their post-mortems. In both cases, the only thing standing between the agent and the destructive action was the instructions written into the prompt. The instructions weren’t the constraint they appeared to be.

Across the agent ops engagements I’m taking on right now, the same pattern shows up on a smaller scale. Agents behave inconsistently in exactly the situations that require consistency: revenue, expenses, employee and customer data, and regulatory actions. The agents do the work correctly most of the time, and “most of the time” is the problem. That’s not a model failure. It’s the absence of architecture around the model.

You are accountable for the AI you built, the AI you bought, the AI inside platforms you don’t operate, and the AI a colleague built and handed off. The architectural standards you would apply to your own builds apply to all of it. The criteria for what counts as a real control don’t change because the source changed. Wire the architecture around the AI, or pay the tax when the agent runs the wrong command on the wrong day.

The Collapse

Two things made the build/buy distinction useful in the pre-AI era. Building was expensive, so most companies bought what they didn’t have time or expertise to build. And the things you bought came with vendor responsibility, since the vendor had built the thing and you were renting their architecture.

AI broke both. Building agents and policy enforcement is now cheap enough that the company that wouldn’t have built its own ERP in 2015 will build its own AI compliance layer in 2026. The vendors selling AI features are increasingly admitting in the fine print that their models' behavior is non-deterministic and that the customer bears the residual risk.

The May 7 piece in this newsletter named one consequence of the shift: the tolerance for non-builders is shrinking, especially at mid-to-senior levels. The architecture and risk angle are the operational versions of the same trend. “I’m just buying it” was a defensible position when the seller carried the risk. The contracts and the regulators are moving the risk back onto the buyer, and the only way to manage that risk is to become the person who can architect real policy enforcement around the AI you didn’t write.

The Four Sources

The AI in your portfolio comes from four sources. You wrote some of it: agents, scripts, and prompt chains your team built in-house. You bought some of it: enterprise accounts at frontier labs and domain-specific SaaS tools with built-in AI features. Some lives inside platforms you don’t control, like Salesforce Einstein, ServiceNow Now Assist, and the AI features being added to every enterprise app your company already uses. And some came from a colleague who shipped a prototype and walked away, leaving scripts and automations running in production with no current owner.

Each of these is a different surface. The lens you use to assess them doesn’t change because the surface changed. The same questions a builder would ask about their own agent before shipping it apply to every surface above. The work of asking those questions is what most organizations are skipping for the bought, embedded, and inherited surfaces, because the assumption is that someone else has answered them. They haven’t, or they’ve answered them in ways that don’t survive contact with reality.

How You Look at an AI Surface

Four questions decide whether a given AI surface is architecturally sound. Where does the policy live? If it lives in a prompt, you have a behavior. If it lives in code that runs before the action ships, you have a control. The second question is what happens when something goes wrong. That covers two cases: a user trying to bypass the policy, and the agent itself making an autonomous decision under stress. The Cursor and Replit agents weren’t attacked; they violated their instructions on their own. In both cases, “the model won’t” isn’t an answer; “the policy code rejects the attempt and logs it” is. The third is how you would demonstrate this control under pressure, whether to an auditor, a board member, or an incident reviewer. Pointing at a system prompt produces a soft control at best. Pointing at a code path and a test suite that exercises it produces something real. The last question is the hardest: is the failure rate zero, or is it “we haven’t seen it yet”? Models are non-deterministic, which means a prompt-only control’s worst-case behavior is your worst-case exposure, multiplied by your traffic.

Microsoft’s Agent Governance Toolkit quantifies the difference. In their red-team testing, prompt-based safety (“please follow the rules”) resulted in a 26.67% policy violation rate. Deterministic application-layer enforcement produced 0.00%. Same agents. Same scenarios. The 26-point delta is the gap between a behavior and a control. SOC 2, the framework most enterprise software is measured against, assumes controls work the traditional way: documented, tested at a point in time, and effective until intentionally changed. AI delivers none of that natively. The framework expects a control; the agent produces a behavior. The gap is yours to close.

Most vendor pitches conflate behaviors and controls. The language gives them away.

The right-hand column is what a control looks like. The left-hand column is what a behavior looks like. Behaviors are useful. They are not controls. A control survives an adversary. A behavior survives only the well-behaved user. The Cursor agent that wiped PocketOS in nine seconds had an instruction not to run destructive commands; its post-mortem read: “I violated every principle I was given. I guessed instead of verifying. I ran a destructive action without being asked. I didn’t understand what I was doing before doing it.” The instructions were real. The constraints weren’t.

Compliance Is Becoming Agent Architecture

The cost of treating bought or inherited AI as architecturally separate from your own builds shows up in three places, all of which end up on your desk. Production incidents arrive on inherited systems first; the prototype someone shipped six months ago and abandoned is still running, still talking to customers, still capable of producing outputs nobody thought to gate. Then there are the vendor failures you inherit by contract. The breach happens at the vendor, the data was yours, and the regulator calls you. And there are the audit and incident reviews, where the control on paper turned out to be “the vendor said so.” Third-party assertion isn’t evidence of a control, and the reviewer doesn’t accept it. The Delve scandal in March 2026 made that failure mode public: a Y Combinator-backed compliance automation startup was generating SOC 2 reports where 493 out of 494 were nearly identical, with the same paragraphs and the same grammatical errors across hundreds of customers. Y Combinator asked Delve to leave the program. Every customer who pointed at their Delve-generated badge as evidence of a control now has the same problem: the badge wasn’t backed by a control. It was backed by a behavior of the vendor’s documentation generator. Contractual indemnification doesn’t close the gap. The vendor can carry contractual liability; only the buyer can carry the architectural kind, and a regulator looking at the actual control mechanism doesn’t accept “we have indemnification” as evidence of one.

Shadow AI breaches cost an average of $4.63 million per incident, roughly $670,000 higher than breaches without AI involvement. 77% of employees paste data into GenAI tools, and 22% of those pastes contain PII or PCI. The AI surface in your organization is bigger than your architecture knows about, and the gap between those two surfaces is where the cost lives.

This is what it looks like when compliance becomes architecture. The function that used to live in vendor management and compliance team budgets is folding into the work on your desk because non-deterministic agents can’t be governed through vendor-managed badging. The May 14 piece described judgment as the new scarce resource and the asymmetry opening up between people whose judgment is sharpest and people whose output was their differentiator. The architectural version of that asymmetry is the gap between senior people who can run this assessment and senior people who can’t. Forrester’s layoff regret data tracks one symptom: the people who came back were AI architects, not AI consumers.

Standards Don’t Change With the Source

You can’t prompt-engineer your way to reliable agents. You also can’t outsource your way to a compliant AI portfolio. The architectural standards don’t change with the source. Wire the architecture around the AI you bought, the AI you built, and the AI you inherited, because all three have the same name on the page when something goes wrong.

The technical version of “wire the architecture” is the policy enforcement gateway: side-effecting actions are mediated by code that runs before the action ships, not by the model’s instructions. The identity version is harder. It’s the willingness to take ownership of every AI surface in your portfolio, treat each one with the same architectural rigor regardless of who built it, and develop the assessment skill that lets you see in the first thirty seconds whether the controls are real.

The exercise to run this quarter: list every AI surface in your stack across the four categories above. For each, identify whether the controls live in prompts or in code. The ones that live in prompts are your highest-impact architectural work, regardless of who built them.

The architecture that turns strongly-worded prompts into real controls is the paid build: Stop Treating MCP as Tools. It's Your Architecture. New here? Start with the map: The Claude Architecture Series.

Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.

Claude Code for Non-Coders publishes on Tuesdays and Thursdays. If you found this useful, share it with someone whose compliance story is one prompt away from collapsing.

Leaderboard

Architecture Series · Domain 2 · Lesson 2.1 · Tool Design

Domain 1 (Lessons 1.1 – 1.7 + Capstone Parts 1 & 2) is complete. The full series index also appears at the end of this piece.

tl;dr Tool selection is a description problem before it is an architecture problem. The first fix when your agent picks the wrong tool is to rewrite the two competing descriptions so each one names the other and says when NOT to use it.

Your agent picks the wrong tool. You ask about a specific order, and it fetches the customer profile. You ask about a refund, and it lists recent orders. The reflex is to blame Claude. The reflex is wrong.

Tool selection is not a model problem. The model reads each tool’s name and description and picks based on what it sees. When two descriptions say roughly the same thing, the model picks one, and you hope for the best.

For operators who aren’t writing tools themselves, the judgment that matters is what to do about it. You can stack architecture on top, a classifier, a router, or a block of few-shot examples that show correct routing. Or you can fix the descriptions that made the choice ambiguous in the first place. Operators who reach for the classifier turn a thirty-line fix into a three-hundred-line system, and the system still fails at the edges where the descriptions still overlap. Operators who fix the descriptions ship reliable agents and stop fighting their own architecture. This is the kind of choice that separates operators from prompters, the operating discipline this newsletter exists to teach.

The Misrouting Moment

Let’s look at an example in which a customer support agent has five tools: lookup_customer, lookup_order, list_recent_orders, list_refunds, and issue_refund. The user prompts, “Check the status of order #12345.” The agent reaches for lookup_customer. The two descriptions it had to pick between read:

lookup_customer: Retrieves customer information.
lookup_order:    Retrieves order information.

The boundary between them is implied, not stated. The model is being asked to infer where one tool ends and the other begins, based on two short sentences that mirror each other almost word for word. Models infer poorly at the edges of overlapping definitions, and overlapping definitions are the rule, not the exception, in tool surfaces that grow over time.

Vague or overlapping descriptions produce unreliable selection. Not occasionally, not on edge cases. Reliably unreliable, wherever the descriptions don’t draw clear lines.

The Reflexes That Make It Worse

I made this mistake on an MCP server I was building before I had a name for it. A tool would get picked at the wrong moment, and I would reach for the architecture itself: add a mode parameter, split one tool into two, consolidate two others. Architectural moves, sometimes a whole afternoon of refactoring. The descriptions stayed roughly the same, and that was the actual problem. Every time, the fix I needed was just twenty minutes of writing.

Instinctively, most builders gravitate toward architecture before descriptions. But the right move is usually to fix the descriptions BEFORE tinkering with the tool architecture.

A classifier in front of the agent is the most common reach. A small model reads the user’s message and decides which tool to call. It sometimes works, at the cost of doubling the architecture. You now have two systems to maintain and two systems that can disagree. The classifier routes around broken descriptions rather than fixing them.

Few-shot patches are the next instinct. A block of examples in the system prompt shows the right tool for various inputs. They sometimes work, at the cost of tokens per call and a system prompt that grows whenever a new ambiguity surfaces. The descriptions are still wrong, and you have patched the symptom.

Consolidation is the move that feels architecturally clean. Collapse the two tools into one with an entity_type parameter. This is the right move for five GitHub tools that all handle issues in similar ways. It is the wrong move to use lookup_customer instead of lookup_order. Those tools operate on different resources, return different shapes, and have different consequences when called incorrectly. A bad consolidation produces a single tool that requires more documentation than the two clean ones it replaced.

The fix most builders skip is the one the official docs call “by far the most important factor in tool performance.” Rewrite both descriptions so each one explicitly names the other and says when NOT to use it.

What a Working Description Looks Like

Read more

👋 Welcome! I’m Daniel Williams. I write Claude Code for Non-Coders for senior technical professionals who built their careers on technical judgment, stopped writing code years ago, and are now figuring out how AI and coding agents will change their work.

The goal is to keep you as the operator, not the AI’s assistant (“reverse-centaur”), by helping you decide which tasks to automate and which require the judgment that made you valuable in the first place.

I advise clients on AI tools, strategy, and human resilience at dewilliams.co. This newsletter is where I document the patterns, commands, and operator habits that help you grow from babysitting prompts to building reliable systems.

Join 33,000+ senior technical professionals learning the operating discipline that keeps your judgment valuable.

SUBSCRIBE

The careful professional in the meeting wasn’t failing at communication. The org was structurally rewarding confidence theater over judgment. AI is now making the cost legible.

Mats Alvesson coined the term "functional stupidity" in 2016, and it is finally getting the attention it deserved a decade ago. Orgs systematically tax reflexive thinking and reward fluent performance, because frictionless execution looks good in quarterly numbers. The colleague who delivered three confident sentences about alignment got the nod. The careful point, the one with the actual data, and the inconvenient caveat got “parked for later consideration,” which everyone in the room understood to mean never.

Sven Brodmerkel’s piece this week extends the diagnosis to the very people most likely to be reading this newsletter. Senior technical professionals built careers on careful pattern recognition. Many learned to mask it to survive. The ones who couldn’t perform confidence theater on demand became the “difficult” ones, the ones meetings get scheduled without, the ones whose pattern recognition was too sharp for the room to absorb. I’ve watched this play out in client engagements more than once. The person with the careful read on the rollout gets sidelined for the person with the confident roadmap, and six months later, the rollout stalls in exactly the way the careful person predicted, after the budget has already been spent.

The CC4NC thesis names what the system has been hiding. Your judgment is the layer the org de-funded for thirty years, and the AI rollout is about to make the cost show up on the line item. When McKinsey reports that less than 20% of AI adopters see bottom-line impact, somebody has to figure out why. When the 18,000-process automation at the apparel group stops compounding, somebody has to redesign the operating model. The careful thinkers are the only people in the building who can do that work. The org that taxed your judgment will now need it back, and the question is whether you’re still in the room when they ask.

McKinsey just admitted in print that less than 20% of AI adopters see bottom-line impact, and the reason isn’t the models.

Andrei Savine’s analysis pairs McKinsey’s State of Organizations 2026 with HBR’s “Last Mile” diagnosis. One story repeats across both. 88% of organizations deploy AI in some capacity. 86% of leaders say they aren’t ready to embed it in day-to-day operations. The productivity gains that show up locally (250 LLM apps in production at one global bank, 18,000 automated processes at an apparel group, 99% Copilot adoption at a payments network) get reabsorbed into low-value work because nobody redesigned the roles and budgets to harvest the freed time.

McKinsey put a number on it: for every $1 spent on AI technology, $5 should be spent on people. Current spend is the opposite. We funded models, integration, and dashboards. We did not fund the production layer: verification, agent orchestration, role redesign, and the governance that determines whether an AI output touches a customer or a ledger. Savine calls it System 2. Almost no enterprise has built it.

I keep running into a version of this in advisory discussions. The exec team announces an AI program. The engineering team builds the integrations. Six months later, the CFO asks why the line item hasn’t moved, and the answer is always the same: nobody owned the operating-model redesign. The reabsorption pattern in McKinsey’s data matters because CFOs who can’t see a production layer balance the spreadsheet by cutting headcount and calling it an AI transformation. Atlassian cut 10% of staff in March. WiseTech is cutting 29% of its 7,000-person workforce over 18 months. The first companies to cut aren’t the ones with the most AI value to capture. They’re the ones with the least serious operating-model design.

If your judgment is what System 2 looks like in practice, your value just doubled. The question is whether you’re positioned to be the one the CFO calls when the spreadsheet stops working, or whether you’re already on the layoff slate the spreadsheet generated instead.

The $700B consulting industry isn’t being disrupted by AI. Its positioning to capture the production-layer margin that enterprises never funded, and whether it can actually deliver the work it’s now charging for, are open questions.

Pradeep’s analysis of CB Insights’ professional services report reveals what the headline numbers are hiding. McKinsey has deployed 12,000 internal AI agents. Accenture merged five business units into a single “reinvention services” line. KPMG, EY, Deloitte, and PwC have all launched agentic platforms in the past year. AI agent solutions generated over $10B in private market revenue in 2024 and are on pace to more than double in 2025. The orchestration layer (Workbench at KPMG, Refinery at Accenture, EY.ai’s agentic platform) is the product the firms now sell, and the advisor tier is being subsidized to feed it. KPMG’s Global AI Head said it plainly: “We built Workbench as our global architecture to standardize how agents are built, deployed, and monitored.” That is the language of a platform company, not a service firm.

The caveat the announcements skip past is that management consulting has lived in the advisory-recommendation lane for fifty years. The deck got delivered, the partner moved on, and accountability for whether the recommendation actually worked was structurally somebody else’s problem. Owning the orchestration tier is the opposite business model. You stay through implementation, you’re on the hook when the agent breaks the audit, and you eat the margin when the productivity number doesn’t hit. Whether these firms can actually staff to deliver that work, or whether they’re charging platform prices for a service offering they’ve never proven they can ship, is the question every CIO should be asking in the next procurement cycle.

The second question is even sharper. If AI compresses delivery costs by 60-80%, where does the surplus land go? The optimistic read says competition forces firms to pass savings through to clients, and outcome-based pricing makes the lower cost legible on the invoice. The realistic read says firms sell their platforms as proprietary infrastructure, lock clients into multi-year arrangements that look like SaaS and feel like SOW retainers, and keep as much of the new margin as they can for as long as they can. The history of this industry suggests the realistic read wins, which means the orchestration platform pivot is partly a value-capture play wearing platform-economics clothing.

If you’re a senior technical professional inside one of these firms, the question is whether you’re being moved into the orchestration tier or the advisory tier. The traditional pyramid is inverting fast. Lovable hit $100M ARR with 45 people. Anysphere generates over $2M revenue per employee. When clients eventually run at that efficiency, the billable-hour justification collapses, and the firms that survive will be the ones who can actually deliver outcomes they charge for. Internal builders who can own a production layer are about to be the most valuable people in the industry. Everyone else is in the headcount review the spreadsheet is already writing.

The credentials American universities have been selling for fifty years just got reevaluated in real time, and the institution can’t hedge between “formation” and “ticket” anymore.

Amarda Shehu’s piece names what every higher-ed piece this year has been hedging. She’s a computer scientist running AI deployment at a 40,000-student public research university, most of whose students are first-generation. She names what the institution has been doing for two generations: telling the public a story about citizenship and formation while collecting tuition for a credential the labor market reads as a hiring filter. AI is making both stories impossible to hold at once.

The data she pulls together is hard to dismiss. Forrester’s 2026 Future of Work report finds 55% of employers regret AI-related layoffs and projects roughly half will be reversed. The Burning Glass Institute reports the value of a bachelor’s degree has dropped to a thirty-year low. Companies that fired junior analysts last year are quietly rehiring them offshore. Tuition keeps rising. The bachelor’s wage premium is approaching parity with non-graduates, because the entry-level cognitive work the degree was supposed to qualify you for has been absorbed by language models.

Shehu’s answer isn’t a list of safe disciplines. There is no list. The answer is formation: judgment, slow understanding, tolerance for ambiguity, relational capacity under uncertainty. The things that resist automation aren’t subjects. They emerge from sustained encounters with hard problems and the people working on them. The contrarian move isn’t a new AI-literacy curriculum or another interdisciplinary degree. It’s an honest audit of which existing programs actually deliver formation and which deliver only the ticket, and a refusal to keep charging the same tuition for both. The public research university (where a first-generation student can access formation without being born to wealth) has the most to lose if it doesn’t choose, in public, what it actually sells.

If you’re hiring senior people in the next five years, the formation pipeline that produces them is narrowing under you. The same question hits parents with high schoolers at the dinner table. This is the Loop 3 reabsorption question from last week’s dispatch at the institutional level: the careful thinkers orgs will need to build production layers that come from somewhere, and the places that take formation seriously aren’t the ones selling tickets. If the public university spends the next five years studying the question, the formation slot in American life closes, and the only people who get it are those who can pay private-college prices. That’s a much narrower industrial base for the AI economy than anyone in policy circles is acknowledging.

Anthropic just shipped /goal in Claude Code, and it isn’t a chatbot feature. It’s the outcome-specification interface this newsletter has been pointing at since Domain 1.

/goal lets you tell Claude Code what “done” looks like, then walk away while it works across sessions until it either succeeds or escalates. I ran it this week, paired with the feature contract workflow I use on AutomationResilience.com. Wednesday evening, I specified the goal, handed Claude the contract that defined “done,” and went to make dinner for the kids with my wife. By the time we sat down to eat, Claude had shipped the update, and the test suite was green.

This is the operator move at the personal-practice level. Most Claude Code usage is still in task mode: prompt, watch, prompt again, watch again. /goal is outcome-mode: name the contract, let the agent figure out the steps, return when the work is verifiable. The discipline isn’t typing. It’s specifying outcomes precisely enough that an agent can’t drift away from them. That is the production layer in personal practice, the same layer that the McKinsey 5:1 ratio names as missing at the enterprise level. The reason most enterprises can’t see ROI on AI is the same reason most individuals can’t get more than a chat session out of Claude Code: they’re still operating in task-mode when the tool is built for outcome-mode.

If you’re using Claude Code, this is the skillset to build. Most users will treat /goal like a fancier prompt and keep getting fancier-prompt value out of it. The operators will treat it like a contract: a specification of what “done” means, written before they start, that the agent has to satisfy or escalate. The skill that gets harder to charge for over time is task execution. Anthropic just made the second one cheaper to practice, and the gap between people who do it deliberately and those who don’t is widening fast.

Claude Code for Non-Coders publishes Tuesdays and Thursdays. Weekend Dispatch covers AI developments that I find interesting and typically share with friends and family.

Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.

LEADERBOARD

Tokenmaxxing is being sold to every CFO in the country as a discipline. It is the data warehouse mistake that we already learned, painfully, through the late 1990s and into the 2000s, that volume metrics on infrastructure whose underlying value isn’t understood produce confidently wrong decisions and a decade of compression projects on data that should have been deleted. The lesson took fifteen years and several billion dollars of write-offs to absorb then. AI tooling is reproducing it now, and the people building the dashboards have no apparent memory of how the last version of this story ended.

The discipline that worked then is the discipline that will work now: rationalization, not optimization. Agent rationalization means deciding, at the portfolio level, which agents are producing value and which to kill. Compressing prompts on automations that shouldn’t exist is the mistake being made now.

The Last Time We Did This

Through the late 1990s, large enterprises built data warehouses the way large enterprises now build agent platforms in 2025: every team got a pipeline, every system got a feed, every report became a job, and the storage line item compounded quarter over quarter. By the mid-2000s, the CFO noticed. The first response was technical. Compression ratios, columnar formats, tiered storage, partition strategies. Vendors sold optimization. Consultants sold optimization. The cost curve bent for about eighteen months and then resumed climbing, because the underlying problem wasn’t storage efficiency. The underlying problem was that nobody knew which of those pipelines was producing decisions and which was producing dust. Forrester eventually quantified the gap: 60 to 73 percent of enterprise data goes unused for analytics, regardless of how much storage gets optimized.

What eventually broke the cycle were master data management and data rationalization, both euphemisms for deletion. The companies that did this honestly killed 40 to 60 percent of pipelines and reports. The work that mattered ran faster and got governed better. The work that didn’t matter went away. The savings compounded because they were structural rather than technical. The companies that stayed in compression mode spent another ten years optimizing infrastructure carrying low-value freight, and the line item never came down.

Rationalization, done honestly, surfaces underinvestment as often as it surfaces waste. I ran one such engagement at a top-20 global pension fund. The work canceled hundreds of thousands of dollars a year in data licensing the fund didn’t need and identified over $10 million in new and expanded data products and services worth investing in. The client hired me to find savings. They left with something more valuable: a clear-eyed map of where they had been under-investing in assets that actually mattered.

Token spend has the same shape, on a faster clock. Any metric that captures volume of activity on infrastructure whose business value is unclear will produce optimization projects, and those projects will be confidently executed. They will not move the bottom line because the value problem has always been upstream of the volume problem. The vendor ecosystem is already lining up to sell you the optimization layer.

“Tokenmaxxing”

Tokenmaxxing is a meme describing the cluster of practices that confuse the meter for the work. Prompt golf, where engineers spend a day shaving 800 tokens off a system prompt that runs in an automation nobody has audited for outcomes in six months. Compression schemes that pre-summarize context before it reaches the model, on the theory that if the model produces similar output for less input, the optimization is free. Agent harness comparisons that report token efficiency to 4 significant digits and output quality as a sentence. Vendor pitches denominated in dollars per million tokens, as if the unit being purchased were tokens rather than work products. The token-spend dashboard at the CFO level, which is easier to build than a value framework, is therefore the artifact that gets reviewed in the QBR.

Each of these practices shares a particular tell: teams have stopped asking what the agent is for. They have moved to asking how to do whatever it currently does for less. That move is socially comfortable. It produces a number that goes down quarter over quarter, it generates artifacts to put in the deck, and it doesn’t require any of the hard portfolio conversations about whether the automation should exist. It is also, almost without exception, in the wrong layer of the stack.

When a team tells me they cut token usage by a third, the question I ask back is which automations they killed. The answer is almost always none. They have made the existing portfolio more efficient. The portfolio still contains the same number of agents producing the same questionable work product, and the dashboard now reports the spend as down. Five quarters of that and the cost curve resumes climbing, because the underlying portfolio is still wrong.

The buying organization is not the beneficiary of any of this. Tokenmaxxing produces no shipped product, no decision improvement, and no customer value of any kind. What it produces is more token consumption, more sophisticated optimization stacks, and more reasons to keep buying inference. The parties whose interests the practice actually serves are the frontier labs billing by the token, the GPU and TPU manufacturers selling the substrate, and the data centers leasing rack space. Inside the company, paying the bills, tokenmaxxing is a discipline whose primary externality is keeping the meter running. The vendor ecosystem will tell you it’s the responsible thing to do, because for them, it is.

What Agent Rationalization Actually Looks Like

This discipline doesn’t have a name in the current discourse. Search for AI agent governance, and you find runtime concerns: identity, kill switches, policy enforcement, and reliance drills. Search for AI portfolio rationalization, and you find vendors offering AI agents as a tool to rationalize legacy application portfolios, which is a different problem entirely. Search for agent decision frameworks, and you find guidance on selecting the right agent for a use case. The strategic question of which agents in your existing AI portfolio earn their keep, and which ones don’t, isn’t being asked. Call it “agent rationalization.”

The strategic move is portfolio review, not prompt engineering. The deliverable is a list of automations, agent workflows, and recurring AI-touched processes, scored by the business value they produce rather than the tokens they consume.

A professor I had in grad school taught us a framework I have used ever since. Every project a company invests in has to fit one of three buckets: generate revenue, reduce costs, or increase efficiency. If it does not fit cleanly into one of those three, the question is, why are we doing this? Apply it to your AI portfolio, and the answers come quickly. An agent that drafts proposals that actually win deals fits the revenue bucket. An agent that handles a class of tickets that used to require headcount fits the cost bucket. An agent that compresses a review cycle from a week to a day fits the efficiency bucket. An agent that produces an artifact nobody files, summarizes meetings nobody acts on, or runs every night because someone built it once and forgot fits none of them. That last category is where most token spending ends up when nobody is asking the question.

The bottom third of the portfolio gets retired. The middle gets re-evaluated against a sharper version of the original brief. The top gets resourced more aggressively than current spend, because the constraint on those agents is judgment and design, not token budget. Most rationalizations I have run have produced both directions of recommendation in the same deliverable: cuts to the work that wasn’t earning its keep, and increased investment in the work that was producing real value but was under-resourced. The same logic applies to agents. Useless AI initiatives don’t survive a rationalization. Value-generating ones come out the other side with more resources, not fewer. Token rationalization is a sub-discipline of agent rationalization, applied to the portfolio that survived the test. The compression and prompt optimization completed at that point are legitimate work. Done before the portfolio review, they are tokenmaxxing under a different name.

The senior person doing this work has to be willing to say which automations are not pulling their weight, which is socially harder than saying which prompts can be compressed. The shift the work asks of you is from someone who manages AI inputs to someone who governs an AI portfolio. That’s the discipline that scales with seniority, and it’s not the one a token-spend dashboard will ever measure. Most organizations will choose the easier framing because it produces clean numbers without making anyone defend their pet workflow. The companies that take the harder path will end up with smaller, sharper agent portfolios and better cost discipline three years out, the same way the companies that took the harder path on data ended up with smaller, sharper data estates.

The senior technical professionals reading this newsletter are who this work falls to, because nobody on the prompt-optimization track is going to surface it. The token-spend dashboard is being installed in your finance org right now, or it will be by the end of the year. The question to bring to the next portfolio review is not how the tokens are trending. It’s which of these agents produced work in the last quarter that someone actually used, and what would happen if you turned the others off tomorrow. That conversation is harder to have than a compression ratio, and it’s the only one that ends in a different cost curve.

If you run an AI portfolio of any size, do this one exercise this quarter: list every recurring agentic workflow your organization runs, and for each one, name the decision it informs or the artifact it produces. The ones you can’t name go on a list. The list is your starting point.

Subscribe now

Tokenmaxxing is a dead end as AI prices rise with each new model release. Learn to architect around the uncertainty: AI Prices Are Going Up. Your Architecture Is Your Hedge. — New here? Start with the map: The Claude Architecture Series.

Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.

Claude Code for Non-Coders publishes on Tuesdays and Thursdays. If you found this useful, share it with someone who’s about to install a token-spend dashboard.

Leaderboard

This is the second half of the Domain 1 Capstone. Last week, we wired the agent. This week is how production agents survive the work.

You built the agent. The Domain 1 capstone walked through the wiring: the loop that runs while Claude works, the PostToolUse hook that normalizes data before the model sees it, and the PreToolUse gate that blocks policy-violating tool calls. That’s the part that takes the most time to explain because most people haven’t seen it. It’s also the part that takes the least time once you’ve seen it. Once the wiring is right, it’s done.

Production agents have to do three more things that the wiring alone doesn’t address. They have to know what they’re for, without you re-explaining every session. They have to handle work that doesn’t fit cleanly into a single prompt. They have to survive the gap between Friday afternoon and Monday morning, across machines, across colleagues, across the closed laptop.

The capstone repo has all three. Same agent, same hooks, same MCP server. Three more architectures are sitting around them.

The Persona Defines the Job, Not the Job Title

The agent persona for the capstone is a 41-line markdown file at .claude/agents/support-agent.md. It declares which of the five MCP tools the agent is allowed to use, the refund policy in plain language, the expected tone, the date format the agent can rely on, and the workflow shape. The frontmatter at the top declares the model and the tool list; the body is prose for the agent to read at every session start.

The first instinct most builders have when they encounter this file is to name the agent like a human role: “Senior Customer Support Agent,” “Compliance Officer Agent,” “Senior Data Analyst Agent.” This is the wrong instinct, and it’s the most common mistake people make when they first encounter subagents. The persona file isn’t a job title. It’s the substance of a job description: what the agent is for, what tools it has access to, what the boundaries are, and what outcome it owns.

A real job posting doesn’t lead with the title. It leads with responsibilities and scope. The title gets applied last, often arbitrarily. The persona file is what the title would be at a real company once HR translates the actual work into a label. Skip the label. Write the work.

The wrong instinct produces persona files that read like LinkedIn profiles (”results-driven senior agent with 10+ years of experience”) rather than operational specs (”uses these five tools, follows this workflow, escalates these cases, never bypasses these checks”). The first kind doesn’t help Claude do the job. The second kind does.

There’s a second thing the persona file does that’s easy to miss. It declares contracts with the surrounding architecture. The capstone’s persona has this line: “Order dates always come back in ISO 8601.” That sentence is not true at the data layer. The orders.json file has Unix epoch integers, MM/DD/YYYY strings, and ISO 8601 mixed together. The sentence is true because the PostToolUse hook converts every date before the model sees it. The agent prompt can rely on a clean schema because programmatic normalization sits between the data and the prompt.

This is the relationship between persona and architecture. The persona says what the agent expects. The hooks make that expectation true. If the persona declared a contract that no hook enforced, the agent would behave one way most of the time and another way at the wrong moments. Hook-backed contracts are the only kind that hold.

The persona is the job description. The hooks are the compliance department. Both are written, both are operational, and neither replaces the other.

Decomposition Lets It Work at Scale

Most demos run in Claude Code without a separate Anthropic API key. The loop demo is the exception: it calls the Anthropic API directly to expose the stop_reason mechanic that Claude Code normally hides.

If you don’t have a standalone API key, that one step gets skipped, and the rest still runs. Get one at console.anthropic.com. It takes about five minutes. Once you have it, set it in your terminal before running the scripts:

export ANTHROPIC_API_KEY=sk-ant-...

The same five tools that handle one customer’s refund request can audit all three customers’ refund patterns. How you orchestrate the audit determines what it actually finds.

The seeded data has 3 customers, 30 orders, 9 refunds, and 8 ground-truth patterns to surface. The audit_demo/ folder contains two scripts that approach the same audit in different ways.

Single-pass (audit_single_pass.py) dumps every customer’s orders and refunds into one prompt and asks for the full analysis at once. This is the way most people instinctively approach the problem. It finds the headline patterns: Alice’s March cluster, Bob’s clean record, Carla’s high refund rate. It’s fast, it’s coherent, and it consistently misses two or three of the eight planted patterns because the model’s attention dilutes across 30 orders and 9 refunds.

Multi-pass (audit_multipass.py) spawns three parallel workers, one per customer. Each worker runs its own stop_reason loop, calls the tools to fetch only its customer’s data, and produces a structured audit section. After all three are complete, a synthesis call reads only the compressed findings (not the raw orders and refunds) and produces the final report.

Both versions find the headline patterns: Alice’s March cluster, Bob’s clean record, Carla’s high refund rate. The interesting part is what only the synthesis step can see.

In testing, the multi-pass synthesis produced observations neither single-pass nor any individual worker surfaced:

- Alice's pattern is a burst-abuse model: four refunds in six days. Carla's is sustained selective extraction: every refund targets a delivered, high-value order ($480–$720); no low-value order has ever been disputed. Two distinct fraud archetypes, requiring different responses. Visible only when both accounts are compared.

- The $500 approval threshold is structurally visible to customers. All three accounts have at least one refund in the $400–$499 band, each individually sub-threshold, each avoiding the manager-approval gate. Single-pass flagged the pattern for one customer. The synthesis produced a cross-customer comparison table and named it threshold structuring.

- manager_approval_flag is non-functional as a control in all three cases, for different reasons. Alice: never set despite four refunds in six days. Carla: set but didn't stop ongoing activity across seven months. Bob: not set on a watchlist account. Each worker found its own case. The synthesis connected them.

These aren’t faster findings. They’re deeper findings, and two of the three only exist at the synthesis layer, where no single worker had the full picture. Multi-pass costs more tokens than single-pass, roughly three to five times more in practice, which is the same overhead laid out in Lesson 1.6. The point of multi-pass isn’t speed. Its depth.

The pattern is the same as the per-file analysis pattern from Lesson 1.6: each item gets undivided attention in its own context window, and the integration step reads only the compressed signal. Production agents that audit, summarize, or compare across many items without this pattern will produce thinner findings than they should. The pattern that matters is sometimes the one that requires every account to be considered fully, then compared.

The Session Model Survives the Closed Laptop

Real cases don’t finish in one sitting. The Alice / ORD-1002 investigation that the capstone uses for its refund-bypass demo is exactly the kind of investigation that gets paused over a weekend and resumed Monday morning, sometimes on a different machine. The capstone’s session_demo/ folder has three scenarios, all on the same investigation, each demonstrating a different resumption pattern.

scenario_1_continue.md walks through the simplest case. Investigate Alice’s refund cluster on Friday afternoon. Step away. Come back Monday morning, same machine, same folder. Run claude --continue. The full session loads. Claude references the March cluster without re-fetching anything.

This works because the session is recent and the context window can hold the whole transcript. It breaks down exactly the way Lesson 1.7 said it would: past a certain size, reloading the full transcript actively degrades the next response. For investigations that finish within a session or two, --continue is the right tool.

scenario_2_fork.md walks through a different problem. The investigation is done. The manager has approved the refund. Before issuing it, you want to see two outcomes from the same starting point: the approved branch (issue the refund) and the denied branch (draft the escalation email instead). Both branches share the parent’s context up to the fork; after the fork, they diverge. The parent session stays untouched.

What catches experienced builders here is what fork doesn’t do. It doesn’t fork the filesystem. If the approved branch issues the refund and writes to refunds_log.json, the denied branch starts its work, seeing that change. The mandatory step between branches is to reset the log with python3 audit_demo/reset_refunds.py. The reset is the lesson. Forks branch the conversation, not the disk.

scenario_3_fresh_brief.md walks through the cross-machine, multi-day case. You finished Friday on the office laptop. Monday you’re on the home desktop with no shared session state. The handoff brief at scenario_3_fresh_brief.handoff_brief.md looks like this:

# Investigation handoff: Alice Chen / ORD-1002

## Subject
alice@example.com (CUST-01, Pro tier), refund request for ORD-1002 ($612.00, "shipping damaged", March 15 2025).

## Findings
- Manager approval flag is FALSE; refunds over $500 require manager_approved=true (enforced by PreToolUse hook)
- Refund history shows a 7-day cluster (March 14–20 2025): 4 refunds totalling $1,212
- 3 of 4 cluster refunds lacked manager approval; policy oversight gap flagged

## Outstanding
- Manager verdict: APPROVED (shipping damage documented in carrier report)
- Action needed: call issue_refund for ORD-1002, amount $612, reason "shipping damaged (carrier documented)", manager_approved=true
- Confirm entry in refunds log

The brief is about 200 words. It contains the case facts, the findings, and the outstanding action with the exact tool parameters. New session, no flags, paste the brief, ask Claude to continue. Claude re-fetches what it needs and processes the refund correctly.

This is the doctor’s handoff pattern from Lesson 1.7. The transcript has hundreds of turns. The brief has twelve lines. The brief preserves the signal; the transcript preserves the noise. For long gaps, cross-machine work, or any handoff where the session itself can’t travel, the brief is the right tool.

The three patterns sit on a single axis: how much context survives the gap.

What Operating Looks Like

The capstone wired the agent. These three architectures are how it operates.

Without persona, every session re-explains the agent and its workflow. Without decomposition, work that needs depth across many items produces shallow output. Without a session model, every gap loses context that the next session has to rediscover.

With them: production AI, not toy AI. The agent knows what it’s for, scales to work that doesn’t fit one prompt, and survives the gap between when you started and when you came back. The wiring you did in the capstone holds because these three sit around it.

Domain 2 starts on Tuesday, May 26, and the paid tier opens then. The five tools the support agent uses (lookup_customer, get_order, list_recent_orders, list_refunds, issue_refund) each had to be designed before the agent could pick the right one. The design choices aren’t obvious. Builders who skip them produce agents that pick the wrong tool and can’t explain why.

The Founding Member tier opens Tuesday, capped at the first 100 readers: $200 a year, the price holds as long as the subscription stays active. Standard paid pricing applies after. Domain 1 stays free for everyone, including this two-part capstone.

Domain 1 wired and operated the agent. Domain 2 makes the operation reliable.

The full repo for this build is at github.com/danieleugenewilliams/cc4nc. The audit_demo/ and session_demo/ folders have the demos this article walked through, with verification tests in verification/. Same paste-into-Claude-Code prompt as the capstone; it walks through the loop and hooks, and the audit and session demos run directly from the command line.

Subscribe now

One of the most overlooked aspects of agent ops is understanding why agents make silly mistakes that cost you in tokens and money. That’s one of the areas I walk you through here: Your Agent Hallucinated a Recovery. Your MCP Tool’s Error Response Asked for It. New here? Start with the map: The Claude Architecture Series.

Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.

Claude Code for Non-Coders publishes on Tuesdays and Thursdays. If you found this useful, share it with someone who’s been building agents and wondering what changes once they go to production.

Share

This is the first CC4NC Weekend Dispatch, a free, feed-only roundup of the week’s most important AI developments through the strategic builder’s lens. Short, reactive, and designed to keep you current without adding to your inbox.

OpenAI, Anthropic, and Google just spent $5.5 billion hiring consultants and calling them something else.

They’re calling them “Forward Deployed Engineers” (FDE). The price tag is $10K/day. The job is to sit inside your company and make AI work for you. As one commenter put it: “I have about 20 years of experience as a forward-deployed engineer, we used to call them consultants.”

OpenAI launched a $4 billion deployment company and acquired Tomoro to staff it with 150 FDEs. Anthropic raised $1.5 billion with Blackstone and Goldman Sachs for the same play. Google is recruiting hundreds more. EPAM is certifying 10,000 Claude architects. Aaron Levie calls it one of the most in-demand jobs in tech.

Allie Miller got closest to what everyone else is dancing around: external FDEs won’t make your company AI-first. You can customize the deployment and still have your employees avoid AI and distrust every leadership decision around it. Her Salesforce analogy: you can customize the implementation, but that won’t make your sales team fix their data hygiene.

Platforms are going headless because customers have already picked their agents elsewhere. Salesforce tried Agentforce. Notion tried Notion AI. People used Claude or ChatGPT instead, because nobody wants to learn a different agent for every SaaS tool they touch. Salesforce launched Headless 360 in April: 60+ MCP tools that let your agent of choice operate the platform without a UI. Notion shipped its developer platform on Tuesday with Workers, Database Sync, and external agent support. The platforms aren’t competing to be the agent anymore. They’re competing to be the substrate the agent runs on.

Your client already has Claude Desktop. They already have Codex. I frequently recommend Claude Desktop to clients, friends, and family members. My cousin started using Claude Cowork and found tens of thousands in change order value from an electrical spec on day one. No FDE. No SOW. What we discussed afterward was the architecture he couldn’t build himself. If your value disappears when the client opens a $20/month tool, you’re not selling expertise. You’re selling navigation through complexity you could have simplified.

This bifurcates the FDE play. Simple integrations and happy-path workflows go to the frontier lab-released skills, SaaS MCP connectors, and the desktop agent that the buyer already pays for. The hard cases are messy data, cross-system architecture, and domain logic that nobody wrote down. Those need humans with context: call them FDEs, call them consultants, call them internal builders with the skill and authority to make it work. Every company with legacy systems and compliance burdens genuinely needs that help. The $5.5 billion bet is reasonable for the hard half. The risk is that most buyers can’t yet tell which half they’re in.

Remove all the code from your app. Give the raw input directly to an LLM. Is the output roughly the same?

That’s Karpathy’s test. He ran it on his own product, and it failed.

He built Menu Gen: a photo of a restaurant menu goes through OCR, an image model generates pictures of each dish, and the app re-renders the menu with food photos next to every item. Full pipeline. Deployed on Vercel. Someone gave Gemini the same photo with one prompt: “overlay pictures of each dish onto the menu.” Gemini returned the original menu with food images rendered directly into the pixels. One prompt. The entire app is unnecessary.

I ran this test on two of my own products. One passed cleanly; the knowledge maturation pipeline does things no single prompt can replicate. The other was closer to the line than I expected.

The 20% that survives has to be something the model genuinely cannot do: persisting state across users, enforcing access controls, processing payments, connecting to hardware. If your 20% is “better formatting” or “a nicer UI,” you’re in the 80% that’s about to get compressed. Run the test before the market runs it for you.

Video: Karpathy discussing his app getting oneshotted

Citrini’s “No Natural Brake” diagram includes a brake. They drew it and forgot to label it.

Citrini Research published “The 2028 Global Intelligence Crisis,” a fictional memo from June 2028. The diagram went everywhere: AI improves, companies need fewer workers, layoffs increase, displaced workers spend less, the economy weakens, and companies invest more in AI. Stamped across the top: “No Natural Brake.”

Displaced workers spend less. The economy weakens. That is the brake. Agents don’t buy coffee or pay rent. The income has to flow to someone who does. When it stops flowing, consumption collapses. When consumption collapses, revenue disappears. When revenue disappears, nobody is funding the next round of AI investment. The brake isn’t gentle: it’s a recession. But it exists.

The strongest objection is that automation could close the loop without consumers at all. Wealthy investors fund automated B2B chains supplying other automated businesses. Capital cycles through machines that never needed human spending in the first place. The Thiel/Yarvin enclave scenario. It’s the most coherent version of “no brake,” and short of an authoritarian solution to the political problem, it can’t run at a steady state. Capital is only valuable to the extent it commands real goods, services, or political power. Pure capital-serving-capital resolves into paper wealth nobody can redeem. The closed loop is a transient: it lasts as long as investors keep funding the bet, and breaks when they notice revenue isn’t materializing or when joblessness becomes politically untenable. Reabsorption isn’t just morally preferable. It’s the only durable equilibrium short of authoritarian enclosure.

The real question is speed. Does the acceleration hit the demand brake before or after the labor market adjusts? History suggests markets do adjust: new roles absorb displaced workers, but only if there’s a reabsorption mechanism. That mechanism is the third loop Citrini left off the diagram: displaced workers who learn to define and architect outcomes rather than execute tasks. Forrester found 55% of employers regret AI-related layoffs. The companies that cut too fast didn’t lose friction. They lost the judgment that knew when the AI output was wrong.

If you’re reading this newsletter, you’re building the skills that put you in the third loop. The question is whether enough of the labor market gets there before the brake kicks in.

Nvidia is running the mineral rights playbook with silicon instead of coal. You should want to own the compute, not rent out your wall.

Nvidia and PulteGroup are installing XFRA nodes on residential properties. Liquid-cooled, fanless GPUs mounted on exterior walls. Deploys 6x faster and 5x cheaper than building a data center. The homeowner provides the wall, the electricity, and the network connection. Nvidia keeps the compute revenue. The homeowner gets a discount on their electric bill.

In Appalachia, homeowners owned the surface while coal companies owned the mineral rights. The wealth left the community. This is the same structure with a different commodity.

The alternative exists. A Raspberry Pi 5 running open models handles routine inference for $150. Frontier APIs handle the complex reasoning on demand. One of my readers runs three AI systems, coordinated through LocalMemory on a Pi 5—Claude and two open-source models, that share a unified knowledge layer. Not theoretical. Running in production.

Most homeowners can’t set up a home server today. But most homeowners couldn’t set up a home network in 2003 either. The infrastructure will get easier. The question is whether you’re positioned as the owner or the tenant when it does. The internet followed this arc: mainframes, client-server, cloud, edge. AI is following. NVIDIA is building step 3. The people who set up step 4 own their data, costs, and independence from providers that can change pricing overnight.

The portable layer this piece is about, the config you can hand to a different model tomorrow, is the paid build: Stop Treating MCP as Tools. It's Your Architecture. New here? Start with the map: The Claude Architecture Series.

Claude Code for Non-Coders publishes Tuesdays and Thursdays. Weekend Dispatch covers the week’s biggest AI developments through a builder’s lens.

Daniel Williams advises clients about AI tools, strategy, and human resilience at dewilliams.co.