Tuesday, July 21, 2026

Integrating SAP Joule with Microsoft 365 Copilot: A Step-by-Step Guide with Challenges and Lessons Learned

Introduction

Enterprise users often move between SAP applications, Microsoft Teams, Outlook, and other Microsoft 365 services to complete a single business process. The integration of SAP Joule with Microsoft 365 Copilot helps reduce this context switching by providing a conversational experience across the SAP and Microsoft ecosystems.

With the integration enabled, users can access supported SAP capabilities from Microsoft 365 Copilot or Teams. In the opposite direction, users working with Joule can use supported Microsoft 365 context, such as emails, calendar information, and Teams conversations. Microsoft describes this as a managed, bidirectional integration that does not require an organization to build a custom Copilot agent.

We recently worked through this integration and found that the technical steps are only one part of the journey. Identity mapping, tenant design, consent, user provisioning, system propagation, and ownership across SAP and Microsoft teams all require careful planning.

This article presents a structured implementation approach, the most important validation steps, and the challenges administrators should anticipate.

Important: Product behavior, supported scenarios, permissions, and setup procedures can change. Always validate the current requirements against the official SAP and Microsoft documentation before implementing changes in a production environment.

What Does the Integration Provide?

The integration supports two main interaction directions.

Microsoft 365 Copilot to SAP Joule

A user working in Microsoft 365 Copilot or Microsoft Teams can ask an SAP-related question. The request is routed to Joule, which processes the question using the SAP applications and capabilities available to that user.

Example:

@Joule Show me my remaining leave balance.

Depending on the configured SAP solution and enabled Joule capabilities, this request could retrieve information from SAP SuccessFactors.

SAP Joule to Microsoft 365

A user working in Joule can request supported Microsoft 365 information.

Example:

Find emails from customers concerning delayed payments.

Microsoft’s documentation identifies HR, procurement, finance, sales, and supply-chain scenarios as representative use cases. Supported experiences depend on the SAP products connected to Joule and the standard capabilities currently available from SAP and Microsoft.

The Microsoft AppSource listing explains that the SAP Joule app can provide transactional, navigational, and informational capabilities. The capabilities actually available to a user depend on the connected SAP solution, Joule configuration, licensing, and role-based authorization.

High-Level Architecture

The integration involves the following primary components:

Microsoft Entra ID
SAP Cloud Identity Services, Identity Authentication
SAP Business Technology Platform
SAP Joule
Microsoft 365 Copilot
Microsoft Teams, where applicable
SAP applications connected to Joule

The identity foundation is an OpenID Connect trust relationship between Microsoft Entra ID and SAP Cloud Identity Services. SAP processes the SAP-specific business request, while Microsoft provides the Copilot and Teams user experience.

A simplified request flow looks like this:

User
  |
  v
Microsoft 365 Copilot or Teams
  |
  v
Microsoft Entra ID authentication
  |
  v
SAP Cloud Identity Services trust and user mapping
  |
  v
SAP Joule
  |
  v
Connected SAP business application

For the reverse direction, Joule passes a supported request through the authorized Microsoft integration so that relevant Microsoft 365 information can be accessed under the signed-in user’s permissions.

Prerequisites

Before starting the implementation, confirm the following:

Joule is subscribed, activated, and connected to at least one supported SAP business tenant.
SAP Cloud Identity Services is available and configured for the BTP landscape.
A Microsoft Entra ID tenant is available.
Microsoft 365 Copilot is deployed to the intended users.
Users have the appropriate Microsoft 365 Copilot and SAP licenses.
Users who will access Joule from Microsoft 365 have been created or replicated in the SAP Cloud Identity Services user store.
Administrative access is available for Microsoft Entra ID, Microsoft 365, SAP Cloud Identity Services, and SAP BTP.
Conditional authentication for Joule has been reviewed and configured where required.
Security, privacy, and compliance teams have approved the intended information flows.

Microsoft’s public overview lists SAP S/4HANA Cloud Private Edition, SAP S/4HANA Cloud Public Edition, SAP SuccessFactors, selected SAP Ariba scenarios, and other Joule-supported cloud applications as examples of supported applications. The SAP documentation should be treated as the authoritative source for the latest product-specific availability.

Step 1: Define the Tenant Strategy

Tenant planning should happen before creating the Entra application.

SAP states that Joule maintains a 1:1 relationship with a Microsoft Entra ID tenant. A single Entra tenant therefore cannot be used to configure multiple Joule environments in this integration model. For example, a development Joule environment and a production Joule environment cannot both be associated with the same Entra tenant. SAP recommends using a dedicated Microsoft 365 tenant when a separate integration test environment is required.

Document the following before proceeding:

SAP BTP global account:
SAP BTP subaccount:
Joule environment:
SAP Cloud Identity Services tenant:
Microsoft Entra tenant name:
Microsoft Entra tenant ID:
Microsoft 365 environment:
Integration owner:
Identity owner:
Security approver:

Lesson learned

The tenant constraint can affect project timelines, licensing, test planning, and security approval. It should be addressed during solution design rather than discovered during configuration.

Step 2: Collect Tenant and Issuer Information

You will need both the Microsoft Entra issuer and the SAP Cloud Identity Services issuer.

The Entra issuer follows this pattern:

https://login.microsoftonline.com/<ENTRA_TENANT_ID>/v2.0

The SAP Cloud Identity Services issuer can normally be obtained from its OpenID Connect discovery endpoint:

https://<IAS_DOMAIN>/.well-known/openid-configuration

Open the endpoint and record the exact value of the issuer property. The issuer value should be copied exactly, including protocol and domain, and normally without an unintended trailing slash.

Validation checkpoint

Confirm that:

The Entra tenant ID belongs to the intended environment.
The SAP Cloud Identity Services issuer resolves successfully.
The issuer value matches the domain used in the trust configuration.
Custom domains, if used, are included in the design.

Small differences in issuer URLs can cause token validation errors or repeated authentication redirects.

Step 3: Register the Federation Application in Microsoft Entra ID

In the Microsoft Entra admin center, navigate to:

Identity
  > Applications
  > App registrations
  > New registration

Create an application with a meaningful name, such as:

Federation with SAP Cloud Identity Services

Configure the web redirect URI:

https://<IAS_DOMAIN>/oauth2/callback

After registration, record:

Application (client) ID
Directory (tenant) ID

Both values are required during later stages of the integration. [community.sap.com]

Step 4: Add All Required Redirect URIs

Do not assume that one SAP Cloud Identity Services domain is sufficient. Depending on the tenant configuration, SAP may expose multiple supported domains.

Typical callback patterns include:

https://<TENANT>.accounts.ondemand.com/oauth2/callback

https://<TENANT>.accounts.cloud.sap/oauth2/callback

If a custom domain is used:

https://<CUSTOM_DOMAIN>/oauth2/callback

Add each applicable address under the application’s web authentication configuration. Missing callback URLs can result in redirect URI mismatch errors or inconsistent sign-in behavior when users enter through different endpoints. please make end of urls without spaces.

Step 5: Configure the Federated Credential

In the Entra application, navigate to:

Certificates & secrets
  > Federated credentials
  > Add credential

Select Other issuer and configure values corresponding to the SAP Cloud Identity Services trust.

A representative configuration includes:

Issuer:
<SAP_CLOUD_IDENTITY_ISSUER>

Subject identifier:
Federation with Entra ID

Audience:
https://login.microsoftonline.com/<ENTRA_TENANT_ID>/v2.0

The subject identifier must later correspond with the configuration in SAP Cloud Identity Services. Record the exact value instead of relying on memory or manually retyping it.

Common challenge

A mismatch in the issuer, subject, or audience can create authentication failures even when the Entra application itself appears healthy.

Step 6: Configure Claims, Permissions, and Token Versions

Add the required Microsoft Graph delegated permissions to the federation application:

email
offline_access
openid
profile

Grant tenant-wide administrative consent and verify that the permission status shows as granted. Also configure the optional email claim for the access token when required by the documented setup.

The documented application manifest configuration uses version 2 access tokens:

"requestedAccessTokenVersion": 2

For the corresponding legacy manifest property, the documented value is:

"accessTokenAcceptedVersion": 2

Review the current Entra portal experience and SAP instructions before editing manifest properties, particularly because portal labels and legacy manifest views can change.

Common challenge

It is possible for interactive sign-in to succeed while downstream token exchange still fails. This often leads teams to focus on the user account even though the actual problem is consent, token version, audience, or API exposure.

