In the last post we argued that a service agent is a new form of asset, and that an asset has to grow, not just be held. A service agent does have to grow. But it can't grow the way a personal agent does, by teaching itself from memory as it's used. It grows through supervised versions: its context is split into layers, each with an owner, and the signals that come out of serving customers are reviewed and shipped as new versions.

This isn't caution for its own sake. It's what makes service possible at all. A service agent that teaches itself from memory can't explain why it gave an answer, and can't take back what it learned wrong. Letting it grow on its own means giving up audit and oversight, and a system like that can't be relied on by any of its customers.

## A service agent can't teach itself from memory

A personal agent can grow this way. As we said in the first post, it's built for change: every experience settles directly into it, and since the consequences mostly fall on the user, it can change along with that person.

If a service agent did the same, four things would go wrong.

**Nobody could say why it answered the way it did.** Its behavior would depend on everything it had accumulated, with no fixed version to point to and say "this is what it was working from." When a customer complains or a regulator asks, there's nothing to audit.

**Mistakes couldn't be undone.** Once a bad lesson mixes into its memory, you don't know where it is, and you can't remove just that one.

**One customer would change how it treats everyone.** Whatever one customer taught it would shape its next answer to someone else. That breaks the equal treatment service depends on, and it can carry one customer's information into another customer's conversation.

**It could be taught to misbehave.** Anyone who talks to it can influence it. There's a well-known case of a public chatbot that learned from its conversations with users and, in less than a day, had been taught to say things so offensive that it had to be taken offline.

Researchers who study how agents are built reach the same conclusion. The CoALA framework, published by Sumers and colleagues in *Transactions on Machine Learning Research* in 2024, divides a language agent's memory into working, episodic, semantic and procedural memory. The paper notes that an agent rewriting its own procedural memory, meaning the way it does things, is far riskier than writing to its other memories: it can easily introduce bugs, or let the agent subvert its designers' intentions. In the paper's own example, a retail assistant can record its interactions with each customer, but it can only read the product inventory and its own code, never change them.

## It grows through supervised versions

Not teaching itself doesn't mean not growing. The difference is where the growth happens.

A personal agent grows while it's used; the change happens inside each conversation. A service agent grows between versions. While it serves, it runs one fixed version. Improvements happen outside the agent: someone responsible proposes them, they're reviewed, and they take effect as a new version. In CoALA's terms, learning is an action the agent takes itself, deciding what to write into its own memory. A service agent moves that action outside the agent, into a release process that someone owns.

That gives a clear line: **while it serves, a service agent never rewrites anything its customers share.** It can record what happened with this customer, but it can't change how it treats everyone because of this customer.

## Context comes in five layers, each with an owner

CoALA tells us what kinds of memory an agent has, but not who owns each one or who may change it. For a personal agent the answer is simple: all of it belongs to the person it represents. A service agent has to answer layer by layer. Here context means everything the agent reads while it serves, which covers the context, configuration and customer records from the last post. On that basis we split it into five layers. The first three are shared by every customer; the last two belong to one customer.

**The rules layer** corresponds to procedural memory: identity, tone and hard limits; service procedures; which tools it can call and with what permissions; when to hand over to a person; which model it runs on. The provider's operations team owns it, and hard limits need sign-off from higher up. It ships with the agent's versions and is read-only while serving.

**The business layer** corresponds to semantic memory: products, prices, policies, professional knowledge, and facts about the provider itself. It comes from the provider's business systems, is owned by the business teams, and updates when those systems do. The service agent only reads it and never writes to it.

**The case layer** corresponds to the shared part of episodic memory: reviewed examples of how situations were handled. It's selected from many conversations, added with a new version once reviewed, and read-only while serving.

**The customer record** corresponds to the personal part of episodic memory: this customer's history and past interactions. It lives in the provider's own business systems, is kept separate per customer, and is only ever appended to. As we said in the first post, it's an input to the rules, not something that changes them. Because the record isn't stored inside the agent, the service agent itself stays stateless: every conversation starts from the same version and then reads in this customer's record.

**The session** corresponds to working memory: the matter being handled right now. It can be read and written during the conversation and is discarded when the conversation ends.

| Layer | Memory | Owner | While serving | How it changes |
|---|---|---|---|---|
| Rules | Procedural | Operations team; hard limits signed off higher up | Read-only | Ships with agent versions |
| Business | Semantic | Business teams and systems | Read-only | Updates with business systems |
| Cases | Episodic (shared) | Reviewed by operations | Read-only | Added with versions after review |
| Customer record | Episodic (personal) | Provider's business systems | Append-only | Written after each conversation, per customer |
| Session | Working | None | Read and write | Discarded when the conversation ends |

Only the last two layers are written to while serving, and both belong to a single customer. None of the three shared layers is rewritten by the agent while it serves.

## Signals from service are reviewed and become new versions

A service agent doesn't rewrite its shared structure, but every conversation produces signals for improving it: customer ratings, conversations handed over to a person, replies a human agent rewrote, complaints, and the eventual business outcome.

The layers give each signal somewhere to go. A wrong price is a business-layer problem for the business team. A conversation that should have been handed over and wasn't is a rules-layer problem for operations. A hard situation handled especially well can be written up and added to the case layer. Every layer has an owner, so every signal has someone to pick it up.

The steps after that are fixed. The owner changes the relevant layer, the new version passes evaluation, and then it ships, with a small share of traffic first if needed. When the first post said that what a service agent learns "is distilled, reviewed and released as a new version of the structure," this is the process it meant.

The loop follows the same idea as the Plan–Do–Check–Act cycle in quality management. Each turn improves the structure a little, and every turn has someone accountable for it.

## The evaluation set is both a gate and a growing record

An evaluation set is a collection of questions and expected answers that can be checked again and again. In this loop it does two jobs.

It's the gate before release. Every new version has to pass it first, to show that nothing it used to get right is now wrong.

It's also what the loop produces. As we said in the last post, every question in the evaluation set traces back to a real mistake. Each time a new mistake turns up in service and gets fixed, it becomes a new question. The more questions accumulate, the harder it is for the same mistake to come back. The evaluation set records every lesson the service agent has paid for, and it's part of the asset in its own right.

## Every version can be traced, so growth stays under control

Supervised versions don't give up growth. They make growth controllable, and each of the four problems from the start of this post now has an answer.

Every conversation records which version handled it, so "why did it answer that way?" has a traceable answer, down to the version and the layer. A mistake affects only one version, and you can go back to the previous one. One customer's experience goes into that customer's record and doesn't change what anyone else gets. And anyone trying to teach it something bad has to get past review and evaluation first.

Chain stores have worked this way for a long time. Every day, stores run into situations the manual doesn't cover, and staff report them to headquarters. Headquarters revises the manual and sends it to every store. No clerk changes the pricing policy because one customer asked. Prices are set by headquarters, and every store is told.

Growing this way can be slower for any single lesson than teaching itself would be. But it keeps compounding: each version builds on what the previous one already proved, and one mistake can't wipe out everything that came before.

## Next

A service agent that improves through versions also has to hold up in front of real customers: who authorizes what it does, who answers when something goes wrong, how problems get noticed, and how someone takes over when it fails. The next post, "Ready for real customers," takes up those questions.