AXIOM: Mission Failed, So I Built the Ultimate Machine
How a dead Mac mini experiment became the operating system Tomedia was missing.
It’s Been a Hot Minute
So, it’s been a hot minute.
Again.
I continue to be spectacularly bad at sticking to my usual attempt at publishing four articles every month. This month, you get two big ones instead.
Sorry, not sorry.
There is a good reason for that, though. I’ve been busy writing and building AXIOM.
I’ve also been working on 4671, but that is going to be a separate article because there is only so much sleep-deprived technical rambling I can reasonably fit into one post. Or, more accurately, only so much I should fit into one post.
This one is about AXIOM.
Or, more specifically, how a failed experiment involving a Mac mini slowly turned into the connective tissue for nearly everything I have spent the past year building.
Mission Failed
Remember AXIOM?
The story technically started with Claude Code, OpenClaw and a Mac mini.
I got a little overexcited, installed everything, connected it all together and managed to get the thing running. For a short and beautiful period, it appeared that I had created a useful little autonomous machine that could sit in the corner and do work for me.
Naturally, I wrote an article praising it.
The next day, it died in a ditch.
It stopped working. It stopped connecting. Nothing talked to anything properly. I spent an entirely reasonable amount of time cursing it, switched off the Mac mini and put it in a cupboard.
That is where it stayed for quite a while.
Mission failed.
Or so I thought.
My general worldview when it comes to technology is that if something is broken, badly designed or irritating enough, the obvious response is to build something better myself.
This is not necessarily a healthy worldview. It is, however, responsible for quite a lot of Tomedia.
So I eventually brought the Mac mini back out, mentally dusted off the AXIOM idea and started thinking about a problem I had needed to solve for a very long time.
The problem was not really OpenClaw.
The problem was me.
More specifically, the fact that I had somehow turned myself into the connective tissue between every system I had built.
Tomedia Had Plenty of Organs but No Nervous System
Tomedia is currently split into a growing collection of separate systems.
There is Scribe. There is Mule. There is Seer for large-scale research. There is Overwatch for proof, monitoring and reporting. There is Discover. There are internal CRM, creative and operational systems. There are website tools, deployment processes, client systems and a steadily expanding collection of models that do genuinely useful things.
They all exist.
Some of them are very good.
Some of them contain mathematical and strategic models that I have spent months building, testing and refining. They can implement repeatable strategies consistently, and I can see the impact of those strategies in client work.
The problem is that I am probably using most of them at about ten per cent of their full potential.
They have no connective tissue.
Each system understands its own part of the world, but there is no shared layer that understands why a piece of work exists, where its information came from, which client it relates to, what decision approved it, who or what is meant to carry it out, and whether the result actually worked.
That makes the whole business more convoluted to operate than it needs to be.
It also makes me quite sad, frankly. I have worked hard to build these systems, but the final step between “this is an impressive tool” and “this meaningfully changes how the company operates” has remained stubbornly manual.
At the same time, software engineering work has expanded into entire 30-hour weeks of big-data pipelines, integrated website systems and infrastructure work for one of my main clients.
That work is interesting and valuable, but it has stretched me thin.
Then there is Discover.
Discover gets new users every week, which should be exciting. The last count I saw was somewhere around 300 users, which is honestly not bad for something that only properly started around seven months ago and has changed substantially since then.
Unfortunately, I am not happy with it.
It is a buggy mess.
It does have an inbuilt error-finding system that tells me exactly what is going wrong on a daily basis, which is useful. The less useful part is that somebody still needs to fix those errors.
That somebody is me.
Assuming I have the time.
Free users also do not magically become paying users, especially when the platform they are being asked to pay for behaves like a bin fire with a login screen.
On top of that, there is Risen. CutCompass still needs to be finalised properly. Veritas needs cleaning up. Ephemera has only just reached the point where The Big Book of SEO is finished and available for sale.
There are client systems to maintain, internal products to finish, ideas to validate, reports to review, deployments to manage and bugs to fix.
I have been very busy.
Time has become the enemy of nearly every good thing I have built over the past six months to a year.
Which led me to a fairly obvious question.
What if there were a way to get some of that time back?
What if the menial coordination work could happen automatically, without handing complete control of the company to a chatbot with an API key and an unjustified amount of confidence?
That is where AXIOM comes in.
And, oh my, it is beautiful.
The First Control Plane
AXIOM did not originally begin as AXIOM.
The first practical version was called the AI Control Plane, which is functional but not exactly the sort of name that inspires mythology.
It lived inside Tomedia, and it had one job: use Codex to automate fixes for TomediaMain, the repository containing the main website.
TomediaMain already produced logs for every issue it found. Those errors were sent directly to me and saved into a bug-fix collection, ready for somebody to investigate.
The reporting part worked.
The fixing part still required manual effort.
I had to inspect the error, understand the relevant part of the codebase, create the task, implement the fix, test it, prepare the change and deploy it.
The Control Plane was designed to close that gap.
It would take a recorded error, turn it into a properly structured GitHub issue and move the proposed fix through a staged software-delivery process.
While building it, I finally accepted that it was probably time to set up proper GitHub Actions and deployment workers.
Until then, I had been doing a rather embarrassing amount of deployment work manually.
This did occasionally break things.
Whoops.
The new process added GitHub Actions, connected Codex through GitHub, generated fixes for me to review and returned them through pull requests.
And it worked.
It worked remarkably well.
The system could discover an issue, create the corresponding work and prepare a fix, sometimes within the first hour of the problem appearing.
Instead of an error sitting in a collection until I found time to deal with it, the first pass could already be waiting for review.
Bob’s your auntie Pat: the bug was identified, investigated and potentially fixed before it had time to become part of the furniture.
For Discover, that was ideal.
The product desperately needed a cleanup phase, and this gave me a credible way to perform one without sacrificing every other thing I was meant to be doing.
Perhaps, eventually, Discover could even earn some money.
It turns out people are more likely to pay for a platform when it is usable. Who knew?
Then I Made It Bigger
Naturally, I was not satisfied.
Fixing bugs automatically was useful, but I still had far too much to manage.
I wanted dedicated automation branches. I wanted release trees and separate pipelines for different areas of the platform. I wanted reports sent to me in a format I could approve while away from my desk. I wanted the whole process to be more visible, interactive and controllable.
So I introduced Slack.
Then I introduced more workers.
Then more routing.
Then more reporting.
Then all the other fun things that turn a small automation script into an infrastructure project.
I also did not want every piece of internal work to require paid access to Codex, OpenAI or whichever model happened to be fashionable that week.
So I built a model machine.
A couple of years ago, I built a fairly powerful computer. AXIOM gave it a new purpose: running local models, benchmarking them and allowing several models to compete or collaborate on internal reporting and analysis.
The machine is connected through Cloudflare Zero Trust, which means I can access it securely from elsewhere without opening the entire thing to the internet and hoping for the best.
More importantly, the worker framework is designed so that the machine itself is not special.
I can bring the Mac mini back out of its cupboard, connect it and assign it a different set of workers. I can add another Mac mini later. I can attach a Linux GPU machine. I can temporarily route approved work to a cloud model.
Each machine contributes capacity.
The framework decides what kind of work that machine is suitable for.
This first version reached the point where it was roughly 80 per cent complete. Complete enough that the core approach worked, but not fully switched on across everything.
Then I made the dangerous mistake of thinking:
What else could I do with this?
Introducing AXIOM v2
This is AXIOM v2.
Or possibly v3, depending on whether we count the original OpenClaw monstrosity.
AXIOM is my new magnum opus. It is designed to take control of the time I cannot manage manually, without taking control away from me.
It is a second brain without fully surrendering the first one.
It is a way to implement more rigorous, repeatable and evidence-driven work. More importantly, it is finally a way to connect nearly all of Tomedia’s existing optimisation systems into one coherent package.
The ultimate machine.
So, What Actually Is AXIOM v2?
The easiest mistake would be to describe AXIOM as another AI assistant with a lot of integrations attached to it.
It isn’t.
An assistant usually sits inside a chat window and waits for somebody to ask it a question. It receives a prompt, produces an answer and then forgets most of the operational reality surrounding that answer.
AXIOM is closer to an operating system for a small digital company.
Or, more accurately, it is an artificial ecology made up of specialised workers, departments, models, machines, memories and approval systems, all operating beneath one protected controller.
It is the connective tissue Tomedia has been missing.
Instead of Scribe, Mule, Overwatch, Seer, Discover, SiteOps, CRM, Creative and everything else existing as separate islands, AXIOM sits above them.
It connects the reason work exists, the research behind it, the person or machine performing it, the approval that permitted it, the result it produced and the evidence showing whether that result actually worked.
The current AXIOM core already handles jobs, workers, model routing, costs, risks, approvals, Slack requests, GitHub issues and software delivery.
V2 broadens that control plane into a system that can research, plan, delegate, compare different approaches, retain evidence, measure results and gradually improve the way work is performed.
The distinction between what exists and what is planned matters.
I am not claiming every named component below is secretly alive, fully autonomous and running the company while I sip something expensive on a beach.
Some parts are working now. Some are being connected. Others are mapped as later capability branches.
The spine, however, exists.
That is the important bit.
The Artificial Ecology
The ecology comparison is not just me being dramatic.
Although I am, obviously, also being dramatic.
AXIOM itself acts as the protected germline. It owns the rules, goals, budgets, permissions and ability to create workers.
The workers are temporary cells.
Each worker has a manifest that functions a little like DNA. The manifest defines which model the worker uses, which tools it can access, what data it is permitted to see, how much compute it can consume, how long it is allowed to remain active and under which conditions it must stop.
Tests, evidence and real outcomes create the selection pressure.
Useful workers and workflows can be retained and reused. Unreliable ones can be modified or retired. Time limits, permission revocation and rollback function as a form of programmed cell death.
It is reproduction, without worrying about it coming back to bite me.
A worker cannot decide to copy itself onto another machine. It cannot expand its own permissions, remove its expiry time or suddenly decide that it should have access to a client advertising account.
Only AXIOM can create another worker.
Every child worker inherits a narrower set of permissions than the controller or parent process that created it.
This is one of the fundamental rules of the system.
More machines increase capacity.
They do not increase authority.
That means I can connect the Windows model machine, wake the Mac mini back up, add another Mac mini later, attach a Linux GPU box or temporarily use an approved cloud model.
Each machine registers what it can actually do. It reports which models are available, what hardware it has, how heavily loaded it is, what privacy levels it supports and which classes of work it is allowed to receive.
AXIOM can then place each job on the most appropriate machine.
The Mac mini is no longer pretending to be the brain.
It is one organ in a larger system.
There Is No Main AI Model
There is no single “main AI model” sitting at the centre of AXIOM.
That is deliberate.
Different models are good at different things. Some are quick and efficient. Some are better at careful reasoning. Some write stronger code. Some extract structured information more reliably. Some are useful precisely because they disagree with the others.
AXIOM is designed to take advantage of that diversity rather than pretending one model should be trusted with everything.
For difficult jobs, it can run tournaments.
One worker might focus on finding information quickly. Another might perform deeper reasoning. A third might attack the underlying assumptions. Another might verify every factual claim. Another might inspect the technical feasibility. Another might write the code.
The workers operate independently enough that one answer does not simply contaminate all the others.
Their outputs can then be compared.
Weak claims are challenged. Contradictions are surfaced. Unsupported conclusions are rejected or sent back for more evidence. The final result is checked again rather than accepted because one model sounded especially confident.
The objective is not to create artificial consensus.
It is to create useful disagreement and then resolve it with evidence.
A hundred copies of the same model making the same mistake is not intelligence.
The useful part comes from genuine diversity, independent evaluation and a reliable way to determine which answer survives.
This is where the named AXIOM departments begin to appear, because apparently one acronym was not enough and I decided the system needed an entire mythology.
THEORIA: Research Before Action
THEORIA is the research and development branch.
Before a major Tomedia feature, client strategy or operational change becomes active work, THEORIA creates a proper research dossier.
The dossier describes what currently exists, what problem is actually being solved, what evidence supports that problem, which assumptions are being made, what alternatives are available and how we would know whether the chosen direction worked.
That last part is particularly important.
A surprising amount of work begins with a solution somebody finds exciting, followed by a frantic attempt to invent the problem it supposedly solves.
THEORIA is intended to reverse that process.
It is not allowed to approve its own conclusions.
It produces the research for me to read, question, challenge, narrow, reject or approve as a specific direction.
Under THEORIA are several more specialised roles.
ARGUS is the evidence scout. It gathers internal information, client data, market research, technical sources and other relevant evidence. It records where information came from, when it was captured, how fresh it is and whether different sources contradict one another.
DAEDALUS is the systems architect. It maps the infrastructure that already exists before proposing another shiny new subsystem.
This is especially important for Tomedia because I am extremely capable of building a new tool before remembering that I created 70 per cent of it somewhere else six months earlier.
SOCRATES is the deliberately annoying one.
Its job is to challenge the idea, identify the strongest argument against it, expose unsupported claims and ask what evidence would prove the preferred direction wrong.
For example, imagine I want to add a major new feature to Discover.
ARGUS can investigate user behaviour, error patterns, feedback and market evidence. DAEDALUS can inspect whether the necessary capability already exists elsewhere in Tomedia. SOCRATES can ask whether the proposed feature solves the real problem or merely creates another subsystem for me to maintain.
THEORIA then assembles those perspectives into one versioned document.
I can comment on individual sections, request more evidence, ask for another option or approve one exact revision.
That revision is frozen.
AXIOM cannot quietly rewrite the document later and pretend the new version was what I approved all along.
Approving a direction also does not approve every action that might follow from it.
A research approval does not automatically grant permission to publish something, spend advertising money, merge code, deploy to production, send a document to a client or mutate an external provider.
A strategic decision and an operational permission are not the same thing.
That boundary is essential.
HERMES: Turning Decisions Into Work
Once a direction has been approved, HERMES handles the handoff.
HERMES is the coordination layer between a decision and the systems that must act on it.
It converts an approved direction into properly scoped work for the correct Tomedia departments.
The handoff includes the client, objective, source evidence, approved revision, expected result, constraints and acceptance criteria.
The next worker is not given a vague prompt with half the context missing.
This solves one of the most persistent problems in both human and machine workflows: context evaporating between stages.
A research system understands why something matters. A project-management tool sees only a task title. A developer receives a ticket. A reporting system later sees a release. Somewhere between those points, the original reason for doing the work disappears.
HERMES carries that reason through the chain.
Every downstream job can be traced back to the approved evidence and decision that created it.
FORGE: From Recommendation to Software
Software work is sent to FORGE.
FORGE is the engineering collective.
It turns approved recommendations into GitHub issues, isolated branches, code changes, tests, draft pull requests and release evidence.
FORGE can build a change.
It can inspect the codebase, generate an implementation, run tests and prepare the proposed work for review.
What it cannot do is quietly alter the approved direction, review itself, merge itself or deploy itself to production.
Those are separate powers.
This separation is not there because I assume every model is secretly plotting a takeover.
It is there because the same process should not be responsible for proposing a change, implementing it, declaring it correct and releasing it into the real world.
Humans are bad enough at marking their own homework. Machines do not need the same opportunity.
FORGE can say, “Here is the implementation, here are the tests, here is the evidence and here are the remaining risks.”
Another system--or I--decides what happens next.
AXIOM Does Not Replace the Existing Tomedia Systems
Client work continues through the existing Tomedia departments.
Scribe remains responsible for content and search work.
Mule remains responsible for advertising strategy and reversible campaign changes.
Seer continues to support large-scale research and analytical work.
Overwatch remains the proof, health and reporting layer.
SiteOps and GitHub retain control over website and software delivery.
CRM, Creative and the other systems retain their own responsibilities, restrictions and action gates.
AXIOM coordinates them.
It does not replace everything with one enormous ai machine god.
The goal is not to throw that work away and ask one general model to improvise the company from scratch every morning.
The goal is to connect those systems so they can operate as parts of the same machine.
Memory Must Be More Than a Chat History
Behind all of this is the memory layer.
MySQL holds the current operational truth.
It records which jobs exist, what state they are in, who approved them, which worker has claimed them, which permissions apply and what is allowed to happen next.
It is the live state of the machine.
ClickHouse becomes the empirical memory.
It stores what evidence was used, which worker or model performed the task, how much the work cost, how long it took, which tests passed, what humans accepted or rejected, whether something was rolled back and what happened to the actual business result later.
The difference between those two forms of memory is incredibly important.
The system of record cannot just be a long conversation transcript.
AXIOM needs to know both what is true now and what happened historically.
Most AI systems effectively learn that “task completed” means success.
AXIOM is designed around the idea that completion and quality are not the same thing.
A beautifully written report can still be wrong.
A code change can pass one test and break something else.
A campaign recommendation can sound clever and lose money.
A page can increase clicks while making the website worse for everybody who arrives there.
A worker can technically complete every requested step and still produce something useless.
AXIOM’s long-term fitness measurements are therefore based on evidence, tests, human judgement, incidents, rollbacks and delayed outcomes.
Not merely whether a worker successfully produced some text.
This also allows the system to learn which models and workflows are actually useful for particular kinds of work.
The cheapest model is not always the most economical model if its output creates four hours of human rework.
The most sophisticated model is not always the best choice for a simple extraction task.
The fastest worker is not necessarily the most valuable if everything it produces needs to be checked twice.
The outcome data gives AXIOM a way to make those distinctions empirically.
Controlled Self-Improvement
The memory layer also creates a controlled path towards self-improvement.
Eventually, AXIOM will be able to propose changes to its prompts, workflows, routing rules, tools, worker manifests and selected pieces of worker code.
The important word is propose.
Those changes follow the same boring, beautiful software process as everything else.
Research.
An isolated branch.
Tests.
Independent evaluation.
A pull request.
Staging.
A limited canary release.
Then either promotion or rollback.
AXIOM can identify that a routing rule is performing badly. It can produce evidence showing that another model or workflow performs better. It can prepare the change and submit it for review.
It cannot approve its own evolution.
That gives the system room to improve without creating an environment where it can silently rewrite the rules governing its own behaviour.
Improvement is allowed.
Unsupervised authority expansion is not.
Seeing the Whole Machine
All of this needs to become visible through a new management layer.
The Founder Command Centre provides the “what needs me right now?” view across clients, approvals, incidents, costs, capacity, research and releases.
I do not need another dashboard showing me fifty green numbers.
I need to know where a decision is blocked, where something has gone wrong, where money is being wasted and which action genuinely requires human judgement.
Client Mission Control shows what has been promised to a client, what is being worked on, why that work exists, which research supports it, what is blocked, what has been delivered and whether it achieved anything.
The R&D Portfolio contains every active idea and dossier, the evidence behind it, the questions that remain unanswered and the exact decision being requested.
The Work Graph shows dependencies between research, jobs, departments, people and outcomes.
Instead of giving me twelve separate queues and expecting me to reconstruct the story in my head, it shows how the work fits together.
The Quality and Outcome Lab contains tournaments, tests, human reviews, rejected outputs, incidents, rollbacks and real-world results.
That is where AXIOM can prove whether it is becoming more useful rather than merely becoming busier.
The Worker Fleet and Model Registry shows every connected machine, available model, declared capability, benchmark, active queue, failure and piece of spare capacity.
Adding another Mac mini should eventually be as simple as enrolling it, benchmarking it and allowing AXIOM to assign appropriate work.
It should not require rewriting the routing system every time I find another computer in a cupboard.
The Other Organs
There are several other planned organs within the wider AXIOM ecology.
MNEMOSYNE is the semantic memory layer. It connects clients, companies, people, campaigns, code, claims, decisions and outcomes over time.
It allows AXIOM to understand that a client mentioned in a meeting, a campaign referenced in a report, a company stored in the CRM and a repository containing the client’s website all belong to the same wider context.
DIPLOMAT is the integration gateway. It provides one governed way to connect new tools, data sources and external systems without giving every worker unrestricted access to everything.
LANTERN handles observability. It allows a piece of work to be traced from its original goal through every worker, model, tool call, approval and result.
CUSTODIAN manages privacy, retention, consent and data boundaries.
ORACLE is the experimentation and causal-analysis branch. Its job is to help separate “this happened at the same time” from “this probably caused the result”.
SIMULACRUM is the scenario and digital-twin laboratory. It allows AXIOM to rehearse capacity, campaign, pricing and operational decisions before changing the real world.
LEDGER connects machine cost, model spend, human time, client value and available capacity.
Saving three pence on a model is not especially useful if the cheaper output creates four hours of rework.
Then there are assurance and commercial branches.
AEGIS focuses on security and resilience.
JUSTITIA handles obligations and compliance.
PROSPECTOR researches commercial opportunities.
STEWARD focuses on client success, value delivery and retention.
Not every one of these is fully alive yet.
Some already exist within the current infrastructure. Some are being wired together. Some remain mapped as later capability branches.
But the spine now exists.
That is the important bit.
A Second Brain Without Giving Up the First
AXIOM is not meant to replace my brain.
It is meant to stop my brain being used as the database, router, project manager, deployment checklist, error queue and connective tissue between every system I have built.
I do not want an autonomous machine making unreviewed decisions for clients, spending money because it feels optimistic or deploying changes because one model told another model that everything looked fine.
I want a system that gathers the evidence, preserves the context, coordinates the work, tests the output and presents the right decision to me at the right moment.
It gives me a second brain without requiring me to hand the first one over.
Instead of spending my time chasing broken deployments, copying context between tools, checking whether something was approved, manually reconstructing client work or noticing the same bug for the fifth time, I should be spending it on decisions, strategy, clients, ideas and the strange new things I apparently cannot stop building.
For the first time, all of Tomedia’s separate systems are starting to look like parts of the same machine.
Not a collection of disconnected tools.
Not a folder full of clever experiments.
A machine.
Now I just need to finish it before I get distracted by 4671.
Which, unfortunately for my sleep schedule, is going to be its own article.