Introduction to LLM Agents

What Is an LLM Agent?

An LLM agent is a software system built around a language model that can pursue a goal through context, state, tool use, feedback, and repeated interaction.

The model is important, but it is not the whole agent. The larger system supplies the prompt, chooses what context the model sees, exposes tools, records state, retrieves memory, validates actions, handles errors, and decides when the work is finished. When people say that an agent “remembers,” “plans,” or “uses a tool,” the precise mechanism usually belongs to this surrounding runtime, not to the model by itself.

That distinction matters throughout this book.

It also separates three things that are often blurred together:

The boundary is not about prestige. A model call is often enough. A workflow is often better than an agent. The agent form earns its complexity only when the next useful action depends on what the system has learned during the task.

A simple model call looks like this:

prompt
  ↓
model
  ↓
response

An agentic system has more structure:

goal
  ↓
context + role + state
  ↓
model proposes next step
  ↓
tool, memory, or message
  ↓
observation
  ↓
feedback and revision
  ↓
continue or stop

The difference is not that the second diagram is automatically smarter. It is that the system has a loop. What happens next can depend on what was observed before.

That loop is the beginning of agent architecture.

What Is New Here?

Large language models changed the working material of software. They made ordinary language a practical interface for many tasks that previously required formal commands, code, menus, or rigid forms.

Agent systems build on that shift. They let a model-driven system interpret an instruction, gather context, call tools, revise an answer, coordinate with other components, and continue across multiple steps. They can be used as assistants, researchers, editors, planners, critics, tutors, companions, or bridges between other systems.

The important word is system. The model does not improve itself during a conversation in the way a training process improves a model. It does not permanently learn a new fact just because you corrected it once. But an application can store that correction, retrieve it later, place it into context, and change the next interaction. To the user, that may feel like memory or adaptation. Architecturally, it is a runtime using stored state.

This book is about designing that runtime.

It begins with a simple observation: language models are probabilistic. They do not follow a fixed decision tree written by the developer. They generate outputs by sampling or selecting from distributions shaped by training, context, instructions, and decoding settings.

That can be frustrating when you need repeatability. It is also the source of much of their usefulness. Variation lets a model propose alternatives, analogies, drafts, plans, objections, and unexpected connections. A deterministic function is excellent when the route is known. A probabilistic model becomes useful when the route is partly unknown and exploration has value.

The architectural task is to decide where uncertainty helps and where it must be constrained.

model:
  propose, interpret, draft, compare, reframe

runtime:
  store state, expose tools, enforce rules, track versions, verify outcomes

human:
  set direction, judge purpose, accept responsibility, choose what matters

Good agent design does not mean letting probability leak into every part of the system. It means using the model where interpretation and variation are useful, while using ordinary software where correctness, safety, persistence, and accountability matter.

A New Discipline Is Emerging

Traditional software is built from explicit instructions. A developer specifies data structures, control flow, interfaces, storage, error handling, and outputs. That world has not disappeared. It remains the foundation of reliable systems.

LLM agents add a different layer. Some behavior is now shaped through roles, examples, context, feedback loops, tool boundaries, memory policies, and collaboration patterns. The developer still designs the system, but not every path through the system is enumerated in advance.

That changes the work.

You are no longer only asking:

What should the program do?

You are also asking:

What should the model be allowed to decide?
What information should it see?
What tools should it reach?
How should its output be checked?
What should be remembered?
When should the human step in?
How do we preserve a better version without losing the old one?

Those are architectural questions.

This book is not a definitive guide to a settled field. Agent systems are still changing quickly, and many claims made about them are premature. The goal here is more practical: to give you a map of the design space so that new tools, frameworks, and workflows become easier to understand.

The map begins with collaboration.

A person brings intention, taste, values, context, and responsibility. The machine brings speed, breadth, pattern recognition, and a capacity to generate many possible next steps. The productive relationship is not blind delegation. It is a feedback loop in which human judgment and machine variation work together.

That loop can compress the distance between idea and artifact. A developer can prototype faster. A researcher can compare more material. A writer can test more versions of a passage. A teacher can generate and refine examples. A non-programmer can describe a useful workflow and begin shaping it in language.

This does not make expertise obsolete. It changes where expertise enters. Clear goals, good questions, domain judgment, taste, and the ability to recognize failure become more important, not less.

A Brief History of Intelligent Agents

The idea of intelligent agents predates modern language models by decades.

In the 1950s and 1960s, AI researchers explored symbolic reasoning: systems built from rules, logic, and explicit representations. Later expert systems tried to capture specialized knowledge in rule bases. These systems could be useful in narrow domains, but they were brittle. They worked best when the world could be described in advance.

In the 1990s and early 2000s, software agents appeared in more practical forms: programs that monitored events, responded to triggers, searched information, filtered messages, or acted on behalf of a user inside a constrained environment. These agents were often autonomous in a narrow sense, but they did not understand open-ended natural-language goals.

Modern LLM agents combine older agent ideas with transformer-based language models. Transformer models gave AI systems a much more flexible language interface. They could summarize, translate, classify, draft, answer questions, write code, and follow instructions across many domains.

The agent layer then added structure around that capability:

language understanding
  +
roles
  +
