The AI guild, community of practice or centre of excellence is one of the first structures organisations create when AI tools arrive. It is a good instinct. Enthusiasts find each other, share what works and spread practice faster than any formal training plan.
After a year, many guilds look the same. A well-attended monthly session. A busy chat channel full of links and tool tips. A folder of demonstrations. And a recurring debate about which coding assistant is best that is never settled, because nothing the guild says binds anyone.
That is a guild running on enthusiasm. It is pleasant and useful for the people who attend. For a team that has never attended, it changes nothing.
Kalahari Assurance is fictional, and its systems and figures are illustrative. Kalahari's guild started in 2025 with about 60 members and a monthly demonstration slot. By the middle of 2026 it had produced 14 recorded demonstrations and a channel with several thousand messages. When the head of engineering asked which guild outputs a new team should adopt on day one, the honest answer was none. There was nothing to adopt, only things to watch.
What a guild is for
CloudNala's view is that an AI guild exists to turn individual discovery into organisational defaults. Its test is simple: does the next team's work change because of what the guild produced, even if nobody on that team attended?
That test points to four kinds of output:
Versioned standards with owners. Short documents that state how something is done here: how repository instruction files are structured, how agent permissions are scoped, how evaluation sets are kept, how an MCP server is designed. Each has an owner, a version and a review date.
Reference implementations. A working example of each standard, in a repository a team can copy. A standard without an example is an argument; a standard with one is a starting point.
Platform defaults and checks. The standard built into the paved road, as described in Part 4, so that following it requires no effort and breaking it requires a decision.
Decisions with review dates. Recorded choices, for example "we use this tool for this data class", with the reasoning and the date the decision will be revisited. This ends the recurring debate by giving it a schedule.
From recurring problem to platform default
Kalahari reorganised its guild around a pipeline. A topic enters only when a real problem has appeared in at least two teams. It leaves only when it is either a platform default or explicitly dropped.
- Problem in two teams. A single team's problem is that team's business. A problem in two teams is a candidate standard. This filter alone removed about half of the guild's agenda.
- Proposal with owner. One named person writes a short proposal: the problem, the options, a recommendation and what evidence would show it works.
- Trial in one team. The proposal is applied in one real team for a fixed period, typically four to six weeks, and the evidence collected.
- Standard published. If the trial works, the standard is published with its owner, version and review date, and a reference implementation.
- Platform default. The platform team builds it into templates, checks or configuration.
- Review date. On the review date the owner confirms, revises or retires the standard.
The first standard through Kalahari's pipeline was the repository instruction file. Three teams had written their own AGENTS.md conventions and agents were behaving inconsistently between them. The guild produced a one-page standard with a template, trialled it in the claims team, published it and asked the platform team to add it to every new repository. Within a quarter every new service had the same starting instructions. The harness engineering article describes why that kind of consistency matters for agent behaviour.
Keeping the enthusiasm
None of this means abolishing the demonstrations. Discovery still needs a place, and people still need a community. Kalahari kept its monthly session but split it in two: half for open demonstrations and discoveries, half for the pipeline, reviewing proposals and trial evidence.
What changed was the guild's reporting. It stopped reporting attendance and messages. It now reports four numbers each quarter: standards published, standards that became platform defaults, standards retired, and the share of active teams whose repositories meet the current standards. Those are numbers a head of engineering can act on.
Who sits in the guild, and with what time
A guild made only of enthusiastic engineers will produce engineering standards and miss everything else. Kalahari deliberately rebuilt its core group to reflect the delivery system rather than the people who liked AI most.
The core group has 12 members on a one-year rotation: four engineers, two testers, two analysts, an architect, a designer, someone from the platform team and someone from security. Each spends about a day a fortnight on guild work, and that time is planned in their team's capacity rather than squeezed into evenings. Anyone can bring a problem or join a trial; only the core group runs the pipeline.
Three features of this design matter more than the exact numbers. Rotation keeps the guild from becoming a permanent club and spreads the experience of writing standards across more people. Protected time signals that standards are real work, which is the difference between a standard that is finished and one that is abandoned at 80 per cent. And including testers, analysts and security means standards are tested against the stages that will have to live with them, before they reach the platform.
The guild lead is a senior engineer with a reporting line to the head of engineering. That line gives the guild a route to have its recommendations considered, without giving it the power to mandate them alone.
Authority and its limits
A guild that produces standards needs some authority, and that has to be designed carefully.
| Decision | Who decides |
|---|---|
| Whether a topic enters the pipeline | Guild leads |
| The content of a standard | Standard owner, with guild review |
| Whether a standard becomes mandatory | Head of engineering, on the guild's recommendation |
| Security and privacy requirements inside a standard | Security and privacy, not the guild |
| How the platform implements a default | Platform team |
The guild recommends; accountable leaders mandate. This keeps the guild close to practitioners, where its credibility comes from, without turning it into an unaccountable policy body. It also keeps the risk decisions with the people who own the risk, consistent with the argument in experts govern.
Common traps
- Standards that are too long. If a standard runs to twenty pages, teams will not read it and agents will not follow it. Kalahari's rule is one page plus a reference implementation.
- Standards without owners. An ownerless standard ages silently, exactly like an ownerless MCP server in Part 5.
- Tool rankings as standards. A guild that publishes "the best tool" will be wrong within months. Standards should describe practices and criteria; tool choices belong in decisions with review dates.
- The guild as a gate. If every change needs guild approval, teams will route around it. The pipeline is for defaults, not permissions.
Next: Part 7, Measure capability through work products. All parts are on the series page.
How CloudNala can help
We help organisations turn an existing AI community of practice into a guild that produces standards: an intake rule, a proposal and trial pipeline, a one-page standard format with reference implementations, clear decision rights and reporting that leaders can act on. We usually start by taking two or three live debates through the pipeline end to end.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Plan an AI Capability Programme or write to us at consult@cloudnala.co.za