In the last post we argued that service providers need a context system they can build, accumulate and iterate on, and that the context from every interaction should build up as their own asset. Where does it build up? In the service agent. This post takes the next step and looks at the service agent itself: it's a new form of asset, and one that service providers have never really been able to hold before.
This shapes how a provider should think about spending on agents. Treat it as an expense and you'll look for the cheapest integration and be ready to swap it out at any time. Treat it as an asset and you'll care who owns it, whether it compounds, and what it costs to replace.
Three tests of an asset
An orchard is an asset, and each year's fruit is the return it produces. What the orchard is worth depends on how much fruit it will still bear.
You can test whether something is an asset with three questions:
Was it built up by past investment? You pay a cost today to earn returns later. An orchard has to be planted, watered and waited on for years.
Will it keep producing returns? It isn't used up once; it creates value again and again.
Do the returns go to the holder? The owner has to be the one picking the fruit. If anyone can walk in and pick it, the orchard is worth little to its owner.
Each old carrier lacks a piece
What a service provider values most is often how to serve well: how to handle each situation, which customers need special care, what must never be said, which mistakes can happen once and never again. That know-how used to be spread across four carriers, each doing only part of the job.
People have judgment, but tacit knowledge is hard to pass on, and when a long-serving employee leaves, ten years of judgment leaves too. Documents can be copied, but they don't execute; someone still has to read and follow them. Software executes and scales, but it can only encode definite rules and doesn't learn from cases. Data records what happened, but holds no judgment.
People can judge but can't be copied. Documents can be copied but can't execute. Software can execute but can't judge. Data can record but can't decide.
A service agent assembles them into one system
A service agent's parts map onto the strengths of those four carriers:
Context takes over from documents: business knowledge, service rules and past cases, written down and executed directly.
Configuration takes over from software: which model it runs on, which tools it can call, what permissions it has, which channels it sits in, and when it hands over to a person.
Memory and customer records take over from data: each customer's history and status become direct inputs to judgment while serving.
Judgment, once found only in people, is now carried jointly by the model, the cases and the standards. The standards are written as a set of questions and expected answers that can be checked again and again, an evaluation set, and they define what good service means.
On top of these there's something no earlier carrier had: versions and iteration. They record how the system changed, version by version: what changed each time, why, and whether things got better or worse.
These parts aren't just placed side by side; they're tuned against each other. How strict a service rule should be depends on how the model performs on that kind of question. How far a tool is opened up depends on how permissions are set and how errors get handed to a person. Every question in the evaluation set traces back to a real mistake. Every trade-off was found by trying it against real cases.
Easy to scale, hard to rebuild
Because the parts are tuned against each other, a service agent has a property that looks like a contradiction: it's easy to scale and hard to rebuild.
Easy to scale, for its owner. The same service agent can serve one person or ten thousand at once, and each additional person costs close to nothing. That's where its returns to scale come from.
Hard to rebuild, for anyone starting over. Take only its business data, meaning the rules, cases and customer records, load it into another agent, and the results don't come along. How the parts work together isn't in the business data; it's in the combination of every part: how the model was chosen, how permissions were set, how the evaluation questions were written, why each version changed the way it did. Without those, you have to go through every round of adjustment again.
A restaurant works the same way. Hand the recipes to another kitchen and the dishes won't come out the same. The recipes, the heat, the prep order and how the cooks work together are what make that restaurant's food.
One question tests where the value lies: if you move the business data out, do the results move with it? If they do, only the data was valuable. If they don't, the whole system is. For a service agent that's actually serving customers, the answer is that they don't.
So the service agent itself passes the first two tests of an asset: it's built up by investment in round after round of tuning, and it keeps producing returns in every interaction that follows.
Complexity makes accumulation possible
An asset can only accumulate if there's somewhere for the accumulation to go.
If an agent is simple enough, say a prompt on top of a general-purpose model, there's nothing to accumulate. Anyone can build the same thing in an afternoon, so it's no advantage at all. Because a service agent is a system of many interdependent parts, every investment has a place to land: a rule revised, a case added, a permission tightened, an evaluation question written. Each one makes the system a little less like anyone else's.
Complexity isn't an asset by itself, though; only complexity you can manage is. A system where nobody can say why it's configured the way it is, and every fix breaks something else, is a liability. That's why versions and evaluation sets aren't extras. Versions give every adjustment a history. Evaluation sets let every change be checked. Together they let complexity keep compounding instead of turning into a mess.
Control decides ownership
The third test, whether the returns go to the holder, depends on who holds the system.
Holding it doesn't mean running your own servers. A service agent can run anywhere; what matters is control. Do its context, configuration, memory, evaluation set and version history all belong to the provider? Can the provider inspect them at any time and take all of them along? Does the provider decide whether and how they change?
If only the business data belongs to you, while the configuration, evaluations and version history are kept by someone else, then that data is all you can take with you. As we saw, the business data alone doesn't carry the results. The more you invest, the more the asset is worth, and the less of it is in your hands.
So before investing, a provider should make sure of one thing: what it holds is the whole service agent. Only then does the agent pass all three tests, and only then is spending on it truly an asset rather than an expense.
Next
An asset has to grow, not just be held. How does a service agent get better with each interaction? How do outcomes become signals, how does a handoff to a person become teaching, and how does the evaluation set grow? The next post, "Better with use," looks at that loop.