The Co-Pilot Model

• 8–12 ha week for the whole project
• ~80small memory files behind the index
• ~11words in a typical message

The distinction that matters

There is a version of “using AI” that looks like this. You open a chat window, type a question, get an answer and close the window. Tomorrow the model has no memory of you, your project, your earlier decisions, what you tried that failed, or the constraints you work inside. Every conversation is session zero, and you spend the first five minutes re-explaining.

That is fine for one-off questions. It is a terrible way to run a project that lasts months and a hundred sessions, where the value of the work compounds and so does the cost of repeating yourself.

The co-pilot model is the other thing. The model is still the model. The system around it persists: a knowledge base, a memory, a tracker, rituals, hard rules. The model walks into every conversation with most of the context already loaded, and walks out having updated it.

---

What persistence looks like

The project knowledge file

At the root of the project is one file of about four hundred and fifty lines. It grows by ten or twenty lines a week and it is the first thing the co-pilot reads in any session. It holds:

• A system overview. What the house is, what is in it, when things were installed.
• Hard rules. Twelve numbered, non-negotiable rules, each one there because something went wrong. Never push automation YAML to live without explicit authorisation. Never split a climate mode change and a temperature change into two calls. Every session ends with a persistence sweep. They are short and unambiguous on purpose. Soft guidance does not survive a long session.
• Tested patterns. Enough detail that a future session can apply them without re-deriving them. Every entry is a failure I made, a root cause I found, and a rule I now refuse to break.
• An incident log. A dated table of what broke, why, and the fix. When something new breaks, I read it first to see if it is a variant of something old.
• Known risks. The fragile bits I haven’t fixed yet. This is my list for an unscheduled hour.
• A file inventory. The antidote to the slow rot where nobody, including the author, can say where the canonical version of anything lives.

No one section is clever. The point is that it is the same file every session, it is updated every session, and it accumulates. Read cold, it gets you useful in about five minutes. Without it, every session would burn those five minutes on re-orientation.

The memory

Alongside it is a smaller, more personal layer: an index, and behind it around eighty small memory files. Each is one fact or one rule about me, the project, or feedback I have given, written to survive being read alone by a session with no other context.

They cover who I am and how I like to work, the state of each part of the project, what the data has shown, and a set of behavioural rules for things I have had to correct more than once. Save memory at every significant advance. Never accept first output. British English, always.

The index means the right memories surface when needed and the rest stay quiet. This is what turns “the model walks in cold” into “the model walks in knowing what I have already told it.”

The issue tracker

The knowledge file is the project’s brain and the memory is the personal layer. The tracker is the spine.

It holds ten projects, about fifty issues, and a few dated milestones that act as forcing functions. Every piece of work, whether an interactive session, an overnight task or a fix found mid-something-else, is on the board. If it isn’t on the board, it isn’t real.

That sounds like over-engineering for one person. It isn’t, because once I started running tasks overnight, agents producing drafts and audits while I slept, the next-morning version of me needed one place to see what had run, what had failed and what was blocked. The knowledge file is good for facts and rules. The tracker is good for state. It lets me close the laptop on a Saturday night, schedule six tasks, and trust that nothing will evaporate by Sunday.

The rule behind it: every session ends with a sweep. Update the knowledge file if something was learned, the memory if something load-bearing changed, and the tracker. That rule didn’t exist on day one. It exists because on day fifty I went looking for a decision I knew I’d made and couldn’t find it, and that was unpleasant enough to be worth a hard rule.

---

The session, start to finish

At the start, I check the tracker for what is in progress. That is what the previous version of me thought was next, and unless I have a strong reason to override it, that is where I start. Then I read the knowledge file top to bottom, and the memories the index says are relevant. Then I start work. It takes well under ten minutes and it is the highest-value ten minutes of the session, because it makes session N a continuation of session N minus one.

During the session, the working style is conversational. My typical message is about eleven words: try this, no, the other thing, now expand the section on X. The co-pilot iterates with me, and the knowledge base and memory let it push back when I’m wrong. I ask it to flag risks and challenge my framings. When the output is wrong I say so, often bluntly. The co-pilot model is not a magic oracle. It is a partner that shares state with me.

At the end, the sweep runs. New patterns into the knowledge file, new facts and feedback into memory, finished work closed and new work filed.

The next session inherits the closed state, and the five-minute re-orientation works because there is something to re-orient to.

---

A week of entry points

Here is an ordinary week as a list of sessions.

• Monday evening, forty minutes. The tracker says a dashboard fix is outstanding. Read the relevant memory, do the fix.
• Tuesday lunch, fifteen minutes. An oddity in the daily import number. Quick check in the datastore, log the finding on the issue.
• Wednesday evening, ninety minutes. A blog draft, iterated against the quality metric.
• Thursday. No session.
• Friday evening, two hours. A new finding that belongs in two places. Update the analysis note, comment on the issue, queue the blog rerun.
• Saturday morning, thirty minutes. Triage the tracker.
• Saturday night, ten minutes. Schedule three overnight tasks and close the laptop.
• Sunday morning, forty minutes. Read the overnight output, score it, decide what ships.

About half of these start from a tracker issue. The other half start from a free-form prompt that ends with a sweep that creates one. Either way the board converges with reality.

There is nothing exotic about any one piece of it. The exotic thing is that all the pieces are in the same place, talking to each other, and they survive between sessions.

---

Why this matters

A side project this size would once have died of its own complexity. Not because any piece was hard, but because holding it all in one head between sessions, on eight to twelve hours a week, is brutal. You forget what you decided, re-derive what you already derived, and re-discover bugs you already fixed. You quietly stop touching the bits you can’t remember the state of, and those bits rot.

The knowledge file cures forgetting what you decided. The memory cures re-explaining yourself. The tracker cures things falling through the cracks. The rituals cure the drift that turns a project into a graveyard.

None of this is the model. The model is one component, and the system is what does the work.

The next post is about the part of the system I trust least: the first draft. The first draft of my first post for this blog had eighteen factual errors, all confidently stated. Here is what I built so it doesn’t happen twice.