@nicos_ai: Prompt engineering → context engineering → harness engineering → loop engineering → graph engineering: The list keeps g…

Prompt engineering → context engineering → harness engineering → loop engineering → graph engineering: The list keeps growing, and each new term is usually treated as if it replaces the previous one. But the reality is different: each layer envelops the previous one. The simplest way to differentiate them is to ask what their unit of work is. Prompt engineering is the message The model remembers nothing before that call, so the prompt has to contain everything necessary: the role, the context, the instructions, some examples, and the output format. If the result isn't what's expected, the key is to discover which element is missing or failing, not to rewrite the entire prompt over and over. The unit of work is a single input. Context engineering is the memory Across multiple steps, the context window is limited, but the available information isn't. That's why a selection process is needed. That process consists of keeping what's important, summarizing what's useful but bulky, and discarding the rest. A good context doesn't consist of stuffing in more information, but of knowing what to eliminate. The unit of work is what remains within the context window. Harness engineering is the machine On its own, a model only generates text. The harness handles gathering the necessary information, running the model, calling tools or subagents, and verifying the result through tests or an evaluator. That verification step is, to a large extent, what differentiates a simple API call from an AI agent. The unit of work is a complete execution of the machine. Loop engineering is the iterative execution A single execution rarely solves the entire problem. A mechanism is needed to decide whether the machine should run again. For that, you need a goal defined from the start, limits like a maximum number of iterations or a cost budget, and an automatic criterion that determines when the task has truly ended. An agent stopping its requests for tools doesn't mean it's completed the work; it just means it's finished that turn. The unit of work is the entire cycle execution. Graph engineering is the coordination When multiple loops have to work together, you need to define what runs, when it runs, what can be done in parallel, and which components oversee others. The nodes do the work, the connections (edges) decide what happens next, and the shared state flows between them. In fact, a single loop is nothing more than a graph of one node with a connection pointing back to itself. That's why graphs organize loops, rather than replacing them. The unit of work is the complete process. The relationship between all these layers is straightforward: The prompt and the context live within the harness's gathering phase. The harness executes a full pass. The loop decides if that pass should be repeated. The graph decides which loops run and how they coordinate with each other. The broader your perspective, the larger the unit of work. The deeper you go, the more you return to the prompt. And that also indicates where to debug a problem: identify which layer has failed based on its unit of work and fix that layer. The prompt is the easiest part to modify, which is why it often gets blamed for errors that, in reality, originate three levels higher up. In the article below, it explains what graph engineering is, covering the main idea, how to get started, how to manage shared state, how to create reliable routing, and when using a graph is really worth it. If you want to stay up to date, read it next