Prompt, context, harness and loop engineering

The proposal arrived at Kalahari's architecture forum with a confident organisation chart. Under a new head of AI engineering sat four small teams: prompt engineering, context engineering, harness engineering and loop engineering. Each had a lead, a headcount request and a short mission statement borrowed from a conference talk. The chief architect read it twice and asked one question: "When the claims assistant gives a wrong answer, which of these four teams do I call?"

Nobody could answer, because the honest answer was "probably all four, and also the data team, and also security". The four labels describe something real. They do not describe four separable jobs.

Kalahari Assurance is fictional, and its systems and figures are illustrative. Kalahari is the group IT function of a mid-sized South African insurer that this series has followed from a prompting workshop to four observable levels of maturity. This part takes the four labels that now circulate in AI engineering and asks what an organisation should do with them.

Four layers of control, not four professions

The labels are best read as nested layers, each controlling a wider part of what happens when a model does work.

Prompt engineering controls the instruction: what the model is asked to do, in what format, with which examples and constraints. Anthropic's engineering team describes it as "methods for writing and organizing LLM instructions for optimal outcomes" in its guide to context engineering (September 2025).

Context engineering controls everything else the model sees on a given call: retrieved documents, tool results, conversation history, memory and system state. The same guide defines it as the strategies for "curating and maintaining the optimal set of tokens (information) during LLM inference". In practice, a model's answer depends more on what is in front of it than on how the instruction is phrased.

Harness engineering controls the environment around the model: which tools it can call, with which permissions, which checks run before and after its work, and which signals tell people whether it is behaving. CloudNala has covered this layer in depth, from guides, guards, checks and sensors to the harness as a control system. This part does not repeat that material.

Loop engineering is the least settled of the four terms. In CloudNala's reading it controls the run over time: how many steps the agent may take, what it may spend, when it stops, how it is interrupted, and how it resumes. The agent loop in plain English explains the loop itself, and You do not control the agent until you control the loop covers ownership of the runtime loop.

Each outer layer constrains the inner ones. A perfect prompt cannot rescue a context that is missing the policy wording. A rich context cannot rescue a harness that lets the agent write to production. A good harness cannot rescue a loop with no budget and no stop condition.

Why the layers make poor team boundaries

Kalahari's proposal failed the chief architect's question for a structural reason. Most real failures cross layers.

When the claims assistant told a broker that a policy covered flood damage, the investigation found three causes. The prompt asked the model to "answer helpfully", which encouraged a definite answer. The retrieval step returned the general wording but not the regional exclusion, which is a context problem. And no check compared the answer against the exclusion list before it was shown, which is a harness problem. A team organised by layer would have had three owners for one failure, each able to show that its own layer was reasonable.

There is a second problem. The four labels leave out work that decides whether any of the layers succeed:

• Data engineering. Context engineering assumes the content exists, is current and is labelled. Somebody has to make that true.
• Security. Tool permissions, secrets, prompt injection through retrieved content and identity at each tool call cut across every layer.
• Product discovery. None of the four layers asks whether the assistant should exist, or what a good answer is for the person reading it.
• Evaluation. Every layer needs evidence that it works, and the evidence must be designed before the layer is tuned.

A model of the craft that omits these four is a model of the parts that are interesting to engineers, not of the system that ships.

Map each layer to a work product

Earlier parts of this series argued that capability is shown in work products, not attendance. The four layers become useful once each is tied to the artefact it produces and the evidence that proves it works.

Evidence recall, the context test in the table, is explained with a worked example in Context trimming without losing the evidence.

The table changes the conversation. Instead of asking "who is our context engineer?", Kalahari asks "where is the context specification for the claims assistant, who approved it, and when did its evidence-recall test last run?" That question has an answer or it does not, and the gap is visible.

A useful discipline is to version the prompt and the context specification together. A prompt written for one set of retrieved documents is often wrong for another. From prompt to structured contract covers the output side; the same thinking applies to the inputs.

Who owns which layer at Kalahari

Kalahari did not create four teams. It assigned each layer to people who already existed, using the role tracks from earlier parts.

• Prompt and context are owned by the product team that ships the assistant. The application engineers write them, the business analyst co-owns the context specification because she knows which policy documents and exclusions matter, and the tester owns the evaluation set. Context is not separated from the product because it encodes product knowledge.
• Harness is a shared responsibility. The platform team provides reusable harness components: tool registration through the internal MCP registry, standard checks, telemetry and identity. The product team configures them for its use case and owns the result. Security reviews tool permissions before release.
• Loop follows the same split. The platform team provides budget, interruption and checkpoint mechanisms. The product team sets the values, because only it knows what a reasonable number of steps or a reasonable spend looks like for a claims question.
• Cross-cutting work sits with existing owners: the data team owns the freshness and labelling of source documents, security owns the threat model, the product owner owns the definition of a good answer, and the AI guild owns the standards that make all of this repeatable.

The result is two kinds of ownership: product teams own the behaviour of each AI feature across all four layers, and the platform team owns the reusable mechanisms. That is the same split Kalahari already uses for conventional software, which is the point. The four labels describe a new technical stack, not a new organisational logic.

What this means for learning paths and hiring

The layers are a good structure for learning, as long as nobody learns only one of them.

For Kalahari's application engineers, the learning path moved from prompt-writing exercises to a sequence that follows the layers outwards: write a prompt with an output contract; write a context specification and test it for evidence recall; configure a harness with two checks and one blocked tool; set a loop budget and prove the agent stops. The work product at the end is one small assistant with all four layers documented and tested. That is harder than a prompting course, and much closer to the work.

For hiring, the layers are a useful lens and a poor title. A job advert for a "context engineer" will attract people with very different experience. An advert for an application engineer who can show a context specification with an evidence-recall test, and explain what it would have caught, describes the job and the evidence at once.

Failure modes to watch

• Prompt tuning as the default fix. When an answer is wrong, the first instinct is to edit the prompt. Check the context first. If the model never saw the exception, no instruction will make it apply the exception.
• Context without an owner. Retrieval configuration drifts as documents change. Without a named owner and a test, nobody notices until a broker complains.
• Harness by vendor default. Accepting a framework's default permissions and checks means the harness reflects the vendor's assumptions, not your risk.
• Loops without stop reasons. An agent that stops "because it finished" and one that stops because it ran out of budget look the same in a dashboard unless the stop reason is recorded.
• Four labels treated as the whole profession. If data, security, product and evaluation responsibilities are not named, they become everyone's side job.

Key points

• Prompt, context, harness and loop engineering are nested layers of control, each constraining the ones inside it.
• Most real failures cross layers, so organising teams by layer creates several owners for one failure.
• The four labels omit data engineering, security, product discovery and evaluation, which decide whether any layer succeeds.
• Tie each layer to a work product and to evidence that it works: a versioned prompt, a context specification with an evidence-recall test, tool contracts and checks, budgets and typed stop reasons.
• Let product teams own behaviour across all four layers and the platform team own the reusable mechanisms.

This is the final part of Building Organisational AI Engineering Capability. Start again from Part 1, AI literacy is not a prompting workshop.

How CloudNala can help

CloudNala helps engineering leaders turn the vocabulary of AI engineering into ownership and evidence. We map your AI features across prompt, context, harness and loop, identify where each layer has no work product or no owner, and design learning paths that end in a tested artefact rather than a certificate, so that the next wrong answer has a clear route to a fix.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Plan an AI Capability Programme or write to us at consult@cloudnala.co.za