tools
  +
memory
  +
feedback
  +
coordination

The result is not a single invention. It is a convergence: old ideas about agents, planning, tools, memory, and collaboration rebuilt around a model that can operate through language.

Why Agents Matter

Language models made it possible to work with software through explanation, conversation, and examples. Agents matter because they connect that interface to action.

A model can suggest a plan. An agent runtime can keep the plan as state.

A model can describe a search query. A tool interface can run the search and return results.

A model can critique a draft. A revision loop can preserve the old version, apply the new one, and compare them.

A model can infer what the user probably wants. A human approval step can decide whether anything should actually happen.

This is the design pattern behind many agent systems:

interpret
  ↓
propose
  ↓
act through a boundary
  ↓
observe
  ↓
revise

Agents matter because they make that pattern reusable.

They also make failure more interesting. A bad result may come from the prompt, the model, the retrieved context, the role definition, the tool schema, the memory policy, the coordination protocol, or the human instruction. Without architecture, all of those failures collapse into “the AI got it wrong.” With architecture, you can ask which part of the system failed.

That is the first step toward improving it.

Agents vs. Traditional Software

Traditional software is strongest when the rules are clear. A tax calculator, a payment processor, a compiler, a database index, and a file synchronizer should not improvise. They should do the same thing for the same inputs, or fail in a controlled way.

Agentic systems are useful when the work contains ambiguity:

The mistake is to treat agents as replacements for software. They are better understood as a new kind of component inside software.

For example, an architect might describe a building concept in plain language and ask an agent to produce options, constraints, and research questions. A researcher might ask an agent to compare papers and identify disagreements. A teacher might describe a student’s needs and ask for lesson variations.

In each case, the language model helps interpret and generate. The surrounding system still needs storage, permissions, tool boundaries, versioning, review, and responsibility.

The machine is adapting more to human language, but the work is not free of structure. Good outcomes still require clear intent.

Working with AI agents can feel like moving from doing everything alone to coordinating a small team of helpers. The gain is not that every helper is always right. The gain is that you can divide work into roles, compare outputs, and use your judgment at a higher level.

From Ten Years to Now

In his essay Teach Yourself Programming in Ten Years, Peter Norvig challenged the idea that someone could master programming in a few weeks. His point still holds. Programming is a craft. It rewards depth, discipline, patience, and hard-won judgment.

LLM agents do not erase that.

They do change the entry point.

For many tasks, you no longer need to begin by translating an idea into syntax. You can begin by describing the goal, the constraints, the examples, the desired output, and the current failure. The system can help you explore possible implementations, generate scaffolding, explain errors, and revise the result.

That means more people can participate in building with technology. It also means more people need to learn how to judge what these systems produce.

The compressed timeline is not:

no skill required

It is:

faster path from intention to first working artifact

The difference matters. Getting to a first artifact quickly is not the same as making it correct, durable, secure, or humane. Agents can accelerate the beginning of creation. They do not remove the need for judgment at the end.

Building Systems at the Speed of Thought

One of the strongest experiences of working with modern AI is the sense that thought can become structure almost immediately.

You begin with a question, a sketch, or an intuition. The system responds with possible outlines, examples, code, counterarguments, or next steps. You react. It adapts to the new context. The artifact changes while the idea is still forming.

That rhythm is different from the older blank-page workflow.

idea
  ↓
conversation
  ↓
option
  ↓
critique
  ↓
revision
  ↓
artifact

This is where stochasticity becomes useful. The model may offer an unexpected analogy, a structure from another field, or a version of the idea you would not have written yourself. Some suggestions will be wrong. Some will be ordinary. A few will shift the work.

The user remains responsible for direction. The system supplies momentum and variation.

That is what this book means by building at the speed of thought: not instant correctness, but rapid movement between intention, representation, feedback, and revision.

Amplified Cognition

When you work with an agentic system, you are doing more than delegating tasks. You are expanding the number of thoughts you can try.

The model can produce alternatives faster than you can write them. Tools can gather context faster than you can search manually. Memory can preserve details you would otherwise forget. A critic role can apply pressure to an idea before another person sees it. A planning role can turn a vague goal into a sequence of possible moves.

None of that replaces your cognition. It extends the workspace around it.

This is amplified cognition: a working arrangement in which human intention, machine-generated variation, external tools, and persistent context combine into a larger thinking environment.

The amplification is valuable only when it preserves agency. If the system floods you with noise, hides its assumptions, manipulates your attention, or makes decisions you did not intend to delegate, it has not expanded your agency. It has reduced it.

Architecture matters even in the most human parts of this book.

A New Kind of Agent

The most interesting agent in this book is not only artificial.

It is also the human who learns to work through these systems: someone who can describe goals, shape roles, inspect outputs, compare alternatives, preserve useful patterns, reject bad versions, and build with a wider field of possibility.

The chapters that follow move from the mechanics of agents to the larger working medium they create. We will look at roles, feedback loops, tools, memory, reflection, versioning, multi-agent systems, companion agents, digital lenses, freestyle cognition, and amplified human agency.

The aim is not to make machines seem mysterious. It is to make this new design space visible.

Agent architecture begins with a model. It ends with the question of what a person can now think, build, discover, and create.