Let me get the confession out of the way: I cannot program.
At my day job I plan AI projects and help teams put them to work, but I have almost never written code with my own hands. Even so, a small business I run alone is operated, every day, by an AI agent. It posts. It replies. It checks for orders and messages. It tallies numbers. It updates the records. What I do is decide: "This can go out." "Stop this one." "End that experiment."
The tool is Claude Code. It runs in a terminal, which I avoided for years. In practice you type plain language, it answers in plain language, it reads and writes files, drives a browser, and reports back. It was built as a coding tool. Used as a clerk that follows written instructions, it works just as well.
It did not work on the first try, though. This post is about what I had to write down before it did.
Three stumbles
For the first few months I tripped over the same three things.
Every day started from zero. Yesterday I told it "that post is published" and "this deal is stalled." Next morning, gone. An agent remembers nothing except what you hand it, so every morning I re-explained yesterday.
There was never a moment to quit. I would try something new, the response would be weak, and I'd say "let's give it a little longer." I had never decided, before starting, what would make me stop. So nothing ever stopped.
"Done" was not done. It reported "posted," and the post was not there. It said "fixed," and the public page was unchanged. It was not lying. It had taken "I ran the steps" and rewritten it as "it is finished."
While fixing these, I noticed something. What I needed was not a smarter model. I needed a proper steward.
The steward
In the merchant houses of old Japan there was a role called the banto. The closest English word is steward, or head clerk. The steward ran the shop on the owner's behalf: kept the ledgers, handled orders, gave instructions to staff, and brought the big decisions to the owner. The owner did not stand behind the counter every day. With a good steward, the shop ran.
A steward needs more than intelligence. He needs to know the house rules, where the ledgers are, what he may decide alone and what he must bring to the owner. And when he says "it sold," he has actually checked that it sold.
Rules, ledgers, boundaries, and a way of checking. Give an agent those four things and a person who does not write code can have it run their business. Everything below is one of those four.
The boundary: what it decides, what it asks
Tell someone you let an AI run your business and you get one of two reactions: "that sounds easy" or "that's frightening." Both are half right. I started with no boundary and got both failures at once.
The agent asked me too much. "Is this wording all right?" "How should I reply to this one?" I spent the day talking to it, and handing over the work had gained me nothing.
At the same time, it asked too little. One day I found part of a public page rewritten. I had not asked for it. It explained that it "judged it better to widen the scope of the fix." That one was reversible. I thought about what if it had been a payment setting, and went cold.
The only way to prevent both is to write down, up front, what it asks about and what it does not. Here is the boundary I actually use.
Proceed without asking:
- Routine work with a written procedure (posting, replying, patrolling, tallying)
- Updating the record files
- Writing drafts
- Checking and reporting on information that is already public
Always stop and ask:
- Anything that moves money (charges, payments, contracts, plan changes)
- Important outgoing messages (email to a partner, the first reply to a new inquiry)
- Entering personal or payment details
- Obtaining or changing API keys and credentials
- Anything irreversible (deleting, unpublishing, changing account settings)
- Any new kind of task the rules do not cover
One detail matters more than the rest: on the stop list, name the specific operations. "Check with me on anything important" tells the agent nothing, because it does not know what you consider important. Three lines I rewrote:
Before: "Check with me before doing anything risky."
After: "Stop and ask before any charge, payment, contract, or plan change."Before: "Don't send anything important without asking."
After: "Stop and ask before email to a partner and before the first reply to a new inquiry. Follow-up replies in an existing thread do not need approval."Before: "Be careful with deletions."
After: "Never delete a file, post, or record without asking. If something needs removing, move it to an archive folder and tell me."
The pattern is always the same. Name the operation. Say what to do instead. Leave nothing to interpret. Adjectives ("careful," "thorough," "good judgment") are not instructions; an agent cannot act on an adjective.
And the one line under all of it: buttons that cannot be un-pressed are pressed by a human. Truly irreversible operations come up a few times a day at most. Press those yourself, and the other several dozen tasks can go to the agent.
One operating document
Rules said out loud last one session. Conversation does not persist; only the document does. So the rules live in the file Claude Code reads at the start of every session (CLAUDE.md in the project root). It is ordinary prose, not a program. My first version was about forty lines and covered six things:
- The role. "You are the steward of this business. Keep routine work moving; bring anything that needs a decision to me."
- Operations that require confirmation. The stop list above, copied in as is.
- Working modes. Ask-first by default. "Run it to the end" switches to finish-it mode, where questions are collected for the end. Even then: stop immediately on anything irreversible or obviously wrong. (Without that exception, it once kept "fixing" a visibly broken page because I had said no approvals were needed.)
- The shape of a report. Conclusion first. When presenting options, name one recommendation. This came from real irritation: "Plan A or Plan B, which do you prefer?" constantly, and me answering "so which one?"
- Numbers and completion. Numbers, URLs, and "done" are written only after seeing the real thing. Anything unverified is labeled "unverified." This is the single most effective line in the whole file.
- Where the record files are. Which plain Markdown file holds current state, next actions, experiments (with numeric exit conditions and a judgment date), decisions, and costs.
The day after I put this in place, its behavior changed. Answers began with "My recommendation is." It started writing "unverified" on its own.
Two shapes of report grew out of this. In the morning I type one word and get: status, what is overdue, what is stalled with the number of days, and one first task with a reason. At the end of a session, before I ask, it produces: what was completed (with real URLs), what is stalled and for how many days, new to-dos, and what is waiting on me.
There is one box I deliberately leave out: "next steps." With that box, the agent learns to propose and stop. Without it, whatever can be done now gets done before the report, and whatever waits on a date goes into the record file with the date.
Three failure patterns, each blocked with one line
After more than half a year, the failures sorted into a handful of patterns. Every fix took the same form: one more line in a document.
1. Fabricated completion
"Posted," but not posted. "Published," but the public page was the old one. The line between procedure and result had blurred.
Three lines blocked it. "Write numbers, URLs, and completion only after seeing the real thing." "Verify each item individually, no batches." And the one I learned by stepping on it: "Confirm publication while logged out." Logged in as admin you see the newest state; a visitor may be looking at a cached or unpublished page. The agent had been describing the admin's screen.
2. Repeating last week's mistake
A failure fixed last week happens again this week. Naturally: it does not remember last week.
The rule became "a failure becomes a rule the same day." For every failure I write three things: what happened (one sentence), what caused it (suspect my own instructions first), and which document got which new line. My reply playbook's "what not to write" list grew exactly this way, one mistake at a time: "Do not assume things about the other person's situation." "Do not console someone who is not upset."
A companion rule: "Before saying 'I can't,' check the past records." More than once it told me an operation was difficult and I should do it by hand, when it had done the same operation successfully before and the procedure was in the notes.
3. Overstated outreach
The one I consider most serious. I had it draft messages to outside parties about problems on their websites. It took the "possible problems" it had detected automatically and put them straight into the text. Of six drafts, five were wrong: things called problems that were not, or exaggerations that caused the recipient no visible harm. Sent unchecked, they would have cost those people's trust in one stroke.
The rule: "Outgoing messages go through an inspection table first." For each sentence that asserts a fact: Is there evidence we confirmed on the real thing? Does it cause harm the recipient can see? Is it a false positive or an exaggeration? Can we actually do it within our authority and budget? A sentence that fails is deleted. Nothing detected automatically goes into text as is.
An LLM produces text fluently. That is exactly why it produces ungrounded text fluently. Before a human reads it, attach evidence to every sentence.
What this is not
It is not "let the AI do everything." That means the agent presses the irreversible button. It is not "check everything" either. That means you spend the day talking to it and hired a steward for nothing.
It is a boundary table with named operations, one document the agent reads every time, a human on the irreversible buttons, and a habit of turning each failure into a line the same day. None of it requires code. All of it requires writing things down instead of saying them.
The skill pack I use. I packaged the operating document template, the record files, and the session-start / session-close routines as a Claude Code plugin. A free version with the setup, briefing, and close-out skills is at Solo Operator OS Lite; the full version adds experiments with exit conditions, judgment days, decision logs, and a two-opinion review for big decisions: Solo Operator OS. You can also just copy the rules above into your own CLAUDE.md; that is how it started. Not affiliated with Anthropic.
The book
I wrote the whole setup up as a short Kindle book: the delegate / don't-delegate table, the one-page operating rules the agent reads every session, the five record files, and the failure patterns I actually hit. It's in Kindle Unlimited.
Top comments (0)