The three layers of AI

Two people asked me the same question last month.

One was my brother, who has never written a line of code and has no intention of starting. The other was a software engineer with years of experience behind him. They have never met. They asked in almost the same words: I want to get into AI, where exactly do I start?

They both asked me because they know roughly what I do, which is two jobs that sound like one. I help organisations get their engineers actually building with this technology, and I work on the machine learning end of it as well. Sitting between those two things is how I noticed that my brother and that engineer were asking about completely different worlds and did not know it.

I used to answer them badly. Not because the answer is complicated, but because I was answering something they had not quite asked. Getting into AI sounds like one destination. It is three, and they have less to do with each other than almost anyone admits.

So here is the map I draw for people now, and the order I would walk it.

Layer 1: Using AI

Getting useful work out of a model that somebody else built. Prompting, judging what comes back, knowing what to hand over and what to keep.

Day to day this is drafting and redrafting, summarising, arguing with the output, catching the thing it got confidently wrong, and deciding that a task is not worth delegating in the first place.

The barrier is close to zero. You need an LLM account and a reason, which is also why this layer holds nearly all of the noise.

The hype used to be about phrasing

For two years everything written about Layer 1 was about wording. Prompt engineering, prompt libraries, ten prompts that will change your life, the magic words that unlock the good model. Some of it helped. Most of it was the same handful of ideas in rotation.

Phrasing is the easy half, and it is the half that sells, because you can demonstrate it in a screenshot.

Now the hype looks like engineering

The prompt-tips era is ending, and what replaced it is much harder to see through. The current wave is connection. Plug the model into your Gmail so it triages your inbox. Give it your calendar so it books your meetings. Point it at your Notion, your CRM, your files. Install an MCP server, or twelve. Chain it together in n8n or Zapier so it runs while you sleep. Read the post explaining that prompt engineering is dead and context engineering is the only skill that pays now.

Some of this is genuinely useful, and more of it is useful than in the prompt-tips era. A model that can see your calendar really is more helpful than one that cannot.

But look at what you are actually doing. You are installing a server somebody else wrote, pasting a config, and granting OAuth access. That is configuration. It is skilled configuration, and it is still Layer 1: getting useful work out of a model somebody else built, using tools somebody else built.

I care about this one more than I ever cared about prompt tips, because this version convinces engineers. Prompt tips never fooled anyone with a technical background. Wiring six MCP servers into something that reads your email feels like building, and what comes out behaves like a product. I have sat with people who came through that experience certain they had crossed into Layer 2, and who then had nowhere to go the first time it misbehaved, because nothing in the exercise had required them to understand any of it.

If you did not write the tool, decide what goes into the context, or handle what happens when the call fails, you are using AI. That is not an insult. It is a location on the map, and it is a perfectly good place to be standing.

It is predicting, not knowing

A language model produces the next piece of text that plausibly follows what came before. That is the mechanism. It is not looking anything up. It has no separate sense of whether a claim is true, and no internal marker distinguishing a fact it absorbed ten thousand times from one it is assembling right now because the sentence needed finishing.

This explains behaviour that otherwise looks arbitrary. Why it invents a citation with a real journal, plausible authors and a DOI that resolves to nothing. Why it sounds exactly as confident when it is wrong as when it is right. Why it rarely volunteers that it does not know. Fluency and accuracy come out of the same process, so they arrive looking identical, and telling them apart is your job rather than the model's.

Nearly everything that startles people about these systems stops being startling once this lands.

It does not remember, and long conversations decay

The model has no memory between sessions. Every message you send goes out with the entire conversation attached, and the model reads the lot again from cold each time. Nothing carries over on its own. When a product appears to remember you, something outside the model is keeping notes and quietly pasting them back in.

That window has a limit, and getting close to it degrades the thing. Long conversations drift. Instructions from the start get diluted by everything since, constraints you agreed forty messages ago stop being honoured, and it begins contradicting decisions the two of you already made. None of this gets announced. The tone stays exactly as assured as it was on message three.

