Prompt, Context, Harness, Loop, Graph — I Kept Up. Barely.

The community throws out a new buzzword roughly every six months to a year. During the Prompt Engineering era, I was rewriting system prompts every single day until I started questioning my life choices. Then Context Engineering took the baton, and Karpathy's one-liner yanked the whole conversation in a new direction. After that came Harness — "Agent = Model + Harness" got framed as a formula and plastered everywhere. Then it was Loop's turn — people started saying they no longer write prompts, they only write loops. By mid-2026, Graph is back on the table: multi-node, shared state, resumable execution.

I chased these terms at first, too, until I noticed something: on the surface it looks like a relay of nouns, but underneath, the same thing keeps happening over and over.

It's not that the new word sounds better. It's that the failure at the layer above got expensive, and the engineering leverage was forced to shift outward.

In May I wrote about the journey from Prompt to Harness, in June about loop engineering, and in July about Harness self-iteration. Each of those posts pinned down a single layer. This one does just one thing: I string the five layers into a single causal chain, then answer a practical question — which layer are you stuck at right now?

The Five Layers Are Nested Floors, Not an Upgrade Roadmap

I've seen too many people treat these five terms as an "upgrade roadmap": PE is outdated, so move to Context, then Harness, stacking all the way up to Graph. Every time I see that framing I want to slam the table. They are nested floors — each layer contains the ones before it. They're not version numbers that invalidate each other.

One more thing I need to nail down upfront: this is a bottleneck narrative, not a strict chronology. ReAct's loop (2022) and LangGraph (2024) predate the naming wave for context/harness (2025–2026) on the calendar. Naming has always lagged behind practice. The trap I fell into: in 2024 I was already using state graphs for orchestration in a project, but I called it a "workflow engine" because the word "Graph" hadn't been formally claimed by the community yet.

Prompt is a subset of Context; the Context pipeline is a subsystem of Harness; Harness powers a single Loop; a Loop is often just one node in a Graph.

Every Layer Pays for the One Above It's Weaknesses

PE: Say It Clearly, Then Hit "No Facts Outside the Window"

Prompt Engineering solves problems at the sampling-distribution level: role setting, few-shot examples, output format, refusal boundaries. From my own testing, the same model can produce wildly different outputs just by rephrasing the prompt. Its ceiling is equally clean: no matter how perfect the wording, you can't conjure facts that aren't in the context.

The moment a task shifts from "write a copy paragraph" to "get things done with my codebase, tickets, and contracts," the bottleneck immediately moves from "expression" to "information." PE didn't die — it just stepped back from the lead role to become a managed object inside a larger system. Harrison Chase puts it more bluntly: PE is a subset of context engineering. I agree, because my own system prompts are now dynamically assembled by the harness, and the hand-written portion keeps shrinking.

Context: Feed the Right Things In, Then Hit "Long Means Rotten"

That widely quoted line Karpathy posted on X puts the shift in plain terms:

I really like the term "context engineering" over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM. —— Andrej Karpathy

Anthropic puts it even harder: context is a finite, costly attention budget; the longer the window, the more prone to context rot — a gradual degradation in recall and focus, not a cliff-edge collapse. The principle is refreshingly simple: find the smallest possible high-signal token set. Source: Effective context engineering for AI agents.

The progress at this layer is upgrading "write one prompt" into "re-curate for every inference: what goes in the window, what gets compressed, what hits disk, what's retrieved on demand." CLAUDE.md, git state, on-demand file reads — they're all context engineering in essence. In my own projects, I keep CLAUDE.md under 80 lines and route anything beyond that through on-demand retrieval. It works far better than shoving an entire README in.

But Context still has a hard flaw: no matter how clean the input, nobody is watching the execution. I hit this once — step 1 was right, step 7 drifted, step 20 was building on the error, and then it confidently declared "done." You can't fix that by "feeding it two more documents."

Harness: Put a Reins on a Single Run, Then Hit "You're Still the Start Button"

LangChain states the formula cleanly:

Agent = Model + Harness. If you're not the model, you're the harness. —— The anatomy of an agent harness

Harness covers everything outside the model: tool registration and validation, permission gates, state and memory, compaction, retry and recovery, logging and observability. The model proposes; the Harness executes, observes, and decides whether this round can continue.

Anthropic's article on long-running agents names several real failure modes: trying to one-shot an entire project, losing memory across sessions, declaring completion too early. Their response is very engineering-flavored — an initializer sets up the environment and feature list first, the coding agent tackles one chunk at a time, handoffs happen via progress files and git, and acceptance is based on real end-to-end checks, not self-reported scores. Source: Effective harnesses for long-running agents.

This layer answers: can a single run keep doing the right thing? The ceiling is just as clear: no matter how perfect the harness, by default it manages "this one run." Start it, check the result, decide whether to kick off another round — the human is still in the loop. For a high-stakes one-off task, that's fine. But once the work becomes daily issue triage or weekly report refreshes, you've become a cron job. I became a cron job myself — manually hitting "continue" every morning for three weeks before I realized I needed a loop.

Loop: Pull Yourself Out of the Cycle, Then Hit "One Specialty Can't Hold It All"

The public signals at the Loop layer are already quite clear. Peter Steinberger, author of OpenClaw, points in this direction: stop prompting the coding agent one message at a time — design the loops that prompt it for you. Boris Cherny, head of Claude Code, is even more direct: he no longer prompts personally; he has a bunch of loops running, and his job is writing loops. LangChain then distilled loop engineering into stackable layers: agent loop, verification loop, event-driven loop, hill-climbing loop. Source: The art of loop engineering.

The boundary needs to be pinned down:

