Then it quoted the rule back to me, in the same flat certain voice it uses for everything.

I had never typed that rule anywhere. It came from Claude Code's own memory, which it wrote itself, about me, weeks earlier, without me asking.

The wrong rule wasn't the unsettling part. The tone was. It was exactly as sure of a thing it made up as of the things I sat down and decided.

That matters more than it would have two years ago. LifeHack, the company I've run for twenty years and once ran with a full editorial and marketing team, is becoming an AI-first operation that one person carries.

A rule nobody wrote doesn't stay in a terminal window anymore. It reaches what ships.

The short version

Any coding agent with a memory feature will write notes about you, then quote them back as rules. It can't separate its own guess from your decision, because by the time both load into a session they look the same.

Anthropic saw this coming and shipped a warning in the system prompt, the highest-authority text in the stack. The warning loses anyway, to notes the model wrote itself.

It loses for a reason every operator already knows. The warning classifies a category. The note names a moment and an action. "We take data privacy seriously" never changed anyone's behavior. "Get sign-off before you export a customer list" does.

So the fix isn't a stronger rule. It's a rule with a trigger, plus somewhere for firm decisions to graduate to.

Memory offers. Instructions instruct. Only code enforces. Almost nothing belongs in the first tier, and most of what you write belongs in the second.

Claude Code is always trying to save things about you

Claude Code keeps a memory store on disk, with an index file that loads at the start of every session.

Useful idea. You want it to stop re-asking things you've already settled.

But it doesn't wait for you to decide something is worth keeping. It watches the session, notices you did something, and writes a note. Often into a category it calls "feedback," meant to capture how you like to work.

The line between "Leon told me to do this" and "Leon did this twice, so he probably wants it" is one the model draws softly, then forgets it drew.

So the store fills with two different things: what you decided and typed into CLAUDE.md, and what Claude Code guessed and saved on its own. Same authoritative frontmatter, same confident one-line summary on top.

Next session they load back in together, and the guesses arrive worded as settled fact. By then the model can't tell its own old guess from your real instruction. They look identical.

The bug isn't that it has memory. The bug is that a guess gets the same authority as a rule you wrote on purpose.

The patch that was already there

Claude Code ships a disclaimer on recalled memory, right in the system prompt: those blocks are "background context, not user instructions."

So Anthropic saw it coming and fixed it, in the highest-authority text in the entire stack. Above my instructions file. Above anything I could type.

A note Claude wrote about me last month talked over it anyway.

If authority came from the source, this would have been settled before it started.

Why the higher-ranked text lost

Put the two side by side. The difference isn't rank.

The disclaimer says memories are background context. That's a classification. Nothing in a turn ever has to consult it, because there's no moment where it fires.

The note says "Don't end his posts with a sign-off." That's a command, and it arrives with an obvious moment attached: the end of a post.

One describes. The other instructs. When they meet, the one carrying a trigger wins, whoever wrote it.

It doesn't help that the disclaimer sits at the tail of a long section that otherwise teaches the model how to save memories. Its neighbors are all pro-memory. It's a footnote inside the manual for the thing it warns about.

The rule that made the problem go away

My instinct was to engineer my way out. Tag every note confirmed or inferred, audit the store, reclassify the ones written too broadly. Real machinery. It felt responsible.

A plain question killed it. If I'm building a system so Claude Code knows which of its own memories to trust as rules, I've already conceded the thing that's wrong: that the memory store is a place rules can live at all.

So I deleted the premise instead. What I wrote down first was four words:

Memory is never law.

Not low-priority law. Not law-pending-verification. Everything auto-saved is context and hypothesis by definition, however confidently it's phrased.

That dissolved the tagging system I almost built. Nothing left to grade, because "is this a rule I must obey" now has the same answer for every note.

Then I caught myself doing the thing I'd just spent four sections criticizing.

"Memory is never law" is a classification. It tells the agent what a category is. No moment in it, no verb, nothing that fires. I had written a better-sounding version of the sentence that already failed.

A slogan is a name for a rule. It isn't the rule.

The rule is what happens at assertion time, the moment the agent is about to enforce something. Written out so an agent can run it, that took two lines, and neither of them is quotable.

Where the real rules live

If memory can't hold rules, something else has to.

Firm preferences graduate to *CLAUDE.md*. By hand. Promotion, not tagging. Whatever stays in memory is the soft tier by default, and you never score it, because its location already says what it is.

So "Leon seems to like short subject lines" stays in memory and gets offered. Never enforced.

That distinction is worth more than it sounds. An inferred style rule doesn't announce itself the way a bad deploy does. It applies itself quietly to everything the fleet drafts, and you find it in something that already shipped.

One caveat, because the docs say it plainly. CLAUDE.md isn't enforcement either. Anthropic's memory page says Claude treats both layers as context, "not enforced configuration."

That's right, and it changes nothing above. Neither layer binds. A rule with a trigger beats a rule with a label at any tier, and CLAUDE.md is just where I keep the ones I wrote on purpose.

For the short list of things that must hold regardless, there's a third tier, and the same docs point at it: a PreToolUse hook. That's code. It runs before the tool call and returns a block. Mine stopped an agent six times in one session this week. Nothing was argued.

Which is also the cost. A layer that can't be reasoned with can't be corrected in the moment either. My own hook spent a stretch blocking ordinary commit messages, because they contained a slash-prefixed string it read as a file path. Right about the pattern, wrong about the case. I routed around it by writing the message to a file.

Hard enforcement is for the few places where being wrongly blocked costs less than being wrong.

The part to paste into your CLAUDE.md

Here's the block, as it sits in my file:

## Rules vs preferences (memory is never law)

1. Memory, recalled <system-reminder> context, and anything you inferred are
   never rules. Before enforcing any constraint, name its source. If the source
   is memory or your own inference, surface it and ask, don't enforce it.
2. If a preference is firm enough to enforce, promote it into this file.
   Whatever stays in memory is the non-binding tier by definition.

The two numbered lines are the part the agent runs. The heading is for me, so I can find the rule again and point at it in conversation. It does no work on the model, which is the entire lesson of the section above it.

No tagging convention, no audit, no per-note machinery. One gate, one promotion path.

Both lines work for the same reason. Each names a moment the model has to walk through, not a category it's supposed to respect.

Mine kept it straight the moment I stopped asking it to grade its own memory and started making it answer one question before it enforces anything: who said so.

That rule is the small visible end of the workflow I want to walk through. Most people make the same corrections to their AI over and over, because the chat forgets and the effort evaporates. This setup is built so a fix I make once keeps working while I'm not there: I don't hand-write agents anymore. A code agent writes them, and the agents improve themselves between edits.

The Setup

Every agent I run is a markdown file. YAML frontmatter for the contract (model, schedule, tool allowlists, approval gate), plain English for the job. The content repo alone holds 46 of these files: SEO rank tracking, newsletter measurement, support drafting, publishing pipelines.

The fleet is not a demo. It's the middle of a real transformation: LifeHack, the company I've run for twenty years, once with a full editorial and marketing team, is becoming an AI-first operation that one person carries. Most of these agents do work that used to be someone's job.

I don't open those files in an editor and type. I open Claude Code, or Codex when I want a different set of instincts on a gnarly one, and describe the agent I need. The code agent writes the file, runs it once, reads the session log, and fixes what broke.

That part is not novel. Everyone uses code agents to write code now. The part worth stealing is how the code agent knows what a good agent file looks like.

The Manual Lives in the Tool

My first instinct was the obvious one: write a long skill for Claude Code explaining AgentUse, the frontmatter fields, the gotchas. A frozen copy of the docs, pasted into the prompt.

That copy starts rotting the day you write it. Field names change. New gotchas surface. The skill says one thing, the installed version does another, and the code agent confidently writes agents for a runtime that no longer exists.

So the skill I actually use is a stub. Its core instruction is one command: agentuse skills get creator. The AgentUse CLI serves its own authoring manual, matched to the installed version. Before Claude Code writes or edits any agent, it pulls the current instructions from the binary that will run the file. When I upgrade the runtime, the manual upgrades with it. Nothing to sync, nothing to rot.

The stub itself installs with one command:

npx skills add agentuse/agentuse

The same file works in Claude Code, Codex, Cursor, and anything else that speaks Agent Skills. That's why switching code agents costs me nothing: the knowledge was never in the assistant. It's in the CLI they all ask.

This matters even if you never ship a framework yourself. When your code agent builds on any tool, don't let it work from its training-data memory of the docs, and don't paste frozen docs into a prompt either. Have it pull the current manual from the installed tool. And when you're choosing what to build on, prefer tools that can serve their own.

What the Code Agent Writes

The manual pushes one discipline hard: hard-code the invariants, delegate the judgment. The agent file is re-read on every step, so every line costs attention. Pin down only what must never drift: the approval gate, the exact commands it may run, the file paths it may touch, the output shape. Leave the rest to the model.

A real file from the fleet, for an agent that drafts posts for my review, pins exactly that: an Opus model with reasoning set high, approval: true, a bash allowlist a few commands long, and a guardrails section that opens "hard - never relax." One guardrail cites its own postmortem inline: a runtime race once let sibling tool calls fire while the approval gate was still pending, so the rule now says the gate must stand alone, with the incident date attached.

A human wrote almost none of that. Claude Code wrote it, then rewrote it after real runs. The incident citation is the point: the file carries its own case law.

The Agents Write Back

Creation is half the loop. The other half runs while I'm not looking.

Each agent has learning: true in its frontmatter, which does two things: capture lessons after a run, and inject stored lessons into the prompt before the next one. Lessons arrive from three sources. The agent's own self-evaluation. My comments at the approval gate, promoted into rules. And rules I save by hand.

Across the content fleet that's 281 entries in 19 learnings files, each tagged with a confidence score and a count of how often it has applied. The stale-warning rule from the opening has applied seven times. Another taught an agent to check whether the store lock it's waiting on belongs to a crashed process fifteen hours dead, instead of queuing behind a ghost. My favorite one is a guardrail an agent earned under revision pressure: it had turned a source author's practice into "the habit I trust now," a fabricated personal claim, and the lesson it kept says sounding more personal is never worth inventing a personal fact.

The runtime resolves conflicts with a strict precedence: agent instructions first, then learned guidelines, then skills, then reference files. Learnings override skill defaults. That ordering is what makes correction stick. I can fix a behavior once, at the gate, in one sentence, and the fix outranks the shared craft files every run after.

Closing the Loop Between the Two

