AI-Native Series · Agent Engineering, Compared: Prompt · Context · Harness · Loop · Graph

Prompt Engineering Is a Specification, Not a Spell

Episode 1 of 6. This series compares the five ways people engineer AI agents — prompt, context, harness, loop and graph engineering: where each came from, what it controls, who is driving it, and which principles survive measurement. This episode is the oldest rung, prompt engineering, and the 2026 measurement that says it is not solved.

By Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app · 2026-09-03 · Episode 1 of 6

What this episode covers, and why prompt engineering comes first

There are now five named disciplines for building AI agents, and they arrived in roughly this order: prompt engineering (2020), loop engineering (2022), graph engineering (2023), harness engineering (2024) and context engineering (2025). The clearest published statement of the set is Feng et al.'s survey (arXiv:2608.21156), which orders them by what each lets you control rather than by age: prompt → context → harness → loop → graph. This series takes them one per episode, in that order, and asks the same four questions of each — where did it come from, what exactly do you control, who is driving it, and which failure pushes you up to the next rung.

Prompt engineering goes first because everything above it is bounded by it. The 2026 measurement at the centre of this episode (Dhage, arXiv:2608.26197) set out to prove that a harness — rung three — makes agents reproducible. It found instead that the variance left over came from one place where the model was still allowed to write prose, and that constraining that one prompt-level step did what the harness could not. You do not get to skip rung one.

Who this is for. An AI engineer who needs the same input to produce the same output. A founder deciding whether an agent demo can become a product. A high-school builder who wants to know what "prompt engineering" actually is, without the mysticism. The only prerequisite is having called a language model once.

Where prompt engineering came from, and who is driving it

[DEF] A prompt is the text you send to a language model: the instructions, any examples, and the shape you want the answer in. Prompt engineering is the discipline of writing that text so the output is what you needed. That is the whole definition. The history is how it went from a trick to a specification.

[DESIGN] Three things to notice in that table. First, the discipline did not start as engineering; it started as a 2020 discovery that the words in the input steer the model without retraining it. Second, the "magic phrase" era peaked in 2022 and was over by late 2023, when Stanford's DSPy replaced hand-written prompts with declared signatures and an optimizer. Third, the practitioner canon — Anthropic's and OpenAI's own guides — converged on the same short list: be explicit, show examples, give the output a structure, let the model reason before it answers, split big jobs into chained calls. Nothing on that list is a spell. Every item is a constraint the output can be checked against, which is the definition this episode runs on.

Who drives it now. The model labs (OpenAI, Anthropic, Google) publish the guides and own the system prompts. Stanford NLP's DSPy and the software-engineering "promptware" programme are turning prompts into versioned, tested artifacts. Independent practitioners keep the labs honest — Simon Willison named prompt injection in 2022 and was annotating Claude's newest system prompt the day before this went to press. The measurement this episode rests on came from none of them: a single-author empirical study posted three weeks before press time.

The mental model for the series: the kitchen ladder

One picture will carry all six episodes, so here it is, stated as a tool rather than a story. Every cook climbs the same ladder: you cook for yourself, then for your family, then in a restaurant kitchen, then you run a fast-food chain, then you run the national supply chain that feeds several chains. Every AI engineer climbs a matching one — school learner, junior developer, senior developer, AI tech lead, CTO, frontier leader — and each rung of agent engineering is one kitchen on that ladder. Rung one is the recipe card. You write it; a cook you cannot talk to makes the dish; you are not in the kitchen and you cannot taste as they go. Everything you want has to fit on the card, in advance, with no chance to clarify:

Tomato-and-egg stir-fry for two. Three eggs, two tomatoes, 3 g salt, 1 tsp sugar. Eggs soft-scrambled first and out of the pan before the tomatoes go in — so they stay soft. On the table in 12 minutes.

That card is a prompt. The cook is the model. Each higher discipline is a different part of the kitchen you are allowed to touch — the pantry and counter the cook works from (context), the stations, the tools and the pass (harness), the taste test and the correction (loop), the supply chain feeding many kitchens (graph). This episode you control the card and nothing else. Not the pantry, not the tools, not what happens after the card is handed over.

