Prompt, Context, Loop, Graph: Every AI Discipline Is a Patch With an Expiry Date

In July someone sent me a guide to graph engineering, introduced as the discipline that replaces loop engineering, which had replaced context engineering. I had drawn a graph for an agent pipeline six weeks before that and I was pleased with it — it cut the wall clock roughly in half. Then I read the guide, looked back at my diagram, and recognised what I had actually built: a DAG with a critical path, the same shape Airflow has had since 2015, with model calls in the boxes instead of Spark jobs.

That is not an argument against graphs. It is the reason the noun keeps changing. Every discipline in this sequence exists to compensate for something the models of that year could not do, and every one of them shrinks when the models learn to do it. So the useful question is never which discipline is current. It is which half of each one patches the weights and which half patches the system around them — because only the second half survives the next release.

Every discipline is a patch, and patches have expiry dates

An AI engineering discipline is a workaround with a name. It appears when enough teams hit the same limitation in production, it gets a label once somebody with reach writes it down, and it decays when the limitation gets fixed in the weights instead of in your code.

That gives you a test you can run on any of them, including whatever gets named next month:

What would have to become true for this practice to be unnecessary?

If the answer is "a better model", the practice is perishable. Nobody appends let's think step by step to prompts any more, because the models do it internally whether you ask or not. If the answer is "a different business" — different failure costs, different audit requirements, different budgets — the practice is durable, and it will outlive every model on the current price list. Everyone still needs a retry budget, and no amount of pretraining will decide for you whether a failed enrichment step should abort a run or pass a null downstream.

Run that test over the last four years and the sequence stops looking like progress up a ladder and starts looking like a maintenance log.

Prompt engineering patched a model that could not follow instructions

The 2023 practice was real and it was measurable. Chain-of-thought prompting (Wei et al., January 2022) and ReAct (Yao et al., October 2022) were papers, not folklore, and the gap between a carefully framed prompt and a casual one was worth tens of accuracy points on the models of the day. Role framing, delimiters, magic phrases, begging the model to return JSON and then parsing it with a regex anyway — all of it was compensating for weak instruction following.

Instruction tuning, RLHF and then reasoning models closed most of that gap. The job market shows the shape of the decay precisely: postings with Prompt Engineer in the title fell around 40% between 2024 and 2025, while postings listing prompt engineering as a skill went up sharply over the same period. That is not a discipline dying. That is a discipline becoming a line item in somebody else's job description.

What survived is the part that was never about model weakness: output contracts, few-shot examples used to pin down format rather than teach a task, negative examples, and evals. I keep eight prompt patterns that still hold up and four that stopped doing anything measurable years ago — the split between those two lists is almost exactly the perishable/durable line.

RAG patched a four-thousand-token context window

The entire chunk-embed-retrieve stack exists because, in 2023, you could not put the document in the prompt. GPT-3.5 gave you 4k tokens. GPT-4 arrived in March 2023 with 8k and a 32k variant that most people never got access to. Claude 2 pushed to 100k that July, Gemini 1.5 Pro to a million in February 2024. Within eighteen months the primary justification for retrieval had evaporated for a large class of documents.

Retrieval did not disappear, it got demoted. It is no longer the thing that makes an answer possible; it is the thing that makes an answer attributable, permissioned and affordable. You retrieve because you need to know which document the answer came from, because this user is not allowed to see the other four, and because stuffing 800k tokens into every request is a budget decision nobody wants to defend. That is why a local retrieval assistant built on Ollama and ChromaDB is still a sensible thing to build in 2026 — just for different reasons than in 2023.

Context engineering patched the discovery that long windows lie

Tobi Lütke posted his preference for "context engineering" over "prompt engineering" on 19 June 2025; Karpathy amplified it six days later with the sharper definition — filling the context window with just the right information for the next step. The label went mainstream in a week.

The evidence arrived a month after the name. Chroma's Context Rot report (July 2025) tested 18 frontier models — GPT-4.1, the Claude 4 family, Gemini 2.5, Qwen3 — on tasks extended from needle-in-a-haystack, and found accuracy degrading non-uniformly as input grew, sometimes by 30-50% well before the documented limit. On million-token models the effect typically becomes obvious somewhere around 300,000-400,000 tokens, and it accelerates as the semantic distance between the query and the target grows.

This patch has not expired, and the reason it has not is the interesting part. Bigger windows did not fix it; they moved the failure mode. The old failure was the document does not fit, which is loud. The new failure is the document fits and the model quietly ignores the middle of it, which is silent and shows up as a plausible wrong answer. That is a property of attention over long sequences, not a training gap somebody forgot to close — so the discipline of deciding what earns its place in the window keeps paying. It is also why bloated instruction files cost more than people think, something you can measure directly on your own setup with the custom instructions token analyser rather than guessing, and why a lean instruction set beats a comprehensive one on both bill and accuracy.

Loop and harness engineering patched the agent, not the model

Two more nouns arrived in 2026 and neither is about intelligence at all.

