What Is Agent Engineering?

Agent engineering is the discipline of designing, building, evaluating, and operating goal-directed AI systems that can reason over state, use tools, and act inside real workflows under explicit control.

That is our definition. Two others are in wide circulation, and it is worth saying where we agree and where we do not.

LangChain, in Agent Engineering: A New Discipline, writes that “Agent engineering is the iterative process of refining non-deterministic LLM systems into reliable production experiences,” a cycle of “build, test, ship, observe, refine, repeat.” We agree that the work is iterative, that shipping is how you learn, and that this is “a set of responsibilities that existing teams take on,” not a new job title. We disagree that the definition should stop at the process. A cycle describes how you practice. It does not name what you own: the bounded-autonomy system around the model.

Anthropic, in Building effective agents, draws a sharper architectural cut: “Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.” They recommend “finding the simplest solution possible, and only increasing complexity when needed,” which “might mean not building agentic systems at all.” We agree with both claims. The discipline includes the decision to stay on a workflow. Maximizing autonomy is not the job.

The shorter form of our definition is this:

Agent engineering is the work of making bounded-autonomy systems useful, reliable, and governable in practice.

If you are only improving a single prompt, you are not doing the full job. If you are only wiring a model to a tool without thinking about state, recovery, permissions, and evaluation, you are not doing the full job either.

Agent engineering starts when the system has to pursue a goal across steps and someone has to decide how that system should think, what it should know, what it may do, how it should be checked, and how it should be operated once it is live.

That last part matters more than the market sometimes admits. The term sounds new because many teams are still treating agents like dressed-up prompts. They are not. Once a system can choose among actions, touch tools, carry state, and create side effects, you are doing a different kind of engineering whether you use the label or not.

What Is Agent Engineering, in Plain English?

In plain English, agent engineering is the discipline around building AI systems that can do more than answer once.

These systems can:

• inspect the current state of a task
• decide what to do next
• use tools or external systems
• carry context across steps
• recover when something goes wrong
• stop, escalate, or ask for approval when risk is too high

That is why the discipline exists. Once you move from one-shot outputs to multi-step, tool-using, stateful behavior, the hard problem is no longer just the model response. The hard problem is the system around the model.

LangChain’s later framing of that system is useful here. In The Anatomy of an Agent Harness they write: “Agent = Model + Harness. Harness engineering is how we build systems around models to turn them into work engines.” OpenAI’s practical guide splits the same object into three parts a team can actually assign: a model, tools, and instructions. We treat those as complementary pictures of one thing, not competing slogans. The model is the intelligence. The harness is everything else you have to design.

Two quick examples make the boundary clearer.

If a team improves the prompt behind a support chatbot so the answers sound better, that is useful work, but it is still mostly prompt engineering.

If that same team builds a support system that:

• decides whether a case needs retrieval, policy lookup, or a CRM tool call
• pulls the right account context
• drafts a resolution
• asks for approval before issuing a refund
• records the trace and escalation path

that has become an agent engineering problem.

The same pattern shows up in coding. A model that writes a function from a prompt is not the whole discipline. A coding system that plans a fix, runs tests, inspects failures, retries safely, and stops when the change is ready for review is.

Why Prompting Is No Longer the Center of Gravity

Early prompt engineering was mostly about improving a model’s output inside a single interaction. That still matters, because models still reason through language. It just no longer explains most of the failure in production agent systems.

Once a system has memory, tools, external context, and the ability to act, you are not designing a prompt. You are designing a closed-loop system that has to interpret a goal, decide what information it needs, retrieve or update context, choose an action, judge whether the action worked, decide what to do next, and stop safely when confidence is low or risk is high.

The serious failures now live in the layers around the prompt:

• the system did not have the right context at the right time
• the tool interface was ambiguous or poorly constrained
• the model chose the wrong tool or the wrong action sequence
• the workflow had no durable recovery path
• the team had no way to observe what happened
• the agent succeeded once in a demo and failed repeatedly under real traffic

That is a structural shift, not a matter of emphasis. A team can have strong prompts and still ship a weak system. A team can also have modest prompts inside a strong architecture and get much better results. System quality is displacing prompt quality as the differentiator, which is exactly why the discipline needs its own name.

