An organization wants employees to ask an assistant which supplier contracts require review this month. The files live in SharePoint, approval activity happens in Teams and authoritative supplier data lives in a procurement application. Building a standalone chat interface may be tempting, but employees already work in Microsoft 365. The architecture question is whether to extend an existing Copilot experience, add a specialized agent or build an independently hosted application. The answer affects identity, distribution, knowledge scope, cost and who must operate the resulting service.
An employee-facing assistant may belong in Teams or Microsoft 365 Copilot even though supplier records and approval systems live elsewhere. Its extension must preserve SharePoint permissions while relying on a governed business API for authoritative updates. Microsoft AB-100 covers choosing the agent surface, extension mechanism and administration model together, including how organizations approve distribution, revoke access and keep integrations supportable.
Choose the operating surface before the agent technology
If the user is preparing a meeting inside Teams, an extension that works in that context may deliver a better experience than sending them to a separate portal. If the user is approving a high-value procurement transaction in an ERP system, the final action should generally remain in the system that enforces the business rules. One agent can help gather evidence in Microsoft 365 without becoming the owner of the procurement ledger.
List the core surfaces and responsibilities. Teams may provide collaboration and notifications, SharePoint may hold document evidence, Outlook may expose correspondence and Dynamics 365 may own the authoritative customer or supplier record. The agent should use supported connectors and permissions to retrieve information only when needed. A universal bot that copies every source into its own storage creates a wider data perimeter without solving the original process problem.
The distinction between extending and building is economic as well as technical. Reusing supported Microsoft 365 experiences can simplify discoverability and some administrative integration, while a custom application may provide tighter workflow control or an interface tailored to a specialist task. Use the criteria in build-versus-buy decisions to evaluate support ownership, licensing conditions, release control and the ability to meet compliance requirements.
Match extension type to the work it performs
Microsoft documents options such as declarative agents, connectors, plugins and custom applications that use supported Microsoft 365 APIs. An agent whose main task is answering questions from approved organizational documents has different needs from one that requests a purchase-order amendment. A declarative or knowledge-grounded extension may be appropriate for the first; the second needs a constrained action contract and authoritative system validation regardless of where the conversational UI appears.
When assessing an extension, ask where the planning and execution occur. Does the solution use a hosted orchestration layer? Does the builder control the tool implementation? Which parts are managed by Microsoft 365 and which remain the organization’s service to operate? Do not assume a connector grants all the downstream privileges of the human who opened the chat. Each service boundary should have an explicit authentication and authorization design.
Some choices are constrained by feature, license, tenant and region availability, and Microsoft’s admin and publishing guidance can change. A product label alone cannot guarantee a capability is enabled in a particular tenant. Record the supported distribution path, its version and administrative prerequisites as part of the architecture decision. This is especially important when planning an enterprise-wide agent rollout rather than a demonstration for a single team.
Ground in SharePoint without assuming every file is safe
A contracts assistant might retrieve an approved renewal policy alongside supplier-specific agreements. The latter can include legal rates and negotiation terms not visible to every employee. The search path must apply existing access rules before documents reach the model. It should preserve source location, version and effective date so the user can distinguish an older draft from an executed agreement.
SharePoint organizational structure often differs from the way people phrase questions. Two sites may contain a similarly titled document with different authority. A security-trimmed retrieval result can still be misleading if the agent does not know which version controls the transaction. Source owners should define the authoritative library and how superseded records are marked. If the necessary evidence is unavailable, the agent should report the limitation instead of producing a plausible but untraceable commitment.
Copying a SharePoint document into a separate index can remove it from the sharing and retention controls applied at its original location. Grounding and knowledge architecture must preserve permission checks, content freshness and source ownership across that indexed copy’s lifecycle, including when access to the original document is revoked. A correct citation to SharePoint does not by itself prove that the retrieved content was authorized.
Separate collaboration actions from business actions
Posting a Teams notification, drafting a message and changing a supplier contract are not equivalent permissions. A procurement assistant might prepare a comparison document and send it for review in Teams, but the approved amendment should be recorded through the procurement system’s authorized workflow. Tool names and descriptions need to communicate that distinction; a generic “complete supplier request” operation obscures who is committing what.
Apply narrow scopes and backend validation. A user who can read a contract summary should not automatically gain access to the finance system’s supplier master. If the assistant posts on behalf of a user, it must clearly identify what identity the action uses and preserve enough context for investigation. A channel message should not leak data that was retrieved from a restricted private library or another subsidiary.
Exposing a procurement operation through MCP and agent extensibility does not remove Microsoft 365 administration requirements. The extension must be approved, discoverable only to authorized users, revocable if a connector is compromised and capable of reporting an unavailable remote tool without silently broadening permissions.
Distribute agents as governed enterprise software
A pilot that works for its creator is not a deployment plan. Decide whether agents will be shared with a small group, published in an organizational catalog or made available more broadly through supported Microsoft 365 channels. The chosen route affects administrative approval, access management, support and user discoverability. Avoid creating multiple indistinguishable agents with overlapping permissions and similar names.
Treat descriptions as part of the user experience and the governance contract. A sales-support agent should state which business purpose it serves, what sources it consults and whether it can update records. Where several agents might respond to similar requests, document routing and ownership so users are not sent between products indefinitely. Versioning should include instructions, connections, data permissions and tool contracts, not only the agent display name.
The operating model in AI adoption and the Center of Excellence can help manage agent intake, review and retirement. Administrative approval should focus on real differences in consequence: a narrow knowledge agent needs lighter oversight than a channel-connected tool that can disclose confidential accounts or execute a purchase. Mature governance reduces repeated manual effort without giving up the ability to revoke access rapidly.
Test the experience through Teams and the business system
A realistic end-to-end scenario might begin with a Teams request for an expiring supplier agreement. The agent searches permitted SharePoint content, identifies the correct legal entity, creates a draft review task and directs an authorized employee to the procurement application for final approval. The test succeeds only if the source, permissions, task identity and approval state remain consistent. A fluent answer that retrieved another subsidiary’s agreement is a failure.
Include edge cases: a revoked SharePoint permission, a deleted channel, a document renamed after indexing, a connector timeout and two users who belong to different legal entities. Test whether the agent preserves the original caller’s scope after delegation and whether it explains missing data without guessing. Keep the human approval step enforceable when the user jumps from a Teams message to a business application.
Use cross-application agent testing to build regression scenarios for these transitions. A narrow happy-path demonstration cannot validate an enterprise agent; the testing strategy must exercise every trust boundary the architecture introduced, including the deployment and distribution path.
Measure value and plan for change
Usage in Teams is not enough to establish success. Measure whether employees found the correct evidence, whether review tasks reached the intended owner, how often an expert corrected an agent and whether inappropriate data was exposed. Combine those signals with business outcomes such as time to complete a contract review. An assistant that generates many messages but leaves users repeating the same manual step is not delivering the hoped-for transformation.
Plan what happens when a SharePoint site moves, an organizational app catalog entry is retired or a backend API changes. The agent must not silently fall back to a less restricted source because its primary connector failed. Release records should identify versions of knowledge, instructions, connectors and the associated business action service, with a rollback or disable path that administrators can execute.
For AB-100, successful Microsoft 365 extension architecture is not about naming the largest number of Copilot features. It is about choosing the correct user surface, respecting document and action permissions, delivering a maintainable integration and demonstrating that an enterprise task can cross Teams, SharePoint and business applications without losing ownership of its data or approvals.