Step 7: Expose the Federation Application API

In the Entra application, navigate to:

Expose an API

Configure the Application ID URI according to SAP’s documented format. The SAP Community procedure specifically notes that the identifier must end with the expected accounts.cloud.sap domain format.

Create the delegated scope:

access_as_user

Provide an appropriate administrator consent name and description, then save the scope.

Carefully distinguish between:

The access_as_user scope exposed by the federation application
The access_as_user permission later added for SAP’s Copilot API access application

Although the names are similar, they serve different parts of the integration configuration.

Step 8: Configure Microsoft Entra ID as the Corporate Identity Provider

In the SAP Cloud Identity Services administration console, navigate to:

Identity Providers
  > Corporate Identity Providers
  > Create

Create a provider with settings similar to:

Display name:
Federation with Entra ID

Identity provider type:
OpenID Connect Compliant

Use the Entra issuer and federation application client ID collected earlier. Complete the trust configuration and ensure that the subject information corresponds exactly with the federated credential created in Entra ID.

Validation checkpoint

Test authentication through SAP Cloud Identity Services before adding Microsoft 365 Copilot to the troubleshooting scope. This isolates identity federation from agent installation and Joule routing.

Step 9: Validate User Provisioning and Identity Mapping

All intended users must exist in the SAP Cloud Identity Services user store. Authentication in Entra ID alone does not guarantee that Joule can identify and authorize the user.

Check that the following attributes are consistent:

Login name
Email address
User principal name
Subject identifier
User status
Relevant group or role assignments

Common challenge

A pilot user may have the correct Microsoft 365 Copilot license and still be unable to use Joule because the matching identity is absent, inactive, or inconsistently mapped in SAP Cloud Identity Services.

Use a small group of pilot accounts and create a simple identity comparison sheet before expanding the rollout.

Step 10: Add Microsoft 365 Copilot to the Joule Landscape

In the SAP BTP cockpit, open the system landscape and add a system of type:

M365 Copilot for SAP Joule

Enter the Microsoft 365 tenant ID associated with the intended Copilot and Teams deployment.

For a new Joule implementation, the integration can be activated during the Joule Booster execution. For an existing Joule implementation, add the new system to the relevant formation in the BTP cockpit.

Validation checkpoint

Confirm that:

The correct Microsoft tenant ID was entered.
The new system is present in the landscape.
The system is included in the correct Joule formation.
The formation has completed successfully.
No previous test tenant association is still active.

Step 11: Install SAP Joule from Microsoft AppSource

Use the Microsoft 365 admin center to install and deploy the official SAP Joule app to the appropriate users or groups.

The official AppSource listing states that the app connects to SAP solutions already integrated with Joule and can provide transactional, navigational, and informational capabilities based on the underlying SAP solution. It also notes that the necessary Microsoft and SAP licensing must be in place.

After the setup is complete, it can take up to two hours before the Joule agent becomes accessible from Microsoft 365 Copilot Chat. Do not immediately rebuild the application or modify permissions simply because the agent is not visible in the first few minutes.

Operational recommendation

Record:

Deployment start time:
Assigned user group:
App deployment status:
First successful visibility time:
First successful test time:

This helps distinguish normal propagation from an actual configuration failure.

Step 12: Enable Joule to Pass Requests to Microsoft 365 Copilot

The reverse direction requires additional consent for SAP’s Copilot API access application.

According to SAP’s documented procedure, an administrator first performs the tenant-specific consent flow for the SAP Copilot API access application. The federation app is then updated by adding the delegated access_as_user permission from:

svc-ai-joule-copilot-api-access

After adding the permission, grant administrator consent and verify that its status changes to Granted.

This step is necessary when Joule must access supported Microsoft information, such as Outlook calendar context, under the signed-in user’s authorization.

Step 13: Test the Integration in Both Directions

Testing only the launch experience is not sufficient. Validate identity, routing, authorization, and business responses.

Test A: Microsoft 365 Copilot to Joule

Example:

@Joule What is my remaining leave balance?

Or, where supported:

@Joule Show me open purchase orders past their expected delivery date.

Microsoft lists HR, procurement, and finance as representative scenarios for requests initiated from Copilot and routed to Joule. Actual availability depends on the connected SAP applications and enabled standard scenarios.

Test B: Joule to Microsoft 365

SAP’s documented validation example is:

What is in my calendar today?

If the integration and permissions are working, Joule should request the relevant Microsoft calendar information for the signed-in user.

Test C: Authorization Boundary

Test with:

A fully licensed pilot user
A user without the required SAP role
A user not provisioned to SAP Cloud Identity Services
A user outside the deployment group

The integration should not give users broader SAP or Microsoft access than their existing permissions permit. The AppSource description emphasizes that Joule provides role-based access to connected SAP processes and data.

Challenges and Troubleshooting Guide

1. The Joule Agent Does Not Appear

Possible causes:

Microsoft 365 deployment is still propagating.
The app was assigned to the wrong group.
The user does not have the required Microsoft 365 Copilot license.
The user has not signed out and back in.
The Microsoft tenant does not match the tenant configured in BTP.

SAP notes that the agent can require up to two hours to become available after installation and setup.

2. Authentication Repeats or Redirects Continuously

Check:

All applicable callback addresses
SAP Cloud Identity Services issuer
Entra issuer
Federated credential subject
Audience value
Corporate identity provider configuration

The SAP identity configuration guide documents these values as interdependent parts of the OpenID Connect trust.

3. Authentication Works but Joule Does Not Respond

Check:

Whether the user exists in SAP Cloud Identity Services
Whether the Joule formation is complete
Whether the appropriate SAP business system is integrated with Joule
Whether the required SAP role is assigned
Whether admin consent has been granted
Whether the requested scenario is supported

Microsoft notes that this managed integration supports standard Joule and Microsoft 365 Copilot scenarios and is distinct from custom agents created in Copilot Studio or Microsoft Foundry.

4. Joule Cannot Access Microsoft 365 Information

Check:

svc-ai-joule-copilot-api-access is present
access_as_user was added
Administrative consent was granted
The user has access to the relevant Microsoft 365 service
Conditional Access is not blocking the token flow

SAP’s reverse-integration procedure requires the delegated permission and administrator consent before Joule can pass supported requests to Microsoft services.

5. Development and Production Tenant Collision

If an Entra tenant is already associated with one Joule environment, do not assume it can also support another Joule environment. Review the 1:1 tenant limitation and use a separate test Microsoft 365 tenant when necessary.

Security, Privacy, and Governance Considerations

The integration should not be approached as a purely technical app installation. It connects two enterprise identity and AI ecosystems, so security and governance teams should review the use cases, application permissions, consent, data handling, audit responsibilities, and user communications.

SAP advises that generative AI output should be reviewed before use and that users should avoid entering sensitive personal data or other personal data they do not want processed. SAP also notes that Microsoft 365 Copilot processing is governed by the customer’s agreement with Microsoft.

Recommended governance controls include:

Start with a limited pilot group.
Use least-privilege SAP roles.
Review Entra enterprise application permissions.
Document all administrator consent actions.
Define an incident and access-revocation process.
Verify organizational retention and compliance requirements.
Train users to validate AI-generated responses.
Do not use production credentials or sensitive data in screenshots.
Review use cases with data protection and works council representatives where applicable.

Key Lessons Learned

1. Treat identity federation as its own workstream

Most implementation delays are not caused by the conversational experience itself. They are caused by mismatched issuers, callback URLs, user identities, permissions, or consent.

2. Confirm tenant topology before configuration

The 1:1 relationship between a Joule environment and an Entra tenant can significantly affect development and production planning.

3. Test one direction at a time

First test Microsoft 365 Copilot to Joule. Then test Joule to Microsoft 365. This makes it easier to identify whether the failure is related to the Joule agent, SAP business authorization, or Microsoft API access.

4. Allow time for Microsoft 365 propagation

Agent visibility is not always immediate. SAP documents a potential delay of up to two hours.

5. Separate managed integration from custom-agent requirements

The Joule and Microsoft 365 Copilot integration is a prebuilt, managed experience. If a requirement involves custom orchestration, organization-specific SAP APIs, proprietary workflows, or custom agents, Microsoft positions Copilot Studio, the Microsoft 365 Agents SDK, and Microsoft Foundry as separate extension approaches.

Conclusion

Integrating SAP Joule with Microsoft 365 Copilot can provide a valuable conversational bridge between SAP business processes and the Microsoft 365 working environment. Users can access supported SAP capabilities from Copilot or Teams, while Joule can use supported Microsoft 365 context without requiring a custom agent for the standard integration.

