The Four Layers of LLM Engineering
A friendly, visual field guide to prompt engineering, context engineering, harness engineering, and loop engineering — for technical and non-technical readers alike.
A field guide for humans working with AI
Why "write a better prompt" stopped being the whole answer — and the four crafts that replaced it.
- Prompt — what you say
- Context — what it sees
- Harness — what it can do
- Loop — how it improves
Readable by non-engineers · code is optional everywhere · all numbers are illustrative examples, not benchmarks
The World's Strangest New Hire
Imagine you've just hired the most impressive employee you've ever met. They've read practically everything, they work at superhuman speed, and they never get tired or bored.
There's a catch. Four, actually. Your new hire knows nothing about your company — your products, your policies, your customers. They have no memory between shifts: every conversation starts from a blank slate. They take instructions very literally, filling any gap you leave with a confident guess. And they will never say "I'm not sure" unless you make that an acceptable answer.
That is, more or less, what a large language model is. And getting consistently great work out of this employee is not one skill — it's four, layered on top of each other:
In plain English: The brief you write for them is prompt engineering. What's on their desk when they do the work is context engineering. The office around them — which keys they hold, which tools they're handed, what needs a manager's sign-off — is harness engineering. And how their work gets checked, corrected, and improved over time is loop engineering.
Each layer answers one question, and each contains the ones before it. A prompt lives inside a context window; the window is assembled and used inside a harness; the harness runs step after step inside a loop. When something goes wrong, the fastest fix is at the layer that owns the failure — and the most common mistake in the field is rewriting the brief for a problem that actually lives two layers down.
FIGURE 1 — The stack — each layer contains the ones above it. How to read it: start at the top. If your problem survives a perfect brief, look one layer down. The colors used here — indigo, teal, green, amber — mean the same four things in every figure in this guide.
The Four Layers at a Glance
| Layer | Key Question | Unit of Work | You Build… | It Fixes… | It's the Bottleneck When… |
|---|---|---|---|---|---|
| Prompt | What do I say? | The message | Briefs, examples, output formats | Wrong format, wrong task, guessing | Failures happen even in one clean request |
| Context | What does the model see? | The token budget | Retrieval, memory, summaries, budgets | Long-chat decay, missed facts, runaway cost | Failures appear with length or scale |
| Harness | What can the model do? | The runtime system | Tools, permissions, sandboxes, logs | Wrong tool, dead-end errors, unsafe actions | Failures happen at the moment of action |
| Loop | How does it iterate & improve? | The trajectory | Verifiers, budgets, retries, test suites | Endless runs, premature "done", repeat bugs | Failures happen across steps and weeks |
Meet SupportPilot — The Running Story
Theory sticks better with a story, so this guide follows one system the whole way through.
Northwind is an online kitchenware shop. Its support team is drowning, so the company builds SupportPilot — an AI assistant meant to read customer tickets and resolve them: track orders, answer product questions, approve small refunds, and know when to hand things to a human.
One customer will keep us company throughout: Dana, whose new espresso machine leaks from the top, who has already returned two of them, and who — reasonably — has opinions about talking to bots. Version 0 of SupportPilot is three sentences of good intentions bolted to a model. Each chapter upgrades exactly one layer, and each upgrade fixes a different way v0 lets Dana down.
FIGURE 2 — The journey — one system, four upgrades. Spoiler, on purpose. Knowing where the story ends makes each chapter easier to place. The percentages are invented to show the shape of the improvement — your numbers will differ; the shape usually won't.
How is this guide?
Last updated on
Netspective Unified Process for Probabilistic Software (AI-Native Systems)
A comprehensive framework for building, governing, and operating AI-native systems. Combines AI-native engineering practices with quality governance for trustworthy AI/ML applications.
Layer 1 · Prompt Engineering
Writing the brief — framing the task, setting role boundaries, shaping the output contract, and eliminating ambiguities.