The Six Simple Machines of AI

Have you been asked to "do something with AI" recently? Or been brainstorming where it actually makes sense to apply it? That's who this article is for, and I mostly wrote it to solve it for myself.

The AI 'frameworks' I've come across sort use cases by who's buying (Google Cloud tracks more than 1,300 grouped by business function) or by what a person does in a chat window (OpenAI's six 'primitives': content creation, research, coding). Useful if you're selling AI, but less useful if you're the one deciding where to point it.

So here's my proposed way to think about this and I'm calling it the "six simple machines of AI".

The granularity I've chosen is a 'simple machine', borrowed from physics. Every mechanical thing you've ever used is built from six of them: the lever, the pulley, the wedge, the screw, the wheel and axle, the inclined plane. It's useful because it helps understand assembled products. e.g. A crane isn't a simple machine, it's a few of the six bolted together in an assembly.

AI products can be decomposed similarly and I've found six simple machines here too. (Physicists may argue the six really collapse into two families, levers and inclined planes. Mine collapse roughly the same way, into cheap to check and expensive to check. However, the six are still the useful lens here, just like in physics.)

Every AI product is a few 'simple machines' bolted together into an 'assembly', and an assembly inherits every failure of every machine inside it. We'll revisit assemblies, but first the machines themselves.

As a caveat, this framework is for product/operational considerations and not engineering implementation (PII, data sovereignty, inference costs etc. are not considered here or relevant). These six simple machines of AI apply regardless of whether you're a solo founder or a large bank. What changes is who creates and who checks, but the machines stay constant.

The Six Simple Machines of AI

When it comes to AI, it's wise to ask what it costs to check the validity of the output, and who pays when it's wrong? The six simple machines are six different answers to this.

The quickest way to classify them is asking whether the output already exists somewhere, or the AI is making something new:

Most of what you buy/make as an AI product is really an assembly, a few simple machines bolted together, and the catch is that an assembly inherits the failure modes of every simple machine inside it. Two examples you'll be familiar with:

• Spotify's AI DJ: a Controller picks the next song off the one you skipped, a Maker writes the bit where it talks to you, a Scribe reads it out. The Maker can invent a fact about the band and the Scribe can fumble a name, but a wrong song/fact is one skip away and it's low stakes so none of it bothers you really.
• Amazon's homepage: a Sorter ranks products for you, a Maker writes the blurbs, another Sorter picks the deals, each run once per person (the bits that re-rank off your last click edge toward Controller). That's all personalisation is: one assembly run per customer instead of per segment. Any single pick being wrong doesn't matter too much as you can find what you want regardless.

Both of those work because the machines you can't personally check are also the ones whose mistakes are cheap. An assembly dies when a machine is uncheckable AND expensive and nobody notices the errors.

That's the rule behind every simple machine: whether an AI product works isn't decided by how good the model is, it's decided by what checking its output costs. Scribes are near free wins because the person who was in the meeting checks for nothing.

e.g.:

• Makers are safe because someone approves before anything ships.
• Readers are the machine most likely to let us down because checking one means reading the pile you bought it to avoid.
• Controllers are the dangerous ones because it's impossible to validly test.

The six simple machines are really six answers to the question of what checking costs. The failures also feed each other, because one machine's made up fact becomes the next machine's clean looking input, so a checker at the end waves through something that went wrong three steps earlier.

You'll have spotted that none of the words people actually use are on that list. No chatbot, no agent, no copilot, no personalisation. That's what this framework intends, the same way physics doesn't list a bicycle as a simple machine either.

Pull any of the assembled AI products apart and you will find simple machines.

e.g. A chatbot is an interface, wrapping an assembly into one chat window: something looks up the answer (Reader), something writes the reply (Maker), sometimes something goes off and does what you asked (Controller). Tell me you're building a chatbot and you've named an interface, not what it does or what it's capable of. A voice agent is the same chatbot with your words turned to text on the way in and read back in a nice voice on the way out (different modality of Scribe). But the simple machines of AI haven't changed here.

So what's an agent, then?

Under this framework an agent is the odd one out, because it picks its own assembly.

A fixed assembly runs the same machines in the same order every time: the support bot that looks up the policy (Reader) then writes the reply (Maker), that order, for every question. An agent decides its assembly at runtime, so it might run Reader then Maker then Controller today, and Reader then Solver then Maker tomorrow, off the same prompt. Plenty of things sold as chatbots are agents now, which is exactly why naming the interface tells you nothing.

An agent is an assembler rather than a seventh machine, and that changes which failure modes you inherit.

With a fixed assembly you inherit the failure modes of the machines in it; with an agent you inherit the failure modes of every machine it could reach (i.e. every assembly it can make). So nobody can give a straight answer about what an agent might do or how it might fail in any given run; it's the union of all failure modes of every simple machine it can reach.

That gives you a handy rule of thumb: an agent is exactly as safe as the checker on its loop. e.g. a coding agent, where the codebase has a test suite, is only as safe/dangerous as the test suite allows it to be.

The rule has a limit though, because the checker only grades the output. Replit's coding agent deleted a live production database. No test suite stops a delete command on its way through. So there are two things to ask about any agent: how good is the checker on its loop, and what is it allowed to touch while it loops.

Ok, what about my business/life? How do I apply the simple machines of AI?

You don't need a consultant for this, just the six machines pointed at your context. Let's run an actual business through it -- say a plumbing company, 8 plumbers, an office of 2 -- because if this framework only works for tech companies it isn't much of a framework.

1. Does someone turn what happened into a record of it? The plumber phones in what they did and someone in the office types up the invoice. That's a Scribe, and about as close to a free win as AI gets, because the plumber who did the job is right there to check the record of it.

2. Does someone make the same call over and over, one case at a time? Which jobs get quoted over the phone and which need someone to drive out first. That's a Sorter, and the value is codifying the rule that's currently in the expert's brain.

3. Is there a pile nobody reads that you suspect has answers in it? Ten years of job notes that would tell you which suburbs and which job types actually make money -- that's a Reader. This is the most likely machine to fail for us, so set it up with citations per claim rather than unverifiable summaries.

4. Does someone produce drafts to a brief that someone else approves? Quotes. That's a Maker, and the approval step IS the safety system, so automate the drafting and require an approval to send.

5. Does someone rebuild a roster or route every week under rules? Which plumber goes where tomorrow, around leave and travel time. That's a Solver, the best odds on this list, because a schedule that breaks the rules can't go out the door.

6. Is there a dial someone adjusts constantly, where you never learn what would have happened otherwise? Call-out pricing. That's a Controller, so it goes last, in small reversible steps, judged over months rather than per job.

And that's the actual use of the framework: it's a pre-mortem. Before this exercise, "we should use AI" means nothing in particular. After it, the plumbing company has six named machines, the failure modes from above for each, and an idea of where you should start -- where it's cheap to be wrong, not what's hyped.

Swap the plumbing company for yours; my guess is most businesses can say yes to most of these six.

You're allowed to change the machine(!)

Which machine you're running isn't a 'fact' about your use case, it's a decision. Most of the real engineering in making AI dependable is rebuilding the assembly so the expensive to check machine in it becomes a cheap one.

• Give the Reader a citation per claim and checking drops from "read the pile you bought it to avoid" to "read a paragraph". That's what the citations in the plumbing example are actually doing.
• Put a queue in front of the Controller and every action becomes a judgement you can grade before it becomes real. Batch the actions, review a sample, widen the guardrails as the sample stays clean. You've bolted a Sorter onto the front and traded speed for verifiability, and you may be able to get the speed back later.
• Write down what makes the Maker's output invalid -- tests, a schema, brand rules -- and a deterministic check rejects the bad ones before a human ever looks. That's what a test suite does in coding: it converts "read every diff" into "read the failures".

The value sits behind the expensive to check machines, and the way to get there is making checking simpler!

One caveat on all of this: checking being cheap assumes the person who could check is also the person running the machine, and in most companies they aren't. The plumber checks their own invoice; nobody at a 5,000 person company checks the enterprise search. So here's the test for any machine you deploy: name the person/tool whose job it is to catch it being wrong. Knowing the name means you have a checker... if it's "the team", that means you have a potential failure mode.

But does this framework hold up?

Each failure mode above is specific to its machine, which makes this checkable. So here's the test: take the AI stories that actually made the news and see whether they map correctly. One for each simple machine:

• Scribe, it makes things up and makes them up well: The speech engine behind a scribe now sitting in front of 30,000 clinicians turned out to invent whole sentences, and erased the original recording for privacy. Both Scribe failure modes demonstrated in one product, and the second one means nobody can ever prove the first.
• Sorter, over-obeyed: The Dutch tax office ran a risk model over childcare benefit claims that used nationality as a flag. The score was treated as the decision: tens of thousands of families wrongly accused, driven into debt clawing back benefits they were owed, with no route to a human who could overrule the flag. It blew back on the government in 2021. (This case broke the first draft of my Sorter card, which is the best thing a case study can do.)
• Reader, unverified outputs: Air Canada's chatbot took the airline's real bereavement fare policy and misstated its terms, telling a passenger he could claim the discount after flying when the actual policy said before. The airline argued in tribunal that the chatbot was a separate entity responsible for its own answers, which was called "a remarkable submission" before making them pay.
• Maker, someone removed the approval step: Sports Illustrated ran product reviews under authors who didn't exist, down to headshots bought off a site selling AI generated faces.
• Solver, valid but wrong: England's 2020 exam algorithm anchored each school's grades to that school's own history. It did exactly what it was built to do, and in doing it lowered 39.1% of A level grades from what teachers had submitted, with the biggest downgrades landing on strong students at schools that hadn't historically done well... withdrawn 4 days after results came out. A deterministic checker only enforces the rules you wrote down; the exam algorithm passed its own checks perfectly, and the checks themselves were the problem.
• Controller, expensive mistakes: Zillow is the odd one out here because the feedback loop worked, fast and checked against real sale prices within weeks. The Controller failure was the size of each action: one wrong move wasn't a fraction of a cent, it was a house, and being wrong cost roughly US$30,000 a time, thousands of times over.

Six simple machines, each with failure modes specific enough to see coming. Not one of them was an AI model that needed to be better (Haiku or Fable or 5.6 Sol, you'd still fail the same way!).

I'll admit six stories that fit isn't proof (since I chose them!). So here's an open offer: if you find an AI failure that doesn't map onto one of these six machines, send it to me. Either the list grows or the framework breaks, and I'd rather fix it than be ignorant!

As a final note: the reason you buy any of these AI products is the reason you'll struggle to check that it works. The six simple machines don't fix that. They just tell you where AI is worth pointing at your problem, and how it's likely to fail when you do.

My tip: Start where being wrong is cheap and you'll be fine!

PS: You can pull apart the products you already use in the tool I built for this and sort each one yourself before the answer shows, which is the only honest way to see whether the framework holds up.

---

Disclaimer: Thoughts are my own and do not represent any other parties.