Catalogue › Learning and Skills › advanced-pathways

Advanced pathways

Designs advanced AI pathways for makers, power users and specialists - entry on declared role, approved access and maker commitments, tracks for delegated Cowork work, agent and automation makers, Copilot Code and Microsoft Foundry, learning by building in governed sandboxes with mentoring, and evidence from a reviewed build. Use when building opens to more people, when makers learn in production, or when specialists lack a route.

Department

Learning and Skills

Lifecycle

Enable, Deliver, Scale

Maturity

builder, scaler, ai-enterprise

Risk tiers

0, 1, 2

Platforms

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

Editions

starter, scale, enterprise

Reviewers

none

Status

draft

Copilot Cowork

Learning and Skills plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

Once people can use Microsoft AI well, some need to go further: delegating complex work, building agents and automations, writing code with Copilot or engineering solutions in Microsoft Foundry. This skill designs the advanced pathways that take them there, track by track, with entry conditions, learning by building in safe places, mentoring and evidence from a real, reviewed piece of work. It usually goes wrong when advanced learning is a collection of product courses with no link to governance, when makers learn by trial and error in production, and when the pathway produces confident builders who have never tested, documented or handed over anything.

When to use

• Agent building or automation is being opened to more people, and they need a structured way to learn it well.
• Makers are learning by experimenting in production or the default environment.
• Power users have outgrown the Proficient level and ask what comes next.
• Developers or AI engineers are adopting Copilot Code or Microsoft Foundry without a shared standard of practice.
• Builds reaching review keep failing for the same reasons, such as missing tests, owners or documentation.

When not to use

• Governing who may build and share, and makers' onboarding commitments - use platform-governance:maker-governance.
• Setting the environment zones where building happens - use platform-governance:ai-environment-strategy.
• The learning offer for recognised Champions within the Champion journey - use champions:champion-learning.
• The shared foundation-to-proficient pathway for the whole workforce - use learning-and-skills:ai-learning-pathway.
• Analysing which roles need building skills at all - use learning-and-skills:ai-skills-needs-analysis.
• Building and staffing the AI delivery team itself - use organisation-tailoring:capability-gap-analysis.

Questions to ask first

1. Which building and advanced-use activities are approved, for which groups, in which environments - delegated Cowork tasks, Agent Builder, Copilot Studio, Power Platform, Copilot Code, Foundry?
2. Who is asking for advanced learning, by declared role, and what will they build or do with it in the next six months?
3. What commitments does maker governance require before someone can build and share, and does the pathway need to cover them?
4. Who can mentor - experienced makers, the Centre of Excellence, engineers, a partner - and with what agreed time?
5. Where do learning builds live, and how does a build worth keeping move into intake and release?

Required inputs

• Maker governance rules and onboarding commitments from platform-governance:maker-governance.
• The environment zones and learning sandboxes from platform-governance:ai-environment-strategy and learning-and-skills:practice-labs.
• Role needs statements showing which roles include building, from learning-and-skills:ai-skills-needs-analysis.
• The organisation's engineering, testing and release standards for each platform, from the relevant delivery departments.
• Named mentors with agreed time.

If maker governance is not in place, do not open a maker track; offer the power user track and record the dependency. If no learning sandbox exists for a platform, defer its track rather than letting people learn in production.

Decision framework

Define tracks by what people will do, each building on Proficient evidence from the workforce pathway.

Entry rules:

Practitioner approach

Start from the work, not the product. For each track, describe what someone who has completed it does: "An agent maker can judge whether an agent is the right answer, build a simple governed agent in the team zone, test it with realistic questions, name an owner and take it through release." That description decides the content and the evidence, and keeps the track from turning into a feature course.

Tie every track to governance from the first module. The rules on where to build, what to share, ownership and release are not an appendix; they are what separates a maker from someone who creates ungoverned solutions. Cover the onboarding commitments maker governance requires, and make accepting them a condition of building anything that will be shared.

Learn by building in safe places. Each track centres on a build or piece of work in a learning sandbox or the zone the environment strategy allows, using fictional or synthetic data. Learners move through small builds to one meaningful piece that addresses a real need in their area. That final piece is the evidence: not a certificate, but a build with tests, an owner and documentation that a reviewer could pick up.

Make testing and handover part of the craft. Most builds that fail review fail on the same things - no realistic test questions, no owner, no plan for when the maker moves on. Teach these as core skills with the same weight as building. For Foundry and code tracks, evaluation and security review practice are central, not optional.

Pair learners with mentors. A short regular check-in with an experienced maker or engineer catches poor patterns early and teaches the judgement that courses cannot. Agree mentor time with their managers, and keep the ratio of learners to mentors realistic.

