The AI Operating Assistant Setup for Solo Founders

An AI operating assistant is a general-purpose AI model wrapped in a fixed set of context files, rules, and verification gates so it can do real work without you supervising every step. The model is the commodity. The files that govern it are the asset, and building them is a founder skill, not a prompt trick.

I run this setup daily. The largest system I operate is a real-time multiplayer platform I build alone, and the governing files for it have grown to 16,068 lines across eight markdown ledgers. Those ledgers currently hold 134 recorded architecture decisions and 217 logged working sessions across 1,583 commits. I am pre-revenue, so I have no MRR chart to show you. What I do have is a working system for keeping an AI assistant accurate across roughly 5,400 hand-written source files in six languages, and that is what this post is.

This sits inside the wider founder stack. Read it alongside AI workflows for solo SaaS founders for which tasks to hand over in the first place, the solo founder operating system for the human half of the loop, and how to use decision logs as a founder for the discipline this whole thing rests on. It all lives under the broader SaaS Playbooks pillar.

Key takeaways

• An AI operating assistant is a model plus governed context. Founders who get value from AI are not writing better prompts, they are maintaining better files.
• Drift is the core failure mode. An assistant with no written record re-proposes ideas you already rejected, because from its side of the window you never rejected them.
• Five ledgers do almost all the work: constitution, facts, decisions, state, history. Two hours to create, then a habit.
• A written precedence order matters more than any single file. When two documents disagree, the assistant needs a rule, not a judgment call.
• A forbidden list of enumerated negative constraints outperforms a longer positive prompt, because “never do X” is checkable and “please be careful” is not.
• Verification gates are the difference between output and work. Nothing counts as done until something automated says it passes.

What is an AI operating assistant?

An AI operating assistant is an AI model that you have given a persistent, structured context: a set of files it reads at the start of every session, rules about which file wins when two conflict, and gates that define what must be true before its output is accepted. It converts a stateless chat tool into a system that accumulates knowledge about your specific business.

The word “operating” is doing real work in that phrase. A chat assistant answers questions. An operating assistant participates in the running of the company, which means it needs the same three things any new hire needs: written context, clear authority limits, and a way to check its work.

Most founders skip straight to tooling questions. Which model, which editor, which agent framework. Those choices matter far less than whether you have written down what your business already decided. A weaker model with excellent context beats a stronger model with none, on almost every task that touches your specific product.

Why AI assistants drift on real codebases

Drift happens because each new session starts with no memory of your prior decisions, so the assistant reasons from general best practice rather than from your specific constraints. It re-suggests the library you rejected for licensing reasons, renames things away from your convention, and proposes an architecture you already ruled out.

This is not a model weakness. It is an information problem, and it gets worse as the system grows. On a small project the assistant can read most of the code and infer the conventions. Past a certain size it can only see a slice, and a slice does not contain the reasoning.

I hit this hard. Somewhere around the point where the platform crossed a few dozen services, I noticed the same three arguments repeating every week. Not because the assistant was wrong, but because nobody had written the conclusion down anywhere it would look. The fix was not a smarter model. The fix was a file.

The other half of drift is silent. An assistant will rarely tell you it lacks context. It will produce something confident and plausible that is subtly wrong for your situation, which is more expensive than an obvious failure because it survives review.

The Five Ledgers: the file system that makes an assistant reliable

Five files do almost all of the work. Each answers a different question, and the separation matters, because mixing them is what makes context files rot into an unreadable wall that nobody updates.

Ledger	Answers	Write pattern	Failure if missing
Constitution	What are the rules, and which document wins?	Rewritten deliberately, rarely	Assistant invents its own conventions
Facts	What is true and must never be contradicted?	Append + correct, never casually	Confident output contradicts reality
Decisions	What did we choose, and why?	Append-only, one entry per choice	Settled arguments reopen weekly
State	What exactly is in flight right now?	Overwritten every session	Sessions restart finished work
History	What happened, and what surprised us?	Append-only, one entry per session	No pattern detection over time

Constitution. The single file the assistant reads first. Mission, the rules that cannot be broken, the locked stack or locked process, and the precedence order. Mine is about 200 lines and it is the single most consequential file in the repository. Under 300 lines is a good ceiling, because a constitution nobody re-reads stops being one.

Facts. Things that are true and are not up for discussion: your entity structure, your naming rules, your brand constraints, your identity, the version numbers you are pinned to. The rule I write at the top of mine is blunt: if the output contradicts this file, the output is wrong. That single sentence prevents an entire category of confident error.