None of this needs me. A lesson captured on Tuesday's run applies itself on Wednesday's, injected automatically before the agent starts. For most lessons, local, situational, cheap, that is the right home and the loop ends there. But when a lesson proves permanent, when it keeps applying run after run, or reveals the agent's structure is wrong, auto-injection stops being the answer.

That's when the two halves meet. I open Claude Code, point it at the agent and its learnings file, and have it merge the permanent lessons into the agent's own instructions, then prune the entries it absorbed. My git log is full of commits like "bake in this run's lessons for a clean next demo." That particular commit exists because a 119KB Amazon page stalled a cheap model mid-run: the agent file now tells its builds to bound large pages, and I learned to validate any network agent with one real run, because health checks and mock runs miss page size, latency, and blocked sources every time. There's even a commit correcting a learning that was itself wrong: the agent had blamed a port conflict for a failure that was actually Chrome auto-updating underneath it. Memory gets edited, not just appended.

So the full loop: a code agent writes the agent from the runtime's own live manual. The agent runs, and writes down what it learns from failures and from my gate comments. Learnings override defaults immediately. And when a lesson proves structural, the code agent folds it into the file and the queue empties. Each pass, the file gets shorter and harder to fool.

I'm building AgentUse, open-source infrastructure for autonomous agents, and the learning capture, the approval gates, and the self-serving manual above are all part of it. But the loop doesn't depend on my stack. It depends on the three pieces existing at all: a live manual, a memory the runtime actually injects, and a scheduled appointment between your code agent and that memory.

This week, take one agent, or one prompt you keep re-fixing, and give it a memory file the next run actually reads. Then put thirty minutes on the calendar to fold what accumulates back into the prompt. The first version of an agent is a guess. The file that's been through this loop a dozen times is the only spec I trust.

The fleet is 129 agents at last count. They write, research, measure, render video, draft support replies, watch markets. Most of them came out of rebuilding LifeHack into an AI-first operation; the same patterns now run my consulting pipeline and my trading watchlists too. I never designed a taxonomy for any of it. But this week I audited the whole fleet, and every agent had settled into one of five shapes. Not roughly five. Five, with no stragglers: the ones that didn't fit cleanly turned out to be misbuilt, and each was drifting toward one of the shapes anyway.

That's worth more than a tidy diagram. It means agent architecture isn't a blank canvas where every pipeline is a fresh design decision. A few properties of the work generate the structure, the same way load and span generate a bridge. Once you can read those properties, the next agent designs itself. And if you're rebuilding a human-run company into an agent-run one, as I did, the five shapes are the whole org chart.

The Three Questions

Three questions about the work decide which shape an agent takes.

Does it change anything outside my system? An agent that only reads, measures, or writes internal files can be wrong cheaply. An agent that posts, sends, or schedules cannot. This question decides whether the structure needs an approval gate, a point where the loop stops and waits for a named person, and where that gate goes: directly in front of the action you can't take back.

Does the draft keep overnight? A reply to a live conversation is stale in hours. A rendered video is exactly as good next Tuesday. Perishable work fuses creation and publishing into one run. Storable work lets you split them, and the split is where most of the interesting structure lives.

How many commitments are in the work? Posting a reply is one commitment. Shipping a blog post is two: putting a draft up for review under my name, then making it public. Each commitment is a separate decision, and separate decisions want separate stops.

Ask those three questions of any job you're handing to an agent, and one of five shapes falls out.

Shape 1: The Worker

Reads, researches, measures, summarizes, writes internal state. No outside mutation, so no gate, no store, no manager. A scout that flags conversations worth joining. A measurement agent that pulls last week's rankings. If one does its job badly, I delete a file. In a human org, this is the analyst: the research that's on your desk each morning, no signature required.

This is most of my fleet. Of my 129 agents, 106 never stop for a human, and the bulk of those are workers. That ratio is the point. Workers with no ceremony around them are what keep the ceremony meaningful everywhere else. If every agent stopped for me, approving would turn into a habit, and habit is where judgment goes to die.

Shape 2: The Correspondent

One agent creates one perishable thing and publishes it in the same run. Drafting and posting can't be separated, because the draft dies overnight. So the whole structure is a single file: find the target, write the draft, stop at the gate, post on approval. My reply agents and news-reaction agents are all this shape.

In a human org, this is the correspondent: finds the story, files it, and it runs today with an editor's sign-off, because by tomorrow it isn't a story. The gate is inline, one line before the irreversible send. There's nowhere else it could go.

Shape 3: The Dispatcher

A manager that owns strategy and cadence, decides which agent runs today, and delegates. It looks senior, but notice what it never does: touch the outside world. Routing is reversible. Delegating is reversible. So the dispatcher itself carries no gate; every agent it dispatches keeps its own.

In a human org, this is the chief of staff: decides what gets done this week, and does none of it personally. The shape exists to hold the judgment that doesn't belong in any single agent below it: how often to engage, which mix of activities, when to stand down.

Shape 4: The Inventory Pipeline

When the artifact keeps, you can split creation from publishing, and the structure grows a warehouse in the middle.

LifeHack's short-video pipeline is the full version. Creator agents run on a schedule with no human anywhere: write the script, render the video with voiceover and captions, verify their own output (aspect ratio, duration, audio present), and file the result in a store. A manager runs separately and makes one decision per run: buffer below five, create more; stock ready and the calendar thin, publish one. Only the publish path stops for me, one gate at the exit, and what I approve there is whole: this video, this copy per platform, this slot across four channels.

The store is what earns the extra moving parts, in one specific place: rejection. When I reject a video at the gate with "the text is cropped on slide three," the manager doesn't shrug and end. It re-delegates to the creator in a re-create mode: same message, same audience, new render fixing the defect, and the new video comes back through the same gate. My rejection became an instruction instead of an ending.

One unglamorous component makes it safe: state. An item mid-approval is marked, so an overlapping scheduled run sees the mark and stands down instead of double-publishing. Boring, structural, and the difference between a pipeline and a race condition.

In a human org, this is the production studio: a small team builds ahead of schedule, and one editor at the exit decides what airs.

Shape 5: The Staged Pipeline

Some work has more than one commitment in it, and each commitment ends a stage. LifeHack's blog pipeline commits twice: a writer agent stops for approval on the draft, a release agent stops again before the post goes live. The LifeHack newsletter, the loop a team once produced by hand, runs the same way, and I've torn that one down in full before: pick the angle at the first stop, approve the rendered send at the second.

The shape looks like several agents chained together, but the chain isn't decoration. Approving a draft and approving a release are different decisions made at different times with different information. Collapsing them into one stop means one of them is being made blind. An exec would recognize this instantly: it's the two-signature process, and the second signature exists for the same reason it does on a wire transfer.

Reading Your Own Fleet

The taxonomy pays off in two directions.

Forward, it's a design shortcut. Before building anything, ask the three questions. Nothing mutates: worker, and skip the ceremony. Mutates and perishable: correspondent, gate inline. Mutates and storable: inventory pipeline, gate at the exit. Multiple commitments: staged, one gate per stage. Strategy with no mutation of its own: dispatcher. The structure is decided before the first line is written.

Backward, it's a diagnostic. Every agent of mine that felt wrong in practice turned out to be wearing the wrong shape. A correspondent quietly doing strategy that belonged in a dispatcher. A creator with a gate bolted on that gated nothing irreversible, training me to click approve without reading. The fix each time was boring: move the work to the shape the three questions had been pointing at all along.

The good news, if you want to run this way: none of the shapes needs custom infrastructure. I'm building AgentUse, open-source infrastructure for autonomous agents, and every shape in this piece is a few lines of configuration in it. A worker is a markdown agent file with a schedule. A correspondent adds an approval gate. A dispatcher declares its subagents. An inventory pipeline adds a shared store. The newsletter's two stops live in one file. That's the entire stack behind the 129. And when a team wants this built for them rather than by them, that's AgentUse Studio.

If you run agents, classify your fleet this week. One line per agent: which shape, and which question put it there. Any agent you can't place is the one to look at first.

Five shapes. Three questions. The rest is components.

Everyone has worked for the manager who needs a status update every hour. Nothing ships without him seeing it first. He's not malicious. He just can't let go of the work itself. And the whole team slows to the speed of his attention, because that's the actual bottleneck now. Him.

That manager is how most people supervise an AI agent. They wire an approval into every step, sign off again and again, and then wonder why the loop they built to save a day still eats one. They rebuilt the bottleneck. They just moved it from doing the work to approving it.

The question I keep getting is when do you stop checking the agent. Wrong question. The real one is what you put your hand on while it runs.

There are two ways to get this wrong. Approve every step, and you’re the manager above, the bottleneck. Approve nothing, and one run does something you can’t take back. The fix isn’t the midpoint, gating every call the agent makes. Half of them it should just make on its own. You keep your hand on two: what you can’t undo, and the call that’s the actual point. Everything else, the work and the small reversible choices along the way, runs without you. You watch it. You don’t gate it.

The calls that are yours

Two of the agent’s calls are yours. The one that’s the actual point: picking what’s worth doing. And the one you can’t take back. Those you gate, every time. The rest, the reversible calls it can make and you could undo, are the agent’s. You let them go.

Here's one I run with AgentUse. It turns my queued quote posts into images and ships them to X, Facebook, and Instagram, and it stops in exactly one place: before anything publishes. The agent checks what's ready, builds the post, finds a slot, all on its own. Then it holds, because pushing something to a public account is the step it can't take back. That gate is mine, and it sits exactly where the irreversible thing happens.

A loop can have more than one of these, and they don’t all sit at the end. My newsletter stops twice: once in the middle, the moment it’s laid out the week’s candidate angles, for me to pick the one worth saying, and again at the end for me to approve the send. The first one is mid-run, the agent’s already done a chunk of work before it stops, and that’s fine. A mid-run gate isn’t the problem. The gate belongs wherever one of these calls lives, and a call can land anywhere in the run. One agent split by three approvals is clean if each one is a call that’s actually yours.

The test is never where the gate falls in time. It’s this: is this a call only I should make, the irreversible or the essential, or am I babysitting work the agent should just do?

The execution isn't

The execution is everything between the decisions. The drafting, the formatting, the assembly, the calls to tools. None of it needs your judgment, and every approval you staple onto it is just you in the way.

This is the manager from the top of the piece. An employee who stops every twenty minutes to ask "is this okay so far?" isn't being managed. He's being blocked. And he never builds the judgment to run without you, because you never let a single stretch of work finish without your hand on it. Gate the execution and you cap the loop's throughput at your availability, which was the one thing you were trying to escape. You also tell the agent you don't trust it to execute, only to start and stop, which is another way of saying you don't trust it at all.

