AI Engineering Disciplines

You know how to write a good prompt. You’ve probably moved beyond “act as an expert” and into structured system prompts with role definitions, output constraints, and chain-of-thought instructions. You might even version-control your prompts.

That puts you ahead of 80% of the field. It also puts you on the first floor of a four-story building.

Familiar Ground

The AI engineering conversation in 2024 was dominated by a single discipline: prompt engineering. Write better prompts, get better outputs. The advice was tactical: be specific, provide examples, use delimiters, assign a role. Entire courses and certifications emerged around the skill of phrasing instructions to language models.

It worked. For simple, single-turn tasks, it still works beautifully.

But production systems are not single-turn tasks. Autonomous agents run multi-step workflows over hours or days. They orchestrate tool calls, manage state, recover from errors, and coordinate with other agents. In that world, the quality of your prompt matters about as much as the quality of your steering wheel matters to a city’s traffic system. It is necessary. It is nowhere near sufficient.

Counter-Signal

Here is what changed: the industry discovered that most production AI failures are not prompt failures. They are context failures, infrastructure failures, and alignment failures.

A perfectly phrased prompt directed at a model that has the wrong information in its context window produces confident, well-structured hallucinations. An agent with brilliant prompts and perfect context but no feedback loop drifts off course at step nine of a fifteen-step workflow and delivers polished garbage. A system that solves the right problem with perfect execution but optimises for the wrong outcome is the most dangerous of all, because it looks correct until the damage compounds.

Three different failure modes. Three different disciplines required to address them. The field is waking up to a progression that was always implicit but never named as a unified sequence.

⚛️ The Fusion

Four ideas crash here:

Prompt Engineering (how you phrase instructions), Context Engineering (how you curate what the model sees), Harness Engineering (how you build the system around the model), and Intent Engineering (how you define what the system should achieve and why).

These are not four unrelated skills. They are four evolutionary layers, each one absorbing and transcending its predecessor. Each answers a deeper question about how humans direct AI systems:

Each layer does not replace the one below it. It absorbs it. You still need excellent prompts at layer four. But prompts become a solved problem within a much larger system of context curation, infrastructure design, and purpose specification.

Layer 1: Prompt Engineering (2022-2024)

The question: “How do I phrase this?”

Prompt engineering is the craft of writing effective instructions for language models. It is the discipline that launched the AI engineering profession and remains the most widely taught and practised layer.

What it looks like in practice

You structure a system prompt with role definitions, output constraints, and reasoning instructions. You use techniques like few-shot examples, chain-of-thought scaffolding, and output format specifications. You iterate on phrasing to reduce hallucinations and improve relevance.

What it gets right

Prompt engineering teaches you that language models are instruction-following systems, not conversational partners. The shift from “chat with AI” to “specify for AI” is the foundational insight. Everything that follows depends on it.

Subramanian Narayanan at Amazon calls this Prompt-Driven Architecture: treating prompts as production specifications rather than casual requests. His production prompts run 1,000+ lines and include anti-hallucination markers, checkpoint-resume logic, and explicit constraint boundaries (“MANDATORY: build must succeed before proceeding”). This is prompt engineering at its ceiling.

Where it breaks

Prompt engineering assumes the model has the right information. When it does not, no amount of instruction craft can compensate. A flawlessly structured prompt cannot fix “garbage in.”

Prompt engineering also operates at the instruction level, not the system level. It tells the model what to do on this turn. It says nothing about what happens between turns, across sessions, or when the model encounters a situation its instructions do not cover.

The ceiling of prompt engineering is the floor of context engineering.

Layer 2: Context Engineering (2025)

The question: “What does it need to know?”

Context engineering is the discipline of managing a language model’s attention budget. Unlike prompt engineering, which focuses on crafting instructions, context engineering addresses the holistic curation of all information that enters the model’s limited context window: system prompts, tool definitions, retrieved documents, message history, and tool outputs.

