Why an agentic AI workshop for enterprise architects looks different
Developers come to training with a task. Architects come with a decision. The questions are not about prompting. They are about blast radius, data flow, standardisation across forty repositories, and what happens when an agent writes a change nobody can attribute.
So the day is built around producing artefacts, not skills. Architects leave with a draft standard, a risk list they wrote themselves after seeing the failure modes, and a rollout plan sized to their organisation.
The parts that matter at organisation scale
- Context boundaries. Which repositories an agent may read, what leaves the network, and how that differs between an IDE assistant and a cloud-hosted task runner. Architects usually discover these are different products with different data paths.
- Repo instruction standards. A common baseline file, extended per repository. The organisation-wide part should be short. Local teams own the rest or they ignore all of it.
- Attribution. Agent-assisted commits need a marker, whether a trailer or a label, so you can answer an audit question a year later.
- Golden paths. Agents follow the most visible pattern in the codebase. If your preferred service template is not the most copied one, the agent will scale the wrong pattern faster than your architecture review can catch it.
- Cost and quota shape. Usage is spiky and concentrated. A few engineers drive most consumption. Budget for that shape rather than an average per seat.
The exercise that changes the room
We take a real service from the organisation and ask an agent to add a field end to end. Model, migration, API contract, client, tests. Then the architects review the diff as a review board would.
What they find, almost every time: the code compiles, the tests pass, and the change quietly bypasses an internal library everyone is supposed to use. Nobody argues about the need for machine-checkable standards after seeing that. It also makes the case for keeping the check in CI rather than in a wiki page, because the agent reads the repo, not the wiki.
A useful move here is putting the standard into an executable check, then naming that command in the repo instruction file so the agent runs it before declaring done, something like ./gradlew archTest.
The limits we state out loud
A one day workshop does not produce a governance framework. It produces a first draft and a set of people who have felt the failure modes personally, which is what makes the second draft good. Anyone selling a complete enterprise AI governance model in a day is selling a template you could have downloaded.
We also do not do vendor selection theatre. If your organisation has already standardised on one tool, we train on that tool. If it has not, we will show the practical differences we have seen across Claude Code, Cursor, and Codex, and let you decide.
What to do next
Pick one service and one real change before the session. Bring the current architecture standard, however outdated. Invite one engineer who already uses an agent daily, because architects and practitioners argue productively when both are in the room and badly when they are not.