Use Microsoft's published learning for product depth. Point learners to current Microsoft resources for features and configuration, checked against the source records, and spend the organisation's effort on the parts only it can teach: its governance, environments, standards, patterns and real use cases.

Connect the end of each track to real delivery. A build worth keeping moves through intake, design and release like any other solution; the pathway never promotes it directly. Completing a track can lead to joining a maker community, contributing to the Centre of Excellence or mentoring the next cohort.

Review the tracks when products or governance change, and when the reasons builds fail review shift.

Outputs

• An advanced pathways definition recorded in the advanced pathways section of the ai-learning-plan template - tracks, audiences, entry rules, content, mentoring, evidence and owners.
• A track guide per track with modules, sandbox builds, the final build brief and evidence requirements.
• A mentoring arrangement with named mentors, agreed time and check-in rhythm.
• A route from completed learning builds into intake and release, agreed with platform governance.

Microsoft platform considerations

Tracks follow the building platforms the organisation approves: Copilot Cowork for delegated work, Agent Builder and Copilot Studio for agents, Power Platform for automation, Copilot Code and GitHub for development, and Microsoft Foundry for engineered solutions including third-party models available through Microsoft. Which platform fits a need is a design decision owned elsewhere; the pathway teaches each in the context of the organisation's zones and standards. Features, limits, model availability and licensing change often, so check references/sources.md and route licensing to platform-governance:ai-licensing-and-capacity.

Adoption considerations

Advanced learners become multipliers. Connect graduates to the maker community and the Champions network so their patterns reach others, and make clear that building is a privilege that comes with commitments rather than a badge.

Knowledge considerations

Agents and Foundry solutions depend on good knowledge sources. Tracks teach makers to check content readiness and ownership before grounding a solution on it, and to involve the knowledge owner. Reusable patterns from completed tracks are recorded with an owner.

Security and privacy considerations

Learning builds use fictional or synthetic data in approved environments with no production connectors or live secrets. Tracks teach connector policy, authentication and secrets handling for their platform. Anything moving beyond the learning environment goes through the security review its risk tier requires.

Responsible AI considerations

Every track includes when not to build, human oversight, transparency to users and testing for harmful or wrong outputs. The AI specialist track covers safety evaluation in depth. Learners never build solutions that make decisions about people as practice exercises.

Evaluation requirements

Track evidence includes testing appropriate to the platform: realistic test questions for agents, test runs and exception cases for flows, tests and review for code, and an evaluation plan with results for Foundry work. Learning builds are evaluated as practice, not released; any build promoted later is evaluated under the release process.

Value measures

Baseline: the share of builds reaching review that fail on testing, ownership or documentation, and the number of ungoverned builds found, before the tracks launch. Measures: first-time pass rate at review for builds by track graduates at cohort level, orphaned solutions over time, and track completion by evidence. Owned by the Learning Lead with the platform governance owner, reported at cohort or role level, never ranking makers.

Scale notes

Starter

One or two tracks, usually power user and agent maker, run as small cohorts with a mentor and a learning sandbox, with other tracks described as future routes.

Scale

All approved tracks with cohorts each quarter, a mentor pool, standard track guides and a defined route from learning builds into intake.

Enterprise

Tracks run with the Centre of Excellence across business units, localised mentoring, specialist tracks for engineering teams, and pathway content updated with platform and governance changes.

Hand-offs

• To platform-governance:maker-governance for onboarding commitments and sharing rights on completion.
• To learning-and-skills:practice-labs for sandboxes for each track.
• To opportunity-management:idea-capture when a learning build addresses a real need worth taking forward.
• To ai-centre-of-excellence:coe-delivery-model where graduates contribute to CoE delivery.

Reviewer gates

Not applicable to learning builds that stay in the learning sandbox. Any build moved to shared or production use passes the gates its risk tier requires under platform-governance:ai-release-policy, including security-privacy and evaluation-quality from risk tier 2.

Failure modes

• Tracks teach product features but not governance, producing confident makers who create ungoverned solutions.
• Learners practise in production because no sandbox exists, and test agents reach real users.
• Testing, ownership and handover are treated as optional, so graduates' builds fail review.
• Mentors have no agreed time, check-ins lapse and poor patterns go uncorrected.
• Completing a track is treated as permission to release, bypassing intake and review.

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

• Open a building track before maker governance and a learning environment exist.
• Use real personal, customer or confidential data, production connectors or live secrets in learning builds.
• Promote a learning build to shared or production use outside intake and release.
• Rank makers or publish individual track progress.