Explainer
"Self-learning" appears on a great many product pages and means three different things on them. When an AI agent is said to learn, either the model changes, what the model is shown changes, or the instructions it follows change. Those three have almost nothing in common - not in cost, not in who can inspect the result, and not in how you fix it when it learns something wrong. Only the second and third happen in Olano. This page says which is which, and why we think a text file is the better answer.
The model changes. This is training and its smaller cousin, fine-tuning: the model's weights are adjusted against a body of examples until it produces different output. The result is a new model. It is the meaning most people assume, because it is the one that sounds like learning, and it is the one that almost never happens inside a deployed agent. It is slow, it needs a large set of curated examples, and it produces something nobody can read - a wrong lesson is stored as numbers, and there is no line to find and delete.
What the model is shown changes. The model is exactly the same on day three hundred as on day one. What differs is the text placed in front of it before it answers: notes about your business, facts about your customers, documents it can look up. This is memory and retrieval, and it is where nearly all of the learning in a working agent lives.
The instructions change. The same model again, but the procedure it is told to follow has been rewritten - a step added, a format tightened, a caveat inserted after a conversation showed it was missing. This is what skills and operating instructions are.
One sentence needs saying plainly: an Olano agent's underlying model does not change because of anything your agent does or sees. Nothing in the platform adjusts weights. What changes is what the agent remembers and how it works, and both of those are files.
Same word, three mechanisms, and the differences an operator actually feels.
| The model changes | What it is shown changes | The instructions change | |
|---|---|---|---|
| Also called | Training, fine-tuning, retraining | Memory, retrieval, a knowledge base | Skills, procedures, operating instructions |
| What is produced | A new set of model weights | Text the model reads before it answers | Text the model follows while it answers |
| Can a person read it | No. Weights are numbers, and nobody can read what was learned from them. | Yes. It is markdown in the agent's workspace. | Yes. A skill is a folder with a markdown file in it. |
| Correcting a wrong lesson | Collect counter-examples and run the whole process again. | Edit the file. The correction applies on the next reply. | Edit the procedure. Revision history shows what it said before. |
| Switching to a different model | The lesson stays behind with the old model. | The same files are read by whichever model you choose. | The same. |
| In Olano | Never. | Yes - daily logs, long-term memory and the knowledge base. | Yes - learned skills and proposed edits to instructions, under approval rules. |
Two mechanisms, and both leave text you can open in the dashboard.
Self-learning is on by default and runs in the background. It reads recent conversations, distils what is worth keeping, and writes it into two places: a dated daily log for that day, and a curated long-term memory file, MEMORY.md, for facts that should outlast the day. A weekly pass re-distils, so the long-term file stays a summary rather than becoming a transcript. Before every reply the agent reads MEMORY.md plus today's and yesterday's logs. That is the whole mechanism by which a correction you made on Tuesday is in front of the model on Wednesday - nobody edited a prompt, and no model was touched.
The knowledge base is the other half, and it is deliberately different. Documents you add - manuals, price lists, policies, past proposals - are indexed and searched when a question calls for them, and the agent quotes what it finds. Nothing is memorised. When the price list changes you replace the document, and the next answer comes from the new version. Memory holds what the agent has learned; the knowledge base holds what is true right now.
The memory stack and the memory and knowledge chapter cover the layers in more detail. The point for this page is narrower: every one of them is text.
Memory records what happened. Cortex is the engine that turns repeated work into procedures, and it runs per agent on a schedule you set - relaxed, balanced or aggressive - with a Think button for running it now.
When the same procedure keeps recurring - the same report assembled the same way, the same enquiry handled with the same steps - Cortex drafts it as a reusable skill: a folder with a markdown file and any scripts it needs, owned by that agent and listed in its Skills tab as a learned skill. The agent then has a written procedure to follow rather than reconstructing it each time.
Proposed edits to the agent's own operating documents: the phrasing that caused a misunderstanding, the check a conversation showed was missing. Under Fully Autonomous a sharper procedure is applied on its own and logged. An edit to the agent's identity documents - SOUL.md, AGENTS.md, IDENTITY.md - is different: it waits for a person whichever way the switch is set. See the approval table below.
A tidy-up pass over the memory files: duplicate facts merged, old daily logs rolled up. It is snapshotted before it runs and can be undone in one click, so a tidy-up that removed something you wanted is a click away from coming back.
The same tidy-up over learned skills: duplicates merged, the survivors polished. Also snapshotted, also undoable.
Two things steer all of this. The intensity preset sets the cadence and a daily cap on deep-reasoning runs, so the improvement loop costs what you decide it costs. And an optional per-agent guidance file, CORTEX.md, with Goals, Dreams and Avoid sections, tells the generative phases what to pursue. It is editable in the dashboard, and it is the first thing worth writing: an engine told what you are trying to achieve produces relevant work, and one left on the default scaffold produces generic work.
Notice what is on that list and what is not. Skills, memory, procedures, tidy-ups. Every one of them is a file being written or rewritten. There is no phase that touches the model, because there is nothing there to touch. Inside Olano Cortex goes deeper into the engine, and the Cortex docs cover the settings and the phase schedule;how an AI agent learns a new skill follows one lesson end to end.
Fully Autonomous is on by default. Three categories wait for a person whichever way the switch is set.
| Change | Fully Autonomous on (the default) | Fully Autonomous off |
|---|---|---|
| Distilled memory, a new learned skill, a sharper procedure | Applied on its own. Logged. | Queued for approval. |
| A Pulse suggestion that carries a concrete action | Executed on its own, unless it falls into one of the three rows below. Logged. | Queued for approval. |
| Tidy-ups: memory garden, workspace consolidation, skill-library dedupe | Applied on its own. Snapshotted, one-click undo. | Queued for approval. |
| Rewriting the agent's own instructions (SOUL.md, AGENTS.md, IDENTITY.md) | Waits in Approvals, under Pulse, for Approve or Reject. | Waits in Approvals, under Pulse. |
| Sending anything outside the deployment - email, calendar, posts, messages to other agents | Waits for a person. | Waits for a person. |
| Anything that cannot be undone - moving money, overwriting a stored secret | Waits for a person. | Waits for a person. |
The bottom three rows are the per-agent approval_required list, and they hold in either mode. A deployment owner can lift the hold for a specific agent by emptying that list; it is never lifted by default. The reasoning behind the split is in approvals and trust, and it is worth stating here in one line: a click on every distilled memory would teach your team to approve without reading, which is the worst thing that can happen to the queue that does matter.
Four things the vague version of "self-learning" lets people assume, and the honest answer to each.
No weights are adjusted, on any plan, by any phase. The model you chose is the model you have. If you swap it for another, the memory files and skills are read by the new one - which is why learning survives a model switch here and would not survive one under fine-tuning.
Learning is confined to the agent's own deployment, which is an isolated deployment and not a shared tenancy. What your agent learns about your customers is in your files. It is not a signal that improves anyone else's agent, and nobody else's agent improves yours.
The model's reasoning is whatever the model you chose can do, on day one and on day three hundred. What improves is what the agent knows about your business and how reliably it follows your procedures. That is worth having. It is not an intelligence gain, and a vendor who describes it as one is describing the model, not the agent.
Every autonomous change is logged in the Cortex Activity view, and every edit to a memory or instruction file - by the agent or by a person - is a revision you can open, attributed to whoever made it. "What did it change last Tuesday" has an answer.
Everything above could be read as a limitation. We think it is the design, for four reasons that only hold because the learning is text.
You can read it. The Memory tab is a direct view of the agent's long-term memory, as an outline, as rendered text, or as raw markdown. If you want to know what the agent believes about a customer, you look. Under fine-tuning the same question has no answer - the belief is distributed across numbers that mean nothing individually.
You can correct it. An agent that has learned something wrong is fixed by editing one line of MEMORY.md, from the dashboard or a text editor, and the fix takes effect on the next reply. There is a quick-add form for the reverse case, when you want to tell it something rather than wait for it to notice. Under fine-tuning, a wrong lesson means collecting counter-examples and running the process again, and hoping the new model has forgotten the wrong lesson and nothing else.
You can undo it. Configuration and memory files have a revision history, each change attributed to the agent or the person who made it, and Cortex's tidy-ups are snapshotted with one-click undo. The unit of change is a file, which is a unit a person can reason about.
It comes with you. Memory in files is memory the model does not own. Switch to a cheaper model for routine agents, or a stronger one for a hard job, and they read the same files. Multi-model agents work because the learning lives in the platform rather than in the model.
There is a fifth reason, and it is less comfortable. A wrong fact in a file is a visible problem. A wrong lesson in a fine-tuned model is an invisible one. A system whose mistakes can be seen is a system that gets corrected; a system whose mistakes cannot be seen is a system that gets trusted until it is not.
The honest design has a cost, and it should be named: everything above relies on someone occasionally reading. Two things go wrong when nobody does.
The queue nobody opens. Proposals to rewrite the agent's own instructions wait in Approvals in either mode. If nobody opens it, the agent keeps working with the instructions it had. That is the safe outcome - the platform does not apply an identity edit on its own unless a deployment owner has lifted that hold for the agent - but it is also a month of sharper instructions sitting unread, and eventually a queue long enough that whoever finally opens it approves in bulk, which is the outcome the queue exists to prevent.
The memory file nobody reads. Self-learning distils what it sees. If a conversation contained a confident wrong claim, the distillation can carry it into memory, and from there into every conversation after it. The fix is a one-line edit. It only happens if someone looks.
The practical answer is the one in the Cortex documentation's starting configuration: enable it for one agent first, switch Fully Autonomous off for that agent to begin with (it is on by default) so you see the proposals and can judge their quality, and come back in a week to read the Activity log and the memory file. If the output is good, turn Fully Autonomous back on. If it is not, sharpen the guidance file rather than turning the engine off. Either way, you have read what the agent learned - which is the one thing no fine-tuned system can offer you.
Yes, but in a specific sense. In almost every deployed agent, learning means that what the model is shown changes (memory and retrieved documents) or that the instructions it follows change (skills and procedures), while the model itself stays the same. Training or fine-tuning the model is a third meaning and almost never happens inside a working agent. Olano does the first two and never the third.
No. Fine-tuning adjusts a model's weights against a set of examples and produces a new model that nobody can read. A self-learning agent in Olano keeps the same model and writes what it learns into markdown files - a daily log, a long-term memory file, learned skills - that are read before each reply. The result is inspectable and correctable by editing a file, which a fine-tuned model is not.
A background self-learning loop reads recent conversations, distils what is worth keeping, and writes it into a dated daily log and a curated long-term memory file. A weekly pass consolidates. Before every reply the agent reads the long-term file plus today's and yesterday's logs, so a lesson from one conversation is in front of the model in the next. Cortex goes further by drafting repeated procedures as reusable skills.
Yes, by editing the file. Long-term memory is a markdown file in the agent's workspace, editable from the dashboard's Memory or Files tab or any text editor, and the edit takes effect on the next reply. Learned skills are folders you can open and change. Every edit, by you or by the agent, lands in a revision history, and Cortex's tidy-ups are snapshotted with one-click undo.
It gets more useful, which is different. The model's reasoning ability is fixed by the model you chose. What improves is what the agent knows about your business, your customers and your procedures, and how consistently it follows them. That compounds, but it is knowledge and procedure improving, not intelligence.
No. Learning is confined to the agent's own deployment, and each Olano customer has an isolated deployment rather than a shared tenancy. Nothing your agent learns is pooled, used to improve a shared model, or visible to anyone else's agent.
Where to go next.
The improvement engine: cadence, the Fully Autonomous switch, and what waits for a person.
The settings table, the phases, the daily budget and a sensible starting configuration.
What survives a restart, a model switch, a new device and a deletion - layer by layer.
Trust levels, approval categories and why identity edits wait for a person in either mode.
If a vendor says its agent learns, ask to read what it learned last week. We will show you the file, the daily log it came from and the revision that wrote it - and tell you plainly whether your workflow would improve from any of it.
