Most AI tools start fresh or keep a notes file

Most AI assistants start each conversation with no memory of the last one. Some keep a notes file: a list of facts and instructions that is added to the next conversation. That helps, but notes are only text. The model has to read them, decide whether they apply and then follow them correctly. Nothing in a notes file can run.

A business needs more than notes. If your team fixes the same supplier layout every week, the fix should become a procedure that runs every time, not a reminder the model may or may not read.

The AI builds the tool it is missing

Most AI agents have a fixed set of tools chosen by their developer. When they meet a problem none of those tools can handle, they stop and ask a person. The Buffaly article Buffaly Builds Its Own Tools (Matt Furnari, June 14, 2026) describes a different design. When Buffaly hits a gap, it can write a new tool, load it into the running system and use it without a restart.

The article analyzed 1.2 million messages and more than 380,000 tool calls from a real Buffaly instance. Of the new tools it created, 70% were used in the same session they were written. In other words, most were built to solve the problem in front of it, and then used straight away.

One example from the article: an agent debugging a failure found logs in an old, undocumented format. Instead of asking a person to pull the data out, it wrote a parser for that format, loaded it, and turned the logs into a table it could search.

Illustration titled Hit a gap, build the tool, keep working. A loop of four steps reads Missing tool, Write it, Load it and Use it now. A bar at the bottom reads: The fix stays for the next job.
Figure 1. When a needed tool does not exist, the system writes it, loads it and uses it in the same job, and the tool stays available afterward.

An example: a PDF in a new layout

Suppose, as an example, a supplier starts sending its price updates as a PDF in a new layout. An assistant with a fixed set of tools stops and asks someone to type the prices in. A system that can build tools writes handling for the new layout, checks what it read against the PDF, and keeps that handling as a procedure. The next PDF from that supplier is read the same way, without anyone asking.

This happened in a real migration. When a flooring distributor moved off Zoho, staff kept working in the old system during the parallel run and emailed the PDF files it produced, and agents entered them in the new system. The handling for those PDFs was not written in advance. The agents built it themselves while the work went on, in the way the article above describes.

What it learned on its own

Building a tool on request is one step. Deciding for itself what is worth keeping is the next. The Buffaly article We've Solved Online Learning (Buffaly blog, September 2026) describes two reviewers that run alongside the working agent:

  • A memory reviewer learns things and how they relate, such as which system owns a service or which repository a backup protects.
  • An action reviewer learns reusable procedures, and corrects ones it has already learned when they turn out to be wrong.

What they learn is kept first in the working session where it was found. Items that prove useful are borrowed by other sessions, used and improved. One-off details stay where they mattered.

The article reports a September 8 snapshot of the Buffaly instance it studied:

  • 10,653 working sessions.
  • 6,157 entities (things it knows about) and 3,371 actions (procedures it can run).
  • Of those, 4,679 entities and 1,204 actions were learned on its own during sessions.

The article also shows learning that improves with use. A learned copy-and-check procedure was later reused to deliver 310 screenshots, and every copied file matched its original. A learned backup procedure wrote its timestamp into file names incorrectly. The reviewer corrected the code, and later runs show the right names.

What this means for a business over months

The instance in that article had been running since late February when the September snapshot was taken. Its thousands of learned entities and actions built up from ordinary daily work, not from a project to write rules.

For a business, the same mechanism applies to the details that today live in people's heads. Suppose, as an example, a flooring distributor runs order entry through such a system:

  • A customer's own part number turns out to always mean one of your items. That link is learned once and used on the next order.
  • A supplier's PDF layout is handled once and kept as a procedure.
  • A step your team always checks by hand becomes a procedure that runs every time.

Each of these is small. Over months they add up to a system that has already seen much of what arrives. Automate order entry from emailed PDFs shows where this fits in order entry, and What an ontology is, explained for business owners explains the model the learning is added to.

What it can learn versus what it is allowed to do

Learning a new procedure must not give the AI new permission. The online learning article says it plainly: search makes a learned capability discoverable, not automatically loaded or authorized.

For commerce, that means price changes, approvals, credits and invoices stay behind checked actions whose rules are written in code, however much the AI learns. A procedure that reads a supplier's PDF faster still produces draft records that a person or a checked rule approves. Can you trust an AI agent with orders, prices and invoices? explains how those checks work.

Illustration titled Learning grows, permissions stay fixed. Rising green blocks are labeled What it has learned. A locked gate is labeled What it may change, with the note Checked every time. A bar at the bottom reads: New skills do not bring new permissions.
Figure 2. What the system learns keeps growing. What it is allowed to change stays behind checked actions.

Questions to ask a vendor

  • When your AI meets a document layout it has not seen before, what happens: does it stop, guess or add handling?
  • Is what it learns kept as notes the model reads, or as procedures that run?
  • Can we see what it has learned, and correct or remove it?
  • Can anything it learns change what it is allowed to approve, price or post?
  • How is a learned procedure checked before it is used again?

Send us the task your team repeats every week

Tell us one job your team does by hand every week: a supplier file, a customer's part numbers, a check before an order goes out. We will show you what the system would learn from it, and what would stay behind a person. Tell us about your current system, or read how full service works.