LLM Agents on AIBussin — AI applications, systems and books

What Is an Agent, Really?

Sat, 08 Aug 2026 15:40:00 +0100

This book is about building systems around models. Before we build planners, memory, tool routing, critics, search and verifiers, we need an answer to a question that turns out to be harder than it looks:

What is an agent?

The word is currently applied to almost everything: a single LLM call, a chatbot, a fixed pipeline, a tool-using loop, and any five model calls with class names ending in Agent. Those systems may all be useful. But when one word covers all of them, it stops telling us anything about the computation, and we lose the ability to say which mechanism is doing the work.

Introduction to LLM Agents

Mon, 01 Jan 0001 00:00:00 +0000

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.

Methodologies and Core Patterns

Mon, 01 Jan 0001 00:00:00 +0000

Five Core Shifts in the AI-Human Paradigm

Chapter 1 introduced agents as systems built around language models, not as models alone. This chapter looks at the working patterns that make those systems useful.

The patterns are not complicated. They are easy to miss because they do not look like traditional programming. You converse, inspect, revise, compare, preserve, and try again. The loop is simple, but its consequences are large.

Five shifts sit underneath that loop.

Candidate Generation and Selection

Sat, 08 Aug 2026 15:54:00 +0100

The previous chapter built a boundary that stops arbitrary model output from acquiring execution authority without explicit checks. It made one class of failure inspectable and enforceable, and it is silent about another.

Suppose the model is asked to solve a coding problem. One run produces the right patch. The next produces a plausible but incomplete one. A third produces something better again. Nothing is malformed, nothing violates the action schema, and every one of them would pass the boundary we just built. Validity and quality are different properties. A proposal can be completely valid and still be a poor choice, which relocates the uncertainty rather than removing it:

Critique, Revision, and Acceptance

Sat, 08 Aug 2026 16:23:00 +0100

Selection can only choose among the candidates it is given. A strong evaluator may recognize that every available candidate is poor, but it cannot select a correct answer that the generator never produced.

That limitation becomes practical because the candidates usually come from one model answering one prompt, and such samples correlate. When four candidates share the same misreading of the evidence, ranking them can still produce a confident winner while leaving the shared defect untouched.

Planning and Execution

Sat, 08 Aug 2026 16:35:00 +0100

The critique loop works on one thing at a time. It assumes the task already exists as a candidate we can hold, inspect and improve.

Some tasks have no draft to hold.

Inspect a project, reproduce the failing test, find the cause, patch the code, rerun the relevant tests, and report what changed.

No single narrow action responsibly completes that goal, and the actions constrain each other. Patching before diagnosis is guesswork wearing the costume of work, and reporting success before observing a passing test is a claim about the world that nothing in the run supports. Worse, if execution reveals that an assumption was wrong, the rest of the route may be wrong too. A runtime choosing each action independently can react to the new observation, but without an explicit representation of the intended route it has nothing concrete to compare the changed world against.

Runtime State, Progress, and Termination

Sat, 08 Aug 2026 16:56:00 +0100

A plan is a claim about the future. It says that reproducing the failure, then diagnosing it, then patching, then testing, is a route from here to a working system. Making that claim explicit was worth the machinery. But it is written before any of the work happens, and execution may invalidate one of its assumptions almost immediately.

Execution produces something else entirely: a trajectory. Actions went out, observations came back, and some of what came back may contradict the intended route. The patch step failed because a dependency is missing. The test step is not merely late; it is unreachable.

Memory and Selective Recall

Sat, 08 Aug 2026 17:14:00 +0100

The capability boundary gave the agent a defined action space and a rule for which capabilities are eligible at each step. Runtime state gave it an explicit working representation of what this run has established so far and how it reached that point. Together they govern the current execution, but neither gives information from an earlier run a controlled way to influence this one. There is a family of failures that requires exactly that.

Trajectory Search

Sat, 08 Aug 2026 17:26:00 +0100

An agent can make every local decision look reasonable and still lose the task.

A coding agent sees that test_checkout_redirect is failing, concludes there is an implementation bug in checkout.py, and then behaves impeccably for twenty steps: it reads the file, edits it, runs the tests, repairs the new failures its edit introduced, rewrites the patch, and runs the tests again. Every one of those steps is defensible given the step before it.

The Memory Contamination Problem

Sun, 30 Aug 2026 18:39:00 +0100

Chapter 13 ended with a strict recovery invariant:

repair
→ new candidate state
→ re-measure
→ re-authorize

and with one additional rule:

candidate in HOLD
→ do not persist as trusted factual memory

That second rule changes the scale of the problem.

A hallucinated sentence displayed once is transient.

The same sentence written into persistent state can survive the conversation that created it.

It can then be:

retrieved
summarized
copied
cited
used as agent experience
used to fill a user profile
inserted into a vector index
fed into another model
used as a future repair source

and eventually appear to the system as if it came from somewhere else.

References and Supporting Papers

Mon, 01 Jan 0001 00:00:00 +0000

