6: Analysis, Automation, and Agents

What Makes a System an Agent?

The word "agent" is used loosely in marketing material, which makes it worth defining precisely. An agent is a model placed inside a loop with tools. It examines a goal, decides whether a tool would help, uses it, reads the result, and repeats — continuing until the goal is met or it fails. That loop is the entire difference between an agent and the ordinary assistant discussed in earlier chapters, which responds once, in text, with no means of checking anything or acting in the world. It is possible to create multiple agentic systems in parallel for different purposes and use an orchestration layer to direct agents to complete portions of a large and complex project. For example, one agent could manage data analysis, while another creates charts and graphs, while a third compiles a written report incorporating all of those elements. Four components make a system agentic. There is the model, which makes the decisions. There are standing instructions telling it which tools it may use and how. There are the tools themselves, each performing one narrow function. And there is the loop: the surrounding mechanism that actually executes each tool call and returns the result for the next round of decision-making.

^{Image generated by Nano Banana 2 through Google Gemini}

There are two implications to the way these systems are built. First, it is important to note that the intelligence resides entirely in the model, not in the loop or the tools, which is why substituting a more capable model into the same arrangement produces better decisions within an unchanged structure. Second, an agent is not free: every pass through the loop costs time and money and introduces another opportunity for error. The arrangement earns its cost on open-ended, multi-step work that benefits from iteration, and is poor value for a single lookup or a one-shot piece of writing, where a direct request is faster and more predictable. Agentic systems function best for complex but repeatable process where the outputs can be dialed in so that the system functions consistently and dependably.

The Model and the Tools Are Different Things

When an AI assistant searches the web, checks a calendar, or performs a calculation correctly, the natural conclusion is that the assistant has become more capable. It has not. As we touched on in Chapter 3, two separate components are at work, and keeping them separate is the key to understanding the whole category. The language model's job is to interpret what is being asked, determine which tool, if any, would help, translate the request into the precise form that the tool requires, and then incorporate the tool's raw result into a readable answer. The tool's job is much narrower: perform one specific operation reliably and do nothing else. The intelligence lies in recognizing that a task should be delegated and to what — not in the delegated operation itself. This distinction is foundational for understanding agentic systems, but it also has diagnostic value as well. When an agentic system produces a bad result, the failure is locatable. Did the model misunderstand the request, select the wrong tool, or phrase the query to the tool incorrectly? Those are all failures of the model. Did the tool itself return incorrect or incomplete information? That is a failure of the agent, and no amount of better prompting will fix it. A further point corrects a common assumption. Retrieval — the ability to look something up in an external source and use it — is access, not memory. The model uses the retrieved material for the current response, and unless the system has been specifically built to store it, that material is gone afterwards. A retrieved fact can be wrong without becoming a permanent, trusted part of what the system believes. Memory is a different capability, and as the next section shows, a more consequential one.

Memory, Persistence, and Responsibility

A simple assistant that forgets everything when the window closes has a limited capacity to cause harm. A system that persists — retaining preferences, holding a calendar, acting on someone's behalf — belongs to a different category, and the difference is practical rather than philosophical. Consider what happens to an error in each case. In a system without memory, a hallucination is an isolated mistake: it can be dismissed, and the next conversation begins clean. In a system with long-term memory, the same fabricated detail may be stored and then resurface weeks later as though it were established fact, shaping later answers without anyone having verified it. The initial error is not corrected by time; it is entrenched by it. The stakes rise again once a system can act rather than only write. A misunderstood instruction that produces a poor paragraph is an inconvenience. A misunderstood instruction that books the wrong travel, sends the wrong message, or deletes the wrong file produces consequences that are financial, reputational, or irreversible. The ability to act converts an information source into something that operates in the world, and the standard of reliability required rises accordingly.

Keeping the Human in the Loop

The practical question raised by everything above is not whether to permit automation but where to place the point at which a person must approve. That placement is a judgment no tool makes for you, and it follows directly from the risk analysis in Chapter 4: the checkpoint belongs wherever the cost of being wrong is concentrated. Current agentic systems can be given approval to do almost anything automatically, but without guardrails costly mistakes can easily be made. It is best to build instructions into the loop that tell the model when to stop and ask for permission, while also enabling a second layer of controls at the system administration level. Typical controls include token budgets (without which agent costs can easily escalate), specific folder or file editing limitations, and level of permission requirements. In addition, it is important to be deliberate about what a persistent system is permitted to retain, since stored information shapes future behavior invisibly. Treat a system's recollection of earlier interactions as something that can be wrong, and verify it when it matters, rather than assuming that anything remembered has been checked. Insist on human approval for actions that are expensive, irreversible, or visible to other people — which is a narrower category than approving everything, and a far safer one than approving nothing.

Conclusion

The unifying idea of this chapter is that capability and responsibility increase together. Adding tools to a model does not make it more intelligent; it extends the reach of a system whose judgment is unchanged. Adding memory does not make it more reliable; it makes its errors more durable. Adding the ability to act does not make it more trustworthy; it raises the cost of the errors it was always capable of making. None of this is an argument against using such systems, which are genuinely useful for open-ended, multi-step work. It is an argument for designing the oversight deliberately rather than discovering afterwards that none was in place. Chapter 7 takes up the professional dimension of that responsibility: disclosing how AI was used, explaining it to people who are not technical, and applying it honestly to your own career.