If you want your Copilot Studio agent to use a specific AI model (for example a model you deployed in Microsoft Foundry), you don’t need to build a custom connector or call an API manually for many scenarios. Copilot Studio now supports “Bring your own model for your prompts”-a native way to connect Microsoft Foundry models and use them directly inside Prompt tools / prompt actions.

What “Bring Your Own Model for Prompts” Actually Means

Copilot Studio has a Prompt tool (prompt action). When you create a prompt, you can select which model should run that prompt.

• By default, you see managed models.
• With this feature, you can connect models from Microsoft Foundry / Model catalog and pick them in the prompt’s Model dropdown.

[!NOTE]
You’re not replacing the whole agent’s brain globally.
You’re choosing which model runs a specific prompt action inside your agent.

Key Capabilities

1) Large model choice via Microsoft Foundry Model Catalog

Microsoft highlights access to models such as GPT 4.5, Llama, DeepSeek, and 11,000+ more through Microsoft Foundry’s model catalog-available to use in Copilot Studio prompts through this integration.

2) Prompt can be added as a tool or inside a topic

You can add a prompt:

• from the Tools tab (Add a tool → choose an existing prompt or create a new one), or
• inside Topics by adding a node and creating a New prompt.

3) Supports chat-completion type models (important limitation)

At the time of the documentation update, it currently supports models with chat completion type.

Step-by-Step: Use Microsoft Foundry Model in a Copilot Studio Prompt

Step 1: Create (or open) an agent in Copilot Studio

Microsoft’s flow starts with creating an agent (Agents → New agent → “Skip to configure”, then fill details and create).

Step 2: Add a Prompt tool (prompt action)

In Copilot Studio:

• Go to New tool → Prompt
• Give your prompt a name
• Add instructions either by writing your own prompt OR letting Copilot suggest one and selecting “Keep it”.

Step 3: Connect an Microsoft Foundry model to the prompt

On the right panel (next to prompt instructions):

• Open the Model dropdown
• Select the plus (+) to connect a model from Microsoft Foundry
• In the “Connect a model from Microsoft Foundry” screen, enter:
  • Model deployment name
  • Base model name
• Important: these must match exactly as they appear in Microsoft Foundry
• Select Connect

Step 4: Use the model in your agent

Once connected:

• The model appears in the Model dropdown
• Select it for the prompt
• Add that prompt into your agent flow

Microsoft clearly states: Anytime this prompt runs, it always uses the selected model.

Working with Images and Documents (When Relevant)

If your prompt includes image input, Copilot Studio will only show Microsoft Foundry models that support image/document usage. Microsoft lists examples like Phi vision models and GPT-4o/GPT-4.5-preview among those that work with images.

(If your use case is purely text, you can ignore this and just focus on chat-completion models.)

Governance and Administration (Very Important for Enterprises)

1) It uses a Connector

Microsoft Foundry models are “connected by connectors.”

2) Control with Power Platform Admin Center policies

You can manage governance for this connector in Power Platform admin center → Policies, under the connector name “Microsoft Foundry”. Microsoft calls out that you can add a specific data policy (DLP) for these models (and manage it alongside tenant data policies).

3) Connections are visible like other Power Platform connections

Each model connection a maker sets up is also available as a connection (similar to how Power Apps connections appear).

4) Responsible AI (RAI)

Microsoft recommends applying Responsible AI (RAI) policies for the models you use and managing that in Microsoft Foundry.

Design Pattern: How to Structure Prompts When You Bring Your Own Model

When you start choosing different models for different prompts, a simple pattern works best:

• One prompt = one “job”
  • Example: “Summarize customer email”
  • Separate prompt: “Extract order number and dates”
• Use the right model per job
  • Lower-cost / faster model for extraction or formatting
  • Strong reasoning model for complex decision support
• Keep the prompt stable
  • Remember: your prompt will always run on the selected model
  • So changes in model selection can change behavior; treat model choice like a “configuration decision”.

Use Cases

1) Industry-specific assistant (Healthcare / Legal / Finance)

• You choose a model that best fits domain language or compliance needs (through Foundry catalog)
• Use prompts for summarization, classification, or drafting, while still keeping the agent logic in Copilot Studio

2) Multi-model strategy inside one agent

Within the same Copilot Studio agent:

• Prompt A uses a fast model for “extract entities”
• Prompt B uses a stronger model for “generate final response”
  This is possible because model selection happens per prompt tool.

3) Controlled rollouts and governance

Because Foundry models are connected via a connector and can be governed via DLP policies in Power Platform admin center, you can:

• allow only approved teams to use the connector
• restrict usage in certain environments (Dev/Test/Prod)
• enforce compliance boundaries

Summary

Microsoft Copilot Studio now allows organizations to bring their own Microsoft Foundry models directly into prompt actions, giving enterprises greater control over which AI model powers each specific task inside an agent.

Instead of relying only on default managed models, makers can connect a model deployed in Microsoft Foundry by selecting it in the Model dropdown within a Prompt tool, entering the correct deployment and base model names, and using it immediately inside agent flows. Every time that prompt runs, it consistently uses the selected model—enabling predictable behavior and controlled AI design.

References

• Microsoft Learn: Bring your own model for your prompts

Artificial Intelligence is moving from single chatbot experiences to multi-agent systems, where multiple intelligent agents collaborate to solve complex business problems. Instead of one large model handling everything, different agents specialize in tasks like planning, data retrieval, validation, summarization, or compliance checks.

Microsoft Foundry provides a structured environment to design, build, deploy, and govern such multi-agent solutions. It offers model access, orchestration, evaluation, observability, and enterprise-grade security.

This article explores how multi-agent systems are implemented using Microsoft Foundry, the architectural patterns involved, governance implications, and a real-world example of intelligent orchestration in action.

Designing Coordinated AI Workforces for the Enterprise

Artificial intelligence in the enterprise has rapidly evolved from experimental chatbots to mission-critical systems embedded in operational workflows. Early implementations typically relied on a single large language model responding to prompts in isolation. While this approach works for simple Q&A scenarios, it begins to fail when organizations attempt to automate complex reasoning, decision-making, classification, and cross-system orchestration.

Enter the multi-agent paradigm

Rather than depending on one monolithic AI model to do everything, multi-agent systems decompose intelligence into specialized agents that collaborate toward a shared outcome. Microsoft Foundry provides the architectural foundation to design, orchestrate, govern, and scale such systems responsibly within enterprise boundaries.

The Shift from Single AI to Coordinated Intelligence

Traditional AI chatbot implementations often struggle with reliability, explainability, and control. As prompt complexity grows, responses become harder to debug. Costs increase as larger models are repeatedly invoked for tasks that do not require advanced reasoning. Governance becomes difficult because there is no structured breakdown of responsibility.

Multi-agent systems address these limitations by introducing specialization. Instead of one AI handling classification, routing, estimation, compliance, and summarization simultaneously, the workload is distributed across purpose-built agents.

This mirrors how organizations operate in reality. In a company, different departments handle specific responsibilities — finance manages budgets, legal ensures compliance, operations handle execution. Multi-agent systems apply the same principle to artificial intelligence.

Microsoft Foundry enables this structured, collaborative model by providing not only model hosting capabilities but also orchestration mechanisms, knowledge integration, identity enforcement, and observability.

Understanding the Multi-Agent Architecture in Foundry

At its core, a multi-agent system implemented in Microsoft Foundry consists of four foundational layers:

1. Specialized Agents
2. An Orchestrator
3. Shared Context or Memory
4. Governance and Observability Controls

Each component plays a defined role in the system.

Specialized Agents

Every agent in the system is designed with a single responsibility. One agent might evaluate urgency. Another may assign ownership. A third might estimate effort. These agents are defined using carefully engineered prompts, structured output schemas, optional tool integrations, and guardrails.

The critical principle here is determinism. In enterprise settings, agents must produce structured, machine-readable outputs — typically JSON schemas — so downstream orchestration remains reliable.

In Microsoft Foundry, agents can be configured to:

• Use different models depending on task complexity
• Access specific knowledge areas
• Call tools or APIs
• Enforce output validation rules
• Operate under identity constraints

This modularity enables independent tuning and governance of each agent.

The Orchestrator

The orchestrator is not another “super AI.” It does not attempt to solve the business problem itself. Instead, it coordinates the collaboration between agents.

When a request is received, the orchestrator determines:

• Which agents must be invoked
• Whether calls should be sequential or parallel
• How intermediate results should be aggregated
• Whether conditional routing is required
• What final structure should be returned

In Microsoft Foundry, orchestration logic can be implemented using workflow definitions, conditional routing logic, or agent chaining patterns.

Shared Memory and Context Management

For agents to collaborate effectively, they must operate within a shared context. This may include:

• Original user input
• Intermediate structured outputs
• Retrieved knowledge from indexed data
• Session-level state information

Foundry allows structured context injection and secure retrieval from knowledge stores, ensuring that agents operate with the right information while respecting data boundaries.

Governance and Observability

Enterprise AI cannot function as a black box. Every interaction must be traceable, auditable, and compliant.

Microsoft Foundry integrates:

• Prompt and response logging
• Guardrail enforcement
• Identity management
• Model usage tracking
• Cost monitoring
• Access control policies