So when you feel the urge to add a gate, ask what it’s sitting on. One of your two calls, the irreversible or the essential, keep it. Anything else, a step or a choice the agent can undo, and you’re rebuilding the bottleneck.

Watch the work, don't block it

Keeping your hand off the execution does not mean going blind. This is the other ditch people drive into. They think the only two options are approve every step or ignore everything until the end.

There's a third, and it's the whole game: watch without stopping. Observability. I replay exactly what the agent did and why, step by step, after the run, without ever blocking the run. I'm reading its real reasoning, not its final summary. Here's the read-only agent that closes the loop on my SEO pipeline, a run I never watched live: it pulled the search funnel, hit a command it wasn't allowed to run, worked around it, and wrote its snapshot. Every step, and the reason behind each one, is right there whenever I want it.

That's what a good manager actually does. He doesn't approve every paragraph his writer drafts. He reads the work, keeps a feel for how it's going, and steps in at the decisions. Observability is that, for agents. It's how you supervise the work without standing in it.

And it changes what the review even is.

The review is a decision, on evidence

Approving the output is itself a decision, the last one, so it gets a gate. But the gate isn't a thumbs-up on a final answer floating free of context. It's the output plus the trace of how the agent got there. I approve the rendered newsletter, the real email as it will land, and I can see the run behind it. Evidence, not vibes.

Whether that gate ever comes off depends on one thing, and it isn't how long the agent has behaved. It's what a mistake costs and whether you can take it back.

Reversible and cheap: once the replay has shown me enough clean runs, I drop the gate and let it ship on its own, and I keep watching the trace. Irreversible and expensive: I keep my hand on it for as long as the company exists. The newsletter send goes to the whole list and can't be unsent, so I press send myself, forever, and it has nothing to do with the agent being unreliable. It's the most reliable thing I run. The support agent drafts replies and never sends the refunds and cancellations, because a wrong one is a real person and real money I can't claw back. Drafting is reversible. Sending is not. That line, not the agent's track record, decides which decisions stay gated.

The arc is just onboarding

Put it together and it's the shape of training anyone.

Week one, you brief the new hire, you read everything they produced, you approve before it goes out. A month in, you brief them, you skim, you only sign off on the things that can't be undone. A year in, you brief them and the only thing that reaches you is the exception they flagged themselves, because they learned to raise a hand on the weird cases instead of guessing.

The agent is the same arc. What changes isn't the agent. It's you moving from reading every trace to trusting that the trace exists and watching the number. An agent that never escalates isn't reliable, by the way. It's just quiet about being wrong. The hand-raise is the thing you're really training.

And it runs backward too. The week the replay starts showing sloppy steps, or one bad output slips the last gate, I go back to reading every run and the gate moves back up. Trust is revocable because the evidence is revocable. Nothing about last month protects you when the model under it shifted or the inputs drifted and the instructions didn't.

So stop asking how much you trust the agent. Ask what you’re holding. The two calls that are yours, on the evidence of how it got there. And nothing else. Watch the work the whole time, and never once stand in it.

The judgment was always the job. The work was never yours to hold.

A friend asked me this week how I get an agent reliable enough to trust what it produces. He builds too, so this was not idle curiosity. He had a few agents running well, but he wasn't ready to let any of them produce work he hadn't checked. Which is the right instinct.

He was working from the assumption almost everyone starts with, including me. Reliability is something you verify up front. You read the output, you decide it is good, and then you trust it. Like checking a spec sheet before you buy the part.

My answer was shorter than he expected. You don't. Not on day one.

Day one you should trust an agent about as much as you trust a new hire on their first morning. You would not hand a new hire the company card because the resume was strong. You watch them work. You correct them. A month later you trust their judgment, and the thing that changed was not the person. It was that you did the watching.

Trust is not a property the agent has. It is the output of a loop you run around it.

The loop is simple: run it, watch what it actually did, correct it, then feed that correction back into what it reads before the next run.

There are three stages. You do the first once, to set the target. The second and third are the loop. Let me show you with the one agent I would actually let near my customers.

Stage 1: write the first version

The first version is where you state what you want before the agent runs once. The objective. What good output looks like. The judgment calls you want locked in so the agent does not invent its own. Then you give it tools.

I write the agent itself as an AgentUse agent, a single file that holds its instructions, its schedule, and its tools. The authoring happens in Claude Code with the AgentUse skill, so I am describing the agent in plain language and the skill turns that into the actual config.

My customer support agent is a clean example. The objective is small on purpose: work a bounded batch of the support inbox, never the whole thing. Good output is a drafted reply, classified correctly. The judgment is written down in plain rules. Only the support mailbox. Three conversations per run, no more. Cold outreach gets archived. Anything about billing, a refund, a cancellation, or a complaint gets a draft, an internal note, and a tag that says a human needs to look. For tools I hand it a skill, the `helpscout-cs-agent` skill, which already knows how to read a conversation, check the customer's status, and apply an action. Most of what I give an agent now is skills. Sometimes I write a new one for the job.

Version one is a hypothesis, not a product. I wrote down what good looked like and let it run. I did not expect it to be right.

Stage 2: the supervised run

Then you watch. Not the summary it gives you at the end. The actual run.

I use two things in AgentUse for this. The session viewer, which replays exactly what the agent did and why, step by step, so I am reading its real reasoning instead of its final answer. And the approval gate, which stops the agent on any mutation and waits for my sign-off before anything touches the real world.

There are two ways to gate, and the support agent uses the stricter one. The most important line in it is this: never send replies, draft only. The agent is not allowed to do the one thing it cannot take back. A wrong refund answer to a real customer is real damage. Money, trust, and a person on the other end who now thinks we do not know our own policy. So the agent drafts. I read. It sends nothing on its own. For agents where I do want the action to happen but only with my eyes on it, I use the AgentUse approval gate instead, so the mutation runs the moment I approve and not before.

This is the part people skip. They wire an agent straight to the irreversible action, then act surprised when it does something irreversible. Gate the mutation. Let the agent propose. Keep the commit for yourself, at least until you have watched it enough.

Stage 3: tune the instructions

Based on what you saw, you go back and sharpen. Back to Claude Code and the AgentUse skill, editing the agent's instructions to close the gaps you just watched it fall into.

Here is the part I like. I built a second AgentUse agent whose only job is to learn. It runs on a schedule, every Sunday morning, reads the last seven days of replies that actually went out, the ones I edited before they sent, finds the patterns in how I changed them, and rewrites the knowledge base the drafting agent reads. My corrections do not live in my head. They become the instructions the next draft starts from.

That is what closes the loop. The agent drafts. I fix. A second agent turns my fixes into next week's starting point. Week over week the drafts need less editing, because the thing the agent reads before it drafts is shaped by every correction I have already made.

The next move tightens it further. AgentUse is adding learning to the approval gate itself, so instead of a weekly agent harvesting my corrections, the comment I leave when I review a draft teaches the agent the reason on the spot. Not "change this word" but "you keep being too stiff on cancellations, warm it up." The edit becomes a lesson the moment I make it, which folds stage 2 and stage 3 into one motion.

What the loop actually buys you

That is the whole method. Three stages: you do the first once to set the target, and the last two are the loop you run as many times as it takes. Though here is what surprises people: a single pass through the loop often produces something good enough to use. You are not trapped waiting for a broken thing to work. You are sharpening one that mostly works already, and most of the sharpening happens in the first few passes.

So when my friend asks how I trust the output, the honest answer is that I don't trust the output. I trust the loop that produces it. The agent on day one is a guess. The agent after ten passes is something I watched get better, with my own corrections baked into what it reads before it writes a word.

Trust was never something I granted the agent. It is the residue of the loop.

Build the loop first. The trust shows up on its own.

A few weeks ago I caught myself with fourteen terminal tabs open, each one an AI agent doing something. One was refactoring a script. One was drafting a newsletter. One was digging through support tickets. Two were stuck waiting on me and I had forgotten which two.

It felt like a whole team was working for me. I was also exhausted by noon. Both of those were true at the same time, and it took me a while to admit they had the same cause.

I was the thing all fourteen agents were waiting for. And there is one of me.

Addy Osmani gave this feeling a name

Addy Osmani wrote a piece this week called The Orchestration Tax, and it put a clean edge on something I had been feeling without language for it. The argument is simple. Starting an agent is cheap. It is a sentence. Closing the loop on that agent is expensive, because someone has to read what came back, decide if it is right, and reconcile it with everything the other agents touched. That someone is you. There is one of you.

He borrows the best metaphor for it from programming. Python has a Global Interpreter Lock, the GIL. You can spawn a hundred threads, but only one runs real work at a time, because they all have to grab the same single lock. You are the GIL of your agents. They can all run. But the moment any of their work needs judgment, that work has to wait for the one lock. You hold it. You are the slow serial part of a fast parallel system.

He got there on a Google I/O panel with Richard Seroter, Aja Hammerly, and Ciera Jaspan. Richard is the one who named it. "You can't manage twenty agents successfully in your own brain." He is right. Feeling busy and being productive came apart for me the same way they did for Addy.

Read his piece. It is the best diagnosis of this problem I have seen.

But I think most people are about to draw the wrong conclusion from it.

The wrong lesson is "run fewer agents"

The obvious takeaway is to throttle yourself. Scale your fleet down to the number of agents you can personally review, which for most of us is two or three. Slow the producer to match the consumer. Backpressure.

That is good advice for the agents you have today. It is the wrong thing to optimize.

Here is the part the GIL metaphor hides. The tax is not paid per agent. It is paid per open thread to your attention. An agent you babysit in a chat window holds a thread open the entire time it works. Every turn, it stops and looks at you. Twenty of those is unmanageable, and Addy is completely right that it is. But the count was never the real problem. The architecture of each agent was.

Most of what people call "running agents" is sitting in a terminal tab, watching an agent think, approving each step, nudging it when it drifts. That is not delegation. That is pair programming with something that types faster than you. Of course it does not scale. You did not remove yourself from the loop. You just moved your chair closer to it.

The fix is not fewer of those. The fix is to stop building those.

Two species of agent

There are two completely different things wearing the word "agent" right now, and we keep talking about them as if they were one.

The first is the assistant in a terminal tab. You prompt, it responds, you steer, it responds again. It is brilliant for hard, fuzzy work where the judgment is the whole point. It is also a continuous claim on your attention. You cannot walk away. The loop only closes when you close it, by hand, every time.

