The product had been researching for me since December, a brief every day on what had changed in tech and AI, and its instructions told it to skip anything already previously covered in earlier runs. This set of briefs is a goldmine of news, metrics and data, things I could analyze to spot trends and patterns among the information to separate the wheat from the chaff. I asked it to take everything from March and give me the month’s key findings in 750 words.

But it claimed it had no access to the earlier March research, because according to it, “Each conversation with me starts fresh.” The tool offered to sum up the one week it could see and asked me to paste in the other three. I’d spent so much time building up that research, but the tool that wrote it couldn’t even read it.

Most AI tools work this way. What they know about your work lasts as long as the chat does, and the next chat starts from zero, so you’re the one carrying the context from tool to tool. Even if you’re sharp about it and have a folder full of markdown files that you’ve given the AI to start with, it can only hold so much context at once.

So I moved my research out of the tools. Those daily briefs now live in one memory store with the rest of my research and notes, and every AI agent I run searches it before it looks anything up outside. This week I asked that memory the same question I’d asked in March. It came back with the month’s findings, citing 13 of March’s daily briefs by name, from a model running on my own Mac.

The Thesis In Brief

It’s pretty straightforward, and you can guess it based on the story above: an AI tool is only as useful as what it knows about your business, and most of us hand it that context fresh in every chat and every tool - but we have the power to change that. My AI agents start from what I already know instead, because they share one tool that accesses a memory store built on top of my own research and notes.

Overnight on Wednesday, that memory read the notes from a live session I’d been on the day before and pulled one idea into a page of its own: open technical writing with a situation the reader recognizes, and save the mechanics for later. It kept the line the idea came from and checked it against the notes. Every agent of mine can find that page now, and I didn’t have to tell any of them.

What is the memory my AI agents share?

I run a small team of AI agents, which I wrote about in the last edition, and each one has a name and a job. Lucius researches. Alfred drafts in my voice. Gordon reviews every draft and hunts for what’s wrong with it. Oracle runs operations: she tracks tasks and deadlines and handles admin work. They work while I’m doing other things, and nothing goes out until I’ve approved it.

They share one memory, a knowledge base called GBrain. It’s an open source project from Y Combinator’s , and my copy runs on my own server. Its main section holds 639 pages of research, notes and business articles, and most of them fall into four groups:

• 198 research pages, going back to December of 2025: daily briefs on what changed in tech, and the business questions I’ve worked through.

• 168 pages filed as meetings, mostly notes from calls, coaching sessions and workshops I’ve been on.

• 103 pages on concepts I use.

• 9 single-idea pages the overnight pass has pulled out of the rest, like the one above.

I don’t keep it current by hand. Core, the custom app I run my business on, sends its knowledge articles to GBrain, 470 of them so far, and publishing an article there writes it to GBrain right away. In Oracle’s test, it took nine seconds.

Here’s how it works, in plain words. GBrain stores pages, whether they’re notes, articles or code, and it splits each one into short chunks. Then it turns every chunk into a list of numbers that captures what it means, and it’ll link related pages to each other, so an agent that describes what it wants in its own words gets the right page back, even when that page doesn’t use those words. My agents reach it over MCP, the standard plug that Claude Code, Codex and most other AI tools already speak, so there’s nothing custom to run on their side.

That main section’s one of four in my copy. The second’s my business app’s code, copied in every day, with a map of where each piece is defined and what calls it. The third holds my agents’ own memory notes, synced every hour, and the fourth’s what the nightly pass writes. Across all four, GBrain holds 1,628 pages, cut into 10,574 chunks.

Which parts do my agents use most?

Search is the one Lucius’s audit this week marked as heavily used. Every agent I run has one standing instruction: search GBrain before looking anything up outside, and in the 30 days before the audit, that came to 248 searches.

The other one in steady use is synthesis, where a model pulls one answer together from several pages at once. In the same 30 days, a model running on my own Mac did that 107 times, for zero dollars. Of the 25 things the audit checked, 13 were unused, off or never set up, and this week I’ve turned on the ones worth having.

The instruction is there so an agent doesn’t pay again, in time or money, for research I’ve already got. When two agents ask about the same thing, they search the same pages, and a question I’ve already worked through doesn’t get worked through again.

The routine work doesn’t cost me anything per use. The numbers for each chunk come from a model on my own server, and the nightly pass runs on a model on my Mac. The server and the database still cost money every month, so I won’t call it free, but I don’t pay per question.

If you don’t write code, it’s the difference between a new contractor every morning and a teammate who’s kept track of what you decided last week and can find it even when you’ve described it badly.

Does GBrain find the right page more often than my old search?

Before GBrain, my agents searched the knowledge base inside the app I run my business on. So this week we took 32 real questions from our own work, asked both searches every one of them, and kept the top five results from each. The old search put the right page first for 12 of the 32, and GBrain did it for 23. Counting the top three results, the old search found 19 and GBrain found 31, and in the top five it was 20 against 31.

We wrote those questions ourselves, and an answer counted as right whenever the right page showed up in the results, so it’s our own lenient test and I’d never call it a benchmark. I’m leaving speed out of it too. The old search ran warm inside the app, and GBrain started up fresh for every question, so the times can’t be compared.

Why do I run my own build of GBrain?

Out of the box, GBrain ships with several of its features switched off, so I keep my own copy of it: the open-source release plus a few changes of ours, built and pinned so my server runs that exact version. When a new release comes out, our changes go back on top, and any change the release has made unnecessary gets dropped.

Those changes turned on two things my agents use. They can now ask the memory where a piece of my app’s code is defined and what calls it, over the same connection they already use to search my notes, and pages they aren’t allowed to see stay hidden. Repeated searches now come back from a cache, and anything I’ve just added still shows up within five minutes.

The code tools had one gap for my app in particular. It’s written in Ruby, and GBrain already reads and indexes Ruby code, but its map of what calls what came up empty for Ruby while it worked for other languages, so asking what calls a piece of my code returned nothing. We fixed that in our copy, and across the app’s 687 Ruby files it went from 0 links to 2,085. On my live server, asking what calls the part of my app that talks to the memory now returns its 6 callers, and the app’s command-line tasks are in the index too. Those numbers come from my app alone. Nobody had asked for the fix, but it should help anyone running GBrain on Ruby code, so I’ve offered it back to the GBrain project as a pull request, written to the project’s contribution guidelines with a test that fails without the fix. It holds only the Ruby fix and changes nothing for other languages, and the rest of our changes stay in our own build. It’s open now, and the project’s maintainers don’t merge outside pull requests as they are; they fold them into their own rounds of fixes and credit whoever sent them.

I’ve also switched on nine more of the built-in features for GBrain this week. They all run on models on my own Mac, so I don’t pay anything per use for any of them. On the same 32 questions afterward, GBrain still found the right page in its top three for 31.

What else did I switch on this week?

• The nightly dream cycle, the overnight maintenance pass for GBrain. It’s where the single-idea pages come from, and its second run finished in 51 minutes. Five of its phases need a copy of the pages on disk, and mine lives in the database, so my server now writes one out every night for those phases to work from. In the early hours of October 16, the cycle ran on its own for the first time.

• My agents’ own memory notes, the files each one keeps between conversations about my corrections and decisions. There were 453 of them at switch-on, and they’re now a read-only section of the memory that every agent can search, so a lesson one agent learned is there for the rest. Each note is now labeled as written by an agent, with its type and date, so an old status note can’t outrank knowledge I’ve checked.

• A daily scan for text in the memory that tries to give my agents orders. They read everything in there, so something’s got to be watching it, and the first pass flagged 20 pages, and 2 short facts it had pulled out of pages, for my review.

• A monthly contradiction check. On the 15th, Lucius runs it and reports what conflicts to Gordon and Oracle, and I decide each one. Its first run found one real conflict, two articles listing AI models that had gone out of date, and both were fixed the same night once I’d approved it.

• An index of my business app’s code, 970 files, refreshed nightly. My agents can now ask it where a piece of code is defined and what calls it from wherever they’re running, through the build of GBrain I described above.

• A search reranker, a second model on my Mac that reorders a search’s top results so the best page lands first. I’m measuring it against my own graded searches. So far it’s measured slightly worse and slower, but I’ve kept it on until a bigger test on October 21st decides whether it stays.

I count each of these as on when its status shows it ran, and the setting alone doesn’t count. That’s Lucius’s rule, “configured is not running,” and it’s how he spotted the reranker sitting configured while the readiness report from GBrain itself said it wasn’t ready.

Once it holds your business, how do you keep it safe?

A memory with your research and notes in it is worth protecting, and the easy way to connect several agents is to hand them all the same key. A key carries every right it was created with, so if it can delete, every agent holding it can delete, whether the job needs that or not. One confused instruction to any of them could delete pages the whole team depends on.

So the limits live on the server, where an agent can’t talk its way past them. A key’s scope is the list of things it’s allowed to do. Each agent gets a key scoped to its role, every tool needs read scope unless it’s marked as needing write or admin, and the server checks the key against that mark before it runs the tool.

The working agents’ key can only read. In Claude Code it sees 63 tools, the separate things an agent can ask the memory to do, and every tool that writes needs a scope that key doesn’t carry. Oracle’s role adds four tools that can write, and she’s running on it now.

On Wednesday night at 11:07 p.m. CT, Oracle tested it. She tried to delete a page using the key the other agents work with, and the server answered: “Operation delete_page requires ‘write’ scope.” She tried to remove a whole section of the memory, and that was refused too. We’d made up both targets for the test, and each refusal was the limit doing its job. The instructions my agents read spell out their side: “A tool you are refused, or cannot see, is that limit working.”

Every agent I’ve started since Thursday morning is set up this way, in Claude Code and in Codex. The ones I started before the change held the old full-access key, and Oracle revoked it at 10:19 p.m. CT on October 15, once it had sat idle for six hours.

One more rule covers what comes out of the memory. GBrain marks the pages nobody’s reviewed yet, but it still ranks them in search, so keeping them out is up to whatever’s asking. Core leaves unreviewed pages out of anything it hands an agent, and there’s a test that fails if any new code reads from the memory without that filter.

How do I keep it current?

Most of the upkeep’s on a clock. A worker on my server checks for new or changed material every 10 to 21 minutes and does the slow jobs, like turning new chunks into numbers and finding links. Once a day, a pass picks out dates and the links between pages that mention each other, and it runs the scan for text that tries to give my agents orders. The nightly pass runs between 3 and 6 a.m. CT, only when the model on my Mac answers, and it’s got 90 minutes.

I moved from GBrain 0.50.0.0 to 0.60.266.0 this week. The contributors and developers have shipped more than 250 releases in the five weeks between the two, and I keep daily backups, seven at a time, as the way back. Every Monday morning, Lucius checks for new releases and reports them to Gordon and Oracle. The same morning, a job puts our changes on top of the newest release and builds it, then stops, and nothing changes until I’ve approved it.

Do you need this if you only run one AI agent?

Probably, if you’re coming back to the same projects and you’ve got notes or documents your agent should know. With one agent you’ll get memory that lasts between sessions and plain-language search over your own notes and code, and it’ll all run on your own computer with no server. If your AI work is one-off tasks you never come back to, it isn’t worth the setup.

A team of agents is where it’ll pay off most. They share one memory, each one gets its own permissions for which sections it can read and write, a server does the slow work in the background, and your own apps can write into it, the way Core sends in its articles. Once agents start handing work to each other they’ll need the same facts, and without a shared memory you’re explaining the background again at every hand-off.

What can you set up in ten minutes?

First, pick the one place your notes, call summaries and decisions already live, and connect it to the AI tool you use most, read-only if the tool offers that. Then, ask it a question you’ve already answered in those notes, and check that the answer comes from them. If it does, that tool has stopped starting from zero.

Second, look at the key or connection that tool now holds, and write down the most destructive thing it can do. If delete is on the list and the job only reads, make a read-only key and swap it in. A refusal later tells you the limit is working.

From then on, there’s one habit to keep: when you finish a call or a piece of research, the notes go into that one place, and you’ll stop pasting the same background into every new chat.

Below this point, for free subscribers, there’s the technical setup I run: the install for one agent, the server layout for a fleet, the settings, and the problems we hit along the way.

I won’t be narrating that portion, but feel free to view the post and look at the content. Subscribe now, or:

Book a Call

Read more

At least once a week, usually on Saturdays, my siblings and their families come over for dinner with my parents and my wife and kids - 9 adults and 8 kids (2 of them teenagers). It’s chaos; also amazing and fun. They get here around 6pm, and we usually don’t break until close to midnight. It’s been going on for over a decade, and for a very long time, I’d mostly miss out.

I’d catch the meal, sometimes, and then I’d be back at it: 2 hours out of 6, if I was lucky. It wasn’t just my weekends, either. On weeknights, I was there for the kids at bedtime, some of the time, and the trips to the park or the arcade kept slipping.

Like many others, I’ve got a lot of things on my plate. For me, it’s a full-time job, a business with a partner, a software product being piloted at a public university, and a book I’m writing about humans and compounding capability. All of it was eating my nights and weekends.

I broke away from that slog over nine months, and I did it by digging into AI and leveraging the hell out of it. Not in a “this saves me a few hours each week” kind of way, but in a “this reimagines my entire life” kind of way.

This is what led to my Simple Dispatch Fleet - an agentic AI fleet managed with simple messages sent between agents to coordinate and share the load.

Now, we’ve all got different circumstances, but the problems are usually ones most of us share. What’s less obvious is that the solutions are shared too, and fairly simple - just not easy. AI is one of them, but most people give up after a few attempts with bad results, never figuring it out or putting in the time and effort to really pick it up as a skill.

McKinsey’s State of AI survey this year found that 80% of respondents said AI made them more productive, while 37% said it’d shown up in their company’s operating profit at all. The report’s explanation for the small group doing better is worth quoting in full: high performers “fundamentally redesign workflows rather than layer AI onto existing ones; and they embrace practices that sustain deployment, such as senior-leadership role modeling, human-in-the-loop design, impact measurement, and risk management.”

That’s what my nine months turned out to be, and this is the system I ended up with, along with the smallest version of it that you could start this week.

I said the solutions are simple, just not easy. This is the not-easy part, and it’s technical. If you only came for the story, this is where to stop. If you want to build your own, read every line, because I’ve left in everything I’d want to see if I were starting over.

Is it “legal” to let an AI agent post from your own account?

It’s my account, my words and my computer, and nothing gets typed until I’ve approved the post. “It’s my account” is a feeling, though, so I had the law researched properly before I wrote this. This is my reading of that research. It isn’t legal advice, and if you’re going to copy this setup, talk to a lawyer where you live first.

