Blog

Prompt, context, loop, graph. The newest one is your whiteboard

Five names in five years for a job that kept drifting away from the model. The newest one lands on a skill your operations person already has.

There's a specific flavor of stupid that comes from reading a technical paper and slowly working out that it's describing something you already do. It has three stages and I went through all of them in about ninety seconds.

Stage one is feeling like a genius. Thirty-five researchers on the byline, an arXiv number, dense paragraphs about system intelligence and organizational capacity, and I'm nodding along going yeah, obviously, that's how you'd have to build it. Look at me. Should have done a PhD.

Stage two is the floor going out from under that. I was nodding because somebody had written up my job with better vocabulary on it.

Stage three is checking the other monitor to be sure. n8n was open on it. Nodes. Edges. A branch on a field value. A wait node parked in the middle holding for a human to click approve. An error path looping back to a retry with a delay on it. I've been building that for years and calling it a workflow, because that's the word printed on the tab.

The paper is Graph Engineering in the Era of LLM Agents, and it argues that the field has already moved through prompt engineering, context engineering, harness engineering, and loop engineering, and that all of them run into the same wall: one agent, however well equipped, can only organize so much work. The authors' answer is to stop tuning the agent and start drawing the system. Explicit nodes, explicit edges, explicit state.

I didn't see any of this coming and I invented nothing. A skill I already had, sitting in the least glamorous corner of the org chart, stopped being unglamorous while I wasn't looking.

Five names, four movements

Prompt engineering came out of the GPT-3 era and peaked in 2023, the year Anthropic posted a "Prompt Engineer and Librarian" role and Time wrote it up at up to $335,000. Context engineering has a birthday: Shopify's Tobi Lütke posted the definition on June 18, 2025, Karpathy amplified it a week later, and Anthropic formalized it in an engineering post on September 29, 2025. Harness engineering arrived on March 10, 2026, when LangChain's Vivek Trivedy published The Anatomy of an Agent Harness. Loop engineering got its name from Addy Osmani on June 7, 2026. Graph engineering showed up six weeks later, in LangChain's three-year retrospective on LangGraph on July 22, 2026, and then in the paper.

Five names in five years. If you run a business that doesn't have an engineering department and you've had a low hum of anxiety that everyone else got a memo you didn't get, that's the memo. It's a vocabulary list.

Two of the five coinages came from a company that sells the thing being named. Read who signed the memo. That's the mentor rule from the last time I wrote about vocabulary: be careful when somebody tells you what you should do, because there's more in it for them than there is for you.

The tell for a fake rename is that it describes work you were already doing under a word you already had. These four describe work people were doing badly with no word for it, which is why the fix each one prescribes is different from the fix before it.

And underneath the churn there's one movement, which is the unit of engineering sliding outward. The string. The window. The run. The system.

GRAPH · THE SYSTEM2026LOOP · THE RUN2026CONTEXT · THE WINDOW2025PROMPT · THE STRING2020"LET'S THINK STEP BY STEP"EACH ONE KEEPS THE ONE INSIDE IT
Every rename moved the unit of engineering one frame outward. None of them replaced the frame inside.

Prompt engineering

What it was. The model completed text. One window, no memory between sessions, no tools, no way for it to check its own work. The only surface you could touch was the string you typed, so the string became the entire discipline.

How it got used. The GPT-3 paper showed a model picking up a task from a few examples pasted into the prompt with no retraining, and few-shot prompting became the default move. Chain-of-thought prompting followed in 2022: show the model worked examples and its accuracy on multi-step problems jumps. Then Kojima and coauthors found you could skip the examples and get much of the same effect by appending "let's think step by step." A phrase. Typed at the end. Measurably different output.

No wonder there was a gold rush. Prompt libraries. Prompt marketplaces. Screenshots of prompts sold as products. For about eighteen months everybody was a prompt engineer, it was in headlines above people who had opened ChatGPT eleven times, and the rest of us read the $335,000 number and did some math on our own salaries that did not improve the afternoon.

Why it stopped being the job. Two things happened.

It doesn't survive scale. One clever string is a trick. Forty of them spread across a company, each written by a different person, none versioned, none tested, is a maintenance problem, and no amount of cleverness in any single string fixes it.

Then the tricks got absorbed. Chain of thought went from a phrase you typed to behavior the model was trained to produce, which is what reasoning models are. The technique got promoted into the weights. That happens to any prompt trick that works well enough for long enough, which is worth remembering the next time somebody offers to sell you a pack of them.

So prompt engineering got demoted. It's now what you do inside one box. Most of those headlines are gone now, though nobody held a ceremony. They quietly became "AI Strategist," which is the same claim with less of it checkable.

The part I'd still defend: prompting was a communication skill wearing an engineering job title. Knowing what a stranger needs spelled out, and what they'll fill in on their own, is a teaching skill. That's why the best prompters in a lot of companies were the writers, the trainers, and the support reps rather than anybody in IT.

Context engineering