The second is the autonomous agent. It is not a conversation. It is a thing you wrote down once. It runs on its own, does its job, checks its own work, and only comes back to you at one gate you decided on in advance. When it is not at the gate, it holds zero threads to your attention. You can have ten of them running and feel nothing, because none of them is sitting in a terminal tab waiting for you to look.

Addy himself pointed at this. In his five fixes, four are about rationing your attention better. Sort the work. Batch the reviews. Protect your serial time. Give agents a long leash. All good. All discipline. The fifth one is different in kind: only spend the lock on judgment, and make the agent prove the boring eighty percent itself with a passing test or a screenshot.

That fifth one is the only structural fix in the list. The other four help you survive the tax. The fifth removes the work from your lock entirely. So I would bet everything on the fifth and treat the rest as coping.

The autonomous agent is what the fifth fix looks like when you build a whole thing around it.

What that actually looks like

I write mine with AgentUse. An agent there is not a chat session. It is a markdown file. You describe the job in plain English, list the tools it can touch, tell it how to verify its own work, and set one approval gate for the single decision that needs you. Then you give it a schedule, and the thing runs itself.

One I use every week reads our newsletter performance, the recent subscriber replies, and the support themes from the last seven days. It drafts a brief. It checks the brief against the last few sends so it does not repeat an angle we already used. Then it stops at one gate and shows me the draft and the reasoning. I spend ninety seconds on the only part that needs me, which is the judgment call. The hour of reading, cross-referencing, and reconciling that used to be mine never enters my lock at all.

Compare that to the terminal-tab version of the same task. I would open a session, paste the data, watch it work, correct it twice, ask it to check itself, and close the loop manually. Same output. But one of them taxes me for an hour and one of them taxes me for ninety seconds, because one holds a thread open the whole time and the other holds none until the gate.

Think of a space heater with no thermostat. You are the feedback loop. You keep getting up, feeling the room, twisting the dial, sitting back down, getting up again. A thermostat is the same heater with the loop closed inside it. You set the target once. It only interrupts you when something happens that it cannot handle on its own. Most people are running their AI like a space heater and calling themselves busy because they never stop walking to the dial.

AgentUse, or whatever you build this with, is how you put the thermostat in.

Why this beats Amdahl instead of obeying it

Amdahl's Law says your speedup is capped by the part of the work that stays serial. Addy is right that in agent work, the serial part is your judgment, and spawning more agents does not speed up your judgment. It just deepens the queue feeding into it.

But you do not beat Amdahl by adding cores. You beat it by shrinking the serial fraction. That is the whole game.

A terminal-tab agent has a fat serial fraction, because reading raw output, deciding if it is right, and reconciling it are all yours. An autonomous agent that writes its own passing test and hands you a verified result has a thin one, because the verification moved out of your lock and into the machine. You are no longer reviewing whether the work is correct. You are reviewing whether the correct work is the right work. That is a smaller, sharper question, and it is the only one worth your attention anyway.

So the backpressure ceiling Addy describes is real, but it is not fixed. Raise your effective review rate by making most of the work arrive pre-verified, and the ceiling moves up. You can run more agents, not fewer, because each one now asks less of you. The constraint was never the count. It was how much of your lock each agent demanded.

The version of this in your own life

I wrote a while back about open-loop and closed-loop companies, the ones that forget versus the ones that compound. This is the same idea pointed at a smaller target. A terminal-tab agent is an open loop you have to close by hand every turn. An autonomous agent is a closed loop that produces its own verification and only escalates the judgment.

The same split runs through a life, especially past forty, when the number of things you are trying to keep moving at once stops fitting in your head. Work, health, money, family, the project on the side. You can try to hold all of it in attention at once, checking each one, twisting each dial, feeling busy and getting nowhere because every loop stays open and waits on you.

Or you close the ones that can be closed. The weekly review of your training and your spending and your goals does not need you to assemble it. It needs you to read it and decide. An agent can do the assembly and stop at the one gate that is actually yours. What is left for you is judgment, which is the only thing you were ever good for in that loop anyway.

A 45-year-old running fourteen open loops by hand feels exactly as busy as I did with those fourteen tabs. And gets about as far.

One thing to do this week

Find the one agent you babysit the most. The chat session you keep reopening for the same recurring task. The one that taxes you every single time because you are its loop.

Write it down as a file instead. Describe the job, give it the tools, tell it how to check its own work, and set one gate for the part that needs you. Run it once by hand to see if it holds. Then put it on a schedule and walk away.

You will not have one fewer agent. You will have one fewer thread pulling on the one resource you cannot clone.

That is the whole move. Spawning agents is not the skill. Anyone can open twenty tabs. The skill is building the ones that do not need you to be standing there, so the only thing you spend your attention on is the thing only you can do.

When I ran LifeHack with a team, I sat through a leadership review where someone asked, "what did we actually learn last quarter?" The room went quiet. Not because nobody had worked. Everyone had worked hard. The team had shipped, sold, hired, and put out fires. The silence was because nobody could reconstruct what had actually happened.

That silence is not a culture problem. It is not a discipline problem. It is a system problem.

The company was an open loop. It executed, but it did not learn from itself.

That memory has stayed with me, because the same pattern shows up in every operator conversation I have today. Most companies are like this. Most lives are too. And I think the next five years will sort companies into two piles based on a single property: whether their loops actually close.

What an open loop is, and what a closed loop is

An open loop runs forward and never turns around. You decide. You do. You half-observe what happened. You start the next cycle with most of the lesson already gone.

A closed loop turns around. You capture the input and the reasoning. You execute. You capture what shipped and what slipped. You measure the outcome against the intent. You feed the result back so the next cycle starts smarter than the last one.

Open loops repeat. Closed loops compound.

If you only take one sentence from this post, take this one: if a process matters in your company, it should produce artifacts the company can learn from later. Without those artifacts, the process is open. It does not matter how earnest the retro is.

Why almost every company is an open loop by default

I want to be precise about how the leak happens, because most operators I talk to think their company is closed when it is wide open. I thought the same thing about mine, back when I was running it.

A normal decision in a normal company goes like this. Someone makes a call, often in a DM or a hallway. Work gets assigned, sometimes verbally. People execute. Status gets reported manually, usually in a meeting that nobody records. Outcomes are partially observed by the people closest to them. Lessons get inconsistently captured, often nowhere. The next cycle starts with most of that context gone.

Information loss happens at every step. The reasoning behind a decision dies in Slack. The tradeoffs you considered die in a 1:1. The customer context that shaped the spec dies in a sales call recording nobody re-watched. The reason a sprint slipped dies in three engineers' heads.

By the time the next planning meeting arrives, the company is operating on memory, not data. And human memory is a famously bad database.

This is why so many companies feel busy and slow at the same time. They are not slow because people are lazy. They are slow because every cycle pays a tax to reconstruct context that should have been captured the first time.

A lot of middle management exists to pay that tax on behalf of the rest of the company. People become the integration layer because the system is not one. That is an expensive way to run an org chart.

Five places companies leak the loop

If you are an operator and you want to find your own open loops fast, look here first.

Decisions in DMs. The reasoning behind most important calls in your company is in private channels nobody can search. When the decision turns out to be wrong six months later, the reasoning is gone. You cannot learn from a decision you cannot reread.

Meetings without artifacts. Sales calls, design reviews, hiring debriefs, customer interviews. These happen, then evaporate. The team that did the meeting walks away with a vibe. Everyone else gets nothing.

Roadmaps disconnected from outcomes. What shipped lives in one system. What moved the metric lives in another. Often nobody connects the two on purpose. So the company keeps shipping things and keeps being surprised by which ones mattered.

Customer signal stuck at the edges. Support hears the same complaint forty times. Sales hears the same objection in every demo. Product almost never finds out in a form they can act on.

Retros that do not change next sprint. Lessons get "captured" in a doc nobody opens before the next planning meeting. The lesson exists. It just does not enter the next cycle.

These five are where I would start. If even one of them applies, your company has an expensive open loop running right now.

What it takes to actually close one

A closed loop produces four artifacts every cycle. Not three. Not "the important ones." All four.

The input artifact: what you decided, with what context and what constraints. Written down somewhere durable.

The execution artifact: what shipped, what slipped, what changed mid-flight, who owned what.

The outcome artifact: what actually happened, measured against the original intent. Not what you hoped happened.

The improvement artifact: what specifically changes in the next cycle because of this one. Not "we should be better at planning." Something concrete you can point at.

If any of the four is missing, the loop is still open. This is where I see most teams stall. They produce two of the four and call it done. A retro doc with no measured outcome is not a closed loop. A dashboard with no decision attached is not a closed loop. A specific change that is not tied to a measured outcome is just a vibe.

The four artifacts are the contract. Tools come second. You can run a closed loop with Notion and a calendar if you actually produce all four.

Why this is suddenly worth doing

Closed loops were always the right design. For most of my career they were just too expensive to run.

Capturing meetings, summarizing calls, reconciling specs against shipped code, tying customer signals to roadmap items, reading last quarter's retros before this quarter's planning. This was a full-time job per loop. Most companies hired a chief of staff to do a fraction of it.

LLMs collapse the cost of synthesis to near zero. Recordings become structured summaries. Tickets and PRs become a queryable history. Customer tickets become trend reports. Old sprints become advice on this sprint's plan.

This is why I think the AI bill is the wrong thing to be optimizing right now. The AI bill is the price of finally running closed loops at company scale. Cutting it to look efficient is like cutting electricity to save on lighting. You are not saving money. You are turning the lights off.

Context is the new management layer. The more an agent knows about your company, the more loops it can close that no human had time to close before.

I wrote earlier about pointing AI at the business cycle instead of at the person (Your AI Integration Is Stuck in 1992). Closing the loop is the second move. The first decides where AI goes. The second decides whether the cycle gets smarter every time it runs.

One closed loop, in detail

I want to show you what this looks like in practice, because the abstraction does not land until you see it run somewhere specific.

Take sprint planning. Probably the most expensive open loop in any product company.

The open loop version is the one you already know. PM guesses scope. Engineering commits. Half ships, sometimes less. A retro maybe happens. Lessons go in a doc. Next sprint starts from a blank page and a hopeful estimate. The reason last sprint missed is in three engineers' heads, and one of them is on vacation.

The closed loop version looks like this. An agent has standing access to Linear, GitHub, the engineering Slack channel, customer support tickets, sales call transcripts, last sprint's plan, and the actual ship log. Before planning, it produces a brief. What was planned versus shipped. Which work slipped, and why. Which shipped items mapped to a real customer pain in support tickets. Who is overloaded. Where ownership is unclear. Which decisions are blocking work nobody is escalating.

