Reasoning, Actions, Memory

Ask ten people in a large organisation what an AI agent is and you will hear nine versions of the same answer: it is a chatbot that is better at its job. That answer is comfortable because it requires nothing new. If an agent is a better chatbot, then the plan is to buy a better chatbot, put it behind a login, and move on to the next initiative.

The answer is also wrong, and the wrongness is expensive. A chatbot can tell you what to do. An agent can understand a goal, decide what to do next, use tools, remember useful information, and help complete the task. The distance between telling and completing is not a feature gap. It is the difference between a system that produces text and a system that changes the state of your business.

There is a simple way to hold the distinction in your head. Three words. Reasoning. Actions. Memory. Put those three together and you begin to understand what an agent actually is. Take any one of them away and you have something simpler and safer, which is fine, as long as nobody in the room believes they bought the other thing.

This essay takes the three words apart one at a time, because each of them makes a different demand on your architecture, your controls, and your organisation. And it ends where every honest discussion of agents ends: with the observation that all three capabilities run on the same fuel, and the fuel is context.

Reasoning is the part people think they already understand, because every model on the market can decompose a problem into steps when asked nicely. But there is a meaningful difference between reasoning about a question and reasoning toward a goal, and it shows up the moment the first step returns something unexpected.

A question has one turn. You ask, the model answers, and the interaction is complete whether or not the answer was useful. A goal has an indefinite number of turns and a stopping condition. Reduce the open invoice backlog. Resolve this customer's billing dispute. Find out why last month's regional revenue moved. Reasoning in the agentic sense is the capacity to decide what to do next given a goal, the history so far, and what just came back from the world.

That last clause carries most of the weight. Planning against a fixed picture is a solved problem; planning against a picture that changes after each step is where agents earn their keep and where they fail. The tool returned an empty result. Two sources disagree. The customer record exists but the entitlement is ambiguous. A single-turn system has no obligation to notice. An agent has to decide whether to retry, reformulate, escalate, or stop.

This is why the book treats an agent as a loop rather than a prompt. Chapter 2 sets out the five capabilities in plain English — answer, reason, plan, use tools, act — and makes the argument that a good agent on a modest model usually beats a poor agent on an excellent model, because the structure around the model does most of the work. Chapter 3 then explains why the reasoning quality you actually observe in production tracks the quality of the working set the model is reasoning over, not the marketing benchmark of the model itself.

There is also a practical failure mode worth naming early. Reasoning without a stop condition is not intelligence, it is expenditure. An agent that keeps planning until it runs out of budget looks thoughtful in a demo and looks like a runaway invoice in production. Every reasoning loop needs three exits defined before launch: success, a defined failure, and a limit measured in tokens, seconds, or currency.

Actions are where the discomfort starts, and the discomfort is appropriate. Once a system can issue a refund, send a message, update a record, open a ticket, or run a job, it has stopped giving advice and started making commitments on your behalf. Every governance question that felt theoretical becomes operational on the day the first tool is wired in.

The useful way to think about actions is as a catalogue rather than a capability. An agent does not have access to your business; it has access to a specific, enumerated list of tools, each with a typed input, a typed output, a documented failure mode, and a known cost. Anything outside the catalogue is refused. This sounds restrictive and is in fact the thing that makes action safe enough to ship.

The tool description deserves particular attention, because it is a piece of context in the strictest sense. It is the model's entire understanding of what a capability does. A description that promises slightly more than the tool delivers will not produce a crash; it will produce a confident, reasonable-looking attempt that quietly does the wrong thing. Inaccurate tool descriptions are not a documentation debt. They are a behavioural defect with a documentation disguise.

This is the territory of Chapter 14, which argues that access control — who may read what — has to mature into action control, meaning what a system may do, under whose authority, within which limits. Chapter 15 covers the machinery that makes it real: approval gates for high-consequence actions, reversibility where reversibility is possible, and audit trails detailed enough to reconstruct a decision months later. Chapter 13 explains why none of this can be inherited unchanged from human governance, since a human who is unsure asks a clarifying question and an agent that is unsure proceeds fluently.

