Agentic Engineering

Loops, tools, and context — the craft of building software around models that act.

Agentic Engineering / The Map
The Trunk · 01

The Map

Agentic engineering is the discipline of building software where a language model, rather than hand-written code, does the work: the model runs in a loop, reads its context, calls tools, and acts on the results. The field has six load-bearing parts — the agent loop, context engineering, tool design, evaluation, multi-agent orchestration, and cost engineering — with security and observability woven through all of them. The loop is the trunk: everything else exists to feed it, steer it, or measure it.

Here is the entire field on one page. Read this before anything else — every later section assumes you know where it sits on this map.

The one-paragraph version

An agent is a language model called in a loop: on each pass it reads everything it has seen so far, decides on an action — usually calling a tool like “search the codebase” or “run this command” — and the result gets appended to what it sees before the next pass. That’s the whole trick. Agentic engineering is everything required to make that loop do useful work reliably: what the model sees (context), what it can do (tools), how you know it worked (evals), how loops compose (multi-agent), and what it all costs (economics).

The subfields

Each part of the field, in plain language:

  • The agent loop — the core cycle of model-decides, software-executes, result-feeds-back, and the harness (the ordinary program that runs the cycle) around it. This is the trunk of the whole subject.
  • Context engineering — deciding what the model gets to see on each pass. The model has no memory between calls and a limited reading window, so choosing and arranging its input is a real discipline, not a preprocessing step.
  • Tool design — defining the actions available to the model: their names, descriptions, inputs, and what they return. Tools are the model’s user interface to the world, and most agent failures trace back to a confusing one.
  • Evaluation (“evals”) — measuring whether the agent actually works, using repeated runs and graded scoring rather than single demos, because the same input can produce different outputs each time.
  • Multi-agent orchestration — splitting work across several model loops: one agent coordinating others, each with its own reading window, passing work between them.
  • Cost and latency engineering — keeping the loop affordable and fast. Agents re-read their whole history on every pass, so cost grows quickly with conversation length unless you engineer against it.
  • Security and safety — defending against the signature attack of this field: since the model reads instructions and data through the same channel, anything it reads — an email, a web page — can try to hijack it.
  • Observability — recording everything the agent saw and did (the “trace”) so that failures can be diagnosed after the fact.
  • Memory — giving an agent durable knowledge across sessions, usually by having it write notes to files or databases it can read back later.

What depends on what

Learn things in this order; each level assumes the ones above it.

  • The agent loop — the prerequisite for everything
    • Context engineering — you can’t manage what the model sees until you know how the loop feeds it
      • Cost and latency — caching and pricing are consequences of how context is arranged
      • Memory — long-term memory is context engineering stretched across sessions
    • Tool design — tools are meaningless outside a loop that calls them
      • Security — the risk of hijacking is proportional to what the tools can do
    • Evaluation — you need trajectories (recorded runs) before you can grade them
      • Observability — production evals are just evals over live traces
      • Multi-agent orchestration — last, because it multiplies every problem above and you need evals to tell whether it helped

What this hub covers, and what it only points to

Covered in depth, as Topics 05–10: the agent loop, context engineering, tool design, evals, multi-agent systems, and cost and latency.

Covered inside other topics rather than standalone: security (inside Tool Design and Context Engineering), observability (inside Evals), and memory (inside Context Engineering).

Pointed to but not taught: model training and fine-tuning (you’ll use models as given), the product design of agent UX, and the internals of inference serving. Go Deeper has starting points for each.

Where the hard problems live

Three tensions generate most of the field’s open problems: small per-step error rates compound into large end-to-end failure rates; the model’s reading window is finite while real tasks are not; and the most capable agent is also the most dangerous one to let loose. Major Problems unpacks all of them — after you’ve picked up the Mental Models that make them legible.