I started an AI shogunate

It started with a video from TuTu Life introducing Grok Bot — the kind of product that gives you a row of AI characters to chat with. Watching it, a question came up: if I built one myself, running on the Mac at home and usable from my phone, what would it look like?

One night and half a day later, what went live was nothing like Grok Bot. Grok Bot is "a row of characters that chat." This isa company that remembers its own history: every member has a name, a remit, and a file-based memory it maintains over time; they have hands — they can edit files and run commands — but they ask before acting; they can delegate work to each other; and every morning at nine they hold a standup and send me one message on my phone with everything I need to know.

This post isn't about architecture diagrams. It's about the part that's worth more than the diagrams: the 30-minute test before any coding that saved an entire day, the three reversals on "how should the bots be divided," the design calls behind memory and org structure, and one table of hard-won lessons.

As usual, a note on method: this is still an AI collaboration experiment. Claude wrote the code; the architecture was argued out back and forth. Every key decision — including the two times I overruled the AI's proposal — was mine.

The spec grew out of three sentences

The first version of the spec was just "it can chat." Three exchanges pushed it into its real shape:

1. "Not just conversation — it has to get things done." Writing a blog post, for example, from idea to publication, end to end.
2. "Like a company: a projects department, marketing, finance, QA, sometimes ad-hoc teams."
3. "AI conversations have a length limit. Past it, the system compresses, and compression breaks things — I've hit this too many times. That's why I insist on storing progress in files."

That third sentence became the foundation of the whole system. Hold onto it; we'll come back to it.

The 30 minutes before coding were the highest-value ones

Whether the whole plan was viable hinged on a single unknown:can an AI actually "pause, wait for my approval, then continue" before it acts?

If it can't, an "AI with hands" is left with two bad options: allow everything (terrifying) or block everything (useless). So before writing a single line of real code, I spent 30 minutes testing it. The findings:

• The official built-in "manual confirmation mode" is adead end— it doesn't ask you, it just refuses, then tells the model "you weren't authorized." The model reads that and gives up; you never even get the chance to approve.
• But another path works: hang an interceptor (a hook) at the exact moment a tool is about to run. If the hook doesn't return, the AI genuinely stops and waits. In testing it waited 6.3 seconds before I released it, and the tool ran as normal — no need to repeat the request.

Those 6.3 seconds are the foundation of the vermilion-seal system — every "ask me first" mechanism (we call itshuin, the vermilion seal) is built on top of it.

The methodological lesson matters more than the finding:when an entire build hinges on a single unknown, spend 30 minutes testing only that one thing.If I'd started coding without testing first, I'd have wasted a full day on a dead end.

Three reversals: how should the bots actually be divided?

Once the system ran, the genuinely hard question arrived: which bots do we create? This went through three versions. The AI proposed the first two; I killed both. The third held. It's the most important piece of thinking in the whole project.