One design rule earns its place in every serious programme: classify actions by consequence, not by convenience. Reads are cheap and reversible. Writes to internal systems are recoverable with effort. Anything that touches money, a customer, or a public surface belongs in a category with an explicit approval path. The escalation path is not a fallback for when the agent fails. It is a feature that makes the high-value actions safe to grant at all.

Memory is the third word and the one most organisations discover late, usually by accident. A stateless system is annoying but honest: every session starts from zero, so every session must be given everything it needs. A system with memory is far more useful and quietly far more dangerous, because it can now be wrong on the basis of something it learned rather than something you told it.

Useful memory comes in several distinct flavours and conflating them causes most of the trouble. There is working memory, which holds the current task and disappears when the task ends. There is episodic memory, the record of what happened in previous interactions with this customer, this account, this incident. There is semantic memory, the durable understanding of how the organisation works and what its terms mean. And there is procedural memory, the accumulated knowledge of which approach tends to work for a given class of problem.

Each of those requires a different retention rule, a different confidence level, and a different correction path. The failure that shows up in real programmes is a single undifferentiated store where a customer's one-off preference, a stale process description, and a canonical business definition all sit at the same authority, retrieved by the same similarity search, and treated by the model as equally true.

The consequence is the most expensive artefact in an agentic system: a wrong memory. A single incorrect answer costs one correction. A single incorrect memory converts that error into an organisational belief, which is then read by a second agent next week and treated as established fact. Errors that write themselves into memory compound; errors that do not, do not.

This is precisely why the book has three chapters on this layer rather than a paragraph. Chapter 10 makes the case for institutional memory as an asset rather than a cache. Chapter 11 treats context as a living layer that decays without review, which is the property that makes memory hygiene an ongoing operational job rather than a launch task. Chapter 12 addresses portability, because a memory you cannot export is a memory you are renting. The companion essay on why memory is the new moat develops the strategic version of the same argument.

It is tempting to treat reasoning, actions, and memory as three separate work streams that different teams can deliver in parallel. In practice they are three faces of one system, and each pair has a seam where value or failure is created.

Reasoning without actions produces a very articulate advisor. It can tell you what should happen and it cannot make anything happen, so the last mile stays human and the promised efficiency never arrives. Most disappointing agent pilots are this: a good planner with no hands.

Actions without memory produce a system that solves the same problem repeatedly and learns nothing. The third time a customer explains their situation, the agent starts from zero again, which is the exact experience customers already hate about being transferred between departments.

Memory without reasoning produces a very well-organised archive that cannot decide anything. And reasoning plus actions without memory produces the most alarming combination of the three: a system with authority to change your business and no record of what it concluded last time it did so.

The pattern is consistent. Each capability multiplies the others and each also multiplies the consequences of weak context underneath. Which brings us to the part of the argument that the three-word framing deliberately leaves implicit.

Reasoning is only as good as the working set it reasons over. Actions are only as safe as the tool contracts and permission boundaries that describe them. Memory is only as trustworthy as the definitions, sources, and provenance attached to what was written down. In every case the determining input is context, not model capability.

This is the central claim of the whole book and the reason it is named what it is. The bottleneck in enterprise AI is not the intelligence of the model; it is the gap between what the model knows and what the organisation knows. Chapter 4 frames context as the first of the four C's and the one that gates the other three. Chapter 6 makes the harder argument that a semantic layer cannot be replaced by better retrieval, because a definition is a decision and retrieval only finds text that resembles the question.

The mechanics matter as much as the principle. Chapter 35 covers retrieval as an engineering discipline — chunking, ranking, freshness against similarity, what to do when two authoritative sources disagree. Chapter 36 covers compaction and the token budget, which is where reasoning quality and cost meet: summarise too aggressively and you delete the detail the answer depended on, summarise too little and every step drags the entire history behind it.

