Catalogue › AI Centre of Excellence › coe-delivery-model

CoE delivery model

Defines how the CoE actually builds and releases agents and automations once work is approved - delivery routes from self-service makers to CoE-assisted, CoE-built, partner and pro-code teams, a definition of ready and of done by risk tier, maker support, reusable patterns and handover to operations. Use when approved work has no clear way to get built, when makers and partners work differently, or when solutions go live unsupported.

Department

AI Centre of Excellence

Lifecycle

Mobilise, Deliver, Assure, Launch, Scale

Maturity

builder, scaler, ai-enterprise

Risk tiers

0, 1, 2, 3, 4

Platforms

m365-agents, copilot-cowork, copilot-code, copilot-studio, ai-foundry, power-platform

Editions

scale, enterprise

Reviewers

design-authority, evaluation-quality, security-privacy

Status

draft

Copilot Cowork

AI Centre of Excellence plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

The operating model decides which route an idea takes; the delivery model decides how the build itself happens on each route. This skill sets out who builds, with what support, to which standard of ready and done, and how a solution is handed to the people who will run it. Delivery goes wrong when every build is a one-off negotiation, when makers are left alone with tier 2 work, when partners hand over solutions nobody internal understands, and when "done" means "published" rather than "owned, tested and supported".

When to use

• The CoE has approved work in its backlog but no consistent way to get it built and released.
• Business makers, the CoE and partners build in different ways and to different standards.
• Solutions go live without test evidence, support arrangements or a review date.
• The CoE wants to move from building everything itself to enabling makers safely.

When not to use

• Choosing the CoE's shape and routing ideas by suitability and tier - use ai-centre-of-excellence:coe-operating-model.
• Selecting the platform for one specific solution - use ai-architecture:platform-selection.
• Designing one agent's scope, knowledge and actions - use m365-agents:agent-use-case-design.
• Application lifecycle management for Copilot Studio agents in depth - use copilot-studio:studio-alm.
• Selecting and managing delivery partners contractually - use programme-management:supplier-management.
• The support model for live solutions - use ai-operations:ai-support-model.

Questions to ask first

1. Which delivery routes exist today: business makers, a CoE build capability, an IT or digital team, partners, pro-code engineers?
2. What does each route build on, and which environments and tools does the governance model allow for each tier?
3. What support can the CoE give makers: office hours, review, pairing, templates?
4. Who will support solutions after release, and do they accept them today?
5. How many builds per quarter does the CoE need to deliver, and what capacity sits on each route?

Required inputs

• The routing table from ai-centre-of-excellence:coe-operating-model.
• Risk tiers and minimum controls from ai-centre-of-excellence:coe-governance-model.
• The environment strategy, where it exists, from platform-governance:ai-environment-strategy.
• Declared maker skills and partner arrangements, recorded at role level.
• The support model owner, from ai-operations:ai-support-model or IT service management.

If no environment strategy exists, restrict tier 2 and above builds to a single managed route until it does, and mark the gap "to confirm".

Decision framework

Match the route to tier and complexity.

Definition of ready and done, by tier. Each tier adds to the one below.

Practitioner approach

Start by listing the routes that really exist, not the ones the organisation would like. Many CoEs discover that most building is already happening by business makers in personal or team environments, and that their real job is to make that route safe and supported rather than to replace it.

For each route, write who builds, on which platforms, in which environments, at which tiers, with what CoE support and to which standard. Keep the routes few. Five clear routes are easier to follow than a matrix of exceptions.

Write the definition of ready and done next, because these are what make routes consistent. Ready protects the builders from vague requests; done protects users from unsupported solutions. Agree them with the reviewers and the support owner before the first build, so nobody discovers a gate at the end. The key rule is that "done" includes an owner, a support route and a review date, not just a working solution.

Design maker support. A CoE-assisted route works when makers can get help quickly: regular office hours, a design review at the start rather than the end, a test set template and a release checklist on the agent-release-checklist template. Pair a maker with a CoE builder for their first tier 2 build; after that, review rather than rebuild.

Build reuse in. Keep a small library of patterns: instruction structures, knowledge layouts, flow templates, test sets and briefing materials that worked. Each new build starts by checking the library and ends by contributing anything reusable. Feed patterns to ai-centre-of-excellence:coe-portfolio-management so they appear in the catalogue.