This transforms multi-agent systems from experimental prototypes into production-ready enterprise infrastructure.

A Practical Example: Implementing a Bug Triage Multi-Agent System

To illustrate how multi-agent systems operate in practice, consider a software organization attempting to automate its bug triage process.

When a new ticket arrives, the organization needs to determine:

• How urgent the issue is
• Which team should handle it
• How much effort it will require

Instead of building one large prompt attempting to answer all three questions simultaneously, the organization defines three independent agents:

Priority Agent
Analyzes ticket description and assigns a severity level.

Team Agent
Determines ownership based on domain keywords and context.

Effort Agent
Estimates implementation complexity and expected resolution time.

When a ticket such as:

“The checkout page crashes when selecting PayPal on mobile Safari.”

is submitted, the orchestrator sends the description to each agent. These agents may run in parallel because their analyses are independent.

Each agent returns a structured output:

• Priority: High
• Team: Frontend Payments Team
• Effort: Medium (Estimated 3 days)

The orchestrator aggregates these structured responses into a final JSON payload suitable for automation workflows, dashboards, or ticketing systems.

This modular architecture improves:

• Debuggability (each agent can be evaluated separately)
• Cost efficiency (lighter models can handle simpler classification tasks)
• Governance (each agent operates within defined boundaries)
• Maintainability (agents can be upgraded independently)

Orchestration Patterns in Microsoft Foundry

Multi-agent systems are not limited to simple parallel calls. Foundry supports several orchestration patterns depending on business requirements.

Sequential orchestration is useful when later agents depend on earlier outputs. For example, escalation logic may only execute if a priority agent returns “Critical.”

Parallel orchestration improves performance when tasks are independent.

Conditional routing enables policy-based flows, such as invoking a compliance agent only when certain keywords are detected.

Hierarchical orchestration allows a supervisory agent to delegate subtasks to specialized sub-agents, particularly in research-heavy or multi-step reasoning scenarios.

Selecting the appropriate pattern is a design decision driven by latency requirements, cost considerations, and business complexity.

Governance Considerations in Multi-Agent Deployments

As multi-agent systems become more autonomous, governance becomes increasingly important.

Organizations must answer critical questions:

• Which model was used for each agent?
• Was sensitive data accessed?
• Were guardrails triggered?
• How much did this interaction cost?
• Was policy routing applied correctly?

Microsoft Foundry provides mechanisms to monitor model selection, enforce token limits, isolate agent permissions, and apply identity-based access control using enterprise identity systems.

Without governance, multi-agent systems risk becoming fragmented AI silos. With governance, they become accountable digital workforces.

Cost Optimization in Multi-Agent Architectures

A common misconception is that multi-agent systems are inherently expensive. In reality, they often reduce cost when designed correctly.

Instead of invoking a high-capacity model for every task, Foundry allows:

• Lightweight models for classification
• Medium-tier models for structured reasoning
• Premium models for deep analysis only when required

Model routing policies can dynamically select models based on complexity thresholds. This ensures intelligent cost-performance balancing across the system.

Caching, token budgeting, and context trimming further optimize operational expenditure.

Debugging and Reliability

Multi-agent systems introduce new debugging challenges. Agents may disagree. Outputs may drift. Orchestrators may misroute.

To address this, production systems should:

• Log intermediate agent outputs
• Validate structured responses
• Implement maximum iteration limits
• Define fallback mechanisms
• Monitor confidence signals

Foundry’s observability framework makes it possible to trace the entire lifecycle of a multi-agent interaction, enabling iterative refinement and system hardening.

Multi-Agent Systems vs Traditional Workflow Automation

It is important to distinguish multi-agent systems from conventional workflow automation tools.

Traditional workflows are deterministic. They follow predefined rule trees. They do not reason — they execute logic.

Multi-agent systems introduce probabilistic reasoning, contextual interpretation, and adaptive behavior. They are not replacements for workflows but rather intelligent layers embedded within them.

In practice, enterprises often combine both:

• Workflows handle structured execution.
• Agents handle reasoning and interpretation.

Production Readiness and Strategic Adoption

Before deploying multi-agent systems in enterprise environments, organizations should validate:

• Structured output enforcement
• Guardrail definitions
• Logging and observability configuration
• Identity isolation
• Cost monitoring
• Fallback strategies
• Data classification policies

Multi-agent systems represent not just a technical shift but an operational shift. They introduce digital collaborators capable of reasoning within defined boundaries.

The Road Ahead

As Microsoft continues to enhance Foundry with agent identity, cross-agent communication, advanced orchestration frameworks, and observability enhancements, multi-agent architectures will mature into fully managed digital ecosystems.

Future systems may include:

• Agent marketplaces
• Enterprise memory graphs
• Self-optimizing routing
• Human-in-the-loop validation layers
• Federated agent collaboration

The transformation from chatbot implementations to coordinated AI workforces has already begun.

Conclusion

Implementing multi-agent systems with Microsoft Foundry allows organizations to build AI architectures that are modular, governed, cost-optimized, and production-ready.

Instead of relying on a single generalized intelligence, enterprises can design coordinated networks of specialized agents — each accountable, observable, and secure.

This approach moves AI from experimentation into enterprise-grade system engineering.

The future of enterprise AI is not a single model.

It is a structured ecosystem of intelligent agents working together under governance — and Microsoft Foundry provides the architectural foundation to build it.

Microsoft Foundry Local is Microsoft’s way to run generative AI models directly on your own device (laptop, desktop, or server) instead of calling a cloud endpoint. You install it once, download a model once, and then you can run inference locally using a CLI, an OpenAI-compatible REST API, or SDKs (Python/JavaScript/.NET, etc.).

This is useful when you want privacy, low latency, offline capability, or you simply want to avoid recurring cloud inference cost for certain workloads.

What Foundry Local is

Foundry Local is an on-device AI inference solution that lets you run AI models locally through:

• CLI (foundry)
• REST API (OpenAI-compatible)
• SDKs (for building apps that talk to the local service)

It’s currently available as a preview feature, meaning capabilities may change and some parts can be limited compared to a production cloud service.

When Foundry Local is a fit (and when it isn’t)

Foundry Local is best for single-device or edge scenarios. For multi-user, high-throughput, or broader production workloads, Microsoft suggests moving to Microsoft Foundry (cloud).

Benefits

1) Privacy and data control

Your prompts and outputs are processed on your machine when you call a local endpoint (for example, http://localhost:PORT). This helps keep sensitive data local.

2) Lower latency

Because inference runs locally, you can often get faster responses, especially for interactive apps.

3) Cost efficiency

You reuse existing hardware and reduce (or eliminate) cloud inference costs for local workloads.

4) OpenAI-compatible integration

Foundry Local exposes an API that is compatible with OpenAI-style chat completions, which makes it easier to switch your app from cloud → local by changing the base URL.

5) Hardware-aware model variants

When you run a model by an alias (example: qwen2.5-0.5b), Foundry Local can pick the best variant for your device (GPU/NPU/CPU) and download what matches your hardware.

System requirements and prerequisites

Below are typical prerequisites for getting started:

• OS: Windows 10 (x64), Windows 11 (x64/ARM), Windows Server 2025, macOS
• Hardware: Minimum 8 GB RAM and 3 GB free disk (recommended 16 GB RAM and 15 GB disk)
• Network: Internet required for first-time model downloads; after that, cached models can run offline

Also:

• A terminal (Windows Terminal / macOS Terminal).
• Initial downloads may include execution providers optimized for your hardware.

How Foundry Local works (simple architecture)

Foundry Local typically involves these pieces:

• Foundry CLI (foundry): manages models, service, and cache
• Local service: exposes a local endpoint (OpenAI-compatible REST server)
• Model cache: where downloaded model files live on disk
• Execution providers: acceleration layers for CPU/GPU/NPU depending on your machine

Quick checks:

• foundry service status shows whether the service is running and prints the local endpoint.
• curl http://localhost:PORT/openai/status can validate that the REST service is reachable (replace PORT from foundry service status).

Installation

Windows (WinGet)

winget install Microsoft.FoundryLocal

Verify:

foundry --version

Upgrade:

winget upgrade --id Microsoft.FoundryLocal

Uninstall:

winget uninstall Microsoft.FoundryLocal

macOS (Homebrew)

brew tap microsoft/foundrylocal
brew install foundrylocal

Upgrade:

brew upgrade foundrylocal

Uninstall:

brew rm foundrylocal
brew untap microsoft/foundrylocal
brew cleanup --scrub

Manual installers (GitHub releases)

If you prefer not to use package managers, the GitHub repo provides manual installation steps and release artifacts.

How to use Foundry Local (CLI-first workflow)

1) List available models

foundry model list

This may download execution providers the first time.

2) Run a model interactively

foundry model run qwen2.5-0.5b

Then type a prompt in the terminal (example: “Why is the sky blue?”).

3) Control the local service

Common service commands include:

foundry service start
foundry service stop
foundry service restart
foundry service status

4) Manage downloads and cache

Useful model/cache commands include:

foundry model download <model>
foundry model load <model>
foundry model unload <model>

foundry cache list
foundry cache remove <model-name>

Using Foundry Local via REST API (OpenAI-compatible)