The implementation becomes much more predictable when it is treated as a coordinated identity, security, SAP platform, and Microsoft 365 deployment. Tenant planning, exact issuer values, complete redirect URI configuration, user replication, delegated permissions, administrative consent, and controlled testing are the areas that deserve the most attention.

Our most important lesson was simple: validate every trust boundary independently before testing the entire conversational journey. This approach reduces troubleshooting time, makes ownership clearer, and produces a more reliable production rollout.

Documentations and Further Reading

SAP Help Portal: Integrating Joule with Microsoft 365 Copilot
The primary SAP integration page covering prerequisites, BTP landscape configuration, Joule app installation, tenant limitations, and propagation expectations.
Microsoft Learn: SAP Joule and Microsoft 365 Copilot Integration
A useful public overview of the bidirectional architecture, supported scenarios, prerequisites, setup flow, and troubleshooting. The page was updated in May 2026.
SAP Community: Configuring SAP Cloud Identity Services and Microsoft Entra ID for Joule
A detailed walkthrough for establishing the OpenID Connect trust, including application registration, redirect addresses, credentials, permissions, token settings, API exposure, and corporate identity provider configuration.
SAP Community: Enable Joule to Pass Requests to Microsoft Copilot and Teams
Covers the reverse integration, SAP Copilot API access application, delegated permission, administrator consent, and a calendar-based validation scenario.
Microsoft AppSource: SAP Joule
The official application listing describing prerequisites and Joule’s transactional, navigational, and informational capability types.
Microsoft Learn: About SAP with Microsoft AI
Provides broader architectural context for using the managed Joule integration, extending through Copilot Studio, or building more advanced enterprise AI solutions.
Microsoft Learn: Copilot Studio and SAP Overview
Useful when the standard Joule integration does not cover a custom business requirement and a custom SAP-aware agent is being considered.

Monday, July 20, 2026

From “Tokenmaxxing” to “Token-pocalypse”: Is AI Becoming More Expensive Than Humans?

Companies raced to adopt AI. Now they are racing to control the bill.

For the last 3 years, businesses have been told the same story:

AI will help people work faster, automate repetitive tasks, and reduce operating costs.

That promise encouraged companies to buy AI assistants, deploy coding agents, and push employees to use artificial intelligence in almost every part of their work.

But a new problem is emerging.

AI may improve productivity, but using it at scale can be far more expensive than many organizations expected.

The conversation is quickly moving from:

“How much AI can we use?”

to:

“How much value are we getting for every AI token we consume?”

Welcome to the shift from tokenmaxxing to the token-pocalypse.

What Is an AI Token?

Before discussing the cost problem, it helps to understand what an AI token is.

A token is a small unit of information processed by a large language model. A token might be a word, part of a word, punctuation, code, or another piece of data.

Every time someone asks an AI assistant a question, the system processes tokens.

The AI may process:

The user’s prompt
Previous messages in the conversation
Uploaded documents
Connected business information
Instructions supplied to the AI
The response generated by the model

A simple question may consume relatively few tokens. However, an AI coding agent reviewing a large software repository, generating code, testing it, identifying errors, and trying again can consume a significant number of tokens.

When thousands of employees and autonomous agents perform these activities every day, the total cost can grow rapidly.

How “Tokenmaxxing” Took Over the Workplace

At the beginning of the AI adoption wave, many companies focused on encouraging usage.

Employees were asked to experiment with AI, integrate it into daily work, and use advanced models as often as possible. Some organizations reportedly introduced internal leaderboards and incentives to increase AI participation.

This culture became known as tokenmaxxing.

The basic idea was simple:

More AI usage should lead to more productivity.

For organizations concerned about falling behind their competitors, this appeared to be a sensible strategy. Leaders did not want employees debating whether to use AI. They wanted AI to become a normal part of the working day.

But measuring usage is not the same as measuring value.

An employee can consume millions of tokens without producing an equally valuable business outcome. A team may generate more code while also creating more bugs, rewrites, and review work.

In other words, token consumption can increase even when business value does not.

The AI Bill Is Arriving

The initial generation of workplace AI tools often came with simple, predictable subscription plans.

That made budgeting relatively easy. A company could purchase a certain number of licenses and know approximately how much it would spend each month.

AI agents are changing this model.

As vendors move toward consumption-based pricing, the final cost increasingly depends on factors such as:

The number of tokens processed
The model being used
The size of the context window
The frequency of requests
The number of steps an AI agent performs
How often the agent retries a task
The amount of data the system reads
Whether several models or agents work together

This makes AI expenditure much harder to predict.

TechCrunch reported that despite falling per-token prices, wider adoption and increasingly autonomous AI agents have pushed overall consumption higher. Companies that once focused mainly on AI capabilities are now asking vendors for better visibility, auditability, efficiency, and spending controls.

The important lesson is that a cheaper token does not automatically create a cheaper AI system.

If the price of each token falls but the organization consumes many more tokens, the total bill can still increase.

Gartner’s Warning: AI Coding Could Cost More Than a Developer

On June 24, 2026, Gartner issued a striking prediction:

By 2028, AI coding costs will surpass the average developer’s salary.

Gartner linked this prediction to rising token consumption and the transition from predictable, seat-based licenses to consumption-based pricing. The organization warned that many businesses are underestimating the financial impact of scaling AI coding agents.

This does not mean that every AI tool will cost more than every developer.

It means that the total AI coding cost associated with supporting a developer could become greater than the developer’s salary in some business environments, especially where agents operate with limited controls.

According to Gartner, common causes of overspending include:

Agents receiving too much autonomy
Unnecessarily large context windows
Poor visibility into token consumption
Inadequate cost controls
Limited feedback on inefficient usage
Difficulty connecting AI spending to measurable outcomes

That challenges one of the most common assumptions about workplace automation: that technology is automatically cheaper than human labor.

Why AI Costs Can Grow So Quickly

1. AI agents do more than answer questions

A normal chatbot might answer one question and stop.

An AI agent can plan a task, search through data, call tools, generate an output, test its work, discover a problem, and repeat the process.

Every additional step can consume more tokens and computing resources.

2. Large context windows are expensive

Employees often provide AI systems with large documents, lengthy chat histories, extensive code repositories, or unnecessary background information.

The AI must process that context before completing the task.

A bigger context window can be useful, but it does not always produce a proportionate improvement in quality.

3. The most powerful model is not always necessary

Organizations frequently default to their most capable AI model, even for simple work such as:

Reformatting text
Summarizing a short email
Renaming variables
Classifying support tickets
Converting information into bullet points

Using a premium model for every task is similar to hiring the most expensive specialist in the company to complete basic administrative work.

4. Small tasks become expensive at enterprise scale

One AI request may appear almost free.

Now multiply it by:

Thousands of employees
Hundreds of requests per person
Multiple AI agents
Continuous automated workflows
Every working day of the year

A low individual cost can become a major enterprise expense.

5. Companies struggle to measure the return

Many businesses can track how many employees are using AI, but fewer can explain how much revenue, quality improvement, or time saving that usage creates.

TechCrunch cited research indicating that heavy AI users could be around twice as productive while consuming approximately ten times as many tokens. The same reporting also noted concerns about bugs and rewrites increasing alongside output.

If productivity doubles while spending increases tenfold, leaders must ask whether the investment is efficient.

From Unlimited Usage to Token Rationing

The industry is now experiencing a sharp change in direction.

Companies that previously pushed workers to use AI are starting to impose budgets, restrictions, and usage controls.

TechCrunch described organizations trying to prevent expensive AI resources from being consumed by low-value activities such as basic document conversion. The publication characterized this as a move away from tokenmaxxing and toward token rationing.

This creates a confusing situation for employees.

They may have been told:

Use AI in every workflow
Demonstrate AI adoption
Increase AI usage
Develop AI skills
Show AI-related productivity

Now those same employees may be told:

Reduce token consumption
Avoid expensive models
Do not use AI for simple tasks
Stay within departmental budgets
Prove that every AI workflow creates value

The problem is not that employees suddenly became irresponsible.

In many cases, organizations encouraged usage before establishing clear financial rules.

Is AI Really More Expensive Than Human Employees?

The honest answer is: sometimes, but not always.

AI can be highly valuable when it accelerates expensive or complex work. For example, using AI to identify a critical software defect, analyze thousands of documents, or significantly shorten a product-development cycle may justify substantial computing costs.

