Toward Autopoiesis

I've always wanted infinite prosperity. A life that flourishes, minus all the worldly noise. Capital goods too, the means of production, all of it. I just didn't want to keep grinding my own stamina and focus into it.

My attention is way too expensive. I want to do too many things. So, attention economy and all, I wanted a self-powered perpetual engine that eats as little of my attention as possible. In sync with my head, growing on its own...

I've spent the past year arguing with AI, and I think I left some pretty meaningful footprints on the way to automating knowledge work for good. So, first post in a while.

Misconception 1. It's not the work you automate

People keep asking

How do I automate ((the work that's hard for humans))?

Automating PR review, automating codebase understanding, that kind of thing. To me, that's thinking way too much like a human. After burning about 600 million won of tokens (a bit over $400K) as of October 18, 2026, the biggest bottleneck was somewhere else entirely.

Unity of taste.

Humans have continuity of thought, so you'd assume agents on the same model act the same.

Nope. Every new agent has different taste, and its decisions land somewhere new every time. Polishing skills and Markdown files didn't change that. Add higher-level calls like design direction and it gets worse.

What even is taste, though? A bundle of decisions. This button goes here, this error blows up like that, etc.

So the real problem wasn't automating work. It was getting every agent to follow a decision once I've made it.

Misconception 2. Are the frontier's problems even mine?

The industry worries about how much human to pull out of the loop (human-in-the-loop), because nobody's asking for zero attention. At a company, human attention is about as cheap as tokens. And every decision has someone accountable.

I couldn't do that. I can't put an accountable person on every decision, and I can't make AI accountable either. The engine still had to run.

So... cutting attention and taking it to "$\lim\limits_{x\to 0}$" are completely different problems. Cutting means fewer human hands per task. Zero means human hands have to stop scaling with the task count at all.

The industry's questions come from the PR level

Most of them assume someone's watching every PR.

These questions aren't wrong. They're just not much use to me. Companies are trying to go from ten thousand people to a hundred. I'm trying to go from one to zero.

(Flip it around, though, and I think my questions work for companies just as well.)

Why Decisions, not PRs

If the PR is the unit of work, my attention scales with PR count. Once agents open hundreds of PRs a day, that's it, I'm the bottleneck. That's exactly what the frontier is worrying about right now.

But rip those hundreds of PRs apart and there's only a handful of decisions inside. The same ones repeat in every PR (PRs are so noisy the directional calls get buried). So a human should look at the decision, not the PR.

• A PR is done once merged. A decision keeps working in the next PR, and the one after.
• A PR belongs to one thread. Hundreds of agents pull the same decision at once.
• PR review needs a human every time. A decision only has to be made once.

Bezos said something like this. Senior execs get paid to make a small number of high-quality decisions, and three good ones a day is enough. After a while that's where I landed too.

So every question I answer becomes a precedent.

• Each answer is saved as a precedent doc holding one fact.
• When I correct something, that session fixes the precedent on the spot.
• Agents have to search precedents before asking me anything.
• Asking me something I already answered, or making me repeat myself, gets logged as a failure. Which becomes a precedent too.

One more reason. Long-horizon context isn't a silver bullet, and when hundreds of agents hit similar questions at once, decisions have to be shared ACID-ly. As in, what one agent learns, every other agent has to know right away. With Markdown files a decision isn't shared until right before merge, so it turns into a bottleneck.

The wild part is my attention ends up scaling with the number of kinds of decisions, not the number of PRs. Within the same work, new kinds show up less and less. I keep building new stuff, so there are always some.

Embedding every conversation into a book of precedents

For decisions to be the unit of work, they need to pile up somewhere and pop back out when needed. Agent memory today is bad at that. Debugging almost never makes it into long-term memory.

1. the agent has to explicitly write a memory,
2. even then, only the debugging inside that thread survives,
3. only successes get saved, never failures,
4. someone has to deliberately recall it next time,
5. and debugging from another thread, another tool, another computer... good luck.

So I dumped my whole work history into vector memory. I started in early September and that alone was 18,025 items. While I was at it I threw in Claude Code, Codex, GitHub issues, and records from old computers, 73,802 items total. Then I had the vector memory run Dreaming on it (the server refines and summarizes memories in the background). That gave me about 6,600 precedents. About 1,400 are rules and conventions, about 3,200 are gotchas and debugging findings, and the rest are decision records, references, and such. Funny how experience outnumbers rules that much.

But memory only matters if you actually pull it out. A rules file usually gets read once at session start and that's it. So long sessions get something like catastrophic forgetting (it forgets the earlier stuff).

So right before an agent acts, a PreToolUse hook searches memory with the exact words of that action. Shell commands, emails, messages to other threads, scheduled jobs, all of it. It searches again on every prompt and after context compaction. (Making this fast and reliable on cheap models takes a bunch of tricks. Another post.)

The point is to take load off the agent. Don't make it memorize. What it needs should always be readily available.

Oh, and why not Markdown files? With hundreds of worktrees running at once, decisions don't sync, and that's fatal. Why not Notion? Knowledge is tangled like a cloud, not stacked in a hierarchy. I've thought this for almost five years. See Creating Next-gen Digital Brains.

I could've made Notion work if I had to, but I didn't feel like reinventing anything, so I went with Supermemory.

Autopilot for taste

Back to the bottleneck. Every agent is born with different taste. But if the taste lives in precedents instead of the model, that changes.

• My taste in writing, UI, and code lives on as precedents.
  • Stuff like no defensive code, no eyebrow labels above or below titles.
• A fresh agent, Opus, GPT, Muse, or Grok, pulls the same precedents.
• So swapping models doesn't reset taste.

Even when I'm not holding the wheel, the engine keeps nudging it a little toward my taste.

Mesh engineering

Say zero attention and everyone worries about losing control. That's a matter of perspective too. I chose to see the codebase as one persistent, living thing. See Mesh Engineering.

• No conductor decides what to build or merge.
• Agents read traces like issues, PRs, and precedents, then pick up work and finish it themselves.
• The agent that wrote something doesn't verify it. A model from a different company reviews it.
• Every task gets a fresh reviewer, so no review queue piles up.

Here too, decisions keep the work moving. No conductor, but there are precedents, so hundreds of agents head the same way.

The engine also needs corrigibility. A corrigible agent doesn't deceive its operator, doesn't hide its reasoning, and keeps the whole system correctable even when it spawns subagents. Here's how this one does it.

• One correction from me reaches every thread, and the latest thing I said wins. Say stop once and everything stops.
• Every conversation and work log is indexed, so there's nowhere to hide.
• A precedent says "mistakes are fine, but shortcuts and deception aren't." No reporting a success that a screenshot or a real check could overturn.
• When subagents spawn, a hook blocks disallowed models, and the precedents follow the subagents as-is.

In the industry, corrigibility comes from oversight, and oversight costs attention. Here a correction is just another decision. Make it once and it keeps working in every thread after. So corrigibility actually saves attention.

Oh, and also...

• When an agent gets corrected, it edits the rules and skills itself. My personal skill/mcp/hook repo has 575 commits since September, 209 in the past week alone.
• streamline reads conversation logs, finds missed guesses and my corrections, and fixes them. Then it checks on the next run whether the fix worked.
• Every evening it tests whether memories come back properly and turns wrong answers into more edge cases.
• Agents QA each PR as the user, cross-check each other, and a mistake that keeps coming back becomes a precedent too.
• Vendors and libraries get swapped when something better shows up.

Anyway

The industry asks how to review PRs faster with fewer people. I'm building an engine that works in decisions, not PRs. Every day it needs my hands a little less, and looks a little more like me.