Capability Model

Every AI conversation starts in the wrong place.

Someone walks into the room and says, “We need an agent.” Or worse: “We need to use Foundry.” They’ve jumped to a platform before they’ve named the outcome, described the user, or asked whether AI is even the right tool. This is how projects fail — not from bad technology, but from skipping the thinking that should come before the technology.

This page teaches that thinking. Not a decision tree — those come later. This is the mental framework that makes decision trees useful. Learn it once, and it survives every product rename, every Build keynote, every “everything is an agent now” news cycle.

The flow is always the same: Outcomes → Behaviors → Platforms. Who benefits and how? What does the AI actually do? Only then: which building blocks support that behavior?

How to use this page:

  1. Start with outcomes — name who benefits and how (The 3 AI Buckets).
  2. Pass the checkpoint — verify AI is even the right tool.
  3. Define behavior — describe what the agent does before you name a product (The Coin & 5 Dimensions).
  4. Map to building blocks — match behaviors to Capability Groupings and the Three IQ Layers.
  5. Choose your build path — pick the right layer of the New Full Stack.

For a detailed intake workflow, see Decision Framework.

Table of contents

  1. The 3 AI Buckets
    1. The “AI Podcast” Problem
  2. Checkpoint: Do You Even Need an Agent?
    1. The Right Tool for the Step: Deterministic Code Is Not the Expensive Option Anymore
  3. The Agent Framework
    1. What is an agent?
    2. Two Sides of the Spectrum (The Coin)
    3. How to Choose Your Agent: The 5 Dimensions
  4. Capability Groupings (Building Blocks)
    1. 1. End‑user copilots (ready‑made UI)
    2. 2. Extensibility into existing copilots
    3. 3. Build AI apps and agents (hybrid by default)
    4. 4. AI services and building blocks
    5. 5. Specialized agents (don’t rebuild what already exists)
    6. The Three IQ Layers (How Agents Understand Your Organization)
  5. The New Full Stack
    1. Three Layers, One Architecture
    2. The “Better Together” Architecture
    3. Why the Economics Now Match the Architecture
  6. Sources

The 3 AI Buckets

Start by naming who benefits and how. This keeps early conversations grounded in outcomes before you debate platforms.

Bucket What It Is Key Distinction
Copilot for Everyone AI as personal assistant Helps people do their work and life tasks.
AI as Product/Capability AI is the value delivered to end users Standalone agents, embedded features, or LLM‑powered integrations where users consume AI outcomes.
Agentic Coding Autonomous technical builder AI builds software or systems; the output may or may not contain AI features.

The “AI Podcast” Problem

Why do we need these buckets? Imagine searching for “AI” in a podcast app. The results are a chaotic flood because they mix three different intents:

  • The “Life Hack” Listener: Wants to know how to use Copilot and ChatGPT for parenting advice or “10 tips to organize my day.” (Bucket 1: Personal Productivity)
  • The AI Architect: Wants to know how to orchestrate multi-agent systems to ship a new feature to their customers. (Bucket 2: Shipping Value)
  • The Developer: Wants to know how to use an autonomous coding agent to refactor legacy code in the background. (Bucket 3: Agentic Coding)

If you don’t separate these channels, you risk applying “life hack” advice to enterprise architecture. Three AI buckets, three different conversations.

Checkpoint: Do You Even Need an Agent?

Not every AI problem needs an agent. Microsoft’s AI agent guidance explicitly calls out cases where agents add unnecessary cost, latency, and risk.

  • Structured and predictable tasks: Use deterministic code or non‑generative AI when the workflow is rule‑based and predictable.
  • Static knowledge retrieval: Use classic RAG for single‑turn question answering or summarization from a fixed index. If there’s no tool execution or multi‑step reasoning, an agent is overkill.

See When not to use AI agents.

The Right Tool for the Step: Deterministic Code Is Not the Expensive Option Anymore

Even inside an agent architecture, not every step deserves an LLM call. State machines, rule engines, and well‑written if/else code give you what language models fundamentally lack: predictability, observability, and recoverability.