Two axes, not one. Read the table carefully and it is not a ladder you climb and leave behind: every kitchen has all five layers at once. A home cook has a card, a pantry, a stove, a taste, and a supplier. What changes as you climb — as a cook or as an engineer — is how many layers you are allowed to touch and how rigorously you run each one: by feel, then measured, then gated, then self-correcting. A national chain with a decorative supply-chain diagram and no taste test is less mature than a single restaurant that weighs every plate. So the five disciplines are layers (what you control); seniority is maturity (how you run them); and "graph" is not automatically more advanced than "loop". The open sixth layer has a strong candidate — evaluation engineering, the truth function every other layer borrows to know whether it improved — and Episode 6 will argue it rather than assume it.

The analogy is allowed to introduce a claim. It is never allowed to be the evidence for one — every element is pinned to one thing in code in the 1:1 technical map below. And the episode ends with the discovery that a perfectly written recipe card still produces different dishes, because the card is not the only thing on the counter when the cooking happens. That is Episode 2.

The ladder is not mine

[DEF] The vocabulary, pinned to its source — because five labels compete for the same territory and most listicles get the set wrong.

The clearest published statement of the ladder is Feng et al.'s survey (arXiv:2608.21156, revised 2026-08-26). It names four rungs and then argues for a fifth: "Prompt Engineering to elicit model capabilities, Context Engineering to manage information access, Harness Engineering to organize external tools and resources, and Loop Engineering to support continual reflection and self-improvement" — and then Graph Engineering, for what the authors call System Intelligence, the point at which one agent's organizational capacity is the binding constraint rather than its ability.

[DESIGN] Note what that means for the four-label framing you have probably seen — prompt, harness, loop, graph. It is missing a rung, and not a minor one. Context engineering sits second, between prompt and harness, and it is the rung that the practitioner literature has spent the most words on. Episode 2 is about the rung the listicles skip.

[OPEN] Note also what the survey does not claim: that each rung supersedes the last. That is the reading the labels invite and the one this season is going to keep testing. Season 6 of this franchise tested the nesting claim specifically — a prompt inside a harness, a harness running loops, a graph coordinating loops — and found it contradicted by its own primary source, since Anthropic's own definition makes the harness the loop rather than a layer above it. That finding stands. This season adds a different question: when a rung fails, is the next rung the fix?

The claim, classed

[DEF] A prompt is a specification. Not a request, not an incantation, not a "magic word" — a written statement of what the output must satisfy, handed to a worker who cannot ask a clarifying question.

[EVIDENCE] The reason to take that definition literally rather than poetically is that somebody finally measured it, and the result is sharper than the folklore.

Dhage's empirical study (arXiv:2608.26197, 2026-08-25) set out to test whether wrapping an agent in a deterministic execution layer — finite-state control, forced tool selection, output validation, bounded retry, structured planning — makes it reproducible. Two synthetic tasks (finance and legal), two open-weight models (Qwen-2.5-7B-Instruct and Gemma-3-27B), four model-task cells.

The first-pass result is a mess, and the paper says so plainly: the harness "significantly improves reproducibility in one of four model-task cells, significantly degrades it in two, and has no effect in the fourth."

Read that again. Three of four cells got no better or actively worse. The team added guardrails and the dashboard filed a complaint. If you had stopped there, the honest headline would have been harness engineering does not work.

[EVIDENCE] Then the trace-level diagnostic found the cause, and the cause is the whole reason this episode exists. Once the tool sequence, the state sequence and the output were already highly consistent, the dominant remaining source of run-to-run variance was an unconstrained free-text planning step. One place in the pipeline where the model was still allowed to write prose.

Constraining that one thing — "validating the plan against a fixed schema before any tool is invoked" — "eliminates the effect entirely: three of four cells reach a Reproducibility Rate and Determinism Index of 1.000 at N=100, and task success rises to 100% in three of four cells."