Foundry Local supports an OpenAI-compatible Chat Completions style endpoint (POST /v1/chat/completions).

Example: call chat completions with curl

• Get the endpoint/port:

foundry service status

• Send a request (replace PORT):

curl http://localhost:PORT/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen2.5-0.5b",
    "messages": [
      {"role": "user", "content": "Explain RAG in simple words."}
    ],
    "temperature": 0.3
  }'

Notes:

• Your model value can be an alias or a specific model id (aliases allow hardware-aware selection).
• The REST API is under active development and can have breaking changes (important for production planning).

Using Foundry Local from applications (SDK examples)

Option A: Python (OpenAI SDK + Foundry Local manager)

Microsoft’s integration guidance shows using FoundryLocalManager to start the service, load a model, and then point the OpenAI client at the local endpoint.

import openai
from foundry_local import FoundryLocalManager

alias = "qwen2.5-0.5b"
manager = FoundryLocalManager(alias)

client = openai.OpenAI(
    base_url=manager.endpoint,
    api_key=manager.api_key  # not required for local usage
)

resp = client.chat.completions.create(
    model=manager.get_model_info(alias).id,
    messages=[{"role": "user", "content": "Write a 3-line summary of Foundry Local."}]
)

print(resp.choices[0].message.content)

Option B: JavaScript / Node.js

The Learn article also provides a JavaScript flow using foundry-local-sdk and the OpenAI JS SDK pattern.

Option C: .NET (native + OpenAI-compatible patterns)

Foundry Local has a .NET-friendly path (including a NuGet SDK package) and documentation for using “native chat completions” in C# projects.

Practical use cases

1) Sensitive internal data scenarios

• HR policy Q&A, finance analysis, legal summaries
• Customer data processing where you want to reduce exposure by keeping prompts local

2) Offline / low-connectivity environments

• Field teams (manufacturing sites, remote locations)
• Secure environments where external network calls are restricted

3) Low-latency experiences

• Real-time copilots inside desktop apps
• Local assistive tools for developers, writers, analysts

4) Prototyping before cloud deployment

• Build a feature locally, validate model fit and prompts
• Later move to Microsoft Foundry (cloud) for scale and shared access

5) Local “chat UI” integrations

Microsoft provides guidance for integrating Foundry Local with tools like Open WebUI so you can have a local chat interface backed by Foundry Local models.

6) Beyond chat: audio transcription

Foundry Local also documents native audio transcription using a Whisper model in a C# console application (local inference, streaming output).

Examples you can try today

Example 1: First-run CLI demo (fastest path)

foundry model run qwen2.5-0.5b

Ask: “Give me 5 bullet points about Microsoft Copilot Studio.”

Example 2: Run a bigger model (if your hardware supports it)

foundry model run gpt-oss-20b

Microsoft notes CUDA variants can require an NVIDIA GPU with ~16 GB VRAM or more for some larger models.

Example 3: Starter projects (ready-made code)

Microsoft provides starter projects such as a chat app starter, summarize sample, and function calling example.

Limitations and considerations

1) Preview + breaking changes risk

Foundry Local is in preview, and the REST API is explicitly described as under active development with potential breaking changes. Plan accordingly if you are building something long-lived.

2) Not for distributed production hosting

Microsoft’s guidance is clear: Foundry Local is for on-device inference, not distributed/containerized/multi-machine production deployments.

3) Hardware constraints are real

Your experience depends on:

• RAM/VRAM/NPU availability
• Model size and quantization
• Drivers and execution provider availability

4) OS support

Microsoft’s “Get started” guidance lists Windows (including Server 2025) and macOS as supported OS options.
(If you develop in Linux environments like WSL2, you may need to call the Foundry Local service remotely from a supported host machine.)

5) First-time download requirement

You typically need internet access to download models and execution providers initially. After caching, you can run offline.

Best practices and troubleshooting tips

Microsoft’s troubleshooting guidance highlights common patterns:

• If inference is slow, prefer GPU acceleration and consider more quantized variants (for example INT8).

• If the service isn’t accessible or has port binding issues, try:

    foundry service restart
  

• If installation via winget has scope/machine issues, Microsoft provides a PowerShell-based approach for all-users installation.

Summary

Foundry Local gives you a practical way to run LLMs and other AI models locally with a developer-friendly experience: CLI to manage models, a local service with OpenAI-compatible endpoints, and SDK integrations for Python/JS/.NET. It shines in privacy-first, low-latency, offline, and prototyping scenarios. The main tradeoff is that it’s a preview, it’s not meant for distributed production hosting, and model performance depends heavily on your hardware.

References

• Microsoft Learn: Get started with Foundry Local
• Microsoft Learn: What is Foundry Local?
• GitHub: microsoft/Foundry-Local
• Microsoft Learn: Foundry Local architecture
• Microsoft Learn: Integrate inference SDKs with Foundry Local
• Microsoft Learn: Best practices and troubleshooting guide for Foundry Local
• Microsoft Learn: Foundry Local CLI reference
• Microsoft Learn: Foundry Local REST API reference

Microsoft’s Frontier program is an early-access program that lets you try the newest Copilot and agent experiences inside Microsoft 365 before they become generally available. It’s meant for organizations (and some individual subscribers) who want to learn early, experiment safely, and provide feedback that helps Microsoft shape what ships next.

At the same time, Microsoft’s 2025 Work Trend Index describes a broader shift: the rise of the “Frontier Firm”-organizations that combine people and AI agents as “digital labor” to scale capacity and close the “time and energy” gap. Frontier (the early-access program) is one practical way to start moving along that journey.

What is the Microsoft Frontier program?

Frontier is an early-access space for the latest AI innovations in Microsoft 365. It provides hands-on access to:

• Experimental agents (available via Agent Store),
• Preview features in Microsoft 365 apps (Word/Excel/PowerPoint and more),
• Other “what’s next” capabilities beyond core apps.

Microsoft positions Frontier as a way to:

• Explore new Copilot experiences before general availability,
• Learn faster with real usage,
• Share feedback using built-in tools,
• Do all of this while staying in the familiar Microsoft 365 environment.

Frontier vs. Frontier Firm (and why it matters)

These terms sound similar, but they’re different:

• Frontier program: an early-access program inside Microsoft 365 to try new Copilot/agent features early.
• Frontier Firm: a type of organization described in the Work Trend Index-built around “intelligence on tap” and human + agent hybrid teams.

Journey to the Frontier Firm

Microsoft describes three phases (not always linear; many orgs will be in multiple phases at once):

• Human with assistant
  AI helps employees work better and faster by removing routine work.
• Human-agent teams
  Agents join teams as “digital colleagues,” doing specific tasks under human direction.
• Human-led, agent-operated
  Humans set direction; agents execute end-to-end workflows and processes, checking in as needed.

Microsoft also highlights why this shift is urgent: leaders see a capacity gap (productivity pressure vs. limited human time/energy), and many expect agents to be integrated into AI strategy in the next 12-18 months.

How Frontier helps: Frontier gives you a controlled way to pilot “phase 2 and 3” style agent capabilities early-so you can adapt people, process, and governance before broad rollout.

What you can explore in Frontier

Microsoft groups Frontier access into three main categories:

• Frontier agents
  Experiential AI agents available in the Microsoft 365 Copilot Agent Store.
• Frontier core app features
  Early-access features inside Microsoft 365 apps like Word, Excel, etc.
• Other Frontier capabilities
  Experiences beyond agents and core apps-Microsoft highlights examples such as Agent 365, Copilot Pages, Project Opal, and Windows 365 AI-enabled Cloud PCs on the Frontier program page.

Who can use Frontier?

Enterprise & business users

If you have a Microsoft 365 Copilot license, you’re eligible to try Frontier features-subject to availability and your organization’s admin settings.

Individuals

People with Microsoft 365 Personal, Family, or Premium subscriptions can also access certain Frontier features (initially called out as web experiences like Word/Excel and Copilot chat on the web, with early availability noted for U.S.-based subscribers in English first).

Important program notes

• Frontier includes experimental capabilities, so features may change as Microsoft improves them.
• Early availability may be limited by region and language (with initial rollout noted for English/U.S. in some cases).

Key benefits of joining the Frontier program

1) Early capability access (ahead of GA)

You get to explore new Copilot and agent features earlier, which is valuable if you’re responsible for AI strategy, adoption, or governance.

2) Faster learning and readiness

Frontier is designed to “accelerate learning” and gather real-world feedback-so your teams can build internal skills and patterns before features become mainstream.

3) Influence through feedback loops

Because Frontier is experimental, Microsoft explicitly expects feedback to guide what becomes broadly available (often via built-in feedback tools).

4) Practical progress toward the “Frontier Firm” model

Work Trend Index data points to agents becoming part of company strategy soon, and Frontier helps you pilot the tools that enable human-agent teams and agent-run workflows.

5) Safer experimentation inside your Microsoft 365 environment

Microsoft frames Frontier as exploration within the security and familiarity of Microsoft 365 (while still requiring admins to control access).

How to enroll and activate Frontier (step-by-step)

Terminology note: “Enroll” often means your admin opts your tenant/users in, and then users see Frontier features where available.