However, the calculation becomes less convincing when expensive AI models are used for:

Low-value administrative work
Repetitive tasks with inexpensive alternatives
Poorly defined experiments
Outputs requiring extensive human correction
Automated workflows that run continuously without monitoring

Reports have highlighted cases where AI compute costs competed with or exceeded the cost of the employees using the systems. At the same time, human workers remain necessary to review outputs, correct mistakes, manage risk, and validate business results.

The better comparison is therefore not simply AI versus humans.

It is:

Human work alone versus human work improved by appropriately governed AI.

In most organizations, the strongest model is likely to be collaboration rather than total replacement.

The Productivity Trap

One of the biggest mistakes companies can make is confusing activity with productivity.

These numbers may look impressive:

Number of prompts submitted
Number of tokens consumed
Number of employees using AI
Number of AI-generated code suggestions
Number of agents deployed

But none of them automatically represents business value.

A successful AI program should focus on outcomes such as:

Time saved
Revenue generated
Defects prevented
Customer satisfaction improved
Processing time reduced
Employee workload reduced
Decisions made faster
Risk lowered

If an AI agent consumes €10,000 in tokens but helps prevent a €1 million loss, it may be an excellent investment.

If it consumes €10,000 to produce reports that nobody uses, it is not.

What Smart Organizations Should Do Next

The answer is not to stop using AI.

The answer is to use it with greater discipline.

1. Match the model to the task

Smaller and less expensive models can handle many routine activities.

Organizations should reserve premium models for difficult tasks that genuinely require advanced reasoning or higher-quality output.

Gartner recommends intelligent model routing, where simpler and more frequent tasks are sent to smaller models and complex work is escalated only when necessary.

2. Define when AI should be used

Not every task needs an agent.

Companies should create clear categories, such as:

Human-led work
Human work assisted by AI
AI-led work with human approval
Fully automated AI workflows

The appropriate level of autonomy should depend on cost, complexity, risk, and business value.

3. Improve context engineering

Employees should be trained to provide only the information the AI needs.

This may involve:

Removing irrelevant documents
Summarizing long conversations
Breaking large tasks into smaller requests
Avoiding repeated background information
Giving the AI structured and precise instructions

Better context can reduce both cost and confusion.

4. Introduce token budgets and alerts

Teams should have clear spending thresholds.

Finance and technology leaders can introduce:

Usage dashboards
Department-level budgets
Model-specific limits
Alerts for unusual consumption
Approval requirements for expensive workflows
Automated shutdown rules for runaway agents

These controls should be built into the workflow rather than added after the budget has already been exhausted.

5. Review high-consumption workflows

Gartner recommends including token-usage reviews in development cycles and sprint retrospectives. This can help teams identify waste, refine prompts, improve workflows, and share efficient practices.

6. Measure value, not enthusiasm

Employees should not be judged only by how frequently they use AI.

Rewarding raw usage can encourage unnecessary consumption and create the wrong behavior.

Instead, organizations should evaluate whether AI helps employees produce better outcomes at a reasonable cost.

AI Literacy Must Include Cost Literacy

AI literacy is often discussed as the ability to write prompts, understand limitations, and verify outputs.

That definition is no longer enough.

Modern AI literacy should also include:

Understanding token consumption
Selecting the right model
Managing context efficiently
Recognizing unnecessary automation
Checking output quality
Protecting sensitive information
Measuring costs against business results

The most AI-literate employee will not necessarily be the person who uses the most tokens.

It may be the person who gets the best result with the least unnecessary consumption.

Final Thoughts

AI is not becoming irrelevant. It is becoming accountable.

The novelty phase is ending, and businesses are entering a period where AI must prove its value in real operating environments.

That means asking harder questions:

What problem are we solving?
Is AI the right tool for this task?
Which model should we use?
How much will the complete workflow cost?
Does the output still require human correction?
Can we measure the business result?
Is there a simpler and cheaper alternative?

The winners of the AI race will not be the companies that consume the most tokens.

They will be the companies that create the most value from every token they consume.

Because the future of work is not about choosing between humans and AI.

It is about designing a system in which human judgment, AI capability, and financial discipline work together.

Key Takeaway

Do not measure AI success by how much your organization uses it. Measure success by the value it creates after cost, quality, and risk are considered.

Join the Conversation

Has your organization started measuring the cost of AI usage?

Are employees still being encouraged to use AI everywhere, or are teams beginning to introduce token budgets and usage controls?

Share your experience in the comments.

Follow for more practical insights on AI literacy, responsible adoption, governance, and the changing future of work.

References and Further Reading

Note: Some linked publications may require registration or a subscription to access their complete articles.

Start Small, Build Trust, Then Scale: My Experience with Copilot & Studio and Enterprise GenAI

Why successful enterprise AI adoption begins with people, practical use cases, trusted data, and a strong governance foundation.

Generative AI is often introduced as a technology transformation. From my experience, it is better understood as a people, data, and trust transformation enabled by technology.

Enterprises naturally want to move quickly. Leaders see powerful demonstrations, hear ambitious productivity claims, and feel pressure to launch sophisticated AI products. But when an enterprise is new to AI, starting with the most complex platform or use case can create confusion, resistance, governance concerns, and disappointing results.

My experience has taught me a different lesson:

Start with a simple and accessible AI experience. Help employees understand its value. Build security, privacy, data, and responsible AI foundations. Then introduce more advanced solutions such as Microsoft Copilot, specialized agents, and integrated AI workflows.

This approach may appear slower at the beginning, but it can enable much faster and more sustainable adoption later.

Our First Step Was a Simple Chat-Based AI Agent

When generative AI became a major enterprise topic in 2023, we did not begin with a large portfolio of complex AI products. We started with a relatively simple large language model based conversational agent and made it available to a broad employee population.

The purpose was not to automate an entire business process immediately. It was to give people a safe and practical environment in which they could experience generative AI.

Employees could ask questions, summarize information, structure ideas, improve written communication, and explore simple daily use cases. These activities helped users understand both the capabilities and the limitations of the technology.

Over approximately two years, the solution grew to around 60,000 users. That growth did not happen simply because the technology was available. It happened through continuous learning, employee feedback, practical enhancements, user education, and the addition of relevant everyday scenarios.

The platform became more than an AI tool. It became an enterprise learning environment.

AI Adoption Begins with Confidence

One of the most important lessons from this journey is that enterprises should not expect employees to adopt AI simply because a license has been assigned.

Before people can change the way they work, they need answers to fundamental questions:

What can this technology do for me?
What information am I allowed to enter?
Is my data protected?
Can I trust the response?
What should I do when the answer is incorrect?
Will AI replace my judgment or support it?
Who is accountable for the final result?

A simple chat-based experience gave employees the opportunity to answer these questions through practice. They learned how to write better prompts, verify outputs, identify useful scenarios, and recognize when human expertise was still necessary.

This aligns with Microsoft’s current adoption guidance, which emphasizes security and data readiness, intentional rollout, AI governance, user communities, champions, training, and clear expectations about where AI should support rather than replace human expertise.

The greatest value of the first solution was therefore not a single technical feature. It was the confidence it helped create.

The Foundation Made Copilot Adoption Easier

At a later stage, we decided to begin onboarding Microsoft Copilot while continuing to improve the existing AI experience.

These activities were intentionally run in parallel.

The first solution had already introduced users to conversational AI. Many employees understood concepts such as prompting, summarization, content generation, verification, and responsible use. Copilot could therefore be introduced not as an unfamiliar technology, but as the next stage of a journey employees had already started.

This reduced the conceptual gap between traditional applications and AI-assisted work.

Microsoft recommends evaluating data governance maturity and security controls before deploying Microsoft 365 Copilot. Its guidance also highlights that Copilot works with existing Microsoft 365 permissions, making content management, access controls, and data governance essential parts of readiness.

This is an important point for every enterprise: an AI assistant does not operate independently from the surrounding digital environment. Its usefulness depends on the quality, accessibility, security, and permissions of the information available to it.

Moving from General AI to Integrated AI

Once employees had a basic level of AI familiarity, we could introduce additional tools for more complex requirements.

These included solutions designed around:

Specialized business use cases
Enterprise knowledge retrieval
Process automation
Application and system integration
Role-specific assistance
Departmental workflows
More advanced AI agents
Productivity support within existing applications

The sequence mattered. Instead of presenting every AI capability at once, we built from general understanding toward specialized value.

