Your FabrCore Agents, Now in Microsoft 365 Copilot
Your users already live in Microsoft 365. Their questions start in Teams chats and Copilot conversations—not in another browser tab. With the new FabrCore.Services.Microsoft365Copilot addon, the agents you build on FabrCore show up right there: in the Microsoft 365 Copilot Agents rail and in Teams, as first-class custom engine agents. Two lines of code, one configuration section.
The Gap Between "We Have Agents" and "Our Users Can Reach Them"
FabrCore has always made the server side of agents feel solid: Orleans-backed lifecycles, per-principal isolation, ACL, plugins, MCP, observability. But reaching those agents meant your own UI—a Blazor app, a REST client, a WebSocket session. That is exactly right for product surfaces you own. It leaves out the surface your users open every morning.
Microsoft 365 Copilot supports custom engine agents: agents that bring their own orchestration, their own models, and their own infrastructure, surfaced natively inside Copilot and Teams. That is precisely FabrCore's shape. The missing piece was the channel plumbing—Azure Bot Service's /api/messages endpoint, channel token validation, identity mapping, manifest packaging. The new addon makes all of that a hosting detail.
Two Lines in Program.cs
The addon is a standard FabrCore server addon. It plugs in beside AddFabrCoreServer and changes nothing about FabrCore.Host or your agents:
builder.AddFabrCoreServer(new FabrCoreServerOptions
{
AdditionalAssemblies = [typeof(MyAgent).Assembly]
});
builder.AddMicrosoft365Copilot();
var app = builder.Build();
app.UseFabrCoreServer();
app.UseMicrosoft365Copilot();
app.Run();Configuration follows the same philosophy as the rest of FabrCore: one section in fabrcore.json with your bot's Entra registration and which [AgentAlias] answers conversations. Under the hood the addon hosts the Microsoft 365 Agents SDK, synthesizes the SDK configuration it expects, and validates the JWTs Azure Bot Service presents—under a dedicated authentication scheme that never collides with your host's own auth.
Every User Gets Their Own Agent
The part we care most about: identity is not an afterthought. Teams and Copilot stamp the user's Entra identity on every message. The addon maps that identity to a FabrCore principal—the same principal model that scopes agent state, chat history, storage partitions, and ACL everywhere else in FabrCore.
On first contact, the addon provisions that user's agent from your configured template, the same ensure-style provisioning that Blueprints use. The result: every Microsoft 365 user chats with their own agent instance, with isolated history and state, inside their own security boundary. No session bolt-ons, no shared-context leakage between users.
Prefer one shared agent for everyone? Point Agent:SharedAgentHandle at an existing agent such as system:helpdesk—cross-principal messaging then goes through FabrCore's ACL like any other cross-principal traffic.
The App Package Writes Itself
Making an agent visible in Copilot normally means hand-authoring a Teams app manifest—schema versions, bot ids, scopes, icon sizes, copilotAgents declarations. The addon generates the whole package from your configuration instead. Run in development and download it:
GET /m365copilot/manifest.json ← schema v1.22, customEngineAgents bound to your bot
GET /m365copilot/appPackage.zip ← manifest + icons, ready to uploadUpload the zip in Teams or the Microsoft 365 admin center and your agent appears in the Copilot Agents rail with your name, description, and conversation starters. When you configure single sign-on, the manifest automatically gains the webApplicationInfo section Copilot needs for silent token exchange.
Acting as the User, When You Choose To
Identity alone is free—no sign-in prompt. When your agents need to call Microsoft Graph or your own APIs as the signed-in user, configure a user-authorization handler and the addon handles Teams SSO and the on-behalf-of exchange. Opt in with PassUserTokenToAgent and every bridged message carries the user's access token in its Args, ready for a Graph call inside any plugin or tool.
Streaming is on by default for channels that support it: an informative status update while your agent thinks, a typing indicator, and the reply delivered through the channel's streaming protocol with the AI-generated label—with feedback buttons one flag away.
Runs Where Your Agents Run
Nothing about this requires moving your infrastructure to Azure. The FabrCore Host keeps running wherever it runs today—on-premises, another cloud, a container platform. Azure Bot Service only needs a public HTTPS route to /api/messages; during development a dev tunnel from your laptop is enough, and the Microsoft 365 Agents Playground exercises the whole bridge with no Azure resources at all.
The addon ships as a NuGet package, FabrCore.Services.Microsoft365Copilot, alongside FabrCore.Core, FabrCore.Sdk, and FabrCore.Host—and the FabrCore repository includes a distributed fabrcore-microsoft365copilot skill with configuration templates, an Azure provisioning script, and SSO references so your team (or your coding agent) can wire up a host in minutes.
Why This Matters
Custom engine agents change the distribution story for agent platforms. You keep everything that makes FabrCore worth building on—your models, your orchestration, your plugins, your ACL and observability—and you meet users in the tool they already have open. No new app to adopt. No parallel chat UI to maintain for the "just let me ask it in Teams" crowd.
One host, one config section, one uploaded package—and the agents you have been building all along are a Copilot conversation away.
Put Your Agents in Copilot
The documentation covers setup, identity mapping, SSO, the app package, and the production checklist.