[DERIVATION] So the finding, stated as a rule you can act on: the most elaborate machinery on the higher rungs is bounded by the least constrained piece of language anywhere in the system. You do not get determinism by adding layers. You get it by finding the one place still emitting free text and giving it a shape.

That is a rung-one problem with a rung-one fix, discovered by people who were trying to demonstrate rung three.

[DESIGN] And the cost is not zero, which the paper is careful about: "token cost falls in every cell, but latency shows a genuine, sample-size-robust split by model — one becomes faster under the constraint, the other markedly slower." Cheaper, more reliable, and possibly slower, depending on which model you point it at. The paper's own conclusion is the right one to steal: harness engineering is a real discipline "but its cost is model-dependent and must be measured, not assumed."

[OPEN] Two honest limits on all of the above. It is one paper, two synthetic tasks, two open-weight models at 7B and 27B, no independent replication. And "determinism" is a stranger goal than it sounds — a system that gives the same answer every time is not thereby giving a good answer every time. Reproducibility and correctness are different axes, and the paper measures both precisely because they can move in opposite directions.

1:1 technical map

Every element of the metaphor maps to exactly one thing you can point at in code. A metaphor may introduce a claim. It may never evidence one — so here is the translation, with nothing left decorative.

[DEF] The two numbers the rest of this season leans on, defined once:

• Reproducibility Rate — over N identical runs, the fraction that produce identical output. Nothing about quality. Purely: does it do the same thing twice.
• Determinism Index — the same idea applied to the trajectory rather than the final answer: same tool sequence, same state sequence, same output.

A system can score 1.000 on both and be reliably wrong. That is a feature of the metric, not a flaw. It separates "is it stable" from "is it right", and you genuinely cannot debug the second until you have settled the first.

Prediction Gate

Before you scroll, commit. Write your answer down — the point of this device is that a prediction you did not record is a prediction you will believe you got right.

You take one prompt that produces structured output. You write down twenty assertions about what its output must satisfy: fields present, types correct, enum values legal, lengths bounded. You run it 100 times at temperature 0.

Q1. What fraction of runs produce byte-identical output?

Q2. You now add a single change: the model must first emit a plan that validates against a fixed schema, before any tool is called. What happens to the fraction in Q1 — and what happens to latency?

Q3. Rank these three by how much they reduce run-to-run variance, most first: (a) lowering temperature to 0, (b) adding twenty explicit assertions to the prompt text, (c) schema-validating one free-text step.

Answers are in the Failure Room and the Notebook. If you got Q3 in the intuitive order, the notebook is going to be worth your fifteen minutes.

Failure Room

Break it deliberately. A mechanism you cannot break is a claim, not a mechanism.

Failure 1 — temperature 0 is not determinism. The most common belief on this rung, and it is false in practice. Temperature 0 makes sampling greedy; it does not make the system deterministic, because batching, kernel non-determinism on GPU, tool results, timestamps and retrieval order all vary underneath you. Dhage's four cells are all at controlled settings and still show variance worth a whole paper. If your reliability story is "we set temperature to zero", you have not started.

Failure 2 — the assertion you did not write. The card says 3 g salt. The cook uses exactly 3 g — and the dish is still too salty, because you specified the salt and never mentioned the soy sauce, which carries its own. Every incomplete spec looks complete until the first plate. This is why the notebook makes you write assertions before you look at any output: assertions written after are just a description of what you got.

Failure 3 — over-specification eats the capability you were paying for. Push the other way and you get the mirror failure. Constrain every field, forbid every deviation, and you have written a very expensive if statement — a cook who follows the card with the culinary imagination of a stapler. The cook's judgement is the thing you hired. The engineering question is never how much can I constrain — it is which single unconstrained step is costing me the most variance, which is precisely the question the trace-level diagnostic in arXiv:2608.26197 answers empirically rather than by taste.

Failure 4 — the metric that is 1.000 and useless. Get Reproducibility to 1.000 by having the model return {} every time. This is not a joke; it is the shape of most reward hacking. Any determinism metric must be reported next to a task-success metric or it is an invitation to cheat. The paper reports both, and so does the notebook.