The lineage of the role is older than the current label. In 2023, swyx argued in The Rise of the AI Engineer that software engineering was spawning a subdiscipline “specializing in applications of AI and wielding the emerging stack effectively.” Agent engineering is a further specialisation of that role: the same applied-AI engineer, now responsible for a system that chooses actions under uncertainty.

What the Discipline Owns

The simplest useful way to define the field is by the jobs it owns. Vague writing describes the aura of agentic systems instead of the work. The field becomes much easier to reason about once you ask a harder question: what job does the engineer now own that did not exist when the system was just a model call?

This page is the hub for those jobs. Each one has a canonical article on this site.

1. Context and harness design

Once an agent operates across steps, it needs more than a good prompt. It needs the right working context, retrieval strategy, and memory boundaries: what the system should know right now, what it should retrieve on demand, what it should remember across runs, and what it should forget.

That is also an architecture decision, and topology is where teams routinely underinvest. Single agent or multi-agent. Planner-executor or supervisor-worker. A workflow graph or an open-ended loop. Where the handoffs between models, tools, and humans sit. Where schema constraints and execution boundaries are enforced. A weak orchestration design can bury a strong model under the wrong tools, the wrong context, or the wrong sequence of tasks, and a strong one often makes a smaller model far more useful.

Barry Zhang, speaking for Anthropic, puts the context job as a habit: “put yourself in the agent’s context window,” because at each step the model is still “just running inference on a very limited set” of context (8:20). The harness is how you decide what that set is.

Read Context Engineering: The New Core Skill and How Good Agent Memory Actually Works in Production.

2. Tools

An agent is only useful if it can do something beyond generate text. Agent engineering owns the execution surface: tool definitions, schema design, argument quality, retries, permission boundaries, and the handoff between reasoning and action.

This is the layer where the model stops being an answer engine and starts behaving like an operator. A tool call that works once on stage proves almost nothing. The engineering question is whether the tool surface is clear enough, constrained enough, and observable enough to survive repeated use under messy inputs.

Read Designing Tools for Agents, Tool Use: How Agents Take Action, and MCP in Practice.

3. Control and approvals

An agent system needs a goal, a stopping condition, and clear boundaries on what it is allowed to do. When should the system choose its own next step? When should it follow a fixed workflow? Which actions require approval? What should cause it to stop or escalate?

The job is not to maximize autonomy. The job is to apply the smallest amount of autonomy that solves the problem safely. That cuts against a lot of current product theater. The market still rewards broad autonomy claims. Production systems reward narrower, better-controlled loops.

Anthropic’s workflow-versus-agent cut belongs here, as does Zhang’s cost argument: if you can map the decision tree, “just build that explicitly” — it is “a lot more cost-effective” (3:06). OpenAI’s guide makes the same first filter: if the work is not complex decision-making, difficult-to-maintain rules, or heavy unstructured data, “a deterministic solution may suffice.”

Read Human-in-the-Loop Control Design, When to Use a Workflow Instead of an Agent, and Structured Outputs, Guardrails, and Execution Boundaries.

4. Evals

A single correct answer does not prove that an agent system is healthy. Agent engineering has to judge the run itself: did the system choose the right path, use the right tool, recover well, stay inside policy, and stay inside cost and time?

This is why agent evaluation is about trajectories, not just outputs. Andrew Ng’s version of the gap is that teams should put in eval frameworks that trace individual steps, and that many wait too long on human evals (5:50). Start by reading failures before you write graders.

Read Error Analysis: The First Eval You Should Run and Evaluating Agent Trajectories, Not Just Outputs.

5. Observability

You cannot evaluate, govern, or improve a system you cannot see. Traces are how you inspect each decision, each tool call, and the context that informed them. LangChain’s successful adopters — they name Clay, Vanta, LinkedIn, and Cloudflare — are described as “treating production as their primary teacher,” “tracing every decision, evaluating at scale.”

Read Tracing and Observability for Agent Systems.

6. Operations

The discipline does not stop when the system works once. A real agent system has to be observed, reviewed, and controlled after deployment: traces and runtime visibility, regression checks, incident review, cost and latency controls, approval paths, rollback, and reliability discipline.

