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. Two distinctions run through this book. First, the prompt — roughly, what was typed — is only part of the context: everything actually made available to the model for one computation, including retrieved memory, tool results, and runtime instructions. Second, 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 the papers, essays, and project references behind the themes in the book. Each work appears once, with its verified identifier. Works are listed as supporting reading: where a chapter relies on a source directly, the source is cited in the text.

Canonical entries

Vaswani et al. (2017). Attention Is All You Need. NeurIPS 2017. arXiv:1706.03762 — Introduced the transformer architecture foundational to modern LLMs.
Brown et al. (2020). Language Models are Few-Shot Learners (GPT-3). NeurIPS 2020. arXiv:2005.14165 — Demonstrates zero/few-shot learning without fine-tuning.
OpenAI (2023, Jun 13). Function calling and other API updates. openai.com — Product note (not a paper) describing tool-calling interfaces and structured model outputs.
Yao et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. arXiv:2210.03629 — Reasoning traces interleaved with actions; relevant to reasoning-and-acting loops.
Schick et al. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv:2302.04761 — Self-supervised API-call learning; relevant to tool-use interfaces.
Shinn et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. NeurIPS 2023. arXiv:2303.11366 — Verbal self-reflection over trials; relevant to reflection and feedback loops. Does not by itself establish companion-agent memory or content filtering.
Madaan et al. (2023). Self-Refine: Iterative Refinement with Self-Feedback. NeurIPS 2023. arXiv:2303.17651 — Same-model generator/feedback/refiner loop; the model-as-critic structure.
Qin et al. (2023). ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs. ICLR 2024 Spotlight. arXiv:2307.16789 — Basis for tool-augmented capabilities; the ToolBench dataset and evaluation are introduced inside this work (cited as ToolBench therein, not as an independent paper).
Patil et al. (2023). Gorilla: Large Language Model Connected with Massive APIs. arXiv:2305.15334 — Fine-tuned API-call generation; relevant to tool and API use.
Wu et al. (2023). AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. arXiv:2308.08155 — Conversation-first multi-agent framework; practical implementation of roles and coordination.
Li et al. (2023). CAMEL: Communicative Agents for “Mind” Exploration of Large Language Model Society. NeurIPS 2023. arXiv:2303.17760 — Role-played multi-agent dialogue; relevant to role assignment in simulations.
Chen et al. (2023). AgentVerse: Facilitating Multi-Agent Collaboration and Exploring Emergent Behaviors. arXiv:2308.10848 — Multi-agent collaboration; relevant to centralized vs decentralized architectures.
Khattab et al. (2023). DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines. ICLR 2024. arXiv:2310.03714 — Declarative language-model programs; relevant to modular program design.
Rajani et al. (2019). Explain Yourself! Leveraging Language Models for Commonsense Reasoning. ACL 2019 (P19-1487). arXiv:1906.02361 — Background on explanation and reasoning traces.
Bai et al. (2022). Training a Helpful and Harmless Assistant with Reinforcement Learning from Human Feedback. Anthropic. arXiv:2204.05862 — Reward feedback loops and alignment strategies.
Bai et al. (2022). Constitutional AI: Harmlessness from AI Feedback. Anthropic. arXiv:2212.08073 — Building AI systems aligned with stated principles.
McLuhan, M. (1964). Understanding Media: The Extensions of Man. McGraw-Hill, New York. — “The medium is the message”; the AI-as-medium discussion.
Sutton, R. (2019, Mar 13). The Bitter Lesson. Essay. incompleteideas.net — Argues that general methods that scale with computation, search and learning, have outperformed hand-built knowledge.
Norvig, P. Teach Yourself Programming in Ten Years. Essay. norvig.com — Programming as craft; agents change the entry point, not the need for judgment.
Gottweis et al. (2025). Accelerating scientific discovery with Co-Scientist (first posted as Towards an AI co-scientist). arXiv:2502.18864 — Multi-agent generate, reflect, rank, and evolve pipeline for hypothesis generation; the paper used as the worked example in Chapter 10.
Wooldridge & Jennings (1995). Intelligent Agents: Theory and Practice. Knowledge Engineering Review 10(2). doi:10.1017/S0269888900008122 — Agent theory, architectures, and languages.
Maes, P. (1994). Agents that Reduce Work and Information Overload. CACM 37(7). doi:10.1145/176789.176792 — Software agents acting on behalf of users.
OpenAI (2023). GPT-4 System Card (pdf) and GPT-4 Technical Report (arXiv:2303.08774); Introducing GPTs (openai.com, Nov 2023). — Browse/code/tool behavior and custom GPTs.

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.

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.