If you want the short version, the essay on why the context window is not context makes the point in one sitting. A larger window gives you more room. It does not give you better meaning, fresher facts, or a decision about which of two definitions is correct.

Traditional software fails loudly. A stack trace, a failed job, a dashboard with a gap. Agentic systems fail quietly, and each of the three capabilities has a characteristic quiet failure worth learning to recognise.

Reasoning fails as a plausible plan built on a stale or partial working set. Nothing errors. The agent proceeds confidently down a path that would have been correct three months ago. The only visible symptom is a result that a domain expert would have questioned and nobody asked.

Actions fail as a correct call to a tool that does something slightly different from what its description promised, or as a legitimate action taken at the wrong scope: the right refund to the wrong account, the right message to the wrong segment. The audit log shows a successful operation.

Memory fails as a confident recollection of something that was never true, or was true until the policy changed in the spring. This is the failure with the longest tail, because it propagates: one agent writes, another reads, and by the time somebody notices, the belief has been cited three times in places nobody is looking at.

The practical response is not more caution in the prompt. It is measurement. A graded set of representative tasks with known-correct answers is the only instrument that tells you whether any of the three capabilities is degrading, and it is the one investment that pays for itself before the quarter ends. Chapter 17 treats evaluation as core infrastructure, Chapter 29 treats it as the professional core of the agentic era, and the essay on why evals are the new dashboards explains why a team without one cannot distinguish between getting cheaper and getting worse.

The framing is not only architectural. It also reorganises who does what, and it does so in a way that is unusually favourable to data professionals.

Reasoning is fed by whoever curates the working set: the definitions, the retrieval scope, the freshness rules, the instructions that frame the question. That is analytics engineering work wearing a new title. The essay on why context engineering is the new analytics engineering makes the case in detail, and it is not a metaphor — the skills transfer almost completely.

Actions are owned jointly by the engineers who build the tool contracts and the risk function that decides which actions need approval. This is the seam where most programmes are thinnest, because the tool catalogue tends to be treated as an implementation detail rather than the permission surface it actually is.

Memory is owned by nobody in most organisations, which is precisely the problem. A memory store written by machines never appears in a catalogue and never acquires a steward. The remedy is the accountability map described in the agent org chart: a named human against every definition, retrieval scope, tool contract, memory policy, and evaluation set. An empty owner cell is a finding, not a formatting issue.

For readers who want the career-shaped version of this, the 30-day path from data engineer to context engineer turns the same three capabilities into a sequence of things to build.

The fastest way to find out where an agentic programme actually stands is to ask three questions, one per capability, and to insist on specifics rather than intentions.

For reasoning: can somebody draw the loop on one page, including every stop condition and the budget limit per request? If the answer involves the phrase it depends on the prompt, the loop does not exist yet.

For actions: can somebody name every tool the agent can call, and for each one state the typed input, the typed output, the failure mode, and whether it requires approval? If nobody in the room can produce the full list, the permission surface is unknown, which means it is larger than anyone believes.

For memory: can somebody show what the system wrote down last week, who is accountable for it, when it expires, and how a wrong entry gets corrected? If memory is described as just the vector store, the organisation has a cache and is treating it as an institution.

Two green answers and one red is the normal starting position, and the red one is almost always memory. That is a solvable problem and it is much cheaper to solve before the store is large than after.

It is worth being fair to the chatbot. Answering questions well is genuinely useful, and a great many workflows need nothing more. The mistake is not building one; the mistake is believing that the path from a chatbot to an agent is an upgrade you purchase rather than a system you design.

The three words are useful precisely because they resist that shortcut. Reasoning requires a loop with brakes. Actions require a catalogue with contracts and consequences. Memory requires ownership, expiry, and correction. None of the three arrives with a model release, and all three are within reach of any team willing to treat context as infrastructure rather than as a prompt.

That is the whole argument, and it is the reason the essay on why the model is not the moat keeps proving true quarter after quarter. Everybody rents the same intelligence. What differs is the reasoning environment you built, the actions you were brave enough to bound, and the memory you decided to own.