Skip to content
FR

Design an Overall AI Strategy

Step 5 of 22

AB-100: Agentic AI Strategy, Platforms, and Roadmap

An agentic AI strategy connects business outcomes to platform choices, governance, and a staged delivery roadmap. This AB-100 lesson covers the skills measured under Plan AI-powered business solutions (25–30%) that relate to the overall AI strategy: applying the Cloud Adoption Framework for AI agents, choosing between single-agent and multi-agent designs, deciding whether to build, buy or extend, and putting the organization (prompt library, Center of Excellence) in place to scale.

Learning objectives

After this lesson you can:

  • Explain what an agentic-first strategy is and how it differs from adding AI features to existing apps.
  • Explain the four Cloud Adoption Framework adoption areas for AI agents: plan, govern and secure, build, manage.
  • Decide between a single-agent and a multi-agent architecture.
  • Apply a build, buy or extend decision across SaaS, low-code and pro-code options.
  • Describe the role of a prompt library and an AI Center of Excellence.
  • Sequence a roadmap with measurable stages and increasing autonomy.

1. Agentic-first strategy

An agentic-first strategy designs processes around agents that can reason, use tools and act, with people supervising and handling exceptions, rather than bolting a chat assistant onto an unchanged process. It starts from business outcomes and processes, not from a model or product, and it treats data, identity, governance and operations as part of the design.

Typical elements of the strategy:

  • Business goals and priorities – which outcomes matter (cost, speed, quality, customer experience) and how success is measured.
  • Use-case portfolio – a ranked list of candidate agents, scored by value, feasibility, data readiness and risk.
  • Technology plan – which Microsoft platforms are used for which scenarios (Microsoft 365 Copilot, Copilot Studio, Dynamics 365 and Power Platform agents, Microsoft Foundry).
  • Data and security foundation – grounding data, permissions, labels and compliance controls.
  • Operating model – roles, funding, support, change management and skills.
  • Roadmap – staged delivery with checkpoints.

2. Cloud Adoption Framework for AI agents

The Cloud Adoption Framework (CAF) offers guidance specific to AI agents, organized in four areas:

Area Purpose Examples
Plan Align agents with business and technology strategy Use-case selection, requirements, ROI, technology plan, skills and organizational readiness
Govern and secure Reduce risk before scale Responsible AI principles, identity and access, data protection, compliance, policies for who may create and share agents
Build Create agents on the right platform Choose SaaS, low-code or pro-code; design tools, knowledge and orchestration
Manage Operate and improve Monitoring, evaluation, lifecycle, cost control, support

Exam tip: governance is not a late step. Policies and guardrails (who can build agents, which connectors are allowed, which data they can reach) are defined before broad rollout, then refined as usage grows.

3. Build, buy or extend

Compare options against functional requirements, security, operating skills, and lifetime cost. Start by checking for a suitable existing capability, then investigate extensions or custom platforms where gaps remain:

  1. Buy / use prebuilt – ready-made agents and features in products the organization already licenses (for example Microsoft 365 Copilot agents, or the AI capabilities of Dynamics 365 applications). They can reduce implementation effort, but licensing, consumption, and lifecycle costs still need evaluation.
  2. Extend – adapt a prebuilt solution with your own knowledge sources, actions, connectors or prompts (for example extending Microsoft 365 Copilot, or adding actions to a Dynamics 365 agent).
  3. Build low-code – create custom agents in Copilot Studio when the logic fits topics, tools, flows and connectors, and makers are business users or low-code developers.
  4. Build pro-code – use Microsoft Foundry (models, Agent Service, SDKs, containers or other compute) when custom models, orchestration control, or specialized integration justify code. Choose an appropriate hosting service for any custom runtime; Foundry also supports declarative portal-based agents, so it is not synonymous with writing all components yourself.

Factors that push toward more custom work: unique competitive logic, special data or latency requirements, model choice or fine-tuning needs, unusual channels, and strict isolation. Factors that push toward buying or extending: standard processes, limited developer capacity, time to value, and lower maintenance.

Many solutions combine layers: a Copilot Studio agent for the front end, Foundry agents for specialized reasoning, and prebuilt Dynamics 365 agents for standard tasks, connected through interfaces supported by the selected services. MCP commonly exposes tools and context; agent-to-agent protocols or connected-agent features support delegation. Verify compatibility, authentication, authorization, data contracts, and error handling rather than assuming any two agents interoperate automatically.

4. Single-agent or multi-agent

CAF guidance on this choice can be summarized as follows. Splitting prompts into several agents does not itself isolate data: enforce separation through identities, authorized tools, deployment boundaries, and permitted message contents.

A single agent fits when:

  • The scope is narrow and well defined, with a limited set of tools.
  • One team owns it and one security boundary applies.
  • Simplicity, lower latency and lower cost are priorities.

A multi-agent design fits when:

  • The use case crosses security or compliance boundaries (different data owners, regions or sensitivity levels).
  • Several teams own different parts of the process.
  • Specialties differ enough that one agent would carry too many instructions and tools, hurting accuracy.
  • The system is expected to grow and should be extended by adding agents rather than rewriting one.