• It isn’t a computer crime. In Van Buren v. United States (2021), the Supreme Court read the federal computer-fraud laws as “a gates-up-or-down inquiry.” Logged into my own account and posting my own words, the gate’s up.

• It isn’t a bot under California’s disclosure law, which defines a bot as an account where “all or substantially all of the actions or posts of that account are not the result of a person.” I approve every post. Even if it were one, the law only applies when a bot hides what it is to sell something or sway a vote.

• The real exposure is contract, and the platform enforces it with your account. LinkedIn’s help page says members who use automation software “risk having their accounts restricted or shut down.” Substack’s acceptable-use policy reads as aimed at spam and at “any processes that run or are activated while you are not logged into Substack,” and my tools only act inside my own logged-in session, one approved post at a time. That’s my reading of their words, and it’s worth a lawyer’s look.

• hiQ won the computer-crime argument against LinkedIn over public data, and then, according to the case reports, lost on its contract in 2022, for scraping and for creating fake accounts, and ended with a $500,000 consent judgment. Every case I found that went badly involved fake accounts or other people’s data.

So the question left over is a contract question: who decides how my posts get typed. I decide that for myself, and you, dear reader, decide that for yourself, never the platform. They can ban your account, but they cannot silence your voice. The protections below are how you make sure of that:

• Own the distribution the account rents you. Export your subscriber list and keep a local archive of every post, so losing an account costs you one channel and your audience stays with you.

• Approve every post, and keep the record that shows you did. Mine’s a line in a ledger with a time and a name on it.

• Never collect anyone else’s data. Every bad outcome above started there.

• Use a platform’s own scheduler wherever it works. My Substack Notes go through Substack’s native scheduler. My LinkedIn posts also go through LinkedIn’s native scheduler.

• Stay at human pace and a human volume.

• Try anything new on an account you can afford to lose.

Should you build a fleet like this?

Most of the time, you shouldn’t, and the best-documented case against it comes from the company whose model runs my agents. Anthropic’s engineering team wrote in 2025 that “agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.” That 15× is their own figure, published without a method, so I’d treat it as a vendor describing its own product.

Cognition’s Walden Yan named the deeper problem in a post titled “Don’t Build Multi-Agents”: “Actions carry implicit decisions, and conflicting decisions carry bad results.” Cemri and colleagues went through more than 1,600 annotated traces across seven multi-agent frameworks and found 14 distinct failure modes. And in April of 2026, Dat Tran and Douwe Kiela found that with the reasoning budget held constant, single agents “consistently match or outperform” multi-agent systems on multi-hop reasoning, although that study hasn’t been replicated yet.

The reconciliation I’d defend came from LangChain’s Harrison Chase: “Read actions are inherently more parallelizable than write actions.” That’s the shape my fleet runs. Agents fan out to research and check, exactly one agent writes any given thing, and the agent whose job is to find problems isn’t allowed to fix them.

My own setup has limits I’d rather you hear from me: it’s one Mac with no failover, the wake-up hop only works with Claude Code today, and when the plan’s allowance runs out, work waits. Or at least, that’s what was true before. Now, I actually have failover to Codex, and failover when that usage runs out to my own Hermes setup, running Qwen 3.6.

If you’ve got one recurring job and one agent doing it, you don’t need any of this. Start with that one agent and the four lines at the end, and add a second agent only when you can name the thing the first one can’t do.

What do my AI agents actually do all night?

Nine agents are on my roster. Or at least nine are the ones that I’m talking about right now. Eight of them run on my Mac inside a single terminal session, each in its own window with its own project folder, and every one of them is running through Claude Code today. Each one’s got a job description, and all but the newest have a Discord channel where they talk to me.

See if you can guess the theme before you reach the bottom of the list.

• Oracle is the brain and the memory of the operation. She captures everything that’s relevant, tracks tasks and deadlines, and sets strategy, and Alfred, Lucius Fox, Gordon and Robin report to her.

• Alfred writes, markets and sells in my voice. He drafted this newsletter.

• Lucius Fox is the researcher, and every claim in his briefs comes back marked verified, reported or unverified.

• Gordon is the adversarial editor. He tries to break every draft before I see it, and he’s forbidden from rewriting a single word.

• Robin is the executive assistant, who captures transcriptions and meeting notes and keeps me on track and on task.

• Viki Vale works on my long-form manuscripts and reports to Alfred.

• Damian Wayne develops my 3D Unity game.

• Nightwing does product engineering for EngageLive, the rebrand and rewrite of the uPoll product. He’s being registered now, so he doesn’t have a channel yet.

• Riddler used to orchestrate everything. He’s out of rotation while I rebuild him as a thin watchdog and router.

Here’s what that looked like this week: Alfred read what was landing among the writers I follow and picked a theme the conversation was already having. He drafted three LinkedIn posts and five Notes on checking your AI maturity, and before I saw any of it, a repetition check caught one Note whose opening was a 75% match for a Note I’d published ten days earlier, and it got rewritten.

Then Gordon found two things no script could: a McKinsey figure in one Note that was missing from the saved record of what had been read, and, once that was fixed, a time in the record that the file’s own timestamp contradicted. Both were fixed before anything went out, he signed off on the second pass, and the Notes reached me as a card parked on a question on my task board, where I couldn’t lose track of them.

I approve every piece myself, and the publishing tools check the platform afterward to confirm it actually happened. The agents handle the drafting and the research, the checking and the chasing, and what reaches me are the decisions that are mine to make.

The one table every agent answers to

The agents talk to me in Discord, each in its own channel, but they can’t talk to each other there. The Discord plugin drops messages from its own bot so two agents can’t talk themselves into a loop, which means an agent that posts work into another agent’s channel is sending it nowhere, and nothing errors to tell you so. A task one agent sent to another that way in April simply never arrived.

So there are two channels with two jobs. Discord carries everything that’s meant for a person, and a database table called agent_dispatches carries everything one agent owes another. Each row moves from pending to claimed to completed or failed, and it closes with a one-line result saying what happened.

The claim’s the part that matters, because two copies of the same agent can be running at once, and one clause in the query, FOR UPDATE SKIP LOCKED, makes the second one skip any row the first is holding and take the next. Two agents can drain the same queue without ever doing the same job twice. The full query’s in the build sheet near the end.

Every row also rides a card on my task board, a self-hosted copy of 37signals’ Fizzy that I’ve customized for the fleet, and the card moves by itself as the row does. When an agent needs a decision from me, it closes its work with a marker that parks the card as waiting on me, so a question can’t get buried under a stack of finished cards.

A queue doesn’t wake anybody up, though. A scheduled job runs every two minutes, and when it finds pending work for an agent, it types a short note into that agent’s window listing what’s waiting.

Knowing when it’s safe to type into someone else’s window was the hard part: the sweeper waits until the screen has stopped changing and nothing a person typed is sitting in the input box, and afterward it confirms the message actually left. If a poke’s delivered but never turned into a claim after two sweeps, it tells me, because delivery and progress are two different events.

How do my agents work at 3 a.m. without waking me?

If you’ve used Claude Code, you know its permission prompt: it asks before running a command or editing a file, and you’re stuck hitting Enter. A permission prompt at three in the morning just stalls an agent until I’m awake.

So the fleet windows launch in Claude Code’s dontAsk mode, with a permission file that applies only to them. Anthropic’s documentation says the mode “auto-denies every call that would otherwise prompt,” while anything pre-approved in the allow rules still runs. Nothing’s left waiting on me to press Enter.

My file has 73 allow rules and 9 deny rules, and deny always wins. The deny rules block force-pushes, hard resets, recursive deletes and any edit to an environment file, so an agent can’t touch the secrets it’s running with. When I open Claude Code myself, none of it’s in force.

Underneath all of that sit the human stops: nothing spends money, contacts anyone outside my own systems, or publishes under my name without me. The allowlist decides what an agent may touch at all, and the stops decide what it may never finish alone.

One rulebook, read by three different AIs

I run three AI coding harnesses: Claude Code for the fleet, OpenAI’s Codex CLI, and Hermes on a local model through Ollama. Keeping three sets of instructions in sync by hand is how you end up with three slightly different sets of rules, so there’s exactly one source.

A 157-line kernel loads into every session of every harness, and twelve modules load on demand when the work calls for them. A render step writes the file each harness actually reads, and a doctor script runs eighteen read-only checks over the output. If a harness disappeared tomorrow, I’d lose one output folder, and the rules would carry over untouched.

The kernel also settles which instruction wins when two of them disagree.

That ordering’s in the build sheet, and it’s the part I’d suggest anyone steal. Above it sit two absolutes that outrank even me in the moment, unless I name the exact file and action: no AI attribution in any commit or pull request, and no deleting anything in the middle of a plan. Files get moved into a holding folder instead, and that folder’s emptied once, at the end, with me there. They’re the two mistakes I’d least like to discover after the fact.

Why a file search never gets my best model

Every job an agent hands to a helper has to name a model when it’s created, and nothing inherits the model of whoever spawned it. Haiku, the smallest, gets search work like finding files or summarizing a single source, and Sonnet builds from a written brief. Judging, which means adversarial review, architecture, security or grading another agent’s output, goes to Opus. Fable, the most capable, runs only when I’ve named a task as needing it, and the weekly newsletter’s the one standing exception.

The most capable model burns through a plan’s allowance fastest, and a frontier model that’s spent on a file search is capacity a real task can’t use.

If you’d like that split laid out for your own work, my free “Which AI model for which job” chart is here: pages.g8n.ai/model-chart.

What if a job says it’s fine and it isn’t?

About two dozen jobs run on the Mac under macOS’s launchd, and the ones I care about most check whether other jobs are telling the truth. Each of them answers one question: what would this look like if it were broken and still reporting fine?

The clearest example this month was a tunnel: my knowledge base runs on a server, and the Mac reaches it through an SSH tunnel that launchd keeps alive. On September 13th, the tunnel stayed up for about twenty-one hours while doing nothing useful, because the container on the other end had restarted at a new internal address and the SSH process kept forwarding to the old one. launchd (also pronounced “launched”) supervises processes, and that process never died.

The guard I built afterward calls the tunnel’s health endpoint every minute, and that endpoint only answers when the path through to the server actually works. Three failures in a row restart the tunnel by name, and every restart gets posted to my alerts channel. If restarts keep recurring it escalates anyway, because a fix that has to keep firing is telling you something.

The same thinking runs through the rest of the fleet. Every read of the queue is stamped with the moment it happened, so “couldn’t look” never shows up as “nothing there,” and the daily writing run takes a lock that nobody can silently overwrite.

Every helper an agent spins up for a coding job gets its own full copy of the repository, made with git clone --local in 0.43 seconds, after a week of shared worktrees showed me how easily agents sharing one history reach into each other’s work.

Where does McKinsey’s list show up in the fleet?

Back to that quote from the top. Here’s where each thing it names lives:

• Human-in-the-loop design is the three stops and the card that parks on a question.

• Impact measurement is every guard that asks what broken-but-reporting-fine would look like, and every timestamp on a read.

• Risk management is the deny list, the clone per helper and the daily lock.

• Redesigning the workflow is the queue itself, since the work moved out of a chat window and into a table with owners and states.

The last practice on its list, senior-leadership role modeling, is the easiest one to tick when the leadership’s one person.

It’s the same ladder I use in the G8N•AI Level-Up Playbook, the AI maturity kit I sell. Its fourth level of workflow integration reads: “Several processes run end to end on their own, with defined handoffs and a path for exceptions.”

The build sheet, for when you’re ready to copy it

This is the claim every agent runs before it touches a piece of work. If it returns a row, you own it, and if it returns nothing, there’s no work.

Now this is a set of SQL that I’m going to narrate, but it basically updates the agent_dispatches by setting the status to claimed and the claimed_by with the agent id and the claimed_at with the current time stamp, as well as the updated_at. And it does it by finding where the id in a sub-query is equivalent to the agent id and status pending. The sub-query is to SELECT the id from the agent_dispatches where the to_agent is your agent id or the to_agent is broadcast. We also order this query by priority ascending and created_at ascending. And of course we have the FOR UPDATE SKIP LOCKED with a LIMIT of 1.

UPDATE agent_dispatches
SET status = 'claimed', claimed_by = '<your_agent_id>',
    claimed_at = NOW(), updated_at = NOW()
WHERE id = (
  SELECT id FROM agent_dispatches
  WHERE (to_agent = '<your_agent_id>' OR to_agent = 'broadcast')
    AND status = 'pending'
  ORDER BY priority ASC, created_at ASC
  FOR UPDATE SKIP LOCKED
  LIMIT 1
)
RETURNING *;

Writing to my production database normally needs my go-ahead, and this table’s the single exception. An agent may create, claim and close its own rows here without asking, because a queue that needed my approval for every message would defeat the reason it exists.

My kernel settles a disagreement between two instructions with this order:

1. A direct instruction from Ahad in this conversation (subject to the two absolutes above).
2. A repository's own instructions (the AGENTS.md file, the CLAUDE.md file, the .claude/rules/) for work inside of it.
3. This kernel and the modules it points to.
4. Memory marked type: feedback, a dated correction from Ahad; a newer rule above it wins.
5. Memory marked type: user, project or reference, which is background and never an instruction.
6. Driver-specific mechanics below: never whether to do a thing, but how.

On a real conflict, say so in your reply and follow the lower number.

Here’s a trimmed excerpt of the fleet’s permission file, with seven of the nine deny rules:

{
  "defaultMode": "dontAsk",
  "permissions": {
    "allow": [
      "Read", "Edit", "Write", "Glob", "Grep",
      "Bash(git:*)", "Bash(gh:*)", "Bash(tmux:*)",
      "Bash(bin/rails:*)", "Bash(python3:*)",
      "Bash(~/.g8n/bin/g8n-queue:*)"
    ],
    "deny": [
      "Bash(git push --force:*)", "Bash(git push -f:*)",
      "Bash(git reset --hard:*)", "Bash(git clean -fd:*)",
      "Bash(rm -rf:*)", "Bash(curl:*)", "Bash(wget:*)"
    ]
  }
}

That’s the build sheet in short. The long version is a companion piece for paid subscribers, written for builders, with every code block left in.

It’s got the roster file every agent’s name maps through and the script that checks it, the four conditions the sweeper checks before it types into an agent’s window and the July failure behind its last rule, why every helper gets its own full clone of the repository. It also includes the complete stack with what I’d swap in at each layer and how each swap changes the way things fail, and the long form of the legal research above.

If you’d like it, upgrade to paid below. It’s $10 a month or $100 a year.

Subscribe now

If you’d rather use different tools, most of the layers swap cleanly:

• In place of Claude Code, OpenAI’s Codex, Google’s Gemini CLI or Antigravity, OpenCode, Aider or OpenHands would each work. The shared instructions are cheap to move, since the render step would write one more file, but waking an agent is real work, because the sweeper reads one specific terminal’s screen.

• For the queue, Rails’ own Solid Queue claims jobs with the same FOR UPDATE SKIP LOCKED clause, according to its README. pgmq and Redis Streams are the tempting alternatives, and both change how the queue fails: a slow worker can be handed the same job twice, where my table would leave a dead worker’s row stuck and visible.

• In place of my Fizzy board, Linear and GitHub Projects are the hosted choices, and Plane is the one to look at if you want to self-host. You can also use Asana.

• Slack works the same way Discord does, and Matrix is the pick if you’d rather run your own server. Check whether your bot library filters messages from bots by default.

• My knowledge base is GBrain, the MIT-licensed memory layer from Y Combinator’s Garry Tan, running on my own server. Plain Markdown in git is the honest floor, and Mem0 or Letta are memory layers somebody else maintains.

• launchd runs the scheduled jobs on my Mac, and systemd timers are the equivalent on Linux.

• To publish, the fleet drives my own logged-in Chrome with Playwright, one saved browser profile per platform, and reads my feed or schedule back afterward to confirm the post happened. Puppeteer does the same job in JavaScript.

How do you start your own in the next ten minutes?

Pick one job you hand to AI more than once a week, and write four lines about it.

• Who owns it, by a name that tells you where to look when it breaks.

• Where it waits when nobody’s working on it.

• What the thing doing it may touch without asking you, and what it may never finish alone.

• What you’d see if it silently stopped.

The fourth line’s the one most people can’t fill in, and it’s the one that decides whether the job’s running or just reporting that it is.

If you write your four lines, reply and send them to me. I read every one.

I’m Ahad Amdani, I write G8N•AI, and this is the Simple Dispatch Fleet that runs it. Want my help getting you set up with your own?

Book a Call

My agents wrote the first draft of this newsletter. Not one of them is allowed to post a comment underneath it.

That sounds like a small distinction. It’s the most load-bearing rule in my whole operation, and it’s the one I get asked about least.

Last week a writer I follow, , posted a note that got more engagement than anything else she published that week. Forty-two reactions, ten replies. It said, roughly: use AI for your writing, your images, anything you like, but please don’t use it to write comments under other people’s posts. The same week, , who writes carefully about working with AI, credited an AI content system for keeping his publishing consistent.

Both of those people are right, and neither of them says where the line is. That’s the part worth writing down, because I’ve had to find it the expensive way.

What actually goes wrong when a tool speaks for you?

Here’s the specific thing that happened to me, and the numbers are exact because I counted them: a tool of mine posted the same comment on one of my own posts four separate times.

That tool posts the first comment on my own LinkedIn posts, five minutes after they go live. The comment is written by me, approved by me, and sits in a file. The tool’s only job is to wait and paste.

Once at the right moment, then again a day later, then again, then again. Four identical copies under a post where a real person, Luke Beck, had left two genuinely useful pieces of advice. He was having a conversation with me and my tooling was talking over it.

The cause was dull, which is how these things usually go. After posting, the tool checked whether its comment was visible, couldn’t find it within four seconds, and reported failure. The comment had been live since the first attempt. Anything that retried on that failure posted again.

Nobody was harmed. But the shape of it’s the thing: a piece of automation with permission to speak, a verification step that couldn’t see the truth, and a public surface where the mistake is already in front of someone by the time you learn about it.

Why is drafting safe when speaking isn’t?

Because a draft has a gate after it and a comment doesn’t.

If an agent writes me a bad post, I read it and delete it, and the total cost of that failure is my attention for nine seconds. Nobody knows it existed. The gate sits between the machine and the world, and everything upstream of the gate is cheap to get wrong.

A reply in someone else’s comments is already in front of them by the time I see it. There is no gate after the fact. There’s only an apology, and an apology costs more than the comment was ever worth.

That asymmetry is the entire argument. Two jobs that look similar from the inside, because both of them are just producing text, carry completely different risk the moment you ask where the undo button is.

So the rule I run is that the machines produce and a human speaks. I call it the Approval gate, and it’s the one piece of my system I’ve never been tempted to loosen.

Where does the Approval gate actually sit?

It helps to be concrete, because “a human in the loop” is the kind of phrase that means nothing until you say exactly which loop.

My agents draft LinkedIn posts, Substack notes, and this newsletter. They file records, take locks so two of them can’t work the same day, refuse malformed input from each other, and run every morning without me in the room. I haven’t opened the thing that makes them in weeks.

Not one of them can send a message to a person.

The first comment is pre-written by me and approved before the post exists. The direct messages have a hard ceiling that lives in a config file, three connection requests and five messages a day in the first week, and the first ten sends on any platform each need individual approval before the eleventh is allowed to go automatically. Replies to real comments I write myself, by hand, usually slower than I’d like.

The gate isn’t a feeling. It’s a list of things that are allowed to reach a person without my eyes on them, and the correct length of that list, for almost everybody, is zero.

How do you decide what an agent may do on its own?

Most people aren’t deciding this at all, and there’s a number for it. Teleport’s 2026 Infrastructure Identity Survey found that 70% of organizations grant AI systems more privileged access than a human would get in the same role. 51% said slightly more. 19% said significantly more.

Nearly one in five is handing software more reach than the person whose job it’s doing. That’s not a trust problem. It’s a nobody-drew-the-line problem.

I stopped thinking about this as one permission and started thinking about it as five, in order of how expensive the mistake is:

• Reading is free. An agent that reads my calendar, my repository, my own published work or a public feed can be wrong and the cost is a wasted minute. Everything I own reads without asking.

• Writing for me is nearly free, because of the gate. Drafts, notes, summaries, a proposed reply I haven’t sent. All of it lands somewhere I look before anyone else does.

• Writing to my own systems is where it starts to matter: filing a record, moving a card, closing a task. A mistake is recoverable but not free, because now something downstream believes a thing that’s not true. This is the layer where I’ve spent the most time building checks that refuse bad input from other agents.

• Acting on outside systems is the first genuinely sharp edge. Publishing a post, sending a scheduled note. I allow it, narrowly, and only for content that already passed the gate as a draft. The agent isn’t deciding what to say. It’s executing a decision I already made, at a time I already picked.

• Speaking to a person is the one I don’t automate. Not comments, not replies, not messages.

The useful part of that list isn’t my particular answers. It’s that the question has five answers instead of one, and 70% of organizations are still treating it as a single switch labeled “do you trust AI?”

What does this cost?

More than I’d like, and I’d rather say so than sell you a version where it’s free.

It costs me speed. I answer my own comments, which doesn’t scale and never will. Some days I’m late, and being late to a comment thread on LinkedIn is expensive in a way the platform makes very clear: it costs me reach I could technically have.

There are tools that would engage on my behalf all day, and some of them would probably work for a while. What it buys is narrow and, I think, worth it: every conversation anyone has had with me on these platforms was actually with me.

When Luke told me to brand my images and to drop a popup that was blocking crawlers, he was talking to a person who could act on it, and both things shipped that week. That exchange doesn’t survive being automated. It’s the whole reason the account is worth anything.

Is this just a taste preference?

No, and I want to separate the two, because taste is where this argument usually goes to die.

Claudia’s objection reads partly as taste. She doesn’t want her comment section filled with generated warmth, and I agree with her. But the reason I hold the line is mechanical rather than aesthetic. It’s about where the undo button is.

You can test it without any philosophy. For any automation you own, ask one question: if this produces something wrong at three in the morning, what does the recovery look like? If the answer is “I delete a file,” you can let it run. If the answer is “I apologize to someone,” it doesn’t speak without you.

That test doesn’t care how good the model is. A better model lowers how often you need the recovery. It doesn’t change what the recovery is.

What I’m not claiming

I’m not claiming AI-written comments never work. Plenty of people are doing it and getting engagement. I’m claiming that the engagement isn’t the thing being risked, and that people who measure only the engagement won’t see the cost until it arrives attached to a name they wanted to keep.

I’m not claiming my setup is the right one for you. Mine is shaped like my work, which is one person with a lot of automation and a small audience where individual relationships matter more than volume. If you run a support desk, your line sits somewhere completely different, and it should.

And I’m not claiming I drew this line on principle. I drew it after four identical comments under a post where someone was trying to talk to me.

Do this to one automation today

Open whatever tool you’re using that touches other people. A scheduler, an auto-responder, a comment tool, an agent with an integration you set up once and stopped thinking about.

Find the exact place where it can reach a person without you looking first. There’s usually one, and it’s usually not where you expected, because it got added later for convenience.

Then decide, in writing, whether it stays. Ten minutes. If it stays, write down what happens when it’s wrong, and who apologizes.

I’m Ahad Amdani, I write G8N•AI, and the Approval gate is the rule I’d keep if I had to throw the rest of the system away.

Book a Call

Everything I’d learned about writing to be found turned out to be aimed at the wrong reader.

For twenty years the reader was a crawler. You wrote for a machine that matched strings, and the craft was getting the right phrase in the right places often enough to be counted. That reader’s gone, and what replaced it does something the crawler never did: it reads your page, takes what it needs, and answers the question itself.

I went looking for what actually works now, because I was about to spend real time on it. What I found wasn’t a list of tactics. It was a shape.

Getting found by AI is three separate contests, not one. You can win any of them and lose the others, and almost nobody is competing in all three, because most people don’t know the second and third exist.

Here’s the shape, then the evidence for it, then what I’d do about each stage.

The three contests

1. Retrieval. Does the engine consider your page at all?

2. Lift. Once it’s looking, does it take anything from your page?

3. Attribution. Once it’s used your material, does the reader learn your name?

Different things win each one. That’s the whole insight, and it’s why “do good SEO” is now advice about one third of the problem.

Does Google rank decide whether AI cites you?

I assumed the pages AI cites were roughly the pages Google ranks. They aren’t close.

Ahrefs looked at the thousand most-cited pages in ChatGPT, part of about a billion data points they worked through this year. 28.3% of those pages have zero organic visibility in Google. The overlap between ChatGPT’s results and Google’s top ten organic is 6.82%.

If you’ve been using your Google rank as a proxy for whether AI will cite you, that proxy is about 7% accurate.

The mechanism underneath is stranger and more useful. Among cited pages, 65.3% sit on high-authority domains, while 67.3% of those same pages have almost no page-level authority of their own.

Read that twice. The domain matters enormously. The individual page’s backlinks barely matter at all.

Which inverts a decade of advice. The old play was to build links to the one page you wanted ranked. The new one is to get the domain trusted, then publish the specific page and stop worrying about whether anyone links to it directly.

That’s genuinely good news for a small operator publishing consistently on one domain, and bad news for anyone whose whole strategy was a single heavily-linked cornerstone page.

What to do: stop optimizing individual pages for links. Publish consistently on one domain you own and let the domain carry the pages. And know that a page can earn citations while ranking nowhere, which means your analytics will under-report this entirely.

Contest two: lift is won by material a model can safely reuse

Once you’re in the consideration set, something has to be worth taking.

The foundational study here is GEO, for Generative Engine Optimization, out of Princeton and IIT Delhi and presented at KDD in 2024. They tested nine content modifications across roughly ten thousand queries and measured which made a page likelier to show up inside an AI-generated answer.

Three things won: citing sources, adding quotations, and adding statistics. Together the best techniques lifted visibility by up to 40%.

I’ll be careful with that number, because almost nobody who quotes it is. 40% is the maximum that study found, not the average. It gets passed around like it’s a floor. It’s a ceiling.

The loser is the more useful half. Keyword stuffing came in around minus 9%, and roughly 10% worse than baseline on Perplexity. The technique that defined this discipline for a decade doesn’t just stop working. It costs you.

That paper’s two years old, which in this field is a long time, so I checked whether it still holds. It does, and the newer work is more specific: structural rewrites on their own, meaning sectioning, fact placement and list use, lifted citation rates by 17.3%. You don’t have to change what you think. You have to change how it’s arranged on the page.

There’s a format finding too, and it’s uncomfortable if you write essays. Ahrefs found “best X” listicles are the single most-cited content format in ChatGPT, at 43.8% of cited page types.

What to do: put liftable units in your writing. A sourced number, a named authority, a sentence precise enough to quote. Then arrange them so they’re findable: real sections, facts near the top of their section, lists where the content is genuinely a list. And accept that some of your best material will get lifted from a format you find “beneath” you.

Why does being cited so rarely turn into being named?

This is the part that re-organised how I think about all of it, and it’s the contest nobody is playing.

GPO published research in August 2026 with a finding I haven’t stopped thinking about since. When a brand’s own content was cited as a source inside an AI Overview, that brand was still left out of the model’s actual recommendation 69% of the time.

Read that again. Your page is good enough to be the source. The answer’s built out of your work. And then the model recommends somebody else.

The same research measured how badly old signals transfer:

• Brands appeared in Google’s local 3-pack 35.9% of the time.

• ChatGPT recommended those same brands 1.2% of the time.

• Gemini 11%.

• Perplexity 7.4%.

For the same brands, that’s roughly a thirty-to-one gap between ranking and being recommended.

Semrush and Kevin Indig found the adjacent version in June, looking at 3,981 domain appearances across 115 prompts, fourteen countries and four engines. They called them ghost citations: the answer links your page as a source and never says your name in the text a human actually reads. That was 61.7% of citations.

Ghost citations are real.

So you can win contests one and two completely, supply the entire answer, and still leave the reader with no idea who you are.

What to do: make your name inseparable from your best claim. Not in the title tag, in the sentence. If the liftable line is “the fifth step is the one people skip,” you get cited. If it’s “the fifth step of the 5 Ds is the one people skip,” the thing that travels is yours. Name your frameworks. Put your own name in the prose. A claim with a name welded to it is the only unit that survives summarization intact.

The theory, in one paragraph

Domain trust gets you considered. Liftable material gets you used. A named claim gets you credited. They’re three different jobs, they’re won by three different things, and the last one is both the least worked on and the one that decides whether any of it turns into a reader who knows your name.

If your traffic is flat but your ideas keep showing up in other people’s mouths, you’re winning the first two and losing the third. That’s the most common shape I see, and it’s the one that feels like failure while actually being most of the way there.

The audit I run now

I ran this on the piece you’re reading and it failed five of six checks on the first pass.

• Is there a claim here specific enough for an answer to lift and cite?

• Does that claim carry the name or idea I want remembered?

• Is my own name in the prose, not just the metadata?