Why it matters more than prompts

Muratcan Koylan established the critical distinction: the context window is a scarce, degraded physical resource, not an infinite canvas. As context length increases, models exhibit predictable degradation patterns: the “lost-in-the-middle” phenomenon, U-shaped attention curves, and attention scarcity. Effective context engineering means finding the smallest possible set of high-signal tokens that maximise the likelihood of desired outcomes.

The analogy is precise: treat context like RAM, not a junk drawer.

What it looks like in practice

You design information architectures that load the right knowledge at the right time. You implement progressive disclosure: at startup, agents load only skill names and one-line descriptions; full content loads only when a skill is activated. You build retrieval systems that surface relevant facts and suppress noise. You version-control not just your prompts, but the knowledge graphs, memory stores, and tool manifests that surround them.

Zephyr’s research on 2027 workforce skills identifies context engineering as one of seven non-negotiable capabilities: “Setting up AI so it already knows the business, product, and voice context, avoiding generic re-explanations.” This is the difference between an entry-level AI user and a practitioner who compounds productivity gains over time.

Where it breaks

Context engineering manages what goes into the model. It does not manage what happens outside the model. When your autonomous agent runs a fifteen-step workflow and fails at step nine, no amount of context curation helps if there is no feedback loop to detect the failure, diagnose it, and trigger recovery.

Context engineering treats the model as a decision-maker that needs the right information. Harness engineering treats the model as a component inside a larger system that needs infrastructure to operate safely.

Layer 3: Harness Engineering (2026)

The question: “What system should I build around it?”

Harness engineering is the design of the operational environment surrounding an AI agent. It treats the model as a CPU and the harness as the operating system: memory, tools, feedback loops, constraints, and lifecycle management.

Why the industry arrived here

The 2025-2026 “production reality check” forced it. Teams that built impressive demos with great prompts and smart context engineering discovered that their systems broke in production. Not because the model was wrong, but because there was no mechanism to detect, diagnose, or recover from failures over long-running autonomous operations.

Peter Steinberger at PSPDFKit demonstrated one pattern for this: he ships code he does not read. 6,600 commits in a single month. His secret is not a better model. It is the “closing the loop” pattern: specification → agent generation → automated testing → result feedback → agent iteration → loop until success. The harness, not the prompt, is the hero.

The four pillars of a production harness

1. Architectural Constraints

Deterministic boundaries that prevent agents from drifting. Guard rails (“MANDATORY: build must succeed before proceeding”), forbidden actions (“FORBIDDEN: proceeding to deployment with pending tasks”), and structural limitations that keep the agent within its operational envelope.

2. Feedback Loops and Verification

Multi-agent “generator-evaluator” patterns where one agent proposes and another validates. Linting, automated testing, and output verification as first-class system components, not afterthoughts. The difference between an agent you demo and an agent you trust.

3. Checkpoint and Recovery

Long-running operations will hit failures: context limits, API timeouts, transient errors. Production harnesses encode checkpoint-resume logic: “After completing each task, save progress. If execution restarts, read the checkpoint and resume from the first pending task.” This is not traditional error handling code. It is natural language instructions that the model interprets and follows.

4. Entropy Management

Systems degrade. Documentation drifts. Context stores accumulate noise. Production harnesses include maintenance agents that repair environmental decay, clean obsolete entries, and ensure the operational environment remains healthy over time.

What it looks like in practice

You build a directory structure, not a file. You design multi-step workflows with explicit phase gates. You implement observability: logging what agents do, why they chose each action, and where they failed. You create audit trails that let you reconstruct any decision chain after the fact.

Where it breaks

A perfectly engineered harness can execute flawlessly towards the wrong objective. If no one defines what “success” means at the system level, who resolves conflicts between competing agents, or what values the system should optimise for, the harness is a vehicle without a destination.

That is the gap intent engineering fills.

Layer 4: Intent Engineering (2027+)

