An employee handbook for my AI staffessay

A while back, a bug fix in my homelab was committed, pushed, and marked done. Weeks later the bug was still alive. Nothing errored; the fix was real code sitting in the repo, looking exactly like success, because the running process never restarts itself just because a file changed. What that quiet failure exposed wasn’t a smarter-AI problem. It was a paperwork problem, and the paperwork is what this post is about.

Every AI session I start is the same employee: brilliant, tireless, but suffering from total amnesia. It has never seen my homelab, doesn’t know the family depends on the photo server, and will cheerfully re-propose the idea I rejected weeks ago, with the same confidence I once found charming. Companies solved this problem long before AI existed. It’s called institutional memory, and it lives in onboarding docs, decision records, and procedure manuals rather than in any employee’s head. So that’s what I built: an employee handbook for a company with one human and a rotating staff of machines.

The onboarding packet comes first: context files that every session reads before touching anything. Who I am, what the systems are, where things live, and the house rules, including the ones written in scar tissue (“when something breaks at 11pm, roll back, don’t debug”). New hire, day one, here’s the tour.

The decision log is where my past reasoning became something my staff can grep. Every non-trivial choice gets an entry in a fixed shape: the context, the options considered, the decision, and (the field that has paid for itself most) how reversible it is. The log now runs to hundreds of entries, and its real customer isn’t me. Before an agent proposes a change, it searches the log; the idea I rejected weeks ago comes back to it as history rather than inspiration. It’s admittedly an upfront token hit, but it pays dividends in dead ends never chased.

Skills are the piece I’d defend in a design review: procedure manuals for recurring work. How to add a service to the Docker stack without missing the monitoring step. How to operate the alert pipeline. How to publish a post to this blog without violating its own style guide. Writing them is easy; the hard question is whether they’re actually complete, or whether they secretly rely on knowledge in the head of whoever wrote them, which is the ancient failure mode of all documentation. So skills have to pass an exam before they count. A fresh model, given no context except the skill itself, gets handed real tasks closed-book. If it performs them correctly, the skill works. If it stumbles, the document failed, not the model, and the gap it fell into is exactly what I fix. Before the exam, a panel of parallel reviewer agents goes at the draft adversarially, fact-checking claims against the live systems. My documentation is the only thing in the lab that has to pass a test to get hired.

Two habits keep the whole thing from rotting. Every fact lives in exactly one canonical home, and everything else points to it; I learned this after chasing two staleness bugs to the same root cause, a fact duplicated into two files that drifted apart. Here’s the actual entry from the day that habit became law, as my staff reads it:

2026-06-12: canonical homes

Decision: every durable fact gets exactly ONE canonical home
(a skill, else an inventory doc, else the context file);
every other mention is a pointer.

Rationale: this week's two staleness bugs both traced to the
same root cause: a fact duplicated into two homes that
drifted apart.

Reversibility: trivial. Content moved verbatim; git history
has the originals.

The second habit: every project that ships gets a closeout sweep, updating each document that mentioned it, because a handbook that says “in progress” about something finished for a month teaches staff to distrust the handbook. The quiet failure from the opening is what hardened both habits into their current shape: deploy steps now live in the skills themselves, and “done” means the procedure’s verification passed, not that the code left the laptop.

This is the through-line of the whole blog: I change AI models the way other people change radio stations, and it costs nothing, because the memory was never in the model. The staff turns over weekly; the company remembers.