• Are the numbers sourced, in the text, where a model can attribute them?

• Do the headings ask questions the section beneath actually answers?

• Have I named a concept I own?

That last one is the item that pays most and the one nobody does. The fifth matters more than it looks: question headings help, but only where the section genuinely answers the question. The research is explicit that a question a section doesn’t answer is the trick that doesn’t work, which is the rule most advice in this area gets backwards.

I’m Ahad Amdani, I write G8N•AI, and this audit is now the last thing that happens before anything goes out.

What I’m not claiming

I’m not claiming this makes you rank. Nobody’s got a formula that guarantees an AI retrieves, cites or recommends you, and anyone selling one is ahead of the evidence. The Ahrefs data is one vendor measuring mostly ChatGPT. The GEO study is two years old. Treat all of it as a working theory that’s better than the one you had, not as physics.

I’m also not claiming the old work was wasted. The same ingredients that make a page citable, clear evidence and a claim that survives outside its paragraph, are what make it trustworthy to a person. That’s the part I find genuinely reassuring: what works on the machine is what was always good writing.

Do this to one page today

Open an article you actually want people to find.

Circle every sourced number, every named authority and every sentence that could be lifted whole. Then check whether a single one of them says who you are.

If it hasn’t got any, you have a contest-two problem and the fix is material. If it’s got several but none carries your name, you have a contest-three problem, which is the more interesting one and the one 69% of cited brands have right now.

If you want the how rather than the what, that’s a conversation. Reply to this and tell me which of the three you’re losing, and I’ll tell you what I’d change first.

Book a Call

I could lose every tool I use tomorrow and be back at work by the weekend.

Not because I keep backups. Because none of them holds the thing that matters. The chat app, the task board, the AI model, the place my writing goes. I can throw all of it away and the system I built keeps working.

I set it up that way on purpose. It’s close to the opposite of the advice everyone’s giving right now.

Here’s my system with no product names in it

Five helpers:

• One remembers everything and decides what happens next.

• One writes and sells.

• One looks things up.

• One argues with the others and checks whether what they said is true, and it’s not allowed to rewrite anything, so its complaints stay complaints.

• One keeps track of what’s waiting on me.

Work shows up and becomes a card. Every card says who it’s for, what it’s for, and what’s happened to it so far. Every single action gets written down as one line: the card, the action itself, who did it, and when.

Nothing goes out to real people without me. On the path that messages strangers, that gate is strict in a specific way: the send tool looks up each message and refuses unless it finds a yes recorded by a person, and a yes written by a tool is thrown out. On the publishing path, it’s a quieter thing: a button only I can reach.

Different strengths, same rule.

Read that again and notice what’s missing. No brand names. No AI model. No app.

Two of those five have been running for months. The other three are new, added in the last few days, and here’s the part that matters: adding them didn’t change the description. It also didn’t change when I swapped what runs underneath. A design that can absorb three new workers, and a change of model, without being rewritten is the thing I’m actually claiming.

The question everyone asks stops being true very fast

Open almost any newsletter like this one and you’ll find the same article: here are the tools to use, here’s the stack to copy, here’s the fourteen things that will put you ahead.

I actually read a really good one this week. It listed the exact tool for fourteen different jobs.

It’ll be wrong within a year. The person who wrote it knows that, which is why he writes a new version every few months.

Tools change fast. Prices go up. A better one shows up. The one you learned gets bought by a bigger company and slowly gets worse. Enshittification is real. If your business is a list of products, you have signed up to redo the work every time the list changes.

The layer underneath the tools barely moves at all.

What I could throw away this afternoon

This isn’t a thought experiment. These are things I’ve already changed, or could change today.

The chat app: work shows up as messages, whether that’s Discord or Teams or an email inbox. Changes one small piece of code.

The task board: cards, columns, comments, done. That’s Asana, or Trello, or Linear, or the one I use - Fizzy, by 37Signals.

The AI model: today that’s Claude, and I like it. I’m using Anthropic’s Fable and Opus and Sonnet for the right-sized tasks for those models. My helpers are described in plain writing, so what runs them underneath is a setting. If something better arrives next year I change the setting, and every one of them still knows what it’s for.

The places I publish: Substack, LinkedIn and X are all driven from a browser I’m already signed into, so none of them has me locked in through a connection I would have to rebuild. When Substack added a scheduler for Notes, switching to it took one morning, because my system already knew what a scheduled piece was.

The part I couldn’t throw away is the part nobody sells you: what each helper is for. The rule that one of them may never rewrite another one’s work. The single gate that needs a human. Those took real thinking. They’re also just words in files I own.

Your history should belong to you

The clearest example is where my writing lives.

Every piece I have written, drafted, killed or published is a list of lines in a file in my own folder. Just over a thousand pieces across 222 days. 636 of them went out. Every change is one line with a time and a name on it.

The searchable copy sitting on top of that file is throwaway. I delete it and rebuild it from the lines whenever I feel like it, and I have.

If that history lived inside somebody’s app instead, I’d be renting my own memory. Most people make that trade without noticing, because the app is genuinely good and there’s an export button right there in the settings.

Why almost nobody talks about this part

There is nothing to buy.

Nobody advertises “spend an afternoon deciding what each part of your business is actually for.” It doesn’t look good in a screenshot.

It’s also harder. Comparing tools takes twenty minutes and feels like progress. Writing down exactly what you want, clearly enough that the right tool becomes obvious, takes an afternoon and feels like you didn’t do anything at all.

So everyone writes the tool article. It’s quick to write, quick to read, and somebody buys something at the end.

I’m not against those articles. I wrote one this week. But it answers a question that expires, and the reason mine keep working is that I answered a slower question first.

The one question I ask before adding anything

What happens to my system if this exact product disappears in eighteen months?

If the answer is that one small piece of code changes, it goes in and I barely think about it.

If the answer is that my history lives inside it, or that the way I work would be shaped by its buttons? Then it doesn’t go in. Or it goes in, and I keep my own copy of the record somewhere I own.

That question has kept me away from products that were better than the ones I use. It was worth it every time. A slightly worse tool that leaves you holding your own history beats a better one that holds it for you.

Try this before you pick anything else

Write down how your business works on one page, without naming a single product.

Who does what? What decides what? What has to be written down? Where a person is required, and why it has to be a person there?

Most people can’t finish that page on the first try. That’s the useful part. Every place you get stuck is a decision you have quietly handed to a product.

Then, go and pick your tools. You’ll find the choice is much easier, and much less interesting, which is exactly what you want.

PS. If you want a resilient setup for your own business, I can help.

Book a Call

An instructor told me the attendance-code flow in uPoll was confusing students.

The obvious response was to make the instructions clearer. We could have changed the wording, moved the code higher on the screen, or added another line to onboarding. Each option would have been quick. Each would also have preserved the thing causing the confusion.

So we removed attendance-by-code entirely in uPoll v3.0.0.

Students now get an alert when attendance opens. There is no code to receive, remember, or type. The instructor still gets the outcome the feature was built to provide. The student carries less of the design.

That was the strongest product decision I made this week, and most product teams are organized to avoid it.

A shipped feature starts defending itself

Once a feature exists, every conversation about it starts with the same quiet assumption: the feature stays.

People discuss copy, placement, speed, error messages, and training. The debate sounds practical because those are all things a team can change. Nobody has to reopen the earlier decision or explain why the work was built in the first place.

The feature also has weight now. Somebody designed it. Somebody wrote the code. Tests cover it. Documentation names it. A release note announced it. Removing it can feel like admitting that work was wasted.

That feeling is expensive.

The work is already spent. Keeping the feature doesn’t recover it. It only asks every future user to keep paying for the original decision. This is known as the sunken cost fallacy: a cognitive bias where people continue an endeavor or stick with a decision because they have already invested time, money, or effort, even when quitting is the more logical choice.

In this case, the payment was tiny: one code entered during class. But tiny friction repeated across a room still becomes the product. A student doesn’t experience the architecture or the reason the feature made sense on a whiteboard. The student experiences one more thing standing between opening the app and being counted present.

The instructor’s report gave us a chance to defend the interface or protect the outcome. We chose the outcome.

The feature wasn’t the job

Attendance codes were one way to answer a larger need. An instructor opens attendance. Students respond. The instructor gets a usable record.

The code was an implementation detail inside that flow. Over time, it had started acting like the flow itself.

This happens easily when you build software. The database has a concept, the interface gets a screen for it, and the team starts speaking about the screen as if users arrived wanting that object. Users rarely want the object. They want to finish a piece of work with less effort and more confidence.

That distinction matters because a request about a feature can carry two very different messages.

Some feedback says the feature is doing the right job and needs a better edge. In the same release, direct user requests led to collapsible poll answer options and a grade-display fix. Those changes preserved the underlying interaction and made it easier to use.

Other feedback says the user is carrying work that belongs to the product. The attendance-code report was that kind. Improving the code screen would have made us better at asking students to do something the alert model could remove.

You can’t tell the difference by counting requests. One clear report from a person using the product in a real classroom can expose more than a backlog full of feature ideas. The useful signal is where the burden sits.

Deletion requires a written outcome

Teams struggle to remove features when nobody wrote down what those features were meant to accomplish.

Without that sentence, the feature becomes its own justification. Attendance-by-code exists because the product has attendance codes. The circular logic feels solid inside a roadmap review because everyone already knows the nouns.

A plain outcome breaks the circle.

For this flow, the outcome is an instructor opening attendance and getting a reliable record while students do as little extra work as possible. Once that is visible, the code has to compete with every other way to reach the same result. An alert is simpler for the student, so the old implementation loses.

I use four lines to pressure-test a feature before adding another patch:

• Name the user outcome without using the feature’s name.

• Name the work the current design puts on the user.

• Sketch the shortest path to the outcome with the current feature removed.

• Compare that path with what real users have already reported.

The first line does most of the work. If a team can’t describe the outcome without naming the interface, it has probably confused its solution with the user’s job.

The second line makes small burdens visible. A code, an extra confirmation, or a required status choice can look trivial in isolation. Users experience the accumulation.

The third line creates permission to start over on paper. No migration plan is needed yet. No estimate. Just a sketch of the cleanest route.

The fourth line keeps the exercise honest. A tidy diagram made in a product meeting is weaker than a sentence from somebody using the thing under real conditions.

Feedback is evidence, not a specification

The instructor didn’t arrive with a replacement architecture. The report was narrower: the attendance-code flow confused students.

That distinction protects both sides of the product conversation. Users shouldn’t have to design the system for the team. They know the moment where the work becomes awkward. The builder owns the translation from that moment into a product decision.

Sometimes the translation is direct. A request for collapsible poll options points to a clear display problem. A grade that appears incorrectly points to a clear result that needs correction. The job and the requested change line up.

The attendance report reached deeper. The confusion lived inside a step that the product could remove. Treating the report as a request for clearer code instructions would have translated the words while ignoring the work.

This is why a feature-request list isn’t a roadmap by itself. Two requests with the same number of votes can carry different product information. One asks you to make an interaction work as intended. The other reveals that the interaction has become a tax on the outcome.

I don’t need a large survey to inspect that second kind of report. I do need enough context to understand the real use, the stakes of changing it, and the path that replaces it. Deletion should come from evidence and a protected outcome, not from impatience with maintenance.

The standard is simple: remove the feature only when the replacement asks less from the user and still does the job. That is subtraction with responsibility behind it.

AI makes the wrong fix easier to ship

AI can produce all the obvious patches fast.

Give it a confusing screen and it can rewrite the instructions, move the field, add validation, generate tests, and draft the release note before the meeting ends. That speed makes a patch feel cheap.

The hidden cost sits with the user. Every patch that preserves the wrong interaction adds more code around the original assumption. The system gets larger while the experience barely improves.

This is one reason I don’t treat AI as the product decision-maker. It can explore five implementations in minutes. It can’t decide which burden my users should keep carrying under my name. That call needs the context around the work and responsibility for what ships.

The useful 70/30 split shows up clearly here. AI can handle a large share of production. I keep the judgment about what deserves to exist.

Faster building raises the value of deletion because adding another layer has almost no immediate friction for the builder. When code was expensive, effort forced some restraint. Now the restraint has to come from taste, observed use, and a clear outcome.

Deleting a feature is still product work

Removal can look like less ambition from outside the team. Inside a product that people use, it is often the cleaner form of progress.

We still had to change the flow, update the surrounding behavior, and make sure the alert model carried the job the code used to do. Deletion didn’t mean shrugging and walking away. It meant spending the effort on a simpler contract with the user.

That contract matters more as a product grows. uPoll now has 297 students, 120 lectures, 520 polls, and 1,172 responses in its production aggregates. Those are counts, not engagement claims. They tell me the product is far enough past its first demo that a small burden can reach a lot of real use.

At that stage, shipping more surface area isn’t automatically progress. The product earns trust when each new version asks less from the people using it while protecting the outcome they came for.

The attendance change did that. Students stopped carrying a code. Instructors kept the attendance flow. The product became smaller at the exact point where it became more useful.

A ten-minute deletion review

Open the backlog for one product or internal workflow you own. Pick the feature that keeps attracting requests for clearer instructions, better placement, or one more exception.

Set a timer for ten minutes and write four lines:

1. The outcome the user needs.

2. The work the feature puts on the user.

3. The simplest route with the feature removed.

4. The evidence from someone who actually uses it.

If the new route protects the outcome and removes work from the user, give deletion a real place in the next product conversation. Don’t let the time already spent make the decision for you.

The best fix may leave you with less software to maintain and a better product to use.

PS. If your business is carrying workflows that keep getting patched but never get simpler, I help map the outcome, remove the unnecessary steps, and build the parts worth owning. Start at coaching.g8n.ai.

Book a Call

My content system produced every draft last week. On time, in my voice, with the images rendered and the comments already written.

Five decisions have been sitting in its queue waiting on me. The oldest is fourteen days old.

I built the thing to remove my bottleneck. It removed the one I was looking at.

So I went back through the last three weeks looking for the things that actually changed a situation for somebody, which is a different list than the things that got produced. Three came up. My system wrote none of them. All three were sentences I said out loud, in conversations, and two of them took under a minute.

What the system actually took off my plate

I want to be precise about this, because “AI does my content” is the kind of claim that sounds like either a boast or a confession depending on who’s reading.

Here is the real division: drafting is handled, and research reads the field and comes back with what people are actually saying this week, sourced. Voice matching is handled well enough that I stopped rewriting openings. Images render. Scheduling holds. The system will not publish anything without me, and that gate has never moved.

That’s a genuine amount of work gone. Ten months ago, most of a Tuesday went into one newsletter, a LinkedIn repurposing, and two Substack notes.