A) IT admin: turn on Frontier in Microsoft 365 admin center

Microsoft’s “Getting started with Frontier” guide describes an admin opt-in flow in the Microsoft Admin Center, including:
Microsoft Admin Center → Copilot → Settings → User Access → Copilot Frontier → Turn on Frontier features

Admins can also manage access for web apps through the same “Copilot Frontier” area and grant access to specific users.

B) End users: find and use Frontier agents (Agent Store)

Microsoft Support describes how users can discover Frontier-labeled agents in Copilot Chat:

• Sign in at microsoft365.com
• Open Copilot Chat and go to All Agents / Agent Store
• Look for agents labeled “(Frontier)”
• Install or request access (depending on admin settings)

C) Desktop & mobile: Microsoft 365 Insider / Beta channel (where required)

The getting started guide also mentions Insider/Beta enrollment for some desktop/mobile experiences:

• Admins can add users to the Microsoft 365 Insider program (with an option like “Channel Picker” suggested).
• Users may need to switch to Beta Channel in Office apps (e.g., File → Account → Update Channel → Beta Channel) to receive some early features.

D) Special Frontier experiences may have extra prerequisites

Some “beyond core apps” offerings have additional requirements. For example, the guide lists separate eligibility for things like AI-enabled Cloud PCs and Microsoft Agent 365 (including “Modern Billing” and accepting terms).

Governance and best practices for running Frontier safely

Frontier is powerful, but it’s still an early-access program-so treat it like a controlled preview.

Recommended approach

• Start with a pilot group
  Use a small, cross-functional group (IT + security + a few business teams) to evaluate value, risk, and user experience.
• Use admin controls intentionally
  Frontier access depends on admin settings and agent access policies; curate what’s available if you need tighter control.
• Define success metrics
  Tie pilots to outcomes: time saved, cycle time reduction, quality improvements, user satisfaction, reduced rework, etc.
• Create a feedback rhythm
  Make feedback part of the pilot process (weekly check-ins, “what worked / what didn’t,” and use built-in feedback tools).
• Prepare a change/adoption plan
  Frontier features may change-so keep training content lightweight and updateable (short videos, internal FAQs, “prompt patterns,” and do/don’t guidance).

Use cases

Below are practical ways organizations use Frontier capabilities to move toward the Frontier Firm model.

1) Executive and leadership: strategy acceleration

• Use Frontier Copilot experiences to draft strategic narratives, operating model changes, and “human-agent team” charters aligned to the 3-phase journey described in Work Trend Index 2025.

2) Sales: pipeline and outreach support

• Try “Frontier” agents such as Sales-focused experiences highlighted on the Frontier program page (example: Sales Development Agent is referenced as a Frontier learning item).
• Use Copilot Chat + agents to summarize customer context, prepare call briefs, and create follow-up content consistently.

3) Marketing: faster campaign execution

• Use early features like Copilot Pages (called out on the Frontier program page) to turn ideas into structured campaign plans and working assets in one place.

4) HR and People teams: employee support and insights

• Explore People-related agent experiences (Support documentation references “Person view in People Agent”).
• Common scenarios: onboarding Q&A, policy summarization, role-based help, and internal communications drafting.

5) Finance and operations: analysis and reporting

• Pilot early Excel/Word Copilot capabilities (Frontier includes early access in Microsoft 365 apps and web versions depending on eligibility).
• Use for variance explanations, narrative reporting, and faster insight generation from existing workbooks.

6) IT and security: controlled experimentation with agents

• Use admin settings to enable Frontier for selected users and manage access to agents.
• Build an internal “approved agents” list, document supported scenarios, and establish escalation paths when users see access blocks or policy prompts.

7) “Human-led, agent-operated” pilots (advanced)

To test phase 3 concepts from the Work Trend Index, pick one workflow where humans set direction and agents do the execution (with oversight). Examples:

• Incident response triage (draft, summarize, propose next steps)
• Vendor onboarding documentation
• Policy-to-procedure conversion and validation
  These align directly with the “agents execute business processes and workflows, checking in as needed” description.

Common rollout pattern (a simple playbook)

• Choose 2-3 high-value scenarios (one per function: Sales, HR, IT).
• Enable Frontier for a pilot group (admin opt-in + Agent Store policy).
• Run a 2-4 week pilot with lightweight training + weekly review.
• Document what worked (prompts, templates, governance decisions).
• Scale in waves (expand access, refine policies, formalize training).

Summary

Microsoft Frontier is an early-access program inside Microsoft 365 that gives you hands-on access to experimental agents and preview Copilot features-helping you learn faster, influence product direction through feedback, and prepare your organization for broader adoption.

It also fits neatly into Microsoft’s broader “Frontier Firm” journey: moving from AI as an assistant, to human-agent teams, and ultimately to human-led, agent-operated workflows. Frontier gives you a structured, admin-controlled way to start that transition with real scenarios, not just theory.

References

• Microsoft Adoption: Frontier program
• Microsoft WorkLab: 2025: The year the Frontier Firm is born
• Microsoft Support: What is Frontier?

As organizations build more AI-powered applications, one common challenge keeps appearing: which AI model should be used for which task?
Some prompts are simple and need quick answers, while others require deep reasoning, higher accuracy, or larger context windows. Using a single large model for everything often leads to high costs, while using only smaller models can reduce answer quality.

Model Router in Microsoft Foundry solves this problem.

Model Router is a smart routing layer provided by Azure AI Foundry that automatically selects the most suitable underlying language model for each incoming prompt. Developers interact with one single endpoint, and Model Router takes care of deciding which model should answer which request, based on complexity, cost, and quality needs.

This approach allows teams to build scalable, cost-efficient, and high-quality AI solutions without managing multiple model endpoints or writing complex routing logic themselves.

What Is Model Router in Microsoft Foundry?

Model Router is a deployable chat model available in the Azure AI Foundry model catalog. Unlike traditional models, it does not generate responses on its own. Instead, it works as an intelligent decision engine that sits in front of multiple large language models (LLMs).

When a request is sent to the Model Router:

• It analyzes the prompt
• Determines the level of reasoning, complexity, and expected quality
• Routes the request to the most appropriate underlying model
• Returns the response back to the application

From the application’s perspective, this all happens behind the scenes.

Key Characteristics

• Single endpoint for multiple models
• Dynamic model selection per request
• Built-in cost and quality optimization
• No changes required in application logic

Why Model Router Matters

1. Cost Control at Scale

Not every prompt needs a powerful and expensive model. Model Router ensures that:

• Simple questions are answered by smaller, cheaper models
• Complex tasks are handled by advanced reasoning models

This dramatically reduces overall AI spend, especially in high-volume applications.

2. Simplified Architecture

Without Model Router, developers must:

• Deploy multiple models
• Write logic to decide which model to use
• Maintain and test routing rules

Model Router removes this complexity by acting as a central intelligence layer.

3. Consistent User Experience

Users always interact with the same chatbot or API endpoint, while the platform dynamically adjusts the intelligence level behind the scenes.

How Model Router Works

The internal workflow of Model Router can be understood in four simple steps:

• Request Received
  The application sends a chat completion request to the Model Router endpoint.
• Prompt Analysis
  Model Router analyzes:
  • Prompt length
  • Task type (summarization, reasoning, generation, etc.)
  • Complexity and ambiguity
• Routing Decision
  Based on the selected routing strategy and allowed model subset, it chooses the best underlying model.
• Response Returned
  The chosen model generates the response, which is sent back through the router to the application.

All of this happens in real time and is fully managed by Azure AI Foundry.

Routing Modes in Model Router

Model Router supports different routing strategies to align with business goals.

Balanced Mode (Default)

• Balances cost and quality
• Ideal for most enterprise applications
• Uses advanced models only when necessary

Cost-Optimized Mode

• Prioritizes lower-cost models
• Suitable for high-volume workloads such as:
  • Internal chatbots
  • FAQ systems
  • Support ticket triage

Quality-Optimized Mode

• Prioritizes best possible responses
• Routes most prompts to top-tier models
• Useful for:
  • Legal or compliance analysis
  • Executive reporting
  • Customer-facing critical responses

Supported Model Selection (Model Subsets)

Model Router allows you to define a subset of models it is allowed to route to. This is important for:

• Compliance requirements
• Performance consistency
• Cost predictability

For example:

• Exclude experimental models
• Restrict routing to models approved by security teams
• Limit to models with specific context sizes

This gives organizations governance without losing flexibility.

Implementation in Microsoft Foundry

Step 1: Deploy Model Router

• Open Azure AI Foundry
• Navigate to Model Deployments
• Select Deploy a model
• Choose model-router from the catalog
• Configure:
  • Routing mode
  • Allowed model subset
  • Rate limits and content filters

Once deployed, you receive a standard endpoint, just like any other chat model.

Step 2: Call Model Router Using Chat Completions

Model Router uses the same Chat Completions API as other Azure OpenAI models.
This means no special SDKs or APIs are required.

Example Request (Conceptual)

{
    "messages": [
        { "role": "system", "content": "You are a helpful assistant." },
        { "role": "user", "content": "Create a summary of our quarterly sales performance." }
    ],
    "max_tokens": 300
}

The application does not specify which model to use. Model Router decides this automatically.