Version 1 (AI's proposal): divide by function.A research bot, a publishing bot, and so on. One sentence punctured it: "Shouldn't publishing be a skill — a reusable process document any bot can invoke?" Functions are skills, not identities. Any bot can learn to publish, which leaves a "publishing bot" with no reason to exist. Version 1 died.

Version 2 (AI's proposal): divide by permissions.Four bots, split by "blast radius if it screws up." I punctured that too: "The permission gate is already asking at every step. Dividing identities by permission again is doing the same job twice." Push that logic to its conclusion and the self-consistent answer is one all-permissions bot behind one permission gate — the axis of division dissolves. Version 2 died.

Version 3 (my call): divide by "context you don't want to rebuild."One project, one bot, for exactly one reason:so you don't have to re-read the code and re-read the memory every time.

That's the final answer:a bot exists not because of a function, not because of permissions, but because of context you don't want to rebuild from scratch every time.Functions can be skills, permissions can be a gate — only "long-term memory of this specific project" has nowhere else to live.

Once that axis was set, the corollaries grew on their own:

• Identities that need toaccumulate memory→ persistent bots. Very few of them.
• One-off roles that needfresh eyes(proofreading, review) → disposable temporary agents. There's a counterintuitive point here: proofreading should *not* use a persistent bot — a proofreader who has accumulated memory gets assimilated into your thinking and goes blind alongside you.
• A cross-cutting "department" (marketing, say) is justified on exactly one condition:that function genuinely accumulates something across projects.My advertising lessons are scattered across five projects with nowhere consolidating them — so a marketing bot is justified.

Memory: the session is a cache, not storage

Back to that foundational sentence: "conversations that run too long get compressed, and compression breaks things."

For most AI assistants, "memory" is the conversation log itself. When the conversation gets too long, the system auto-summarizes and compresses it — and what gets compressed away is always the exceptions, the details, the "this is exactly where it went wrong last time" parts. Compression is lossy, and what it loses is precisely the most valuable part.

So the rule in this shogunate is:

• ❌ a bot's memory = the conversation session ← gets compressed, and exceptions go first
• ✅ a bot's memory = files (we call themoboegaki, memoranda) ← the session is just a window, a cache, not storage

Every bot reads its own memorandum before starting work and writes anything worth keeping back at the end: facts, decisions, mines it has stepped on. Paired with a second, unchanging layer — thekakun, house precepts(how it operates) — the two split cleanly: precepts are "how to work," memoranda are "what you know."

The precepts aren't decoration; they're compressed lessons. The marketing bot's precept, "check your supply lines before going to war," comes from a real ad campaign: money spent, signups arriving, revenue zero — it broke at the final step of the payment flow, and nobody had verified it before launch. The ops bot's precept, "reporting success isn't success," comes from an ops task that hit four traps in a row. Ten-thousand-plus NT dollars of tuition compressed into one sentence, auto-loaded at the start of every session — and it demonstrably works: after writing a file, with nobody asking, the ops bot ran a verification command on its own to confirm the write had actually landed.

The company metaphor: copy half of it

"Like a company" was the original spec, but copying it wholesale gets it wrong. My conclusion after thinking it through:half of corporate structure exists to solve the limitations of *people*— people are expensive, can only do one thing at a time, and leave, taking their memory with them. AI has none of these limits, so the structures that solve them shouldn't be copied.

• Transferable: departments. But a department's essence isn't a grouping of people — it'san axis for filing memory: "who owns remembering this lesson."
• Not transferable: thinking in headcount (spin up as many AI as you want), deep hierarchy (two layers max: me → the assigned bot → a temporary agent; any more is a game of telephone), and QA independence enforced through incentive design (the AI equivalent isn't incentives, it's the fresh eyes above).

Then, because a corporate skin is genuinely boring, I swapped it for a shogunate one. The sobayōnin (chamberlain — the only entity in the system permitted to interrupt me unprompted; the right to interrupt is a budget, spend it sparingly), the jōdai (ops), the gunshi (strategist — marketing), the yūhitsu (scribe — documentation), the metsuke (inspector — impeaches, never does the work), and the shikan (chronicler — this article's source material is his first volume). The mechanisms got names too: asking permission is shuin (the vermilion seal), delegation is hikyaku (the courier), the morning standup is chōgi (the morning council), and the 50 project bots that sleep until summoned are sankin-kōtai (alternate attendance).

Honmaru Goten — the org chart on the system's home screen. Every node is an entrance: tap it and you're in that retainer's conversation. Top right is a live quota gauge.

The reskin sounds like a lark, but it does real work:names carry rules."Sobayōnin" makes a model remember "I'm the only one who can interrupt my lord unprompted, so I'm the one who should least abuse it" far better than "notification-manager" ever could.

The table of hard-won lessons

One night and half a day, and plenty of traps. The ones worth archiving:

1. Before you commit, spend 30 minutes testing the single unknown.(The dead end above — not testing first would have cost a day.)
2. Failure gets remembered.After its delegation feature failed the first few rounds, the bot concluded on its own that "this feature has been disabled," and stopped even trying. Change the design and you have to clear the old conversation and retest — otherwise you're testing its prejudice, not your new design.
3. A mechanical "deny" has to put the truth in the reason.The system would deliver a message on the bot's behalf, then return a formal deny; the model saw the deny and resent, got denied, resent again. The fix isn't to block it — it's to state plainly in the denial reason that "the message was actually delivered." Models read reasons.
4. Two bots being polite to each other = an infinite loop burning money.In the first live test, a test bot received a message and politely replied; the other side politely replied back… Loop protection has been mandatory ever since: once peer triggers exceed a consecutive limit, it hard-stops.
5. Commands that are nominally read-only may not be.Initially every action required approval, and I was quickly buried in cards, so I opened a "read-only commands skip approval" allowlist. While building it, a unit test caught this:find is a query command, but with certain flags it deletes files. Write allowlists against tests, not from memory.
6. Before you wait on a signal, confirm the signal actually appears.Wrapping up, a monitoring script waited five minutes for the word "success" — turns out that program writes no log at all on success. The bot had actually finished in five seconds.
7. Reports can be ugly; they cannot be silent.The AI composes the morning standup before sending it, but the composition layer needs a fallback that doesn't go through the model at all: if composing fails, send the raw list. Better ugly than missing.
8. The watchdog can't live inside the dog it watches.If your monitoring code runs inside the service it monitors, the service goes down and the monitor goes with it — and you never get that alert.
9. Every approval card a user has to tap must answer "who, doing what, and why are you asking me."I hit this the moment I started using it: it asked me to approve a string of commands with no explanation whatsoever. Asking permission isn't offloading responsibility onto a human — it's putting the information needed to judge in front of them.

The ledger

• Timeline: the idea struck late on day one, the whole system went live on the morning of day two — one night and half a day.
• Scale: roughly 900 lines in the main program, about 700 in a single-file front end, external dependencies close to zero.
• The brain: a resident Claude Code CLI process on a subscription plan, not the metered API — a flat monthly fee makes experimenting painless.
• Cost samples (converted to API pricing; actual usage ran on subscription quota): one full round of collaboration between two bots took 56 seconds and about US$0.45; a delegated task with an approval step, US$0.10–0.37; one morning standup, 1–3 minutes of model time.
• Outsourcing: even the AI outsources — skin adjustments go to a cheap model, while the main model is reserved mostly for architecture and reasoning.

Not open-sourcing it yet, but I wrote this

I did consider open-sourcing it. Not yet. The differentiated parts (the memory system, the inspection checklists) aren't finished, permission validation is still dev-grade, and the git history contains real config files — a public version would mean starting over in a fresh repo.

But the logic from the last post,on the decision to open-source, applies here in reverse: even without open-sourcing, writing out the thinking captures about 80% of the value. This post is that.

Next comes the validation period: I'm going to use it for a few days and see whether it beats just opening a Claude Code window. The test is simple — which one am I still using a few days from now. The answer goes in the next post.

FAQ: multi-agent AI systems

What is a multi-agent AI system?

A system where multiple AI operate with their own identities, memories, and remits, and can delegate work to one another. The difference from "one AI playing several roles" is that each agent has its own independent long-term memory and working directory — memories don't contaminate each other, and they don't vanish when a conversation ends.

How should bots in a multi-agent system be divided?

The conclusion after two AI-proposed versions were overturned by testing: don't divide by function (functions should be shared, reusable skills), and don't divide by permission (permissions belong to one unified gate). Divide by "context you don't want to rebuild every time" — one bot per project or function that needs long-term memory. Work that needs fresh eyes (proofreading, review) should use disposable agents instead; a reviewer with accumulated memory gets assimilated.

How should long-term memory for AI be built?

Don't rely on the conversation log. Long conversations get auto-compressed, compression is lossy, and the first things lost are exceptions and details. The reliable approach is files: the AI reads its memory file before starting work and writes new facts, decisions, and lessons back at the end. The conversation is only a window; the file is the storage.

Is it safe to let AI have permission to act?

Handle it in three layers. First, every action requires human approval by default (in testing this has to use an interception mechanism, not a mode that outright refuses — a refused model just gives up). Second, verifiably harmless read-only commands go on an allowlist that skips approval — but test that allowlist, because some query commands turn into deletions with certain flags. Third, approval cards must state "who, doing what, and why they're asking you," or approval becomes blind signing.

Subscription AI or metered API?

For experimental, high-frequency personal systems that stay running, a subscription-based resident process is the better deal — a flat monthly fee means you can let it run freely. The metered API suits production products with predictable traffic. In this test, one round of two-agent collaboration ran about US$0.45; on the API, heavy experimentation would add up fast.

Further reading: - Three things I settled before open-sourcing my game - What automated lead-hunting actually costs: four days, 638 posts, and one reply seen by three people