How AI uses tools and memory

Training is the only thing that puts information inside a model. Nothing a company wrote after the training run, and nothing it kept private, is in there. An assistant asked about its own employer’s policies has nothing to draw on, and answers anyway.

Everything else a model appears to know about a specific business arrived in the context window for that one request, put there by the system around the model. Almost all production AI is built out of exactly that: things the model can call, and things placed in front of it before it answers.

Tools

A tool is anything the model can call to do something that writing text cannot do.

The simplest one is a calculator, and it fixes a failure the model has on its own: models handle a surprising amount of mathematics and stay brittle on long arithmetic.

Example

Let’s say someone asks for 23% of 184,592. A model on its own writes a plausible number. Given a calculator, it writes out the call instead, gets 42,456.16 back, and is reliably right.

The common ones:

• Web search. Questions about recent events stop being a guess and become a search plus a summary.
• Database query. “How many open tickets are there on the new release” becomes a query against the ticket system.
• File access. Reading documents at volume rather than one paste at a time.
• Company systems. Your CRM, the billing system, the scheduling tool, each reached through the API it offers.
• Code execution. The model writes a few lines of Python and runs them in a walled-off space where they cannot touch anything else, then uses the result.

The pattern never changes. The model produces a structured request naming the tool and the input, the system runs it, the result comes back into the context, and the model carries on with the result in hand. When you hear that an assistant “can search the web” or “can run code”, that is tool use.

For a long time every one of those connections was custom. A tool built for one assistant did not work with another, so connecting a company system meant a separate integration project per assistant. There is now a common standard for it, MCP, which is why connecting an assistant to the CRM has moved closer to configuration than to a build. What a connection to a company system actually is, and what it costs to let one write rather than read, is the next chapter.

What the product remembers

The major assistants now keep notes between conversations. Nothing inside the model changes from one day to the next: the model is a fixed set of weights, identical for every user of that product. What changes is the notes the product keeps. While you chat, it writes short entries about facts that look durable, and at the start of a new conversation it puts the relevant ones into the context window ahead of your message. The model reads them the way it reads anything else in front of it. This is memory, and the product is the part that remembers.

Example

Let’s say a support lead opens a new chat on Monday morning and it already knows that her business runs a 40-person support desk, that numbers should come back as a table, and that “the Q3 deck” means one particular file. None of that sits inside the model. The product wrote those entries during earlier chats and placed them in front of the model before her first message.

It is on in most places by default. Claude stores memory as individual entries organised into categories, written and updated as the conversation runs, with a separate memory space for each project. ChatGPT combines facts you have asked it to save with facts it draws from past chats in the background. Gemini’s version is opt-in, tied to keeping activity history, and is not available on work or school accounts, which is worth knowing before assuming a team has it.

What memory holds is a summary the product chose, not a record of what was said, and it can be quietly wrong until an answer leans on it. It does not travel: move the same work to a different assistant and it starts from nothing. And it is not access to the company’s systems. Remembering that the business runs support on a particular helpdesk is a long way from being able to read a ticket in it.

Memory carries a summary of past conversations. Answering from the company’s own documents needs the documents.

When the answer lives in a document

A model that has never seen a policy page still answers questions about it, in clean English, wrongly.

Example

Let’s say a support lead pastes a customer complaint into an assistant and asks what the refund terms are. The answer comes back correctly formatted and wrong: 14 days, no photograph needed. The actual policy is 30 days and a photograph of the damage. Nothing malfunctioned. That page has never been in front of the model.

One fix is to put the whole document in front of it, which is more viable than it used to be. A million tokens, the units models count text in, is standard at the top of the range and works out at roughly a couple of thousand pages, so pasting one contract set or one product’s full manual into a single request is a real option. Two things stop it generalising. Published limits are not working limits: measured quality usually falls off well before the number on the spec sheet. And a company’s documents run far past a manual once tickets, contracts, wiki pages and email threads are counted, they change every week, and re-reading all of it would be paid for on every question.

So the standard approach fetches only the passages that bear on this question.

1. Take the documents and cut them into passages.
2. Turn each passage into a numerical fingerprint, and store the fingerprints in a database built for finding near matches.
3. When a question arrives, fingerprint the question the same way.
4. Pull the passages whose fingerprints sit closest to it.
5. Paste those into the context with the question, and let the model answer from what is now in front of it.

This is retrieval-augmented generation, RAG for short, and almost every “ask questions of our internal documents” product is some version of it. It is also one of the 3 ways to adapt a model to a business, the one that fits when the gap is knowledge rather than behaviour.

Watch RAG run · one stage at a time

0 / 5

Click Start to watch a RAG request from question to answer.

Start →

Where it goes wrong

The citations at the end of that demo tell you which passages the answer was built from. That is traceability and it is worth having. It is not a check on whether the answer is right, because it says nothing about what never came back.

Step 4 is where most of the failures start.

Example

Let’s say the same refund question arrives from a wholesale customer. The passages that come back are from the consumer returns policy, which is worded almost identically; the wholesale terms sit in a contract addendum nobody indexed. The model answers fluently from the material it was handed, and gives a consumer answer to a wholesale question. It cites the consumer returns policy accurately, and that passage does say what it is quoted as saying. The citation is right and the answer is wrong.

Most production retrieval failures are this shape: the right passage never came back, either because it was never in the index or because something more similar-looking outranked it. The model did not make anything up. It was handed the wrong material and did its job on it.

Why the system around the model matters more than the model

Products that answer questions about a company’s own information sit on a model anyone else can rent. The base model is close to a commodity. The work that differs from one product to the next is all around it:

• How data sources get connected.
• How documents are cut up and filed so the right passage can be found.
• How the system ranks passages against a question.
• How updates flow through when a document changes.
• What it does when nothing in the index actually answers the question.
• Whether it shows its sources, so an answer can be traced back to the passages behind it.

Most of the engineering effort in any serious “AI for our company” product goes into that list, not into the model. Retrieval, tools and memory are 3 of the 5 parts a team is actually building when it builds AI.

What this looks like in the products you already use

Anything that knows things about the business is running retrieval underneath. Anything that does things, books, sends, updates, is running tools, with specific permissions and, in good designs, a record of what was called and why and a clear path for where the data goes. Anything that opens already knowing the account is running memory.

A model with none of the three can only work on what someone types into it. That still covers real work: drafting, rewriting, the things a model handles well on its own. For everything past that, and for anything that goes on to act as an agent, this layer is the product.