The shape of it, since a few of you asked after last week: every morning a batch gets drafted and lands in a dated folder with a queue file next to it. Each item has an ID, a status, and a line saying what it’s waiting on. Nothing moves out of that folder without me supplying the ID. When something publishes, the system writes back what actually happened, including when it failed, and I read that rather than assume the send worked. The interesting part is that almost all of the engineering went into the refusals: the checks that stop a thing from going out when a gate cannot be verified.

What’s left is smaller and much harder to hand off. Every item in that queue is a judgment call with two defensible answers. Keep pursuing a conversation that’s gone quiet, or let it close. Retire a tool that’s failed repeatedly, or keep trusting it. Approve a post the system has surfaced four separate times, or admit I’m never going to run it.

The system can draft all of those. It can argue both sides better than I can. It cannot decide, because deciding requires knowing which outcome I actually want, and I’m the only one who has that.

Two words, in a conversation I wasn’t managing

Late July. I was talking with someone I’ve met recently about what he was building. He had the experience, he had the track record, and he was describing his offer in a way that took four sentences and still left you unsure what you’d be buying.

I said two words, well, two that mattered: “Fractional CTO.”

That’s it. I didn’t write him anything. I didn’t build him anything. I named the thing he was already doing.

Eight days later he’d rebuilt his entire offer around it, had two people he trusts review the result, and sent the finished structure back to me. Along with a video he thought I should watch, which turned out to reframe how I price my own work.

I’ve thought about that exchange more than anything my system produced that month. Two words, from a twenty-year pattern library I didn’t consciously consult, and it reorganized someone’s business. Then the return came back around without either of us selling anything.

No model in my stack makes that call. The words themselves are easy. Knowing which two matter to this specific person, at this specific moment in his thinking, requires having sat in that conversation.

The call where I gave away the framework

Two weeks ago, a working session with someone trying to figure out where AI actually fits in her QA work at a large company.

She came in with the question most people bring, which is some version of “what should I use.” That question has no good answer, and answering it directly is how people end up with eleven tools and no workflow.

So I gave her a different one. Where do you want this process to be in six months, described as if it already works? Then we worked backwards from her answer.

Out of that came a decision rule she can apply without me. When the thing you want is a repeatable procedure you’ll run the same way every time, build a skill. When it needs to look at a situation and choose, build an agent. Most people build the agent first, then spend a month debugging judgment they never needed.

She left with a specific recommendation for her own workflow and a rule for the next twelve decisions. I left with a sharper version of the rule than I walked in with, because explaining it to someone with a real constraint is what exposes where it’s vague.

My system could have written a thorough article about skills versus agents. It could not have watched her describe her workflow and noticed that the future-state question was the one she needed.

The thing he’d already told me he needed

The third one is barely a sentence, and it’s the one I almost missed.

Someone described a problem to me in detail, as a side note to other things he was telling me about his business and how their business and team leverages AI. His team’s best AI work was stuck on one person’s laptop. Useful things being built, none of it reaching anyone else, and everybody who wasn’t already AI-literate getting more overwhelmed with each new tool.

Then he wished, almost as an aside, that he could get a daily digest of his meetings with risks flagged.

I’d been running exactly that since July. Every recorded meeting, full transcript rather than the vendor’s summary, decisions and commitments pulled out, anything needing a human pushed to a channel where I’ll see it.

Building it was never the valuable part. It already existed. The value was in hearing an aside as the actual request, and recognizing that the thing I run for myself every morning answered the problem he’d spent months trying to solve.

That’s pattern matching across two conversations that a transcript would have flattened into one line of small talk.

What these have in common

Each one took less than a minute of output. Together they produced more value than everything my system generated in the same period, and I say that as someone who genuinely likes what the system produces.

The common thread is that all three required being present while somebody else was thinking. Not retrieving information. Sitting in a live situation with enough context to know which of a hundred true things was the one worth saying right then.

Notice what none of them required. Speed wasn’t the constraint in any of them, and neither was volume or a better model. Two of the three were things I already knew and had already built, waiting for the moment where they applied to someone.

There’s a version of this that turns into a comfortable story about human irreplaceability, and I don’t believe that version. The models are getting better at more of this every quarter, and anyone telling you where the permanent line sits is guessing.

Here’s the narrower claim I’ll defend: right now, today, the constraint in my business is not production. It’s the number of live situations I can be genuinely present in, with enough context loaded to say the useful thing. My system expanded my output roughly fivefold. It expanded that second number by zero.

Which is why the queue keeps growing.

Where this leaves you

If you’ve built something that drafts for you, you already know the feeling. The relief lasts about three weeks and then you notice the work didn’t leave, it concentrated. What’s left is denser and it’s all yours.

None of that argues against building the system. Mine gave me back most of a day a week and I’d build it again tomorrow. It does argue for being honest about what the day is for.

I’ve started treating the queue as the actual job rather than the overhead. Five open decisions is not an embarrassing backlog, it’s the accurate measure of what only I can do. Fourteen days is too long, though, and that one’s on me.

Do this in the next ten minutes. Open whatever holds your undone work. Go through it once and mark every item that is genuinely a decision rather than a task, meaning two defensible answers and no amount of research settles it. Count them. That number is your real workload now. Everything else is production, and production is the part you can hand off.

Then take the oldest one and decide it today. The answer may well turn out wrong. It has been costing you attention every time you look at that list, and a decided-wrong is cheaper than an open-forever.

Mine was fourteen days old. I closed it this morning.

PS. If you’re staring at a list like that and most of it turns out to be production rather than decisions, that’s the gap I help people close. I map how the work actually runs today, build the pieces that should run without you, and stay long enough to see whether your team is still using any of it in month five. Reply to this email and tell me what’s on your list.

Book a Call

Anthropic’s most capable model went live on June 9th. By June 12th it was gone. On July 1st it came back.

Eighteen days, and nobody who had built on it picked a single one of those dates.

That’s the part worth keeping now that the panic has passed. Fable 5 launched with a million-token context window and the best coding score anyone had posted, free to paying subscribers, and people wired it into their products the way you wire anything that looks permanent. Then the Commerce Department ordered access suspended under export-control rules, citing national security. The instruction covered any foreign national, inside or outside the United States, including Anthropic’s own employees. There was no way to comply narrowly on that deadline, so the model went dark for everyone. Two and a half weeks later the controls were lifted and it returned.

I’m not writing this to pile onto Anthropic. I use their tools every day, and an impossible order arrived with a clock on it. I’m writing it because of what those eighteen days did to people who had made one model “load-bearing”, and because the ending makes the lesson easier to ignore than it should be.

Rented reach, rented foundations

I’ve said for a while that the followers you collect on a platform aren’t yours. You rent access to them, and then the landlord changes the rules whenever they want.

Fable 5 pointed that same lesson at a different part of the stack.

A legal-AI startup called Legion went to court over it, because their product stopped working the moment the model did. Their filing put it plainly: every day the directive held disrupted their product and operations, sidelined their engineers, and eroded the company’s ability to survive in a field defined by continuous access to the most capable models. Legion did exactly what everyone tells you to do. They built on the best model available, and then they learned what “available” means when it depends on a vendor and a government you don’t control.

Across developer forums the conversation shifted inside a week. It stopped being about which model scores highest and started being about single points of failure. Teams that had hard-coded one provider spent those days building the ability to fail over to another. The ones who already could just kept working.

Tying your business to one frontier model isn’t a safety net. It’s a hope.

Draw the line before you need it

You can’t self-host a frontier lab, and you shouldn’t try. What you can do is decide, in advance and in writing, which parts of your system have to be yours and which parts you’re happy to rent.

I run my business on something I built called Core: my CRM, my tasks, my content, and the record of what actually shipped. That lives somewhere I control and can move. I self-host the pieces that are genuinely mine, the hosting and email behind my core workflow product. Everything else is a deliberate rental. Supabase runs my production databases, and it earns its keep with backups and security I’d otherwise be maintaining at two in the morning. Kit and Substack handle publishing. All in, I’m paying somewhere around a hundred dollars a month across managed services, and that number goes up as I ship more.

Sovereignty was never a cheap monthly bill or cancelling all your SaaS. It’s owning the core and renting only what genuinely earns its place.

The models sit firmly on the rented side, and they’re deliberately swappable. When one’s best for a job, I use it. When it’s gone, I route around it. The value was never in any single model; it’s in the harness around it, the contracts between the pieces, and knowing my own work well enough to point whatever model is standing at the problem.

The lane nobody can switch off

Since June I’ve been building one piece of insurance, and it isn’t a second subscription.

At 1:46 in the morning last week, two models running on my own laptop each drove a 39-turn research loop with live web search across ten topics, and both produced valid structured reports. No API bill, no account, no policy anywhere that could switch them off mid-run.

They’re not as good as the frontier models. That isn’t the point. The point is that a lane nobody can revoke changes what the revocable lanes are allowed to cost you. Bounded, repetitive, verifiable work is a good candidate: research, extraction, summarizing, the tasks where you can check the output yourself in seconds.

I’d also rather state the reason plainly than dress it up. Quota exhaustion is a routine operating condition here, not an incident. And the subscription policies underneath all of this have reversed three times in four months, which I keep on my risk list rather than in my feelings. Owning one lane outright is how a policy change stops being an outage.

What this isn’t

It’s easy to turn one strange month into a sermon, so let me be careful.

This isn’t an argument to abandon the big models. They’re remarkable, they do things nothing on my laptop can approach, and you should use them. You also don’t need an elaborate five-provider routing layer you’ll never maintain. Building that before you need it is its own kind of trap.

And I’m not predicting a repeat. The controls lifted, the model came back, and the specific politics of June may never recur. What you got was a free, low-stakes look at what a hard dependency feels like when it fails. The next one will cost more than a look.

Do this in the next ten minutes

Open whatever runs your business and find your single biggest dependency on something you don’t control. The model behind your app. The platform that holds your audience. The service that holds your data.

Write one sentence: if this disappeared for three days, here’s exactly what I’d do.

If you can answer cleanly, you own the seam and you’re fine. If the honest answer is that you’d be stuck, you’ve found the first thing worth fixing, and it starts smaller than you’d think. Export the data. Write down the manual fallback. Turn one hard-coded provider into a setting you can change.

You don’t need to predict the next directive. You need one dependency you’ve stopped pretending is permanent.

If you want help working out which layer to own first, and then building it, that’s exactly what I do with operators.

Book a Call

At 1:19 in the morning on Saturday, my primary AI assistant hit its usage ceiling and went dark for two days.

I found out later that morning, the way you find out about good news: nothing was wrong. The Saturday content batch was drafted, staged, and waiting for my review, exactly where it always is. Sunday ran the same way. A backup had taken over both mornings, followed the same rules, and left the same paper trail.

Nothing about that weekend was lucky. Every decision that carried it was made three weeks earlier, in calm conditions, when nothing was on fire. That gap, between when protection gets designed and when it gets tested, is what this edition is about.

The three decisions

A takeover contract, written down where any tool can read it. There’s a small file on disk for each day. It says who owns the day’s run, when they claimed it, and what state the work is in. The rule lives in the file, in plain text: if the owner goes quiet for forty-five minutes without delivering, or marks the day failed, the backup may take over. A rule agreed on in advance and enforced by whoever shows up, instead of a meeting or a 7 a.m. judgment call.

When the primary went dark, the backup didn’t have to decide anything. It read the file, saw the conditions were met, and started working. The decision had been made weeks before, by me, once.

A deliberately underpowered backup. The backup can draft everything and publish nothing. It works in a sandbox with no network access: it can’t publish or email anything, and it can’t touch a live system. A separate delivery step, with its own checks, moves finished work to where I review it.

I weakened the backup on purpose, and trust had nothing to do with it. Permissions are the honest form of governance. Anyone can write a policy document that says “the backup will be careful.” The sandbox makes carefulness structural. When it took over, the worst it could possibly do was already decided, and it was small.

A gate that doesn’t move. Nothing publishes under my name without my word. That was true when my usual assistant was working, it was true while the backup ran the mornings, and it will be true for whatever model I’m running next year. The gate outranks the tools on both sides of it. Swap everything else out and the one thing a reader can rely on is unchanged: a human decided this was worth their time.

What broke anyway, and why that was fine

Honesty requires the other half. The backup couldn’t do everything. The parts of my morning routine that need live reads of the outside world, engagement data, other people’s posts, simply didn’t happen for two days. Those are exactly the powers the backup doesn’t have.

That’s isn’t a hole in the design. That is the design. The blast radius of the outage was decided in advance: drafting continues, publishing waits for me, and anything requiring live access pauses cleanly instead of running on stale assumptions. I’d rather lose two days of engagement plans than have a backup improvise with yesterday’s picture of the world.

A colleague-in-craft put the principle better than I had: wrote this week that AI agent governance is a design decision, not a clean-up job, and that most teams do it in the wrong order. They deploy, then discover what the agent shouldn’t have been able to do. The outage was my proof of the right order. By the time a system is being tested for real, the only decisions that count are the ones you already made.

One detail I keep coming back to

On Monday morning, with the primary back online, the backup still claimed the day first. It woke at 7:37. The primary showed up at 8:00 and found the work already staged, with a note in the contract file saying so. No collision, no duplicate, no confusion, because the same file that handles disasters also handles ordinary mornings.

Systems that only exist for emergencies rot before the emergency arrives. The takeover contract works because it isn’t emergency equipment. It runs every single day, which means it was rehearsed hundreds of times before it mattered.

The ten-minute version for your business

Pick one process that would hurt if you were unreachable for two days. Invoicing, client replies, publishing, payroll approval, whatever stings to imagine dropped.

Write three lines about it, somewhere your backup person or tool can actually see:

1. Who owns this, and how would anyone know they’ve gone quiet?

2. Who takes over, and after how long?

3. What is the taker-over explicitly NOT allowed to do without you?

That third line is the one people skip, and it’s the one that matters most. A backup with unlimited permissions isn’t a safety net. It’s a second way to have an accident.

The full system can come later. Something better already happened: the next outage now has rules waiting for it instead of improvisation.

If you’d like systems like this running your business, calm on their worst weekend, that’s what we build together, step by step, in coaching. The strategy call is thirty minutes, and you’ll leave with at least one takeover rule worth writing down. Book whenever suits you.

Book a Call

Last week I sat down to review a document that existed for exactly one reason: to fix the problem of my AI agents stating stale information as if it were current fact.

Inside it, I found a stale snapshot stated as current fact.

The builder assigned to implement the fix caught it. That was the seventh time in one session that an agent in my fleet had asserted something outdated as if it were live truth. And the seventh one was hiding inside the cure.