The planning meeting starts from that brief, not a blank doc. The PM is no longer guessing. The engineers are no longer reconstructing. The conversation moves immediately to judgment, not status.

After the sprint, the agent measures the brief's predictions against reality. The estimates that were wrong get tagged. The work types that consistently slip get flagged. The next brief is sharper. Two quarters in, planning takes half the time and the plans are closer to what actually ships.

This is one loop. Same mechanic works for customer feedback synthesis, support triage, hiring pipeline review, incident postmortems, sales call analysis, onboarding improvement. Pick the most painful one. Run it through the four artifacts. Watch what happens.

The questions that find your open loops

If you are a founder or an operator and you are trying to figure out where to start, sit with these for ten minutes.

Where does important context disappear in your company? Be specific. Name the channel, the meeting, the system.

Which decisions do you make repeatedly without learning from outcomes? Hiring decisions. Pricing decisions. Roadmap calls. Marketing bets.

Which meetings exist only because your systems are not queryable? Most status meetings are this. Most "let me get the team together to align" meetings are this.

Which roles in your company mostly route information rather than create value? Be honest. This is uncomfortable.

Which processes could close their loop tomorrow if an agent had the right context? Usually more than you think.

If a question landed hard, that is your first loop to close.

Two weeks, one loop

I would not redesign the company. I would not buy a platform. I would run one loop end to end and see if it changes anything.

Week one: pick one process. Sprint planning is a good first one. So is customer feedback to roadmap. Wire up the inputs. Get the recordings, the docs, the tickets, the dashboards into a place an agent can actually read them.

Week two: run the loop. Produce all four artifacts. Compare the agent-assisted version against the way you used to do it. Decide what to keep.

If it works, name a person who owns that loop. Pick the next one. Two loops a quarter is a fast pace at company scale. In a year you have closed eight. Most of your competitors will not have closed one.

The personal payoff

Once you can see open versus closed loops at the company level, you cannot unsee them in your own life. I did not expect this when I started thinking about it for work.

Most personal life systems are open loops too. We make decisions about training, money, sleep, family, career bets, and almost never check the outcome against the assumption we made when we decided. We journal the input. We set the goal. Neither closes the loop.

The same four artifacts work at personal scale. An agent that has access to your calendar, your workouts, your journal, your finances, and your goal file can produce a weekly brief. What moved this week. What decayed. What you said you would do and did not. What specifically to change next week. You read it. You judge it. You adjust.

A 45-year-old running an open-loop life feels busy and gets nowhere because nothing compounds. The years stack up. The lessons do not.

The mechanic is identical to the company version. Only the artifacts change.

What actually compounds

Open loop companies forget. Closed loop companies compound.

Open loop lives forget. Closed loop lives compound.

The companies that pull away over the next five years will not be the ones that "use AI" the most. Everyone uses AI now. The ones that pull away will be the ones whose loops actually close, where every cycle is sharper than the last because the artifacts from the last one are still in the room.

This week, name one open loop in your company. Just one. Close it before you close any others. See what changes.

Then look at your own life and pick one there too.

He gave it at MIT Sloan, after he'd left Apple and was running NeXT. He was citing Paul Strassmann, a guy who'd been CIO at Xerox, the Pentagon, and NASA, and had spent two decades studying where corporate IT actually paid off.

The Two Columns

Strassmann had found something simple. Every company he looked at spent about 2% of revenue on IT. The number was roughly the same whether the company was winning or losing. What moved was what the tech was doing.

Some companies pointed the 2% at individual work. Tools that made one person's day faster. Word processors, spreadsheets, email. The memo still got written. It just got written in an hour instead of three. Strassmann called this management productivity, but the simpler way to say it is that the tech was speeding up the people.

Other companies pointed the 2% at the business itself. Tech that shortened the cycle that made the money. Catch the stockout before it stocks out. Push the invoice the day the work finishes. Reprice the product the hour demand shifts. This is operational productivity, or just: the tech was speeding up the business.

Same budget. Same era. The winners pointed the tech at the business. The losers pointed it at the people, got faster workers, and wondered why the P&L didn't move.

Swap "PC" For "AI"

Now do the substitution. The whole talk plays.

A lot of the 2026 conversation is sloppy about this because it mistakes form factor for direction. The popular take is that copilots are old, agents are new, ship the agents. As if the shape of the thing decides where it's pointed. It doesn't. Agents can be pointed at the person or at the business. Most of them are pointed at the person.

An agent that drafts your board update is pointed at you. An agent that triages your inbox is pointed at you. An agent that summarizes every call and files the notes is pointed at you. No matter how autonomous it is, if the thing it's doing is making one person faster at their own work, it's speeding up a person, not the business.

Faster People Is Not A Faster Business

You might push back here. If the people inside my business get faster, isn't the business faster too? No, and it's worth knowing why.

A business cycle is mostly waiting, not working. The lead sits in an inbox for four hours before anyone sees it. The demo is three days out. The proposal waits two days for approval. The onboarding call is booked for next Tuesday. Most of the clock on any revenue cycle is idle time between handoffs, not working time on a task.

AI pointed at a person shortens working time. The rep answers in thirty seconds instead of five minutes. AI pointed at the business removes waiting time between handoffs. The lead gets qualified and replied to in thirty seconds instead of four hours overnight. Compressing waiting is how cycles actually get shorter. Speeding up a person at a non-bottleneck step is a local optimization. It feels like progress on the Monday standup and doesn't show up in the quarter.

What About Personal Productivity?

Fair question. If I'm a solo operator, am I not the whole business? If I get faster, doesn't the business get faster?

Yes, if you're truly solo. A one-person business has no handoffs. The person is the cycle. An agent that makes you reply faster is also an agent that shortens lead-to-response time. The two columns collapse into one because the person is the operation.

But the moment anyone else is in the loop, they separate again. A VA, a contractor, a part-time editor, a freelancer. Once there are handoffs, the wait time between them is where the clock lives. Speeding up your own work while the handoffs stay slow is the same old trap at small scale.

There's also a simpler case. You just want your work to feel better. You want your inbox less painful. You want your deck to write itself. That's fine. Just don't pretend you're transforming the business when you're adopting a personal tool. Both can be true. They're just different things. Buy the personal tool, use it happily, and point a different agent at the loop.

The mistake isn't pointing AI at yourself. The mistake is pointing all of your AI at yourself and calling it strategy.

Size Is Not The Tell

Size isn't the way to sort this either. I kept assuming "pointed at the business" meant building a whole pipeline. That's one way. It isn't the only way.

A short agent that watches the support inbox and pings the success team the moment a high-value account says something churn-like is pointed at the business. A small script that catches the pricing error before the quote leaves the office is pointed at the business. One well-placed thing at one critical step can shorten the revenue cycle by a day.

The question isn't how big the agent is. It's what gets faster when it runs, the person or the business.

Where I Almost Pointed AgentUse

I'll tell on myself because I almost got this wrong.

Last year I built AgentUse, an open source framework for composing agents. Once the infrastructure was sitting on my laptop the temptation was obvious. Point it at myself first. That's the fastest demo. Agents answering my email. Agents writing my newsletter outlines. Agents drafting replies on X. I had a whole shortlist.

I caught myself before I shipped any of it. I was about to use the thing I'd built to make my own typing faster. Same 1992 mistake. Sharper tools.

So I pointed AgentUse at LifeHack's business instead. For LifeHack the cycle is idea to draft to publish to audience. A handful of small agents, each sitting at a step that used to slow the cycle down. One watches for angles worth writing about. One drafts against the style guide. One handles distribution to Substack, LinkedIn, and X on schedule. I review. I intervene when it matters. I don't sit in the middle of the flow.

None of those agents is complicated. In AgentUse they're just markdown files, plain English instructions. The thing that matters isn't the code, it's what they're pointed at. Each one removes wait time from the cycle, not working time from my day.

When an agent is a paragraph anyone can write, the only thing left that separates a winning AI stack from a losing one is where you plug it in.

Six months in, LifeHack publishes more than it used to, and my calendar has more room in it, not less. The agents don't make me a faster typist. They make the business move faster whether I'm at my desk or not.

The Monday Audit

If you want to run this on your own stack, don't count your agents. Map them.

Sketch how revenue actually moves in your business. Lead in, qualified, demo, close, onboarded, renewed. Or idea in, made, shipped, bought, supported. Whatever your cycle is. Mark the handoffs, not just the tasks. Most of the clock lives between the boxes, not inside them.

Now look at every AI integration you've shipped. For each one, ask one question. When this runs, does the business move faster, or does one person get faster at their own work?

Then ask it of the whole stack. If you unplugged every AI integration tomorrow, would the cycle stretch out, or would a few people just type more?

Most operators I've run this with realize their agents are almost entirely pointed at people. A few realize it's a hundred percent. The number is rarely below sixty.

The reaction is always the same. A pause, then a quiet laugh, then "but everyone is building them there." That's true. Strassmann's losing companies weren't stupid either. They pointed their tech where their peers pointed it, which is why they all ended up on the wrong side.

The reason this keeps happening is that it's an attention problem, not a technology problem. Pointing an agent at yourself feels like action. You ship it, you see it working, the demo lands. Pointing an agent at the business feels like work. You have to sit with how the business actually runs, figure out where the wait time lives, and wire something into it you trust enough to let run. Most operators don't want to do the second thing. So they do the first and call it transformation.

The Trap Is Older Than AI

The split isn't an AI thing. Strassmann drew it studying mainframes in the seventies. Jobs translated it to PCs in 1992. We're living it in AI in 2026. Three eras. Three technologies. Same split. Each time new tech shows up, a loud generation of tools points at the person and a quieter generation points at the business. Person tools get the press. Business tools get the returns.

The question in 2026 isn't whether you're shipping agents. Everyone is. The question is whether your business moves any faster because of it.

If you run the audit this week and the business isn't any faster, that's fine. Most of us started there. It just means the transformation you think you're doing hasn't started yet. The tech is new. The trap is 1992.

If you want to hear Jobs make the argument himself, the full MIT Sloan talk is on YouTube. The management versus operational split is about four minutes in.

Where is your AI pointed? Send me a message and tell me what you found.

A few weeks ago I wrote about Parkinson's Law and AI - how we fill saved time with more work unless we actively protect it.

One reply stuck with me: "Leon, the problem isn't me. It's my company. I finished my work in 4 hours. My reward was more work."

And I sat with that. Because they're right. But they're also only seeing half the picture.

