The layer you own

Most services businesses I talk to are being offered the same thing by every vendor: an agent for intake, an agent for research, an agent for quality checks, each sold separately and each very good at its own task. The pitch is usually true. The trouble is what happens when you buy five of them.

Each one arrives with its own copy of your clients, its own idea of what a good answer looks like and its own log. None of them can see what the others know. Your professionals end up checking five different outputs against five different pictures of the same client. And when a better agent comes along next year, whatever the old one learned about your business leaves with it.

If every competitor can buy the same task agents, the advantage is in what they're connected to.

Buy the models

The models are the part that gets better and cheaper every few months, and everyone can rent the same ones. Treat them as a commodity. I wouldn't train my own, and I wouldn't fine-tune one before a good prompt and good retrieval had been tried and had failed. Expect to swap them, and design so that swapping is a day's work rather than a project.

The same goes for the task agents that come inside the software you already pay for. Use them. They're often the quickest way to show people what is possible. Just don't let them become the place your business's knowledge lives.

Route the work, step by step

Not every step deserves the most capable model. The hard, rare, judgement-heavy steps go to the best model you can rent. The high-volume, checkable steps, such as extracting, classifying and matching, go to the cheapest model that passes your tests, and sometimes to one that runs on your own machines and sends nothing anywhere.

Routing isn't only about cost. In a business that works across countries, the model a workflow is allowed to use can depend on where the client sits. That makes the market a routing rule rather than a policy document. The standard stays the same everywhere; the model underneath changes with the rules.

Own the layer underneath

This is the part I'd build and keep, and it's smaller than people expect. It has three pieces.

A connected picture of the business. Your data already sits in a lake or a warehouse. That stores it; it doesn't connect it. What agents need is one picture of who your clients are, what you've done for them, which people work with them, which rules apply, which documents matter, and which decisions were taken and by whom. I call it a knowledge graph, but the name matters less than two rules. Build only what the first workflow needs; don't fund a grand data model. And store decisions alongside facts, because an agent can't be taught a decision nobody wrote down, and that record gets more valuable every time it's used.

Because every agent reads and writes the same picture, the agents stay consistent with each other: the intake agent and the quality-check agent agree on who the client is because they're reading the same record.

A register. Every agent has one page: what it does, what it may read and change, which market it works in, the grade of autonomy it has earned, and the named person who answers for it. If it isn't on the register, it doesn't run. Build each agent once as a template and deploy it as numbered versions. A version that can touch or look up more starts again at the bottom; a new model is re-tested before the agent keeps its grade.

A test set. Real cases from your own files, with the right answer marked by people qualified to judge it, and never shared with the vendors whose models it tests. Every change to an agent, a model or a prompt runs against it before it goes near a client. It's what lets you swap models with confidence, and it's a real answer when someone asks how you know the thing works.

Always a person

Some decisions stay with a named person at every stage: taking on a new client, signing off advice, pricing a piece of work, anything a client will rely on without checking it themselves. The machine prepares; the professional decides. That's not about what the technology can do. In a services business, clients are paying for someone to stand behind the answer.

Build once, configure for each market

In a business that runs the same service in several countries or teams, the temptation is to build a version for each. Don't. Build each workflow agent once. Put the differences between markets in the knowledge graph as configuration, so two markets run the same agent reading different rules. Then let each deployment earn its own autonomy: the same agent can be acting on its own in one market while it's still only recommending in another, because the evidence in each is different.

Scale then becomes a series of small, reversible decisions, each taken on evidence people in that market can see.

What it's worth

The graph, the register and the test set are assets. They survive a change of model, a change of vendor and the next acquisition, because the next business you buy plugs into the same picture rather than starting again. They're what a buyer's diligence team can actually read. And they're what turns a service into something you can prove, which is usually the moment it becomes something clients will pay more for.

You don't need to own the technology to own the outcome. Own the three things above and buy the rest well.

Where to start

One workflow, one team, end to end. If you can bring one client's history together from the systems it's scattered across inside eight weeks, the graph is real. Put one agent on the register, watching the live work with its output held back, and write down the criteria it has to meet before it's allowed to do more. Measure before and after. Then decide, in the room, whether to carry on.