Every plant has a story about the expert who retired and took the know-how with them. The machine still runs, but nobody quite knows why the settings are what they are.
Bots have that problem every night.
Organizational knowledge in ISO
ISO asks an organization to work out what knowledge it needs to run its processes, keep that knowledge, and make it available. And to think about how to get new knowledge when things change.
The goal: knowledge belongs to the organization, not just to someone's head.
Where bot knowledge lives
A bot's "head" is its chat, its context window. See Context windows. That's where it works. But it doesn't last.
- When the chat ends, it's gone.
- When the chat gets long, it gets shortened, and details drop. That's compaction.
So anything a bot learns in chat is like know-how in a retiring expert's head. Useful today, at risk tomorrow.
| Where it lives | ISO parallel | Survives the night? |
|---|---|---|
| Chat | An expert's head | No |
| Saved memory | Personal notebook | Yes, if kept short and accurate |
| Skills and principles | Controlled procedures | Yes |
| Records | Retained documented information | Yes |
The come-back-tomorrow test
What is a bot? uses a simple test: close the chat, come back tomorrow. Does the bot still know who it is, what it's for and what you taught it?
That's the organizational knowledge test, for one bot.
Capturing knowledge
The habit that makes it work: when something worth keeping comes up, it goes into a file.
- A correction becomes a rule in a skill. "Should this be the new default?"
- A decision becomes a record.
- A preference goes into saved memory.
- A lesson from a mistake becomes a check in the test script.
Short and current beats long and stale
More knowledge isn't always better. A memory file that grows forever starts to contradict itself. Old preferences linger. Keep core memory short. Put details in skills. Review now and then and remove what's out of date.
Lessons the next job can find
Most companies already have a lessons-learned archive: old corrective actions, project reviews, complaints. The trouble was never writing lessons down. It was finding the right one when the next job starts.
A bot doesn't mind reading three hundred old reports, and it can match them by meaning, not just keywords. An old report about cracked brackets after a paint bake can match a new job about heat-treating a mounting plate.
- Make it a standing first step. Before a new project, quote or change, the bot searches the archive.
- Ask for a short list. Five to ten matches, each with its source, what went wrong then and why it might apply now.
- A person reads the list and throws out the matches that only sound related.
- Write new lessons so they can be found: the part, process, customer and supplier by name, what happened, the cause and fix, and a date. A bot can draft that entry at the end of every 8D or after-action review.
A bot only has what was written, so thin entries give thin matches.
A real example
Our AN Creation office bots start each session by reading their files, not by remembering. The startup skill tells them where things are. The plan file says what's in progress. The records say what was decided. A bot that was shut down last night picks up this morning from the files, and it's the same bot.
Knowledge across a team
With several bots, knowledge should live where all of them can read it, in one place. In our setup, bots share one computer, so a shared folder works. See Your bots share one computer.
Where bots differ
A person keeps a lot of informal know-how even if nobody writes it down. A bot keeps almost none. So for bots, "write it down" isn't a nice-to-have. It's the only way the knowledge survives.
What this means for you
- Run the come-back-tomorrow test on each bot.
- Move anything important out of chat and into a file.
- Keep memory short and current.
- Share team knowledge in one place.
A bot's knowledge is only as durable as its files.