Agents From First Principles

An agent is not a prompt, a class called Agent, or a framework.

At its most useful, an agent is a running system that can observe its environment, maintain an explicit representation of what has been established, decide what to do next, act through a controlled interface, observe what changed, and decide whether to continue.

This book builds that system from first principles.

We start with the smallest useful loop and add one mechanism at a time. The aim is not to memorize an agent framework. It is to understand the machinery well enough that a framework becomes something you can inspect rather than something you have to trust.

The recurring question throughout the book is:

Who decides what happens next, what is allowed to execute, what actually changed, and what evidence entitles the system to claim that the goal was achieved?

The agent we will build

The basic shape is simple:

goal
  ↓
goal contract
  ↓
runtime state + current observation
  ↓
model proposes
  ↓
action-space exposure + selection
  ↓
validation + authorization + preconditions
  ↓
execution
  ↓
environment observation
  ↓
state update + progress
  ↓
continue / revise / replan / search / stop
  ↓
evidence collection
  ↓
state binding + integrity
  ↓
verification
  ↓
PASS / FAIL / PARTIAL / UNKNOWN

A language model may help make some of those decisions.

But the model is only one component.

The rest is software.

That distinction is the foundation of this book.

What this book is designed to teach

By working through the chapters, you will learn how to make the hidden parts of an agent explicit.

You will learn how to:

• distinguish a model call, a fixed workflow, and an agent by looking at control flow;
• represent model outputs as proposed actions rather than trusted commands;
• validate structure, semantics, permissions, and tool arguments before side effects occur;
• generate several possible solutions and separate generation quality from selection quality;
• use critique and revision without assuming that a critic is automatically correct;
• accept or reject revisions based on evidence rather than confidence;
• separate planning from execution so plans become inspectable program state;
• represent dependencies, expected outputs, replanning triggers, and completed work explicitly;
• distinguish execution trace, runtime state, persistent memory, model context, and cache;
• measure progress, detect nonproductive loops, enforce budgets, and stop for named reasons;
• design tools as narrow capabilities with contracts rather than vague extensions of the model;
• measure tool routing and reduce unnecessary model decisions;
• distinguish working state, working memory, semantic memory, episodic memory, procedural memory, retrieval, and caching;
• search over alternative partial trajectories instead of committing to the first plausible path;
• allocate search breadth and depth under explicit compute and cost budgets;
• define success before execution begins;
• verify the result against the environment instead of accepting the agent’s own declaration that it is done; and
• assemble the mechanisms into one complete agent whose success can be inspected and verified end to end.
• distinguish unknown from false, so missing evidence is never silently converted into failure or success;

The objective is not to make an agent appear more autonomous.

It is to make its behaviour more understandable, controllable, measurable, and reliable.

One system, built progressively

The chapters describe one growing computational system.

01  Control
    What makes an agent different from a model call or a fixed workflow?

02  Actions
    Turn language-model output into structured, validated proposals.

03  Alternatives
    Generate several candidates and make selection explicit.

04  Feedback
    Diagnose defects, revise deliberately, and reject regressions.

05  Planning
    Represent intended multi-step work separately from execution.

06  State and progress
    Track what is true, whether anything improved, and when to stop.

07  Tools
    Design the action space, exposure rules, routing, schemas, and capability contracts.

08  Memory
    Preserve useful past information without confusing it with current state.

09  Search
    Keep multiple partial trajectories alive and spend compute selectively.

10  Verification
    Bind evidence to state and decide what earns the claim that the goal was achieved.

11  Integration
    Assemble the already-earned mechanisms into one verified repair agent.

Each chapter adds another mechanism because the previous system has exposed a specific limitation.

That progression matters.

Memory is much easier to understand once state is explicit. Search is much easier to understand once candidates, scoring, state, and budgets already exist. Verification is much stronger once actions and expected outcomes have been represented explicitly.

Chapter 11 adds no new mechanism.

Instead, it asks whether everything we have built can actually compose:

broken repository
      ↓
reproduce the failure
      ↓