Decisions. An append-only record, one entry per architectural or business choice, in a fixed shape: context, decision, consequences. This is the file that pays back the most over time, and the reason is not documentation. It is that the assistant reads your reasoning and stops re-litigating.

State. The only file that gets overwritten. What task is in flight, which files are open, the next three actions, the commands to re-run. This is what makes a session survive an interruption, and interruptions are the default condition of solo founding.

History. One entry per session: date, what shipped, what broke, what surprised you. It reads like a captain’s log and it is the file you will thank yourself for in six months, when you are trying to remember why something was done a particular way and the decision log only has the conclusion.

The Context Precedence Ladder

When two files disagree, the assistant needs a rule rather than a judgment call. A precedence ladder is one line in your constitution stating which document wins, and it eliminates a whole class of failure where a stale doc quietly overrides a current decision.

Rank	Layer	Changes	Overrides
1	Constitution	Rarely, deliberately	Everything below
2	Immutable facts	Only with a recorded decision	Specs and docs
3	Decision log	Append-only, superseded not edited	Specs and docs
4	Feature or spec source of truth	Per planned change	Supporting docs
5	Supporting docs	Freely	Nothing
6	Code comments, chat history, memory	Constantly	Nothing

The bottom row is the one founders get wrong. Chat history feels authoritative because it is recent and you were there. It is the least reliable layer in the stack, because it was never reviewed, never versioned, and cannot be diffed.

The practical test of a good ladder: when the assistant says “the spec says X but the decision log says Y,” it should already know which to follow without asking you. If it has to ask, your ladder is not written down clearly enough.

How to write a constitution file the assistant will actually obey

Write it as law, not as prose. Short declarative rules, grouped by area, with no hedging and no explanation of why unless the why changes behaviour. Long explanatory paragraphs get compressed and lost, while short imperative lines survive.

Four properties separate constitutions that work from ones that get ignored:

Precedence at the top. Before any rule, state which documents win. The assistant then knows how to resolve every conflict it will meet later in the file.

Rules, not preferences. “We use conventional commits” is a rule. “We generally prefer cleaner commit messages” is a preference, and preferences get negotiated away under pressure. If you would accept a violation, it is not a rule and it does not belong in the constitution.

Explicit authority limits. State what the assistant may never do without you. Mine says all work happens on the development branch and never on main, and that I personally do the merge at each gate. That single boundary means the worst realistic outcome of a bad session is a branch I delete.

A pointer table, not a dump. The constitution should not contain your architecture. It should contain a table saying “before touching area X, read document Y.” Mine routes seventeen areas to their specs. This keeps the always-loaded file small while making the deep context reachable on demand.

Why a forbidden list beats a longer prompt

A forbidden list is an enumerated set of things that hard-fail: technologies you will not use, patterns you will not accept, words you will not publish. It works better than positive instruction because negatives are checkable. You can grep for a banned word. You cannot grep for “wrote it well.”

Positive instructions describe an infinite space and the model has to guess where in that space you live. Negative constraints carve away specific regions and the boundaries are unambiguous. That is why the same effort spent listing what you reject beats the effort spent describing what you want.

My platform constitution carries a forbidden list of specific technologies and patterns, each one representing an argument I already had and do not want again. This blog carries its own: a banned-phrase list that a shell script checks before anything is publishable, covering both AI tells and hustle-culture tells. The list runs as a gate, not as a suggestion, which is the entire point.

The maintenance rule is that every forbidden item earns its place by having actually happened. Do not populate the list with hypothetical mistakes. Add an entry the first time something goes wrong, and the list stays short and real.

The session-start and session-end protocols

These two protocols are what make context persist across sessions, and they are the part most founders skip. Without them the ledgers exist but nothing reads or updates them, which is worse than not having them, because stale files are actively misleading.

Session start, in a fixed order:

1. Read the constitution top to bottom.
2. Read the state file: the exact task in flight and its status.
3. Read the current phase checklist.
4. Read the last two entries in the history file.
5. Read the specific spec documents that the state file names for this task.
6. State a three-line plan, then continue. Never re-audit the repository, never restart finished work.

Session end, before stopping or when context gets heavy:

1. Update the state file: task, files in flight, next three actions, commands to re-run.
2. Tick the phase checklist.
3. Append to the history file: date, what shipped, what surprised you.
4. Record any architectural choice as a new decision-log entry.
5. Commit the ledger updates as their own change.