Employees who had already experienced a simple AI assistant were generally more willing to explore new tools. They could evaluate the solutions using knowledge gained from earlier interactions. They also understood that AI output should be reviewed rather than accepted automatically.

This created a positive adoption cycle:

Employees tried simple AI scenarios.
Practical value increased confidence.
Feedback improved the platform.
Training improved AI literacy.
Trust encouraged broader adoption.
Broader adoption revealed more valuable use cases.
Better use cases supported investment in integrated solutions.

The enterprise was no longer introducing isolated AI products. It was building an AI-enabled working culture.

The Difficult Part Was Not the Model

The technical capabilities of large language models are impressive, but the most difficult enterprise challenges were not limited to technology.

They involved security, privacy, responsible AI, regulatory requirements, trust, and data.

1. Security and Privacy

Users need clear guidance about which information can be entered into an AI solution, how prompts and responses are handled, where information is processed, and who can access the resulting content.

Security cannot be added after deployment. It must be designed into identity management, access controls, data classification, retention, monitoring, and the approval process for AI use cases.

Enterprises should also distinguish between consumer AI services, approved enterprise services, internally developed agents, and AI features embedded in business applications. Employees may see all of them simply as “AI,” but their security and privacy characteristics can be very different.

Microsoft’s Copilot guidance stresses reviewing security and data settings before rollout because Copilot inherits existing Microsoft 365 data access and permissions. This means that inappropriate access or overshared content should be addressed as part of AI readiness.

2. Hallucinations, Unreliable Answers, and Bias

Generative AI can produce responses that sound confident even when they are incomplete or incorrect. Models can also reproduce or amplify bias present in data, design choices, evaluation methods, or the context in which a solution is used.

For this reason, employee education must include more than prompt-writing techniques. Users should learn to validate facts, check important sources, recognize uncertainty, and apply human judgment before using AI-generated content in a decision or business process.

The NIST AI Risk Management Framework identifies validity, reliability, safety, security, resilience, transparency, explainability, privacy, and fairness with harmful bias managed as important characteristics of trustworthy AI. NIST also emphasizes that these considerations must be addressed throughout the AI lifecycle rather than treated as a one-time technical assessment.

A responsible AI program should therefore include testing, evaluation, human oversight, incident reporting, monitoring, and a clear escalation process.

3. European Regulatory and Data-Boundary Requirements

For enterprises operating in Europe, AI adoption must account for data protection, processing locations, contractual obligations, sector-specific rules, and the EU AI Act.

The EU AI Act uses a risk-based approach and introduces obligations progressively. Requirements relating to prohibited practices and AI literacy began applying in February 2025, while rules for general-purpose AI and governance began applying in August 2025. Further transparency and high-risk requirements are being introduced through later phases.

Enterprises should not treat European requirements as a final compliance check. Legal, privacy, security, architecture, risk, employee representation, and business teams should be involved from the beginning.

An enterprise AI inventory is especially important. Leaders need visibility into which models and agents are being used, what data they access, where processing occurs, who owns each solution, and how risk is classified.

4. Trust

Trust cannot be created through communication alone. Employees build trust when they repeatedly see that:

A solution is useful for real work.
Its limitations are explained honestly.
Data is handled responsibly.
Incorrect responses can be challenged.
Feedback results in visible improvements.
Human accountability remains clear.
The enterprise does not exaggerate AI capabilities.

Trust also requires transparency. If users do not know why a particular tool has been approved, what information it can access, or how its output should be used, uncertainty will slow adoption.

The goal should not be blind trust in AI. The goal should be informed and calibrated trust, where people understand when AI is useful, when verification is needed, and when it should not be used.

5. Data Is Often the Biggest Challenge

The most significant practical challenge has been data.

An AI system may have a powerful model and a well-designed interface, but it will not consistently provide high-quality enterprise answers if the underlying information is outdated, duplicated, inaccessible, poorly structured, incorrectly permissioned, or missing important context.

If there is no clearly identified source of truth, the system may retrieve several conflicting documents. If ownership is unclear, obsolete content may remain available. If documents are poorly titled or classified, retrieval quality will suffer. If permissions are inconsistent, the AI may either fail to find useful information or make existing oversharing problems more visible.

Public research similarly emphasizes that relevant and high-quality data is central to realizing value from generative AI. Enterprises need to improve data ownership, metadata, access, quality, and governance rather than expecting a more advanced model to compensate for weak information foundations.

In simple terms:

AI does not automatically fix an enterprise’s information environment. It reflects and amplifies the condition of that environment.

Data readiness should therefore be treated as a business transformation program, not only as an IT cleanup exercise.

A Practical Adoption Model for Enterprises

Based on this experience, I recommend a phased approach.

Phase 1: Introduce

Provide an approved and secure conversational AI experience.
Focus on simple, low-risk daily tasks.
Publish clear acceptable-use guidance.
Explain privacy, security, and responsible AI principles.
Establish feedback and support channels.

Phase 2: Educate

Build AI literacy across the workforce.
Teach prompting, verification, and responsible use.
Create user communities and champion networks.
Share practical examples from different job roles.
Communicate limitations as clearly as benefits.

Phase 3: Strengthen the Foundation

Assess data quality and ownership.
Review permissions and information access.
Classify sensitive content.
Establish an AI inventory and risk-assessment process.
Define governance, accountability, and human oversight.
Align deployments with legal and regulatory obligations.

Phase 4: Expand

Introduce Microsoft Copilot and other productivity assistants.
Prioritize scenarios with observable user or business value.
Integrate AI into existing tools and workflows.
Develop specialized agents only where complexity is justified.
Continue measuring adoption, satisfaction, quality, risk, and outcomes.

Phase 5: Scale Responsibly

Monitor models, agents, data sources, and system behavior.
Retire low-value or duplicative tools.
Reassess risks as use cases evolve.
Improve enterprise knowledge continuously.
Scale proven scenarios across functions and regions.

Final Reflection

The strongest AI foundation is not created by buying the largest platform or launching the most ambitious agent.

It is created by helping people learn, building trust through experience, protecting enterprise information, improving data quality, and introducing complexity at the right time.

Starting with a simple conversational AI agent allowed users to experience generative AI before being asked to transform their work. Reaching approximately 60,000 users over two years gave us feedback, insight, and practical lessons that could not have been gained from a small technical pilot alone.

When Microsoft Copilot and other advanced AI tools were introduced, users were better prepared. They already understood the basic interaction model, the potential value, and the need to validate AI-generated results.

My central lesson is therefore straightforward:

Do not begin an enterprise AI journey with complexity. Begin with accessibility, education, governance, and trust. Build a strong foundation first, and advanced adoption will follow faster and more naturally.

The enterprises that succeed with AI will not necessarily be those that deploy the most tools. They will be the ones that create the right conditions for people, data, governance, and technology to work together.

Friday, July 17, 2026

When to Use Microsoft 365 Copilot vs Copilot Cowork vs Microsoft Scout

A Practical Guide to Choosing the Right AI Assistant

Microsoft's AI ecosystem is rapidly evolving from simple AI assistance to agentic AI that can execute, coordinate, and even proactively advance work. As organizations adopt AI at scale, a common question is:

Which tool should I use: Microsoft 365 Copilot, Copilot Cowork, or Microsoft Scout?

Based on Microsoft announcements and discussions from Microsoft leaders, MVPs, partners, and practitioners on LinkedIn, the answer comes down to a simple principle:

Copilot helps you think.
Cowork helps you execute.
Scout helps you stay ahead.

The Evolution of Microsoft AI

Microsoft's AI journey has moved through three stages:

AI Assistance → Microsoft 365 Copilot
AI Execution → Copilot Cowork
AI Autonomy → Microsoft Scout

Each serves a different purpose and complements the others rather than replacing them.

1. Microsoft 365 Copilot

Your Personal Productivity Assistant

Microsoft 365 Copilot is embedded across Word, Excel, Outlook, PowerPoint, Teams, and Copilot Chat. It helps individuals create content, analyze information, summarize conversations, and generate insights from organizational data.

Best Use Cases

Content Creation

Draft emails
Create reports
Build presentations
Write proposals

Knowledge Work

Summarize meetings
Analyze Excel data
Generate action items
Answer questions across company information

Personal Productivity

Prepare for meetings
Review email threads
Create presentations from documents
Generate executive summaries

Use Copilot When:

✅ You are working individually
✅ You need quick answers
✅ You need content creation assistance
✅ The task can be completed in a single interaction

Example

"Summarize the last three client meetings and draft a proposal based on the discussion."

