AI agents on a team: what training gives you and who is ready for it

Agentic AI training for a team assumes the team ships code without agents too. It has a process someone can describe in three sentences. It has tests it trusts. It has code review that actually happens. An agent amplifies whatever already works and blows apart whatever barely holds together.

The order has a financial consequence. Two days of a whole team cost more than the invoice for the workshop, because stalled delivery comes on top of it. If nobody has anywhere to plug an agent in afterwards, that whole sum disappears. I look at this from two sides. I run these workshops, and earlier I bought training for my own team as a CTO.

What follows is the concrete part. How an agent workshop differs from a prompting course and what conditions the team has to meet. What happens in the room across two days. What two days cannot teach, and who should skip it.

How it differs from an ordinary AI course

A prompting course teaches a tool. Someone shows the chat window, good query patterns and a few tricks for longer context. After a course like that people write better prompts, and the change ends there. As a first step for a whole company it makes sense.

An agent workshop touches something else. The team hands part of its work to a process that runs on its own. The agent reads the repository, runs commands, changes files and opens a pull request. Every one of those actions needs an engineering decision: where to draw the boundary, how to verify the result and who takes it on themselves.

That changes who belongs in the room. For a prompting course you send whoever is curious, from any department. For an agent workshop you send a team that shares one repository, because the decisions from day two will live in that repository for a long time. If half the room has no access to the code, the exercises fall apart before lunch.

So the agenda of such a workshop reads more like an architecture review than a tool course. The biggest argument in the room is usually about boundaries. How much the agent may do without asking, when it has to stop and who clicks approve. It pays to have an opinion on this before the workshop. Two days is too little to reach one from scratch. I wrote separately about how to set an agent's boundaries before it goes anywhere near production.

Readiness criteria for the team

Before a workshop I check five things. None of them is ambitious. All of them are the minimum.

A team that meets four criteria out of five walks into the workshop fine and catches up on the missing one along the way. A team that meets one gets a different proposal from me. Order in the process first, agents after. Saying that costs me the engagement and saves the client two wasted days.

It also happens that a team meets the criteria on paper, and in the room it turns out the tests only run locally on one machine. That shows up in the first hour, and then I change the plan for the day. Better to spend the morning and get the pipeline running than to pretend the rest of the exercises make sense without it.

What a two-day team workshop looks like

The room works on the team's own repository. People sit at their own machines, with their own stack and their own technical debt. The trainer walks between them and watches the screens.

On day one the team uses agents in its everyday work with code. Everyone runs an agent on their own task and hits a wall within an hour. The agent gets half of it right, and in the other half it invents a function name the project does not have. That is where the most important part of the day begins. How to check the result faster than writing it by hand would have taken. The team learns to read the diff instead of reading the summary of changes.

In the afternoon the question of trust comes back. Someone always says they would write it faster themselves. Sometimes they are right and it needs saying out loud. So we split tasks into two piles: the ones where the agent gives an edge, and the ones where it only generates work to verify. That list is often a bigger discovery for the team than the rest of the day.

On day two we build. We design the architecture, set the permissions, close off security and plan how this gets to production. This is where the arguments start, because everyone has a different opinion on how much freedom to give the agent and where to put a hard block. Most of those arguments come down to the same handful of rules, which I collected into a set of twelve design decisions, each with a green do and a red trap.

The day ends with something you can run on Monday. The team walks out with an agent built on its own case, with a repository of exercises and with a checklist it uses to check the output. Three things instead of impressions.

The format is deliberately narrow. Two days and work on your own code, priced from 4,800 USD online or from 6,400 USD on-site with travel included, for a team of up to twelve people for two days. Dates are agreed individually. You describe the stack and the goal in advance, and the form and the full scope of the workshop sit on the offer page.

What two days cannot teach

A workshop gives skills and a starting point. It does not give judgment, because judgment comes from failed attempts.

The first thing beyond the reach of two days: deciding which problem deserves an agent at all. I will show a few criteria and two cases from my own practice. The call for your domain is yours to make, weeks later. Straight after training, someone usually plugs an agent in where a script was entirely enough.

It looks the same when a team splits work between several agents. Fresh off a workshop, people happily stand up three agents where one with a decent tool set would do. Before you break a system into roles, check when a single agent is enough and what splitting into roles actually buys you.

The second thing is an evaluation set for your domain. A few dozen cases with correct answers, against which you measure every prompt change. In the room we build the skeleton and the first cases. The rest grows where the agent gets things wrong, which is already in production. An evaluation set measures the model, not the code that polices it. That second one is measured differently: you break it in one place and check whether the tests catch it.

The third is operational habits. Who looks at the logs on Monday morning, what you do with a run of silent failures and when you switch the agent off. You cannot rehearse that in a room, because it takes weeks of real traffic. A workshop will at most set up the first rota and the first alert.

Who this is not for

I turn down three kinds of teams, and I would rather say it before the invoice.

First: a team that has no code in production. Agents show what they are worth only on an existing system, with commit history, tests and technical debt. On an empty repository the workshop turns into a demo of what is possible. A demo does not change how people work.

Second: a company that wants to hear about trends. That is a sensible need, it is just served by a different format. An hour on stage for the whole department does more than two days of engineers at their keyboards, because it reaches the people who decide about budgets. The same holds for a room where nobody writes code. I build the programme from the other end there and leave people one task to do on Monday, which I wrote up as a session for a room without engineers.

Third: an organisation where nobody will own the result. If the workshop repository has no owner and the rollout has no place in the quarterly plan, the knowledge disperses within a week. I ask about this on the intro call, and sometimes I suggest myself that we move the date by a quarter.

There is a fourth case, rarer and more pleasant. A team that already runs agents in production and is looking for an answer to one specific problem. Two days of a programme is too much then. A few hours over their architecture settles it better.

The simplest readiness test takes five minutes. Ask three people on the team how a task travels from ticket to production. Three different answers mean you start with the process and plan the workshop for next quarter.

Frequently asked questions