What it is. The input is the whole window, and everything that lands in it counts the same: the prompt, system instructions, retrieved documents, tool output, prior turns, memory files, schemas, the lot. Lütke's version is providing all the context needed for the task to be plausibly solvable. Anthropic's is curating and maintaining the optimal set of tokens during inference.

WHAT LANDS IN THE WINDOWRULESTOOL OUTPUTRETRIEVED DOCSPRIOR TURNSTHE PROMPTEVERY TOKEN SPENDS FROM THE SAME ATTENTION BUDGET
Schematic, not measured: the proportions vary by job. Prompt engineering got its name from the smallest slice of it.

Why it's mostly subtraction. The instinct is to add more. I watched a sharp operations manager paste an eighty-page employee handbook into a chat window, ask a specific question about PTO accrual, get a mushy non-answer back, and conclude the AI was stupid. The AI was drowning. He handed it the filing cabinet and asked for one file.

Chroma published Context Rot on July 14, 2025, testing eighteen models, and found that models don't use their context uniformly: performance grows increasingly unreliable as input length grows. Degradation came faster when the answer was semantically distant from the question, and adding even one distractor lowered performance against a clean baseline. The needle-in-a-haystack test everybody quoted made long context look solved because it's close to a lexical lookup in a tidy pile, which is nothing like the pile you work in.

Anthropic frames the cause as an attention budget. Transformer attention computes relationships between every pair of tokens, so the pool is finite and every token you add spends from it. More context is not free context.

How it gets used. Retrieval instead of dumping. Just-in-time loading, where you hand the model file paths and stored queries and let it pull the contents only when it needs them. Compaction, where a conversation nearing the limit gets summarized and restarted in a fresh window. Sub-agents doing focused work in a clean window and returning a distilled summary, which Anthropic puts at roughly a thousand to two thousand tokens.

Handing over the cabinet feels generous and lands as sabotage.

Why it stopped being enough. A perfectly curated window is still one turn. Real work takes many, and the window that was right at step one is wrong by step nine, and nobody is sitting there hand-curating at step nine.

Loop engineering

What it is. Work that runs more than once, where the model acts, reads the result, and acts again until something says stop. The ancestor is ReAct, from 2022, which interleaved reasoning and action so a model could call a tool, read what came back, and adjust. That's the loop running under the agents you use.

Trivedy's harness post gave the machinery its cleanest definition: Agent = Model + Harness, where the harness is everything that isn't the model. System prompts, tools, sandbox, orchestration, the middleware that runs between turns. LangChain says they took their coding agent from outside the top thirty to fifth on Terminal Bench 2.0 by changing only the harness. That's a vendor reporting a win on its own product, so price it accordingly, but the claim is specific and falsifiable and it points where you'd expect.

Osmani named the outer part: "Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead." His five ingredients are automations on a schedule, isolated worktrees, skills holding project knowledge, connectors into real tools, and sub-agents doing verification separately from creation. Plus external state in a file or a board, because the model carries nothing between runs.

What the discipline consists of. Boring things. What counts as done. What happens on failure. How many turns before you stop, and how much you're willing to spend getting there. Who checks.

Skip that and here's Friday morning: forty turns of a polite machine trying the same wrong thing in slightly different outfits, capped by a closing message saying the work is complete. The work is not complete. The work was never started.

Which is why "done" cannot be the model saying it's done. That's the artifact rule: take the diff, take the full test output, take the URL that loads. A summary of the work is another generation from the same machinery that produced the work.

Osmani's own warning is the part that rarely makes it into the reposts. A loop amplifies risk as fast as it amplifies output, verification stays yours, and the comfortable version of this is the dangerous one.

Why it wasn't the end of it. The loop has no shape. It's a while-loop with a smart body, so when it works you get a result and when it doesn't you get a transcript, and there you are on a Friday reading forty turns to find the one that went sideways. A loop also can't say the things a real process is made of: these three run at the same time, then a person approves, then it branches on what they said. You end up describing the process inside a prompt and hoping it gets followed, which is the same plan as taping the org chart to the wall and calling it management.

Graph engineering

What it is. The process, drawn. Nodes do the work, edges decide what happens next, and state lives outside any single node so it survives a step failing.

LangChain's retrospective makes the point that this isn't a rival to the loop: "loops are simple graphs." A loop is a directed cyclic graph that happens to have one node in it. Drawing the rest gives you somewhere to put the parts that shouldn't be up to the model. Their lessons from three years of it: real agents need cycles rather than clean one-way flows, because production work has retries and revisions and pauses for human input; and mixing deterministic paths with agentic ones beats committing to either.

LOOPAGENTUNTIL DONENO SHAPE TO READ WHEN IT FAILSGRAPHCLASSIFYPATH APATH BHUMAN OKERROR PATH
A loop is a graph with one node and no labels on it. Drawing the rest is what gives a failure somewhere to land.