Copilot generates the content quickly and helps you move forward.

2. Copilot Cowork

Your AI Execution Partner

Copilot Cowork introduces agentic execution. Instead of merely generating content, Cowork can plan, coordinate, and execute multi-step tasks across Microsoft 365 applications.

Think of Cowork as a digital teammate.

Microsoft describes Cowork as operating through a:

Plan → Act → Approve workflow.

Best Use Cases

Cross-App Workflows

Outlook + Teams + SharePoint
Meeting preparation
Status reporting
Stakeholder communications

Project Coordination

Gather project documents
Create summaries
Draft communications
Schedule follow-ups

Recurring Processes

Weekly executive updates
Team status reports
Customer follow-ups
Project reviews

Use Cowork When:

✅ Work spans multiple applications
✅ Multiple outputs are required
✅ You want execution, not just content generation
✅ You want AI to coordinate work on your behalf

Example

"Prepare me for tomorrow's steering committee meeting."

Cowork can:

Review meetings
Analyze emails
Locate documents
Create briefing notes
Draft follow-up actions

All while keeping you in control through approvals.

3. Microsoft Scout

Your Proactive AI Agent

Scout represents Microsoft's next step toward autonomous AI.

Unlike Copilot and Cowork, Scout is designed to be always-on and proactive. Instead of waiting for instructions, Scout continuously looks for important information, priorities, opportunities, and risks.

Many experts describe Scout as Microsoft's first "Autopilot" style experience.

Best Use Cases

Monitoring

Competitive intelligence
Industry trends
Executive priorities
Project risks

Proactive Insights

Daily briefings
Emerging opportunities
Escalation identification
Workload optimization

Autonomous Assistance

Calendar optimization
Follow-up tracking
Priority management
Routine monitoring

Use Scout When:

✅ You need continuous monitoring
✅ You want proactive recommendations
✅ You need market intelligence
✅ You want AI to surface insights before you ask

Example

"Monitor customer sentiment, competitor announcements, and executive emails. Alert me when something requires attention."

Scout continuously tracks and reports findings without needing repeated prompts.

Quick Comparison

Capability	M365 Copilot	Copilot Cowork	Microsoft Scout
Content Creation	✅ Excellent	✅ Good	Limited
Summarization	✅ Excellent	✅ Excellent	✅ Proactive
Multi-Step Execution	Limited	✅ Excellent	✅ Autonomous
Workflow Automation	Limited	✅ Strong	✅ Strong
Cross-App Coordination	Moderate	✅ Excellent	✅ Excellent
Research & Monitoring	Good	Good	✅ Best
Proactive Actions	No	Partial	✅ Yes
Best For	Thinking & Creating	Executing Work	Staying Ahead

Sources: LinkedIn community discussions, Microsoft AI practitioners, and partner analyses.

Decision Framework

Use Microsoft 365 Copilot if...

You need help creating content.
You need answers from company data.
You're working inside Word, Excel, Outlook, Teams, or PowerPoint.

Use Copilot Cowork if...

The task spans multiple applications.
You want AI to perform work, not just generate responses.
You need coordinated execution.

Use Microsoft Scout if...

You want always-on intelligence.
You need trend monitoring and proactive alerts.
You want AI to identify opportunities and risks automatically.

Final Thoughts

The future workplace is not about having one AI assistant. It is about using the right AI for the right job.

Copilot = Think
Cowork = Execute
Scout = Anticipate

Organizations that combine all three will gain the greatest productivity benefits, moving from AI-assisted work to AI-orchestrated work while maintaining Microsoft's enterprise security, compliance, and governance controls.

Why Microsoft and Other Tech Giants Cannot “Own” Frontier AI Models Anymore

Microsoft, Amazon, and Google are not simply struggling to keep expensive frontier models inside their ecosystems. A more accurate interpretation is that the AI market is moving away from exclusive relationships and toward a diversified network in which model developers, cloud providers, and enterprise software platforms simultaneously cooperate and compete.

OpenAI and Anthropic need enormous amounts of computing capacity, capital, and customer distribution. At the same time, Microsoft, Amazon, and Google cannot allow their cloud and productivity businesses to depend completely on one external model provider. The resulting strategy is not model loyalty. It is controlled diversification.

From exclusive partnerships to strategic interdependence

Microsoft’s relationship with OpenAI originally appeared to create one of the strongest competitive advantages in technology. Microsoft invested billions of dollars, integrated OpenAI models into Azure and Copilot, and obtained preferential access to OpenAI technology. Azure became the primary enterprise route to OpenAI models, while OpenAI received the infrastructure and capital required to train and operate increasingly capable AI systems. Reuters reported that Microsoft invested $1 billion in 2019 and another $10 billion in 2023, while Microsoft’s later agreements preserved access to OpenAI technology and a significant economic interest in the company.

But the relationship also created a structural tension. OpenAI needed more computing capacity, fundraising flexibility, and access to customers using clouds other than Azure. Microsoft, meanwhile, needed to ensure that products such as Microsoft 365 Copilot, GitHub Copilot, Azure AI, and enterprise agents would not remain dependent on the pricing, release schedule, technical roadmap, and governance decisions of one outside company. By 2025, OpenAI was seeking a broader corporate structure and additional infrastructure partnerships, while Microsoft was trying to retain long-term access to OpenAI’s intellectual property.

That tension produced a more flexible partnership. In April 2026, Microsoft and OpenAI announced that Microsoft would remain OpenAI’s primary cloud partner, but OpenAI would be able to serve products through other cloud providers. Microsoft retained a non-exclusive license to OpenAI models and products through 2032, while OpenAI’s revenue-sharing payments to Microsoft would continue through 2030, subject to a cap. Microsoft also stopped paying a revenue share to OpenAI.

This should not be understood simply as a breakup. Microsoft preserved access to OpenAI technology, an investment interest, and a strong Azure distribution relationship. OpenAI gained the freedom to find additional compute and reach customers outside Azure. Both parties reduced the risk of being constrained by the other.

Why frontier models are so difficult to contain

The first reason is the scale of the infrastructure required. Frontier AI companies need huge clusters of accelerators, high-speed networking, memory, electricity, cooling, and data-center capacity. They also need this capacity in multiple regions to meet latency, availability, and data-residency requirements. Depending on a single provider can create bottlenecks even when the partnership is strategically important.

Anthropic illustrates this clearly. The company identifies AWS as its primary training and cloud provider, but it also operates Claude through Google Cloud and Microsoft Azure. In April 2026, Anthropic announced an agreement to secure up to five gigawatts of AWS capacity and committed more than $100 billion over ten years to AWS technologies. During the same month, it announced an expansion with Google and Broadcom for multiple gigawatts of future TPU capacity.

This multi-cloud approach allows Anthropic to use AWS Trainium, Google TPUs, and NVIDIA GPUs for different workloads. It improves negotiating leverage, resilience, regional availability, and the ability to match workloads with the most suitable hardware. For a frontier-model company, cloud diversification is therefore not disloyalty. It is supply-chain management.

The second reason is that frontier-model inference remains expensive. Training receives much of the public attention, but inference is a recurring operating cost. Every user prompt, generated response, tool call, agent action, verification step, and retrieved document consumes compute. At enterprise scale, a small cost per request becomes a substantial operating expense. Research and industry analysis increasingly describe inference economics as a decisive factor in whether an AI application is commercially sustainable.

Agentic AI makes this problem more difficult. A chatbot might make one model call, while an agent can call a model repeatedly, search databases, use external tools, review its output, and try alternative approaches before completing one task. This means falling token prices do not automatically result in a lower total bill. Usage can grow faster than efficiency improves, especially as AI moves from limited pilots to continuous business processes.

The third reason is that enterprise customers want choice. Organizations do not necessarily want the most powerful model for every request. They want the cheapest model that satisfies the quality, security, latency, and reliability requirements of a particular task. A lightweight model may be sufficient for classification or summarization, while a frontier reasoning model might be reserved for software engineering, scientific analysis, or complex business decisions.

Finally, exclusivity can reduce a model developer’s addressable market. An enterprise that has standardized on AWS may prefer to buy AI through AWS contracts and governance systems. A Google Cloud customer may want Vertex AI integration. A Microsoft customer may want Entra identity, Azure networking, consolidated billing, and the ability to use existing Azure consumption commitments. Requiring customers to move clouds creates friction that both the model provider and the enterprise would prefer to avoid.

Microsoft’s real strategy: control the orchestration layer

