The Six Layers of GenAI Engineering

GenAI engineering now has six distinct layers.

That sounds like category inflation until you examine the problems each layer solves. Prompting, context, tools, iteration, workflow structure, and runtime authority are related. They are not interchangeable.

The six layers are:

1. prompt engineering
2. context engineering
3. harness engineering
4. loop engineering
5. graph engineering
6. runtime engineering

These are not six maturity levels. They are six different system problems. A product can span several at once, and the boundaries overlap.

If you do not know which layer owns the problem, you will keep rewriting prompts to fix a runtime bug. This is a popular strategy, but it’s not an especially successful one.

1. Prompt engineering frames the request

Prompt engineering became mainstream during the ChatGPT boom in 2023 because model behavior was highly sensitive to wording. A small change in phrasing could produce a very different answer.

It still matters, especially for smaller models, local models, extraction tasks, style-sensitive work, and tightly constrained outputs. Frontier models are better at recovering from imperfect wording, but they still cannot infer requirements you never articulated.

Prompt engineering is mostly an application of writing.

Writing is the practice of turning a thought into words another mind can interpret. Speech-to-text counts. The interface may have changed, but the requirement to explain yourself did not.

A useful prompt usually defines:

• the task
• the relevant constraints
• the desired output
• the audience
• examples when the target is hard to describe
• what a successful answer must accomplish

If you’re familiar with agent skills, those definitions might sound familiar.

While skills now often include things like scripts and tools alongside concise SKILL.md docs, the original version was just a single text file. That single text file was merely a standardized form of prompt engineering.

The goal is to reduce avoidable ambiguity and make the final outcome as explicit as possible, not to load up vague requirements like “make no mistakes.”

How to learn it

• Rewrite vague requests into specific ones.
• Compare the results from both versions.
• Ask the model what information or constraints were missing.
• Study clear writing instead of collecting prompt incantations.

The better you become at articulating your thoughts, the better you will be at prompt engineering.

2. Context engineering selects the information

As models improved, wording stopped being the only obvious bottleneck. The next question became more important:

“What does the model need to know?”

In a single sentence, that is context engineering.

The relevant context might include source files, documentation, examples, logs, database records, previous decisions, or test results. It might also be a 1,000-word prompt you will never use again. I write those quite often. It is not wasted text if it makes the current task solvable.

But more context is not automatically better.

Context windows are finite attention budgets. Irrelevant files, stale summaries, conflicting instructions, and outdated decisions can make a capable model worse. The skill is selecting the information that changes the answer, not by giving it everything it can possibly hold.

Good context engineering also separates durable project knowledge from temporary task context. A coding convention belongs in project documentation. The error from the command you ran thirty seconds ago probably belongs in the current session.

RAG, or Retrieval-Augmented Generation, is perhaps the earliest and most well-known technique for automating this process. However, that’s a very broad topic, and far outside the scope of this article.

How to learn it

• Include source material instead of describing it from memory.
• Ask the model which missing facts would change its answer.
• Remove irrelevant context and compare the result.
• Learn retrieval, summarization, compression, and context isolation.
• Track which information repeatedly prevents mistakes and make it durable.

Context engineering manages what information the model receives.

3. Harness engineering controls the action surface

A harness is the system around a model that lets it act.

A model in a chat box generates text. An agent harness gives it tools, files, commands, browsers, APIs, memory, permissions, sandboxes, and feedback.

Harness engineering decides which of those capabilities exist and how the agent may use them.

More tools do not always create a better agent. Every tool consumes context and adds another decision. Strong frontier models often perform well with a small set of broad tools. Pi is the obvious example. Weaker models can benefit from narrower tools and stricter constraints that make predictable mistakes harder.

The right design depends on the model, task, and risk. A harness for local code exploration should not have the same permissions as an agent deploying infrastructure.

Recent work has also pushed harness engineering above individual harnesses. Databricks calls Omnigent a meta-harness. It provides shared sessions, policies, approvals, sandboxing, and a common interface across Codex, Claude Code, Cursor, Pi, and custom agents.

