Addendum on Concept Disambiguation: What Each 'X Engineering' Actually Means

Xiao A came across a job-title map inside his company: Prompt Engineer, RAG Engineer, Agent Engineer, AI Engineer, Context Engineer, Eval Engineer, Loop Engineer, Graph Engineer, Harness Engineer… He counted them, and felt he "seemed to have to know all of them" while also seeming to "be none of them." He took the map to Lao Z.

"Do these titles really mark different jobs, or is HR just inventing words?" Xiao A asked.

"Both." Lao Z said. "This appendix is a reference desk for Part I · Concepts and Part III · Build It — come back to it whenever a term touches the division of labor, a deliverable, or a way of verifying. Let me be clear up front: these names have no unified industry definition. Inside the same company, 'AI Engineer' may mean model fine-tuning, or it may mean application integration. The table below only compares the more common objects of attention. It neither reduces them to software engineering wearing a new name, nor elevates them into brand-new disciplines."

"One more principle before you read the table," Lao Z went on. "When you compare terms, compare their object of attention, their deliverable, and their verification method — not who ranks higher. Not one of these nine titles can govern the others: they manage different things, and they put the emphasis of verification in different places. Which one ranks higher is a question of organizational politics. This appendix answers only the conceptual question: what each X Engineering manages, how you accept it, and who it is easy to confuse with."

Xiao A tried to apply it to himself: "I don't have to ask which row to read. Whichever piece of work is in my hands — that's the row I read."

"Right, that is the most natural way to read it." Lao Z said. "What you are doing now is 'write prompts and tune the model,' so read the Prompt engineering and Context engineering rows. Doing 'run evaluations'? Read Eval engineering. Writing tools and loops? Read Agent engineering and Loop engineering. This table is built for finding your own row; you do not have to read it from beginning to end. Once you have located your row, take a quick look at how the neighbouring rows get confused."

Nine Statements of Account: What Each X Engineering Actually Covers

Lao Z had Xiao A first split the titles on the map into four columns: what it handles, what it produces, how you verify it, and who it is easy to confuse with.

Term	Primary Object of Attention	Common Deliverables	Verification Method	Easy to Confuse With
Prompt engineering	instructions, examples, output constraints	prompt versions, test sets	sample coverage, regression comparison	cannot replace permission checks
Context engineering	the material and state that enters the model	selection / compression / memory strategies	citation correctness, token and omission analysis	not the same as KV cache optimization
RAG engineering	ingestion, indexing, retrieval and citation	corpora, indexes, evaluation sets	recall, faithfulness, permission tests	not the same as "eliminating hallucination"
Agent engineering	the loop, tools, sessions and boundaries	tool contracts, state graphs, audits	task success, failure paths, safety tests	not the same as multi-agent
AI / LLM engineering	model service access and product operation	providers, observability, cost strategies	reliability, cost, quality evaluation	scope usually varies by organization
Eval engineering	quality measurement and its data	cases, rubrics, artifacts	reproducible runs, human / automatic judging	judge scores are not absolute truth
Loop engineering	loop control flow and state machines	stop reasons, checkpoints, turn budgets	failure paths, budget exhaustion, diagnosable aborts	not the same as any while loop
Graph engineering	nodes, edges and routing	workflow graphs, conditional branches, replay contracts	path coverage, deadlock detection, idempotency	not the same as a DAG library
Harness engineering	the assembly layer and the lifecycle	turn-socket wiring, session write ordering, extension events	assembly errors, persistence ordering, shutdown	not the same as a DI container