The question: “What should this system achieve, and why?”

Intent engineering is the discipline of translating an organisation’s purpose, values, and operational boundaries into structured specifications that autonomous AI agents can execute without ambiguity. It bridges the “alignment bottleneck” between what a business stands for and what an autonomous agent actually optimises for.

Why it sits at the top

Every discipline below this one can execute correctly and still produce the wrong outcome. A perfectly prompted agent with curated context inside a robust harness can optimise for a metric that destroys long-term value because nobody specified what “value” means. Intent engineering prevents that failure mode by making purpose, constraints, and success criteria explicit.

The five components of an intent specification

1. Objective and Purpose

Not “process refunds” but “reduce customer effort during returns while maintaining fraud protection thresholds.” The system knows both what it is doing and why, enabling it to navigate edge cases that specific instructions never anticipated.

2. Success Criteria

Measurable states that indicate the goal has been reached. Not “handle returns” but “95% of eligible returns processed within 4 hours, with customer satisfaction maintaining above baseline.” The agent can evaluate its own progress against these criteria.

3. Health Metrics

KPIs that must not be negatively impacted while pursuing the objective. “Maintain fraud detection rate above 97% while reducing processing time.” These are the constraints that prevent naive optimisation.

4. Constraint Policy

Hard boundaries and forbidden actions. Not suggestions, but enforcement boundaries. “Never approve a return exceeding $500 without human review.” “Never modify pricing data directly.” These persist regardless of what any individual prompt or context says.

5. Escalation and Halt Rules

Explicit conditions that require human intervention or stop execution entirely. “If three consecutive returns from the same customer are flagged, pause and escalate.” The system knows its own authority limits.

Beyond specifications

The five components above are the skeletal structure of intent. They are necessary. They are not sufficient.

A deeper truth is emerging as organisations move from isolated agents to autonomous systems that make thousands of unsupervised decisions daily: an intent specification is not a requirements document. It is the encoded identity of the system. The objectives, constraints, and escalation rules are the visible scaffolding. Beneath them sits a philosophical foundation that most teams never articulate: Why does this system exist? What does this organisation value when two legitimate priorities collide? How should this agent reason about trade-offs that no specification anticipated?

Consider the code review agent from the earlier example. The Layer 4 team wrote an intent specification with objectives, constraints, and escalation rules. But what happens when a brilliant engineer submits code that passes every automated test, solves the immediate problem elegantly, and subtly violates the architectural philosophy the team spent three years building? No constraint policy covers this. No escalation rule triggers. The agent must reason from the organisation’s identity: “We value long-term coherence over short-term velocity. This code is brilliant. It is also corrosive. Flag it.”

That reasoning does not come from a specification. It comes from an organisation that has extracted its own core identity (its calling, its boundaries, its definition of coherence) and encoded that identity as the governing layer above every technical constraint.

This is the true frontier of intent engineering, and it is far harder than writing structured specifications. It requires organisations to answer questions they have been avoiding for decades: What do we actually stand for? What are we unwilling to compromise, even when compromising would be faster? What does it mean for our systems to reflect who we are, not just what we want?

Most teams will find the five components above sufficient for their current needs. For those building systems that will operate autonomously at scale, the deeper work, the extraction and encoding of organisational identity, is the discipline that separates governance from automation.

The pattern you should recognise

If you have ever written a requirements document, a product brief, or a strategy memo, you already practice intent engineering for human teams. The discipline is the same. The audience has changed. You are now writing specifications not for developers who interpret loosely, but for autonomous agents that interpret literally.

The precision bar goes up dramatically. A human developer asks clarifying questions. An autonomous agent does exactly what you specified, including all the edge cases you forgot to specify.

The Evolutionary Sequence in Practice

What does it look like when a team operates at each layer? Here is a concrete scenario: building an autonomous code review agent.

Layer 1 team (Prompt): Writes a system prompt: “You are a senior code reviewer. Review this pull request for bugs, style issues, and security vulnerabilities. Be thorough but concise.”

