AIM-06-004-P · Primer — Anatomy of an Agent

The idea in one sentence

An agent is a system built from five standard parts—a model, instructions, tools, memory, and an orchestration layer—that work together in a loop to reason, act, and remember.

Why it exists

Think of an agent like a kitchen robot: the model is the chef’s brain, the instructions are the recipe, the tools are the knives and oven, memory is the notebook of past attempts, and orchestration is the timer that coordinates everything. This separation solves the problem of tangled code where changing one aspect (like swapping a better knife) forces you to rewrite the whole recipe, making development slow and error‑prone.

How it works

First, the orchestration layer starts the loop by feeding the model the current context and the system prompt (instructions). The model reasons about the goal and decides which tool to call, then the orchestration code executes that tool and captures its output. The result is stored in memory, updating the state for the next iteration. The loop repeats, with the model now seeing the updated memory and any new observations, until the goal is satisfied. In the coding agent example, the model (a strong LLM) receives the instruction "fix the failing test," calls the read_file tool to load the source, uses edit_file to apply a patch, runs run_tests, stores the test results in memory, and loops until all tests pass. Each component can be swapped independently: a better model, a new debugging tool, or a different orchestration pattern without rewriting the whole system.

One variation replaces the explicit orchestration loop with a reactive event‑driven framework that triggers tool calls automatically when certain memory patterns appear. Another approach bundles memory and instructions into a single prompt‑engineering layer, but this reduces modularity and makes debugging harder.

See it — the four building blocks

flowchart TD
  M["Model<br/>(reasoning)"] --> O["Orchestration<br/>(the loop / control flow)"]
  T["Tools<br/>(act + fetch)"] --> O
  Me["Memory<br/>(state, history)"] --> O
  I["Instructions<br/>(goal + guardrails)"] --> O

The one gotcha

A common mistake is to pour most effort into building a sophisticated orchestration framework while neglecting the quality of tools and clarity of instructions; the result is a flashy system that still fails to solve tasks. The correction is to prioritize strong, well‑defined tools and concise, goal‑oriented instructions before polishing the orchestration code.

The one-line takeaway

Modular parts—model, instructions, tools, memory, orchestration—let you upgrade any piece without rebuilding the whole agent.

Where you'll meet it

Practitioners see this structure in AI‑augmented IDE plugins, where the LLM (model) follows a prompt (instructions), calls file‑edit APIs (tools), tracks edited files (memory), and runs inside a loop managed by the plugin code (orchestration). Audits often check each component separately: model performance metrics, prompt safety checks, tool permission scopes, memory retention policies, and orchestration logging.