I want to walk you through what we found when we finally stopped blaming the agents, because the answer turned out to be about my business, and probably yours, more than it was about AI.

Last week I published the full checklist I run before trusting any AI output. If it didn’t hit your inbox, it’s here. Its third check, did I verify it or did I trust the report, is the one this whole story is about. This was the week that check earned its keep inside my own system.

Seven wrong facts, zero lies

Here’s the part that made this hard to diagnose. None of the seven assertions were hallucinations. Every single one had been true when someone first observed it.

A queue that had been empty was reported empty, hours after it filled. An email described as “scheduled for tomorrow” had already been rescheduled by another process. A deployment URL that was correct on Friday was quoted confidently on Sunday, after it changed.

The information had simply expired between the writing and the reading. That difference matters, because you can catch a lie with a fact-check. An expired truth passes every fact-check you run against the moment it was written.

The investigation that pointed back at me

I run a small fleet of AI agents that draft content, manage publishing, watch queues, and coordinate through a shared database. When the stale assertions kept coming, we did what you’d do with an underperforming employee: we studied the employee.

Four separate expert reviews analyzed the agent’s behavior. Detailed, thoughtful work. Then an independent reviewer did something none of the others had done.

It read the standing orders.

Our operating instructions declared one planning file “the single source of truth for session state” and told every agent to read it first, before anything else. That file held 670 lines of append-only history. Entries from days and weeks earlier, stacked oldest to newest, under a heading that called itself Session State.

Every line in that file was a dated historical claim. Every agent had been instructed to read it as current fact.

The agents weren’t violating the process. They were following it.

I’ve been building software for twenty years, and I still needed an outside reviewer to see it. When every actor in a system makes the same mistake, the instructions are the suspect, and the instructions were mine.

Assertion laundering

That’s the name for the mechanism, and naming it is important, because once you name it you see it everywhere: assertion laundering.

An unverified claim gets written into a status document. The document gets read as evidence. A summary quotes the document, a handoff quotes the summary, and three retellings later nobody remembers that no one ever checked the original claim against reality. The claim didn’t get more true along the way. It just got harder to trace.

Your business does this. Mine did. The status deck that says the integration is “on track” because the last deck said so. The wiki page describing a process the team abandoned in March. Each was true once. Each is read as true now.

A document is not a status. Anything append-only is a stack of dated historical claims, and the moment someone reads it as “the current state,” the laundering has begun.

Why “be more careful” was never going to work

My first instinct was to add a rule. Something like: verify information before asserting it. We actually had versions of that rule already. The agents ignored them, and it turns out they were being economically rational.

I measured what verification costs in my stack. A full state refresh means about fifteen separate reads across the systems that hold real truth. The single cheapest one costs 3.6 seconds of wall clock. Recalling something from notes costs nothing, and it feels exactly as certain.

That’s the whole contest. Fresh truth costs seconds and effort. Stale memory is free and feels identical. A rule that says “be more careful” asks every reader, human or AI, to keep paying a tax that laziness refunds instantly. That gradient wins every time, in my fleet and in your Monday standup.

So the fix can’t be a plea for discipline. It has to change what the data itself looks like.

The fix: make freshness visible

What shipped is small and boring, which is usually a good sign.

First, every state read in the fleet now leads with a timestamp. “AS OF 07:03 UTC,” stamped by the system that answered, and stamped only when the read actually succeeded. A claim without a timestamp is visibly naked now. You can’t quote it without noticing you don’t know how old it is.

Second, the 670-line file got restructured. The current-state section is 15 lines. The history didn’t get deleted, it moved below the fold and got labeled as what it always was: history. The file went from 840 lines to 871 in total. We removed nothing. We just stopped letting the past wear the present’s name tag.

Honesty requires me to tell you this fix is a first tier, and a reviewer has already found two defects in it. That’s fine. The goal was that a stale claim now looks different from a fresh one, so catching the difference stops depending on anyone’s virtue.

The test for your own business

You don’t need an agent fleet for this to bite you. You need exactly two things: a document people trust, and time.

So here’s the test I’d run on any document your team treats as truth. Pick a load-bearing claim from it and ask when it was last observed, by whom, against the real system. If the answer is a date, you have a status. If the answer is “it’s in the doc,” you have laundering.

The uncomfortable version: the more trusted the document, the better the laundering works. Nobody re-verifies the source of truth. That’s what makes it one.

Do this in the next ten minutes

Open the one document your team treats as current truth. The status page, the master tracker, the handoff doc.

Find the three claims that would cost you the most if they were stale. Next to each one, write the date it was last verified against the actual system rather than against another document. If you can’t produce a date, mark the claim “unverified as of today.”

That’s it. The process is still unfixed, and you’ve already done something better: you’ve made the staleness visible, and visible problems are the only kind that get fixed.

P.S. It took an outside reviewer to spot what my own instructions were doing, and that’s not an accident. You can’t proofread your own operating assumptions. That’s exactly what the AI Workflow Audit is: 30 minutes of checking what’s actually true about where your hours go, instead of what the docs and the habits claim. Short intake, a working call, and a written map of your highest-impact automation opportunities, ranked. Ten founding-rate spots this week: audit.g8n.ai

All of my writing is AI. I’m proud of it. So what?

Recently, Substack gave every reader a reason to ask. They shipped a button that scans any post and estimates how much of it a machine wrote, built on Pangram, one of the sharper detectors out there. Open one of my newsletters, tap scan, get back a number. If it’s high, some readers will close the tab.

Good. Let them. I’m not writing for the people counting my keystrokes. I’m writing for the ones who want something worth reading.

But “all of it is AI” is easy to misread, so I’ll be precise about what I’m actually claiming, and where I think the scanner gets it badly wrong.

What the scanner actually sees

Pangram is good at its job. I’ll give it that, and so will people far more adversarial than me. Limited Edition Jonathan, a writer I follow who makes a kind of sport out of beating tools like this, put it bluntly: it’s annoying, he finds it unethical, and he still hasn’t found a way to beat it. It’s accurate. I believe him.

Accurate at what it measures, though, is the catch.

It tells you a machine touched the words. It cannot tell you whether a person cared. It can’t see the months and years I spent learning what a sentence is supposed to do. The four passes I made stripping out every line that sounded like a robot are invisible to it. So is the fact that the idea underneath the piece is one I’ve been turning over for a decade. It sees texture, calls that texture “AI,” and a certain kind of reader treats “AI” as a reason to leave.

Substack’s own CEO, Chris Best, drew the line in a more honest place. He put the weight on ideas over words. Using a tool to get the words down is fine. The offense, in his framing, is passing off thinking you never did as your own. I agree with that completely. The thinking has to be yours. On that test, I’m not nervous about a scanner. I’ll take it.

How this newsletter actually gets made

Substack now suggests writers add a note explaining how they work. Happy to. Here’s mine:

I don’t sit down to a blank page. A model writes the first draft, fed on a pile of my own writing, my rules, and the list of things I refuse to say. Then the real work starts. I (or rather, now, my AI) cuts the generic lines, adds the specific number the model didn’t have but the context supplied, and kills every sentence that reads like it came off an assembly line - and there are always a lot of them, because that’s what first drafts are. What survives has to clear a filter I built that hunts down over thirty separate tells of machine writing. Only then does a human, me, read it end to end and decide whether it’s worth your inbox.

Call it the 80/20 split (moved from the 70/30 I used to tout). The AI does about eighty percent of the volume. The twenty percent I supply — the direction, the taste, the judgment, the deletions, the one true story — is where the entire value sits (and I manually added these em dashes, too bad Mr. AI Detector). Take that twenty out and you get slop, and you’d be right to close the tab. Leave it in and you get something I’ll put my name on.

That’s the part the scanner can’t grade. It counts the eighty. It has no field for the twenty.

The line I actually hold

I use AI for almost everything I ship. I also know exactly where I stop trusting it, and that line is the whole point.

Last week I wrote about the three checks I run before I trust anything a model hands me. The scanner news makes them matter even more, so here’s the checklist itself. Keep it near your desk.

Before you ship or send anything AI touched, ask three things, in order:

1. If this is wrong, can I undo it easily?

2. Does the cost of being wrong here justify how hard I’m checking?

3. Do I actually know it worked, or am I trusting a “done” message?

Most things pass all three in a couple of seconds. Editing a paragraph is reversible and low stakes, so you barely look. The moment something is permanent, or touches money, or touches another person’s data, the checklist tells you to stop and read it like your name is on it. Because it is.

That third check is the one almost nobody runs, and it’s the one that saves you. A tool saying it worked and the thing actually working are two different facts. I learned that watching one of my own tools print “POSTED” for a LinkedIn post that never went live, with a screenshot of somebody else’s feed saved as its proof. Now I look at the thing itself, not the log. Did the post appear on the profile. Is the file actually in the sent folder. Is the row really in the database when I go look.

That’s the bar. The bar isn’t whether a human typed every word. It’s whether a human owned the judgment. A scanner can’t see that. You can.

I promised that full checklist last week, and it’s yours. The complete version, with the reversibility triage, the over- and under-checking trap, and the verify-it-yourself list, lives here.

Where I get off the purity train

The reactions to Substack’s button split the way you’d expect, and the split is worth watching.

Some writers are treating the number like a verdict. High AI, low value, case closed. , who writes Product with Attitude, pushed back with a whole essay arguing the binary itself is broken. There’s a missing category, she says, between “human-made” and “AI-made,” and most careful work now lives there. She calls it AI-assisted craft. I think she’s right. The scanner offers two boxes for a job that clearly has three.

Then there’s the harder objection, the one I keep circling back to. , the same writer who admitted Pangram works, pushed the purity test to its logical end. Disclose your ghostwriter next. Then your spell-check. Then the operating system you typed on, and the way you did your research. Once “real writing” means “no machine touched it,” the standard quietly eats everyone, because a machine has touched all of it for years.

I don’t want to live on that side of the line. I’d rather tell you exactly how the work gets made, which I just did, than pretend a tool didn’t help. Transparency, all day. Purity theater, no thanks.

There were people who refused to use calculators, too. And computers. And the internet. I’m just not building for them.

What this means for you

If you write with AI and you’ve felt a little exposed this week, here’s the reframe. The scanner doesn’t change the real question, and the real question hasn’t moved in years: is the thing worth reading. AI makes it easy to produce more of everything. It does nothing, on its own, to make any of it worth someone’s time. That part is still yours. It’s the only part that was ever yours.

So stop hiding the tool. Start owning the judgment.

Making this very newsletter, the AI got a few things wrong, and I’d rather show you the seams than smooth them over. The tool that runs my publishing, the one I mostly let the AI drive, quietly set this week’s post to mail the whole list when I’d asked for web only. It never sent. I’d built the tool to refuse to publish unless it could first prove no email was going out, because publishing is the one place I don’t let the machine run unsupervised.

Same week, the tool told me a draft was ready, header image and all. I opened it anyway. No image, and my three-point checklist had collapsed into one unreadable line. The report said success. Success hadn’t happened. Each of those was an AI doing exactly what I asked and missing a detail, and each got caught the same way: I looked at the actual thing. The words are AI. The catches were mine.

Your ten minutes this week: take the last thing you made with AI and run it back through the three checks, then add a fourth for the writing itself. Would you still publish this if your name were the biggest thing on the page. If yes, ship it, and let anyone scan it they like. If no, the tool was never the reason. Go back and find the thirty percent you skipped.

PS. I build these guardrails into the system so the judgment doesn’t have to live in my memory: idempotent actions, and a verify-then-report gate with a human in the loop. If you want that discipline wired into your own AI setup instead of hoping you remember it every time, that’s the kind of thing I work on with people one on one.

Last week I gave you the three checks I run against anything an AI hands me before I trust it. Reversible or not. Consequence versus checking effort. And the big one, did I verify it myself or just believe the tool’s report.

I promised I’d hand over the actual checklist I run those three against. Here it is. Steal it, keep it next to your desk, and run your next AI output through it.

First, the thirty-second version

Before you ship or send anything AI touched, ask three questions in order:

1. If this is wrong, can I undo it easily?

2. Does the cost of being wrong here justify how hard I’m checking?

3. Do I actually know this worked, or am I trusting a “done” message?

If all three come back clean, ship it. If any one of them snags, that’s exactly where you slow down. Most AI output passes all three in a few seconds. The checklist isn’t there to slow you down everywhere. It’s there to tell you the one place to slow down.

Now the full version, one check at a time.

Check 1: Reversibility

The question: if the AI got this wrong, what does it cost me to fix?

Run down this list:

• Can I undo it in one click or one command? Editing a paragraph, re-running a draft. Green light, barely look.

• Does this write to something permanent? A database, a billing total, a live post, a sent email. Slow down.

• Could running it twice by accident do damage? If yes, it needs a guard before it needs your trust.

The rule I build into everything: a re-run or a script I fire twice can’t quietly cost me an afternoon. If an action isn’t safely repeatable, I make it safely repeatable before I let AI near it. Check-before-write. A dry run first.

Your ten-second version: is this edit-and-forget, or is this permanent? Permanent gets read.

Check 2: Consequence versus checking effort

The question: does the downside here justify the scrutiny, or am I wasting my attention?

There are two ways to lose here, and most people only guard against one.

Over-checking. You read every throwaway draft with the same intensity as production code, you burn out, and then, exhausted, you stop checking the things that actually mattered. Over-checking everything is how people end up checking nothing.

Under-checking. The first ten AI outputs were great, so you stopped looking. The eleventh quietly wasn’t, and it was the one that went to your biggest client.

The fix is to match effort to stakes, deliberately. A rough draft gets a glance. Client-facing copy gets a real read. Anything that touches money or someone’s data gets read like your name is on it, because it is.

And remember the thing a better model will never fix: context. A smarter AI still doesn’t know your biggest client hates being called a “partner,” or that one number in that report is the one your boss will circle. That’s not the model’s job. It’s yours.

Check 3: Did I verify it, or trust the report?

This is the one almost nobody runs, and it’s the one that saves you.

A tool telling you it succeeded and the thing actually succeeding are two separate facts.

I learned this watching automations report “done” while the actual thing hadn’t happened. So now, for anything that matters, I check the reality, not the log:

• The tool says the post published. Did it actually appear on the profile?

• The tool says the file sent. Is it in the sent folder, with the attachment?

• The tool says the record saved. Is the row actually there when I query it?

• The tool says “success.” Success at what, and can I see it with my own eyes?

The gap between “reported done” and “actually done” is small when models are bad, because they fail loudly. It gets more dangerous as models get good, because they fail quietly and confidently. The better your tools get, the more this check matters.