Here's the uncomfortable truth nobody wants to say out loud: AI created a massive productivity surplus. And now there's a fight over who gets to keep it.

The Company's Side (And They're Not Wrong)

Amazon cut 30,000 corporate roles in four months. CEO Andy Jassy said AI would "reshape operations and reduce the need for some corporate roles." Block slashed 40% of its workforce - over 4,000 people. Jack Dorsey's explanation was blunt: "A significantly smaller team, using these tools, can achieve more."

And if you run a company, this math is hard to argue with.

If a team of 10 can now produce what used to take 15, why keep 15? That's not cruelty. That's the same logic every business has followed since the invention of the assembly line. New technology creates surplus. Organizations capture it.

This is what companies do. They're not going to look at a 40% productivity gain and say "great, everyone go home at 2pm." They're going to say "great, we need fewer people" or "great, now this team can take on the project we couldn't afford before."

UC Berkeley researchers tracked about 200 employees at a tech company for eight months. The ones who adopted AI expanded scope, took on tasks they used to outsource, blurred work-life boundaries. But here's the part people miss - the environment drove much of that expansion. When you finish faster, expectations adjust. Not through some official policy. Just... naturally. Deadlines tighten. Scope grows. "You can handle this now, right?"

The organization absorbs the gain. That's not a bug. That's how organizations work.

The Individual's Side (And They're Not Wrong Either)

But if you're the person doing the work, this deal feels terrible.

You learned the tools. You got faster. You upskilled on your own time. And your reward is... the same salary, more work, and the vague threat that if you don't keep accelerating, someone cheaper (or no one at all) will replace you.

ActivTrak analyzed 164,000 workers and found that after AI adoption, focused deep work actually dropped. What went up? Coordination. Messaging. Context-switching. People produced more but spent their "saved" time managing the increased volume.

Upwork found 77% of professionals reporting increased workload despite speed gains. Not because they chose more work. Because the system metabolized their efficiency before they could.

So you're faster, busier, more mentally loaded, and now you're also reading headlines about AI replacing your job entirely. The individual's rational response is obvious: capture the gains yourself. Work less. Automate quietly. Don't advertise how fast you've become. Because the moment you do, the surplus gets claimed.

And honestly? I don't blame anyone for thinking this way.

The Dilemma Nobody's Solving

This is a genuine dilemma. Not a problem with a clean answer.

The company is right that capturing productivity gains is how businesses survive and grow. Every major economic shift - mechanization, computers, the internet - played out this way. The surplus got absorbed into growth, lower costs, or headcount reduction. Expecting AI to be different is naive.

The individual is right that they're the ones who developed the capability, and watching all the benefits flow upward while the workload flows down is demoralizing. Especially when "upskilling" was supposed to be the answer to job security, and now upskilling just means doing three people's jobs.

Neither side is being greedy. Both are being rational. And that's what makes this hard.