LangChain’s cycle is the operating cadence, not the definition: build, test, ship, observe, refine, repeat. Shipping is how you get the next trace, not the end of the work.

Read AgentOps: Running Agents in Production.

7. Security

Governance belongs in the same job rather than in a legal appendix. Once an agent can act, someone has to answer which permissions it holds, which tools are read-only and which create side effects, which actions require human approval, what audit trail exists, and what happens if the context is poisoned or the tool surface is hostile. The mature answer is not that the model will behave. It is architecture plus policy: least privilege, secure execution boundaries, typed interfaces, approval gates, and immutable traces.

Read Agent Security: Prompt Injection and the OWASP Agentic Top 10.

How Is Agent Engineering Different From Adjacent Fields?

The cleanest way to understand the term is to compare it with the fields next to it.

Prompt engineering is still part of the work. Software engineering is still part of the work. Machine learning engineering is still part of the work too. LangChain’s version of that overlap is the “3 skillsets” claim: engineering, product, and data/ML. Harrison Chase puts the same mix in spoken form — prompting plus engineering plus product plus ML (evals, fine-tuning) — and is honest that the role is “early on” and “still being defined” (5:15).

Agent engineering sits at the level above any one of those layers. It is about how the whole system behaves once a model is embedded in a loop with tools, memory, and action.

That is also why this article is different from What Is an AI Agent?. That article defines the system object. This article defines the discipline responsible for making that object work in the real world.

Another useful way to say it is this:

• software engineering asks whether the system is correct
• ML engineering asks whether the model is capable
• prompt engineering asks whether the model is being guided well
• agent engineering asks whether the full bounded-autonomy system behaves well over time

A Minimal Harness

The word “harness” is easier to see in code than in a definition. The loop below is the smallest thing that still qualifies: a model, one tool, a step budget, a stop condition, and a trace. Swap the model function for any provider. Everything around it is the harness.

# minimal_harness.py — model + one tool + step budget + trace + stop.
# The model is a function. Swap the stub for any provider.
from dataclasses import dataclass

STEP_BUDGET = 6

def lookup_refund_policy(order_value_usd: int) -> str:
    """One tool. Deterministic. Returns the smallest useful result."""
    return "auto_approve" if order_value_usd <= 50 else "needs_human_approval"

TOOLS = {"lookup_refund_policy": lookup_refund_policy}


@dataclass
class TraceEvent:
    step: int
    kind: str  # tool | stop | budget
    detail: str


def run(goal: str, model, budget: int = STEP_BUDGET) -> tuple[str, list[TraceEvent]]:
    messages = [{"role": "user", "content": goal}]
    trace: list[TraceEvent] = []

    for step in range(1, budget + 1):
        decision = model(messages)  # {"tool", "args"} | {"stop", "answer"}
        if decision.get("stop"):
            trace.append(TraceEvent(step, "stop", decision["answer"]))
            return decision["answer"], trace

        name, args = decision["tool"], decision["args"]
        result = TOOLS[name](**args)
        trace.append(TraceEvent(step, "tool", f"{name}({args}) -> {result}"))
        messages.append({"role": "tool", "name": name, "content": result})

    trace.append(TraceEvent(budget, "budget", "step budget exhausted"))
    return "stopped: step budget exhausted", trace


def stub_model(messages: list[dict]) -> dict:
    last = messages[-1]
    if last.get("role") == "user":
        return {"tool": "lookup_refund_policy", "args": {"order_value_usd": 80}}
    return {"stop": True, "answer": f"policy says {last['content']}"}


def looping_model(messages: list[dict]) -> dict:
    return {"tool": "lookup_refund_policy", "args": {"order_value_usd": 80}}


if __name__ == "__main__":
    answer, events = run("Can I refund this $80 order?", stub_model)
    print(answer)
    for event in events:
        print(event)

    print("---")
    capped, cap_events = run("loop forever", looping_model, budget=3)
    print(capped)
    for event in cap_events:
        print(event)

The first run is a two-step trace and a stop. The second never stops on its own, so the budget branch fires and you get a budget event. That is the whole shape. What production adds — more tools, approvals, durable state, evals on the trace — hangs off this loop. It does not replace it.

