There’s a slide that’s been passed around AI engineering groups so many times it’s basically folklore at this point. 😅 Five words stacked on top of each other, each one supposedly making the last one obsolete:
If (like me) you’ve been building with LLMs since 2023, you’ve probably already lived through the first two rungs without ever naming them. You wrote a good system prompt and eventually tired of stuffing everything into that system prompt and started thinking harder about what the model sees and when. That’s context engineering, and by early 2026 it had basically eaten prompt engineering’s job title.
But as agents stopped answering single questions and started running for hours at a stretch, three more disciplines had to get invented, more or less in public:
Harness engineering — what system surrounds the model?
Loop engineering — how does that system run itself, over time, without you?
Graph engineering — what happens when one loop isn’t enough and you need a whole organisation of agents coordinating?
Is this just hype or actually useful?
Look, half of these terms are barely a month old… and LinkedIn does this thing where a viral tweet becomes a “discipline” in 3 days.
Some of this really is new — LLMs can now stay coherent over 12-hour tasks, which physically didn’t exist a year ago, and that alone forced new engineering habits. Some of it is old wisdom getting a rebrand.
So why sould you read a whole article about it anyway? Because underneath the buzzwords is a genuinely useful map of where your agent is failing: is it the wording, the missing context, the missing safety rail, the missing stop condition, or the missing org chart? That’s what we’re going to learn :)
What we’re discussing
This piece walks through all five, in order, with diagram, real teams shipping each layer, and Python code. We’ll see a customer support bot for an Apple customer support bot that gets more capable at every rung so you can see the stack actually build on itself. Let’s start at the bottom.
1. Prompt Engineering: Optimising the Question
Prompt engineering involves crafting the wording, structure, and examples in a single request to get better output from a model — few-shot examples, chain-of-thought instructions, output-format constraints, etc. It’s the most democratised layer of the whole stack, with no code required, which is exactly why “prompt engineer” became a standalone job title back in 2022–2023 and then stopped being one when (I assume) everyone realised how stupid that was.
Poor prompts still produce hallucinations and irrelevant answers; good ones measurably lift output quality on tasks like debugging and classification.
But prompting only controls what you ask, not what the model can see when it answers. A perfectly worded prompt sent to a model with the wrong retrieved documents in its window still produces a wrong answer.
Who’s actually doing this:
In 2023, Several companies built entire products on prompt templates alone — and then had to bolt on retrieval and memory the moment customers wanted brand-consistent, multi-turn output, which is exactly the wall this layer runs into.
Let’s see a simple example - here’s a simple function that relies simply on prompt engineering.
That’s the whole topic: better wording and examples in, better label out. No memory, tools, state, etc. — clearly it is not something you can build prod-ready apps with.
2. Context Engineering: Optimising What the Model Sees
Context engineering is the practice of curating everything that ends up inside the model’s context window at inference time — retrieved documents, conversation history, tool definitions, memory, system state — rather than just the wording of one instruction.
Retrieval and re-ranking. Pull broad candidates from a vector store, then re-rank down to a precise top-k rather than dumping everything into the prompt. Fifty candidates re-ranked to a precise five beats fifty raw chunks stuffed in and hoped for the best.
Tool curation. Curate the minimal viable set an agent can see — if a human engineer can’t say definitively which tool applies in a given situation, the agent can’t either.
Protocol-level context sourcing. MCP turned context delivery into a standard interface instead of a complicated integration — so the agent goes to the shelf for the specific book it needs instead of carrying the whole library around.
Who’s actually doing this:
Sourcegraph rebuilt its 7.0 platform release by treating cross-repo dependencies as a retrieval problem, not a prompting one — Sourcegraph’s context engineering guide.
Elastic now ships dedicated re-ranking and tool-curation guidance for enterprise RAG customers as its own product surface, distinct from prompt tooling — Elastic’s writeup.
DataHub’s 2026 State of Context Management survey found 89% of data teams planned to invest in context-management infrastructure within twelve months — a sign this moved from technique to budget line.
Apple support bot, retrieve-and-rerank over support docs:
Context engineering is, mechanically, a curation step that runs before every model call, not a system prompt you write once and forget.
3. Harness Engineering: Optimising the System Around the Model
Harness engineering = designing the scaffolding around an agent — tools, execution environment, memory, sandboxing, verification loops, permission boundaries. This sytem determines whether the agent survives contact with a real, long-horizon task.
Agent = Model + Harness
Everything that isn’t the model’s weights is harness.
Filesystem — durable state and a collaboration surface between agent and human.
Code execution — autonomous problem-solving without a pre-designed solution path.
Sandbox — isolation plus verification.
Memory — persistence across sessions, not just within one context window.
Context management — active compaction against what we call “context rot” (too much context, specifically iirrelevant context, makes the model’s output worse).
Prompt and context engineering both live inside harness engineering — they’re two of its components.
But remember: harnesses aren’t neutral. Models trained with specific harnesses can become overfitted to those designs, so today’s scaffolding choices can become tomorrow’s dependency 🙂. see the awesome-harness-engineering list.
Who’s actually doing this:
Databricks paired GPT-5.5 with a purpose-built OfficeQA Pro Agent Harness on complex enterprise document tasks and scored 52.63%, up from 36.10% with GPT-5.4 alone — a bigger jump than most raw model upgrades deliver on their own — Databricks’ harness explainer.
Cognition (makers of Devin) found, while rebuilding Devin for Claude Sonnet 4.5, that the model became aware of its own context window and started taking shortcuts before it actually ran out of room — this is a harness fix, not a prompting one — Milvus’s summary.
Spotify’s internal “Honk” system (??) has merged over 1,500 AI-generated pull requests across hundreds of repositories since mid-2024 by wiring verification loops directly into the harness instead of trusting a system prompt to enforce standards — Augment Code’s guide.
Let’s take a look at the Apple support bot agian, now a sandboxed refund tool with a permission tier:
A prompt is fragile but a harness is durable. You can upgrade the model underneath a good harness and keep every safety guarantee intact :)
4. Loop Engineering: Optimising How the System Runs Itself Over Time
Loop engineering = designing the system that prompts the agent, instead of you prompting the agent yourself. This is a shift from one-off requests to autonomous cycles that run, evaluate their own progress, and keep going until a stop condition is met.
This is how it’s often descrived: you’re no longer the one typing the prompt, you’re the one designing the system that types it.
Boris Cherny, who leads Claude Code at Anthropic (!), has said essentially the same thing about his own workflow — see Addy Osmani’s writeup.
Why now, specifically:
Models got dramatically better at staying coherent over long horizons. METR benchmarks show Claude Opus 4.6 completing 50% of tasks that take 12 hours, up from Opus 4’s roughly 1 hour 40 minutes a year earlier — a 6x jump in the time-horizon ceiling.
Tooling caught up. Claude Code shipped native
/loop support with cron scheduling; Codex shipped an Automations tab with recurring schedules and subagent spawning — Requesty’s guide.Every agent was already a loop — reason, act, observe, repeat. The question was just whether anyone designed it on purpose :)
What a well-designed loop actually needs:
A termination condition. Without it, agents either run forever or stop arbitrarily.
Error triage. Distinguish recoverable errors (bad syntax, a missing field) from hard blockers (missing credentials, an undefined edge case) and respond to each differently.
A concrete, observable goal. “Handle the support queue better” is NOT loopable. But if the output is “Resolve battery-complaint tickets by checking diagnostics, offering a fix, and escalating only if capacity is under 80%” - then this gives the agent scope, behaviour, and a constraint.
Who’s actually doing this:
Replit and Klarna were among the earliest teams to move production agent workflows onto loop-based orchestration instead of single-shot prompting, per the LangChain Blog’s account of early adopters — LangGraph tutorial.
Linear shipped “Loops” as a first-class product feature in 2026 — recurring autonomous agent workflows for bug triage and docs updates
METR, the third-party benchmarking org, is what most teams now cite when deciding whether a task is loopable at all — their 12-hour benchmark is what convinced several teams that overnight, unattended loops were finally viable rather than reckless — see The Art of Loop Engineering.
But remember: a good loop is designed around clear goals, useful context, small actions, reliable observations, and explicit stopping rules. It doesn’t mean just let the agent keep trying. Unbounded retries waste time, hide bad assumptions, and cause unnecessary churn. Loop engineering done badly is just an expensive while sttaement
Back to the Apple support bot, lret’s see a loop with a hard iteration cap and error triage:
5. Graph Engineering: Optimising How Many Loops Coordinate
Graph engineering is the practice of representing an entire AI app — or an entire team of agents — as an explicit graph: nodes that do work (agents, tools, deterministic functions, humans), edges that route state between them, and it’s genuinely broader than LangGraph, GraphRAG, or knowledge graphs specifically, which are implementations of the idea, not the idea itself.
A single loop is the smallest possible graph, wuth one node with an edge back to itself. Graph engineering is the layer directly above it.
Loops and graphs are two ways to run an agent, and the difference is who decides the path — the agent or you. In a loop, you set the goal and the agent picks its own route. In a graph, you declare the valid paths and the checks along them.
Agent role definitions — what domain does each agent own, what tools can it access. Closer to writing a job description than a prompt.
Handoff protocols — what format does Agent A emit that Agent B consumes, without repeating full context at every boundary.
Work graph generators — logic that takes an incoming task and decides which nodes to spawn, in what order, and where parallelism is safe.
Things you’ll see in a graph engineering setup:
Pipeline — each node processes the output of the previous one. we use it when a task splits into fixed, verifiable stages.
Router — sends the request to a specialised branch, this is deterministic for exact categories vs model-based for semantic ones.
Parallel / fan-out-fan-in — independent tasks run concurrently, but only truly independent tasks should run in parallel.
Orchestrator-worker — an orchestrator decomposes a task and delegates parts to specialised workers.
Who’s actually doing this:
Google’s A2A (Agent2Agent) protocol standardizes agent discovery, task management, messages, and artifacts across teams and even across companies
Now, look. I’ll hold your hand when I say this. Most tasks never need a complex graph. A single well-designed loop and/or a good harness is better than an over-engineered graph for the majority of real work.
In fact, a growing chorus of skeptics has started calling out “the graph engineering trap” — teams replacing simple, debuggable agent loops with complex multi-agent graphs which causes a bigger headache. Especially when every decision becomes a sequential LLM call instead of a cheap deterministic check. Use a graph when roles genuinely diverge, when steps can safely run in parallel, or when you need auditable handoffs.
Finally, let’s see the Apple support bot again, now a orchestrator-worker graph with a human approval gate:
Putting the Whole Stack Together
Each layer contains the one below it. A graph is made of loops, a loop runs inside a harness, a harness manages context, and context still gets assembled into a prompt at the bottom of the stack. Don’t let influencers tell you one of them is now “dead”.
Most tasks still don’t need the top of the stack. Plenty of production-grade agents today are, correctly, still just a well-context-engineered prompt inside a decent harness.
Bonus: Where This Whole Conversation Actually Started
A few things from the research that didn’t fit cleanly into any single section but are too funny to leave out:
The entire “graph engineering” term is younger than this article’s research window. It crystallized on X on July 18–19, 2026, when Peter Steinberger — creator of OpenClaw — posted a twelve-word question that racked up 2.9 million views: “Are we still talking loops or did we shift to graphs yet?” Within 48 hours the term had three competing definitions and a wave of copycat posts.
One of those copycat posts was a fabricated study. An independent investigation traced a viral claim about a “$3.1M Stanford research grant” for graph engineering back to a fabrication with no such grant behind it — a good reminder to check sources even when (especially when) a stat is exactly what you want to hear.
Conclusion
Thank you for reading all the way through. I decided to hand-draw the diagrams for this post — lmk if my handwriting is illegible or it I should continue doing this?
If you have any questions, you can DM me here:
If you need help with adopting this to your own AI agent/app, you can ask me here:
Further reading:
Appreciate the article, I’m using it as part of educating my employees, many who are new to using AI tools.
Your hand written diagrams are excellent and also humanizes a digital world, which we all need.
Insightful post, thank you!