Set partner terms that protect the organisation. Partners build to the CoE's definition of done, use the organisation's environments, document what they build, and transfer knowledge to a named internal technical owner before acceptance. The CoE, not the partner, accepts the solution.

Plan handover to operations explicitly. Before release, the support owner accepts the solution with its documentation, known limitations, monitoring and escalation route. If nobody accepts it, it is not done.

Iterate in short cycles. Agents are improved by real questions, so plan a release, a short period of observation, then a first improvement cycle, rather than a long build and a big reveal. Review the delivery model each quarter against cycle times, rework and reviewer findings, and adjust routes or standards accordingly.

Outputs

• A delivery model: routes with builders, platforms, environments, tiers, CoE role and capacity.
• A definition of ready and done by tier, agreed with reviewers and the support owner.
• A maker support offer: office hours, design review points, templates, pairing and the agent-release-checklist template.
• A pattern library with contribution rules.
• Partner delivery standards and a handover checklist for operations.

Microsoft platform considerations

Agent Builder, Copilot Studio, Power Automate, Copilot Cowork, Copilot Code and Microsoft Foundry suit different routes and skill levels. Environment zoning and Managed Environments let the platform enforce which route builds what; ALM and deployment pipelines support tier 2 and above. Check current capability, availability and licensing in references/sources.md, and route licensing questions to the Microsoft licensing guide or a licensing partner.

Adoption considerations

A solution that is built but not adopted is not delivered. Include user briefing, scenario examples and Champion support in the definition of done for tier 2 and above, coordinated with copilot-adoption:launch-plan where a wider launch is needed.

Knowledge considerations

No build starts at tier 1 or above until its knowledge sources have owners and a readiness outcome from ai-centre-of-excellence:coe-knowledge-pillar. Knowledge owners are part of handover, not an afterthought.

Security and privacy considerations

Tier 2 and above solutions pass the security-privacy review before release, including connectors, authentication and data exposure. Makers must build in the environments the tier allows, never in personal environments for shared solutions. Partners use organisation-controlled environments and identities.

Responsible AI considerations

Solutions that inform decisions about people, money, safety or rights follow the tier 3-4 route whatever their technical simplicity, with human oversight designed in, not added at release.

Evaluation requirements

Every tier 2 and above build has a test set and threshold agreed with the business owner before build, using m365-agents:agent-testing or copilot-studio:studio-testing-and-evaluation. Evidence is part of done, and regression testing applies after any change to instructions, knowledge or model.

Value measures

Measure delivery at route level: median cycle time from ready to done, share of releases meeting the definition of done first time, reviewer findings per release, reuse of patterns and share of solutions accepted by operations at release. The delivery lead owns these. Never compare individual makers.

Scale notes

Starter

Not usually a separate design. A Starter working group relies on self-service makers for tier 0-1 and a partner or IT team for anything larger, with a simple definition of done.

Scale

Three or four routes, a definition of ready and done by tier, maker office hours, a pattern library and partner standards. The CoE builds selectively and coaches more than it builds.

Enterprise

Spokes run self-service and assisted routes under hub standards; the hub runs CoE build for shared services, governs partners across units and connects to specialist engineering teams for tier 3-4.

Hand-offs

• To m365-agents:agent-use-case-design or copilot-studio:studio-agent-design for the design of each build.
• To m365-agents:agent-release-readiness for the release gate.
• To ai-operations:ai-support-model for support acceptance.
• To ai-centre-of-excellence:coe-portfolio-management when the solution goes live.

Reviewer gates

From tier 2, security-privacy and evaluation-quality:ai-release-evidence review every release on the CoE-assisted, CoE and partner routes. design-authority:platform-fit-review should challenge the route table for complex work sent to routes that cannot support it, and design-authority:ai-design-review reviews tier 3-4 designs before build.

Failure modes

• Makers are left alone with tier 2 work and release without tests or reviews.
• Partners hand over solutions with no internal technical owner and no documentation.
• "Done" means published, and support discovers new solutions from user complaints.
• The CoE builds everything itself and becomes the bottleneck the operating model was meant to avoid.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Release a tier 2 or above solution without an owner, test evidence, completed reviews and an accepted support route.
• Let partners accept their own work on the organisation's behalf.
• Allow shared solutions to be built or run from personal environments.
• Assert platform capability, availability or licensing from memory.