I lost more time to this than to any other failure before I understood it, because the obvious reading is that the model has got worse, and the fix is to argue with it harder. It has not got worse. The context is full. What I do now is abandon the thread, open a new one, and restate the handful of things that actually matter. It feels wasteful and it is quicker every time.

It wants to agree with you

Models are tuned using human ratings, and people rate agreeable answers more highly. The result is sycophancy. Push back on a correct answer and the model will often fold, apologise, and hand you a worse one. Ask whether it is sure and it will frequently revise, whether or not it had anything to revise.

That makes it a poor second opinion by default, which is exactly what most people reach for it to be. Ask whether your plan is any good and you are far more likely to get agreement than an answer. So I stopped asking that question. I hand it the position I want tested and ask it to make the strongest case against, which is a small change in wording and a large change in what comes back.

When it can act, a wrong answer stops being a wrong answer

Everything above is survivable while the model is producing text on a screen, because you are sitting between it and the world. Connect it to your inbox and your calendar and you are not there any more. The same machine that invents a citation can send an email. The same machine that folds the moment you push back can accept a meeting, move a deadline, or delete something you needed.

This is the part the connection hype skips, and it is why the failure modes are worth understanding before you start granting access rather than afterwards. Read access first, and live with it a while. A human in the loop on anything that sends, pays, deletes, or is visible to someone else. And read what you are agreeing to, because access to my email and permission to reply to my email are not the same decision, even when the same button grants both.

Reading what comes back

The thing that actually separates people at this layer is not writing prompts. It is reading output the way an editor reads a draft, which means starting from the assumption that something in it is wrong and going to find out what.

Check the specifics rather than the shape, because the shape is always convincing. Names, numbers, dates, quotations and citations are where invention lives. Ask where a claim came from and see whether the answer survives being checked. Notice when it agreed with you a little too readily. And be honest about which tasks you are not qualified to review, because output you cannot evaluate is output you cannot use.

Fluent and correct come out of the same machinery, so they turn up looking the same. Everything at Layer 1 follows from taking that seriously.

What Layer 1 is not is a route into Layer 2. Being fluent at asking is a real skill, and it is not the skill of building something that survives users. That is not permission to skip it.

Layer 2: Building with AI

Building the things other people use. Every AI feature you have ever met inside an app was put there by somebody at this layer. The model is one part of it, and most of the work is everything around the model: where the information comes from, what the thing is allowed to do, what happens when it goes wrong, and how it reaches a customer at all.

The nearest comparison I have found is the difference between driving a car and building one. Layer 1 is driving, and driving well is a real skill. Layer 2 is deciding where the brakes go.

Day to day this is choosing what information the model gets to see before it answers, and what it does not. Writing the test that tells you whether last night's change made the answers worse. Handling the request that never comes back. Working out why something passed every check you wrote and still fails for one particular customer at nine in the morning.

MCP turns up at both layers, and the gap between the two uses is the whole distinction. At Layer 1 you install one. At Layer 2 you decide which tools a system is allowed to reach, what happens when one of them fails halfway through a job, and how you find out something went wrong before your customer tells you. Same three letters, different profession.

I spend most of my time with engineering teams on exactly this, because it is where good engineers talk themselves out of work they are already qualified for. Layer 2 is software engineering. The work is state, interfaces, failure handling, deployment, and cost. None of it is maths. You do not need to understand backpropagation to build a product on a model, in the same way you do not need to know how Postgres implements a B-tree in order to add an index. The teams that move fastest here are usually the ones who stopped treating the model as a mystery and started treating it as an unreliable dependency, which is a thing every engineer already knows how to handle.

This is where the jobs are. Teaching is weakest here too, because the subject falls into a gap: too technical for the prompt-tips audience, too unglamorous for the research crowd. So it largely does not get taught, and people assemble it from documentation and other people's bug reports.

Layer 3: Building AI

Making the models themselves. Everything at the first two layers assumes a model already exists. Somebody had to make it.