There is a common misconception that deterministic code is the “expensive” path: that writing and maintaining code costs more than letting an agent figure it out at runtime. That argument had more weight before agentic coding tools (GitHub Copilot, coding agents) collapsed the cost of writing deterministic logic. Today, an AI can write the state machine for you in minutes. The code it produces runs faster, costs less per execution, and fails in ways you can actually debug. The agent call it replaces runs slower, costs more per invocation, and fails in ways that require prompt archaeology.

The anti-pattern: Reaching for agentic orchestration to avoid writing code. Don’t use nondeterminism as a shortcut when the logic is known. Every LLM call introduces latency, token cost, and unpredictable behavior. Reserve that budget for steps where reasoning, ambiguity, or natural‑language understanding genuinely adds value.

The best architectures mix and match. Let agents handle the thinking: intent recognition, multi-step planning, ambiguity resolution. Let deterministic code handle the doing: validation, routing, transformation, and anything with a known correct answer. The two aren’t rivals; they’re teammates with different job descriptions.

The Agent Framework

If you have determined you need an agent, use this framework to describe what kind of AI capability you’re building, before you name a product.

What is an agent?

In Microsoft guidance, agents can handle tasks, take actions, and operate in conversation or via triggers. They can be assistive or autonomous depending on how you design them. See Copilot Studio overview.

Two Sides of the Spectrum (The Coin)

When thinking about agents, consider two ends of a spectrum.

Side A: Interactive Agents (The Face) These are the agents we look at. We poke them, and they poke back. They are conversational, visual, and present. (Examples: Copilot, ChatGPT, GitHub Copilot).

Side B: Invisible Agents (The Force) Flip the coin. These are the agents that look at the world for us. They live in the background, monitoring data, waiting for triggers, and acting without us needing to be present.

How to Choose Your Agent: The 5 Dimensions

Once you know which side of the coin you’re on, you have to decide how that agent behaves.

1. Interface: The Conversation vs. The Trigger (UI vs. No-UI) This defines how the engagement begins. Interactive Agents rely on Conversational UI: you talk, and it answers. Invisible Agents rely on Triggers: a new email arrives, a database updates, or a timer goes off. One is designed for human engagement; the other is designed for seamless system integration.

2. Relationship: The Copilot vs. The Captain (Assistive vs. Autonomous) This defines who holds the steering wheel. Assistive agents work with you: they wait for your input to move forward, keeping a human in the loop. Autonomous agents work for you: once you give them the goal, they drive themselves, making decisions and executing tasks until the job is done or they hit a guardrail. The line is blurring — Copilot Cowork (Frontier Preview) lets M365 Copilot take the wheel for minutes or hours while you steer at checkpoints, occupying a middle ground between Copilot and Captain.

3. Logic: The Recipe vs. The Chef (Deterministic vs. Non-Deterministic) This defines how the agent thinks. Deterministic flows are like a recipe: “If X happens, do Y.” They are rigid, predictable, and 100% accurate, which is perfect for strict compliance tasks. Non-Deterministic agents use reasoning. You give them a goal (“Plan a travel itinerary”), and they figure out the necessary steps themselves, adding intelligence and adaptability to the process.

4. Structure: The Soloist vs. The Orchestra (Single-Agent vs. Multi-Agent) This defines the scope of capability. A Single Agent is a generalist; it tries to handle the query alone. Multi-Agent systems function like a department of specialists. One agent might be the “Researcher,” another the “Writer,” and another the “Editor,” passing the work between them to solve complex problems that a single model couldn’t handle effectively.

5. Collaboration: The Handoff (Agent-to-Agent Workflow) This defines how the team plays together. The true power of AI isn’t just in isolated agents, but in Orchestration. In an advanced workflow, an Invisible Agent (Side B) might detect a server crash and immediately wake up an Interactive Agent (Side A) to alert the engineer, handing off all the context instantly. It connects the two sides of the coin into a single, fluid operation.

Capability Groupings (Building Blocks)

Now that you have defined the behavior, map it to the right building block. These five groupings are not a maturity ladder; they are components you can mix and match.

1. End‑user copilots (ready‑made UI)

The capability is the experience surface itself (chat, in‑app assistants, agent menus).

2. Extensibility into existing copilots

If your users already live in Microsoft apps, extend what they already use.

  • Plugins: Surface your data and actions inside Microsoft Copilots.
  • Graph connectors: Bring external content into the Microsoft 365 ecosystem so Copilot can reason over it. See ISV extensibility story.

