The Five Engineering Disciplines Behind Every AI Agent
The five engineering disciplines behind every AI agent, and when to reach for each.
The problem
Every week a new AI tool promises to “just work.” Some do. Most don’t, and the reason is almost never the model — it’s the engineering wrapped around it. Over the last three years a real profession has formed around making these systems reliable, and it has split into five distinct disciplines. Knowing which one you’re actually dealing with tells you why a tool is failing and what would fix it. This guide is the map. Each section is a couple of hundred words; the links at the end go to the full breakdown of each one.
Prompt engineering — write the instruction
What it is: The craft of writing the instruction you give a model so it returns what you wanted. State the goal, give a role, name the format, show an example, add constraints, and ask it to think before answering. The term comes from the 2022 Chain-of-Thought paper by Wei et al., which showed that asking a model to work through steps first dramatically improved its reasoning.
Use it when: You’re working in a plain chat window and want better, repeatable output — emails, product descriptions, structured data pulled from messy text, or any task you’ll run more than once.
Don’t use it when: The task needs live facts past the model’s training date, a high-stakes decision with no human reviewing it, or capability the model simply doesn’t have. No wording fixes those.
→ Full guide: What is prompt engineering in 2026?
Context engineering — curate what the AI sees
What it is: Deciding, at every step of an agent’s work, exactly what information, tools, examples, and instructions land in its limited working memory. The term was named in mid-2025 (Tobi Lütke’s tweet June 19, Harrison Chase’s post June 23, Anthropic’s deep-dive September 29). It’s the move from “write a clever prompt” to “assemble the right inputs.”
Use it when: You’re running an agent that works for hours across many tool calls — coding assistants, long research, customer-support routing. The core techniques are compaction (summarize when memory fills), persistent notes, just-in-time retrieval, sub-agents, and KV-cache discipline.
Don’t use it when: You just need a one-shot answer from a chatbot. Context engineering is overhead that only pays off once the task outgrows a single prompt.
→ Full guide: Context engineering: curating what the AI sees
Loop engineering — design the cycle
What it is: Designing the repeated observe → plan → act → check → repeat cycle a single agent runs until the job is done. The idea traces through the 2022 ReAct paper and 2023 Reflexion; Peter Steinberger named the discipline in 2026: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”
Use it when: The work is a verifiable cycle — fixing bugs (run test, see red, fix, repeat), resolving a support ticket, repairing a data pipeline. The finish line must be a real signal: tests green, API returned 200, file contains the expected string.
Don’t use it when: The task is a single straight shot, needs sub-200ms responses, or spans specialists who must hand off to each other — that’s graph territory. A loop without a stop condition is a runaway.
→ Full guide: How AI agents work in the background: loop engineering
Harness engineering — build the scaffolding
What it is: Everything bolted around the model that lets it do real work — system prompt, tools, permission gates, skills, filesystem and version control, hooks, and a verification loop. Vivek Trivedy of LangChain put it plainly: “Agent = Model + Harness. If you’re not the model, you’re the harness.” The named discipline crystallized in early 2026.
Use it when: You’re buying, building, or configuring an agent that touches real systems — coding, operations, CRM updates. The harness is what makes the agent safe and useful: a way to verify its own work, approval gates on sends and deletes, and a rollback button.
Don’t use it when: You just want a chatbot to answer questions. A harness takes weeks to get right and quietly locks you to one vendor. Most of the behavior you praise or blame in an agent is the harness, not the model.
→ Full guide: Harness engineering: the invisible scaffolding around AI
Graph engineering — wire the team
What it is: Designing how many agents work together — a programmable organization of nodes (workers, tools, human checkpoints) and edges (the rules for handing work between them). Get the credit straight: the phrase was first used publicly by Itamar Friedman on February 29, 2024. Peter Steinberger’s July 2026 post popularized it; he did not coin it. As a named practice it’s about one month old (as of August 2026) and still settling.
Use it when: One agent’s context window can’t hold the whole domain — multi-domain research, production content pipelines, support triage, or long-lived enterprise automations with audit needs.
Don’t use it when: A single loop with a clear finish line already does the job. Multi-agent systems burn roughly 15× the tokens of one call, and coordination between agents is still unreliable. Solve one loop well before wiring three nodes together.
→ Full guide: When AI starts working in teams: graph engineering
How to pick
Start at the bottom and climb only when you hit a wall: write a better prompt; if the agent forgets or contradicts itself, engineer its context; if it needs to repeat work until a check passes, design the loop; if it touches real systems, build the harness; only when one agent can’t hold the whole job, wire a graph. Most readers of this site will live in the top two. The rest is what the people shipping the tools worry about so you don’t have to.
Sources
Sources
Submit a take
Have a different read on this? Drop a comment below — your email isn't published, and I read every one. Nothing leaves the site until I approve it.