Step 3: Monitor and Optimize

After deployment, teams should:

• Monitor usage patterns in Azure
• Track which models are being selected most often
• Adjust routing mode or model subsets if needed
• Fine-tune prompts to avoid unnecessary complexity

Best Practices for Using Model Router

1. Start with Balanced Mode

Balanced mode works well for most scenarios and provides a strong baseline before optimization.

2. Control Prompt Complexity

Long or ambiguous prompts may push routing toward expensive models.

Always use:

• Clear instructions
• Structured prompts
• Retrieval-based approaches (RAG) where possible

3. Define Governance Early

Use model subsets to:

• Enforce compliance
• Control cost exposure
• Avoid unexpected model behavior

4. Monitor Cost and Performance Together

Do not optimize purely for cost or quality. The real value of Model Router comes from finding the right balance.

Use Cases

1. Enterprise Knowledge Assistant

Employees ask questions ranging from:

• What is our leave policy?
• Summarize compliance risks across regions.

Model Router ensures simple queries stay low-cost while complex ones get high-quality responses.

2. Customer Support Automation

• Password reset questions → smaller models
• Complex troubleshooting → advanced reasoning models

This improves response time and reduces support costs.

3. Internal Reporting and Analysis

• Routine summaries → cost-efficient models
• Strategic insights → quality-optimized models

All handled through one endpoint.

Sample Scenario

Scenario:
An HR chatbot serves 10,000 employees globally.

Without Model Router:

• Uses a single advanced model
• High monthly AI costs
• Overkill for simple questions

With Model Router:

• Simple HR FAQs routed to smaller models
• Policy analysis routed to advanced models
• Same chatbot UI
• Lower costs and better scalability

Summary

Model Router in Microsoft Foundry is a foundational capability for building modern AI applications at scale. It:

• Automatically selects the right model per request
• Reduces cost without sacrificing quality
• Simplifies architecture with a single endpoint
• Enables governance, flexibility, and scalability

For organizations adopting AI across departments, Model Router removes the complexity of model management and allows teams to focus on business value instead of infrastructure decisions.

References

• Microsoft Learn - Model Router Concepts
• Microsoft Learn - How to Use Model Router

At Microsoft Ignite 2025, Microsoft announced one of the most important updates in the Copilot and agentic-AI ecosystem - the Microsoft 365 Agent Store. This new marketplace brings AI agents directly into the Microsoft 365 environment, helping organizations discover, deploy, and govern ready-made or custom-built agents securely and at scale.

The Agent Store marks a major shift from “AI features” to AI-powered workflows, allowing businesses to use specialized agents for tasks like document summarization, ticket triage, HR automation, compliance monitoring, SharePoint insights, and more. Instead of building everything from scratch, customers can now select from curated, safe, compliant agents that are instantly usable inside the Microsoft 365 ecosystem.

What is the Agent Store?

The Microsoft 365 Agent Store is a centralized marketplace, similar to the app store, where organizations can:

• Discover prebuilt AI agents created by Microsoft, partners, or internal developers
• Browse agents for productivity, IT operations, HR, finance, security, and industry-specific tasks
• Deploy agents to users or groups with controlled permissions
• Manage updates, compliance, and lifecycle from a central admin experience

Each agent in the store is built on the Microsoft 365 Agent Framework, ensuring it is:

• Secure
• Governed
• Integrated with Microsoft Graph
• Compatible with Copilot experiences
• Enterprise compliant (access controls, data boundaries, audit logs)

Key Concepts Behind the Agent Store

1. Enterprise-ready agents

Agents are designed to run inside the Microsoft 365 trust boundary. They can access:

• Files
• Teams chats
• SharePoint data
• Outlook mail
• Calendar
• Planner / Loop tasks

All access respects user permissions and organization policies.

2. Multi-channel availability

Agents from the Store can work across:

• M365 Chat
• Microsoft Copilot in Teams
• SharePoint
• Outlook
• Third-party apps, depending on configuration
• Copilot Studio (for customization)

3. Publisher ecosystem

The store includes agents from:

• Microsoft (e.g., SharePoint Agent, Security Agent)
• Independent Software Vendors (ISVs)
• Enterprise developers, who can publish internal agents to the private catalog

4. Compliance & governance

Admins have full control:

• Approve or block agents
• Assign usage permissions
• Track analytics, usage, and data access
• Enforce DLP, sensitivity labels, retention policies

How to Access the Microsoft 365 Agent Store?

Below are the step-by-step instructions as of the Ignite 2025 announcement.

Step 1: Open Microsoft 365 Admin Center

Navigate to:
Microsoft 365 Admin Center → Copilot → Agent Store

Here, admins can browse public and private agents.

Step 2: Browse Available Agents

You will see categories such as:

• Productivity
• IT administration
• SharePoint & content services
• HR automation
• Finance
• Legal & compliance
• Industry solutions (healthcare, retail, manufacturing)

Each listing displays:

• Description
• Capabilities
• Data access required
• Pricing (if applicable)
• Permissions
• Security & certification details

Step 3: Add an Agent to Your Organization

Admins can:

• Install the agent
• Select users, security groups, or departments for access
• Configure settings such as data scope, permissions, and allowed actions
• Enable audit logging

Step 4: Users Access the Agent

Once installed, the agent appears in:

• Microsoft 365 Chat (chat.microsoft.com)
• Copilot for Teams
• SharePoint
• Outlook Copilot
• Copilot Sidebar in Office apps

Users can start interacting with the agent through simple natural language prompts.

Step 5: Governance & Monitoring

Admins can use built-in dashboards to track:

• Usage analytics
• Errors
• Data accessed by the agent
• Audit logs
• Version updates

Value Proposition: Why the Agent Store Matters

1. Faster AI Adoption

Organizations no longer need to build agents from scratch. They can adopt ready-to-use, enterprise-tested agents instantly.

2. Standardization Across the Organization

Teams can use consistent, reliable AI agents across the entire Microsoft 365 ecosystem, reducing shadow IT.

3. High Security & Compliance

All agents run within Microsoft’s enterprise boundary:

• No external data leakage
• Respect for user permissions
• Full audit footprint
• Data residency compliance

4. Reduced Development & Maintenance Costs

Instead of custom development, businesses can reuse partner or Microsoft agents.

5. Extensibility with Copilot Studio

Organizations can customize:

• Behaviors
• Prompts
• Data access
• Workflows

A public agent can serve as a starting point, speeding up development.

6. Better User Experience

Employees get:

• Prebuilt, task-oriented agents
• Less friction
• Faster results
• Integration with daily apps (Teams, SharePoint, Outlook, Files, Planner)

Real-World Use Cases

1. SharePoint Governance Agent

• Identify large/storage-heavy sites
• Report on inactive content
• Recommend retention or archiving
• Audit permissions or external sharing

2. IT Support & Ticket Triage Agent

• Categorize and prioritize user-reported issues
• Suggest solutions
• Integrate with ServiceNow/Jira

3. Finance Automation Agent

• Summarize invoices
• Pull data from Excel financial models
• Extract insights for month-end reporting

4. HR Onboarding Agent

• Guide new employees
• Provide access links
• Explain policies
• Prepare personalized onboarding checklists

5. Sales Opportunity Agent

• Analyze CRM data
• Prepare account summaries
• Generate competitive insights
• Suggest next actions

6. Compliance Monitoring Agent

• Identify sensitive content
• Detect policy violations
• Propose remediation steps

Summary

The Microsoft 365 Agent Store, announced at Ignite 2025, is a major leap in Microsoft’s agentic-AI roadmap. It brings a curated marketplace of enterprise-ready agents directly into the Microsoft 365 ecosystem, enabling organizations to adopt AI rapidly, securely, and cost-effectively.

With strong integration across Teams, SharePoint, Outlook, and Microsoft 365 Chat - backed by governance, permission controls, and analytics - the Agent Store empowers businesses to standardize AI usage and speed up digital transformation.

This is not just a feature upgrade; it is the beginning of a new era where AI agents become as common and essential as apps in the enterprise.

References

• Microsoft Ignite 2025 - Book of News
• Microsoft 365 Roadmap
• Microsoft 365 Copilot and Agent Framework documentation
• Microsoft Technical Blogs (Ignite announcements)

At Ignite 2025, Microsoft made a significant push to advance what it calls the “agentic era” - where AI agents become first-class participants in workflows, not just assistants. The announcements reflect a shift from isolated AI features toward a full-stack infrastructure: agents, governance, intelligence layers, integration with productivity and content systems, and enterprise scale readiness. In summary: productivity tools (Copilot) get smarter, knowledge systems (SharePoint) get deeper context, and agent-management (Agent 365) gets enterprise control. This article explores each of these in turn: what’s new, the use cases, and what it means for organizations.

Microsoft Agent 365

What it is?

Agent 365 is introduced as a control plane for AI agents - a unified governance, management and monitoring platform. As Microsoft puts it, as agents proliferate into business workflows, IT and security leaders need ways to accelerate innovation without rebuilding entire infrastructure

Key capabilities include:

• A registry of all agents (agent ID, registered agents, “shadow” agents) so you can get visibility into what’s running.
• Access control: limiting what agents can access, applying risk-based conditional access policies.
• Visualization: mapping connections between agents, people and data; monitoring agent behavior in real time.
• Interoperability: agents can be connected to apps, data and workflows (including via the intelligence layer Work IQ) so they operate contextually.
• Security: built-in protection for agents, investigations, remediation of agent-targeted attacks, data-leak protection for what agents do.

Agent 365 is available now via the Frontier early access program (for Microsoft 365 admin centre).

Use Cases

• Enterprise-scale agent deployment governance: When you have dozens or hundreds of agents working across sales, HR, operations, you need a “single pane of glass” to see what’s active, what’s over-privileged, what is behaving unexpectedly. Agent 365 provides that.
• Shadow agent discovery: Many organizations will have ad-hoc agents built/added outside IT’s view. With a registry, you can detect ungoverned agents and bring them under policy.
• Risk-based access and behavior monitoring: For example, if an agent tries to access data it shouldn’t, or cross-boundary systems, Agent 365 can raise alerts or block.
• Operational monitoring of agent performance: Seeing which agents are being used, how effective they are, how they interact with people and data, and making decisions accordingly.
• Integration into existing productivity and security stack: Because it connects to Microsoft Defender, Microsoft Entra, Purview, Microsoft 365 apps, you don’t need a separate system from scratch.

What this means

For you (and organisations like yours, delivering Microsoft 365 and Copilot readiness), Agent 365 means you now have a structured path to deploy agents at scale, rather than treat them as isolated pilots. It also means governance and security are embedded, so you can reassure stakeholders that the AI-agent layer is manageable. For example, when guiding customers in adopting Copilot and agents, you can now reference Agent 365 as the enterprise readiness piece.

Microsoft 365 Copilot (and Agent-enhanced Office Apps)

What’s new

At Ignite 2025, Microsoft detailed a rich set of enhancements for Microsoft 365 Copilot, especially around Office apps, conversational/voice interaction, agent modes and content built from prompts. Some of the key announcements:

• Dedicated agents for Word, Excel and PowerPoint: Under Copilot, Word, Excel and PowerPoint will each have “agents” available through the Frontier program. For example:
  • The Excel Agent: transforms data into charts, summaries, insights (forecasts, project plans) via built-in formulas/logic.
  • The Word Agent: organizes complex information into clear, well-written documents (strategic plans, policies).
  • The PowerPoint Agent: builds presentations with storytelling, layout, visuals.
  • These agents integrate with Copilot Chat: you prompt in chat and they will ask follow-up questions, then hand off or transition into the native app.
• Agent Mode extended: Agent Mode (iterative co-creation / in-app AI collaboration) previously in Word & Excel is now expanded to PowerPoint. In PowerPoint, Agent Mode will update existing decks (using organization branding templates), create slides, rewrite/format text, insert/style tables, add images, rearrange content, pulling context from work data (files, meetings, emails) + web sources.

In Excel: Agent Mode on both web & desktop, integrated web search, external data import, choice between Anthropic and OpenAI models.

In Word: Agent Mode (now generally available for Copilot and Premium subscribers) uses Work IQ to auto-select relevant sources (files, emails, meetings) so documents reflect context.

• Outlook enhancements:
  • On mobile (iOS/Android) the Copilot in Outlook now offers interactive voice experience: summarises unread emails, guides users through replies, archiving, pinning etc. Early access via TestFlight/Google Play Beta.
  • One-tap prompts across Outlook (Windows, web, iOS, Android): “Triage my inbox”, “What needs my reply?”, “Summarize and reply”.
  • Scheduling: You can ask Copilot in chat to “schedule a meeting with colleagues” and Copilot will find available times, book rooms, draft agenda, send invites. This is generally available for Copilot license holders.
  • Conflict resolution: Copilot can detect scheduling conflicts for 1:1s/personal events, identify flexible meetings and automatically reschedule and notify users. Early access in Outlook (Windows, web) for targeted release tenants.
• Knowledge/Context enhancements via Work IQ:
  • Conversational memory: Copilot will retain context and specific details across sessions (work profile, custom instructions, saved preferences, previous chats) so responses become more tailored. Users have control: review, update or delete memories. Available via Frontier program.
  • Reasoning over structured metadata in SharePoint libraries (generally available): When a prompt is grounded in a SharePoint library containing structured metadata (e.g., vehicle spec sheets: make, model, engine size) Copilot can deliver more accurate, context-aware answers. Also handles images in PowerPoint, intranet site content, files encrypted with sensitivity labels.
• Copilot Pages and other creation tools:
  • Copilot Chat now can create “Pages” (interactive) based on user intent; it can write code directly onto a page, enabling interactive reports, visualisations, prototypes. Users then iterate via chat or page, share it, and convert into PowerPoint presentation. (Now generally available)
  • Video generation: Integration of OpenAI’s Sora 2 video model in Create experience of Copilot: generate short AI-generated video clips from natural language prompts or swap stock footage with AI-generated content. Includes voiceover, music, brand kits. Available to commercial users via Frontier.
• Licensing/Offerings:
  • Microsoft 365 Copilot Business: New offering for SMBs (<300 users). Automates routine tasks (summarising emails, drafting docs, analysing data, meeting notes). Price $21 per user/month. General availability December.

Use Cases

• Content creation and refinement: A Word Agent enables an employee to draft a complex document (e.g., policy, legal brief) by providing intent; follow-ups refine it; then the output flows into Word with the corporate style.
• Data-driven insight building: Excel Agent transforms raw data (e.g., sales pipeline) into charts, summary insights and visualisations without user having to manually craft formulas and visuals.
• Presentation generation: PowerPoint Agent takes a rough outline (e.g., “Q4 sales strategy”) and builds a branded deck with layout, visuals and narrative. User edits further.
• Email/meeting triage: On Outlook mobile, a sales rep can say “Hey Copilot - summarise what I missed yesterday”, triage inbox, flag things, schedule follow-ups, all via one-tap or voice.
• Knowledge-driven workflows: A user queries Copilot about “what are the specs of the new engine we are selling?” The system pulls from a SharePoint library (metadata-rich) and gives accurate contextual answer - thanks to the improved reasoning.
• Rapid page/list creation: A marketing user types in Copilot Chat: “@SharePoint list agent create a list of my top-selling products by geography”. A page is created without leaving chat.

What this means

For practitioners and trainers (like you) this brings several implications:

• When you deliver training on Microsoft 365 Copilot - emphasise that it’s not just a chat assistant, but now a suite of domain-specific agents built into core Office apps.
• Encourage organisations to prepare their data (metadata, structured libraries in SharePoint) so the new reasoning capabilities deliver value.
• For SMBs you now have a more affordable Copilot offering (Copilot Business) enabling broader reach.
• For change-management: voice interaction, one-tap prompts, cross-app agents shift how people work - training needs to emphasise behaviour and workflow changes.
• For readiness assessment (which you provide via your company), ensure you evaluate: data readiness (metadata, libraries, intranet), governance readiness (Agent 365), licensing/benefit readiness (which Copilot version fits).

SharePoint (and Knowledge/Content Platform Enhancements)

What’s new

While SharePoint has always been a core part of Microsoft 365, Ignite 2025 furthers its role in the “knowledge backbone” of AI and agents. Highlights include:

• Reasoning over structured metadata in SharePoint document libraries: This is now generally available. When a SharePoint library has metadata fields (e.g., vehicle make/model/engine size) Copilot can deliver more accurate responses grounded in that metadata.
• Integration of content types: images embedded in PowerPoint decks, intranet site page content, encrypted files (with sensitivity labels) are now better understood by Copilot.
• Page and list creation via Copilot Chat: Users (Frontier enterprise) can now create SharePoint pages or lists from prompts in chat without leaving workflow. Example: “@SharePoint list agent create a list of my top-selling products by geography”.
• SharePoint Admin Agent (preview): An AI-driven administration agent in the SharePoint admin centre. It monitors inactive or ownerless sites, overshared content, permissions sprawl, then applies policies or automated actions (archive, adjust access). Also provides visibility into sites with highest “agentic activity” (i.e., where Copilot/agents are used heavily) to proactively govern.
• Wider ecosystem integration: SharePoint is becoming more deeply connected with other apps (for example via the Model Context Protocol in Teams) so content stored in SharePoint becomes accessible to agents working in Teams, Copilot etc.

Use Cases

• Knowledge-hub readiness for Copilot: Your organisation has a SharePoint library for product spec sheets. With metadata, a user asks Copilot: “What is the engine size for product X?” The system responds accurately because metadata is present and understood.
• Rapid content generation: A marketing team uses Copilot Chat to create a campaign page in SharePoint (via natural-language prompt), then edits layout within SharePoint.
• Governance and Clean-Up: The SharePoint Admin Agent identifies 500 sites with no owner created two years ago, flags them, auto-archives or requests owners. Reduces cost and security risk.
• Cross-tool collaboration: A project in Teams has an agent, the agent queries SharePoint for “blockers in product launch” via list data stored in SharePoint, drafts mitigation plan and schedules meeting via Teams - all because SharePoint content is accessible intelligently.

What this means

For your context (SharePoint migration, Copilot readiness) the SharePoint enhancements are very relevant:

• When migrating to SharePoint Online, emphasise metadata modelling and structure - this becomes a key enabler for AI/agent use.
• For organisations adopting Copilot and agents, ensure the knowledge architecture (SharePoint, intranet, lists, libraries) is clean, structured, governed - not just file dumping.
• The governance side (via SharePoint Admin Agent) means that compliance, cost control and lifecycle management of SharePoint sites remain vital, and new AI tools can help - but pre-work is needed (site inventory, owner management, permissions hygiene).
• In training, highlight that users can now create pages/lists via chat - this changes how SharePoint is used (less heavy IT involvement for page/list creation). Change-management needs to reflect this shift.

AI Agents (General & Agent-Ecosystem Highlights)

What’s new

Beyond the specific product segments above, the Ignite Book of News lays out a broader set of announcements around agents:

• New agents launched:
  • Workforce Insights Agent: for real-time organisational view (roles, tenure, location, etc) to support leader decisions.
  • People Agent: helps users find colleagues by role/function/skill, suggests connections.
  • Learning Agent: delivers personalised micro-learning, curated courses, role-AI skills aligned to team goals.
• Agents in Teams channels can now work with third-party apps and other agents via the Model Context Protocol (MCP) servers (preview): E.g., within a Teams channel a user asks the agent “what are the blockers for our product launch?”, and the agent pulls from Jira (via MCP server) and schedules a meeting.
• Admin agents: Teams Admin Agent (preview) in Teams admin centre - automates / executes workflows like meeting monitoring, user provisioning, policy enforcement.
• Lifecycle & identity enhancements: In the Copilot Studio / agent-building domain we see features such as:
  • Entra Agent ID: every agent gets a unique ID for governance/identity.
  • Agent evaluations: automated testing of agents, comparing versions, monitoring regressions.
  • Computer use in Copilot Studio: agents can work with apps/websites via virtual machines (secure), enabling automation across large swathes of UI.
• Integration with Microsoft 365 ecosystem: Agents are not standalone-they pull from productivity apps, knowledge systems (SharePoint), business apps (Power Platform) and are managed via Agent 365 etc.
• Pricing/licensing implications: While many of these agent capabilities are in early access (Frontier program), the structure is now in place for production-scale agents.

Use Cases

• HR and workforce management: A Workforce Insights Agent surfaces that a key role in a location has high turnover and low tenure, prompting proactive HR action.
• Learning & upskilling: Learning Agent suggests micro-learning modules to a sales rep whose CRM data shows a pattern of missed follow-ups.
• Cross-tool automation: In a product launch channel in Teams, the channel agent grabs tasks and risks from Jira, communicates with the user in Teams, schedules room/meeting in Outlook, all via one query.
• IT admin automation: The Teams Admin Agent automatically monitors meeting usage, enforces policy (e.g., guest access) and triggers user provisioning workflows without manual steps.
• Content governance: The SharePoint Admin Agent (under the agent umbrella) identifies stale/ownerless sites and automates cleanup.
• Multi-agent orchestration (emerging): Agents that collaborate with other agents (via MCP) to complete a workflow (e.g., Sales Development Agent researches leads, then hands off to human, then Learning Agent triggers training). Indeed, Microsoft mentions a “Sales Development Agent” in preview via the Frontier program - an autonomous agent that researches, qualifies and engages leads, then hands off to human sellers.

What this means

• The concept of “agent sprawl” (hundreds of low-code/no-code agents built loosely) is now recognised and addressed. Organisations must plan agent governance from day one.
• For those preparing customers (via your training/consulting), emphasise that having agents is no longer just a pilot: the architecture for production, identity, governance, monitoring is in place.
• Encourage the mindset shift: an agent is now a “digital employee” that needs identity, performance measurement, lifecycle management just like a human employee.
• Data readiness, knowledge architecture, app connectivity become prerequisites for agent success-not just model performance.
• The ecosystem is expanding rapidly: from productivity agents (Copilot) to business-process agents (Power Platform/Apps) to workforce/learning/HR agents. Viewing agents holistically will help prepare organisations for scale rather than point solutions.

Summary

At Microsoft Ignite 2025 the announcements reinforce that we are entering the next phase of AI in the enterprise - the agentic era. The key takeaway across the four focus areas is integration + governance + context.

• Microsoft Agent 365 gives organisations the infrastructure to manage, monitor and govern agents at scale.
• Microsoft 365 Copilot evolves into specialised agents in Word/Excel/PowerPoint, enriches productivity with voice, conversational memory and contextual reasoning, and extends into video/presentation/creation workflows.
• SharePoint is elevated from “file storage/intranet” to a knowledge and metadata-rich platform that feeds agents and supports rapid content/list creation and governance automation.
• AI Agents (general ecosystem) are now pervasive: covering sales, workforce, learning, IT operations, cross-tool integrations, multi-agent orchestration, and are governed, identified, measured.

For you (in your role delivering training, consulting and readiness assessments), the implications are:

• Emphasise readiness across three dimensions: people (skills and mindset), process (governance, workflows) and technology (data, architecture, platform).
• When assessing organisations: check data architecture (SharePoint metadata, knowledge libraries), agent governance readiness (Agent 365, identity, access controls), productivity adoption readiness (Copilot agents, voice/agent mode), and agent ecosystem readiness (connectivity, model/context layers).
• In your training materials: highlight the shift from isolated AI features to agent-enabled workflows and the need for change management, adoption strategies, and governance frameworks.
• Encourage step-wise adoption: start with pilot agents tied to high-impact workflows (e.g., sales follow-up, HR learning), use Agent 365 and share insights, then scale.
• For SharePoint migrations (which you often work with), add a layer: ensure metadata modelling and library/ site governance are part of the migration plan-because that enables richer Copilot/agent use downstream.

References

• “Book of News” - Microsoft Ignite 2025: Announcements on Agent 365, Copilot, SharePoint.

Microsoft has released SharePoint Framework (SPFx) 1.22, marking a significant modernization milestone for SharePoint and Microsoft 365 developers. This release introduces a new build and toolchain system that transitions from Gulp to a Webpack-based toolchain orchestrated by Heft, part of Microsoft’s RushStack ecosystem. This change aims to improve build performance, maintainability, and consistency with other Microsoft developer platforms such as Teams, Office Add-ins, and Viva Connections.

From Gulp to Heft: What Changed

Earlier Approach: Gulp-based Toolchain

In prior versions, SPFx relied heavily on Gulp for build orchestration. Developers managed tasks like:

• Compiling TypeScript
• Bundling with Webpack
• Packaging and serving the solution
• Running unit tests

Although powerful, this Gulp-based setup had limitations:

• Complex and manual task customization
• Dependency on older JavaScript build tools
• Difficult maintenance in large projects
• Slow build performance over time

New Approach: Heft-based Toolchain

SPFx 1.22 introduces a new, modern toolchain built on Heft - a flexible build orchestrator developed by Microsoft and part of the RushStack suite.

Heft coordinates the build using standardized configurations for Webpack, TypeScript, and other tools.

Key Components

• Heft - replaces Gulp as the main task runner
• Webpack 5 - modern bundler offering better optimization
• RushStack Libraries - provide a consistent foundation used across Microsoft projects
• Enhanced TypeScript Support - cleaner configuration and faster compilation

Benefits of the New Toolchain

How Developers Can Prepare for This Transition?

Transitioning from Gulp to Heft requires some adaptation in the way SPFx developers handle builds and configuration.
Here’s how to prepare effectively:

1. Understand the RushStack Ecosystem

Spend time learning the RushStack ecosystem:

• Heft Overview
• Rush for Monorepos
• Rig Packages and Plugin Architecture

These concepts form the foundation of the new SPFx build process.

2. Update Node.js and NPM

Ensure your environment uses compatible versions:

• Node.js 18.x or later
• NPM 9.x or later

Older versions may cause dependency or script compatibility issues.

3. Review Custom Gulp Tasks

If your solution uses custom Gulp tasks (e.g., for file copying or code generation), you’ll need to:

• Identify each custom task.
• Determine if there’s an equivalent Heft plugin or hook.
• Move logic into a Heft-compatible plugin or event hook.

4. Learn Webpack 5 Enhancements

Heft uses Webpack 5, so understanding key Webpack concepts like module federation, asset modules, and configuration overrides will help optimize your builds.

5. Explore Heft Config Files

Heft relies on configuration files like heft.json and tsconfig.json to define tasks. Learn their structure and how they replace legacy Gulp settings.

Guidelines for Upgrading Existing Projects

Here are practical steps to migrate your SPFx solutions from older versions to the new Heft-based toolchain:

• Backup your project - always keep a working copy of your Gulp-based solution.
• Upgrade SPFx version using:
• npm install @microsoft/sp-build-web@1.22
• Run project upgrade command:
• gulp upgrade

(Note: this command will update configurations, but may not fully remove Gulp dependencies.)

• Review the new project structure:
  • Verify the presence of config/heft.json and related RushStack files.
  • Check for deprecations in gulpfile.js (many will now be unused).
• Clean up obsolete Gulp references:
  • Remove unnecessary gulp-* packages.
  • Update build scripts in package.json to use Heft commands.
• Test builds:
  • npm run build
  • npm run serve
  • npm run package-solution
