Part Two of an Ongoing Series on AI Agents
I want to start with an admission: the first time I really understood what made AI agents different, it wasn’t from reading a research paper. It was from watching one fail.
The agent had been given a task — pull together a competitive analysis, summarize the findings, and draft a briefing. Simple enough, in theory. But somewhere in the middle, it got confused by a website that redirected unexpectedly. Rather than stopping to ask for help, it kept going — confidently, methodically, and completely wrong — for another six steps before producing a document that looked impeccable and was built on a misread source.
That moment taught me more about how agents work than any architecture diagram. Because the failure wasn’t random. It was structural. It emerged directly from the loop the agent was running — the same loop that, when it works correctly, makes these systems astonishing. To understand AI agents is to understand that loop: what it is, how it runs, where it breaks, and why the best teams building with agents spend as much time thinking about the failure cases as the success cases.
So let’s get into it.
The Loop, Explained
At the heart of every AI agent is a cycle. You will see it called different things — the ReAct loop, the plan-execute cycle, the agent loop, the think-act-observe pattern. The terminology varies; the underlying structure does not.
It goes like this:
The agent receives a goal. Not a prompt in the traditional sense — not “write me a summary of X” — but an objective: “research our three main competitors and produce a briefing with pricing, recent product launches, and estimated market position.” The agent doesn’t just respond to this. It reasons about it. What does it need to know? What steps will get it there? What tools are available? This initial reasoning phase produces a plan — sometimes explicit, sometimes implicit in the sequence of actions the agent begins to take.
Then it acts. It calls a tool — searches the web, runs a query, reads a file, executes a piece of code. Something in the world changes, or information is retrieved. The agent observes the result of that action and incorporates it into its understanding. Then it reasons again: given what I just learned, what should I do next? Is this what I expected? Has something changed that requires me to revise my plan?
And then it acts again. And observes again. And reasons again.
This continues — sometimes for three steps, sometimes for thirty — until the agent determines that the goal has been achieved, that it cannot proceed, or that it needs human input to continue.
That, in its essence, is the loop. Reason. Act. Observe. Repeat.
It sounds almost disappointingly simple when laid out like that. The power — and the peril — is entirely in the execution.
Reasoning: Where the Intelligence Lives
The reasoning step is what separates modern AI agents from the automation tools that came before them. Older robotic process automation systems followed scripts. If condition A, do action B. If that fails, do action C. They were brittle precisely because the world doesn’t follow scripts.
LLM-based agents reason in natural language about what to do next. This matters enormously because it means they can handle novelty. When the webpage redirects unexpectedly, a scripted system crashes or loops. An LLM-based agent can, in principle, recognize that something unexpected happened, reconsider its approach, and try something different. It can interpret ambiguous results. It can decide that a particular source seems unreliable and seek another. It can recognize that a subtask is harder than anticipated and break it down further.
The most capable agents today use what researchers call “chain-of-thought” reasoning — the model essentially talks itself through the problem step by step before deciding what to do. Some frameworks make this explicit, with dedicated “scratchpad” space where the agent reasons before producing an action. Others leave it implicit in the model’s generation process. Either way, the quality of this reasoning is the primary determinant of whether an agent succeeds or fails at complex tasks.
This is also where the famous “hallucination” problem intersects with agent behavior in particularly consequential ways. In a simple question-answer setting, a hallucination produces a wrong answer that a human reader can hopefully catch. In an agent loop, a hallucination in the reasoning step — a false premise, a misremembered fact, an invented tool capability — can send the entire chain of subsequent actions in the wrong direction. By the time the error surfaces in the final output, it may be deeply embedded in work that is otherwise correct, and tracing it back to its origin requires careful inspection.
The field’s response to this problem is not to eliminate reasoning errors (an unsolved research challenge) but to build systems that make them catchable: shorter loops with more checkpoints, explicit logging of reasoning steps, and human-in-the-loop design for high-stakes tasks.
Acting: The Tool Layer
Reasoning without action is just thinking. What makes agents agents is their ability to act — to reach out and do something in the world. That ability is mediated entirely through tools, and understanding the tool layer is essential to understanding what an agent can realistically accomplish.
At the most basic level, tools are functions the agent can call. The model generates a structured output — something like “search the web for: Q3 2024 earnings reports for company X” — and a system layer intercepts that output, runs the actual search, and returns the results to the model. From the model’s perspective, it asked for something and received an answer. From a software engineering perspective, this is function calling: the LLM has been trained to produce structured requests that map to executable code.
The variety of tools available to modern agents is remarkable, and it grows constantly. Web search. Code execution (the agent writes Python or JavaScript, runs it in a sandbox, and gets back the output or error message). File reading and writing. Database queries. API calls to external services — Slack, Gmail, Salesforce, Linear, Notion, whatever a team happens to use. Browser control, where the agent can navigate web pages, click buttons, fill forms, and extract content. Image generation and analysis. Even calls to other AI models.
What you can build with an agent is largely a function of what tools you give it — and crucially, what guardrails you put on those tools. An agent with write access to a production database and no confirmation step is a very different risk profile than an agent that can only read. An agent that can send emails autonomously is a very different kind of system than one that can only draft them for human review. These are not abstract philosophical distinctions; they are the practical engineering decisions that determine whether an agent deployment succeeds or goes sideways.
One nuance worth understanding: the agent does not “know” how to use tools in the way a human programmer knows how to call a function. It generates tool calls based on patterns learned during training and on the tool descriptions provided in its context. The quality of those descriptions matters enormously. A poorly documented tool will be misused or ignored. A well-documented tool, with clear examples and explicit guidance on edge cases, will be used reliably. The craft of building effective agents is, to a surprising degree, the craft of writing good tool documentation.
Observing: What the Agent Learns Mid-Task
After each action, the agent receives an observation — the result of whatever it just did. This might be search results, a code execution output, an API response, an error message, or a confirmation that a file was written. The observation is fed back into the agent’s context, where it becomes part of the input for the next round of reasoning.
This is where agents can either shine or compound their errors.
When observations are informative and interpretable, good agents adapt elegantly. They recognize when a search returned nothing useful and try a different query. They catch an error in their own code, read the stack trace, diagnose the bug, and fix it. They notice that a document they retrieved is outdated and seek a more recent source. This kind of adaptive, iterative behavior is what makes agents feel almost eerily capable when they’re working well.
But observations can also be ambiguous, misleading, or simply wrong. Websites return garbled HTML. APIs return error codes without explanatory messages. Code produces output that looks correct but reflects a logic error the agent doesn’t catch. In these cases, the agent has to decide: try again, try differently, escalate to a human, or proceed on the assumption that the observation is close enough. How an agent handles uncertain or noisy observations is one of the most practically important — and least discussed — aspects of agent design.
The better agent frameworks today invest significantly in structured observation handling: parsing API responses into clean formats before presenting them to the model, providing error messages with enough context to be actionable, and implementing retry logic with exponential backoff when transient failures occur. These aren’t glamorous features. They are the difference between agents that work reliably and agents that work in demos.
Memory: Across Turns, Across Sessions
An agent’s loop runs within a context window — the finite amount of information the model can hold in active attention at once. For short tasks, this is plenty. For longer, more complex tasks, the context window becomes a constraint that shapes everything about how the agent operates.
Short-term memory, also called in-context memory, is simply everything in that active window: the original goal, the history of actions and observations, any documents retrieved, and any intermediate conclusions the agent has reached. As the task grows longer, this fills up. Older information gets pushed out or summarized. The agent may begin to “forget” early context in ways that subtly distort its reasoning — a phenomenon that mirrors what happens in human working memory under cognitive load, and that has some of the same frustrating effects.
Long-term memory addresses this by giving agents access to external stores of information that they can query as needed. A vector database holds past conversations, retrieved documents, or learned facts as semantic embeddings; the agent can search it with a natural-language query and retrieve the most relevant entries. This allows an agent to have something like genuine long-term memory — to recall a preference expressed three sessions ago, to remember that a particular API endpoint tends to fail on weekends, to know the full history of a project even though it doesn’t fit in a single context window.
This is still an active area of development. Questions of what to remember, when to retrieve, and how to handle conflicts between remembered information and current observations don’t have clean answers yet. But the direction is clear: the agents of two years from now will have memory architectures that make today’s systems look amnesiac by comparison.
When the Loop Goes Wrong: Failure Modes Worth Knowing
I mentioned the failed competitive analysis at the top. I want to be honest about failure modes, because this is an area where a lot of agent evangelism gets unrealistically rosy, and where the gap between a demo and a production system can be enormous.
Goal drift happens when an agent loses track of the original objective across many steps and begins optimizing for something subtly different. It set out to find the best pricing data; twelve steps in, it’s meticulously cataloging product feature lists. The outputs look productive. They are not what was asked for.
Sycophantic completion is a subtle one: agents sometimes produce an answer not because they have genuinely accomplished the task but because they have run out of productive approaches and their training inclines them toward providing something rather than admitting failure. The result is an output that looks complete and is not.
Tool misuse occurs when an agent calls the right tool for the wrong purpose, or the wrong tool entirely, because the tool descriptions were ambiguous or the agent’s reasoning about what it needs was flawed. This can range from annoying (a search that returns irrelevant results) to consequential (a write operation executed when a read was intended).
Context poisoning happens when bad information early in the loop corrupts everything that follows. The agent reads a source that is wrong, incorporates that wrongness as established fact, and builds all subsequent reasoning on a flawed foundation.
Infinite loops are exactly what they sound like: agents that get stuck repeating the same action-observation-reasoning cycle because each round of reasoning produces the same plan, which produces the same result, which produces the same reasoning. Good frameworks implement loop detection and hard iteration limits. Not all of them do this well.
Knowing these failure modes is not a reason to be pessimistic about agents. It is a reason to design for them deliberately — to build systems with checkpoints, logging, and human oversight calibrated to the stakes involved. The teams getting the most value from agents are the ones who have looked their failure modes in the eye and built accordingly.
The Loop in Practice: A Concrete Example
Abstract architecture discussions are fine, but I find it helps to walk through a real scenario.
Imagine an agent tasked with the following: “Find all invoices over $10,000 in our accounts payable folder from Q1, check each vendor against our approved vendor list, flag any that aren’t approved, and draft a summary report.”
Here is what the loop looks like in practice:
The agent reasons about the task and identifies the steps: access the AP folder, retrieve invoices, filter by date and amount, access the vendor list, cross-reference, identify discrepancies, draft report. It calls the file system tool to list the contents of the AP folder. It observes a list of 47 files in various formats. It calls the file reading tool on each one — or, if it’s well-designed, it runs a batch operation. It parses the extracted data, filters by date and threshold, and produces a structured list of 12 invoices meeting the criteria. It retrieves the approved vendor list. It cross-references the 12 vendors against the list and identifies 2 that don’t appear. It reasons about how to handle edge cases — one vendor name is slightly different; is this a discrepancy or a formatting variation? It flags both to be safe. It drafts a report, including the list of invoices reviewed, the flagging methodology, the two vendors of concern, and a recommendation to verify before payment approval. It presents the output for human review.
That’s eleven to fifteen distinct steps, each involving a tool call and an observation. The whole thing might run in under two minutes. A human doing it carefully might take two hours.
And if it goes wrong? If the agent misidentifies a date format and excludes half the invoices? If the vendor list is stored in a format the file reader can’t parse? These aren’t hypothetical risks — they are the kinds of things that happen in real deployments, which is why the output “for human review” is not optional boilerplate. It is load-bearing.
What This Means for How You Build (and Use) Agents
If you are building agents, the lessons from the loop are practical:
Design for observability first. Log every reasoning step, every tool call, every observation. You cannot debug what you cannot see, and you will need to debug.
Match autonomy to stakes. The more consequential the action — sending a communication, writing to a database, processing a payment — the more important it is to have a human in the loop before execution. Not after. Before.
Write tool descriptions like you are writing documentation for a clever but literal-minded colleague who has never used your system. Because that is, essentially, what you are doing.
Build in explicit failure recognition. Give your agent the ability to say “I don’t know how to proceed” and surface that to a human, rather than producing a confident output that obscures the problem.
If you are using agents rather than building them, the lessons are different but related: understand what loop your agent is running, know what its tools can and cannot touch, and treat autonomous outputs that haven’t been reviewed as drafts, not decisions.
The Loop Is the Agent
What I keep coming back to is how much the agent loop is not just a technical architecture but a kind of philosophy. The loop embodies a specific claim about intelligence: that thinking and acting are inseparable, that understanding improves through engagement with the world, that good decisions emerge from the cycle of hypothesis and feedback rather than from pure reasoning in isolation.
That is not a new idea. It is, in fact, a very old one — something any scientist, craftsperson, or thoughtful practitioner would recognize. What is new is that we have systems capable of running this cycle at machine speed, at scale, across domains that no single human could master.
The loop is not perfect. It fails in predictable and unpredictable ways. It requires careful design, honest evaluation, and ongoing human oversight. But when it works — when an agent reasons clearly, acts purposefully, observes accurately, and adapts intelligently — it is genuinely remarkable to watch.
And we are only just beginning to understand what it can do.
Next in the series: Many Minds — How Multi-Agent Systems Divide, Conquer, and Collaborate
Have any thoughts on this post? I’d love to hear them — drop a comment below. Are you building with agents, deploying them, or just trying to make sense of what’s coming? What’s working, what’s breaking, what’s surprising you? The best conversations I have about this stuff happen in the comments, and this topic in particular feels like one where the people closest to the work have perspectives that deserve to be in the room. See you down there.