Harness engineering came first, early in the year, framed around the equation Agent = Model + Harness: the programmatic wrapper governing the execution environment, with the operating principle that whenever the agent makes a mistake you change the harness so that mistake becomes structurally impossible to repeat. Loop engineering followed in June 2026, popularised by Addy Osmani, and covers the plan-act-observe cycle: termination conditions, state, retries, cost bounds.

Read those descriptions again and notice what is missing. Neither one claims to make the model smarter. They exist because a standing loop fails in ways a single request cannot — it never terminates, it re-calls the same tool with the same arguments, it burns budget for three days before anyone opens the dashboard. Those are operational failures. No model release deletes them, which is exactly why these two labels are unlikely to decay the way the first two did. They will get better tooling, not obsolescence.

The half-life table

Only the top two rows have a filled-in death column, and they have something in common: both patched the model. Everything underneath patches the process wrapped around it, which is why nothing has come along to delete them. That is the whole thesis in one table — the discipline's lifespan is set by what kind of weakness it compensates for, not by how clever it is.

The interval between disciplines collapsed from twenty-nine months to about eight weeks

Put the coinage dates in order and a second pattern falls out, one I did not expect when I started writing this down:

• prompt engineering, mainstream early 2023
• context engineering, 19 June 2025 — twenty-nine months later
• harness engineering, early 2026 — roughly seven months
• loop engineering, June 2026 — about five months
• graph engineering, mid-2026 — about one month

Model capability did not accelerate by a factor of thirty over that window. Label production did. And the relationship between name and practice inverted along the way: the first two labels arrived after the practice was widespread — hundreds of teams were budgeting context before anyone called it context engineering — while the last two arrived alongside it, occasionally ahead of it. A discipline named before its incidents is a content category.

So here is the second test, and it is blunter than the first. Name the production incident the discipline was invented to prevent, in one sentence:

• prompt engineering — the model ignored the output format and the parser threw;
• context engineering — the answer was in the prompt and the model skipped it;
• loop engineering — the agent ran for six hours and spent £300 doing nothing.

If a label cannot produce that sentence, it is a taxonomy, not a discipline, and you can safely read the post and move on.

So is graph engineering the best answer right now?

For a narrow, specific class of system, yes, and it is not close. For most of what people are currently building, no — and being wrong in this direction is expensive, because a graph freezes your assumptions in code and code is much harder to update than a prompt.

A graph earns its place when you can name at least one of these out loud:

Genuine concurrency. Steps that do not read each other's output should not queue behind each other. This is arithmetic, not architecture — on a seven-node research pipeline the difference between a chain and a fan was 130 seconds versus 65, same work, same tokens. If you have four independent lookups, the graph pays for itself immediately.

Failure semantics you can state. Which node's failure aborts the run, which one degrades to a null, which one retries and how many times. A loop with a try/except has an implicit answer to this. A graph forces an explicit one.

A bounded budget across steps, and an audit trail. When someone asks which step made the decision, "the model chose" is not an answer you want to give a regulator.

The counterweight is worth taking seriously. Gregor Zunic's The Bitter Lesson of Agent Frameworks (16 January 2026) argues that 99% of the work happens inside the model, and that frameworks freeze assumptions about intelligence that stop being true a release later. His own product started with thousands of lines of abstraction that "worked — until we tried to change anything". His prescription is a complete action space, a for-loop, an explicit done tool, and context management. Given the half-life table above, he has history on his side.

I think both positions are right about different halves of the same graph, and the split is visible in the edges themselves:

# Perishable — a guess about how the model should think.
# Two releases from now this looks patronising.
edges = [("search", "summarise")]

# Durable — a statement about your business.
# No model release makes this decision for you.
policy = {
    "enrich_crm": {"on_error": "null", "budget_usd": 0.40},
    "charge_card": {"on_error": "abort", "retries": 0},
}

The first edge is orchestration: you are encoding a belief about what the model needs help sequencing. That belief has the same expected lifespan as let's think step by step. The second is operations: it says a failed CRM lookup should not stop a run and a payment must never be retried. That is not going to be absorbed by better weights, ever.

So the rule I use: draw the edges you would defend in an incident review, and delete the ones you drew because the steps read nicely in that order. Start with a single call, move to a tool loop when you need recovery — with an exit condition and a budget from day one — and reach for a graph only when you can state the invariant it protects. Most teams I see skip straight to the graph, because drawing the diagram is the enjoyable part and naming the invariant is not.

Bet on the Half That Does Not Expire

This field will hand you another noun before the end of the year; at the current cadence it is weeks away, not months. Run both tests on it. What would have to become true for it to be unnecessary — and which production incident was it invented to prevent? If a better model would make it moot, learn it in an afternoon and plan to throw it away. If only a different business would make it moot, that is the part worth getting genuinely good at, and it will look suspiciously like distributed systems work that predates every model in this article.

Graph engineering is both halves shipped under one word. Take the operations half, treat the orchestration half as a draft, and you will not have to rewrite your pipeline when the naming cycle turns over again in October.