Zhang names an open problem that this sketch only gestures at: “define and enforce budgets in terms of time… money… tokens” (12:00). A step cap is the cheapest budget. It is not the only one you will need.

One more caution on what “harness work” can look like at the far end. In Extreme Harness Engineering, Ryan Lopopolo describes a constraint “to not write any of the code myself” (3:41). As the interviewer summarises, that was a team of about three shipping on the order of a million lines and 1,500 pull requests (8:49). Lopopolo says most human review is post-merge at that point (9:19), because the work had shifted to building the environment the agent runs in (10:20). Treat those numbers as one team’s report, not an industry norm. The transferable claim is smaller: as the model writes more of the code, the engineer owns more of the harness.

What Usually Fails in Weak Agent Systems?

Weak agent systems rarely fail only because the model was not smart enough. The layers already listed above — context, tools, recovery, and observability — usually break first. Add stale memory, a retry that makes the run worse, and a policy boundary that should have triggered approval and did not.

Harrison Chase’s version of the same gap: prototypes are easy; the hard part is getting “that to something that’s reliable enough to actually move the lever” (2:10), and “there is a lot of engineering skills that go into building reliable agents” (4:14).

A demo can survive with fuzzy boundaries because the happy path is curated. A real deployment has to survive ambiguity, repetition, degraded inputs, partial failures, and human scrutiny. That is where agent engineering becomes a real discipline instead of a nice phrase.

What Agent Engineering Is Not

The term becomes useless if it expands to mean every AI-adjacent task.

Agent engineering is not:

• every project that uses an LLM
• every workflow with a model call in the middle
• every prompt-writing exercise
• every automation system with a chatbot UI
• every multi-agent demo

It is also not limited to coding agents.

The fastest test is this:

If the system does not need to choose among actions at runtime, manage state across steps, use tools under constraints, and remain observable enough to debug, you probably do not need the term.

That usually means these are not strong agent engineering cases:

• one-shot summarization or rewriting
• fixed document pipelines with a known path
• narrow classifiers
• basic chat wrappers
• deterministic automation with a small number of explicit branches

A customer support system that retrieves account context, decides whether to search docs or call an internal tool, asks for approval before issuing a refund, and leaves an auditable trace is an agent engineering problem.

A research system that plans a search path, gathers evidence, updates its working state, drafts a result, and stops when its success condition is met is an agent engineering problem too.

The key test is not the interface. It is whether you are engineering a bounded-autonomy system that has to reason, act, recover, and remain governable across time.

When the Term Actually Fits

The label is most useful when all or most of these are true:

• the task is multi-step
• the right next move depends on what happened in the previous step
• the system must choose among tools or actions
• context quality materially affects success
• there is real risk in getting the action wrong
• the team needs evaluation, traces, and operational control after launch

Andrew Ng’s useful hedge is that agentic-ness is a matter of “degrees,” not a binary (2:42). A system can be a little agentic and still create an engineering problem. It can also wear the word and still be a workflow.

That is why agent engineering tends to appear in domains like support operations, research systems, coding agents, internal copilots with tool access, case handling, workflow triage, and other knowledge-heavy tasks where the path cannot be fully hardcoded in advance.

Why the Discipline Is Emerging Now

Two things arrived at the same time.

The capability layer became good enough. Models can plan, classify, summarize, call tools, and hold multi-step coherence well enough that agent behavior is no longer theoretical.

The systems layer matured quickly alongside it. Tool protocols, tracing stacks, eval frameworks, browser automation, coding-agent runtimes, and workflow engines make it much easier to build something that looks like an agent.

LangChain’s diagnosis is the same pair of shifts: models are now “powerful enough to handle complex, multi-step workflows,” and that power “comes with real unpredictability” that the traditional software playbook does not cover. We agree on the diagnosis. We still want a definition that names the object of work, not only the iteration loop those teams use to harden it.

That combination creates opportunity and confusion in equal measure. More teams can ship agentic behavior, and more teams can ship fragile systems that impress in a demo and collapse under production constraints. The gap between apparent intelligence and actual reliability is where a discipline forms.

It also explains which questions the market tends to skip, because none of them are glamorous:

• when should a workflow stay mostly deterministic?
• how much autonomy is actually safe or economically rational?
• what is the smallest reliable loop that solves the problem?
• which failures are acceptable, and which are not?
• what can be observed, audited, and rolled back?

Those questions are not peripheral to agent engineering. They are the discipline. The name is useful only while it keeps pointing at that work, not at a chat box plus tool calling.

Where This Fits in the Learning Path

Once the definition is clear, the rest of the site becomes easier to navigate.

If you already understand what an agent is, the next useful boundary is LLMs, Workflows, and Agents: What Actually Changes?.

If you want to go deeper into the system layers the discipline owns, the next steps are:

• Context Engineering: The New Core Skill
• Designing Tools for Agents
• MCP in Practice
• Error Analysis: The First Eval You Should Run
• Tracing and Observability for Agent Systems
• AgentOps: Running Agents in Production
• Agent Security: Prompt Injection and the OWASP Agentic Top 10

The Bottom Line

The object being built has changed: a model in a loop with tools, state, and side effects. The work required to make that object reliable has changed with it. That work is the seven jobs above.

FAQ

Is agent engineering just prompt engineering with a new name?

No. Prompt engineering shapes instructions and input. Agent engineering owns the system around the model.

Is agent engineering the same as building an AI agent?

Not exactly. Building an agent might mean assembling the first working loop. Agent engineering is making that loop reliable, governable, and production-ready.

Is a harness the same as an agent?

No. The model is not an agent, and the harness is not an agent either. An agent is the two together: intelligence plus the system that gives it state, tools, a loop, and constraints.

Is agent engineering only for multi-agent systems?

No. A single bounded agent can already create an agent engineering problem. Multi-agent coordination is only one possible architecture pattern.

Does every agent system need memory and tools?

In practice, most useful ones do. Without state and tools, the system usually collapses back toward a one-shot assistant.

What should I read next?

Start with What Is an AI Agent? if the system object is still fuzzy. If that part is already clear, go next to LLMs, Workflows, and Agents: What Actually Changes?.

Further watching

Each of these was transcript-checked; timestamps link to the moment the claim appears.

• Interrupt 2025 Keynote — Harrison Chase (LangChain, May 2025). The spoken version of LangChain’s discipline claim. Prototypes are easy; the hard part is getting “that to something that’s reliable enough to actually move the lever” (2:10). The engineering work is tools, context pipelines, and deployment (4:14). Prompting plus engineering plus product plus ML “has really burgeoned into what we see being the agent engineer,” still early and “still being defined” (5:15).
• How We Build Effective Agents — Barry Zhang, Anthropic (AI Engineer, 14 min, 2025). The production reading of Building effective agents. If you can map the decision tree, “just build that explicitly” — it is “a lot more cost-effective” (3:06). The context habit: “put yourself in the agent’s context window,” because each step is still inference over a limited set (8:20). The open problem: budgets in time, money, and tokens (12:00).
• Extreme Harness Engineering — Ryan Lopopolo, OpenAI (Latent Space, 77 min, 2026). One team’s report, not a norm. Lopopolo’s constraint: “to not write any of the code myself” (3:41). The interviewer summarises a team of about three shipping on the order of a million lines and 1,500 pull requests (8:49). Lopopolo on review and the environment: most human review is post-merge (9:19); the work shifted to modular building blocks and an observability stack the agent can query (10:20).
• Andrew Ng: State of AI Agents (LangChain). Agentic-ness as “degrees” rather than a yes/no (2:42). Teams should put in eval frameworks that trace individual steps, and many wait too long on human evals (5:50).

Primary Sources

• LangChain, Agent Engineering: A New Discipline — the process definition, the three skillsets, “not a new job title,” and the named production adopters.
• LangChain, The Anatomy of an Agent Harness — “Agent = Model + Harness,” and harness engineering as the work of turning a model into a work engine.
• Anthropic, Building effective agents — workflows versus agents, and the instruction to start simple.
• swyx, The Rise of the AI Engineer — the applied-AI role that agent engineering specialises.
• OpenAI, A practical guide to building agents — model, tools, and instructions as the three foundations, and when a deterministic solution still suffices.