Here is the promise we were all given. Artificial intelligence was going to democratize every piece of information in your company.
It would close the gap between having data and making a decision. Teams would move faster. Compliance would be a breeze.
Your organization would finally turn years of hidden knowledge into a massive competitive advantage.
That was the pitch, and that is why you signed the checks for the licenses.
But here is what is actually happening. Your teams are spending more time engineering prompts than actually doing their jobs.
They ask co-pilot a question, they get back a massive wall of text, then they have to navigate back to SharePoint to find the source document.
They jump over to Excel to pull the numbers, they switch to Outlook to send the final approval, somewhere in all that switching.
The efficiency just evaporates, the problem isn't the AI itself, the problem is the interface.
We have built the wrong model for how intelligence should work inside a business.
We took the chatbot idea from consumer apps, text in, text out, and we dropped it into complex business processes.
We never stopped to ask if a text box is the right way to get work done.
It isn't, and the structural cost of that mistake is forcing a change.
On July 1st, the math changes for everyone.
Microsoft 365 base prices are going up.
Even more importantly, the co-pilot features currently sitting inside your apps are moving behind a license gate.
SPFX version 1.24 hits preview in a few weeks, bringing the first real alternative to this chat first world.
By the end of 2026, the shift from chat as an interface to actions as an interface will be the only way forward.
By the end of this video, you will see why the shift is a structural necessity rather than just another feature update.
You will see how the company's preparing right now will be operating 18 months ahead of everyone else.
And you will understand exactly what has to change in your governance model to make it work.
The chatbox bottleneck.
We have to start with a fundamental misdiagnosis.
The story we're told about co-pilot is that text is efficient, we're told it's high density.
You can ask a question in 20 words and get back 200 words of perfect context.
That feels like speed, but in reality, it's the opposite.
That efficiency is great for the machine, but it's a disaster for the human trying to finish a task.
Think about the actual pattern in your office.
A user in your operations team needs to approve a purchase order.
They open co-pilot.
They ask for the status of requisition 47382.
Co-pilot gives them a clean paragraph with the order details, the approval chain and the timeline.
The user reads it, they understand it, but then what?
They still have to navigate back to the procurement system to click the approve button.
If that requisition lives in a SharePoint list, they have to go search for it all over again.
The text didn't finish the job.
It just created a parallel track that the human now has to manually fix.
When you multiply that by every user and every task, you see the real cost.
This is the friction we aren't measuring.
Every time someone jumps from a chat window to an action, they are burning mental energy.
They are leaving the flow of their work.
If you actually track the time from, "I need to do this too," this is finished.
The bottleneck isn't the question.
It's the jumping between systems.
The chat was supposed to stop the searching.
Instead, it just moved it.
In regulated industries, this turns into a compliance nightmare.
Every prompt is a new record to track every time a user switches context,
you create a gap in the audit trail.
When an employee manually matches what Copilot said with what the system shows,
you've hit a control failure.
You are paying for high-level intelligence,
but running it through a broken structure.
In operations, every small delay starts to add up.
A decision that takes 10 minutes to reach should only take 3 minutes to finish.
If it takes 10 minutes just to navigate to the right screen and execute,
you've killed the value of the AI.
You haven't solved the bottleneck.
You've just built a new one.
The core issue is that we've borrowed the model from chat GPT and Gemini.
Those systems were built for individuals asking questions for personal use.
When we dropped that model into the enterprise without asking if it fit,
it doesn't.
And that realization is what should be changing your entire architecture right now.
Permission magnification, not a new risk.
The security conversation needs a reframe.
Most people think Copilot creates new risks.
They think it's a data leakage vector.
They think you have to shut it down or restrict it,
because it might expose things you never intended to share.
That narrative is wrong.
It's a symptom of a deeper misunderstanding.
Copilot doesn't create security risks.
It exposes permission problems that already existed.
And that distinction changes everything about how you approach this.
Here is how it actually works.
Copilot uses the same security trimming as SharePoint Search,
the same filtering logic, the same access control model.
When you ask Copilot a question,
it isn't pulling data from outside your tenant boundary.
It queries the same index that Search uses
and that index respects your existing permissions.
Full stop.
A user cannot see content in Copilot that they couldn't see in Search.
They cannot access a document through the AI
that they wouldn't be able to open manually.
Technically, Copilot isn't a new access vector.
It's using the one you already have.
But here is the amplification effect.
And this is where the real conversation starts.
If your SharePoint has anyone with the link shares on sensitive files,
Copilot doesn't change that.
That problem was already there,
but the discovery time changes.
Copilot makes that data discoverable in seconds instead of hours.
Someone asks a natural language question.
What are our contract terms with Acme?
Find me the competitor analysis from Q3.
They don't need to know the site name.
They don't need the library path.
They don't need to understand the document structure.
They just get an answer instantly.
Is Copilot the problem?
No.
The problem is that someone could share a document
with anyone in the first place.
Copilot didn't create that risk.
It just made it visible.
Architects usually miss this.
They see Copilot surfacing sensitive data
and they blame the tool.
So they restrict access.
They block sites from being indexed.
They treat the symptom, but they don't fix the disease.
The structural flaw is that most organizations have flat permissions.
But hierarchical compliance requirements.
Flat permissions look like this.
You have a site called shared resources.
Everyone in the department can access it.
Everyone can see every folder.
Everyone can edit documents.
It's open.
It's collaborative.
And in a certain context, it makes sense.
hierarchical compliance looks different.
Some documents in that site are contract terms.
Only legal should see those.
Some are budget-focused for finance.
Some are employee records for HR.
But they all live in the same site with the same flat permission model.
This gap is what Copilot makes visible.
It's the distance between how you structured permissions
and what your governance actually requires.
When Copilot surfaces budget data to an individual contributor,
the reflex is to blame the AI.
The actual fix is to go back and restructure your permissions.
You have to enforce compliance at the site and library level.
Not assume it at the behavioral level.
This is why the licensing change matters so much.
Organizations with messy permissions will see Copilot
and think it's too risky.
Organizations with clean permissions
will see Copilot and think it's their primary interface for work.
One group blocks it.
One group accelerates it.
And that decision determines which group you're in by 2027.
The July 1st cliff, licensing is architecture.
What's happening on July 1st isn't just a price adjustment.
It's the moment when licensing becomes a statement
about how you architect AI into your business.
Two things happen at once.
Microsoft 365 base plan prices increase.
E3 goes from $36 to $39.
Business standard goes from $12.50 to $14.
At scale, those numbers add up.
But the pricing changes secondary to what happens to the features.
Right now, if you have a Microsoft license,
you get some AI assistance.
It's limited.
It's often in preview, but it's there.
Starting July 1st, that changes.
Users without an explicit $30 per month Copilot license
lose the embedded AI.
It disappears from Word.
It disappears from Excel, PowerPoint, and OneNote.
And it extends to SharePoint.
If you rely on Copilot for list management
or document workflows,
that feature vanishes for anyone without the paid seat.
Microsoft calls these premium features
that's the marketing.
Pay more.
Get the better version.
But the structural reality is different.
This isn't about feature tiers.
This is about declaring who operates inside the agent fabric.
And who operates outside it?
Think about what that means for your operations.
You have a thousand person organization.
Maybe 30% of those people do work that actually benefits from AI.
The decision makers, the operators,
the people managing workflows.
For a thousand person org, that's 300 people.
Licensing 30% of your staff at $30 a month is $108,000 a year.
That's a budget conversation.
But you aren't just buying a feature.
You aren't even buying access to Copilot.
You are declaring an architectural boundary.
You're saying these 300 people work in a world
where AI is integrated into their tools.
The other 700 work in a world where AI is optional.
Or peripheral.
Or off limits.
That's a governance decision.
And it shapes everything downstream.
Once you decide who gets the license,
everything else follows.
If operation staff have Copilot,
but customer service doesn't,
they are using different tooling.
If project managers have AI in Excel,
but their teams don't, you've created asymmetry.
That asymmetry either becomes a competitive advantage
or it fragments into friction.
It all depends on how you architect the handoff points.
Organizations that haven't thought about this
will hit July 1st and react.
They will either buy too many licenses
or they will restrict it more than they should.
Then they'll live with those consequences
for 18 months while they try to find the right model.
The organization is thinking about this now.
Move differently.
They see licensing as an architecture decision.
Not a cost decision.
They've mapped which workflows need embedded AI.
They have clarity on their governance boundaries.
They understand that the licensing choices
the constraint that forces discipline.
This moment matters because it reveals the shift
in how enterprises operate.
The change isn't arbitrary.
It's the inflection point where chat stops being an option
and becomes a declared operational boundary.
Beyond text, the headless UI model.
If the diagnosis is that chat is a bottleneck,
the question becomes, what is the alternative?
The answer isn't better chat.
It is not about optimizing prompts
or training people to ask smarter questions
or getting faster response times.
The answer is to stop relying on text
to be the interface for action.
Let me reframe what is actually happening
with SharePoint co-pilot apps.
This isn't about adding a feature to co-pilot.
This is about fundamentally changing the interaction model.
In the old way, a user asks a question,
co-pilot returns text,
and the user then has to navigate to a system
to manually act on that text.
The new model looks like this.
A user asks a question,
co-pilot surfaces an interactive component,
a form, a button, or a dashboard,
directly in the chat canvas,
and the user interacts with that component
so the action happens in context.
That is the shift.
That is what beyond text actually means.
The technology enabling this is SharePoint co-pilot apps
which enters preview in July of 2026.
What it does is let SharePoint framework components,
web parts you have already built for your internet,
your dashboards,
and your list management interfaces
render directly inside the co-pilot canvas.
These are not static images or pre-formatted responses.
These are interactive components
where you can click a button, fill out a form,
approve something, or update a status,
and all of that happens in line
without leaving the conversation.
Why does this matter?
Because it collapses the distance between decision and action.
Right now, if someone asks co-pilot,
what is the status of this project?
And co-pilot returns a paragraph describing the status.
The user still needs to navigate
to the project management system
to actually update something.
With the interactive component model,
co-pilot surfaces a status dashboard in line,
which means the user can see the data in context
and hit a button right there to update it immediately.
That is not just faster,
that is a different operational reality.
From a governance perspective, this changes everything.
Every interaction stays inside your tenant.
Every action is logged automatically
because it is happening through your own sharepoint infrastructure
and every component respects the same permission model
that governs your regular sharepoint access.
If you do not have permission to see a list,
the component will not show your data from that list
and if you do not have permission to modify something,
the update button will not even be active.
Nothing happens outside your audit trail.
Nothing escapes your security boundary.
This is critical because it means the agent fabric
isn't some external AI system
that you are integrating with and managing separately.
It is an evolution of the infrastructure you already have.
You are not layering a new security model on top.
You are extending the one that exists for developers.
This is the inflection point.
You have probably spent years building SPFX webpots
for sharepoint pages,
so you know how to build them,
how to structure data and how to call APIs.
That expertise, which was valuable for Internet work,
is now your primary asset for operationalizing enterprise AI.
This isn't about learning a new framework.
It is not about retraining.
It is about understanding that the skills you have already built
are now the primary mechanism
for moving intelligence into the hands of people
who need to act on it.
The component appears in co-pilot.
The user interacts with it.
The action is logged.
The permission is enforced.
The result is immediate.
That is the operational model shift.
That is what changes everything downstream.
And it only works if you understand what comes next.
The difference between how we have been organizing work
and how we are about to have to organize it,
that is the old model versus the new model.
And that distinction is where the real architecture decisions happen.
The old model versus the new model,
to understand why this transition is unavoidable,
you need to see exactly what changes
when you move from text-based chat to interactive components.
The difference isn't cosmetic.
It is structural.
And it reveals why most organizations are currently stuck
in a place they did not intend to be.
Here is how work happens in the old model.
You are in operations.
You need to approve a budget.
You navigate to SharePoint.
You know the site name, finance operations.
So you get there directly.
You look for the folder.
It is in shared documents under Q4 approvals.
You find the spreadsheet.
You download it or open it in line.
And then you read through the line items
to see the budget code, the amount,
the department, and the justification.
Now you understand what you are approving.
But you are not in the approval system yet.
That is in a different place.
So you navigate there.
You search for the same budget item.
You find it in the workflow.
And you finally hit approve.
And add your comments.
So the action is logged.
Start to finish.
That took 15 minutes.
Most of that time was not decision making.
It was navigation, searching.
Context switching between the document
and the approval interface.
Now let's look at why that model is breaking.
The friction points are cumulative.
You are switching contexts multiple times.
And each switch costs cognitive load
because your brain has to reset.
You are doing manual search
because you might not remember exactly where things live.
And if the organization has changed the folder structure
or renamed sites, you are lost.
The content you are reading is separated from the action
you are taking.
So you are holding mental state in working memory.
And all of that extends the time between
I need to make a decision.
And the decision is actually recorded.
That is the old model.
And it is the way most organizations
have built their share point.
The new model is different from the ground up.
You ask co-pilot, what budgets need my approval?
Co-pilot does not return a paragraph
describing what needs approval.
Instead, it surfaces a custom component.
That component shows you the pending items
displaying the budget code, amount,
department and justification
all in a formatted view
in line in the co-pilot canvas.
If you want more detail, you can expand an item.
And if you are ready to decide,
there is an approved button right there.
You click it.
The action is recorded.
You are done.
Start to finish.
That took two minutes.
No navigation.
No search.
No context switching.
No cognitive overhead of holding the budget details
in your head while you jump to another system.
The architectural difference is subtle but fundamental.
In the old model, humans are the primary navigation layer.
You know where things are.
You know how to find them.
The system assumes you are going to navigate manually.
AI is an optional help tool.
You ask it questions, it gives you answers
and you go find the thing.
In the new model, AI becomes the navigation layer.
You tell co-pilot what you need.
It does not just answer your question.
It presents the actionable interface directly.
You interact with the component.
You do not navigate separately.
The system assumes you are going to engage
through co-pilot first.
This is why most organizations are stuck between the two.
They have spent years building sharepoint
around the old model.
Sites are organized around navigation.
Documents are structured for discovery.
Workflows require manual entry points.
The entire information architecture assumes
humans are searching and navigating.
Migrating to the new model requires
rethinking that entire structure.
It is not a technical change.
It is a governance change.
That is why some organizations
that have already restructured their information architecture
classified their data,
built permission boundaries
that match compliance requirements
and invested in sensitivity labels and DLP policies
can move to this new model immediately.
Their governance foundation supports it
for organizations that have not done that work.
The new model creates visibility problems
before it creates efficiency gains.
This is observable in early adoption data.
Organizations moving to the new model
are seeing 40 to 60% reduction in time to decision
for structured workflows.
That is not marginal improvement.
That is the difference between operational efficiency
and operational friction.
And this is why SPFX 1.24 isn't just a feature release.
It is the moment when you have to make an explicit governance
choice about which model your organization is operating in.
You are choosing right now
whether to keep building for the old model
or start architecting for the new one.
Why SPFX 1.24 is the inflection point.
This is the moment where the architecture becomes real.
It stops being theoretical.
SharePoint co-pilot apps.
The actual mechanism for surfacing components
in co-pilot enters preview in July 2026
and it arrives alongside SPFX 1.24.
That timing isn't a coincidence.
It is the point where every technical decision you make
about SharePoint becomes an architectural decision
about how you run your AI.
We need to be clear about what actually changed here.
SPFX was originally designed for SharePoint pages
and it was the framework you used to build web parts
or custom interfaces that lived on your internet sites.
That was the use case.
That was the domain.
You used it to extend the page layer of SharePoint.
But now, SPFX is the primary way
to build what Microsoft calls "Egentic UX".
It is the mechanism for putting interactive components
directly into the co-pilot orchestration layer.
This isn't just an expansion of what SPFX can do.
It's a fundamental shift in what the framework is actually for.
But here's the problem with calling it just another version release.
Version 1.24 is the inflection point
because it includes a full suite of dependency modernizations
that go way beyond incremental updates.
You're getting updated NPM packages across the board
which finally reduces the technical debt
you've been carrying from earlier versions.
You're getting React 18 support
and that finally aligns SPFX development
with the mainstream JavaScript ecosystem
instead of keeping you tethered to older, slower patterns.
You're also getting navigation customizers
that let you override how navigation itself works inside SharePoint.
Each of these changes was designed
to remove the friction of building modern components.
So why does that matter?
It matters because if you already have a mature SPFX estate
and you've spent years building webpots
and custom interfaces for your internet,
you can now surface those exact components inside co-pilot
without rebuilding them from scratch.
The components you already built,
the patterns you already established,
the teams that already know how to maintain them,
you aren't starting over.
You're extending.
That is the reuse story that makes this actually achievable
for a business.
If SPFX 1.24 required you to rewrite every existing component,
adoption would be slow and it would be expensive.
Instead, the process is additive.
You take what you've already built,
you apply the 1.24 modernizations
and then you expose it in co-pilot.
The investment you've already made doesn't become obsolete,
it actually becomes more valuable.
And from a governance perspective,
this is where the security stack inheritance really matters.
SPFX runs inside your tenant boundary.
It doesn't crawl out to external servers for logic or data,
so it inherits the full Microsoft 365 security
and governance stack directly.
EntraID handles your identity,
SharePoint enforces your permissions.
Sensitivity labels flow through automatically
and DLP policies apply without you having
to do any additional configuration.
The compliance controls you've already implemented
for regular SharePoint don't need to be redone
for co-pilot components, they're just automatic.
This is a fundamentally different security model
than building custom integrations
that sit outside your tenant boundary.
There is no credential management
across different boundaries.
There are no external API keys to rotate.
There isn't a separate audit trail
that you have to manually correlate
with your internal logging.
The governance model is unified
because the execution model is unified.
The licensing alignment reinforces this even further.
SPFX co-pilot apps are licensed
through the same Microsoft 365 co-pilot seat
you're already paying for.
You aren't buying a separate skew for this.
You aren't dealing with consumption-based billing,
where every component interaction
gets metered and charged per action.
You make one licensing decision
who gets the $30 per month co-pilot seat
and that decision automatically covers your SPFX co-pilot apps.
It's simple, it's predictable, it's governable.
For developers, this completely reframes
what your existing expertise is worth.
Your SharePoint framework skills,
the things you learned for page-level customization
are now your primary asset for running enterprise intelligence.
You aren't becoming an AI developer,
you're becoming an orchestration developer,
and the interface for that orchestration
is the exact skill set you already have.
This is why 1.24 is the inflection point.
It's not because of one single feature.
It's because all of these elements,
the dependencies, the reusable components,
the governance, the licensing,
and the developer relevance all converge at the same moment.
And that convergence is exactly when
the choice between different architectural parts
becomes unavoidable because SPFX isn't your only option.
There is another path entirely,
MCP apps, the open path,
that other paths is MCP,
and understanding what it is
and why it's fundamentally different
from the SPFX approach,
clarifies the entire governance trade-off you're making
when you choose how to build your agent fabric.
MCP stands for Model Context Protocol.
It's a vendor neutral standard created to define
how AI agents discover, call, and interact with tools.
You can think of it as a contract language
between an AI system and external capabilities.
You define what your system can do,
you list the tools it exposes,
and you set the format for the data it returns.
You publish that definition,
and then any AI system that understands MCP
can call those tools, and that is the core appeal,
vendor neutrality.
The same MCP server you build can work with Microsoft 365 Copilot,
but it can also work with Claude,
ChapGPT, or GitHub Copilot.
You write the integration once,
and then you can reuse it across multiple AI platforms.
That's powerful when you think about your investment.
You aren't locking your work into a single AI vendor's ecosystem.
MCP apps take this a step further.
They let your MCP server return interactive UI widgets
alongside the data.
So instead of Copilot,
just giving you a text response about an order status,
your MCP server returns the status data
and a visual component.
That component lets the user update the status,
track the shipping, or start a refund right there.
The widget renders inline in the Copilot canvas.
The user interacts with it.
The data gets updated back through your system.
Here is how it actually works.
You host an MCP server somewhere,
like on-premises, in Azure,
or in any cloud provider you choose.
You write the server in whatever language fits your architecture,
whether that's node, Python, or .NET.
That server defines the tools it exposes
and what those tools do.
When Copilot needs to interact with your system,
it calls your MCP server
and then your server processes the request.
It returns the structured data and the UI metadata.
Copilot renders the response,
the user interacts with it,
and the loop closes.
That sounds straightforward.
But the friction points reveal why this is a different governance category entirely.
To make this work securely,
you need OAuth 2 properly configured.
You need Mutual TLS,
which means both sides of the connection have to authenticate each other.
You need federated credentials in Entra
so that Copilot can authenticate your MCP server
without your server storing credentials in a database.
If you want custom connectors in Power Apps
to call your MCP server,
you have to register those two.
If you want to log what's happening,
you have to instrument your own server.
Each of these steps is very precise.
One misconfigured redirect,
URI breaks the entire flow.
One certificate issue stops everything.
The real governance cost is that your MCP server
is external to your tenant.
That isn't inherently bad,
and sometimes that's exactly what you need.
But it means you are managing identity across a boundary.
You're securing a new integration point.
You're responsible for secret rotation.
You're maintaining audit logs that span your tenant
and an external server.
If something goes wrong,
the forensics require you to correlate data across two different systems.
This is the right choice in specific scenarios.
If your data is scattered,
some in dynamics, some in Salesforce,
some in a custom ERP,
and some in a data warehouse,
then you need something that can orchestrate across all of it.
You can't build every one of those integrations into your tenant.
In that case,
an MCP server becomes the translation layer.
You build ones, you call from co-pilot,
you get vendor agnostic tool reuse.
But you have to notice what you're trading away.
You gain flexibility and portability
across different platforms.
But you lose the unified governance
that comes from staying inside your tenant boundary.
You gain the ability to integrate anything you want.
But you lose the automatic security inheritance
that comes from running on Microsoft 365 infrastructure.
That trade-off is the entire question,
and how you answer it determines which architecture
you are actually building.
SPFX co-pilot apps, the fortified path.
SPFX co-pilot apps operate on a completely different premise.
Instead of building an external MCP server
and figuring out how to integrate it,
you're taking components you've already built inside SharePoint
and exposing them directly into the co-pilot canvas.
The component you created for your internet page
becomes a tool that co-pilot surfaces in line.
No external servers, no authentication bridge,
no integration complexity.
Here's the technical model.
You build a web part or extension using SharePoint framework,
which is the same way you've been doing it for years.
You package it, you deploy it to the SharePoint app catalog.
When co-pilot needs to surface interactive capabilities,
it pulls that component and renders it in the chat canvas.
The user interacts with the component
and the data flows directly through your SharePoint infrastructure.
Everything stays inside.
This different sounds minor.
It's actually fundamental.
The governance advantage is where this becomes concrete.
Everything runs inside your tenant boundary,
so there is no external server to secure
and no authentication handshake across a network boundary.
Identity is handled by Enter directly.
The component runs with the user's credentials
in the user's context.
Permissions are enforced through your existing SharePoint permission model.
If you don't have access to a list,
the component won't fetch data from it.
If you can't modify something, the button will be disabled.
That's not a separate security layer
that's your existing permission model being applied automatically.
Audit logging is built in.
Every interaction with an SPFX component in co-pilot gets logged
to purview the same way any other SharePoint action does.
You don't need to instrument custom logging.
You don't need to correlate logs across systems.
The audit trail is unified because the execution is unified.
The reuse story is what makes this actually practical at scale.
If you spent the last five years building SPFX webpots
for your internet like a dashboard for project status
or a form for incident reporting,
you don't throw those away.
You surface them in co-pilot.
The component code doesn't need to change
because you aren't rewriting from scratch.
You're exposing what you already have.
That's a massive practical advantage.
You inherit five years of refinement,
five years of performance optimization,
and five years of user feedback baked in.
You're not starting a new technical project.
You're using an existing asset in a new context.
The licensing alignment reinforces the simplicity.
SPFX co-pilot apps are licensed
through the standard M365 co-pilot seat.
There's no additional SKU.
There's no consumption-based billing
where component interactions get metered.
You made the decision about who gets the $30 per month license
and that decision automatically extends to SPFX co-pilot apps.
Every person with a co-pilot license can interact
with every SPFX component.
The licensing model is clear and predictable.
But there's a constraint you need to acknowledge.
SPFX is fundamentally locked into the Microsoft 365 ecosystem.
It doesn't work with Claude.
It doesn't work with ChatGPT.
It doesn't work with any AI platform
that doesn't understand SPFX.
If you're building for maximum vendor portability
or if you're planning to use the same integration logic
across multiple AI systems, SPFX constrains you.
That's not a bug.
It's a trade-off.
The use case fit is where you see this play out.
SPFX co-pilot apps excel at internet orchestration,
which means surfacing company news, organizational information
and employee resources directly in Chat.
They excel at knowledge management
by bringing documentation, FAQs,
and procedural guides into the flow of work.
They excel at list-driven workflows
like approvals, requests, and status updates
where the data lives in SharePoint lists.
They excel at document-centric actions,
allowing someone to search, preview, and modify documents
without leaving the conversation.
Anywhere SharePoint is already the system of record.
SPFX is the natural path.
Where they don't fit is scenarios where your data
is scattered across multiple platforms
and you need a single integration layer that works everywhere.
That's the MCP scenario.
That's where you need the flexibility of an external server
and the portability of a vendor neutral standard.
So when you're standing at the fork in the road,
deciding whether to build MCP or build SPFX,
you're not actually choosing between two equally flexible options.
You're choosing between two completely different governance philosophies.
The governance trade-off.
So here's where we get concrete about the decision you're actually making.
There's attention sitting underneath this entire choice
and it determines everything that comes after
MCP offers flexibility.
SPFX offers assurance.
Those two things point in opposite directions
and where you land on that spectrum depends entirely on
what your organization can actually afford to govern.
That's unpack what governance actually means in each scenario.
With MCP, you're managing a new integration boundary.
Your server sits somewhere, whether it's in Azure,
your own data center, or managed by a vendor.
The moment you deploy it,
you've created a new place where secrets need to be stored and rotated.
O-auth credentials, API keys, certificates for mutual TLS.
All of that is your responsibility now.
You can't delegate that to Microsoft.
You can't inherit it from the platform.
You have to own it.
Identity propagation becomes your problem too.
When co-pilot calls your MCP server,
it needs to pass along the user's identity
so that your server can enforce the right permissions on the right data.
That handoff has to be set up correctly.
A misconfiguration means users see data they shouldn't,
or legitimate requests get blocked.
Audit logging spans two systems now.
Co-pilot logs what it did.
Your MCP server logs what it did.
But those logs are separate.
If you need a complete forensic trail of what happened,
you're correlating logs from two different places.
And you need to make sure that correlation is actually possible,
ensuring that timestamps align and user identities match
so the story is coherent.
If your MCP server calls external APIs,
like pulling data from Salesforce or an ERP system,
you need to implement DLP at the API level.
You need custom logic that says,
don't return this field because it's sensitive.
Or don't allow this combination of data flows
because it violates compliance.
That's not something Microsoft can do for you.
That's code you write.
All of this requires security engineering expertise.
Not I know how to configure Azure AD.
Not I understand how to manage SharePoint permissions.
This is I know how to build secure API integrations
with proper credential rotation and audit trails.
That's a different skill set.
SPFX has a different governance surface.
You're not managing a separate security boundary
because there is no separate boundary.
Your components run inside your tenant.
Identity is handled by Android permissions flow from SharePoint.
DLP policies that you've already set up apply automatically.
Audit is built in.
You're not solving new problems.
Your extending governance that already exists.
Your governance requirements are different.
You need to control who can deploy to the app catalog.
You need SharePoint governance discipline,
which means making sure permissions are structured correctly,
data is classified,
and your sensitivity labeling is consistent.
You need to enforce your existing policies rigorously
because the component will inherit them.
But you're not inventing new governance layers.
This requires SharePoint expertise and governance discipline.
Not I know how to write OAuth flows.
This is I understand how SharePoint permissions work
and how to structure a site hierarchy
that actually matches your compliance requirements.
Here's where organizations get stuck.
Someone MCP's flexibility,
but can't afford the security overhead.
They don't have the infrastructure,
the expertise,
or the governance maturity
to manage external integration securely.
So they look at MCP and realize
it's not actually an option for them.
Others want SPFX's assurance
but lack the SharePoint governance foundation.
Their sites are overshared,
their data is unclassified,
their permissions are flat,
they look at SPFX and realize
they can't safely expose their components in co-pilot
because the governance underneath is too weak.
The decision framework is simple.
If your data lives in SharePoint, use SPFX.
Get your governance house in order.
The investment pays itself back in operational simplicity.
If your data is scattered across systems, use MCP.
But budget for the security investment is not optional.
Some organizations do both.
They use SPFX for SharePoint centric workflows
and MCP for cross-system orchestration.
But that requires dual governance models.
Two security patterns, two audit frameworks.
That's only sustainable
if you have the organizational maturity to manage it.
The core insight is this.
The agent fabric isn't one solution.
It's a framework that chooses based
on your governance constraints.
And understanding those constraints right now
determines whether you're building something sustainable
or something you'll have to remediate later.
The death of TeamsFX and the consolidation.
There is a deprecation notice sitting in the documentation
that most organizations haven't even registered yet.
The TeamsFX SDK is going away.
It will be fully retired by July 2026.
If you have TeamsFX solutions running in production right now,
you need to understand exactly what that means
and why Microsoft is making this move.
TeamsFX was originally positioned
as the primary way to build Teams apps.
It was an attempt to create a simplified developer experience
for building custom applications
that lived specifically inside the Teams client.
Instead of dealing with the full complexity of the SharePoint framework,
you could use TeamsFX to get templates
and a much lighter toolkit.
It made sense at the time
because Teams was exploding
and every organization wanted to build custom experiences
for their channels.
TeamsFX was supposed to make that easy,
but the enterprise moved in a different direction.
And that movement is what is killing TeamsFX.
The shift is fundamental.
Organizations stopped thinking about Teams apps
as a distinct category
and started thinking about co-pilot apps instead.
These are experiences that operate
through the AI orchestration layer
rather than through a specific surface like a Teams tab.
That is a different architecture entirely.
The moment that shift happened,
maintaining two separate frameworks
like SPFX and TeamsFX became unnecessary overhead.
Here is what it means practically.
If you built a request approval app in TeamsFX,
that app lived inside a specific Teams channel.
Users had to navigate to the channel,
open the app and fill out a form
for the request to go through.
It worked, but it only worked inside Teams.
It was not discoverable through co-pilot,
it was not accessible through SharePoint
and it did not participate
in the broader orchestration layer.
It was a single surface solution.
SPFX co-pilot apps changed that equation.
The same approval experience
can now surface inside co-pilot,
inside SharePoint,
or inside the Microsoft 365 app.
You build the logic once
and surface it everywhere the organization needs it.
That is not just a marginal improvement.
It is a different value proposition entirely.
From that perspective,
maintaining TeamsFX as a separate framework
no longer makes sense.
The framework that can do everything
is the one you want to standardize on.
So TeamsFX is being deprecated.
If you have it in production, you have two paths.
You can rewrite for SPFX 1.24
to gain all that multi-surface capability.
Or you can migrate to Power Apps.
If your solution is heavy on business logic
and light on custom UI,
Power Apps is getting much better
at building structured applications
and it integrates directly
with co-pilot studio for orchestration.
The timing creates real pressure.
July 2026 is the hard deadline
and that is not as far away as it sounds.
If you have a production TeamsFX application right now,
you have roughly a year to decide on a path
and execute the migration.
Delaying does not make sense
because the work won't get easier if you wait.
The sooner you move,
the sooner you can take advantage of the capabilities
that come with the new architecture.
But here is what actually matters about this.
The TeamsFX deprecation is not just a technology problem.
It is an opportunity because the forced migration
is exactly the moment to re-architect
how you think about these solutions.
Instead of just patching your existing app
and moving it to SPFX,
you can step back and ask
what the application is actually trying to do.
Is it better modeled as an SPFX component exposed
through co-pilot?
Is it actually a business process
that belongs in Power Apps
with governance-driven automation?
Does it need to orchestrate across systems?
Which might mean building an MCP server instead?
The people writing TeamsFX code right now
are about to make a career inflection point decision.
You can upskill to SPFX
and become an agentex UX developer
who builds the interactive components
that operationalize enterprise intelligence.
That is a growing market where all the investment is going.
Or you can pivot toward Power Apps
and become a business process architect.
That is also a massive growth area
but you cannot stay in TeamsFX
that door is closing.
And that closure is a signal
about the bigger structural shift.
Microsoft is consolidating its extensibility stack.
The future is not multiple frameworks for multiple surfaces.
It is unified orchestration through the agent fabric
with SPFX as the primary mechanism
for interactive components and Power Apps
as the primary mechanism for business logic.
That consolidation makes sense.
It reduces complexity
and aligns everything around a coherent architecture.
It reveals what the next generation
of enterprise development actually looks like.
The security hardening,
CSP enforcement and beyond.
There is another date on the calendar
that matters just as much as the TeamsFX deadline.
And it is going to break a lot of assumptions
about how you have been building SPFX solutions.
On March 1st, 2026,
Content Security Policy Enforcement moves
from report-only mode to enforced mode in SharePoint Online.
What does that actually mean?
Right now, if an SPFX solution loads a script from a CDN
that is not on the approved list,
SharePoint logs the event.
It reports it but it does not block it.
The script still runs and the solution still works.
You might get a warning in the console
but nothing actually breaks for the end user.
Starting March 1st, that changes.
Inline scripts will be blocked outright.
External scripts will have to be explicitly registered
as trusted script sources
in the SharePoint Admin Center.
If a script is not on that approved list,
the browser will simply refuse to execute it.
The violation will get logged in per view audit
so you can see what was attempted
but the code itself will not run.
This matters for SPFX
because many existing solutions rely on loading libraries
from external CDNs like JQuery
or specialized charting helpers.
If those sources are not pre-registered as trusted,
they will stop working and the solution will break.
Users will see incomplete functionality or errors on the page.
It is not just a security issue at that point.
It is a total loss of capability.
If you have SPFX solutions in production right now,
you need to audit your dependencies immediately.
You need to know what external scripts you are loading
and where they are hosted.
This is the work that must happen between now and March 1st.
If you discover a dependency that is not trusted,
you can register the source, move the code to a trusted host
or refactor the solution to eliminate the dependency entirely.
But you have to know about it before the enforcement date hits.
The governance implication is what makes this architectural.
CSP is becoming a central control
for what code can execute in your tenant.
Microsoft is not just blocking random scripts.
They are enforcing a white list of approved sources.
That is a governance model that applies uniformly
across the entire tenant.
Here is where the SPFX security model is actually quite elegant.
SPFX solutions do not run with elevated privileges.
They run with the user's identity and permissions.
When a component executes, it can only do what that specific user is allowed to do manually.
The security boundary is the user's permissions,
not the code's privileges.
That is different from systems where code runs with service account privileges,
which would be much riskier.
SPFX is delegation based by design.
The code inherits the user's permission context.
But here is the part that matters.
CSP controls whether code runs at all,
while DLP controls what that code can do with data once it is running.
You can build an SPFX component that is perfectly CSP compliant
where every script comes from a trusted source.
But that component could still send data to an external API
if the browser can reach it,
and your DLP policy does not block the traffic.
CSP does not prevent data exfiltration.
It only controls code execution.
Those are two different layers of the stack.
So the real security question is not just whether your solution is compliant with CSP.
The real question is where that code can send data
and whether you have restricted those flows with DLP.
The mitigation layers are very specific.
First, you must classify your data systematically
because you cannot protect what you haven't identified.
Apply sensitivity labels to high-risk content
and configure DLP policies that are scoped to co-pilot interactions.
If you have a policy that says not to share data with external systems,
make sure it applies when data flows through co-pilot.
Monitor external API calls from your SPFX components.
If you see requests going to domains,
you do not recognize you need to investigate them.
This is where security becomes a first-class design concern
rather than an afterthought.
You are no longer just asking if a component works.
You are asking where that component sends data
and if that flow is authorized.
The CSP Enforcement Deadline is a forcing function.
It makes you audit your scripts, discover your dependencies
and register what is trusted.
By doing that, you build the governance discipline you need
for the agent fabric to work safely at scale.
Governance first, the permission audit.
You've decided to move forward with the agent fabric.
You've picked your architecture, SPFX, MCP, or a mix of both.
You've mapped out the licensing.
You've hardened your CSP.
Now comes the part most organizations try to ignore
because it isn't flashy or technically elegant.
Before you turn on co-pilot for everyone,
you have to know what your SharePoint actually looks like.
Not the clean version you have in your head,
but the messy version that exists in reality,
this is the audit phase.
And it is not optional.
You start in the SharePoint Admin Center
with Data Access Governance Reports.
You aren't looking for tiny individual errors here.
You're looking for structural patterns.
When you run that DAG report,
look closely at the distribution of access.
You'll see exactly which sites are shared with too many people,
where inheritance is broken
and where external sharing is wide open.
What you're hunting for are sites that are broadly shared for no reason.
Maybe it's a project site shared with everyone in the organization
because a consultant needed a file four years ago.
Maybe it's a finance folder left open to everyone
because managing groups felt too slow.
Maybe it's a classified library sitting inside a research site
with default permissions that let anyone wander in.
These aren't security breaches in the traditional sense.
They're permission drift.
It's a slow accumulation of access that stays invisible
until something forces you to look at it.
Co-pilot forces you to look immediately.
Once you find these overshared sites,
you have to follow a specific sequence to fix them.
First, you kill the broad sharing.
Everyone becomes a specific group
and anyone with the link becomes people I explicitly approved.
You aren't changing the content itself.
You're just fixing the boundary of who can see it.
Second, you layer in restricted access control
for your most sensitive sites.
Think of RAC as a fortress mode,
where you explicitly state that only specific groups can enter
and no one else can be added without a major escalation.
You use this for the high-risk stuff.
Mergers executive strategy or sensitive financial data
where you need absolute certainty.
Third, you use restricted content discovery
to hide certain sites from co-pilot entirely.
If a site is already locked down,
but you want an extra layer of safety,
you tell co-pilot not to index it at all.
Users can still find those files through a normal search,
but co-pilot will never use them as a source for an answer.
Then comes the labeling.
This is where you define what your data actually is.
You deploy sensitivity labels,
like confidential, internal, or public,
and you make the mandatory.
New documents can't be saved without a label,
and existing files get classified through automation
or manual review.
For the highest risk data, you apply encryption.
If a document is labeled confidential and encrypted,
only specific users can actually read it.
Co-pilot can still index the file for search,
but the actual content stays protected
behind that encryption layer.
Your DLP strategy sits on top of this.
You create policies specifically for co-pilot interactions,
like a rule that blocks the AI
if it tries to touch a document containing social security numbers.
You start an audit mode to watch the patterns without breaking anything.
And after a few weeks of monitoring the logs,
you move to active blocking.
This isn't a one-time project.
It's a baseline you have to maintain.
You should be running DAG reports every quarter
and checking your DLP match rates constantly.
If you see a spike in violations for a specific team,
you investigate and tighten the screws.
The timeline is the most important part here.
You need this foundation solid before co-pilot goes wide,
because once the AI is out there,
trying to retrofit governance is almost impossible.
The agent fabric, what it actually means.
Now we need to name what we're actually building,
because the licensing, the architecture,
and the permission audits all lead to one place, the agent fabric.
People use that term a lot and usually it's pretty vague.
So let's be concrete about what it is, how it works,
and why your governance foundation matters
to every single layer of it.
The agent fabric is the infrastructure
that lets AI agents work across your business
while respecting your boundaries.
It isn't a way for AI to bypass your security.
It's the system that forces AI to operate inside of it.
The components are very specific.
Identity is the floor.
Entra ID, that's where you verify who the user is.
Authorization is the next layer.
This isn't just checking a group membership.
It's checking SharePoint permissions,
sensitivity labels, and DLP policies.
Every time an agent touches data, the system checks if it's allowed to.
Ordered is the memory.
Microsoft Perview logs every tool call
and every action the agent takes.
This isn't for compliance theatre.
It's so you actually understand what the system did and why it did it.
Orchestration is the engine.
This is co-pilot, power automate, or co-pilot studio.
These platforms are the interface between what the human needs
and what the tool actually executes.
But here's the reality most people miss.
An agent doesn't think of itself as an agent.
It isn't a separate autonomous entity.
It's just a co-pilot instance with access to a toolbox.
Those tools might be SPFX components in your tenant,
MCP server sitting outside, or power automate flows.
But to the agent, they're just functions it can call.
You ask a question.
The agent reasons through it.
It decides it needs a specific tool to answer you.
It calls that tool.
The tool sends back data or an interactive card
and the agent shows it to you.
You click a button, the result flows back,
and the agent finishes its thought.
That cycle is the agent fabric in action.
The governance model is the only thing that makes this safe for a real company.
Every action is logged, every call is audited,
and every piece of data is permission trimmed.
If the agent tries to grab a file you aren't allowed to see,
the permission check fails instantly.
The tool returns nothing,
and the agent can't show you the secret.
And none of this happens without you.
If an agent is supposed to update a list or modify a document,
there are checkpoints.
You build in approval steps
so the agent can't act unilaterally on your behalf.
Why does this matter?
Because this is the shift from chat to orchestration.
The old model was simple.
You type a question, get some text back,
and then you go do the work yourself.
The interface was conversational,
but the actual execution was manual.
You had to leave the chat to get anything done.
The agent fabric changes that.
You're still talking to an agent,
but now the agent can actually move the gears.
It surfaces interactive components right in the chat
so you can finish a task without switching tabs.
The distance between "I need to do this"
and "this is done"
drops from hours to seconds.
The business outcome is obvious.
Workflows that used to take half a day
now take five minutes.
Data lookups that require digging through folders
now just appear.
Status updates that used to mean opening
three different systems now happen in one click.
But there is a catch.
If your governance is weak,
the agent fabric won't fix it.
It will amplify it.
Bad permissions become visible the second you turn this on.
Poor data classification becomes a total blocker.
Missing audits become a massive liability.
That's why governance has to come first.
The agent fabric is a powerful engine,
but it only works if the tracks are laid down correctly.
If this shift from chat to orchestration
changed how you think about AI.
Follow me, Mucopeter's on LinkedIn,
and if you want more of this,
leave a review.
It helps more people find the show.
Share this with your team,
especially if you're dealing with these permission issues right now.
Why governance must precede architecture?
The entire framework breaks if you get the sequence wrong.
Most organizations make this mistake when they start.
It looks like this.
You get budget approval for co-pilot licenses.
You're excited about the productivity gains.
You buy the seats.
You enable the feature.
You train a few teams.
And then you wait for the ROI to show up,
but it doesn't.
Teams use co-pilot for a few weeks and the novelty wears off.
Adoption plateaus.
You're paying for licenses that people aren't actually using.
The ROI story just evaporates.
The reason this happens
isn't because co-pilot doesn't work.
It's because you skipped the prerequisite.
You tried to build the architecture
before the governance foundation was in place.
And without that foundation,
the architecture becomes a liability instead of an asset.
When I say governance foundation,
I'm not talking about a compliance checkbox.
So I'm not talking about a policy document that sits on a shelf.
So I'm talking about an operational reality.
It means your permissions are actually clear.
You can look at a site and know exactly who should have access
and who shouldn't.
It means your sensitive data is classified
so you know what needs protection.
It means you have DLP policies that actually prevent violations
instead of just logging them after the fact.
That means your audit trail is complete and trustworthy
when you have that foundation.
You can build the agent fabric on top of it with confidence.
When you don't, you're building on sand.
The sequence is non-negotiable.
Governance first, then architecture,
then implementation, skip governance,
and everything else becomes fragile.
There is a structural problem that makes this harder than it sounds.
Most organizations built their sharepoint
around a permission model that made sense 10 years ago.
It's flat.
The default is broad access.
Everyone in the organization gets access to most sites.
That model works fine when people are navigating manually
and searching for content.
But it breaks immediately when you introduce an AI system
that can surface any content to any user
with a single prompt.
At the same time, compliance requirements have gotten more sophisticated.
You have regulations that say certain data can only be accessed by certain people.
You have internal policies that say executive strategy documents
shouldn't be visible to operational staff.
So you have a structural mismatch.
Your permission model is flat.
Your compliance requirements are hierarchical.
For years, people could work around that gap
because navigation was manual.
You'd search for something, find some documents, and move on.
If you stumbled onto something you shouldn't see,
it wasn't a systemic problem.
Copilot makes that gap visible immediately.
Suddenly, data that was technically accessible
but practically hidden is one prompt away.
The friction of navigation and search,
the thing that was actually protecting compliance,
disappears.
The fix requires months of work.
You implement restricted access control on sensitive sites,
so access is explicit and limited.
You apply sensitivity labels to data
so you know what needs protection.
You use restricted content discovery
so certain categories of data aren't indexed by copilot at all.
This work can't be rushed.
It requires IT to understand the permission structure.
It requires security to understand the compliance requirements.
It requires business to weigh in on which data is sensitive.
It's not a technical project.
It's an organizational alignment project.
The cost is real.
It's budget.
It's time.
It's cross-functional meetings.
It's decisions made and remade.
And here's the hard part.
The July 1st licensing deadline
doesn't care whether your governance foundation is ready.
The deadline is coming regardless.
So you face a choice.
You can invest in governance now,
which means delaying your copilot rollout
by several months
but setting yourself up for real value.
Or you can ignore governance and rollout copilot broadly today
knowing that you'll either get minimal adoption
or worse.
You'll discover compliance problems
that force expensive remediation.
That's the decision point.
And it has to be made consciously, not accidentally.
The developer career inflection.
For a decade, the job title was clear.
You were a SharePoint developer.
Or maybe a team's developer.
Your work was about building interfaces.
You took business requirements
for what the page should look like.
The flow the user should follow
and the data that should display.
You build React components.
You called APIs.
You deployed to the app catalog.
Your success was measured by whether the interface worked
and whether people used it.
That role is about to become something
fundamentally different.
Not because the technology changed,
but because what the organization needs
from developers changed.
Building an SPFX component for a SharePoint page
is about UX.
How does the user navigate this interface?
How is the data organized visually?
Those are legitimate technical questions
and answering them well matters.
But they're bounded questions.
The component lives in a specific place.
It serves a specific purpose.
Building an SPFX component for the agent fabric
is about something else entirely.
You're not designing an interface for human navigation.
You're designing an orchestration point
where an agent can call your code
and execute business logic.
That changes every decision you make.
Consider a simple example.
You built a web part that displays a list of pending approvals.
The user sees a nice grid with filters and sorting.
They click "Approve" or "Reject".
The action gets recorded.
That's a well-designed SPFX component for a page.
Now expose that same component in co-pilot.
The agent is calling it.
The user asks co-pilot a question.
The agent reason that showing pending approvals
would help answer that question.
Now your component is rendering inside a conversational interface.
The user can still click to approve or reject.
But the context is different.
The agent is going to interpret the user's decision.
The agent is going to decide what to show next.
Your component is now part of a larger orchestration flow.
That requires different thinking.
You need to understand what data the agent might pass to your component.
You need to handle edge cases where the agent's reasoning
led to your component being surfaced in an unexpected context.
You need to think about how your component reports back to the agent.
Not just the user clicked "Approve",
but what does that approval mean in the context of the larger workflow?
More importantly, you need to understand governance.
When your component executes, whose permissions is it running under?
What data is it allowed to access?
If the component tries to fetch data,
the user shouldn't see what happens.
That's not a UX question.
That's an authorization question.
And it's now your responsibility.
Most SPFX developers today understand React.
They understand the SharePoint Rest API.
Fewer understand identity propagation.
How to verify that the user running the component is actually the user they claim to be.
Fewer understand DLP policies
and how to design a component that respects them.
Fewer understand audit logging and how to instrument their code
so governance teams can see what it did.
Those aren't optional skills anymore.
They're table stakes for building in the agent fabric.
That's the skill gap.
And it's a real one.
But it's also an opportunity.
Because organizations desperately need developers who can bridge that gap.
They need people who understand both the technical side.
How to build React components and the governance side.
How to make sure those components operate safely within compliance boundaries.
The market signal is clear.
Demand for co-pilot app developers or agent architects is growing faster than the supply of people
who actually have those skills.
This is a career inflection point.
You can train yourself now
and you'll be significantly more valuable to your organization in 18 months than you are today.
Or you can stay focused on page level SPFX components
and watch the market move past you.
The training path is straightforward.
Start with SPFX 1.24.
Understand how components render and co-pilot.
Move to MCP and understand when to use it versus SPFX.
Study governance patterns.
Learn how authorization and audit actually work.
Build a component in a test environment that respects permissions and logs its actions.
That foundation prepares you for the work that's coming.
Because the agent fabric doesn't need page developers.
It needs orchestration developers.
The licensing paradox.
Every CFO has the same question on their spreadsheet right now.
Is $30 per user every single month actually worth it?
They want to know what the organization gets for that investment.
But asking that is asking the wrong question.
The real question is both economic and strategic.
What happens if you don't pay it?
Let's look at the math for a thousand person organization.
If you move 30% of your stuff onto co-pilot licenses,
you are looking at 300 people.
At $30 a month that is $9,000 monthly
or $108,000 every year.
For a mid-market company that is a significant line item
that requires real justification and budget approval.
But this is where the analysis usually stops.
Finance asks if the return justifies the spend.
Without a clear way to measure it, the answer is usually we don't know.
So the license gets treated like a cost center.
And in every business, cost centers get minimized.
The deeper math changes the entire conversation.
If those 300 people are the ones who make decisions
and move workflows forward,
their time has a multiplier effect on the whole company.
The ROI calculation isn't about how much faster one person works.
It's about how much value you unlock
when a decision maker cuts their cycle time by 50%.
Think about an operations manager who currently spends four hours every week
on status updates and data lookups.
Through the agent fabric, that work drops to two hours.
That is two hours of brain power freed up every week,
allowing that person to focus on strategy instead of tactical overhead.
Over a year, you have recovered 100 hours of capacity.
If that role costs the company $100 per hour,
you just save $10,000 in productivity for a single person.
When 30% of your staff has a license
and the average recovered productivity is between 5,000 and 15,000 per person,
your return on investment is 10 to 30 times the cost.
Suddenly, the license looks incredibly cheap.
But here is the problem.
That ROI only happens if the licenses go to the right people.
If you hand them out randomly or give them to people
whose roles don't have that decision making power,
the ROI collapses.
You are paying for tools that aren't generating value.
That is the paradox.
The strategic decision isn't whether you license everyone.
You can't. The budget won't allow it.
And most people don't actually need it yet.
The real decision is figuring out who needs it most
and what value you unlock when they have it.
You have to be specific.
Start with roles that make high-frequency decisions.
Operations teams managing resources,
project managers coordinating across departments,
customer service leaders, handling escalations.
Finance teams managing approvals.
These are the spots where AI-driven decisions create
compounding value for the business.
License those roles first and then measure what happens.
Did the time it takes to make a decision actually go down?
Did the quality of those decisions improve?
Did you see fewer compliance violations?
You need to know if people are actually using the tools
or just treating them like a new toy.
Once you have the data, you expand to the next tier of roles.
You show the organization what became possible
and look for where else that patent fits.
You grow the license based methodically,
based on real measurement rather than just hoping for the best.
Timing makes this even more urgent.
On July 1, Microsoft is changing the rules.
Copilot features inside Office Apps will be restricted
to paid licenses and prices are going up.
If you wait, you aren't just delaying the benefits.
You are going to pay more per seat when you finally move forward.
The cost of waiting is compounding every month.
The work of building your foundation
and identifying the right roles needs to happen in the next few months.
Not next year.
That is the paradox.
The license isn't cheap.
But the cost of doing nothing is much worse.
The measurement problem.
How do you know it's working?
You have made the investment,
you built the architecture and deployed the components.
The agent fabric is finally running.
Now comes the question nobody wants to ask
because the answer is difficult.
Is this actually working?
Most people reach for the metrics they already know.
They look at engagement rates, daily active users,
or how long a session lasts.
These are the numbers that work for social media
or consumer apps.
They tell you if people are showing up.
But they tell you nothing about whether the agent fabric
is actually delivering.
The agent fabric isn't there to entertain your employees.
It is there to move work forward.
The metric that matters isn't how long someone stayed inside co-pilot.
It's how much faster they finished the task they were trying to do.
A traditional productivity metrics miss the point entirely.
You can have high engagement where people spend hours in co-pilot
and still be wasting time.
The interface might feel smooth and the chat might feel natural.
But if nothing gets done faster, it is just elegant friction.
It isn't progress.
The measurements that actually matter are operational.
Take time to decision.
How long does it take from the moment a request arrives until it is approved?
In the old model, that might take two hours.
You get an email, you navigate to a system,
you find the request, you review it,
and then you click approve.
The time is measured in hours because navigation and context switching
are built into the process.
In the agent fabric, you just ask co-pilot for pending approvals.
The component appears right there.
You click approve and you're done.
The time to decision is now measured in seconds.
That compressed timeline adds up across the whole company.
If 50 approvals happen every day,
and each one saves 90 minutes of clicking around,
you just freed up 75 hours of capacity in a single day.
Over a year, that is 1,500 hours.
That is how value becomes concrete.
You also need to look at the task completion rate.
How many tasks start in the agent fabric
and actually finish without the user leaving the screen?
In the old way of working, a task involves three different systems.
You check a status here, update a list there,
and send a notification somewhere else.
Users often quit halfway through because the friction is too high.
In the agent fabric, the component handles all those systems at once.
The task finishes right in front of the user
and your completion rates go up.
Error reduction is another huge factor that people overlook.
When users have to jump between systems, they make mistakes.
They update the wrong line because they lost their place
or they approve something they shouldn't
because they didn't have the full picture.
The agent fabric solves this by showing exactly
what is needed to make the right call.
It flags risks and highlights missing info.
When errors go down, your operational and compliance value goes up,
then you have the governance metrics.
Are all the actions being logged?
Can you trace exactly who did what?
Are the permissions being respected?
If someone tries to see data they shouldn't,
does the system actually stop them?
You need to know if there are audit gaps
where actions are happening outside the lines.
These questions determine if your system is controlled
or just a faster way to break the rules.
Risk metrics show you if your governance is actually holding firm.
You need to track how many unauthorized access attempts were blocked
and how many data leaks were prevented.
You need to see if permissions are creeping upward over time
or staying tight.
These numbers tell you if your foundation is preventing bad outcomes
or just recording them after they happen.
The framework for this measurement has to start
before you turn anything on.
You need to establish your baselines now.
Document how long a typical decision takes today.
Record how many tasks never get finished
and what your current error rate looks like.
Six months after the agent fabric is live,
run those same tests again.
The difference between those numbers tells you what changed.
More importantly, it tells you if those changes match your goals.
If your decision time dropped by half
but your error rate stayed the same,
you have speed without safety.
You need to investigate why.
Maybe the governance controls missed something
or the component is showing incomplete data.
If people are finishing tasks faster
but compliance violations are spiking,
you are moving in the wrong direction.
You have to recalibrate, tighten your data protections
and add more checkpoints.
You might even need to slow down to make sure you are moving safely.
Measurement is what reveals the truth.
It cuts through the hype and shows you the structural reality
of your business.
That is where real improvement actually starts.
The organizations that will struggle.
A clear pattern is emerging in organizations piloting co-pilot right now.
It is worth naming because you might be seeing it in your own office.
The companies struggling the hardest are not failing
because the technology is broken.
They are struggling because their governance foundation is fractured.
Weak governance is easy to spot once you know what to look for.
It looks like overshared sites where access was never tightened
after the first deployment.
It looks like unclassified data sitting inconsistently across the tenant
where some folders have labels but most do not.
You see it in DLP policies that only exist as templates nobody ever configured.
Permission models vary wildly from one side to the next
because there is no central standard.
Audit practices log events into a black hole
because nobody defined what actually matters to monitor.
This mess is invisible when people navigate manually.
A user searches for a document, finds it and moves on.
If they stumble into something they should not see,
it is just an isolated incident.
Nobody traces it back to a systemic permission problem.
The friction of discovery actually provides a layer of protection.
You have to actively look to find overshared content
and most people simply do not bother.
Co-pilot changes that equation instantly.
The moment you enable co-pilot in an organization with weak governance,
you have created a discovery engine that operates at machine speed.
A user asks co-pilot for sales forecasts
and the engine searches across the entire tenant to find them.
It finds them in the main sales site which is appropriate
but it also finds them in the shared CEO folder
because that site inherits permissions from its parent.
It finds them in a departmental sharepoint site
that was supposed to be restricted but never was.
It even finds them in a years old archive site
that still has default company-wide access.
Data that was technically accessible but practically hidden
is now surfaced in seconds.
The security and compliance teams notice this immediately.
They see the data flow, they see the risk, and they panic.
The response is predictable.
They block co-pilot access to sensitive sites.
They refuse to index entire categories of data.
They restrict co-pilot to a tiny white list of approved sites
instead of letting it search broadly.
In some cases, organizations simply refuse to enable co-pilot at all
because the risk feels too high.
The result is organizational paralysis.
You have bought the licenses, you have trained the teams,
you have announced the deployment.
Now you are telling those teams they cannot use it
or they can only use it in ways that eliminate most of its value.
The initiative becomes a liability.
It costs money and delivers nothing.
Adoption flatlines and the investment becomes a sunk cost.
This creates a 12 to 18 month lag
where the organization is paying for co-pilot
while the technology sits idle.
The licenses keep renewing and the budget stays active
but nothing meaningful is happening.
Security feels vindicated because they prevented a breach.
Business feels frustrated because they were promised capability
and got a sandbox instead.
It is caught in the middle trying to find a compromise
that satisfies both sides.
The cost compounds over time.
During those 18 months, your competitors are moving forward.
They invested in governance first
so their co-pilot deployment actually accelerates their decision making.
Their operations get faster.
They capture efficiency gains.
Meanwhile, your organization is stuck explaining
why you have licenses that nobody can use.
The exit from this trap exists
but only if you start now.
Do not wait for co-pilot to force the issue.
Start the governance work immediately.
Run the permission audits, classify the data,
implement the DLP policies, build the controls.
It is slower in the short term
and it requires everyone to get on the same page.
It takes months.
But by the time SPFX 1.24 reaches general availability
and adoption accelerates, you will be ready.
You will move from concept to production at speed.
You will capture the gains while competitors
are still arguing about permissions.
The choice is clear.
Govern now or struggle later.
The organizations that will win.
Contrast that with the organizations
making different decisions right now.
They are not waiting.
They are not stuck in permission audits and compliance debates.
They are already moving through that work methodically
because they treat it as a prerequisite.
What is different about their approach?
They have accepted that governance is not a friction point to minimize.
It is the foundation that makes everything else possible.
They are building it deliberately.
They run data access governance reports
as an operational baseline rather than a one-time exercise.
They classify their data because they understand
that classification enables automation.
They implement DLP policies
because they know those policies will eventually govern
how the agent fabric operates.
They build discipline across IT security and business
because they know this is not a technical project
for security to own an isolation.
That cross-functional alignment is what separates them
from the organizations that struggle.
When IT proposes a governance control,
security understands why it matters.
When compliance asks for audit trails, business accepts the cost
because they understand the value.
When business wants to move fast,
IT and security have frameworks in place
that let them move safely.
There is a shared language.
There is alignment on what secure actually means in their context.
That alignment creates momentum.
It is a different pace entirely.
They are not waiting for SPF X1.24 to go live in autumn of 2026
before they start preparing.
They are using the preview period between July and late 2026
to test components and understand how co-pilot surfaces them.
They are training developers on the new model right now.
By the time general availability arrives, they are not learning.
They are scaling.
That timing advantage is measurable.
While struggling organizations are still debating if co-pilot is safe,
these organizations are moving from pilot to production.
They are not dealing with proof of concept friction.
They are dealing with scale challenges
which are fundamentally different problems.
Scale is about infrastructure and monitoring,
which are solvable.
Proof of concept friction is about misaligned governance and fear,
which is much harder to fix.
The competitive consequence becomes visible within months.
These organizations start capturing efficiency gains
that competitors are not even attempting yet.
Their operations teams make decisions faster
because the data surfaces exactly where they need it.
Their project managers coordinate work in half the time
because the agent fabric handles the communication and approvals.
Their customer service teams resolve escalations with better information
because co-pilot synthesizes context from multiple sources.
Meanwhile, the organizations that delayed
are still stuck in the governance debate phase
that efficiency gap compounds.
By the end of 2026, the speed difference is obvious.
By mid-2027, it is undeniable.
These organizations have built organizational muscle
around the agent fabric.
Their teams know how to work with it.
Their governance controls are running routinely,
not as special projects.
Their data is classified, their permissions are tight,
and their audit trails are complete.
They are operating in the new model,
while competitors are still planning to transition.
The talent dynamics shifts too.
These organizations become known as places where the technology actually works.
You can build something and actually use it in production
without fighting restrictions.
That reputation attracts developers and architects
who want to work on modern infrastructure.
They want to build a GEN-TIC UX instead of old-page components.
They want to solve governance problems
instead of fighting compliance blocks.
The talent advantage becomes self-reinforcing,
better talent builds better systems
and better systems attract more talent.
The business outcome is measurable
in ways that go beyond simple metrics.
These organizations improve their compliance posture
because their controls are tight and well integrated.
They achieve real ROI on their co-pilot investment
because they are actually using it productively.
They reduce operational risk
because decisions happen with better data
and complete audit trails.
They build institutional knowledge about how to operate
at the intersection of innovation and control.
By 2028, when the market has fully caught up
to the architectural shift,
the gap will be visible in every metric.
It will not be theoretical.
It will be measurable in decision cycle time
in project completion rates and in ROI per license.
The organizations that prepared now are ahead,
the organizations that delayed are playing catch-up.
This reckoning clarifies what is actually at stake
in the decisions you make right now.
The structural inevitability.
The question isn't whether this shift happens,
it's whether you're ahead of it or behind it when it does.
The forces pushing us toward the agent fabric
aren't just trends, they're structural.
For years, text has been the bottleneck for complex work.
You type a question, you get back a wall of text,
then you have to leave that interface
just to actually do something with the information
that workflow works for simple things,
like asking what time a meeting starts.
But it breaks the moment you need to make a decision
or finish a multi-step task.
The technology to fix this isn't a dream.
It exists right now.
We have interactive components living inside the co-pilot canvas.
We have SPFX rendering directly inside agents.
We have MCP servers that can expose tools and UI
at the exact same time.
These aren't ideas for the future.
They're in preview today.
And they'll be everywhere within the next six months.
When you have the tech to remove friction,
economics takes over.
Organizations using these tools move faster.
They make better decisions because their data is actually useful.
They get more done in less time.
They also lower their risk because their governance
is built in and easy to audit.
In a competitive market, that speed becomes a massive advantage.
Some companies will grab it early.
The rest will be forced to play catch-up just to stay alive.
The timeline is already set.
In July of 2026, licensing changes will turn embedded co-pilot
in office into a paid feature.
By late 2026, SPFX 1.24 and SharePoint co-pilot apps
will be fully available to everyone.
By early 2027, the companies that invested in their architecture
won't be testing anymore.
They'll be operating.
They'll be running real workflows through the agent fabric.
They'll be making decisions in minutes
that used to take your team hours.
This shift changes what we consider normal.
New companies entering the market
won't have to learn this model.
They'll just adopt it as the standard way of doing business.
The pioneers won't just have a head start on speed.
They'll be the ones who wrote the rules on governance
and architecture that everyone else has to copy.
The impact ripples through every role in the company.
Jobs built around just finding data are going away.
Jobs that require real-time decision making
are becoming the most important roles you have.
The developer market is shifting from building pages
to architecting orchestration.
IT is moving from watching platforms
to engineering governance.
These aren't small tweaks.
This is role extinction and role creation
happening at the same time.
The governance problem is where this hits the hardest.
If you don't invest now,
you'll face a brutal choice in 18 months.
You can spend months doing expensive governance work then,
or you can pay for massive remediation
under pressure when things inevitably break.
The cost of waiting isn't just a slow rollout.
It's the compounding price of fixing a broken system
after an operational failure.
But here's what actually matters.
The first move will set the standard for what works.
By the time SPFX 1.24 is the default way to build apps,
the earlier adopters will have months of proven patterns
already baked into their culture.
They'll know exactly what works.
Competitors who wait will just be copying old home work.
They won't be innovating.
They'll just be following.
The business reality is simple.
At the turning point in late 2026,
the market stops asking if the agent fabric is possible.
It starts assuming it's the standard.
Organizations caught in the middle will lose.
They'll be paying for new technology
without the governance to use it safely.
They'll be stuck in old processes
while everyone else races past them.
Your position in 2028 is being decided by what you do right now.
It's not about the tech.
The tech is solved.
It's about your governance.
It's about whether you build the foundation
that makes this whole architecture possible.
The path forward.
The choice is actually simple.
You can invest in governance now.
Or you can accept a tiny return
on your co-pilot investment while your competitors pull away.
The window is closing fast.
We have the July 1st pricing.
We have the July 2026 preview.
We have the general release in the autumn of 2026
by the time you're hearing this month's have already slipped by.
So start here.
Run a governance audit.
Classify your data.
Set up your DLP policies.
Get your IT security and business teams on the same page.
Then build your agent fabric on top of that foundation.
By 2027, you'll be running the new model
while your competitors are still fighting with the old one.
That isn't just a small win.
It's a total shift in how your enterprise operates.
The technology is just the tool.
The change is structural.
Subscribe for the next episode
where we'll look at the specific governance patterns that actually scale.
And if you're dealing with these challenges right now,
connect with me, Mirko Peters.
On LinkedIn, let's figure this out together.