Answer to Q3: (c), then (b), then (a) — and the gap is not small. Schema- validating one free-text step took three of four cells to 1.000. Adding assertions to the prompt text helps the model try harder; it does not make anything checkable. Temperature 0 was already in force when the variance was measured.

Notebook

Lab 01 — Variance, and the one step that removes it.

labs/01_prompt_as_specification.ipynb · Colab free tier · no API key · ~15 seconds of CPU · every cell executed before publication.

Eight cells. The worker is a stub whose decision is derived from a free-text plan field — that one design choice is the entire lab, because a free-text step upstream of a decision does not add cosmetic variance, it moves the decision.

1. The worker, with four packaging failure modes held deliberately independent of the plan, so the diagnostic can tell the decision moved from the JSON was malformed.
2. The assertions, written as a schema before any output is looked at.
3. Baseline over N=100: reproducibility 0.280, determinism 0.330, task success 0.890.
4. Bounded retry — the one-line fix every framework ships. Task success goes to 1.000. Determinism moves to 0.440.
5. The trace-level diagnostic, attributing variance by field. plan and the decision fields downstream of it dominate; ticket_id never moves.
6. The sweep, and the cell worth stealing. Vary how unstable the free-text step is and watch the two interventions come apart.
7. Structured Planning — constrain the plan before the decision reads it — plus the plot.
8. The bridge: point the identical measurement at any OpenAI-compatible endpoint.

[EVIDENCE] The result that made this lab worth building is in cell 6, and it is not the one I expected when I wrote the outline. Retry never lowers determinism at any setting in this simulator — I predicted it would, and the notebook's verdict is computed at runtime rather than written in advance precisely so that it could contradict me, which it did. What actually happens is subtler and more useful:

Retry wins outright when the upstream step is already stable, and its advantage evaporates exactly as the problem gets hard. The plan gate is flat across the whole sweep, because it removes a cause rather than absorbing a symptom. That is the difference between a structural fix and a poultice — and it is completely invisible if you only ever measure at one setting, which is how almost everyone measures.

[DESIGN] Why a stub and not a live model. Season 1's labs are explicitly mechanism-first and "do not pretend a four-action bandit is an LLM". A simulator reproduces where variance enters and what removes it in seconds, free, with no key. It does not reproduce magnitudes. Nothing the notebook prints is evidence for Dhage's 1.000-at-N=100; that was measured on real models and only the paper can be cited for it. Cell 8 is the honest bridge — set two environment variables and the same measurement code runs against a real endpoint. The measurement does not change. Only the worker does.

Projects

Two builds, from nothing. No frameworks, no dependencies beyond the standard library. Both are the same idea pointed at very different consequences — and both were run before this section was written, so every number below is measured rather than predicted.

Project 1 — real life: the-grocery-slip

projects/01-real-grocery-slip/ · python3 measure.py 20

A weekly meal-plan-to-shopping-list generator. Nobody would think to write a specification for this, which is exactly why it is the right first build: you get to discover that your assertions are incomplete on something where being wrong costs nothing.

prompt version : slip-v4
conformance    : 0.700   (14/20 passed every assertion)
reproducibility: 0.450   (identical output share)

[EVIDENCE] Three things broke, and the README records each one before its fix.

Run 1 — my bug, not the model's. Conformance came back 0.000. Every run failed. The spec said 0 < qty <= 20 for every unit and the list contained 500 g of carrots. The bound was not too tight; it was applied at the wrong granularity — "one household for one week" is 5000 in grams and 20 in bunches, and one number for both is a category error wearing a constraint's clothes. Fixing it took conformance to 0.700. The very first thing a measured spec told me was that the spec was wrong, which is the normal case and the argument for running twenty times before trusting anything.

Run 7 — the hole this project exists to make you find. The list contained milk and Milk, in two different aisles, and every assertion passed. Each item was individually valid. The spec checked the elements and never the collection. It was complete about the wrong unit of analysis. My shopping list passed every test except shopping.

