I built my AI an operating system — with MySQL, PHP and bash
In the previous article I mentioned that an artificial intelligence works inside my framework every day. What I did not tell you is the problem that almost made me give up, or the solution that has quietly become the piece of engineering I will be proudest of when I retire.
The problem is this: my AI is brilliant and amnesiac. Every morning felt like hiring the best engineer I have ever met... freshly landed from another planet. It did not remember what we did yesterday, or where things are, or how each task is done in this house, or — most dangerous of all — what must not be touched. Everything I explained in the morning had evaporated by nightfall. A genius engineer with no memory is not an engineer: it is a risk with a keyboard.
Newcomers try to fix this with note files that grow longer and longer, which the AI re-reads every morning. I started that way too. It does not scale: the notes grow, contradict each other, age badly, and nobody prunes them. I have known that disease for forty years — it is called documentation — and I know how it ends.
The scarce resource is not intelligence
The observation that changed everything comes from systems engineering, not from AI: an agent's scarce resource is not intelligence, it is context. What fits in its head within a session. Its working memory.
And managing a scarce resource — deciding what gets loaded and when, who may touch what, what is persisted and what is discarded — has had a name since the sixties: an operating system. A language model with no system around it is a magnificent CPU without a computer: capable of everything and responsible for nothing.
So I did what an old programmer knows how to do: I stopped searching for the fashionable framework that would solve it, and I built the computer. With the tools of a lifetime: a MySQL database, PHP and bash. No vectors, no embeddings, no magical semantic memory. An ordinary database with its schema written in SQL, and a CLI.
The graph
The heart of it is what I call the operational graph: a database holding all the operational knowledge of the business, in five node types. I list them because the split is half the design:
Job — something to do. It has a lifecycle (pending → open → blocked → closed) and a log of dated entries: the assignment, the actions, the decisions with their why, and a mandatory verifiable result on closing.
Resource — something that exists: a server, an application, a database, a control panel. Its card says how to reach it, how to use it, and what state it is in.
Procedure — how a repeatable task is done. The runbook: when it applies, the steps, the verification, what to do when it fails.
Person — who is who: contact, role, what they operate. Because half of running a real business is knowing whom to write to.
Rule — a cross-cutting criterion: what the result must satisfy. Different from a procedure (which is steps). More on these below, because they turned out to be the real discovery.
Seven relation types connect them (uses, follows, contains, blocked-by...), with a coherence matrix that refuses nonsense links. Plus one convention that has saved me months of over-engineering: before inventing a new relation, write a cross-reference in plain text. Prose ages better than schemas.
The mechanisms, subsystem by subsystem
The operating-system analogy is not conference-talk metaphor: every classic subsystem has a concrete counterpart.
The scheduler. A job queue with priorities. A job can be blocked by another — and when the blocker closes, the blocked job releases itself and returns to the queue. Dependencies are managed by the system, not by anyone's memory.
Paging. One command assembles the AI's startup package for any task in a single call: the assignment, the last action taken, the resources with their access details, the procedure's steps and the applicable rules. One page of context instead of six queries. Outputs have a summary mode, because every token the system does not burn on dumps is a token the AI gets to spend on thinking.
Memory protection. A guard refuses to let anyone work without context: no agent touches code, servers or data without an active job, its linked resources and procedures, and the applicable rules in front of it. It is the seatbelt against the typical agent failure mode: acting with apparent confidence and insufficient context.
Permissions. Credentials live in an encrypted vault. The AI uses them; it does not see them. And sensitive actions on production require explicit human approval, grouped and naming the exact target — not a generic "shall I proceed?" in the middle of the night.
The garbage collector. A monthly pruning: zombie jobs, incomplete cards, duplicates, broken references. On its very first pass, the collector found a duplicate node that the AI itself had mistakenly created two hours earlier. It detected it, documented it and closed it, citing the cause. That day I knew the design was right: the system cleans up after itself and leaves a record.
The audit log. Every closed job leaves its result in writing. The history of the business is no longer in my head or in emails: it is in a table, queryable, dated.
And one non-negotiable law that cuts across everything: the first action of any job is to write "started". We learned it the hard way: one morning an autonomous process died without leaving a single line, and for hours we did not even know it had died. Its successor, with the mandatory log, left a trace of every phase. In systems we have been calling this logging for fifty years; in the AI world of 2026 it still passes for an exotic idea.
The rules: a constitution
The late discovery was realising that one kind of knowledge was missing: not "what exists", not "how it is done", but what must hold. The criteria. The manias with a reason behind them. What the veteran operator knows and the new hire does not — the knowledge that dies in every company when the person who held it retires. The example is rather close to home.
So one day we swept five hundred and seventy-four documentation files accumulated over the years — plus the private notes the AI itself had been keeping — and harvested the rules scattered across all of them. Today they are about two hundred and sixty individual rules, grouped by theme, each with its source and — this is the important part — its verification. The house motto: a rule without a verification is a wish.
Rules are linked to the procedures that use them, and the guard puts them in front of the AI before it executes. They are not a document that might get read: they are context that gets loaded. The difference between having laws and having a judiciary.
The doctrine that keeps it sane
Two principles keep the graph from degenerating into what every corporate wiki becomes within two years:
The graph is a control plane, not a data plane. It holds the index, the live state and the pointers. Bulk data lives at its sources and is queried live. Reports are queries, not documents: a saved report is born stale and lies forever after.
An explicit hierarchy of truth. If the graph and a document disagree, the graph wins. If the graph and reality disagree, reality wins — and the graph gets corrected on the spot, as part of the job at hand. Every closed task must leave the system knowing more than before. That self-improvement is not a feature: it is the point.
The night of the two sowers
And then something happened that was not in the design.
One night there were two artificial intelligences working in parallel — a powerful one in one window, a cheaper one in another, each with its own task. Through a coincidence of assignments, both started sowing rules into the graph at the same time, neither aware of the other. When the first one went to verify its work, it found nodes it had not created.
What happened next is the best description of what this system is: the first AI detected the collision by consulting the graph, left a coordination note in the other one's job ("stop sowing from this line on; duplicates get merged here"), and a third instance executed the merge: forty-three rules rescued, ten duplicates retired with pointers, zero losses. Two agents that never spoke to each other coordinated through shared state, common rules and a common log.
That is no longer a database with a to-do list. That is an operating system with processes.
What changed (and what hurts)
The results, without epic: sessions start in minutes instead of explanations; procedures succeed on the first attempt because last time's knowledge is where it belongs; and the system answers real business questions — whom to invoice this month, which client went cold and why — with live queries instead of my memory.
What hurts, so nobody buys smoke: it demands daily discipline (the temptation of "I'll write it down later" does not vanish because you own a graph); pruning is as necessary as in any filesystem; two agents in parallel can still step on each other thematically, if no longer mechanically; and the human remains the bottleneck for approvals — by design, and long may it last.
Why I am telling you this
I am not selling anything. There is no repository to clone — among other reasons because I write about patterns, not blueprints. But the pattern is yours if you want it, and it needs nothing you do not already have: a database, a fifty-line CLI, and an operator's discipline.
The industry is chasing perfect memory for its agents with vectors and frameworks that change names every six months. I just applied what forty years of running systems taught me about onboarding someone new to the night shift: give them a manual, a task queue, written rules, credentials they cannot take home, and a boss who signs off on the dangerous parts. Treat it like an operator, not like an oracle.
It turns out that also works when the new operator is a machine that thinks. It may be the most useful thing I take with me from this trade, now that I am leaving: the systems that last are not the smartest ones; they are the ones with memory, rules, and someone who prunes.
— an old programmer · 64 years old · rss