Microsoft 365 Copilot is a productivity experience with its own host, identity context, and integration model. Designing an agent to work inside it differs from building a separate web chatbot or a backend automation service. The AB-100 architect must decide whether to reuse an approved Copilot capability, configure a declarative agent, add information through a connector, or build a custom engine when the business requires control the host does not provide. A new agent is not the default answer to every process-improvement request.
Imagine a legal operations team seeking quick answers about contract renewal terms while working in Teams. It wants citations to approved SharePoint documents and the ability to request a renewal review. The reading task needs permission-aware organizational knowledge. The request action needs an authenticated workflow, an audit record, and an authorized approver. Combining them successfully depends on where the agent lives and what it is actually permitted to do, not on a persuasive prompt.
Start with the employee’s host experience
Choose where the work naturally occurs. Teams conversations, Microsoft 365 Copilot Chat, SharePoint content, and Office document experiences have distinct user expectations. An agent launched in a Teams discussion may need to understand thread context; an agent used while reviewing a Word contract may need to cite the specific document version; a SharePoint knowledge experience should not imply permission to modify the underlying site. Define the desired experience before choosing an SDK or connector.
A declarative agent for Microsoft 365 Copilot allows a defined purpose, instructions, knowledge and permitted actions while relying on the Copilot host infrastructure. If the business requires a fully custom interaction, independent hosting, or model selection, compare a custom engine instead. This separation is a design decision, not a ranking that always favors code-heavy implementation.
Decide whether to reuse, customize or build
Inventory existing approved agents and platform features. If a knowledge-answering agent already covers a policy library, extending its authorized scope can be cheaper than creating another isolated instance with different instructions and ownership. But sharing an agent between departments without checking data boundaries can introduce cross-team visibility and maintenance problems. Evaluate who owns its sources, who can approve actions, and how a user knows which agent answered.
Suppose sales staff need a quote summary from an approved account record. Microsoft 365 Copilot may offer relevant work context, while the authoritative price approval still sits in a business application. Reusing the Copilot surface for summary does not mean the model should become the approval engine. Document the missing capability and add a supported action only if the connected system enforces the role, pricing rules, and audit trail.
Ground responses in SharePoint and approved work data
A knowledge source is valuable when its authority and permissions are clear. A SharePoint library might contain both current contract templates and archived drafts. The agent should restrict its retrieval scope, preserve citations to applicable documents, and distinguish the effective version from a superseded one. Do not turn a search result’s fluent summary into a substitute for the signed contract or the owner of the policy. In a dispute, reviewers need to locate the underlying source.
Microsoft documents supported knowledge sources for declarative agents, including certain Microsoft 365 information and connector-backed data. Availability and license requirements vary by capability, so verify them for the target tenant. Retrieval must respect the signed-in user’s entitlement and the security labels of the source. An agent should never be designed around copying confidential material into a broadly accessible new index merely to improve answer quality.
Distinguish knowledge connectors from transactional connectors
A Copilot connector can make external information discoverable through the Microsoft 365 ecosystem. A Power Platform connector or an approved API action can query or change records in a target application. Those functions are not interchangeable. If the agent is supposed to tell a customer success manager which tickets are open, a read-only information path may suffice. If it can change case priority, the application must verify entitlement and record that update as a business transaction.
Choose integration scope with data residency, index refresh, and revocation in mind. A connector that copied yesterday’s case state into a search experience cannot reliably promise that a ticket is still open. A real-time action can ask the authoritative system before changing it. The existing enterprise grounding design describes why retrieval freshness and access are separate requirements that both matter.
Keep Teams actions and consent within policy
An agent mentioned in Teams may look like another participant, but its tools can act beyond the conversation if the designer gives them privileged permissions. Avoid treating inclusion in a chat as consent from everyone in it. A task that creates a service ticket should use the identity and authorization model of the target service and expose a clear proposed action before committing. Channel messages may include sensitive information from people who did not request automation.
Use limited scopes and review distribution settings. Tenant administrators may control which agents and plugins are available to particular users or groups. Publishing an agent package is not proof that every employee should be able to activate it. Record the app owner, supported channels, consent path, incident contact, version, and revocation steps. When an external API returns instruction-like text, treat that output as untrusted content rather than a command from the system.
Choose actions and plugins for specific responsibilities
A narrow action such as open_review_request(contract_id, reviewer_id) is easier to validate than a generic tool that can run arbitrary HTTP requests. Define allowed identifiers, tenant boundaries, parameter types, and error states. If review creation fails, the agent should state that it failed or is pending, not say the contract is approved. Preserve idempotency so a retried conversation does not send duplicate requests.
Microsoft’s extensibility comparison describes routes for connecting agents, actions, and knowledge. The architect must match capability to the host and current platform support; an API plugin, a Microsoft Graph-connected knowledge source, and a Power Platform connector should not be described as the same component. Ensure every outward-facing capability has an owner who can test and rotate its credentials.
Test document permissions, citations and conversation context
Construct a test dataset with a public policy, a restricted legal appendix, two near-identical contract versions, a renamed SharePoint site, and a revoked employee account. Check what authorized and unauthorized users can retrieve, whether the answer cites the effective source, and how quickly permission or deletion changes are reflected. A strong result requires accurate content and correct access enforcement. Another user’s access must not be implied from the wording of a Teams message.
Test the full path when a response leads to a real action. A document can tell the agent who normally approves a contract, but only the current application and directory rules determine who is authorized now. Verify status, ownership, and audit events after the tool returns. Include interruption and retry scenarios, a human handoff, and an account whose rights changed during the conversation.
Operate the extension as part of an enterprise portfolio
Once the agent is in use, observe adoption, retrieval quality, unsupported questions, tool failures, latency, the proportion of accepted business outcomes, and feedback by department. Review changes to document libraries, admin policies, connectors, and host features as production dependencies. A new permission grant can change the information an agent can see without any change to its prompt. A versioned rollout should therefore include access tests and a rollback procedure.
For AB-100, the architecture objective is to bring the right capability to users inside familiar Microsoft 365 work while preserving ownership, source authority, authorization, and operational evidence. Reuse where it is adequate; extend only the missing capability; build a custom runtime when real requirements justify it. The defensible answer explains those trade-offs and how to prove them.