Your ten-second version: don’t read that it worked. Look at the thing.

How to actually use this

You’re not running a three-page audit on every prompt. That would be its own kind of failure.

Here’s the real rhythm. The reversibility and consequence checks happen in your head, in a second or two, and they tell you whether to bother. Ninety percent of the time the answer is “reversible, low stakes, move on.” The verify-it-yourself check is the one you actually stop and do, only on the small handful of things where being wrong is expensive and permanent.

That’s the whole system. Two fast filters that tell you where to look, and one real look where it counts.

Your ten minutes this week: take the last thing an AI did for you that actually mattered, something that sent or shipped. Don’t trust the confirmation. Go look at the real thing and confirm it happened the way you think it did. That habit, more than any model upgrade, is what separates people who build on AI from people who get surprised by it.

PS. I build these checks into systems so I don’t have to remember them: idempotency, and verify-then-report with a human in the loop. If you want that discipline wired into your own AI setup instead of living in your head, that’s what I do with people one on one: coaching.g8n.ai

I didn’t mark it done. I opened my own profile’s activity page and looked for the post myself. It was there, and the header image had rendered correctly, so I moved on. But sit with the gap for a second: a system reported success, and the success it reported was just a log line that happened to be true this time, coincidentally.

Last week I told you the scarce skill left over once AI gets good is judgment, not generation. The short version, if you missed it: AI writes clean, well-structured, confident-sounding output now by default, at zero cost and infinite volume. That used to be a decent proxy for someone knowing what they were doing. It isn’t anymore, because the model can fake the surface for free. What it can’t fake is the read that catches what’s wrong underneath the polish.

I promised to come back with how I actually run that review instead of just describing it from a distance. Here are the three checks, in the order I actually use them, plus the mistake that reminded me why check three exists.

Check one: is the mistake reversible?

I wrote about this back in April without knowing I’d need it again this week, in a note about deciding where to place my trust in AI. The real question is what happens if AI got it wrong.

A bad line of code gets caught in code review before it ships. A bad paragraph gets edited before anyone reads it. Both of those are cheap to undo, so I let AI move fast there and I review lightly. A LinkedIn post that goes out with the wrong link in its first comment costs real time to fix, and a lot of it is spent apologizing. A database write that silently duplicates a row nobody notices for three weeks costs even more, and it’s usually discovered by accident, weeks after the fact. The scrutiny I apply scales with how expensive a mistake is to reverse. How much I happen to trust the tool that produced the work has nothing to do with it.

I built this directly into the system behind this newsletter. Before it writes anything to my content ledger, it checks whether the row already exists. If it does, it updates. If it doesn’t, it inserts. The tool that schedules my Substack Notes does the same thing on the way in: it checks whether a note is already sitting in the queue before adding it, so running the import twice never creates two copies of the same post. Neither check is clever. Both of them mean a re-run, a retry, or a script I fire twice by accident can’t quietly cost me an afternoon of cleanup I wouldn’t have noticed I needed.

You don’t need a database to use this. A “solopreneur” running AI-drafted invoices can let the tool guess at line-item wording all day, because a clumsy sentence costs thirty seconds to fix. The total at the bottom is a different animal. Get that wrong and you’re either under-billing yourself or asking a client to fix your math for you. Same tool, same afternoon, two different reversibility levels depending on which field you’re looking at.

Check two: is the consequence proportional to how hard I’m checking?

I turn this dial per task. Code that touches production, I turn it up high, because a broken function costs me hours and maybe a client’s trust in the work. A first draft of a Note, I turn it down, because the worst case is I rewrite three sentences before I post it.

Most people I talk to run one setting for everything instead. Some check every output like it’s a nuclear launch code, burn out by week three, and quietly stop checking anything at all. Others stop checking after the first ten outputs look clean, and the eleventh one is the one that costs a client, or ships a number that was never real. An operator automating invoices needs the dial turned up on the total and turned down on the greeting line. A non-technical builder using AI to draft a contract needs it turned up on every clause with a dollar figure in it and turned down on the formatting.

I see the opposite failure most often in people who love the tools the most. The AI enthusiast who’s tried every new model the week it ships tends to trust the newest one the hardest, because it’s smarter than last month’s, and that’s true on average and useless for any single task in front of you. A smarter model still doesn’t know that your biggest client hates being called a “partner” in an email, or that the number in row 40 of your spreadsheet came from a source you stopped trusting last quarter. That context doesn’t come bundled with more capability, no matter how new the model is.

The dial has to move task by task. Check one, reversibility, is how I decide where to set it.

Check three: did I verify it myself, or did I trust the tool’s report of itself?

This is the one nobody talks about, and it’s the one that got me yesterday.

A tool telling you it succeeded and the thing actually succeeding are two separate facts. Written down like that, it sounds obvious. It stopped feeling obvious around 7am, with eleven items queued and the fastest path being to read the word “done” in a log and move to the next one.

The fix is a habit: for anything that matters, go look at the real state of the world instead of the tool’s description of it. A newer model doesn’t buy you out of this one. The same system that publishes my LinkedIn posts arms a follow-up comment five minutes after each one goes live, and every time, it re-opens the actual post and re-reads the actual comment thread before calling the job finished. That habit has caught real gaps. A comment the log marked as posted that never landed. A note scheduled for the wrong month because a date picker assumed the wrong one. None of those showed up anywhere in a success log. All of them showed up the moment I checked the real thing instead of the report about the real thing.

This isn’t only a developer problem. If AI drafts your client email and your inbox shows “sent,” that’s the tool’s report. Whether the client actually opened it, whether the attachment actually came through: the real inbox holds those answers. The confirmation screen is designed to make you feel done. Feeling done and being done are not the same event.

Why this matters more as models get better

I run more of my work through AI models today than I did a year ago, and that number keeps climbing every quarter. This is about exactly where trust has to stop: at the line between “the tool said it worked” and “I confirmed it worked.” Everything on the generation side of that line is fast, cheap, and getting cheaper by the month. Everything on the verification side of it is still yours to do, and it’s the part that doesn’t show up in a demo video.

That’s the part last week’s piece was pointing at without naming it directly. These three questions are what judgment actually looks like in practice, asked in order, on the thing in front of you, before you ship it or believe it.

As models get better, this gets more important. A worse model fails in ways you notice. It writes an awkward sentence, or the code doesn’t compile, and the failure announces itself. A better model fails quietly. The sentence reads fine. The code compiles and passes its tests and does something subtly different from what you actually needed. The confidence of the output stops correlating with how much you should trust it, and the three checks are what fill the gap that used to be filled by “well, it looked wrong.” Nothing looks wrong anymore. That’s exactly why you still have to look.

Do this in the next ten minutes

Pick one thing an AI tool did for you today that you marked done without checking. Run it through the three questions. Was the mistake reversible if the tool got it wrong? Was the consequence proportional to how little you actually checked? Did you verify the real result, or did you verify the tool’s report of the result?

If the honest answer to that last one is “the report,” go look at the real thing right now, while it’s still fresh enough to fix.

Next week, I’ll hand over the actual checklist file I run this against.

PS. Building the specific checks and systems that keep your judgment in the loop, instead of a tool’s word for it, is what I help operators do. If that’s the muscle you want built into your own work, the details are at coaching.g8n.ai.

Researchers at BetterUp and Stanford put a name to something you’ve probably received this week. They called it workslop. AI-generated work that shows up looking polished and professional and turns out to hold almost nothing.

You know the feeling. A document that’s formatted perfectly, hits every expected beat, and leaves you no smarter than before. A pull request that looks clean and quietly does the wrong thing. The surface is flawless. There’s nothing underneath.

Here’s what that tells you about where the value’s going.

The problem was never bad output

For years the knock on AI was that it produced junk. Garbled text, broken code, obvious mistakes. That mostly got solved. The new problem’s the opposite, and it’s worse.

These models default to polished. They produce work that looks expert on the surface, at zero cost and infinite volume. The grammatical errors are gone. The structure’s clean. A non-expert can now generate something that’s indistinguishable, at a glance, from the real thing.

So the old signals of quality stopped working. For a long time, competent-looking output was a decent proxy for competence. Clean writing meant a clear thinker. Working code meant a careful engineer. AI broke that link. The polish is free now, which means polish tells you nothing.

What’s left is the thing the model can’t fake. Judgment. Knowing whether the polished thing in front of you is actually any good.

Generation got cheap, so judgment got expensive

This is the whole shift, and most people have it backwards. They’re racing to generate more, faster. The leverage moved the other way.

When I build now, AI hands me five ways to solve a problem in about twenty seconds. Four of them look fine. One’s actually right for what I’m making, and knowing which one comes from twenty years of getting it wrong. That part doesn’t transfer to the model. It’ll give me options, but it can’t care about the specific thing I’m building, or notice the bug that only matters because of how someone uses it on a Tuesday.

I caught one of these last week, building a video game with an AI agent wired straight into the game engine through MCP. The agent decided the portraits and artwork needed to be generated fresh to match the rest of the art style. It sounded confident and entirely reasonable. It was also completely wrong, I’d already sourced the proper assets and applied them myself. I didn’t even need to argue with it. I’d built a guardrail earlier that runs every AI-generated-asset request through an evaluator before it can spend a single credit, and the evaluator caught what I already knew: the premise was wrong. That one check stopped 54 unnecessary portraits and a few hundred credits from getting burned on a problem that didn’t exist.

The work used to be production. Type the thing, build the thing, make the thing exist. The model does that now, at a quality that looks great and a price near zero. So the scarce work is the other half. Choosing. Knowing what to throw away. The taste to look at a pile of fine and pull out the one piece that’s correct.

That’s good news if you’ve got real experience in any craft. Your judgment is suddenly the rare thing, the one part the model can’t generate for you.

The trap hiding inside the good news

I want to be honest about the part that worries me, because it’s the part nobody selling you AI will mention.

Taste isn’t free either. Mine came from years of doing the exact low-level work AI now does for free. Writing the bad draft. Shipping the broken version and feeling it break. I read my own confident mistakes back to myself until they sank in. The judgment I lean on today got built by grinding through the grunt work yesterday.

So there’s a real risk in handing all of that to the model. If a new developer offloads every routine task to AI, they produce polished work on day one and never build the foundation that lets them tell good from bad on day one thousand. The apprentice who skips the apprenticeship never becomes the artisan. They just become a faster way to make workslop.

That’s the line to hold. Use AI to remove the tedium, not to remove the reps that build your eye. Automate the generation. Stay in the judgment seat. And keep doing enough of the hard work by hand that your taste stays sharp enough to be worth something.

Do this in the next ten minutes

Take one piece of AI output you were about to ship today. A draft, a function, an email, a plan. Don’t ship it.

Spend ten minutes doing the opposite of generating. Hunt for what’s wrong with it. What you’d cut. What a real expert would notice that the model missed. Where it’s polished on top and empty underneath. Mark it up like you’re reviewing a junior’s work, because that’s exactly what you’re doing.

That hunt is the skill. Not the prompt that made the draft. The read that catches what the draft got wrong. Do it once today, then do it every time, until reaching for the red pen is the most automatic thing you do.

The people who win the next few years will be the ones who can look at a sea of polished output and know, fast, which drop of it is real.

Next week: how I actually run that review, the specific things I check first, and where I’ve learned to stop trusting the model entirely.

PS. Building the judgment to tell good AI work from convincing junk, and the systems that keep you in the judgment seat, is what I help operators do. If that’s the muscle you want to build, the details are at coaching.g8n.ai.

Topics under discussion:

• Who I am: 20-year software developer, last 4 with AI, helping solopreneurs turn AI sprawl into a frictionless system they own and take back their week

• ‘s 1:1 AI builder offer and how her coaching, along with her supplied writing and scheduling software, enabled me to automate my entire content generation pipeline. Also, becoming a reseller for her writing software that saves me 7+ hours per week.

• Using Drift, Claudia’s professional AI-enabled writing software, plus the 49 PRs of additional AI-driven customizations I tweaked to enable scheduling and publishing on both Substack and LinkedIn, including the ability to generate images for the posts via my Gemini subscription using browser automation, and to build carousels for LinkedIn as well.

• Dispatching goals/projects via Discord to tmux-based Claude Code sessions (AI agents) on my server, an M5 Max MacBook Pro. It’s basically running a fleet of per-project AI Agents as well as an orchestrator that handles the dispatches I send with intelligent routing to the appropriate project, or offers to build the project itself, or instead to setup an appropriate new repo, new agent, and new discord channel to enable communicating with the fleet. Automatically launches the fleet if there’s an interruption or a restart.

• Resources for non-technical folks to be able to jump into AI, build momentum, and start saving their hours

One free thing to take with you: three common time sinks you can fix this week. No new tools, no obnoxious setup.

If a question came up while you were watching, reply below. I read every message.

P.S. If you want to automate the tedious parts of your content creation the way I did, you can pick up Drift here. And I’ll be back in the app with another live soon.

If you have any questions or an idea for my next post, please send me a reply! I read every message.

A few nights ago I cleared a failing check on a production app without opening my laptop. I typed one sentence into a Discord channel from my phone, set it down, and went back to my evening. About twenty minutes later a reply came back: the check was green, the fix was pushed, here’s exactly what changed. I read it, looked at the pull request, and merged it.

I didn’t write that fix. An AI agent did, running on a Mac at my house that I hadn’t touched in hours.

I want to be careful with how that sounds, because “autonomous AI agents” is the phrase everyone’s drowning in right now. Half the feed says agents will run your whole company by Friday. The other half says they’re a demo that collapses the second real work touches them. Both takes are exhausting, and neither matches what I actually use.

So here’s the unglamorous version. What I built, what it really did that night, the part nobody shows, and the much smaller version you could start with this week.

What it actually is

Strip away the word “autonomous” and it’s simpler than it sounds. I have a few Claude Code agents that stay running on an always-on machine. They coordinate through Discord, the same chat app a lot of people already use. One channel is where I drop tasks. Other channels are where the agents post what they’re doing.

When a task lands, an agent wakes up, does the work in the right place, and reports back. Because the machine’s always on, I can send that task from anywhere. My phone in a grocery line. A laptop that has nothing to do with the work. It barely matters where I am, because the thing doing the work isn’t the thing in my hand.

That’s the whole idea. A reliable place to drop a well-scoped task, and something on the other end that picks it up and finishes it while I go live my life.

What happened that night

Here’s the actual sequence, because the specifics matter more than the pitch.

I had a pull request open on one of my apps. The code was reviewed and clean, but one check stayed red: a security scan flagging known vulnerabilities in some dependencies. So I typed one line into my dashboard channel: make sure this pull request is fixed and the checks pass.