This table lists sources only for terms whose origin can be verified. Those with no clear source — such as AI / LLM engineering, whose scope varies by organization and which has no unified source — are left out, so that community usage is not dressed up as a definition. One more note: most of these terms have no ISO-style unified standard. What the table lists are the sources most widely circulated in the community and among authoritative bodies. The absence of a unified source does not mean the term has no meaning; it only means it is still evolving. Dates of emergence are rough estimates based on verifiable sources (paper publication, guide release, the originator's original post). The ordering between newly coined terms is not precise; the ranking only shows the rough sequence in which they appeared.

Term	Approximate Emergence	Community / Authoritative Source (Verifiable)
RAG engineering	2020	Lewis et al., "Retrieval-augmented generation for knowledge-intensive NLP tasks" (NeurIPS 2020, the original paper); the Gao et al. 2023 survey (arXiv:2312.10997)
Prompt engineering	around 2022	PromptingGuide.ai, "Prompt Engineering Guide" (the community's authoritative guide); the official prompt engineering guides from Anthropic and OpenAI respectively
Eval engineering	around 2023	the OpenAI evals open-source framework and its community docs; LLM evaluation community surveys (such as the evaluation docs of DeepEval and LangSmith)
Agent engineering	2024	Anthropic, "Building Effective Agents" (Erik Schluntz, Barry Zhang, 2024-12), which distinguishes workflows from agents; the agent engineering docs from OpenAI and LangChain
Context engineering	2025	the concept was put forward by Tobi Lütke and Andrej Karpathy on X (formerly Twitter); the IBM Think "Context engineering" feature article; a Thoughtworks Technology Radar entry; arXiv, "Context Engineering 2.0" (2025)
Harness engineering	around 2025-2026	proposed by Mitchell Hashimoto (co-founder of HashiCorp); OpenAI, "Harness Engineering: Leveraging Codex in an Agent-First World"; CMU et al., "Agent Harness Engineering: A Survey"
Loop engineering	around 2025-2026	an emerging community concept, in community articles such as "What Is the Agent Loop? Why? How?"; David Khourshid's statement that "a loop is a graph"
Graph engineering	around 2025-2026	the state-graph docs of LangChain / LangGraph; David Khourshid's statement that "a loop is a directed cyclic graph"; community articles (such as "Loop Engineering and Graph Engineering")

"This table has one more dimension than the last one: 'source'." Xiao A said. "Can every term be traced back to some author or organization?"

"Yes, but you have to read them as two kinds." Lao Z said. "Some have an original source. RAG traces back to the Lewis 2020 NeurIPS paper, and the distinction between Agent and Workflow traces back to that Anthropic piece, 'Building Effective Agents'. You can cite those with confidence. Others are community usage only — Loop and Graph, for instance. When you cite those, say 'this is community usage, not a standard definition'; don't pretend there is an authoritative one. For a term like AI / LLM engineering that has no unified source at all, simply don't cite it as a definition: a team can agree on one reading internally, but out loud don't say 'the official definition of this word is…'. If you really must put it in an article or on a résumé, say instead 'I use this word as one particular article defines it'."

"What is the relationship between the working definitions in this book and these community sources?"

"The community sources are the reference baseline; this book adds one layer of engineering constraint on top of it." Lao Z said. "A community definition answers 'what does this word usually refer to'. The terminological landing points in this book answer 'in the context of this project, what do we use this word for, and what is it not'. The two levels do not conflict: first know the community's usual usage, then state this book's convention. That way you neither drift from the community nor leave the definition vague. Where they disagree, defer to the verifiable source rather than arguing from impression."

Xiao A scanned the table across the rows: "Of these columns, which one best separates a real job from a fake title?"

"The verification-method column." Lao Z said. "The object of attention and the deliverable can both be dressed up in marketing language. 'How do you prove it was done well' is very hard to fake: RAG has to be tested for recall and faithfulness, Agent for task success rate and failure paths, Eval for reproducibility. If a title cannot say how you prove it was done well, it has not grown into a job yet. It is only a name."

Xiao A pointed back at the table: "Within one row, what is the relationship between these four columns?"

"The first three are scope; the fourth is acceptance." Lao Z said. "What it handles, what it produces, how you verify it — those define how large an area you own. What it is easy to confuse with marks the traps on the boundary. Scope is a static description; acceptance is a dynamic action. When an engineer reads the table, they scan the verification column first, because that decides whether you sleep well after you ship."

"Can I take this table and match myself to it in front of an interviewer?"

"You can, but one usage needs care." Lao Z said. "The table helps you describe what you did; it does not help you argue with an interviewer about the definition of a role. Saying 'I worked mainly on Agent engineering, including the boundaries between Loop and Tools' describes your responsibilities, and that is useful. Saying 'by your own definition this isn't Agent engineering' argues about definitions, and that is not. Inconsistent definitions are the normal state. What you can do is translate your own responsibilities into terms the other person understands, not correct their terms."

Do All These Words Cover the Same Batch of Work?

Xiao A stared at the table for a long time. "The Prompt row manages instructions, the Context row manages material, the RAG row manages retrieval — however you look at it, they all orbit the model. These nine rows aren't the same batch of work split into nine pieces, are they?"

Lao Z: "There will be overlap, and overlap is the normal state. One RAG product simultaneously needs data engineering (ingestion and indexing), model engineering (provider access), application engineering (the session loop), and security engineering (permission audits). The difference usually lies in what a team treats as its primary risk and its deliverable — not in some authoritative boundary that exists somewhere."

"Is the 'easy to confuse with' column there specifically to handle this overlap?"

"Right. That column puts the confusion on the table first, and then we can talk about the division of labor." Lao Z said. "For instance, the table says 'Context engineering is not the same as KV cache optimization'. That line draws a conceptual boundary and a performance boundary: Context engineering manages 'what the model sees', KV cache manages 'how computation gets reused'. The former decides correctness; the latter decides speed. Keeping the two in separate columns is what stops you from answering a discussion about 'the context got longer' with a cache hit rate."

Lao Z gave an analogy: "It is like 'front end', 'back end', and 'full stack'. The overlap between those three words is larger than the job description at any company, yet you would not therefore say they are the same role. The various X Engineerings are the same: different concerns, different tools, different acceptance criteria. That the code they touch intersects does not mean they are the same thing."

Xiao A flipped back to the table: "Which two rows overlap in the way most likely to cause trouble? Can you see it at a glance?"

"You can. Watch the rows where the 'easy to confuse with' column is longest." Lao Z said. "Everywhere it says 'not the same as' is a confusion that has really happened — that is the pothole. Take 'RAG engineering is not the same as eliminating hallucination': it tells you the two are routinely drawn as an equals sign. Draw that equals sign, and you will start accepting retrieval recall as the hallucination rate, and you will do both metrics badly."

Xiao A pressed: "When does this overlap actually become a problem?"

"When it blurs where responsibility sits." Lao Z said. "The boundary between prompt and context is exactly like that: a prompt is 'what instructions I wrote', context is 'what I let the model see'. Both go into the same request. When the model answers wrongly, whose fault is it? If the prompt was written crookedly, that is Prompt engineering's business. If a stale file got stuffed into the context, that is Context engineering's business. The criterion is not who edited that piece of text; it is whether the root cause of the error sits in the instruction or in the material. Overlap by itself causes no trouble; overlap that nobody claims does — then a fault appears and everyone points."

"Let me give you a concrete way to ask," Lao Z said. "Delete this piece of text: does the error disappear, or does it stay? If what you deleted was an instruction, the error lives in the prompt. If what you deleted was material, the error lives in the context. Attributing cause with a deletion experiment is far faster than debating in a meeting 'who owns this text', and the conclusion is reproducible."

Xiao A picked it up quickly: "So if RAG answers wrongly, I delete the retrieved corpus passages and try again?"

"Right. Delete one thing, watch the result." Lao Z said. "If the error remains, the problem is in generation, not retrieval. If an Agent behaves wrongly, delete one tool; if the behavior changes, that tool was a participant. This line of thought applies to every overlap region, because it depends on no term definition — only on a reproducible comparison."

One Example: Same Repository, Nine Lenses

Lao Z set Xiao A a problem: take pi-mono as the specimen and fit each of the nine lenses onto it in turn. All citations below are marked against this book's Part II · Pi in Source baseline (upstream pi, tag v1.0.0, commit a13d35a7), so you can verify them in the matching snapshot:

• Prompt engineering lens: look at how the system prompt is assembled (base rules + tool descriptions + project material + task), how it is versioned, and how it is probed with tests. Source: packages/coding-agent/src/core/agent-session.ts (prompt assembly within the session).
• Context engineering lens: look at how buildContextEntries selects messages, how compaction summarizes, and how trim cuts. Source: buildContextEntries in packages/coding-agent/src/core/session-manager.ts, completeSummarization in packages/coding-agent/src/core/compaction/compaction.ts.
• RAG engineering lens: look at how skills are discovered and loaded (though pi's skills are closer to instruction packages than to classic RAG). Source: loadSkills in packages/coding-agent/src/core/skills.ts.
• Agent engineering lens: look at how runAgentLoop drives state, how tools execute, and how the stop reason is decided. Source: runAgentLoop in packages/agent/src/agent-loop.ts, Agent in packages/agent/src/agent.ts.
• AI / LLM engineering lens: look at how ModelsImpl connects providers, how authentication gets merged, and how cost is controlled. Source: ModelsImpl in packages/ai/src/models.ts, resolveProviderAuth in packages/ai/src/auth/resolve.ts.
• Eval engineering lens: look at how the evaluation harness builds a temporary environment and collects artifacts, and how the doc-comparison experiments are paired. Source: createPiCodingAgentHarness in packages/evals/src/harness.ts, src/report.ts.
• Loop engineering lens: look at the two-layer loop (the steer/followUp queues plus tool execution), checkpoints, and abort. Source: runAgentLoop in packages/agent/src/agent-loop.ts, the getFollowUpMessages queue and the finishTurn socket.
• Graph engineering lens: look at the branch tree of session fork and the checkpoints of compaction. Source: createBranchedSession in packages/coding-agent/src/core/session-manager.ts, packages/coding-agent/src/core/compaction/compaction.ts.
• Harness engineering lens: look at how the host wires session writes, compaction, extensions, and request projection onto the sockets of the loop. In v1.0.0 the experimental AgentHarness was deleted from pi-agent-core, so this assembly layer now sits in the product layer. Source: the AgentSession constructor and the _install* methods in packages/coding-agent/src/core/agent-session.ts.

"Among the nine lenses, several will especially make people feel they are looking at the same file." Lao Z said. "Loop engineering and Agent engineering, for example, both land on agent-loop.ts. The first looks at 'how the loop turns' (the state machine, the stop conditions, the abort); the second looks at 'how the Agent runs as a whole' (the session, the tools, the boundaries). Overlapping files do not mean overlapping concerns. Two people staring at the same piece of code — one caring about its transition conditions, one about its external contract — are doing two jobs, not duplicating one."

"Turn it around, and different files can still belong to the same lens." Lao Z said. "The verification method of Eval engineering is spread across the harness, artifact collection, and the paired report — the same lens landing in different files. You judge a lens by its object of attention and its verification method, not by a file path. That is also why this appendix cuts by 'lens' rather than by 'module': a module is how the code is organized, a lens is how the concern is organized, and the two do not map one to one."

"There is one more practical use: during troubleshooting, take a lens as a filter." Lao Z said. "When something breaks, ask first which lens it belongs to. Is the prompt written wrong (lens one), did the context get selected wrongly (lens two), or did the loop judge the stop wrongly (lens seven)? Pin the lens, and your search range shrinks from the whole repository to one direction. It is the same logic as 'locate the layer first' in an incident runbook — except that here you locate a lens."

"So these terms are not mutually exclusive jobs. They are different cross-sections of one system." Lao Z added one line. "The layering of pi-mono only describes how this one repository is organized. It cannot prove that these terms mean the same thing in every organization."

Xiao A asked: "Of the nine lenses, is one of them a precondition, with all the others built on top of it? My guess is Loop engineering — if the loop can't turn, everything else is pointless."

"Your guess has reason behind it, but that is not the answer." Lao Z said. "The closest to a precondition is Harness engineering. It manages the assembly layer and the lifecycle: turn-socket wiring, session write ordering, extension events. Assemble it wrong and the other eight lenses cannot run at all; assemble it right and they finally have something to look at. That does not make it higher-ranking. It only makes it the foundation lens: a foundation is inconspicuous, and when it collapses nobody stays standing. Order the lenses as 'assembly → loop → tools → context → model → evaluation', and what you get is not just nine cross-sections but a reading route sorted by dependency."

Xiao A asked: "If you have all nine, is that roughly equal to a 'full-stack Agent engineer'?"

"What you have gathered is a set of skills, not one role." Lao Z said. "One person can know all nine, but inside a team he is usually primarily accountable for only one or two of them. 'Full stack' describes breadth, not the scope of accountability. Someone who understands all nine is most valuable during troubleshooting; someone accountable for all nine is most miserable at acceptance time."

The Reader's Original View: Are These Just Software Engineering Under New Names?

Xiao A remembered his very first question: "I might as well tell you — when I first saw that job-title map, what I muttered to myself was 'isn't this just the work we do every day?' Having read through these tables, does that thought still stand?"

Lao Z laughed: "Half right, half wrong."

• The part that is right: the methods they use (version control, testing, code review, CI, monitoring, incident post-mortems) really are the general methods of software engineering. Prompt engineering needs regression tests, RAG engineering needs evaluation sets, Agent engineering needs failure-path tests. In this respect there is no essential difference from traditional software engineering.
• The part that is wrong: but the objects they handle are different. Software engineering handles deterministic code; these X Engineerings handle probabilistic model behavior. A model hallucinates, drifts, and changes across versions. That is a non-determinism traditional software engineering rarely faces, so the testing methods, the monitoring metrics, and the attribution of incidents all have to be adjusted.

"Look at the right half first." Lao Z said. "Not one method you have learned was wasted. Version control, testing, review, CI — these are the shared foundation of all engineering. In the new jobs, the foundation is all old; everything that must change is in the upper layers. So when you meet a new X Engineering, the first step is always to ask 'which methods carry over as is'. Rule out the unnecessary new problems first, then discuss where things genuinely differ."

Xiao A asked: "In the 'wrong half', what is the first thing that needs adjusting?"

"The standing of regression testing." Lao Z said. "In traditional software, a regression test means 'I changed the code; confirm I did not break an old feature'. It is insurance, not the main body. In a probabilistic system it becomes the main body: every model update and every prompt change has to trigger a run over the coverage sample set, to confirm nothing moved backwards. If you cannot make that turn, every engineering measure after it loses its baseline."

Lao Z pointed out one more, subtler difference: "The definition of 'fixed' changed. In traditional software, 'fixed' means this bug no longer appears. In the model world, 'fixed' usually means the error rate on this class of samples went down — and an error rate is a statistic, not a truth value. You are facing a system that can only say 'right most of the time', so you have to accept 'good enough'. That is not a compromise; it is decided by the nature of the object itself." Xiao A wrote "fix in the statistical sense" into his notes.

Lao Z unfolded the word "probabilistic": "A bug in traditional software has a definite reproduction path: same input, same output, and once fixed it is fixed. A model is not. The same prompt answers correctly this time and wrongly next time; you change the prompt and fix one class of samples, while possibly breaking another class at the same time. So 'it worked on my machine' supports no conclusion. What you need is 'I ran a coverage sample set and the before-and-after comparison shows no regression'."

"And what does 'probabilistic' do to troubleshooting? A traditional bug has a stack trace. A model error has none."

"Right — that is the watershed in how you view troubleshooting." Lao Z said. "An error in traditional software can be followed step by step to the root cause: stack traces, breakpoints, and data flow all locate it. A model's 'error' is usually just 'this output is wrong'. No stack trace — one sample, that's all. What you can do is turn 'one wrong' into 'a set of samples wrong': run it several times and see whether it is a systematic bias or a one-off fluctuation. A one-off fluctuation may be right on the next run; a systematic bias means changing the prompt or changing the material. Without a sample set, you cannot even tell whether this is a bug or luck."

"Are there other traditional practices that 'probabilistic' changed?"

"Monitoring metrics and incident post-mortems." Lao Z said. "A traditional service watches error rate and latency. An Agent service also needs behavior metrics — tool-call success rate, turns per task, the distribution of stop reasons. Post-mortems change too: a traditional incident asks 'which line of code was written wrong'; for an Agent incident the answer is often 'that class of sample was never covered'. The first locates code; the second locates samples and prompts. Force the code lens onto a probabilistic system and each post-mortem leaves you more confused."

"So the more accurate statement is," Lao Z summarized, "that they are software engineering extended to face a probabilistic system, not software engineering renamed. The methods are still those methods, but the object changed — so the acceptance criteria, the testing strategy, and the definition of quality all have to be recalibrated."

Xiao A asked: "For someone coming over from traditional software engineering, what is the first new skill to learn?"

"The first thing to learn is not a framework. It is the mindset of accepting uncertainty." Lao Z said. "In traditional engineering, 'certain' is the default: the same code produces the same result, and a bug is the anomaly. In model engineering that is inverted: 'uncertain' is the default, the same prompt differs slightly every time, and a stable hit is the anomaly. The first lesson for someone transferring over is to replace 'why is it different again' with 'on which dimension is it different this time'. The first is a complaint; the second is an analysis. Once the mindset turns, the tools — sample sets, evaluations, regression — are the things you can actually pick up."

Four Questions for Any New Term

Xiao A asked: "So when a new X Engineering shows up later, how do I judge whether it is genuinely new?"

Lao Z gave four questions:

1. What inputs and state does it handle? The prompt? The context? The retrieval corpus? The loop state?
2. What artifact does it produce? A prompt version? An index? A tool contract? An evaluation set?
3. How does it verify? Sample coverage? Recall? Task success rate? A reproducible run?
4. Who bears the failure? The prompt author? The data team? The Agent engineer? Operations?

"The answers to these four questions guide implementation better than the label does." Lao Z said. "If all four answers coincide with some existing term, it is most likely a marketing coinage. If at least one answer is plainly different, it deserves to be treated on its own. The value of disambiguation is exactly here: it forces you to answer what extra acceptance item and what extra responsibility this new term actually adds for you. Answer it, and it is real. Fail to answer it, and it is an old job in a new skin."

"Of the four questions, the fourth is the one people most often cannot answer." Lao Z said. "The first three are descriptive — a product document can answer them. The fourth is about responsibility: it takes a named owner inside the organization. If nobody on the team can say 'whose is it when this goes badly', then this term's boundary is hollow: the work flows, and nobody claims the responsibility. The more clearly the fourth question is answered, the more real the division of labor."

Xiao A asked: "When all four answers coincide with old terms, is there still a question of degree? Does it take a 100% overlap to count as a coinage, or does partial overlap already warrant caution?"

"It depends which answer overlaps." Lao Z said. "If the first three overlap, it is technically old — the same thing renamed — and you should be wary. If the fourth overlaps, the organization added no responsibility: nobody new has to answer for a new result. Be wary then too. Turn it around: as soon as the fourth question yields 'one additional owner and one additional acceptance item', the term deserves to be treated as a new division of labor even if the first three answers are all old."

"For the same new term, do you use the four questions the same way in an interview as at work?"

"No." Lao Z said. "In an interview, the four questions are an expression tool: use them to describe what you did, so the interviewer sees real competence in your description. At work, the four questions are an audit tool: check whether a new term is old work in a new skin, and whether it chopped responsibility into pieces nobody holds. Use the first to introduce yourself, the second to audit a term. Don't swap them."

Xiao A mused: "So if I coined a term myself — say 'Boundary Engineering' — the four questions would be a test on me too?"

"Right. That is the sharpest use of the four questions." Lao Z said. "Ask yourself before coining: what inputs do I handle? What do I produce? How do I verify? Who bears the failure? Answer all four, and you are coining a real division of labor. Fail all four, and you are coining vocabulary for a slide deck. These questions help you see through other people's marketing terms from the outside, and from the inside they hold back your own urge to coin terms."

Back to the goal of the whole book: new terms will keep appearing. With these four questions in hand, you can tell for yourself which are real objects of attention and which are only recruitment copy.

Xiao A pinned that job-title map back into his notebook. This time he did not first ask "which title do I belong to." He ran the nine titles through the four questions, one by one. The titles were still the same nine; the questions had changed. The next time someone hands him a new job-title map, he knows where to start asking.