I run the end protocol every five commits rather than only at the end of a session, because sessions do not end cleanly. They get interrupted. The five-commit rhythm means the worst case is losing a small slice of context rather than a whole day of reasoning.

The step that earns its keep beyond all the others is the “next three actions” line in the state file. Reopening a system cold and finding three concrete actions written by yourself removes the twenty minutes of re-orientation that otherwise starts every session.

The pointer table: a hand-built retrieval index

A pointer table maps areas of work to the documents that govern them, so the assistant loads the right deep context on demand instead of holding everything at once. It is a manual retrieval index, and on a large system it outperforms letting the assistant search, because you know which document is authoritative and search does not.

The format is two columns and nothing else:

Before touching	Read first
Pricing or plan changes	pricing spec + decisions log
Database schema	schema doc + migration rules
Anything customer-facing	brand rules + legal constraints
Build system	build doc + version pins
Payments	payments spec + provider constraints

Mine has seventeen rows pointing into 67 spec documents. Without it, a session either loads too little context and guesses, or tries to load everything and runs out of room for the actual work.

The reason this beats semantic search on your own codebase is authority. Search returns what is similar. A pointer table returns what is correct. When five documents mention pricing and only one governs it, similarity ranking will not reliably pick the right one, and you already know the answer.

Verification gates: what has to be true before you trust the output

A verification gate is an automated check that must pass before work counts as done, stated in advance and run by a machine rather than by your judgment at the end of a long day. Without gates you are reviewing everything manually, which does not scale, and your review quality drops exactly when session length is longest.

My gates on the platform are the boring ones: the build passes, tests pass with unit coverage above a fixed floor, integration tests run against real containers, contract linting catches breaking changes, and every file carries its required header. On this blog the gates are a banned-phrase linter, a frontmatter schema that fails the build on an unknown field, and a production build that must complete with zero warnings.

The shape matters more than the specifics. A gate has three properties: it is written down before the work starts, it is checked by something other than you, and failing it blocks the work rather than generating a note. A checklist you tick by hand at midnight is not a gate.

There is one gate you should never automate, which is the human review before anything reaches your main branch or your customers. On my platform the assistant never touches the main branch. Work happens on a development branch, gates run, and I do the merge personally. That boundary has never cost me anything and it caps the blast radius of a bad session at “delete a branch.”

For the reasoning behind gate design generally, Google’s SRE book chapter on postmortem culture is still the clearest treatment of why blameless, written records beat remembered ones.

How long does it take to set up an AI operating assistant?

The first usable version takes two to four hours: write the constitution, write the facts file, and start the decision log. The system becomes genuinely reliable after two to three weeks of daily use, because that is how long it takes for the decision log to accumulate answers to the questions your assistant keeps asking.

Setup is not a one-time project. Roughly ninety percent of the value in my ledgers came from the append-as-you-go habit, not from the initial write. The first version of my constitution was under a hundred lines. It reached its current shape by having a rule added every time something went wrong.

Here is a realistic first week, if you want a concrete starting point:

Day	Work	Time
1	Constitution v1: rules, precedence ladder, authority limits	90 min
1	Facts file: entity, naming, brand, pinned versions	45 min
2	Decision log: back-fill the last 10 choices you already made	60 min
3	State file + session-start and session-end protocols	30 min
4	First verification gate (a linter or a schema check)	60 min
5	Pointer table for your three busiest areas	30 min
6-7	Run the protocols. Add a rule every time you correct the assistant	ongoing

What does an AI operating assistant cost to run?

The files cost nothing. They are markdown in a repository you already have. The real cost is the model subscription, which for a solo founder in 2026 sits in the range of a normal professional software subscription, plus the time to maintain the ledgers, which settles at roughly ten to fifteen minutes per working session.

The comparison worth making is not “AI subscription versus zero.” It is the cost against the alternative of the work not happening at all. I run a six-language platform, a mobile app portfolio, and four content properties alone. Without this system some of that simply would not exist, which makes the honest comparison closer to a contractor day rate than to a software subscription.

I will not tell you it pays for itself, because I have no revenue yet and that would be a claim I cannot support. What I can say is that the infrastructure question is separate and cheaper than founders assume. My platform is built to launch on a single ARM node at 25 euros per month, and the same reasoning applies to the single VPS SaaS playbook. The assistant subscription is the larger line item, not the servers.

When does an AI operating assistant stop being worth it?