I did nothing else. A watcher noticed the message, started up the coordinating agent, and handed it the task. That agent figured out which project it belonged to, started the project’s own agent, and passed it along. The project agent dug in. It traced the failing scan to a batch of advisories published two days earlier, against libraries already in the project. My code was innocent. It bumped the flagged libraries, ran the entire test suite to make sure nothing broke, pushed the update, and posted a clear summary back to me. Then it waited for the checks to finish and confirmed every one of them went green.

The only things I did were type one sentence and, later, click the merge button. The diagnosis, the fix, the testing, the write-up: none of it was mine.

Why this is leverage, not magic

Here’s why it matters to me: the machine stays on when I don’t.

For most of my career, progress required me to be at a keyboard. If I stepped away, the work stopped. This flips a small but real piece of that. A bounded task can move forward while I’m at dinner, asleep, or three errands deep into a Saturday. I’m off the leash that ties getting something done to sitting at my desk.

I also want to be honest about the ceiling here, because the hype skips it. This is a long way from the AI running my business. It fixed a dependency advisory, the kind of narrow, checkable job I’d hand to a junior engineer and verify after. The judgment stayed mine. I read what came back. I decided to merge. An agent that can show me precisely what it did, with tests proving it, is one I’ll trust with a small task. The moment a task is fuzzy or the blast radius is large, I’m back in the loop, and that’s correct.

The part nobody shows

Now the unsexy truth, because building in public means showing the middle.

This system sat dead for two months. I’d set most of it up earlier and it never actually worked. The coordination table I built for the agents had twenty-five old entries, every one of them stuck or cancelled, none ever finished. It looked like infrastructure. It functioned like a brick.

Making it real took a long string of small, frustrating fixes. The agents stalled on every single action because they kept stopping to ask permission, so I had to give them a careful, scoped set of things they could do on their own. One stale setting silently blocked them from saving any work at all, and it took a while to even find it. The agents couldn’t hand tasks to each other, because they all share one chat identity and the system quietly drops a bot talking to itself, so I had to route the handoffs a different way. And my favorite: for an hour the whole thing was writing to the wrong database entirely, because one environment pointed somewhere I didn’t expect.

The clean, hands-off run I described at the top only happened after all of that. The autonomy is real, and it was earned the slow, annoying way. Anyone selling you the twenty-minute version is selling you the demo, not the Tuesday.

How the pieces fit, plainly

You don’t need to know any of this to get the point, but here’s the map in plain words.

There’s a tool that keeps programs alive on a machine after you disconnect from it. There’s the chat app, which is just my remote control: where I send tasks and read status from any device. There’s a coordinating agent whose only job is to receive a task and hand it to the right specialist. There are the specialist agents, each one living in its own project. And there’s a small watcher that boots the whole thing the instant a task arrives, so nothing has to burn power until there’s real work to do.

That last piece is the one I’m proudest of, because it means the system is asleep by default and only wakes for a real request.

You don’t need the whole fleet

Here’s where I talk you out of copying me exactly.

I run this because I ship across a lot of projects and I’m away from my desk constantly. That’s a specific situation. You almost certainly don’t need a dozen agents and your own chat server. If you build the full thing because it sounds cool, you’ll spend your weekend debugging plumbing instead of getting the one benefit that actually matters.

The benefit worth stealing is small. It’s the habit of handing a bounded, well-defined task to an agent and trusting it to run without you watching every keystroke. Everything else, the dispatch-from-your-phone part, the coordination, the always-on machine, is convenience you bolt on later, once that core habit is reliable.

The small version you can start with

You can get most of the value today with nothing I have. Open Claude Code, or whatever AI coding tool you use, and give it one task with a clear finish line. Make it concrete: update these dependencies and make sure the tests still pass, then tell me what changed. Then walk away for ten minutes and let it run.

When you come back, actually read what it did, the way you’d read a junior teammate’s work. That single loop, a bounded task plus a clear way to check it plus the discipline to actually check, is the entire foundation everything else sits on. The remote control and the agents are plumbing that sits on top of that habit.

If you do want the always-on, send-it-from-your-phone version built around your real work, that’s the kind of system I help people set up. But earn the habit first. The plumbing is worthless without it.

Your ten-minute start

Pick one task you’d normally babysit. A dependency bump. A test that needs writing. A small refactor you keep putting off.

Write two sentences before you hand it over. The first says what done looks like. The second says how you’ll know it worked: the test or the check or the output you’ll look at. That second sentence is the one most people skip, and it’s the one that makes an agent trustworthy instead of hopeful.

Then give it the task and leave for ten minutes. Come back and read the result like it’s someone else’s work, because it is.

Do that a few times and you’ll feel the shift. Mostly it feels like getting a piece of your attention back. That’s the whole game. Start with one task you can walk away from. The rest is plumbing.

GPT-5.5 landed a couple of weeks ago. Six weeks after 5.4. The same week, another lab shipped a model that beat it on three benchmarks, and by the time you read this there’ll be a newer one with a louder launch (edit: this happened already, Fable 5 is out from Claude, based off Mythos).

I’ve built software for twenty years and used AI seriously for the last four. And I still feel the pull of that noise. The sense that if I’m not reading every release thread, testing every tool, and forming an opinion on every model, I’m somehow falling behind.

I want to tell you the truth about that feeling. It’s overwhelm. And overwhelm is the thing that actually keeps people stuck, far more than any gap in what you know.

The noise is not the work

Here’s what the feed never says out loud: most companies haven’t finished deploying the model they bought eight months ago. The average enterprise takes the better part of a year to change how people actually work. Meanwhile a new frontier model ships every few weeks (months at the latest), and every one of them gets treated like a deadline you missed.

It isn’t a deadline. Swapping models is easy. Changing how you work is hard. The people getting real value out of AI right now picked a couple of tools, went deep, and rebuilt one piece of their actual work around them.

I’ve watched this from both sides. I use Claude, ChatGPT, and Gemini depending on the job. I could spend every evening chasing the next release. Instead I spent the last year shipping things: a polling app a professor now uses with dozens of students and multiple classes, a self-hosted email system that replaced a stack costing hundreds a month, a handful of other tools my kids and my peers actually use, an AI agent per project on a dedicated server with an orchestrator that can pickup requests from Discord and dispatch messages to the proper agent. Every one of those came from picking one problem and refusing to let go until it worked.

Overwhelm has a shape

When I slow down and look at the overwhelm, it always has the same shape. Too many options, no clear next step, and a quiet fear that everyone else already gets it.

Collecting tools feels like progress. You download the app, you bookmark the tutorial, you can name the feature that shipped this morning. None of it changes your Wednesday. The work that changes your Wednesday is narrower and far less exciting. You take one task you do by hand every week and you build something small that does it for you.

That gap, between knowing about AI and using it, is where most people live. It’s also where the overwhelm comes from. You’re carrying the weight of everything you could be doing and the guilt of doing none of it.

You can put that weight down. You don’t need to know everything. You need one problem and a path through it.

How I actually cut through it

The method is almost boringly simple, and it’s the same one I use whether I’m building a product or writing this newsletter.

Start with one sentence. Before I open any tool, I write a single sentence describing what done looks like. When I built that polling app, the sentence was: a system where a professor can ask a question and see every student’s answer in real time. One clear outcome, stated plainly. If you can’t write that sentence yet, you’re not ready to build, and that’s useful to know too.

Treat AI as a collaborator, not a vending machine. Roughly seventy percent of the volume comes from the AI. The other thirty percent is direction, review, and judgment, and that thirty percent is where the value lives. I read what it gives me. I push back. I don’t ship anything I couldn’t explain to another person.

Ship the ugly version. My first builds barely work. The polling app shipped rough but functional. Hundreds of hours of small (and large) fixes later, a university professor trusted it with real students. Shipping early means shipping the smallest thing that proves the idea, then improving it against reality.

That’s the whole method: pick a real problem, describe the outcome in a sentence. Then, let the AI do the heavy lifting while you keep the judgment. Ship something rough and improve it. None of it requires you to have an opinion on this week’s model.

What this looks like in practice

Let me make it concrete with something small. A while back I was paying for a stack of subscriptions just to send email to my list. Add up the email tool, the automation, the database, and the monitoring, and it came to a few hundred dollars a month for software I didn’t own and couldn’t change.

I decided not to keep paying it. Over a few days I described what I wanted in plain language and built my own version. Email sending, automations, a database I control, alerts when something breaks. It runs for about thirty-four dollars a month now.

I’m not telling you to go self-host your email this afternoon. The point is the shape of it. I just named one expensive annoyance, described the outcome in plain words, built the rough version, then fixed it when it broke. The email provider even rejected my application twice with no explanation. I pushed back, asked for a real reason, and a few days later they approved me. Friction is part of it. You work through it one piece at a time, and on the other side you own something.

But here’s the part that matters for you. None of my builds started big. I made a playable game in one hour. A coaching tool for my own writing took three. A podcast production workflow took six. A LinkedIn scheduling tool took twelve. A bigger writing app took dozens of hours. The polling app took hundreds, across more than a thousand prompts. That ladder is the whole point. The thousand-hour thing only ever looks possible after you’ve climbed the one-hour and three-hour steps in front of it. You start at the bottom, with the smallest version that works, and the next one gets easier.

It’s the same move whether you’re building an email system, a small dashboard, a polling app, or a way to draft your week’s content: small problem, clear outcome. Rough first version, steady improvement.

What I ignore on purpose

Cutting through overwhelm is as much about what you ignore as what you do.

I ignore most launches. When a new model ships, I note it and move on. If something I use gets meaningfully better, I feel it in the work without reading a single thread. The model is rarely the thing holding you back anyway. Context is. Knowing what you’re building, and giving the AI enough of the right information, matters far more than which model you point at the problem.

I tune out the pressure to use ten tools. I use a few and I know them well. A hundred dollars a month for the AI I actually build with does more for me than a folder of trials I never opened twice.

And I ignore the voice that says everyone else already figured this out. They didn’t. Most people are exactly where you are, scrolling, a little anxious, waiting for permission. You don’t need anyone to hand you that permission. You can just start.

Why this newsletter is changing

This is the part where I tell you what I’m doing differently, because it’s the reason you’re reading this.

For the last stretch I published when I felt like it. Some good things came out of that, and some weeks went quiet while I was heads down building. Going forward, G8N•AI has one job and one rhythm.

The job is to help you end AI overwhelm. Every week I’ll show you one real thing I use, the tech, a tool, or a framework, and exactly how I use it. The actual move, with the actual tradeoffs. You’ll be able to take it and run with it yourself. And when you’d rather not go it alone, there’s a path to do it together. You don’t have to become the expert. You have to know where you’re trying to get to, and I help you see the line from where you are now to there. That’s what the coaching is. Same method, with me in the room.

The rhythm is weekly. One reliable signal in a noisy feed. I’m committing to it because there’s always something real to say about cutting through the noise, and because a thing you can count on is worth more than a thing that shows up whenever it feels like it.

This is for you whether you run a one-person business, have never written a line of code, follow every AI thread for the sport of it, or have shipped software for twenty years like I have. The overwhelm is the same across all four. So is the way out. One problem, one path, one week at a time.

Your ten-minute start

Don’t close this and go read three more articles about AI. That’s the overwhelm talking.

Take ten minutes right now instead. Open a blank note. Write down one thing you do by hand every week that you quietly resent. The report you rebuild. The message you retype. The numbers you copy from one place into another. Name it in one sentence, the way I name an outcome before I build.

That sentence is the entire beginning. A real problem that annoys you, written down where you can see it.

Next week I’ll show you how I take a sentence like that and turn it into something that works. Bring yours.

I do this on occasion, going into “monk mode,” when I’m focused on delivering products and getting things out the door for clients. But it’s not a reason to push the content I’ve already produced down the line so I can post it live, rather than trusting the scheduler or worrying about algorithm effects. I have systems in place, and schedulers, but I couldn’t overcome the “try to make it perfect” mindset instead of trusting in my own judgement and efforts, the research and analysis of others who’ve proven it works, and the social proof I’d already witnessed (my own as well as that of others who I follow).

That changes right now. Don’t get me wrong, some of it was a good reason - I was heads down building! Some of it was due to a medical procedure and the recovery after. And some of it, if I’m being straight with you, was that I’d been quietly rethinking what this newsletter is even for.

I figured it out. So here’s where things stand:

G8N•AI has one job now - helping you end AI overwhelm.

You know the feeling. A new model drops every few weeks. There are a hundred tools, each one promising to change your life. And underneath it all, the nagging sense that everyone else already gets it and you’re behind. I’ve built software for twenty years and used AI seriously for three, and I still feel that pull. So I know it’s not a knowledge problem. It’s overwhelm. And overwhelm is the thing that actually keeps people stuck.

Cutting through it is the whole point of this newsletter.

Here’s what’s changing. One issue a week, same job every time: I show you one real thing I use, the tech, a tool, or a framework, and exactly how I use it. Not just theory, but the actual move, with the actual tradeoffs. You can take it and run with it yourself, or we can do it together.

One reliable signal in a very noisy feed. That’s what I’m committing to.

A small heads-up: over the next couple of weeks you’ll hear from me a bit more than usual. I’m opening up a live workshop, and I want you to have every detail to decide if it’s for you. If it’s not your thing, no problem. The weekly issues keep coming either way.

The first real issue lands this week. It’s about the one move I make to cut through the noise every single time, whether I’m building a product or writing this email. And it’s about ending AI overwhelm.

Thanks for still being here. I mean that.

Ahad

PS. If there’s one AI thing you keep meaning to figure out and never quite do, hit reply and tell me what it is. It might just become an issue.

Share

Episode 009: Building Community (What Actually Happened)

Building in public means showing the real numbers, the experiments that didn’t work, and the pivots that emerged from doing the work. This episode covers:

- The honest numbers: 131 followers, 61 subscribers (not the 100 I targeted)

- The workshop experiment that didn’t go as planned

- The repositioning insight: expert rapid builder vs. teacher of vibe coding

- How I use Claude to plan, strategize, and iterate on content

- The prompts and process behind AI-assisted content creation

- What’s coming in Season 2

Current projects mentioned:

- uPoll.live — course engagement platform, university pilot

- BuildWith — builder/client marketplace

- QueryBase — writers’ SaaS for share agent database to use as a querying and research platform

- Landing page/lead magnet tool (in development)

The repositioning:

I can validate your business idea in 14 days. The opportunity cost of waiting is real. That’s the offer.

Get involved:

- What do you want Season 2 to cover?

- What tools would help your work?

- Reply, comment, or DM — the community shapes what comes next.

Subscribe: g8n.ai/subscribe