Run 11 — the temptation. The model produced a genuinely better list than the spec allowed, and the urge to loosen the assertion so that run would pass was strong. If the spec is wrong, change it deliberately, in its own commit, with the reason recorded. Never edit it to match one output you happened to like.

Project 2 — enterprise: the-change-ticket

projects/01-enterprise-change-ticket/ · make compare · make gate

An ITSM change-request router: free text in, structured routing decision out — risk tier, approver group, freeze-window flag. Six golden tickets, N=100 each.

[EVIDENCE] One variable changed:

                        WITHOUT plan gate      WITH plan gate
determinism                     0.510                 1.000
conformance                     1.000                 1.000
escalation_recall               1.000                 1.000

make gate exits 0. make gate with structured planning removed exits 1. That is the paper's headline reproduced on a different task — and note that conformance was already 1.000 without the intervention. Every individual decision was valid. They simply were not the same decision twice, which is the failure mode that passes every unit test you own.

Build it in 30 minutes — the contract

Everything the router needs, in the order an engineer will ask for it. Inputs: free text. Output: one Decision. Invariant: no decision is made until a plan has passed the schema. Stop rule: a rejected plan escalates; it is never retried.

PLAN_SCHEMA = {                       # the "to taste" step, given a shape
  "strategy":   enum["standard","expedited","emergency","reject"],
  "risk_tier":  enum["low","medium","high"],
  "freeze_hit": bool,
  "confidence": number in [0, 1],
}
def route(ticket, prompt_version):
    plan = model.plan(ticket)               # free text → structured plan
    if not validates(plan, PLAN_SCHEMA):    # 1 check, before ANY tool runs
        return escalate(ticket, "plan_rejected", prompt_version)  # no retry
    if plan.confidence < 0.60:
        return escalate(ticket, "low_confidence", prompt_version) # refusal path
    return decide(plan, prompt_version)     # deterministic given the plan

# CI gate (make gate): N=100 per golden ticket
#   determinism       == 1.000   (Decision.key() excludes decided_at)
#   conformance       == 1.000
#   escalation_recall == 1.000   (under-specified tickets escalate in ALL 100)
# any line below threshold → exit 1 → the build fails

What is deliberately missing from that block: retries on a rejected plan (they redraw the decision), a timestamp in the comparison key (it would make every run unique), and a live model (swap model.plan for any endpoint; the measurement code does not change).

[DESIGN] Four properties make this enterprise-shaped rather than a demo, and each earns its place:

• Structured Planning before any action. The plan is a choice from four approved routing strategies, validated upstream of the decision. Validating it afterwards only tidies the log.
• No retry on a rejected plan. A retry is a new sample; it redraws the plan, which redraws the decision. Rejection means escalate, not try again — and the notebook's sweep is the evidence, showing retry's benefit collapsing to +0.030 exactly where the problem gets hard.
• A refusal path enforced as an invariant. Two golden tickets are deliberately under-specified. Below a confidence floor of 0.60 the only legal outcome is escalation to a named human, and escalation_recall is gated at 1.000 requiring escalation to be unanimous across all 100 runs, not merely usual.
• The prompt version stamped on every decision row. An auditor asking why #4471 routed to platform in March needs a reconstructible answer, which makes the prompt part of the audit trail, which makes it a versioned artifact — this episode's thesis arriving from the compliance direction.

[DESIGN] One choice worth arguing with. Decision.key() deliberately excludes decided_at: a timestamp is provenance, not a decision, and including it would make every run trivially unique and the determinism metric permanently 1/N. Every determinism number has a choice like this buried in it. If you cannot say what your comparison key excludes and why, you are not measuring what you think you are.

[OPEN] What neither project proves. Both golden sets are synthetic and both workers are stubs by default. The enterprise build's honest status is runnable and gated, not deployed and measured. What would make it real: a golden set sampled from historical tickets with their actual routing outcomes, and an agreement rate reported beside determinism — because determinism without agreement is a router that is reliably wrong.

Same story, five exits

One spine, then a door for each reader. Take one decision and one action; leave the rest.