Layer 2 team (Context): Adds the project’s coding standards document, recent architectural decision records, and the last three reviews for calibration context. Uses progressive disclosure to load language-specific rules only when the relevant file type appears.

Layer 3 team (Harness): Builds a multi-agent pipeline: one agent identifies potential issues, another validates each finding by checking whether the flagged pattern actually violates the project’s conventions. Implements checkpoint-resume so the review can survive context window limits on large PRs. Adds an observability layer that logs every decision with its reasoning chain.

Layer 4 team (Intent): Defines the system objective: “Reduce the time senior engineers spend on routine review by 60% while maintaining the codebase’s architectural integrity score above 85. Never approve changes to security-critical modules without human confirmation. If the estimated review complexity exceeds the agent’s validated capability threshold, escalate the entire PR to a human reviewer rather than producing a partial review.”

Notice what happens at each layer. The agent becomes more autonomous, more reliable, and more aligned with the team’s actual goals. But each layer requires the ones below it. You cannot write a meaningful intent specification without understanding what harness the intent will be enacted through.

The New Pattern

The four-layer model is diagnostic. It tells you where you are and what you are missing.

If your AI agents hallucinate regularly, you have a context engineering problem. You are operating at layer one and attempting layer-three complexity. Stop crafting better prompts. Start curating what the model sees.

If your AI agents drift off course on multi-step tasks, you have a harness engineering problem. Your agent has the right instructions and the right information, but no mechanism to verify its progress, detect errors, or recover from failures. Build the feedback loop.

If your AI agents execute tasks perfectly but produce wrong outcomes, you have an intent engineering problem. No one specified what “success” means at the system level. The agent optimised for the wrong metric. Define the objective, the constraints, and the escalation triggers before you build the harness.

If your AI agents feel brittle and require constant human intervention, you are probably operating at one layer while the complexity of your task demands two or three layers above.

The 80/20 has shifted, again

In the prompt engineering era, 80% of effort went to phrasing instructions, and 20% to everything else. In the context engineering era, the ratio inverted: 80% information architecture, 20% instruction craft.

Now, the ratio shifts once more: 80% of the value in a production AI system comes from the harness and intent layers. The prompts and context are necessary infrastructure, but they are no longer the differentiator. The teams that win are the ones who engineer the system around the model, not the model itself.

The Open Question

Most teams operate at layer one. Some have reached layer two. Very few have built a genuine layer-three harness. Layer four remains the frontier.

Your current ceiling is determined by the deepest question you know how to ask. “How do I phrase this?” is layer one. “What does it need to know?” is layer two. “What system surrounds it?” is layer three. “What should it achieve, and why?” is layer four.

But there is a question beneath “What should it achieve?” that most organisations have never formally answered for themselves, let alone for their AI systems: Who are we, and what will we never compromise?

The five-component intent specification gets you started. The deeper work, extracting your organisation’s core identity and encoding it as the governing layer of every autonomous system, is a discipline that extends far beyond a single article. It demands that leaders, architects, and teams confront questions of philosophy, observability, strategy, and execution that have no quick answers.

This article is the first floor of that building. The deeper layers deserve their own exploration.

Here is the question that sits above all four layers, the one that no framework or discipline can answer for you:

Who in your organisation is responsible for defining the intent, and what happens when nobody does?

This fusion emerged from a STEAL on Subramanian Narayanan’s Prompt-Driven Architecture article, cross-referenced with context engineering research (Muratcan Koylan), harness engineering industry consensus (2026), intent engineering definitions (pathmode.io, mindstudio.ai), and the OpenClaw paradigm (Peter Steinberger). The four-layer model maps to the Mind-Body-Soul framework that governs how living organisations distribute capability. Future articles in this series will explore the deeper dimensions of intent engineering: identity extraction, cognitive governance, organisational resilience, and the observability of coherence.