It’s a useful product label, but not really a settled category. Other projects use “meta-harness” for different things. The underlying responsibility is clearer than the name: normalize and supervise execution across multiple harness types.

This still does not make a meta-harness the final authority over a workflow. Omnigent can govern actions and sessions while another system decides which stage is legal, what evidence permits advancement, and whether the work may close.

Above the harness is not necessarily the top of the stack.

How to learn it

• Build a small agent with three or four tools.
• Observe the mistakes it makes before adding constraints.
• Remove tools and measure whether decisions improve.
• Compare broad tools with narrow, typed tools.
• Practice permission design, sandboxing, validation, and approval gates.

Harness engineering manages what actions an agent can take and under what immediate constraints.

Learning this layer of the stack is arguably the most technically complicated layer. That being said, once you understand the basics, it will massively increase your understanding of how agents work as a whole.

But beyond that, for the vast majority of people, it’s probably a good idea to leave this one to the frontier labs and research organizations.

4. Loop engineering controls local iteration

Even with a good prompt, good context, and a good harness, an agent eventually stops.

Loop engineering determines how execution continues.

A scheduled automation is a loop. Ralph is a loop. /goal is a loop. An evaluator that sends failed work back to a builder creates a loop.

The simplest version repeats the same prompt whenever the agent stops. That can keep useful work moving. It can also repeat a bad assumption with admirable consistency.

Good loop engineering manages:

• the next prompt
• the context carried forward
• the harness used for the next pass
• progress and stop conditions
• verification
• retry limits
• escalation when another pass will not help

I covered the failure modes in much more detail in Naive loops aren’t the solution to loop engineering. Governed loops are.

A loop is usually the right abstraction for local exploration, iterative coding, research, testing, and self-correction. It lets one agent keep working inside a bounded problem.

But a loop does not automatically define how several different kinds of work fit together.

How to learn it

• Build a repeat-until-done loop.
• Add a real stop condition.
• Add a verifier that can reject the result.
• Add retry and escalation limits.
• Persist enough state to resume after the process stops.
• Study failures where another iteration made the result worse.

Loop engineering manages how agent execution repeats, recovers locally, and stops.

5. Graph engineering controls composition

Graph engineering is the newest name on this list.

The mechanisms are not new. State machines, DAGs, dependency graphs, fan-out, fan-in, conditional routing, and cyclic workflows have existed for a very long time. LangChain says as much in its retrospective on three years of graph engineering with LangGraph.

What changed is that complete agent runs became practical graph nodes.

A node can invoke Codex to implement a feature, Claude Code to review it, or Pi to inspect a narrow question. Another node can run deterministic tests. Edges can route the result into repair, approval, escalation, or closure.

Deer Workflow is a recent example. Its TypeScript workflow code owns phases, inputs, and failure handling while Codex, Claude Code, or Pi performs the semantic work inside each phase.

Graph engineering asks different questions than loop engineering:

• Which work depends on which result?
• What can run in parallel?
• Which outcome selects the next stage?
• Where should deterministic checks replace model judgment?
• Which loops belong inside which nodes?
• What joins the branches again?

The graph-versus-loop argument is mostly a category error. A loop can be represented as a cyclic graph. More importantly, a loop can run inside a graph node, while a graph routes between several specialized loops.

Loops govern local iteration, while graphs govern composition.

Graph runtimes such as LangGraph can also provide checkpoints, replay, interrupts, and human approval. The distinction is therefore about responsibility, not a claim that graph systems cannot be durable.

How to learn it

• Learn state machines and workflow graphs.
• Turn a sequential process into explicit stages and outcomes.
• Remove dependencies that do not consume an earlier result.
• Add fan-out only where work can proceed independently.
• Put a verifier after work that requires objective evidence.
• Model failure, repair, and escalation paths instead of only success.