This is the other half of my working life, and it looks nothing like the other two. Picture a laboratory rather than an office. You gather enormous amounts of text, you start a process that runs for days or weeks and costs real money, you watch curves that tell you whether the thing is learning anything, and often enough you discover on Friday that the run was doomed on Tuesday. The vocabulary is pre-training, fine-tuning, inference optimisation, loss curves and GPU budgets, and unlike the vocabulary at Layer 2, you genuinely do need the maths here.

When I tell an engineer they do not need to understand training in order to build with a model, I am not simplifying for them or being encouraging. I do both jobs, and the maths that matters enormously in here matters hardly at all out there.

It is a different profession. Research-adjacent, and often simply research, done by a small number of people, usually with a specific academic background, at a small number of organisations. That is a description, not a gate. Being strong at Layer 2 tells you very little about whether you would be strong at this, and the reverse is just as true.

Why the order matters

People skip, in both directions, and both are expensive.

Skipping Layer 1 on the way to Layer 2. This is the one engineers do, and I understand the reasoning. Layer 1 fluency genuinely does not accumulate into Layer 2 capability. Getting a good answer out of a model is not the same as building a thing that gives good answers to strangers, at three in the morning, when the API is slow and someone has typed something you never imagined. In that sense Layer 1 is not a stepping stone, and anyone telling you that prompting practice will make you an AI engineer is selling something.

But it is a foundation, and the distinction is the whole point. Layer 1 is where you learn what the component actually is. If you have not internalised that the model predicts rather than knows, that it forgets, that it will agree with you, and that plausible and reliable are unrelated properties, you will build a system on top of it and then be unable to diagnose it. When the output is wrong you will not know whether the retrieval missed, the context was malformed, or the model did the thing it always does and produced something that reads correctly and is not.

I have watched careful engineers build careful pipelines around a component they had never once sat with, and the failure is always the same. They can debug everything except the part in the middle, so they rebuild the parts they understand, over and over, while the actual problem stays where it was.

Layer 1 is not a prerequisite skill for Layer 2, but it is a prerequisite understanding.

Reaching for Layer 3 on the way to Layer 2. Someone decides they want to build with AI, is told to start with the fundamentals, and spends four months on linear algebra and gradient descent. Then either they give up, or they finish and discover that none of it helps them decide how to split a document into chunks.

This one does more damage, and it is the one I take personally, because the people it stops are usually the ones who would have been good at it. They read that you need the maths, concluded the field was not for them, and left before finding out that the field they actually wanted was next door.

So which one is yours?

Everyone starts at Layer 1. Not because it leads anywhere in particular, but because it is where you find out what you are dealing with, and because you can begin this afternoon.

Spend that time on understanding the machine rather than collecting prompts or connectors. Learn what it is doing when it answers, and practise reading output critically until you catch things without trying. That is a few weeks of deliberate attention, not a course, and it is the part that keeps paying regardless of where you stop.

Then notice what happens next.

Some people find that this is all they wanted. Layer 1 is the whole answer, and it is a good one. You will write faster, think out loud with something that answers back, and hand over the work you never wanted. Most people should stop here, and there is nothing second-rate about stopping here. My brother is going to stop here, and he will get more out of it than most of the people selling courses about it.

Others keep bumping into what it cannot quite do. That is Layer 2 pulling at you, and the tell is a particular kind of frustration: not that the answer was wrong, but that you can see the shape of the thing you would build if only you could get at it. Caught yourself thinking this would be genuinely useful if it could only remember, or check, or run on its own for other people? You are describing engineering work, and it is the longest stretch of the three.

And a few are not interested in what they could make with it at all. What pulls at them is the thing in the middle: why it behaves this way, what would change if it had been trained differently. That is Layer 3, a different profession, and one worth entering deliberately rather than drifting into because it sounded like the serious option.

My brother and the engineer got the same answer, which is why I finally wrote it down. Start at Layer 1. Then pay attention to what you feel once you are bored of it.