3. Build AI apps and agents (hybrid by default)

This grouping is for custom experiences. Your app may be 95% deterministic and still include a meaningful AI feature.

  • Agent flows and workflows: Support mixing deterministic steps with AI reasoning (e.g., Copilot Studio agent flows, Foundry multi‑agent workflows).

4. AI services and building blocks

This grouping sits beneath apps: models, tools, retrieval, evaluations, and governance. Microsoft Foundry unifies agents, models, and tools with enterprise‑grade management. See Microsoft Foundry overview.

5. Specialized agents (don’t rebuild what already exists)

Microsoft and partners ship specialized agents for specific domains.

  • Microsoft 365 Copilot agents: Integrated into the Microsoft 365 Copilot experience.
  • Azure SRE Agent (Preview): Operational automation for Azure environments. Azure SRE Agent overview
  • GitHub Copilot agent mode & coding agent: Autonomous coding tasks. GitHub Copilot agents in VS Code

The Three IQ Layers (How Agents Understand Your Organization)

The Concept: An agent that can only search documents sees the organization through a keyhole. It finds what was written down, but it doesn’t know what happened in last week’s meeting, who owns the decision, or what the sales data says about the outcome. Real organizational intelligence requires three layers: knowing what was recorded, understanding what’s happening, and interpreting what it all means.

The Analogy: Memory, Awareness, and Understanding.

Think about how a seasoned leader navigates a complex decision. They draw on three distinct kinds of organizational intelligence:

  • Memory is what the organization has written down. Policies, contracts, specifications, reports, research. It’s the accumulated knowledge base. You can search it, cite it, and trust it because it’s governed. But memory alone is static. It tells you what the answer was, not what the situation is.

  • Awareness is the live pulse of work. Who said what in which meeting. What the team agreed to in a Teams thread. What’s on the calendar for next week. What the ServiceNow ticket says about the outage, what the SAP system shows for the purchase order, what the JIRA board reveals about sprint velocity. Awareness isn’t just M365 signals; it extends through 1,500+ connectors into ServiceNow, SAP, Salesforce, Azure DevOps, Dynamics 365, and any system with a REST API. This is the layer that turns fragments of data into the full context of work.

  • Understanding is the business logic that gives data meaning. “Customer” isn’t just a row in a table. It has relationships (places Orders, belongs to a Segment, has a Lifetime Value), rules (if inventory drops below threshold, trigger replenishment), and a semantic structure that’s consistent across every dashboard, agent, and report. Understanding lets agents reason about the business itself, not just the files or conversations about it.

Most teams start their agent journey with Memory (connect a knowledge base) and stop there. The agents that deliver breakthrough value are the ones that also have Awareness (they understand how work happens) and Understanding (they reason in the language of the business).

The Product Anchors:

  • Foundry IQ (Preview) is the Memory layer. Managed knowledge bases built on Azure AI Search agentic retrieval, connected to agents via MCP. Auto-chunking, vector embedding, permission-aware retrieval with ACL sync and Purview sensitivity label enforcement. Citation-backed responses grounded in enterprise documents, SharePoint, OneLake, Azure Blob, and web sources.

  • Work IQ (Preview) is the Awareness layer, and it’s the same intelligence layer that powers Microsoft 365 Copilot. When you connect an agent to Work IQ, you give it the same contextual brain Copilot uses. Built-in MCP servers cover Mail, Calendar, Teams, SharePoint, OneDrive, User profiles, Word, and Dataverse/Dynamics 365 (Sales, Finance, Supply Chain, Service, ERP, Contact Center). The MCP Management Server opens the ecosystem to custom MCP servers built on 1,500+ connectors (ServiceNow, SAP, JIRA, Azure DevOps, Salesforce) and any REST API. Dataverse intelligence extends Work IQ into structured business data understanding. Governed via the M365 Admin Center with Microsoft Defender observability. Requires M365 Copilot license.

  • Fabric IQ (Preview) is the Understanding layer. A semantic intelligence workload in Microsoft Fabric that defines the language of your business through ontologies (entity types, relationships, properties, business rules), graph models for cross-domain reasoning and dependency analysis, Power BI semantic models for trusted KPIs, and operations agents that can trigger governed actions when business conditions are met. Fabric IQ ensures that every agent, dashboard, and application speaks the same business vocabulary.