Microsoft’s long-term strategy appears to be broader than owning or exclusively distributing one model. Its goal is to become the enterprise control plane through which organizations select, govern, deploy, and pay for different AI models.

Microsoft Foundry is central to this strategy. Claude models are available in Foundry with Azure authentication, billing, governance, SDK integration, and options for Azure-hosted or Anthropic-hosted processing. Eligible Claude consumption can also count toward a customer’s Microsoft Azure Consumption Commitment. This makes Microsoft commercially relevant even when the underlying model comes from Anthropic rather than OpenAI or Microsoft itself.

The same logic applies to Microsoft 365 Copilot and Copilot Studio. If Microsoft can provide the user interface, enterprise identity, security controls, document access, workflow integration, agent management, and billing relationship, it can create value regardless of which model processes an individual request. The model becomes an interchangeable component inside a larger enterprise platform. Anthropic’s integrations with Microsoft 365 Copilot, Excel, Copilot Studio, and Foundry demonstrate how a competing model provider can still strengthen Microsoft’s ecosystem.

Microsoft is also developing its own AI models. The strategic purpose is not necessarily to replace every OpenAI or Anthropic model immediately. Internal models can handle high-volume and predictable tasks at a lower cost, while expensive external models remain available for work requiring frontier-level reasoning. This creates a layered architecture: small models for routine requests, specialized models for particular domains, and frontier models for the most difficult tasks. Public reporting in July 2026 indicated that Microsoft had begun using internal MAI models for selected workloads in products such as Excel and Outlook, although those workloads represented only a portion of its overall AI usage.

In other words, Microsoft is moving from a “one model everywhere” approach to model routing. A routing system can consider task complexity, latency, geography, capacity, compliance, and cost before selecting a model. It can also switch providers when a service is unavailable or when a different model offers better price-performance. This reduces vendor dependence and gives Microsoft greater control over the economics of Copilot and Azure AI services.

Amazon and Google are following the same playbook

Amazon’s approach is to combine infrastructure, custom silicon, model choice, and enterprise distribution through Amazon Bedrock. Its relationship with Anthropic provides AWS with an important frontier model, while Trainium and Graviton give Amazon opportunities to reduce reliance on NVIDIA and improve the economics of running AI workloads. More than 100,000 customers reportedly run Claude through AWS, and the expanded 2026 agreement included additional investment and major long-term infrastructure commitments.

Google has a similar layered strategy. It develops Gemini, sells Google Cloud services, provides Vertex AI as a multi-model development platform, and offers Anthropic access to Google TPUs. Anthropic’s decision to diversify across Google TPUs, AWS Trainium, and NVIDIA GPUs demonstrates that a hyperscaler can benefit from an external model provider even when that provider competes with its own models.

The strategic objective for all three companies is therefore similar: own as much of the AI value chain as possible without requiring exclusive ownership of every model. That value chain includes chips, data centers, cloud services, identity, security, data platforms, development tools, agent orchestration, productivity applications, marketplaces, and customer billing.

What the next phase of enterprise AI will look like

The emerging market is likely to resemble a portfolio rather than a monopoly. Enterprises will use several models, just as they already use multiple databases, programming languages, and cloud services. Frontier models will remain important, but they will increasingly be reserved for tasks where their additional intelligence produces measurable business value.

Cloud providers will compete less on whether they possess one exclusive model and more on whether they can offer the best overall operating environment. The winning platform will need to route requests efficiently, enforce enterprise policies, provide observability, support data residency, maintain reliable capacity, and demonstrate the cost of completing a business task rather than merely reporting token consumption.

Cost optimization will also become a product capability. Companies will use prompt caching, shorter context windows, retrieval optimization, smaller models, custom silicon, batching, quantization, and model routing to control inference spending. The central metric may shift from “cost per million tokens” to “cost per successful task,” because a cheap model that requires repeated attempts may cost more than an expensive model that completes the task correctly the first time.

Conclusion

Microsoft and other large technology companies are not losing control of AI because OpenAI and Anthropic are appearing on competing clouds. They are adapting to the economic reality that frontier AI is too capital-intensive, fast-moving, and strategically important to be built around a single exclusive relationship.

OpenAI and Anthropic need multiple sources of capital, infrastructure, hardware, and customer distribution. Microsoft, Amazon, and Google need access to multiple model families, their own internal models, and orchestration systems that can choose the appropriate model for each task.

The ultimate competitive advantage may therefore not belong to the company with the best model at a particular moment. It may belong to the company that provides the most trusted and cost-efficient environment in which many models can operate.

Microsoft’s evolving strategy reflects this shift. It is protecting access to OpenAI, bringing Claude into Azure and Microsoft 365, building its own MAI models, and strengthening the identity, governance, billing, and agent layers around them. The goal is no longer to keep one frontier model trapped inside the Microsoft ecosystem. The goal is to make the Microsoft ecosystem the place where enterprises securely use, manage, and pay for every important model.

Reference

The next phase of the Microsoft-OpenAI partnership - The Official Microsoft Blog

Open-Source and Local AI Models vs Cloud AI Services: Which Hosting Option Should You Choose?

Real-World AI Hosting Case Studies

The differences between hosting models become clearer when we examine how organizations use them in real environments. The following case studies illustrate why businesses select local hosting, managed open-source infrastructure, or proprietary cloud AI services.

Note: The use cases below come from publicly available customer stories and vendor case studies. Readers should assess each architecture against their own security, compliance, performance, and cost requirements.

Use Case : Self-Hosted Open-Source AI for a Private Business Assistant

Business requirement

A private AI assistant was created for organizations that wanted employees to use a ChatGPT-style interface without sending confidential conversations or internal documents to an external AI provider.

The intended workloads included:

Internal document questions
Business strategy discussions
Private knowledge retrieval
Customer-support assistance
Sensitive employee conversations

The main concerns were data privacy, unpredictable usage charges, and reliance on third-party AI APIs.

Hosting decision

The solution used a self-hosted AI stack deployed on a dedicated Linux virtual private server.

Its principal components included:

Ollama for serving open-source models
Llama and Mistral variants as language models
Open WebUI as the user interface
Docker for containerized deployment
Nginx and TLS for secure web access
Authentication and restricted account registration
Host-level security controls

According to the published implementation, prompts and responses stayed on the dedicated server rather than being transmitted to a third-party language-model API. The deployment replaced per-message charges with fixed infrastructure costs.

Reported outcome

The deployment delivered a private AI chat service that was available continuously behind HTTPS and user authentication. The same infrastructure could also be reused for internal knowledge search, document question answering, and other private AI features.

Why self-hosting was appropriate

Self-hosting matched this use case because control over business data was more important than access to the largest proprietary model. The workload could run on smaller open-source models, and the operator was willing to manage the server, security, containers, and model updates.

Key lesson

Self-hosting is particularly effective when the use case is narrow, privacy-sensitive, and sufficiently predictable. It is less attractive when the organization does not have the expertise to secure, monitor, and maintain the environment.

Case-study factor	Assessment
Primary objective	Private AI conversations and fixed infrastructure costs
Hosting model	Self-hosted open-source AI
Model approach	Llama and Mistral variants served through Ollama
Main benefit	Prompts and responses remain on controlled infrastructure
Main trade-off	The operator is responsible for security and maintenance
Best fit	Private assistants, internal document search, offline or controlled environments

Use case: Atos Uses Managed Open-Source Hosting

Business requirement

Atos, a global digital-transformation, cybersecurity, and cloud-services company, needed a repeatable way for teams in Europe and the United States to deploy a broad set of applications and infrastructure services.

Its environment included more than AI models. The company needed to support:

Front-end and back-end applications
CI/CD delivery from GitHub and GitLab
PostgreSQL and ClickHouse databases
Superset for business intelligence
Keycloak for identity management
Monitoring and infrastructure tools
AI development environments and AI coding tools

Managing every component separately could increase deployment complexity and place additional demands on internal operations teams.

Hosting decision

Atos selected Elestio as a managed platform for deploying and operating these services.

According to the published customer story, Atos has used Elestio for more than five years and has expanded its footprint over time. Teams use the platform for services ranging from application delivery and databases to analytics, identity, infrastructure tooling, and AI development environments.

Elestio’s broader service includes managed setup, configuration, encryption, backups, updates, and monitoring for its open-source catalogue. The platform also offers deployment across supported cloud providers and on-premises environments.

Reported outcome

The platform gave Atos teams a consistent method for deploying services across Europe and the United States. The customer story highlights the company’s expanding use of Elestio, including several additional services introduced within a relatively short period.

