An agent built in AI Foundry is worth nothing if it lives isolated from where employees actually work. Microsoft offers two distinct paths for bringing it into Teams and Microsoft 365, and picking the wrong one costs months of redesign.
There are two legitimate ways to expose AI capabilities within the Microsoft ecosystem, and you choose between them based on who owns the experience. The first is extending Microsoft 365 Copilot with agents that appear inside that existing experience (Word, Outlook, Teams). The second is building a standalone conversational agent that lives as its own Teams app, with its own chat interface, bypassing native Copilot. The right architecture decision depends on whether the goal is to augment the Copilot users already use or to create a separate product experience.
Within the first path, a declarative agent is defined with a JSON manifest and natural-language instructions, reusing the model, orchestration, and reasoning engine of Microsoft 365 Copilot -- it needs no LLM infrastructure of its own. A custom engine agent, by contrast, brings its own reasoning backend (typically an AI Foundry Agent Service or Semantic Kernel agent) and connects to Teams or M365 Copilot as an external engine, giving full control over the model, prompt, and tools at the cost of more integration work.
For Microsoft 365 Copilot to answer using data that doesn't live in SharePoint or Outlook -- an internal CRM, a ticketing system, a proprietary knowledge base -- you implement Graph connectors, which index that external content into Microsoft Graph while respecting the source system's original permissions. This is key so that Copilot never shows a user information they wouldn't have access to in the original system: the connector propagates ACLs, not just content.
When the goal is a standalone conversational agent in Teams, the Teams AI Library (built on the Bot Framework SDK) provides the components for handling message lifecycle, attaching an Azure OpenAI model or an AI Foundry agent as the response engine, and managing conversation state per user and per channel.
An agent's responses in Teams don't have to be plain text: Adaptive Cards let you render interactive cards with action buttons, forms, and structured data directly in the conversation thread -- useful, for example, for an expense-approval agent to show details and capture a decision without leaving the chat.
Teams Toolkit (a VS Code extension) automatically provisions the necessary Azure resources (App Service or Functions, bot registration, Teams manifest) and gives you commands to debug locally against a real Microsoft 365 tenant, shortening an agent's test cycle without needing to deploy to production on every iteration.
Any integration with Microsoft Graph operates under the delegated or application permissions model, and requires explicit consent from the tenant admin or the user depending on the requested scope. A misconfigured agent with overly broad application permissions (for example, Mail.Read for the entire tenant instead of per-user delegated access) is the most common security mistake in these integrations, and should be reviewed on every deployment.
Carlos Montiel is an enterprise AI solutions architect. He implements LLMs, Agents, RAG, and orchestrators for companies across Guatemala and Latin America. Reach out for a consultation.
Contact Carlos Montiel