It stops being worth it when the task is genuinely novel, when a wrong answer is expensive and hard to detect, or when the relevant context is larger than what you can write down. Legal structure, tax positions, security architecture, and irreversible customer commitments belong in the category of draft with the assistant, decide with a human.

The detectability test is the sharpest one. Ask: if this output were wrong, how long until I found out? Code that fails a test is detected in seconds. A subtly wrong tax position is detected in a year, by someone else, expensively. The longer the detection lag, the more human review the task needs, regardless of how confident the output sounds.

The second test is reversibility. A bad function is a revert. A bad email to your entire list is not. Route work by blast radius, not by how hard it looks. This is the same logic that governs which decisions belong in your decision log in the first place.

There is a third case worth naming: when writing the context would take longer than doing the task. If the situation is a one-off and explaining it fully costs an hour, do it yourself in twenty minutes. The system is for recurring work in a stable domain, not for every task you touch.

A worked example: what one governed session actually looks like

Concretely, here is the shape of a real session on my platform. I open the repository. The assistant reads the constitution, the state file, the phase checklist, the last two history entries, and the two spec documents that the state file named. That takes a couple of minutes and no input from me.

It then states a three-line plan. I either confirm or correct it, and a correction at this point costs seconds, whereas the same correction after two hours of work costs the two hours. This is the highest-value thirty seconds in the entire loop.

Work proceeds in small commits, never more than about thirty minutes of work per commit. Every fifth commit triggers the end protocol: state file updated, history appended, any architectural choice recorded as a decision entry. At the end of the phase, the gates run and I review and merge personally.

One real failure from that log, because the honest ones are more useful than the clean ones. I had been running long-lived development services as background tasks and assumed they would survive session exit. They did survive a natural exit, because orphaned child processes get re-parented. They did not survive a task being killed, because killing the task kills the whole process group, and one afternoon I took the entire local stack down without understanding why. The fix was to launch long-lived services fully detached. The lesson went into the history file the same day, and the rule went into the constitution, which is exactly the flow the system exists to produce.

The 12-point setup checklist

Use this as the gate for whether your setup is real or aspirational. Every item is either true or it is not.

1. A constitution file exists and is under 300 lines.
2. It states a precedence order for resolving conflicts between documents.
3. It states explicit authority limits: what the assistant may never do alone.
4. An immutable facts file exists and says that output contradicting it is wrong.
5. A decision log exists, is append-only, and has at least ten entries.
6. Entries are superseded by new entries, never edited in place.
7. A state file exists naming the task in flight and the next three actions.
8. A history file exists with one entry per session, including surprises.
9. A session-start protocol is written down and followed in a fixed order.
10. A session-end protocol runs on a rhythm, not only at natural endings.
11. At least one verification gate is automated and blocks work on failure.
12. A human review step exists before anything reaches main or customers.

If you have fewer than eight of these, you do not have an operating assistant yet. You have a chat window with good intentions, which is a different thing and produces different results.

Mistakes that quietly destroy the system

Letting the constitution grow. Once it passes a few hundred lines, it stops being read in full and starts being skimmed, which is functionally the same as not existing. Move detail into spec documents and keep pointers in the constitution.

Editing decisions instead of superseding them. An edited decision log loses the thing that makes it valuable, which is the record of what you used to think and why you changed. Append a superseding entry and mark the old one. This is standard practice from Michael Nygard’s original write-up on architecture decision records, and the discipline transfers directly to business decisions.

Skipping the end protocol when you are tired. This is the failure mode that gets everyone, including me. The session where you are too tired to write the ledger is exactly the session whose context you will most want back. Running it every five commits rather than at session end is a structural fix for a willpower problem.

Treating output volume as progress. A large amount of unverified plausible work is a liability, not an asset. If nothing automated checked it, it is a draft.

Writing aspirational rules. A rule you would let slide is not a rule, and one ignored rule teaches the assistant, and you, that the constitution is advisory. Delete rules you do not enforce.

No first-hand contribution. If the assistant is producing all of the substance and you are only routing it, you have built a content mill rather than a business. Martin Fowler’s ongoing writing on generative AI in engineering is a good corrective here, as is Simon Willison’s running record of AI-assisted programming, which is unusually honest about where the tools actually fail.

Want the system, not just the article?

The Bootstrapped Founder Operating System collects the ledger templates, the precedence ladder, the session protocols, and the verification gates in one place, along with the rest of the operating playbooks from this blog.

Get the workbook →