In short, graph engineering manages how stages, outcomes, dependencies, and transitions compose.

6. Runtime engineering governs durable execution

Once loops and graphs run for hours, survive restarts, wait for people, call outside systems, and change real state, another problem appears.

What is true now, and what is the system allowed to do next?

That is the runtime problem.

Runtime engineering manages the execution semantics around loops and graphs. It owns durable state, recovery, authorization, evidence admission, legal transitions, intervention, and closure.

Three terms need to stay separate:

1. Persistence means the state exists after the process stops.
2. Durable execution means the runtime has defined replay, retry, and resumption behavior.
3. Runtime authority means the runtime decides whether an action or transition is still legal.

Diagrid describes persisted state as a data property and durable execution as an execution guarantee. It’s a useful distinction; a database full of checkpoints does not tell the system which completed work to skip or how to reactivate a failed workflow.

Durable execution does not eliminate every failure problem. At-least-once activities can repeat after ambiguous external effects. APIs still need idempotency keys, conditional writes, or reconciliation. Recovery semantics have to say what the runtime may replay and what it must revalidate.

But authority goes one step further.

An approval might have existed before a replan. A test result might apply to an older commit. A workflow definition might have changed while a run was paused. Durable execution can resume the recorded work correctly and still perform an action that is no longer authorized.

Persistence preserves a record. Durable execution turns the record into a recovery protocol. Runtime authority decides whether recovery is still legal.

Recent research is making this boundary easier to name. SkillSentry converted skill documents into runtime guidance and monitored agent behavior against that structure. Across its selected 15-skill evaluation, mean success rose from 62.6% to 77.7%. Giving the same guidance only through the system prompt performed worse.

That does not make SkillSentry a complete workflow runtime. It does provide direct evidence for a narrower claim: possessing the right procedure is not the same as following it.

Agent Safety Should Be a Runtime Contract makes a related argument. Preventive controls restrict dangerous actions. Evidential controls require tests, logs, diffs, citations, or other checkable proof before accepting completion.

The paper is a position and synthesis paper. Its useful contribution is establishing a clear boundary:

Model output is evidence. It should not automatically become runtime truth.

And this is where Millrace sits.

Millrace compiles workflows (once they’re sufficiently specified) into executable graph plans. External harnesses perform bounded stages. The runtime stores queues, snapshots, run artifacts, waits, evidence, and recovery state. It then decides which transition is legal and what conditions permit closure.

Millrace is not necessary for work a normal agent can finish reliably in one pass. It is for workflows that need to remain coherent across multiple stages, loops, failures, sessions, and runners.

I made the broader case in Runtime Engineering Comes After Loop Engineering.

I covered the authority distinction in Long-Running Agents Don’t Just Have a Memory Problem. They Have an Authority Problem.

How to learn it

• Learn durable workflow engines, queues, and state machines.
• Study replay, retries, idempotency, and ambiguous side effects.
• Separate model proposals from committed state transitions.
• Define evidence requirements before execution begins.
• Model pause, approval, recovery, intervention, and closure.
• Ask which component remains authoritative after a crash.

Runtime engineering governs durable state, recovery semantics, and the legal progression of work.

The complete stack

Here is the concise version:

• Prompts manage how the request is framed.
• Context manages what the model knows for the request.
• Harnesses manage what actions the agent can take.
• Loops manage how local execution continues.
• Graphs manage how stages and outcomes compose.
• Runtimes manage what persists, how execution recovers, and which transition is legal.

The layers overlap. LangGraph is both a graph system and a runtime. Omnigent is both a harness abstraction and an execution control plane. Millrace compiles graphs, invokes harnesses, manages loops, and retains workflow authority.

The point is not to force every product into one box. The point is to identify which system owns each decision.

Prompt problems need clearer requests. Context problems need better information. Harness problems need different capabilities or constraints. Loop problems need better iteration. Graph problems need better composition. Runtime problems need durable rules outside the model.

The names will keep changing.

The ownership questions will not.