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 have issues:

• Google Cloud sorts more than 1,300 AI use cases into 6 types, but they're grouped by business function so the same use case lands in several. VERY helpful if you're selling by customer function, less so if you're actually deciding where/how to apply AI.
• OpenAI sorts 600+ use cases into six 'primitives': content creation, research, coding, data analysis. Closer to what I'm after, but those are things a person does in a chat window rather than what the machine underneath is doing.

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

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. 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 chatbot is a fixed assembly: Reader then Maker, that order, every time. 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.

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 same six machines pointed at your context. One key question for each simple machine.

1. Does someone turn what happened into a record of it? Calls into notes, site visits into reports, receipts into the ledger. That's a Scribe, and about as close to a free win as you can get with AI, especially if whoever writes it was checking it anyway.

2. Does someone make the same call over and over, one case at a time? Approve or decline, flag or pass, urgent or routine. That's a Sorter, and the value is the ruleset it operates under and figuring out who's accountable.

3. Is there a pile nobody reads that you suspect has answers in it? Support tickets, exit interviews, incident reports. That's a Reader, the machine most likely to let us down. Buy/build it as one citation per item rather than as an unverifiable answer.

4. Does someone produce drafts to a brief that someone else approves? Copy, code, proposals, designs. That's a Maker, fastest where checking is a quick glance and a redo is free. The approval step IS the safety system, so automate what you like but keep the pause.

5. Does someone rebuild a roster, schedule, route or allocation every week under rules? That's a Solver, the best odds going, because an answer that breaks the rules can't go out the door so being wrong costs almost nothing.

6. Is there a dial someone adjusts constantly, where you never learn what would have happened otherwise? Prices, stock orders, staffing, bids. That's a Controller, so leave it till last, keep every action small and reversible, and judge it across a longer time horizon rather than decision by decision.

My guess is most businesses can say yes to most of these and find an area to implement AI. It's worth funding them in order of how cheap it is to be wrong rather than whatever is hyped.

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

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.