If you follow my substack, you may know I have talked a lot about harness engineering in the past.
If you follow my substack, you may know I have talked a lot about harness engineering in the past. The following are just examples:
Join My Live “Hands-On Harness Engineering with Claude” WorkshopThe Claude Code Leak: 10 Agentic AI Harness Patterns That Change Everything
The reason for this article is to revisit the concept, and I argue that Harness Engineering is the Umbrella Discipline for Agentic AI development and workflow.
Let us trace the evolution of the terminologies.
First, everyone was talking about Prompt Engineering — finding the exact sequence of words to steer a model. Soon after came **Context Engineering **(RAG and token optimization), followed by Loop Engineering (ReAct and self-correction cycles). Then Graph Engineering took over as the hottest topic, as teams moved from single agents to multi-agent systems. And now I want to put a name on the next piece of this puzzle: Memory Engineering.
I should be upfront that Memory Engineering is not (yet) an industry-standard term. As far as I can tell, I am coining it here. But given how the last four terms played out — each one showing up right when the community needed language for a problem it was already solving in practice — I expect this one to catch on too. Long-term, persistent state across sessions is already the open problem every serious agent builder is fighting with; it just doesn't have a name yet.
Figure 1 shows the order these terms entered the community's vocabulary, ending with Memory Engineering as the newest addition. Each term did not replace the one before it — it named a new layer of the same underlying problem as agents got more capable and more autonomous.
Figure 1: The Buzzword Timeline
It is easy to view this constant stream of terms as mere marketing buzzwords. But they reflect something real: the community's rapid shift from writing clever text prompts to building complex, autonomous systems.
More importantly, there is a unified, durable concept that brings all of these ideas together: Harness Engineering.
In traditional IT, software engineering provided the architecture, control flows, and execution environments needed for code to run predictably.
In the agentic era, foundation models act as probabilistic reasoning engines. But a bare reasoning engine cannot run safely or reliably in production on its own. It needs something around it.
The agent harness is that surrounding software infrastructure — the control plane, memory systems, runtime environment, and guardrails — that enables a probabilistic model to work reliably.
Figure 2 shows Harness Engineering as the umbrella discipline, with the five techniques hanging underneath it as specializations, not competitors. None of them stands alone; each is a piece of the same control plane.
Figure 2: Harness Engineering as the Umbrella Discipline
Just as traditional software engineering encompasses frontend, backend, and database management, Harness Engineering serves as the primary discipline. The individual terms represent specialized technologies and sub-disciplines within it:
Prompt Engineering: structuring core system instructions, personas, and output schemas.
Context Engineering: dynamically managing token windows, dynamic context injection, and state.
Loop Engineering: designing execution feedback loops that let agents inspect tool outputs and retry.
Memory Engineering: managing short-term working state and long-term persistent storage across sessions. This is very different from context engineering, which focuses on the current active session.
Graph Engineering: structuring multi-agent orchestration, routing, and task topologies.
The parallel to pre-agentic software is close enough to be useful, not just decorative.
Figure 3 places the two eras side by side. Software Engineering specialized into frontend, backend, databases, and infrastructure as systems got more complex. Harness Engineering is going through the identical process right now, specializing into the five techniques above as agents get more autonomous.
Figure 3: The Software Engineering Analogy
These five terms are not abstract categories — each one owns a specific point in an agent's execution path. Figure 4 traces a single agent turn and marks where each technique does its work.
Figure 4 follows one pass through the loop: prompt engineering shapes what goes into the model, context engineering governs what's in the window when it runs, loop engineering decides whether a tool result triggers a retry, memory engineering is what survives after the window closes, and graph engineering is what happens when a single loop is no longer enough and the work fans out to more than one agent.
Figure 4: Where Each Technique Acts in the Agent Loop
Treating these concepts as isolated tricks leads to fragmented system architecture. Reframing the problem around Harness Engineering keeps the focus where it belongs: on sound software architecture.
Figure 5 shows what happens when teams chase each buzzword independently versus when they treat all five as parts of one deliberately designed system. Isolated tricks are fragile and hard to maintain because nobody owns the interactions between them. A unified harness is testable and reusable because the interactions are the design, not an afterthought.
Figure 5: Fragmented Tricks vs Unified Architecture
The ultimate goal isn't just to write a better prompt or tweak a single loop — it's to build a robust software harness that makes autonomous agents reliable at scale.
While all of these technologies play a vital role in the harness, Graph Engineering has quickly emerged as the central topic of discussion as teams move toward multi-agent systems and enterprise-scale workflows.
To address this growing focus, I am currently working on a detailed research report dedicated specifically to Graph Engineering.
Figure 6 previews where this is headed.
Figure 6 marks this post as the first of two: this one establishes Harness Engineering as the frame, and the next one goes deep on Graph Engineering specifically — how graph-based architectures fit into the broader harness, how top teams are structuring complex workflows, and how to navigate the shift from single-agent loops to multi-agent topologies.
Figure 6: What's Coming Next
Stay tuned — the full report is coming soon.
For paid subscribers: the audit checklist. Everything above this point is free. Below is a five-item scoring checklist for auditing your own agent stack against prompt, context, loop, memory, and graph engineering, plus the dependency order to fix them in.
Send this story to anyone — or drop the embed into a blog post, Substack, Notion page. Every play sends rev-share back to Agentic AI.
We’ve simplified responses to 👍 / 👎. Past comments are archived but no longer visible.