Reality Mission

Fifteen minutes, on something you already run this week.

1. Pick one prompt you depend on — a real one, in something you actually use.
2. Before you look at any output, write down what its output must satisfy. Fields, types, enum values, length bounds. Aim for ten assertions. You will find this much harder than expected, and that difficulty is the finding.
3. Run it 20 times. Count assertion failures. Write the number down.
4. Find the single place in the pipeline still emitting unconstrained free text — your "season to taste". There is almost always exactly one, and it is almost never where you expect.
5. Give that one step a schema. Re-run 20 times. Compare.

If step 4 turns up nothing because your pipeline is one call with no plan step, you have learned something more useful: you are not yet on this ladder at all, and the next episode is for you.

Research Challenge

Hand this to an agent and pre-register the prediction before it runs — a result you did not predict is a result you will rationalise.

Replicate the structure of arXiv:2608.26197 at small scale. Take one task with a checkable output. Establish a baseline Reproducibility Rate and Determinism Index over N=100 at fixed settings. Then apply exactly one intervention at a time, in a randomised order: (a) schema-validate the plan step, (b) force tool selection, (c) bound retries, (d) add output validation. Report the marginal effect of each on both determinism and task success, plus token cost and latency.

Pre-register: which single intervention carries most of the effect, and whether latency moves in the same direction for two different models.

The paper's own answer is that structured planning carries it, and that latency splits by model — one faster, one markedly slower. Predict before you check. If you reproduce a different ordering on your task, that is a publishable disagreement with a three-week-old paper, not a bug in your setup.

What moved

State of this rung at press time. Generated from a live weekly feed sync across 30 pioneer sources in research-anything (make watch-sync), ranked by technical signal and never by audience reach.

Sync date: 2026-09-03.

• arXiv:2608.26197 (2026-08-25) — the empirical study this episode is built on. Three weeks old at press time.
• arXiv:2608.21156v2 (revised 2026-08-26) — the survey that names the five-rung ladder, including the context rung the popular four-label list omits.
• Simon Willison (2026-09-02) — Claude's new system prompt really doesn't want to reproduce song lyrics: system prompts remain the most-read, least-versioned artifacts in the industry.
• Older but load-bearing: arXiv:2401.14423 Prompt Design and Engineering; arXiv:2503.02400 Promptware Engineering; Lilian Weng's Prompt Engineering (2023-03-15), still the clearest single survey of the rung's techniques.

[OPEN] What has not moved: nobody has published a replication of arXiv:2608.26197. A single-author, single-paper result on two synthetic tasks is the entire empirical basis for this episode's central claim, and it should be read that way until somebody repeats it.

Exit test

Check yourself without scrolling up.

1. Name the five published rungs in order, and say which one the popular four-label list leaves out.
2. What is the difference between Reproducibility Rate and Determinism Index, and why can a system score 1.000 on both while being useless?
3. In arXiv:2608.26197, a first-pass harness made reproducibility worse in how many of four cells — and what single change fixed it?
4. Why does the notebook use a stub instead of a real model, and what specifically does that stub not license you to claim?
5. You are told a pipeline is fully deterministic because temperature is 0. Give three reasons that does not follow.

Cliffhanger

You write the perfect recipe card.

Every quantity bounded and checkable. Every reason stated, not just every rule. The one "to taste" replaced with a number. You run it a hundred times and the Reproducibility Rate reads 1.000, and for one afternoon you believe you have solved the kitchen.

Then you hand the same card to the same cook on Friday night instead of Tuesday morning.

You get a different dish.

Nothing on the card changed. Nothing about the cook changed. What changed is what was on the counter when the cooking happened — last night's half-used sauce, another table's order still clipped to the rail, a jar somebody left open next to the salt.

The card was never the only thing in the kitchen.

Episode 2 — The Pantry. The rung the four-label list skips, the one the published ladder puts second, and the one where the most expensive failure in production agents currently lives.

Read next