This section collects papers, essays, and project references related to the themes in the book. It should be treated as a starting point for further reading, not as a fully audited citation apparatus. Some entries need source verification before a formal publication pass.

Chapter 1: Introduction to LLM Agents

Vaswani et al. (2017). Attention is All You Need. Introduced the transformer architecture foundational to modern LLMs.
Brown et al. (2020). Language Models are Few-Shot Learners (GPT-3). Demonstrates general capabilities of LLMs as zero/few-shot learners.
OpenAI (2023). Introducing Function Calling. Relevant to tool-calling interfaces and structured model outputs.

Chapter 2: Methodologies and Core Patterns

Yao et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. Relevant to reasoning-and-acting loops.
Jiang et al. (2023). Active-Prompt: Prompt Engineering with Chain-of-Thought Reasoning. Related to prompt refinement and idea iteration.
McLuhan, M. (1964). Understanding Media: The Extensions of Man. “The medium is the message” section reference.

Chapter 3: The Architecture of Agent Behavior

Shinn et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. Relevant to reflection and feedback loops.
Liu et al. (2023). ToolLLM: Facilitating Tool Learning with Language Models. Basis for tool-augmented agent capabilities.
Rajani et al. (2019). Explain Yourself! Leveraging Language Models for Commonsense Reasoning. Relevant background for explanation and reasoning traces.
Microsoft (2023). AutoGen: Enabling Next gen LLM Applications. Practical implementation of agent roles and multi-agent coordination.

Chapter 4: Designing Your First Agent (On Your Phone)

OpenAI Community & Prompt Engineering Guides (2022–2023). Prompt design as an accessible interface to agent behaviors.
Qin et al. (2023). ToolBench: Towards Empowering Large Language Models with In-Context Tool Learning. Basis for simulating tools with prompts.
Shinn et al. (2023). Reflexion. Related to critique and revision patterns.

Chapter 5: The Thinking Agent

Madaan et al. (2023). Self-Refine: Iterative Refinement with Self-Feedback. The model-as-critic structure.
Liu et al. (2023). Reviewer LLMs. Citation needs verification before publication.
Bai et al. (2022). Training a Helpful and Harmless Assistant with RLHF. Introduces reward feedback loops and output alignment strategies.

Chapter 6: Architecting Agent-Based Systems

Wu et al. (2023). AgentVerse: Facilitating Multi-Agent Collaboration. Details centralized vs decentralized agent architectures.
Zhang et al. (2023). CAMEL: Communicative Agents for Mind Exploration of Large Scale Language Model Society. Supports multi-agent dialogue frameworks.
Zeng et al. (2022). A Survey of Multi-Agent Systems. Gives academic grounding to MAS coordination techniques.
Patil et al. (2023). Gorilla: Large Language Model Connected with Massive APIs. Relevant to tool and API use.

Chapter 7: A New Way of Working With Technology

Schick et al. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv:2302.04761
→ Relevant to tool-use interfaces.
Paranjape et al. (2023). DSPy: Compiling Declarative Language Model Programs. arXiv:2310.01848
→ Relevant to declarative language-model programs.
Yao et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629
→ Relevant to reasoning-and-acting loops.
Wu et al. (2023). AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation Frameworks. arXiv:2309.11455
→ Demonstrates modular, conversation-first interactions among agents.
Shinn et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366
→ Relevant to reflection and revision patterns.

Chapter 8: Companion Agents

Shinn et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning.
→ Related to reflection loops; does not by itself establish companion-agent memory.
Liu et al. (2023). CAMEL: Communicative Agents for Mind Exploration of Large Scale Language Model Society.
→ Relevant to role assignment in multi-agent simulations.
Paranjape et al. (2023). DSPy.
→ Relevant to modular language-model program design.
Wu et al. (2023). AutoGen.
→ Foundation for prompt-based team construction and multi-role behavior.
Yao et al. (2024). MARS: A Multi-Agent Framework Incorporating Socratic Guidance for Automated Prompt Optimization.
→ Citation needs verification before publication.

Chapter 9: Designing Your Digital Lens

Yao et al. (2022). ReAct.
→ Relevant to task-contextual reasoning.
Paranjape et al. (2023). DSPy.
→ Relevant to declarative interfaces; filtering claim needs verification.
Wu et al. (2023). AutoGen.
→ Conversation-driven interface for lens behavior.
Schick et al. (2023). Toolformer.
→ Relevant to tool-use learning; content-filtering application is an extrapolation.
Shinn et al. (2023). Reflexion.
→ Relevant to feedback-driven revision loops.
Yao et al. (2024). MCTS-RAG: Enhance Retrieval-Augmented Generation with Monte Carlo Tree Search.
→ Retrieval/planning relevance needs verification before publication.

The following references are candidates for Chapter 10’s discussion of freestyle cognition, research automation, and AI-assisted prototyping. Verify each title, author list, date, and relevance before final publication.

Advanced Agents From First Principles 06: Does One Agent Plan, Execute and Judge Its Own Work? Build a Planner-Executor-Critic Architecture