Each IQ layer is standalone, but agents that combine two or three of them answer questions that no single layer can: “What does the policy say (Memory), who agreed to change it last quarter (Awareness), and what does the usage data show since the change (Understanding)?”

The New Full Stack

The low-code vs. pro-code war is over. Here’s what killed it.

For years, the industry drew a bright line: “low-code is for citizen developers” on one side, “pro-code is for real engineers” on the other. The line made sense when code was expensive. Writing a state machine, wiring up auth flows, managing deployment pipelines — these tasks demanded specialized skills and weeks of calendar time. Low-code existed as a category because the alternative cost too much.

That economics has collapsed. Agentic coding tools — GitHub Copilot, coding agents, AI-assisted development — have made writing deterministic logic fast and cheap. A coding agent can scaffold a validated state machine in minutes. The cost argument that justified the binary no longer holds. And on the other side, tools like Copilot Studio now offer code views, variable management, and API integrations that demand an engineering mindset to wield effectively. The “low-code” canvas has become an IDE for conversational AI.

The New Rule: Choose the tool based on the problem, not your job title. A Principal Architect should use Copilot Studio if it solves the problem 10× faster. A Business Analyst working in Foundry isn’t out of their depth — they’re using the right tool for their use case. The tool does not define the role. The problem defines the tool.

Three Layers, One Architecture

Do not think of this as “Copilot Studio vs. Microsoft Foundry.” Think of it as a spectrum of control — three layers that most enterprise architectures use together. This is an “AND” conversation, not an “OR” decision.

1. The SaaS Layer (Microsoft 365 Copilot)

  • Focus: Consumption & Configuration.
  • The Role: This is your “Frontend.” It provides the chat interface, the security perimeter, and the integration into Word, Teams, and Excel.
  • The Build: You don’t build the engine; you tune it. You configure Graph Connectors to feed it data and manage plugins to give it skills.

2. The Orchestration Layer (Copilot Studio)

  • Focus: Extension & Logic.
  • The Role: This is your “Middleware.” Whether you are a developer or a maker, this is where you define behavior.
  • The Build: Developers use this to stitch together APIs, manage conversation state, and build complex agent workflows. It serves as the bridge, taking raw models and turning them into structured business processes that can be published to M365.

3. The Foundation Layer (Microsoft Foundry)

  • Focus: Deep Customization & Model Ops.
  • The Role: This is your “Engine Room.” This is for when the out-of-the-box models aren’t enough.
  • The Build: Here, you fine-tune models, manage vector stores, and evaluate prompt performance. It is deeply technical, but its output (a custom model or agent) is often consumed by the Orchestration Layer.

The “Better Together” Architecture

A robust AI solution often spans all three:

  1. Foundry hosts a custom-tuned model for analyzing proprietary engineering specs.
  2. Copilot Studio consumes that model, adds a “Human Handoff” logic flow, and enforces access controls.
  3. Microsoft 365 Copilot acts as the user interface, allowing an engineer in Teams to query the specs without leaving their chat.

Why the Economics Now Match the Architecture

Historically, the “AND” conversation stalled at procurement: separate billing for Copilot Studio and Foundry forced teams into premature “OR” decisions driven by budget silos rather than architecture fit. The Microsoft Agent Pre-Purchase Plan (P3) removes that friction. Organizations purchase Agent Commit Units (ACUs) in a single pool that pays down both Copilot Credit and Microsoft Foundry usage. One contract, one meter, flexible allocation across layers. This is Microsoft financially codifying the “Better Together” architecture: build in Foundry, orchestrate in Studio, deploy to M365, and let a unified budget follow the workload. See Agent Pre-Purchase Plan.

Next: Decision Framework - Apply BXT and critical questions to shortlist technologies

The Human Side: Technology choices are only half the equation. How your team partners with AI matters just as much as which platform they use. See AI Instinct: The Human Framework for the four instincts that make AI partnership as natural as breathing.

Sources

Back to top

Copyright © 2025. This documentation is based on official Microsoft sources and best practices.

This site uses Just the Docs, a documentation theme for Jekyll.