• The Order Ticket — Season 6, episode 1 — the same rung argued rather than built, and the season that found the nest diagram does not survive contact
• The Governor — Season 6, episode 3 — why none of these five labels can express stability, and the 1877 criterion that could

Episode 1 of Intelligence Engineering Adventures, Season 7 — The Kitchen Ladder. Claims in the series source are tagged by class — definition, derivation, evidence, engineering choice, open question — and a metaphor may introduce a claim but never serves as evidence for it. Every episode ships a Colab notebook that runs on the free tier with no API key, plus two applications built from nothing — one personal, one enterprise-shaped. The ladder is Feng et al.'s (arXiv:2608.21156), not mine. The "what moved" section is generated from a live weekly feed sync of 30 pioneer sources, ranked by technical signal and never by audience reach. This article contains no material from any employer or client. — Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app

References

1. Feng, Y., Xiang, Z., Yang, C., Ma, Q. (2026). Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence. arXiv:2608.21156v2, revised 2026-08-26. — the five-rung ladder, quoted verbatim in "The ladder is not mine".
2. Dhage, S. (2026). Harness Engineering for Predictable Agentic Systems: An Empirical Study of Deterministic Execution Constraints. arXiv:2608.26197, 2026-08-25. — the 1-of-4 / 2-of-4 first-pass result, the trace-level diagnostic, and Structured Planning reaching 1.000 at N=100 in three of four cells.
3. Chen, B., Zhang, Z., Langrené, N. et al. (2023). Unleashing the potential of prompt engineering for large language models. arXiv:2310.14735. — technique survey.
4. Amatriain, X. (2024). Prompt Design and Engineering: Introduction and Advanced Methods. arXiv:2401.14423.
5. Chen, Z., Wang, C. et al. (2025). Promptware Engineering: Software Engineering for Prompt-Enabled Systems. arXiv:2503.02400. — the "a prompt is a software artifact" argument in full.
6. Weng, L. (2023). Prompt Engineering. lilianweng.github.io, 2023-03-15. — and note the same author's Harness Engineering for Self-Improvement (2026-07-04): one writer, three rungs, seven years.
7. Willison, S. (2026-09-02). Claude's new system prompt really doesn't want to reproduce song lyrics. simonwillison.net.
8. Brown, T. B., Mann, B. et al. (2020). Language Models are Few-Shot Learners. arXiv:2005.14165. — the 2020 landmark in the history table.
9. Reynolds, L., McDonell, K. (2021). Prompt Programming for Large Language Models: Beyond the Few-Shot Paradigm. arXiv:2102.07350.
10. Liu, P., Yuan, W. et al. (2021). Pre-train, Prompt, and Predict: A Systematic Survey of Prompting Methods in Natural Language Processing. arXiv:2107.13586.
11. Wei, J., Wang, X. et al. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903.
12. Wang, X., Wei, J. et al. (2022). Self-Consistency Improves Chain of Thought Reasoning in Language Models. arXiv:2203.11171.
13. Kojima, T., Gu, S. S. et al. (2022). Large Language Models are Zero-Shot Reasoners. arXiv:2205.11916.
14. Willison, S. (2022-09-12). Prompt injection attacks against GPT-3. simonwillison.net.
15. Khattab, O., Singhvi, A. et al. (2023). DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines. arXiv:2310.03714.
16. Shinn, N., Cassano, F. et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366. — loop-engineering landmark in the series table.
17. Wu, Q., Bansal, G. et al. (2023). AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. arXiv:2308.08155. — graph-engineering landmark in the series table; LangGraph: github.com/langchain-ai/langgraph.
18. Anthropic (2024-12-19). Building Effective AI Agents. anthropic.com/engineering. — harness-engineering landmark in the series table.
19. Anthropic (2025-09-29). Effective context engineering for AI agents. anthropic.com/engineering. — context-engineering landmark in the series table.
20. Prompt-engineering guides described (not quoted) in the history table: Anthropic · OpenAI.
21. Intelligence Engineering Adventures, Season 6 — The Governor Engine, episodes 1 and 3, for the argument that the nesting diagram does not survive contact and that no label here can express stability.