Loading today’s stories
Build1 distinct publisher3 min readUpdated
A dev.to series argues "prompt engineering" is too narrow for agents: the package sent to the model is reassembled on every call, which makes it a runtime concern, not a file.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Part 5 of the Harness Engineering series on dev.to makes a narrow but load-bearing argument: "prompt engineering" is not wrong, it is just too small a name, because a prompt sounds like something you write once and ship while the payload an agent sends changes on every turn [1][4]. The consequence for anyone building one is that the thing you maintain is not a string in a repo but an assembly step that runs before every model call [5].
The author defines the Context as everything fed into the model on a given API call [2]. Concretely, that payload typically carries the system prompt, the conversation history, any retrieved documents, the tool definitions, prior tool results, attached files or images, and anything else the harness decides the model needs right now [3]. That is six named categories plus an open-ended slot [7]. All of it goes over the wire, the model reads all of it, produces one response, and then the harness assembles a new package for the next iteration of the loop, probably with the previous response added, maybe with new tool results, maybe with different retrieved content [5].
The mechanism underneath is unglamorous: the model is stateless, every API call is independent on the model's side, and nothing persists between calls unless something outside the model puts it there [6]. You cannot tell the model to remember what was said five minutes ago or to reference a file discussed earlier; every fact, message, result and document has to physically be in the payload for the current call or it does not exist [8]. Continuity is a property of your harness, not of the model.
Read as a systems statement rather than a naming quibble, this is where the engineering shows up. The author calls context engineering arguably the deepest discipline in the whole harness, and describes the actual work as deciding what to include, what to compress, what to leave out, and when [9]. Compression and omission only make sense against a finite budget, which is the practical shift: you are sizing and prioritising a per-call payload, not editing copy. Of the three moving pieces the piece names -- system prompt, history, retrieved knowledge [10] -- only the system prompt is described as staying roughly the same throughout the conversation, prepended to every turn to tell the model who it is and what tools it has [11]. So the stable, reviewable, version-controllable layer is one slot out of the several the payload carries [12]. The rest is decided at runtime, per turn, by code you wrote and probably do not inspect.
Two caveats. The excerpt supplied breaks off mid-sentence in the system prompt section, so the treatment of history and retrieval is not visible here [13]. And the author sells a Udemy course and a live Maven workshop on building a harness, both described as optional alongside the free series [14].
What to watch is whether the remaining parts get specific where this one is conceptual: the series lists the filesystem and environment, memory, observability, the overall architecture, and a teardown of Claude Code still to come [15]. Memory and observability are where a per-turn payload budget becomes measurable rather than rhetorical: eviction and compaction policy, and the traces that tell you what was actually in the context when the agent got it wrong.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The article calls context engineering arguably the deepest engineering discipline in the whole harness, and describes the work as deciding what to include, what to compress, what to leave out, and when, adding that there is no version to ship, only the version being assembled for the current call.
The article describes the system prompt as the top layer of the context, prepended to every turn and staying roughly the same throughout the conversation, telling the model who it is, what tools it has, and what good behaviour looks like.
dev.to published "Harness Engineering - Part 5: Context Engineering", part of a 10-part series described as a journey from raw language model to production-ready agentic system.
The article defines the Context as everything fed into the model on a given API call.
The article states that on any single turn the payload sent to the model typically includes the system prompt, the conversation history, any retrieved documents relevant to the current turn, the tool definitions, prior tool results, any attached files or images, and anything else the harness thinks the model needs to know right now.
The article says some readers know this territory as prompt engineering, that the name is not wrong but narrow, because a prompt sounds like something you write once and ship while the reality of running an agent is that the payload changes every turn; hence the term context engineering.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single self-published explainer, mechanics asserted not demonstrated
One source, one publisher, no code, benchmarks, telemetry, or third-party corroboration. The load-bearing mechanical claims (statelessness, per-turn payload assembly, finite context windows) are internally coherent and consistent with how chat-completion APIs are described, but within this cluster they rest entirely on the author's assertion. The strongest evaluative claim — that context engineering is the deepest discipline in the harness — carries no supporting measurement at all, and the supplied text is truncated before it completes its own three-part structure.
No adoption signal in supplied sources
The cluster contains no release, deployment, benchmark, pricing, licensing, usage-disclosure, or incident evidence. The article mentions that files such as AGENTS.md, .cursorrules and CLAUDE.md exist as a user-instruction pattern, but supplies no counts, users, projects, or dates, and nothing about uptake of the 'context engineering' framing or of the author's series and courses. Any adoption number here would be invented.
Mildly overstated: uncontroversial mechanics wrapped in a superlative and a rebrand
The underlying description of per-turn payload assembly under a stateless model is modest and almost certainly accurate, which keeps the gap small. The overstatement sits in the packaging: declaring context engineering 'arguably the deepest engineering discipline in the whole harness' and presenting 'context engineering' as a more accurate successor to 'prompt engineering' are positioning claims advanced with zero supporting evidence, inside an article that funnels readers to a paid course and workshop. The headline framing — stop treating your prompt as a shipped artifact — is therefore directionally sound but rhetorically ahead of what this cluster demonstrates.
Visible, disclosed commercial funnel from free series to paid training
The author sells two paid products on the exact subject of the article — a Udemy course, 'Build a Harness from Scratch', and a live cohort-based Maven workshop, 'Harness Engineering for AI Agents' — and promotes both inside the post while telling readers they are optional. The series structure itself (10 parts, roadmap of future installments including a Claude Code teardown) is a serialized audience-building mechanism. The incentive is openly disclosed rather than hidden, and no vendor, sponsor, or platform interest beyond the author's own is evident in the cluster, which caps the score below the top band.
Low: one truncated source, no corroboration
Confidence is limited by structure rather than by contradiction. There is a single publisher and a single article, the supplied body is cut off mid-sentence, and one ledger claim about where that truncation falls is contradicted by the body itself. Descriptive statements about what the article says are highly reliable; statements about whether its framing reflects broader practice cannot be assessed from this cluster at all.
build
Instrumentation Is the Whole Gap Between an Agent and an Agent You Can Run1 distinct publisher
build
Agents stall on tool surfaces, not models: tool design as an engineering discipline1 distinct publisher
build
Agent Memory Is Two Systems, Not One Dial With Scratch On One End1 distinct publisher
build
Your agent's blast radius is decided by the filesystem, not the prompt1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 15, 2026