Teaching a Team to Build Their Own Agents: What That Actually Takes

The stated aim of most enterprise AI engagements is capability transfer. The actual outcome is usually dependency, because the commercial model of the firm doing the work quietly rewards it.

We think the right test of an engagement is narrow: six months after go-live, can the client build the next agent without us? Here is what it takes to get there, and where it usually fails.

Training courses do not do it

The standard approach is a course. Two days, a curriculum, a certificate, and a set of exercises built on sample data.

People come out of it able to complete the exercises. Very few come out able to build something for their own team, because the difficulty was never the tool. It was knowing which job is worth automating, what the edge cases are, and what to do when the output is nearly right.

None of that is teachable in the abstract. It is learned by building something you actually needed.

What works instead

Build the first one together, with them in the room. Not a demo afterwards — the actual build, with the person whose job it is sitting alongside. Most of what matters is transferred in the moments where you say "no, that will not work, because..."

Have them build the second one while you watch. This is the step most often skipped, and it is where the transfer actually happens. They will get stuck somewhere you would not have predicted, and unsticking it themselves is the thing that sticks.

Make the third one none of your business. If you are still involved by the third agent, the model has not transferred. Being asked afterwards what went wrong is fine. Being needed is not.

Who to teach

The instinct is to train the technical team. That is usually a mistake, or at least an incomplete answer.

The people who build good agents are the people who understand the work — the operations manager who knows why the exception process exists, the finance analyst who knows which number is contested. They tend to need less technical scaffolding than expected, because modern platforms are genuinely approachable, and they bring the domain knowledge that is impossible to transfer in the other direction.

The pattern we see work is a pair: someone who knows the work, and someone technical who unblocks them. Not a centre of excellence, which usually becomes a queue.

What has to exist first

Enablement fails predictably when the groundwork is missing. Before a team can build independently they need the systems already connected and permissioned, an environment where they can experiment without a change request, a rule about what needs review before deployment, and somewhere to see what colleagues have already built.

That last one matters more than it sounds. Most second agents are a variation on somebody else's first.

What good looks like

The signal is not the number of agents. It is where they come from.

If every agent originated with the central team or the implementation partner, capability has not transferred, however many exist. If agents are appearing from teams nobody briefed — the ones you find out about because someone mentions it in passing — that is the thing working.

That is also the point at which the volume stops being a function of your budget, and starts being a function of how many jobs your people are tired of doing.

Why a partner should want this

It is a fair question to put to anyone bidding for the work: your model makes more money if we stay dependent, so why would you do this?

The honest answer is that dependency has a ceiling. A client who can build their own agents builds far more of them, hits harder problems, and comes back for the hard ones rather than the routine ones. That is better work, and it lasts longer than a renewal cycle.

But you should ask the question, and you should listen carefully to how it is answered.