What's actually hard about a Loop is the verifier and the termination condition — drawing the circle is the easy part. An unattended loop with weak verification doesn't just "give a bad answer" — it confidently produces garbage all night long, and you're still paying by the token. I wrote in my loop engineering post: designing the loop isn't hard; keeping it affordable is. Let me add one more line today:

The bottleneck of a Loop is rarely the model. It's the referee.

The ceiling of a single loop is right here: it excels at repeating one specialty. When research, writing, review, and testing naturally require different contexts, different tools, and different success criteria, a single loop starts touching everything and nailing nothing. I tried cramming code review and doc generation into the same loop, ran it for two weeks, and quality dropped on both sides.

Graph: Weave Multiple Nodes into an Organization, Then Hit "Distributed Systems Tax"

The word "Graph" existed well before 2026 — it's not some invention from thin air. LangGraph's positioning has always been: an orchestration runtime for long-running, stateful agents — nodes do the work, edges handle routing, shared state flows across the graph, with an emphasis on durable execution, human-in-the-loop, and post-failure recovery. Source: LangGraph overview.

A single loop is, at its core, the simplest graph: one node with a self-loop. The Graph structure only becomes truly necessary when you need fan-out / fan-in, conditional back-edges, deterministic steps mixed with agentic steps, or explicit audit routing. What it solves is: how do multiple specialties collaborate reliably?

The new tax it introduces is real too: state contracts, failure back-edges, concurrency conflicts, responsibility pollution, observability. At my previous company we tried it once — we adopted Graph too early, and debugging time doubled while intelligence didn't go up. We just added a pile of classic distributed-systems problems for no gain.

Public Signals Are Converging: Everyone Is Actually Renovating the Same Building

The high-signal material from the past year or two uses different language but has a very similar structure: Karpathy is pushing context engineering, Anthropic writes about attention budgets and long-running harnesses, LangChain nails down Agent = Model + Harness and stacks loops into agent / verification / event / hill-climb layers, and LangGraph handles state graphs and resumable execution.

Claude Code, Cursor, and the OpenAI Agents SDK take different routes, but what the harness needs to manage is converging: loops, tools, state compaction, permission gates, recovery, and observability. OpenAI leans more toward explicit multi-agent handoff; Claude Code / Cursor lean toward a strong single agent with deep integration. Organization-level complex delivery is where you truly need graphs and state machines.

Models are getting stronger, but what's widening the gap is increasingly whether the system around the model can survive step 50.

I compared two pipelines using the same model. The only difference was the harness and loop design, and the end-to-end completion rate was noticeably different. When evaluating an agent, reporting only the model name is nearly unreproducible — you have to report the full shell. This is my experience, not theory.

A Diagnostic Map: Stop Using "The Model Isn't Good Enough" as a Universal Scapegoat

What's actually useful day-to-day is labeling the floor:

Most "the model isn't capable enough" complaints, when I break them down, look like this: the instructions are vague; what should be in the window isn't, and noise that shouldn't be is; there's no independent acceptance check, it's all self-evaluation; the human is still the start button and the QA inspector; a team-level problem got stuffed into a single brain too early.

My default order when building products is also refreshingly simple: first solidify the context and harness for a single task, then write a loop with a verifier, and only split into a graph when you genuinely need to.

This is the same discipline as Anthropic's "find the simplest solution first," and it's isomorphic to what I said in my Skill / Workflow / Agent post: "downgrade if you can." If the path can be drawn clearly and needs auditing, use Workflow + Skill. If the path can't be fully specified and the environment is dynamic, use a small-scope Agent with a strong harness. If you need unattended repetition, use a Loop. Only when you need multi-specialty parallelism and convergence do you reach for a Graph.

Should You Adopt Graph? Three Questions Beat Any Slogan

Graph is the easiest to package as "more advanced." I've seen too many slide decks with beautiful topologies of six or seven agents that, in practice, run entirely sequentially. I'd rather you run through three questions:

• Is the task naturally multi-specialty? Do research, writing, review, and testing require different tool sets and success criteria? If the same kind of work is done repeatedly, a single loop is usually more stable.
• Do you need explicit routing and auditing? In compliance, finance, or release-gate scenarios, the weight of edges and state outweighs "letting the model freestyle." Deterministic nodes should be hand-written when they should be.
• Is there an independent verifier node? A multi-agent setup without a referee is just compounding errors in parallel instead of serial. Generation is cheap; judging whether it's good enough is the expensive part.

If you can't answer any of the three questions with confidence, yet you're already drawing a beautiful topology of six or seven agents — stop. You're probably manufacturing a distributed system for yourself; there's no real orchestration happening. On the other hand, if a single agent's contexts are polluting each other, serial execution is too slow, and critical steps must be replayable, then Graph is necessary — and it has nothing to do with showing off.

Wrapping Up

Compressed into five sentences:

• It has nothing to do with buzzword relay — this is leverage being forced outward after failure costs shifted up
• The five layers are nested, not interchangeable — a bad prompt can still poison a beautiful graph
• Public material is already converging — Karpathy / Anthropic / LangChain / LangGraph are renovating the same building
• Label the floor before you build — unclear instructions, missing facts, long-run drift, waiting for a human to start, multi-role conflicts — each needs a different surgery
• Adopt Graph with restraint — multi-specialty, needs auditing, has an independent verifier; get all three before you go; if you can't, a single loop is more honest

The model is the engine, but an engine doesn't win races on its own — the car does. In 2026, the gap will be decided by who first engineers the layer where "failure got expensive" into a shell, a loop, and a graph.

Public references: Karpathy, Anthropic context, Anthropic harness, LangChain harness, Loop engineering, LangGraph.

New words will always go stale. Failure bills never do. Figure out which layer you're stuck at first, then decide whether you need to fix one sentence or redraw the entire graph.