Sat, 08 Aug 2026 23:49:00 +0100

Does One Agent Plan, Execute and Judge Its Own Work? Build a Planner-Executor-Critic Architecture

A single model can often do all of these things:

understand a task,
decide what to do,
execute a tool call,
inspect the result,
critique its own work,
decide whether it succeeded,
and produce the final answer.

That is convenient.

It is also a dangerous concentration of responsibilities.

If the same component creates the plan, executes it, explains why the result is good, and decides whether the job is complete, then failures become difficult to localize.

Agents From First Principles 08: AI Agent Picks the First Solution? Add Search Instead of One-Shot Generation

Sat, 08 Aug 2026 17:26:00 +0100

An AI agent often fails for a surprisingly ordinary reason:

it commits too early.

It finds one plausible next action, follows it, and then spends the rest of the run trying to make that first choice work.

That can look intelligent because the agent keeps reasoning, calling tools, revising plans, and explaining itself.

But underneath, the trajectory may be almost completely determined by an early mistake.

A coding agent chooses the wrong implementation strategy and spends twenty tool calls repairing it.

Agents From First Principles 07: AI Agent Forgets Previous Work? Add Working, Semantic and Episodic Memory

Sat, 08 Aug 2026 17:14:00 +0100

AI Agent Forgets Previous Work? Add Working, Semantic and Episodic Memory

An agent can use the right model, call the right tools, execute the right plan, and still behave as if nothing that happened five minutes ago matters.

You see the symptoms quickly:

it re-reads files it already inspected;
it repeats research it already completed;
it asks for information the user already supplied;
it forgets why a previous approach failed;
it loses decisions made earlier in a long task;
it treats every new run as if the system has never seen the problem before;
it retrieves an old answer and treats it as current truth;
it fills the prompt with so much history that the useful information is buried.

The usual response is:

Agents From First Principles 05: AI Agent Gets Stuck in a Loop? Add State, Feedback and Stopping Conditions

Sat, 08 Aug 2026 16:56:00 +0100

An AI agent that keeps calling the same tool, revisiting the same page, rewriting the same file, or repeatedly saying “I’ll try again” is not displaying persistence.

It is displaying a control-flow bug.

This is one of the most common failure modes in agent software because the basic loop is deceptively simple:

observe
 ↓
decide
 ↓
act
 ↓
observe
 ↓
repeat

The problem is hidden inside the final word.

Agents From First Principles 04: AI Agent Fails on Multi-Step Tasks? Separate Planning From Execution

Sat, 08 Aug 2026 16:35:00 +0100

A surprising number of agent failures are not really model failures.

The model may be perfectly capable of writing each individual step. The failure happens because the system tries to decide what to do and do it at the same time.

That works for simple tasks:

question
 ↓
model
 ↓
answer

It becomes fragile when success depends on several ordered actions:

goal
 ↓
step 1
 ↓
step 2
 ↓
step 3
 ↓
verification

A useful next step in agent design is therefore to separate two jobs:

Agents From First Principles 03: AI Agent Keeps Making the Same Mistake? Add a Critique-and-Revision Loop

Sat, 08 Aug 2026 16:23:00 +0100

An AI agent can fail in a particularly frustrating way: it produces an answer that is almost right, you ask it to improve the answer, and it produces another answer with the same underlying defect.

Sometimes the wording changes. Sometimes it adds more explanation. Sometimes it becomes longer and more confident. But the important mistake survives.

That usually means the system is doing this:

prompt
 ↓
model
 ↓
answer

or this:

Agents From First Principles 02: AI Agent Gives Inconsistent Answers? Generate Multiple Candidates and Rank Them

Sat, 08 Aug 2026 15:54:00 +0100

One of the first things you notice when you build anything around a large language model is that the same prompt does not always produce the same quality of answer.

Sometimes the first response is excellent.

Sometimes it is merely acceptable.

Sometimes it misses the point entirely.

That creates a very common agent-engineering question:

If the model is inconsistent, should the agent trust the first answer it gets?

Often, no.

Agents From First Principles 00: What Is an Agent, Really?

Sat, 08 Aug 2026 15:40:00 +0100

What Is an Agent, Really?

This is the first post in Agents From First Principles.

It follows two earlier series.

In PyTorch: Zero to Hero, we worked upward from tensors, autograd and neural-network building blocks until we could build a small language model ourselves.

In Models From First Principles, we moved one level higher. We looked at how learned components can be composed into scorers, value models, policy heads, recurrent models, hierarchical models and compact recursive systems.

Intelligence Through Execution: The Executable Cognitive Kernel

Tue, 10 Mar 2026 21:58:14 +0000

🧭 Summary

Most modern AI systems treat intelligence as something stored inside a model.

A neural network is trained on massive datasets, its weights are adjusted, and those weights become the system’s knowledge. When the model produces an output, we interpret that output as the result of the intelligence encoded inside those parameters.

But this perspective has a limitation.

Once training is complete, the model is largely static. It does not improve through its own actions, and it does not adapt based on the outcome of its behavior unless we retrain it.