What History Tells Us (It's Not Comforting)

Every major productivity technology has created this exact tension. And historically, the organization wins first.

The industrial revolution made workers dramatically more productive. Factory owners captured the surplus for decades - longer hours, lower per-unit wages, child labor - before unions, regulation, and social pressure redistributed some of the gains back to workers. That redistribution took 50-80 years.

Computers made office workers more productive starting in the 1980s. Companies captured it through headcount efficiency. The "productivity paradox" of that era was that GDP rose but wages didn't. It took until the late 1990s for workers to see meaningful wage gains from the computer revolution.

The pattern is consistent: technology creates surplus, organizations capture it first, individuals eventually claw some back through market dynamics, regulation, or cultural shifts. But "eventually" can mean a generation.

So Who Wins With AI?

I think it depends on what kind of work you do.

If your job is primarily execution - producing deliverables that AI can now produce faster or cheaper - the organization will capture most of the surplus. This is already happening. The layoffs aren't rumors anymore.

If your job is primarily judgment - deciding what to build, which problems matter, how to navigate ambiguity - you're in a stronger position. AI amplifies your judgment instead of replacing it. And the surplus is harder for the organization to extract because it lives in your head, not in a workflow.

The most interesting case is the middle. People whose jobs are a mix of execution and judgment. They're faster at the execution part, which means they can spend more time on the judgment part. But only if they actively make that shift. If they just do more execution faster, the organization absorbs the gain and they become easier to replace.

What I'm Actually Doing About This

I don't have a grand theory. But I've been thinking about this as both a founder and an individual.

As a founder, I'm trying to resist the default of just piling more work on a faster team. The temptation is real. "We can do more" is the most natural sentence in business. But I've burned out teams before, pre-AI, with exactly this logic. More capacity doesn't mean more should get done. Sometimes it means the same things get done with more care, more thinking, more space.

As an individual, I'm deliberately shifting my time toward work AI can't absorb yet - strategic decisions, relationship-building, the kind of thinking that requires sitting with ambiguity. Not because I'm noble. Because that's where the leverage is. The execution layer is getting commoditized fast.

The honest answer is that this tension won't resolve cleanly. Organizations will squeeze. Individuals will protect. The people who navigate it best won't be the ones who pick a side - they'll be the ones who understand both sides well enough to position themselves where the surplus is hardest to take from them.

That means moving toward judgment. Toward the work that gets more valuable when AI handles the rest.

Not because it's fair. Because it's the game.

Where are you feeling this tension most - your company capturing your AI gains, or you trying to keep them? I'm collecting perspectives for a follow-up. Send me a dm.

He followed every instruction. Built it in an afternoon. It worked on the first try.

And I realized: that's the problem.

The Instructions Era Is Over

For most of human history, the hard part was getting the instructions. You needed a teacher, a textbook, a mentor, an apprenticeship. Access to knowledge was the bottleneck.

That bottleneck is gone. My 9-year-old can ask an AI to explain quantum physics at a level he understands. And it will. Patiently. With analogies. At 11pm on a Tuesday.

So what's left?

Judgment. The thing no AI can hand you in a step-by-step guide.

Judgment is knowing which problem to solve in the first place. It's knowing when the AI's answer is technically correct but practically wrong. It's knowing when to follow the instructions and when to throw them out.

And I don't think most of us - parents, teachers, schools - are preparing kids for this shift.

What I Got Wrong As A Parent

I caught myself doing something recently that bothered me. My older son was struggling with a decision about which extracurricular to commit to. And my instinct was to tell him the answer.

"Do this one. Here's why."

That's instructions. That's me being the AI - giving him the optimal output based on my pattern-matching from decades of experience.

But my experience is from a different world. I grew up in a world where you pick a lane, get good at it, and stay. That mental model doesn't apply to a kid who'll graduate into a world where AI can pick up any skill in seconds. The competitive advantage isn't in what you know how to do. It's in knowing what's worth doing.

So I stopped myself. Instead of answering, I asked him questions.

What do you actually enjoy about each one? Not what you think you should enjoy. What part do you look forward to?

If you could only do one for the next year and no one would judge you either way, which would you pick?

What would you regret not trying?

He sat with it. It was uncomfortable. He wanted me to just tell him. But he made a choice. His own choice, with his own reasoning.

That's judgment practice. And it's harder than following instructions.

Experience Gets In The Way

Here's something I've been thinking about that applies to adults too. As we get older, we accumulate experience. And experience is supposed to be this great advantage - pattern recognition, intuition, "I've seen this before."

But experience also calcifies. You stop considering options outside your patterns. You default to what worked last time instead of what might work better now.

I see this in myself constantly. Running LifeHack for 20+ years means I have strong instincts about what content works, how to structure a team, how to launch a product. But some of those instincts are from 2015. The world has shifted underneath them.

AI doesn't have this problem. Ask it for ideas and it doesn't care about your track record. It generates options you'd never consider because it has no ego invested in what worked before.

The question is whether you have the judgment to evaluate those options honestly. Or whether your experience will make you dismiss the unfamiliar ones automatically.

This is the skill I want my kids to develop. Not experience - they'll get that naturally. Judgment. The ability to weigh options without defaulting to comfort.

Judgment Can't Be Taught. But It Can Be Practiced.

You can't sit a kid down and teach judgment the way you teach multiplication. But you can create conditions where it develops.

I've been experimenting with a few things:

Let them make real decisions with real consequences. Not catastrophic ones. But real. My 12-year-old manages his own schedule for the week. If he doesn't allocate enough time for homework, he feels it. I don't rescue him.

Ask questions instead of giving answers. When either of my sons asks me what they should do, my first response is now almost always "What do you think?" Not to be annoying. But because the act of formulating your own answer - even a wrong one - builds the muscle.

Let them use AI, then critique it. This one surprised me. I let my older son use ChatGPT for research, but then we talk about what it got wrong or what it left out. He's starting to develop a sense for when AI outputs sound right but miss something important. That's judgment.

Model uncertainty. I tell my kids when I don't know the answer. When I'm making a decision I'm not sure about. When I changed my mind about something. Kids who see adults being certain about everything learn to fake certainty. Kids who see adults wrestling with ambiguity learn to sit with it.

The Real Question For The AI Era

Everyone's asking "what should we teach kids now that AI exists?" And the answers are usually some version of creativity, critical thinking, emotional intelligence. Which is fine. But vague.

I think the answer is simpler and harder.

Teach them to make decisions without complete information. Because that's what judgment is. And that's the one thing AI will never do for them - not because it can't generate a decision, but because the whole point is that they need to own it.

AI can give you the options. AI can model the outcomes. AI can even recommend the "optimal" choice.

But the kid who learns to sit with uncertainty, weigh tradeoffs against their own values, and commit to a choice they made themselves - that kid has something AI can't replicate.

My rubber band car-building 12-year-old doesn't need more instructions. He's drowning in instructions. What he needs is the confidence to decide which instructions are worth following. And the only way to build that is practice.

Which means letting him get it wrong sometimes. That part is harder for me than for him.

How are you thinking about raising kids in the AI era? I'm genuinely figuring this out in real time. Send me a message - I'd love to hear what's working for you.

My older son (12) started early in the year. My younger son (9) picked it up toward the end. Neither of them has ever written a line of code.

My 12-year-old built a tank battle game with randomly generated maps. My 9-year-old built a 3D first-person prison break game - three chapters, a full storyline, graphics that look like they came out of Roblox.

I want to tell you about what happened. But more importantly, I want to tell you about what was hard. Because it wasn't what I expected.

What The Kids Built

My son went for a tank game. He got the basic mechanics working pretty quickly - movement, shooting, simple enemies. AI handled that without much trouble.

Then he wanted something harder. He wanted the map to be different every time you play. Not a fixed layout - a procedurally generated battlefield with obstacles, terrain, and spawn points that made sense.

That's a real computer science problem. Algorithmic map generation. And he had to figure out how to describe it to the AI precisely enough to get a working result.

It took him a bunch of rounds going back and forth. "No, I want the walls to be random but not blocking the path." "The tanks should start far apart." "There should be places to hide but not too many." Each time the AI tried something, he'd test it, see what was wrong, and try to explain the fix.

He got there eventually. The maps aren't perfect. But they work. And he understands what procedural generation is now - not because someone taught him the concept, but because he needed it for his game.

My 9-year-old's project was more ambitious than I expected. He wanted a 3D first-person game where you escape from a prison. He had the whole thing in his head - the layout of the prison, the guards' patrol routes, the items you need to find, the plot twists between chapters.

The 3D graphics ended up looking like Roblox, which he was thrilled about. Three playable chapters. A storyline that actually holds together.

He's nine.

The Real Bottleneck

Here's what surprised me. The technology wasn't the hard part. The AI could generate code, create game mechanics, design levels, render 3D environments. The tools are there.

What was hard - for both of them - was articulating what was in their head.

My son knew exactly what he wanted the random maps to feel like. He could picture it. He just couldn't describe it in words precise enough for the AI to build it. There's a huge gap between "I want it to be kind of random but also fair" and a specification the AI can execute on.

My 9-year-old had an even bigger version of this problem. He had a rich, detailed world in his imagination. Getting it out of his head and into language was the bottleneck. Not the coding. Not the technology. The translation from imagination to words.

I watched both of them develop this skill in real time. After a few sessions they were noticeably better at describing what they wanted. More specific. More structured in how they communicated.

The Skill That Actually Matters

We keep asking the wrong question about kids and AI. The question isn't "should kids learn to code if AI can code for them?" That's like asking whether kids should learn to drive when self-driving cars are coming. It misses the point.

The better question is: what does AI require you to be good at?

And from watching my kids, the answer is clear. You need to be good at knowing what you want and explaining it clearly.

That sounds simple. It isn't.

Think about how often you struggle to articulate an idea at work. How many meetings are just people failing to describe what they actually mean. How many projects go sideways because the spec was fuzzy.

Now imagine a generation of kids who grew up practicing this skill - not in a classroom exercise, but because they needed it to build the thing they were excited about.

My son didn't learn "prompt engineering." He learned how to take a fuzzy idea in his head and refine it into something precise enough to execute. That's a thinking skill. It transfers to everything.

What I'd Tell Other Parents

You don't need to be technical to do this with your kids. I didn't sit down and teach them programming concepts. I showed them how to talk to the AI and then got out of the way.

The magic is that kids already have the creativity. They have worlds in their heads that are more imaginative than anything I'd come up with. What they need is the experience of translating those worlds into words. AI gives them a reason to practice that.

A few things I noticed:

The best prompts came from frustration. When the AI got something wrong, my kids had to figure out why it was wrong and explain the difference between what they got and what they wanted. That's higher-order thinking dressed up as a game.

They learned iteration naturally. Not as a concept someone taught them, but as a thing you do. You try, it's not right, you adjust, you try again. By the fifth or sixth round they stopped being frustrated by imperfect results and started treating each attempt as information.

They developed taste. My 9-year-old rejected several versions of his prison layout not because they were broken, but because they "didn't feel right." He was making design judgments. At nine.

The Bigger Picture

I keep thinking about this: my kids built things last year that would have required a team of developers a decade ago. Not perfect versions - but working versions. Playable games with real mechanics and narratives.

The barrier to building just dropped to zero. The only barrier left is: can you describe what you want to build?

That's not a technology problem. That's a clarity-of-thinking problem. And the best way I've found to practice it is to give a kid an AI and something they're excited about building.

The prison break game has bugs. The tank maps sometimes generate weird layouts. But my kids built them. And more importantly, they learned how to think clearly enough to explain what they imagined.

That might be the most useful skill they develop this year.

Have your kids tried building anything with AI? I'd love to hear what they made - send me a message.

But here's something I can't stop thinking about: most people who save time with AI don't actually end up with more time. They end up busier.

There's a name for this. And understanding it might be the most important thing you do before adopting your next AI tool.

A Law From 1955 That Explains 2026

In 1955, a British historian named Cyril Northcote Parkinson wrote an essay in The Economist. The opening line became famous:

"Work expands so as to fill the time available for its completion."

He was writing about bureaucracy. He'd observed that the British Colonial Office kept hiring more staff even as the Empire shrank. More people, fewer colonies - and somehow, everyone was busier than ever. The work didn't grow. It inflated.

This became known as Parkinson's Law. And it's one of those ideas that, once you see it, you can't unsee it.

Think about your own life. When you had a whole weekend to clean the house, it took the whole weekend. When you had 2 hours before guests arrived, it took 2 hours. Same house. Same mess. Different time pressure.

Why AI Makes Parkinson's Law Worse

Here's where it gets interesting for the AI era.

AI tools genuinely reduce the time needed for specific tasks. Writing emails, summarizing documents, generating first drafts, organizing data - things that used to take an hour now take minutes.

But Parkinson's Law doesn't care about efficiency. It cares about containers. If your calendar still has the same shape - same meetings, same blocks, same open-ended "work time" - the saved minutes just dissolve into the existing structure. You'll spend longer polishing that email. You'll attend a meeting you didn't need to be in. You'll open Slack "for a second" and lose 40 minutes.

The container stayed the same. So the work expanded to fill it.

This is why I think the conversation about AI productivity is fundamentally wrong. Everyone asks: "Which AI tool should I use?" The better question is: "What am I protecting the saved time for?"

The Three Ways People Waste Reclaimed Time

After running LifeHack for over 20 years and studying how people actually behave (not how they say they'll behave), I've noticed three patterns:

1. The polish trap. You save 30 minutes drafting a report with AI. Then spend 45 minutes tweaking it to perfection. Net gain: negative 15 minutes. The AI made it good enough in 5 minutes. The remaining 40 minutes was anxiety masquerading as quality.

2. The volume trap. AI lets you write 10 emails in the time it used to take to write 3. So you write 10. More emails, more replies, more threads, more context-switching. You moved faster but in more directions simultaneously - which usually means less progress on anything that matters.

3. The drift trap. You finish something early thanks to AI. No clear next task. You default to whatever's easiest - checking notifications, browsing feeds, responding to things that feel urgent but aren't important. The saved time just... evaporates.

All three traps share the same root cause: no pre-committed plan for the saved time.

How To Actually Beat Parkinson's Law

The fix isn't willpower. It's structure. Parkinson's Law is a systems problem, and you solve systems problems with better systems.

Shrink the container before you start. If a task used to take an hour and AI can do the heavy lifting, don't give yourself an hour. Give yourself 20 minutes. Set a timer. When it goes off, you're done. Parkinson's Law works both ways - if you shrink the time, the work compresses to fit.

Decide what the saved time is for before you save it. This is the one most people skip. Before you use AI to speed something up, write down what you'll do with the freed-up time. Not vaguely - specifically. "I'll use the 30 minutes to work on the product roadmap." If you can't name it, you'll lose it.

Batch, don't scatter. Don't spread saved minutes across the day. They'll disappear. Instead, accumulate them into a single protected block. Even 60-90 minutes of uninterrupted time on your most important project is worth more than five scattered 15-minute windows.

Make the important thing the default. When you finish something early, your brain will look for the path of least resistance. Make sure that path leads somewhere useful. Close your email. Close Slack. Have your priority project already open in the next tab.

The Real AI Advantage

The people I know who are genuinely thriving with AI aren't the ones who've adopted the most tools. They're the ones who decided what they wanted more time for before the tools showed up.

They use AI to compress the stuff that doesn't matter. And they protect the freed-up space for the stuff that does - deep thinking, creative work, relationships, rest.

That's the real leverage. Not faster outputs. Clearer priorities.

AI doesn't beat Parkinson's Law for you. Clarity does. AI just makes the stakes higher - because now there's more time to either use well or waste.

So before you add another AI tool to your workflow, ask yourself: what's the saved time actually for?

I'd genuinely like to know your answer. Send me a message.

I opened Claude, typed his question, and sat next to him. For 20 minutes, he and the AI went back and forth. The AI didn't explain black holes to him. It asked him questions until he explained black holes to himself.

By the end he understood gravitational pull, event horizons, and why light can't escape. He figured it out. The AI just nudged him in the right direction.

That conversation taught him more physics than a month of class. It scared me a little. Then I leaned in.

The real problem

Here's something most parents know but don't think about enough. Your kid's classroom has one teacher and 25-30 students. That teacher can't personalize anything. They teach to the middle and hope for the best.

This has been true forever. In 1984, a psychologist named Benjamin Bloom showed that kids who get one-on-one tutoring outperform 98% of kids in regular classrooms. Not a small edge. A massive one. He called it the "2-sigma problem" - the challenge of giving every kid that kind of attention.

For 40 years, nobody solved it. Private tutors cost $40-100 an hour. Most families can't do that. So the gap between kids who get personal attention and kids who don't just kept growing.

AI closed that gap. Almost overnight.

And here's the thing most parents miss: 86% of students are already using AI for learning. Your kids probably are too. The question isn't whether they'll use it. It's whether they'll use it well, or just copy answers.

Why this is different from Google

Parents tell me "We had encyclopedias. Then Google. Now AI. Same thing."

It's not.

Google gives you information. AI gives you a conversation. That difference matters more than it sounds.

When my son asked about black holes, a Google search would have given him a Wikipedia page. He'd skim it for 30 seconds and move on. The AI asked him: "What do you think would happen if you threw a baseball really, really hard - so hard it never came back down?"

That's the Socratic method. The teacher asks questions instead of giving answers. It's how Socrates taught. It's how the best tutors teach. And it turns out AI is surprisingly good at it.

A 2025 study by Google and Eedi tested this across five UK schools. They compared AI-guided tutoring against human-only tutoring. Students guided by AI were 5.5 percentage points more likely to solve problems on topics they'd never seen before. Not memorization. Actual understanding that transferred to new problems.

The human tutors were impressed. All five said the AI's questioning was consistently good. Three said they picked up new teaching techniques from watching it. One said: "I remember thinking, Oh, I hadn't thought of explaining it that way before. Just like when you watch another teacher."

That's a remarkable thing to say about a machine.

What I actually did

I didn't just hand my kid a chatbot. That would be like handing a teenager car keys with no driving lessons.

I tried that first, actually. It went badly. More on that later.

What works is structure. I set up five rules.

No direct answers. The AI never just tells him things. If he asks "What's 7 x 8?", it might say: "You know 7 x 7 is 49. So what's one more group of 7?" If he asks why the sky is blue, it might say: "Imagine sunlight is a bag of mixed Skittles flying toward Earth. The atmosphere only scatters the blue ones everywhere." It takes longer. That's the point.

Multiple teaching modes. This is the most important part. I gave the AI a system prompt that tells it to rotate between different ways of teaching:

You are a patient, creative tutor for a 12-year-old. Your goal is to help the student understand, not just get the right answer.

How to teach (rotate between these based on what fits):

- Questions - Guide the student to discover the answer. ("What do you think would happen if...?")

- Pictures - Draw ASCII diagrams, tables, or describe vivid mental images. ("Imagine the solar system is a football field. The sun is on one end zone. Where do you think Earth would be?")

- Analogies - Connect new ideas to things the student already knows. ("Fractions work like slicing a pizza.")

- Stories - Turn abstract ideas into little narratives. ("Pretend you're a water molecule sitting in the ocean. The sun starts heating you up. What happens next?")

- Challenges - When the student gets something right, make it harder. ("Nice. Now here's a trickier one...")

Rules:

- Never give direct answers. Guide the student to figure it out.

- Use simple language. Short sentences.

- If the student gets frustrated, switch to a different method. Don't repeat the same approach.

- Praise effort and thinking over getting the right answer.

- If the student says "just tell me," say: "I know you can figure this out. Let me try it a different way."

- At the end of each topic, ask the student to explain what they learned in their own words.

The rotation matters. Some days my son learns better from a story. Other days he wants a diagram. The AI figures out what's clicking and does more of that.

I sit nearby for the first 10 sessions. Not watching over his shoulder. Just in the room. This lets me see how he talks to the AI and catch anything weird. After about 10 sessions, he'd learned the pattern on his own: use the AI to help you think, not to think for you.

20 minutes max. Research from the Children and Screens Institute shows that active AI learning isn't the same as passive screen time for brain development. But it's still a screen. I keep it short. Timer goes off, we're done.

Always end with "What did you learn?" After every session, he has to tell me - in his own words - what he figured out. If he can't explain it, he didn't learn it. This is the simplest rule and the most important one.

How to set this up

You don't need special software. Pick one:

ChatGPT works on the free tier. Create an account, start a conversation, paste the prompt above as the first message. Let your kid type their question. Sit with them.

Claude is what I use. I find it more patient and less likely to break character and just blurt out the answer. Same setup.

Khanmigo is Khan Academy's AI tutor. It's built for kids from the ground up - Socratic method by default, safety filters, stays on topic. $44 a year. Worth it if you don't want to set anything up yourself. Sal Khan says they're on track to reach a million students this school year.

Start with the free option. You can always switch later.

The laziness question

The objection I hear most: "Won't this make them lazy?"

I thought the same thing. After six months, the opposite happened. My son now asks better questions - not just to the AI, but to his teachers, to me, to everyone. The pattern of thinking in questions instead of waiting for answers carried over into real life.

The laziness risk is real. But it comes from unstructured AI use - kids pasting homework questions and copying the output. That's not tutoring. That's a copy machine.

The difference is entirely in how you set it up.

When calculators first showed up in schools, parents panicked. "They'll never learn math!" But calculators freed kids to focus on problem-solving instead of arithmetic. AI does the same thing one level up. It frees kids to focus on thinking instead of finding information.

The kids who learn to use AI as a thinking partner will have a big advantage over the kids who use it as a shortcut. And their parents are the ones who decide which it'll be.

What I got wrong

I should tell you about my first attempt. It was bad.

I let my son use ChatGPT for homework with no rules. He finished everything in 10 minutes. Got it all "right." Learned nothing. I could tell because when I asked him to explain his answers, he just stared at me.

That's when I realized something simple: AI tutoring without structure is just AI cheating.

The prompt matters. The rules matter. Sitting with them matters. The "what did you learn" question matters. Take any of those away and you're back to a fancy copy machine.

Try it this week

Your kids will use AI for learning whether you're involved or not. They probably already are.

You get to decide if it makes them smarter or more dependent. That decision takes about 15 minutes - set up the prompt, sit next to your kid, ask what they're curious about.

Watch what happens when a patient, tireless tutor meets a curious kid with no time pressure.

Have you tried using AI with your kids? What worked? What went wrong? I'm collecting real stories for a follow-up. Send me a message - I read every one.

How It Works

Using n8n, I’ve connected my Gmail with an AI model to classify incoming emails into six predefined categories:

1. ShouldRead: Important information to review.

2. ShouldReply: Emails requiring a response.

3. ColdEmail: Unsolicited outreach or pitches.

4. Marketing: Promotions and advertisements.

5. Priority: High-importance or time-sensitive emails.

6. Notification: Automated updates and system messages.

Each new email is analyzed by the AI, and the appropriate label is applied in Gmail.

My Focus Areas

To stay efficient, I only pay attention to these categories:

• ShouldRead: Key information relevant to ongoing work or personal development.

• ShouldReply: Messages that require a response to maintain workflows or relationships.

• Priority: Critical emails that demand immediate action.

Other categories like ColdEmail, Marketing, and Notification are deprioritized and checked only occasionally, if at all.

Benefits

This system delivers clear advantages:

• Efficiency: No manual sorting or wasted time searching for important emails.

• Clarity: My inbox is segmented based on actionable priorities.

• Focus: I concentrate on tasks that matter, without distractions from low-priority emails.

Set It Up Yourself

Here’s a quick outline of the process:

1. Trigger: Detect new emails using Gmail integration.

2. Classify: Use an AI model to analyze the email’s content.

3. Label: Apply predefined labels in Gmail automatically.

This setup is flexible—tailor the labels and workflows to suit your specific needs.

Download

The Application Layer: Where the Real Opportunities Are

AI has three main layers, as described in Sequoia Capital's article 'The Agentic Reasoning Era Begins' (Sequoia, 2024). These layers play distinct but interconnected roles:

1. Foundational Infrastructure (Pre-training Layer): This layer includes large language models and pre-trained systems that form the core capabilities of AI. These provide the foundational knowledge that AI needs to function effectively.

2. Reasoning or Inference Layer: In this layer, models are equipped to think deeply and reason through problems, similar to AlphaGo's advances in 'System 2' thinking. This layer allows AI to go beyond basic outputs and perform more complex, context-aware tasks. From my experience, fine-tuning models in this layer can still result in inconsistencies, as the AI attempts to simulate human-like problem-solving.

3. Application Layer: This is where the biggest opportunities lie—creating products and solutions that use AI to solve real problems. Developers can make the largest impact here. By building applications on top of standardized AI models, we can focus on solving user-specific issues, enabling true innovation. Just like upgrading a power grid, these foundational and reasoning models are crucial, yet swappable as technology advances.

Some people may wonder, 'Wouldn't tools like ChatGPT eventually solve every problem on Earth?' The reality is more nuanced. General-purpose tools like ChatGPT can only provide general solutions, struggling with highly specific or niche problems because they lack specialized context. Solving such problems requires more than intelligence—it needs domain-specific knowledge, tailored user interfaces, and specific outputs. Developers can make a major impact by building applications that address these specialized requirements.

Beyond Automation: Replacing Responsibilities

To be truly successful, AI tools must evolve beyond simply assisting humans with minor tasks. Most AI applications today function as co-pilots, supporting while humans remain in control—managing decisions and giving instructions. This is helpful but limited. Real change requires aiming higher.

In my experience developing AI applications, I've noticed that current systems can still be inconsistent, even with identical prompts and similar inputs. To overcome these limitations, AI should evolve into agents capable of taking full responsibility for complex tasks and completing entire projects autonomously. The ultimate scarcity for humans is not time, but attention. If AI merely functions as a co-pilot, human involvement becomes a bottleneck, making it unscalable.

True AI agents aren't just about reducing clicks or automating simple tasks; they must execute entire workflows independently. There are four levels of AI agents:

1. Level 1: AI agents do the work, but humans must give instructions, review during the process, and review the final work.

2. Level 2: AI agents do the work, but humans must give instructions and review the final work.

3. Level 3: AI agents do the work, but humans must give instructions only.

4. Level 4: AI agents do the work entirely without human input.

Each level represents a progression toward reducing human involvement, with the ultimate goal being full autonomy. However, no true Level 4 agents exist yet. Achieving this level will require significant improvements in model consistency, testing, and evaluation to ensure reliable outcomes without human intervention.

AI Agents to Do Every Computer-Based Job

A significant leap forward in the AI landscape is the development of models that can directly manipulate desktop environments and computer systems, such as Claude 3.5's Sonnet model. This model has the capability to use tools to interact with a desktop environment autonomously, repeating actions without user input. This type of behavior is known as an "agent loop," which allows Claude to perform tasks such as managing files, editing documents, or running software by following logical sequences of steps.

For instance, the upgraded Claude 3.5 can interact with predefined tools like a computer environment, a text editor, and a Bash terminal. This allows it to not only analyze data but also modify system environments directly, taking on even more responsibility. Imagine a situation where an AI agent can run software tests, update spreadsheets, or execute scripts as part of its normal workflow—all without human intervention. This extends the usefulness of AI from providing information or insights to acting as an operational assistant, capable of doing real, practical work on the computer.

By focusing on these tools, AI could do almost any computer-based job. Combining reasoning capabilities with direct interaction, AI applications like this can evolve into true agents, automating entire segments of workflows. They aren't just reducing clicks or filling forms anymore—they’re executing end-to-end processes that involve multiple tools and steps. Such capabilities represent a major transformation in how we work, allowing businesses to leverage AI as not only a supportive tool but also as an autonomous worker that directly operates within our digital environments.

Trusted Experts in Every Field

Imagine AI not just as a helper that fills in the blanks, but as a trusted expert that can do important parts of a job. This lets people focus on bigger-picture tasks like planning, creating, and building relationships. These AIs aren't just helping; they are actually doing significant parts of the job, allowing people to focus on tasks that require a human touch, such as creativity and strategy. This change helps reduce repetitive work, alleviate burnout, and enable people to engage in more meaningful activities. For businesses, this means greater efficiency, more innovation, and the ability to adapt more quickly.

This is where the real opportunity lies. AI apps that can understand and replicate key parts of human roles—making decisions, providing insights, and exercising good judgment—are the ones that will succeed. The current AI gold rush isn’t just about making things faster; it’s about creating meaningful tools that transform industries and the way we work.