The paper's version is stronger. Individual intelligence hits a ceiling when a task needs heterogeneous expertise, interdependent subtasks, parallel execution, independent verification, and persistent state, and, in their words, "augmenting one agent's capabilities or context cannot resolve this architectural mismatch." You don't buy your way out of this with a bigger context window.

Where I live. I work with companies that don't have an engineering department. They make money doing a physical or a professional thing, and somewhere in the last two years a board member, a competitor, or a kid at Thanksgiving told them they need to be doing something with AI.

Those businesses already run on graphs. Nobody has drawn one and nobody would use the word, but it's sitting right there. The job doesn't get invoiced until someone signs off on it. The file doesn't advance until a second person checks two specific things. A quote over a certain dollar amount goes to a different human. Those are nodes, edges, and conditional routing, wearing whatever names that company gave them fifteen years ago.

So most of my first week anywhere is a whiteboard. I ask six people to describe the process and I get six processes, and all six of them believe they're describing the same one. Then we draw the real one, including the step that only exists because a customer yelled in 2019. That drawing is the deliverable, and it stays the deliverable whether or not any AI ever touches it.

Construction is the cleanest example because there the graph is legally enforced. Rough-in before the walls close, with an inspection in between done by somebody who didn't do the work. Fail it and you go back to a named step instead of to the beginning. Nobody at the county calls that a graph with verification gates. It is one, and it was one for a century before anyone put it in software.

The ordering and the independent check transfer to agents. The reliability doesn't. An electrician doesn't wake up on Tuesday with a fresh interpretation of the plans. Your nodes do.

The workflow tools, meanwhile, have been shipping directed graphs to non-engineers this whole time. SAP invested in n8n in May 2026 at a $5.2 billion valuation, double where it sat under a year earlier, with 1.7 million monthly builders and more than 80% of workflows on the platform now involving AI agents. The canvas didn't change. The boxes got smarter. A node used to mean "POST this payload to that endpoint." A node can now mean "read this thread and work out which of three things happened." Same drawing, different contents.

What a graph doesn't fix

Drawing the boxes is the easy half, and owning a whiteboard settles nothing.

Berkeley's Why Do Multi-Agent LLM Systems Fail? annotated more than 1,600 execution traces across seven multi-agent frameworks and sorted what went wrong into fourteen named failure modes in three groups: system design at 43.8% of failures, inter-agent misalignment at 32.15%, and task verification at 23.5%.

Read the names inside those groups and notice how few of them are a model being dumb. Information withholding. Ignored other agent's input. Fail to ask for clarification. Unaware of termination conditions. No or incomplete verification. Those are seams, and drawing a box around each agent fills in none of them.

THE EDGE YOU DREWRESEARCH NODERETURNS JSONDRAFT NODEEXPECTS YAMLWHAT THE EDGE HAS TO CARRYTHE SHAPE OF THE DATAWHAT DONE MEANS HEREWHO WINS IF THEY DISAGREE
Drawing the box is the easy half. The contract between two boxes is the part nobody writes down until it breaks.

Back to the job site: the schedule doesn't make the framer and the electrician talk to each other. Everybody has seen a wall closed up before the rough-in passed, and nobody blamed the schedule.

So the edge is where the work is now. What shape the data takes crossing it, what "done" means for the node that just finished, and who wins when two nodes disagree. That's contract work, and it's the same contract work integration people have done between two SaaS systems forever, with one change: the thing on the other end of the contract is now nondeterministic and will occasionally answer a slightly different question than the one you asked.

Two failure modes I'll own, since I have the automation habits.

A canvas tempts you to draw a node for everything. Forty nodes where eight would do is the same error as a twelve-thousand-token system prompt: you spent your effort specifying instead of deciding, and now all forty are yours to maintain forever.

And my personal one, from years of building deterministic flows: hardcoding a branch where I should have let the model decide. The opposite mistake is more fashionable right now, people handing judgment to a model for things that should have been an if-statement. Mine is the one I catch myself at monthly.

What transfers

None of the four disciplines is about the model. The string, the window, the run, the system: every one of them is the stuff around it, and each rename moved further away.

So the people who are good at this mostly didn't come from machine learning. The first discipline rewarded explaining things clearly to a stranger. The middle two reward editing and QA, which is knowing what to cut and knowing what counts as proof. The last one rewards decomposition: looking at a mess of human work and seeing where it splits into steps, which step carries the risk, where state has to live, and where the thing fails quietly instead of loudly.

Nobody has ever been hired for that in so many words. It's the invisible half of a dozen job titles. Ops, integrations, practice manager, office manager, the one person at a forty-person company who knows how everything actually works and whose two-week notice would be an extinction event.

The next word lands in about eight months. It'll name something real, somebody will be selling a course on it inside a week, and that person will hear about it a year later from a LinkedIn post with 900 reactions.

If that's you, or if that person works for you, go find the whiteboard. Then go look at the diagram in one of these papers. You'll recognize it. Go draw the boxes.

Start here

Recognize the problem? Let's look at yours.

Thirty minutes on the loop that costs you the most hours. You leave knowing whether it can be automated and roughly what that takes.