The six simple machines of AI

Every time a friend asks me where to start with AI I give a slightly worse answer than the last time ('a second brain', 'customer service'), so I went looking for a framework that actually helps and struggled to find a useful one.

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 -- the granularity I've chosen is a 'simple machine', borrowed from high school 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. e.g. A crane isn't a simple machine, it's a few of the six bolted together.

AI products can be decomposed similarly and I've found six here too (a coincidence I promise!).

Two ideas coming up. One is the six machines, the other is that nothing you'd actually buy is a single machine -- every AI product is a few of them 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.

Just to caveat this framework, this is about operational reliability, will it do the job and how will you know when it doesn't. Not technical reliability -- PII, uptime, data sovereignty stay your engineers' problem either way. The unit is the job, not the model: a scribe is a speech model plus formatting plus a delete button, and the whole machine is what fails.

The six simple machines of AI

It starts with one question: does the output already exist somewhere, or is the AI 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 under all six cards: 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. 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 there is nothing to check, ever. The six 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, 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.

It's an assembler rather than a seventh machine, and that changes what 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. Not the ones it used this time, all of them. So nobody can give you a straight answer about what an agent might do; 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.

One caveat: everything above about 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. Once the maker and the checker split, every machine gets more dangerous, and the question stops being "can this be checked" and becomes "whose job is it". If the answer is nobody, you've built the risky version of whichever machine it is.

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, hidden misses: The Dutch tax office ran a risk model over childcare benefit claims that used nationality as a flag, wrongly accused tens of thousands of families of fraud, drove many into debt clawing back benefits they were owed, and blew back on the government in 2021.
• 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.
• Controller, expensive mistakes: Zillow is the odd one out here because the feedback loop worked, fast and checked against real sale prices within weeks. Being wrong just cost too much per house.

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 know than be ignorant!

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. 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.