Rather than building a separate operational process for every database, development tool, or AI environment, teams could use a common managed platform.

Why managed open-source hosting was appropriate

Atos needed flexibility across many technologies and geographies, but it also benefited from a standardized management layer. Full self-hosting would have provided maximum control, but it would also have increased the work required for deployment, patching, monitoring, backups, and lifecycle management.

A proprietary AI API alone would not have addressed the wider requirement because Atos needed databases, identity services, analytics, infrastructure tools, and AI-development environments as part of the same operational portfolio.

Key lesson

Managed open-source hosting is valuable when an organization wants to standardize how open-source services are deployed without transferring every workload to a closed software-as-a-service platform.

Case-study factor	Assessment
Organization	Atos
Primary objective	Standardize deployment of applications, infrastructure, data, and AI environments
Hosting model	Managed open-source hosting
Platform	Elestio
Geographic scope	Europe and the United States
Main benefit	A consistent deployment and management approach
Main trade-off	Continued dependency on an external management platform
Best fit	Multi-team organizations using several open-source technologies

Use case: Rezcomm Runs an Open-Source Data Platform on Elestio

Business requirement

Rezcomm operates a travel and e-commerce platform in the United Kingdom and the United States. Its technology requirements included databases, business intelligence, analytics, identity management, and AI workflows.

The company wanted the freedom to experiment with different open-source technologies while maintaining a consistent deployment process.

Hosting decision

Rezcomm chose Elestio to run its open-source data platform. According to Elestio’s published customer overview, the deployment brings databases, analytics, identity, business intelligence, and AI workflows together under one managed platform.

The case-study summary also identifies GDPR and PCI-related requirements as important considerations and describes a pricing structure that supports experimentation.

Business value

Combining multiple open-source services under one management platform can reduce the fragmentation created by operating each component independently. It can also give development teams greater freedom to test new services without designing a complete operations model for every experiment.

Why managed hosting was appropriate

Rezcomm’s requirement involved an interconnected data platform rather than a standalone language model. Managed open-source hosting provided a middle path between operating the entire stack independently and replacing it with multiple proprietary software services.

Key lesson

The managed open-source approach is not limited to hosting an AI model. It can support the databases, analytics platforms, workflow engines, identity systems, and monitoring tools that surround a production AI application.

Case-study factor	Assessment
Organization	Rezcomm
Industry	Travel and e-commerce
Hosting model	Managed open-source hosting
Workload	Data, analytics, identity, BI, and AI workflows
Main benefit	One deployment method for a broad open-source stack
Main trade-off	Dependence on the managed platform’s supported configurations
Best fit	Organizations building an integrated data and AI platform

Use Case : Almirall Uses a Cloud AI Service for Pharmaceutical Research

Business requirement

Almirall, a global pharmaceutical company focused on medical dermatology, had accumulated more than 50 years of research and development information.

Its scientists needed to search approximately 400,000 documents across three languages. Traditional processes required researchers to spend hours or days locating relevant information, and some existing research risked being overlooked or duplicated.

Hosting decision

Almirall created a custom research assistant using:

Azure OpenAI models
Azure AI Search
Azure Databricks
A tailored interface for scientific users

The solution allowed scientists to search historical research information using natural-language questions. It also helped automate routine information-retrieval tasks.

Reported outcome

Microsoft’s customer story states that scientists could access information in seconds rather than spending hours or days searching for it. The assistant covered more than five decades of R&D information contained in roughly 400,000 documents.

The system helped Almirall make institutional knowledge more accessible, reduce duplicated research effort, and support shorter research cycles.

Why cloud AI was appropriate

This was a complex multilingual knowledge-retrieval problem that needed capable language models, enterprise search, data engineering, and integration services. Using managed Azure services reduced the need for Almirall to build and operate every layer internally.

The business value was driven by faster access to research, not simply by minimizing the cost of each model request.

Key lesson

Cloud AI services are an attractive option when an organization needs to combine advanced models with established cloud search, analytics, security, and data services. They are particularly useful when speed of delivery and model capability outweigh the benefits of managing an open-source model directly.

Case-study factor	Assessment
Organization	Almirall
Industry	Pharmaceutical research
Primary objective	Make decades of R&D knowledge searchable
Hosting model	Cloud AI service
Technology	Azure OpenAI, Azure AI Search, and Azure Databricks
Scale	Approximately 400,000 documents across three languages
Reported value	Information retrieved in seconds rather than hours or days
Main trade-off	Dependency on the cloud provider’s platform and commercial terms

Use case : Air India Uses Cloud AI for Customer Service

Business requirement

Air India wanted to improve its virtual assistant and provide passengers with more effective natural-language support.

Airline customer service requires access to several types of information, including:

Flight bookings
Baggage information
Customer accounts
Travel policies
Service procedures

A conventional chatbot may struggle to interpret complex questions and provide useful responses across these different information sources.

Hosting decision

Air India updated the natural-language processing engine behind its virtual assistant using newer GPT models through Azure OpenAI Service.

Microsoft’s reference architecture for this type of airline solution combines Azure OpenAI with retrieval-augmented generation, Azure AI Search, Azure Cosmos DB, and cloud-hosted application components. The approach allows customers and support agents to ask questions in natural language while grounding responses in airline information.

Why cloud AI was appropriate

Passenger-service demand may vary significantly by time, season, route disruption, or unexpected events. Cloud infrastructure is generally better positioned to accommodate variable demand than a fixed local deployment.

The cloud approach also gives the organization access to updated language models without operating model-serving infrastructure directly.

Key lesson

Cloud AI services are well suited to customer-facing applications where demand can fluctuate and rapid access to capable natural-language models is important. However, the business must still implement reliable data retrieval, escalation to human agents, privacy controls, and monitoring.

Case-study factor	Assessment
Organization	Air India
Industry	Aviation
Primary objective	Improve a customer-service virtual assistant
Hosting model	Cloud AI service
Technology	GPT models through Azure OpenAI Service
Main benefit	Advanced natural-language capability without self-managing the model
Main trade-off	Ongoing API and cloud-service dependency
Best fit	Customer service with variable usage and large knowledge sources

What These Case Studies Tell Us

The case studies demonstrate that hosting decisions are usually driven by business constraints, not by model popularity.

Business situation	Most suitable model	Example
Confidential conversations must remain on controlled infrastructure	Self-hosted open source	Private AI assistant using Ollama and open-source models
Many open-source services must be managed consistently	Managed open-source hosting	Atos on Elestio
An integrated data and AI platform needs operational simplicity	Managed open-source hosting	Rezcomm on Elestio
Large multilingual knowledge collections require advanced search and reasoning	Cloud AI service	Almirall on Azure
Customer-facing demand may change rapidly	Cloud AI service	Air India virtual assistant

A clear pattern emerges:

Self-hosted AI is strongest when privacy, offline operation, customization, or fixed high-volume processing is the primary concern.
Managed open-source hosting is strongest when a business wants control and portability but does not want to operate the full stack.
Cloud AI services are strongest when rapid implementation, elastic capacity, and access to advanced models are the main priorities.

The application’s risk level also matters. A marketing assistant, an internal research tool, and a customer-facing financial system should not automatically use the same architecture.

A Practical Example of a Hybrid Architecture

An organization can also combine all three hosting models.

Consider a financial-services company processing customer documents:

A self-hosted model identifies personal and confidential information inside the company’s private environment.
A managed open-source platform operates the document database, vector store, workflow engine, and monitoring tools.
A cloud AI service performs advanced reasoning on sanitized content when the local model cannot complete the task reliably.
High-risk outputs are sent to a qualified employee for review before any action is taken.

This design allows the business to use each model where it contributes the most value. Sensitive information remains controlled, routine work uses predictable infrastructure, and advanced cloud models are used selectively.

The final architecture should therefore be based on workload classification, rather than selecting one hosting model for the entire organization.

Updated Final Recommendation

Start by classifying each proposed AI workload according to:

Data sensitivity
Regulatory restrictions
Usage volume
Latency requirements
Required model quality
Customization needs
Availability requirements
Internal operational expertise

Then select the hosting approach at the workload level.

A cloud AI service may be the right choice for an initial prototype. As usage grows, predictable parts of the workload may move to managed or self-hosted open-source models. Highly sensitive processes may remain private from the beginning.

The most sustainable strategy is often a hybrid, model-independent architecture that allows the organization to change models or providers without rebuilding the entire application.