inspect the current state
      ↓
generate alternatives
      ↓
select and revise
      ↓
plan and search
      ↓
authorize one mutation
      ↓
execute
      ↓
collect state-bound evidence
      ↓
check integrity
      ↓
adjudicate the goal contract
      ↓
VERIFIED_SUCCESS

The point of Chapter 11 is not another abstraction.

It is to make the accumulated architecture visible as one working system.

The central engineering principle

A language model is probabilistic.

That is useful. It can propose actions, alternatives, plans, critiques, hypotheses, and interpretations that ordinary deterministic code would struggle to produce.

But not every part of an agent should therefore become probabilistic.

When ordinary software can answer a question reliably, let ordinary software answer it.

Does this JSON parse?              → parser
Is this action in the tool set?    → validator
Is this path allowed?              → policy
Did the test pass?                 → test runner
Did state change?                  → runtime
Have we exceeded the budget?       → counter / clock
Did the requested outcome occur?   → verifier

This gives us one of the book’s main rules:

Move as much correctness as possible out of probabilistic model behaviour and into inspectable software.

Or, more compactly:

The model proposes. The runtime controls execution. The environment supplies observations. The verifier decides what the resulting evidence earns.

What you should be able to do after reading

The goal is not that you know every agent architecture or every framework API.

The goal is that unfamiliar agent software becomes legible.

You should be able to open an agent system and ask:

Where is the real state?
What is merely model context?
Who chooses the next action?
What actions are actually available?
What validates them?
Who owns the side effect?
What observation comes back?
How is progress measured?
Why does the loop continue?
What causes replanning?
What is remembered, and why?
Where can the system branch or search?
What makes it stop?
What evidence proves the goal was achieved?
Can the verification path itself be trusted?
What information is authoritative, and what is merely evidence or context?

Those questions are more durable than any particular framework.

They also make debugging much more precise.

Instead of saying:

The agent is bad.

we can ask whether the failure occurred in generation, selection, planning, routing, execution, state update, retrieval, search, stopping, evidence collection, or verification.

That is a much more useful way to build agent systems.

You will also learn when not to build an agent

An agent is not automatically better than a function, a model call, or a deterministic workflow.

If the route is known in advance, a workflow may be easier to test and safer to operate.

If one model call already solves the task reliably, adding planning, memory, search, and multiple agents may only add latency, cost, and failure modes.

Throughout the book we therefore start with the simplest baseline and add machinery only when a measurable failure justifies it.

Agent engineering is not about maximizing autonomy. It is about placing adaptive decision-making only where it earns its uncertainty.

It is about choosing where adaptive decision-making is genuinely useful.

Who this book is for

You should be comfortable with basic Python and with the idea of calling a language model.

You do not need previous experience with an agent framework.

You do not need to know LangChain, CrewAI, AutoGen, or any particular orchestration library.

The examples deliberately stay close to ordinary Python data structures, functions, loops, tests, and explicit state so that the mechanisms remain visible.

Frameworks can automate many of these ideas later.

First we want to know what they are automating.

What this book does not try to cover

This is not an encyclopedia of everything called agentic AI.

It does not attempt to cover every multi-agent topology, distributed runtime, production deployment system, security model, or specialized research architecture.

Those are important subjects, but they make more sense after the core mechanisms are understood.

This book also avoids treating prompt tricks, simulated tools, self-grading, or a collection of roles with names like PlannerAgent and CriticAgent as sufficient evidence that a reliable agent system exists.

Names do not create mechanisms.

We will keep asking what the software actually does.

The promise

By the end of Agents From First Principles, you should be able to look at an unfamiliar agent system and work out:

what state is real, who chooses the next action, what is allowed to execute, what changed, why the system is continuing, and what evidence proves that the goal was actually achieved.

You should also be able to ask one final question:

What does the system trust when it claims success?

Once you can answer those questions, the agent stops being a black box. Its uncertainty has not disappeared, but you can see where that uncertainty enters, what constrains it, what the environment established, and what evidence ultimately justified the result.