Running an AI agent workshop: what actually changes in the team afterwards

The problem with most AI training

Most AI training for engineering teams takes one of two shapes. The first is a presentation — here is how LLMs work, here are some use cases, here is a demo. The second is a vendor-led workshop — here is our platform, here is how to use our API, here is a certificate of completion.

Neither of them produces an agent that runs in your codebase. Neither of them teaches a team how to break what they built before they ship it. Neither of them leaves a repository behind that the team can use as the foundation for the next one.

We run a different kind of workshop. Here is what it produces.

The codebase comes first

We do not bring a toy problem. We bring the workshop into your actual repositories, against an agreed non-production cloud environment, using your actual deployment tooling.

This means the agent your team builds during the workshop solves a real problem in your real codebase. It might be an agent that triages support tickets against your knowledge base. It might be one that checks infrastructure changes against your security policies. The problem has to be specific, bounded, and real — not a chatbot demo.

Starting from something real changes what the team learns, because the friction is real too. The permission errors are in a scoped version of your IAM setup. We use anonymised or synthetic data and realistic integration paths in non-production, so the team learns your constraints without experimenting on live customer records.

Attack before you ship

On the third day of the core workshop, after the team has built a working agent, we attack it. Together, in the room, with the team watching.

We prompt-inject it. We try to make it exfiltrate data. We make it produce outputs that should never reach a downstream system and check whether the guardrails catch them. We test what happens when the tool it depends on returns unexpected responses.

Most teams find at least two things they would not have caught before shipping. Usually one of them would have been embarrassing.

The goal is not to destroy the confidence of the team that just built something. The goal is to make the attack part of the build loop — something they do to every agent they build from now on, not something that happens to them in a security review six months later.

What leaves the room

At the end of the three-day core, the team has a repository with a working, tested, documented agent. It has a runbook that explains how to operate it. It has a threat model — not a formal document, a two-page exercise the team did themselves that answers the five questions a security review will ask.

An optional fourth day covers deployment through your approved change process. The core workshop does not deploy to production.

They also have the muscle memory of having built one. The second agent is faster. The third one is just how the team works.

Who it is not for

This workshop is not for teams that want to evaluate AI before committing to it. It is for teams that have already decided to build with AI and want the first one to ship, survive security review, and set the pattern for everything that follows.

If you are still in the evaluation phase, start with the free Well-Architected Review — it will tell you whether your cloud foundation is ready for an AI workload before you build one on top of it.

The workshop details — including what we need from your team before we arrive — are on this page.