• Resolve compatibility issues:
  • Update third-party libraries (especially React, TypeScript).
  • Check for breaking changes in your custom tasks.

Learning Curve and Developer Readiness

While the transition introduces modern practices, developers may face a learning curve, especially if they have relied on Gulp for years.

Here is what to expect:

Overall, developers familiar with modern JavaScript toolchains (like Webpack or Vite) will find the transition smoother. For others, short learning sessions and experimentation will help adapt quickly.

Use Cases

• Enterprise SPFx Solutions - Faster builds and better modularization in large-scale environments.
• Teams and Viva Integrations - Shared toolchain consistency between Microsoft 365 workloads.
• DevOps Automation - Easier integration into CI/CD systems with standardized Heft commands.

Summary

SPFx 1.22 introduces a modernized, Heft-based toolchain that replaces legacy Gulp tasks, streamlining development with improved performance, maintainability, and extensibility.
While the transition requires developers to adapt to new tools like Heft and Webpack 5, it sets a strong foundation for the future of SPFx and Microsoft 365 development.

By preparing early, reviewing existing projects, and embracing modern JavaScript practices, developers can make this transition smooth and take full advantage of what SPFx 1.22 offers.

References

• SPFx 1.22 Release Notes - Microsoft Learn
• SPFx Toolchain: Transitioning to Heft - Microsoft Learn
• RushStack Official Site
• Heft Overview

The Microsoft Agent Framework is a developer toolkit that allows you to build, orchestrate, and run intelligent agents that can think, reason, and take actions. These agents can perform specific tasks, call APIs, or integrate with real-world systems.

In this article, we’ll learn how to run your first agent using Microsoft’s Agent Framework - both in Python and C#. Instead of simply greeting users, our sample agents will help users track daily tasks in a simple and interactive way.

Understanding the Microsoft Agent Framework

At its core, the Agent Framework enables developers to:

• Create autonomous agents that use AI reasoning.
• Integrate with custom tools (functions, APIs, data sources).
• Run locally or in the cloud using simple commands.
• Extend agents with plugins or external connectors.

The agent runtime handles the conversation loop — interpreting user input, reasoning about it, and taking the right actions (like calling a function or returning a message).

Example 1: Running an Agent in Python

Step 1: Prerequisites

Ensure you have:

• Python 3.10+

• agentframework library installed via pip:

    pip install agentframework
  

Step 2: Create the Agent File

Let’s create a Python agent called task_agent.py:

from agentframework import Agent

# Define the agent
agent = Agent(
    name="task-agent",
    instructions="You are a helpful assistant that helps users manage their daily tasks."
)

# Define a custom tool
@agent.tool
def add_task(task_name: str, priority: str = "normal"):
    """Add a new task with an optional priority."""
    return f"✅ Task '{task_name}' added successfully with {priority} priority."

# Run the agent
if __name__ == "__main__":
    agent.run()

Step 3: Run the Agent

In the terminal, execute:

python -m agentframework run task_agent.py

You will enter an interactive shell where you can talk to the agent.

Example conversation:

> Add a task to review the AI presentation with high priority
✅ Task 'review the AI presentation' added successfully with high priority.

Example 2: Running an Agent in C#

Step 1: Setup Project

Create a new .NET console project:

dotnet new console -n TaskAgentApp
cd TaskAgentApp
dotnet add package Microsoft.AgentFramework

Step 2: Create the Agent Class

In Program.cs, define and run your agent:

using Microsoft.AgentFramework;

class Program
{
    static void Main()
    {
        var agent = new Agent(
            name: "task-agent",
            instructions: "You are an intelligent assistant that helps users plan their daily schedule."
        );

        // Define a simple tool
        agent.AddTool("create_task", (parameters) =>
        {
            string title = parameters["title"].ToString();
            string time = parameters.ContainsKey("time") ? parameters["time"].ToString() : "unspecified time";
            return $"🗓️ Task '{title}' scheduled for {time}.";
        });

        // Run the agent
        agent.Run();
    }
}

Step 3: Run the Application

Run the following command:

dotnet run

Sample interaction:

> Create a task to call the client at 3 PM
🗓️ Task 'call the client' scheduled for 3 PM.

Use Cases

The Microsoft Agent Framework can be extended to fit various business and productivity needs:

Summary

In this article, we explored how to run your first Microsoft Agent Framework agent using both Python and C#.

We created simple task management agents that respond to user commands using natural language. The framework abstracts the complexity of reasoning and orchestration, allowing developers to focus on defining tools and business logic.

References

• Microsoft Agent Framework Documentation
• Tutorial: Run Your First Agent
• Microsoft Agent Framework Agent Types
• Microsoft Agent Framework - GitHub Repository

Microsoft has taken another major step in its AI journey with the introduction of the Microsoft Agent Framework. Announced in October 2025, this open-source initiative provides a unified foundation for creating, running, and managing intelligent agents.

It combines the power of Azure AI, Microsoft Graph, and Copilot extensibility to enable developers to build agentic systems that are context-aware, secure, and enterprise-ready.

The framework is open-sourced on GitHub, making it accessible to developers and enterprises who want to create their own Copilots, workflow agents, or domain-specific AI solutions.

What is Microsoft Agent Framework?

The Microsoft Agent Framework is a software development framework that simplifies the creation of intelligent agents - software entities that can reason, act, and collaborate autonomously or in coordination with humans and other agents.

At its core, it provides:

• A runtime environment for executing agent logic
• A standardized API surface for communication and context exchange
• Integration with LLMs, memory stores, and tool connectors
• Alignment with the Model Context Protocol (MCP) for interoperability

Agents built using this framework can interact with users, call APIs, access enterprise data, and trigger automated actions - forming the foundation for Copilots and agentic ecosystems inside and outside Microsoft 365.

Key Components

How It Works – Example

Let’s consider an HR Assistant Agent built using the Agent Framework.

1. User query:
   “Find all employees whose contracts are expiring this month and send reminders.”

2. Agent Framework actions:
   • The Language Model interprets intent and context.
   • The Agent Runtime identifies that this requires data retrieval and email sending.
   • The agent uses connectors to:
     • Query Microsoft Graph for employee data.
     • Compose and send reminders using Outlook APIs.
   • The Memory System records that reminders were sent and to whom.
3. Response:
   The agent reports back to the user with confirmation.

This flow demonstrates how the framework manages reasoning, action, and communication seamlessly.

Integrations and Ecosystem Alignment

The Agent Framework fits into Microsoft’s broader AI and Copilot ecosystem:

• Azure AI Foundry: Build, test, and deploy agents integrated with AI services, search, and vector stores.
• Semantic Kernel: Embed reasoning, planning, and skill execution logic using SK plugins.
• Microsoft 365 and Graph: Enable enterprise-aware agents that work securely with organizational data.
• Copilot Extensions: Extend Microsoft Copilot experiences (e.g., Teams, Outlook, or SharePoint) using custom agents built with this framework.

This ensures that the same agentic foundation powers Copilot, Declarative Agents, SharePoint Knowledge Agents, and third-party custom agents.

Example: Multi-Agent Collaboration

Imagine a company using three agents:

• Procurement Agent: Handles purchase approvals.
• Finance Agent: Monitors budgets.
• Compliance Agent: Checks policy adherence.

When a manager requests “Approve the laptop purchase request,”

1. The Procurement Agent analyzes the request.
2. It calls the Finance Agent to verify available budget.
3. The Compliance Agent validates policy compliance.
4. After all checks pass, the Procurement Agent executes the approval automatically.

This multi-agent orchestration demonstrates how complex, cross-departmental workflows can be handled without human intervention - with every step traceable and explainable.

Benefits

• Open Source and Extensible: Available on GitHub for developers to extend and contribute.
• Standardized Architecture: Promotes interoperability across Copilot, Semantic Kernel, and Azure AI.
• Enterprise-Ready Security: Inherits Microsoft’s compliance and authentication models.
• Faster Development: Reusable templates and connectors accelerate agent creation.
• Scalable Orchestration: Supports multi-agent environments and distributed workloads.

Getting Started

Clone the repository:

git clone https://github.com/microsoft/agent-framework
cd agent-framework
npm install

Create a new agent using a template:

npx agent create hr-assistant

Define the configuration (example YAML):

name: HR Assistant
description: Helps HR team manage employee records
tools:
  - graph: employees.read
  - outlook: mail.send
memory:
  persistent: true
model: gpt-4o

Run the agent locally or deploy it to Azure:

npx agent run hr-assistant

Business Use Cases

Summary

The Microsoft Agent Framework marks a major evolution in the AI ecosystem — moving from isolated chatbots to collaborative, context-aware agents. By combining the strengths of Azure AI, Semantic Kernel, and Copilot, Microsoft enables organizations to build secure, intelligent, and extensible agents that transform how work gets done.

This framework empowers every developer and enterprise to participate in the next generation of agentic computing — where intelligent systems reason, act, and learn alongside humans.

References

• GitHub Repository – Microsoft Agent Framework
• Microsoft Learn – Agent Framework Overview
• Official Announcement – Microsoft Blog

Disclaimer

Created with human expertise and GenAI support. This article has been enhanced and elaborated with the support of Generative AI.