Common orchestration patterns:

  • Orchestrator (manager) and specialists – a coordinating agent routes work to specialized agents and merges results.
  • Sequential – agents hand off in a fixed order, like a pipeline.
  • Parallel – independent agents work simultaneously and results are combined.
  • Connected agents – an agent calls another agent as a tool, possibly built on a different platform.

Costs of multi-agent designs: more complexity, more hops (latency and tokens), harder testing and tracing, and a need for clear contracts between agents. Choose them for a reason, not by default.

5. Prompt library

A prompt library is a governed, shared collection of tested prompts and instruction patterns. Benefits: consistency, reuse, faster onboarding, quality and safety improvements applied in one place, and a record of what works.

Good practice:

  • Store prompts with purpose, owner, version, target model or agent, example inputs and expected outputs, and known limitations.
  • Review and test prompts (including adversarial inputs) before publishing, and re-test when models change.
  • Separate reusable templates from business-specific parameters.
  • Use the platform's native places for sharing, such as organizational prompt galleries in Microsoft 365 Copilot or shared components in Copilot Studio and Foundry, with access controls and review. Confirm which sharing features are available in your tenant; a gallery entry alone is not version control or evidence of evaluation.

6. AI Center of Excellence

An AI Center of Excellence (CoE) is a cross-functional group that enables the organization to adopt AI safely and at scale. It does not build every agent; it provides the framework others use.

Typical responsibilities:

  • Define the strategy, priorities and the use-case intake and scoring process.
  • Publish standards: architecture patterns, responsible AI requirements, security baselines, naming and lifecycle rules.
  • Maintain shared assets: prompt library, reusable connectors and components, evaluation datasets.
  • Provide training, communities of makers and support.
  • Govern: approve high-risk agents, manage environments and licensing, track cost and value.
  • Measure and report adoption and business results.

Typical members: business sponsors, architects, security and compliance, data owners, legal or risk, developers and makers, and change management. A common operating model is federated: the CoE sets guardrails and shares assets while business units build within them.

7. Building the roadmap

A practical roadmap:

  1. Foundation – governance, security baseline, data readiness, CoE, pilot team.
  2. Pilot – one or two high-value, low-risk agents with human approval and clear metrics.
  3. Scale – extend to more processes, add multi-agent patterns where justified, publish reusable assets.
  4. Optimize – tune cost and quality, retire unused agents, raise autonomy where evidence supports it.

Where justified, raise autonomy gradually: assistive (suggests) → supervised (acts after approval) → autonomous (acts and reports, escalates exceptions). Full autonomy is not a mandatory destination; high-risk actions can retain human approval permanently. Each change needs representative evaluation, observed performance, and risk approval. Track metrics tied to the business case, such as time saved, resolution rate, quality, user satisfaction and cost per task.

8. Worked example

A retailer wants agents for customer service, supplier onboarding and finance reconciliation.

  • Strategy: rank use cases. Customer service scores highest (high volume, existing knowledge base, Dynamics 365 Customer Service in use).
  • Build, buy or extend: use the prebuilt Dynamics 365 service agent capabilities and extend them with the retailer's knowledge sources. Supplier onboarding needs custom steps across ERP and email: build in Copilot Studio with flows. Reconciliation needs custom matching logic and a specialized model: pro-code in Foundry.
  • Single or multi-agent: finance data is under a stricter compliance boundary and owned by another team, so it stays a separate agent. A coordinating agent can delegate through a supported, authenticated interface; the finance service still validates the caller and limits both incoming requests and returned data.
  • Governance: the CoE defines who can publish agents, requires an approval step for payments, and shares a tested prompt library.
  • Roadmap: pilot customer service in one region with human review, then scale, then pilot reconciliation.

Turn this strategy into explicit delivery gates:

  1. Confirm readiness. Review the approved business requirements and grounding data. Resolve missing owners and permissions before expanding the pilot.
  2. Compare suitable options. Record which requirements the existing service agent meets and which require an extension. Compare both with a custom build using the same AI agent costs, benefits, and TCO model. A low licence price alone does not establish the cheapest operational design.
  3. Test separation. Give the service agent no direct finance write permission. Let a finance endpoint authorize a narrowly defined request and return only the needed result. Several agents using the same unrestricted credential would not enforce the intended boundary.
  4. Set the pilot gate. Agree a target response time, answer-quality threshold, and escalation measure with the business owner. Include tests for denied access and unavailable specialist services, not only successful handoffs.
  5. Choose the next stage from evidence. Expand only if those gates pass. Keep payment approval with an authorized person even if routine service questions become autonomous.

A single agent is the stronger alternative for a narrow FAQ with one owner and no mandatory separation. A multi-agent design is justified here by distinct ownership and finance controls, provided those controls are actually implemented.

Key takeaways

  • Agentic-first means designing processes around agents with human oversight, starting from outcomes and data readiness.
  • CAF for agents: plan, govern and secure, build, manage; governance comes before scale.
  • Investigate existing capabilities first, then compare extensions and custom platforms against requirements and lifetime cost.
  • Use multi-agent designs for separate security boundaries, multiple teams, specialization or planned growth; otherwise keep one agent.
  • A prompt library and an AI Center of Excellence provide reuse, standards and governance.
  • Roll out in stages and change autonomy only when evidence and the risk policy support it.

Sources