#183 — How to deploy AI agents in Slack & Microsoft Teams

Q: Should I build my AI agent for Slack first or Microsoft Teams first?

Start with wherever your target users already work. For B2B SaaS selling to SMBs and startups, Slack dominates. For enterprise, government, and regulated industries, Teams is often the primary collaboration tool — and it unlocks the broader Microsoft 365 distribution surface (Outlook, SharePoint, Copilot) with minimal extra effort. If your product is developer-facing, build Slack first; if your buyer is a CIO or enterprise IT team, build Teams first. If you're resource-constrained, build one to production before starting the second — the temptation to build both simultaneously usually results in neither being done well.

Q: What are the most common production failures when deploying AI agents in Slack or Teams?

Context window overflow is the most common silent failure — long conversations exceed token limits and the agent loses coherence without any obvious error. The second is permission scope creep: agents granted broad access during development accidentally surface data to users who shouldn't see it in production. Third is poor async handling: agents that don't acknowledge long-running tasks immediately cause users to re-send requests, triggering duplicate actions. Microsoft's own developer community has documented cases of deployed Teams bots going silent with no error messages due to misconfigured Azure webhook endpoints — a problem that never appears in local testing.

Q: How do I prevent my AI agent from giving confidently wrong answers to employees?

Grounding is the most important safeguard. Retrieval-Augmented Generation (RAG) — connecting the agent to a curated, version-controlled knowledge base rather than relying on the model's training data — dramatically reduces hallucination in enterprise contexts. Add explicit fallback behavior: when confidence is low or data is unavailable, the agent should say so rather than guess. Salesforce's internal 'Horizon Agent' (a text-to-SQL Slack agent used across the company) addresses this by returning the query it generated alongside the answer, letting users verify the logic before acting. Also set firm boundaries: route math, financial calculations, and legal questions to verified tools or humans, not the base LLM.

Q: How do AI agents in Slack or Teams handle GDPR and CCPA compliance?

Compliance exposure is primarily determined by what data you store and for how long. The lowest-risk architecture retrieves Slack or Teams message data in real-time per interaction rather than ingesting and storing it — Slack's own developer guidelines explicitly recommend this approach. For GDPR, you need to handle Data Subject Access Requests (DSARs) and right-to-erasure requests, which means your agent's logs and any stored conversation data must be queryable and deletable by user ID. For CCPA, the disclosure requirement kicks in if your agent's data processing qualifies as a 'sale' of personal information. Treat EU employee data as the strictest case and design for it from day one — retrofitting compliance is significantly more expensive than building it in.

Q: What's the difference between an AI agent and a Slack bot or Teams bot?

A traditional Slack/Teams bot follows pre-programmed, deterministic logic — it pattern-matches commands and returns scripted responses. An AI agent uses a large language model to understand intent in natural language, maintains context across a conversation, and dynamically decides which tools to call based on the situation. The practical difference: a bot requires you to enumerate every possible user input; an agent handles inputs you never anticipated. The tradeoff is reliability — bots behave predictably; agents can surprise you, which is why testing, fallback logic, and monitoring matter significantly more in agent deployments.

Q: What's the right first use case for an AI agent in Slack or Teams for a startup?

Internal Q&A over your own documentation is the canonical first deployment for a reason: it has a clearly defined knowledge scope, the stakes for wrong answers are low enough to learn from, and every employee benefits immediately. A retail company that deployed a code review agent in Slack saved an estimated 450,000 developer hours annually — but that's a mature, high-confidence deployment. Start simpler: connect your agent to Notion, Confluence, or Google Drive and let it answer questions your team currently Slacks each other about. Once you've validated the reliability, accuracy, and usage patterns on internal workflows, the architecture is largely the same when you expand to customer-facing or revenue-critical use cases.

March 4, 2026·18 min read

Contents

The big picture: Slack and Teams are where work already happens. Deploying AI agents there means zero behavior change for users — they just ask questions and get things done. But building production-ready agents across both platforms is genuinely hard, and the technical decisions you make early compound over time.

What an AI Agent Actually Is

An AI agent is software that perceives its environment, processes information, and takes actions toward specific goals. The critical distinction from a traditional chatbot: agents use large language models to understand natural language, maintain context across conversations, and dynamically decide which tools or APIs to call — no rigid pre-programmed scripts.

Agents can handle tasks like:

Answering employee questions by searching across internal documentation
Creating and updating tickets in Jira or ServiceNow
Provisioning app access through identity management systems
Scheduling meetings by checking calendar availability
Generating reports by pulling data from multiple sources

Why These Two Platforms

Both platforms have made deliberate infrastructure investments to support agents. Slack introduced streaming APIs, a Data Access API, and Model Context Protocol (MCP) support. Microsoft built Agent-to-Agent (A2A) communication into the Teams SDK and integrated it with Azure AI and the broader Microsoft 365 ecosystem.

The enterprise reality: most organizations use both. Sales lives in Slack; IT operations lives in Teams. This creates the core engineering dilemma — build once, maintain twice, or architect for shared logic from day one.

Slack: Full Technical Breakdown

Enable Agents & AI Apps First

Toggle on "Agents & AI Apps" in your Slack app configuration before anything else. This unlocks:

A dedicated entry point in the Slack top bar
A side-by-side split pane for agent conversations
The assistant:write permission scope
Access to AI-specific platform features

Streaming Responses

Slack's streaming API uses three sequential methods:

chat.startStream — initiates the stream
chat.appendStream — pushes text chunks as the model generates them
chat.stopStream — finalizes the message

Both the Python and Node.js Slack SDKs include a streamer utility that handles stream state, chunk buffering, and error recovery. Streaming is not optional for good UX — it turns a 10-second wait into a perceived instant response.

Data Access API

Currently in limited release for partner developers, the Data Access API gives agents contextual access to messages, files, and channel metadata — filtered strictly by what the invoking user already has permission to see. Unlike standard Slack APIs that require explicit per-message requests, this API provides comprehensive context retrieval. Slack's own developer guidelines recommend not storing this data — retrieve it in real-time when needed. This reduces data governance risk and ensures the agent always works with current information.

Block Kit Interactive Elements

Three Block Kit components are especially useful for agents:

Feedback buttons — thumbs up/down to capture response quality signals
Icon buttons — delete, regenerate, or other quick actions without requiring text commands
Context action blocks — compact multi-action layouts (e.g., "Try again," "More details," "Mark resolved")

Slack Rate Limits

Know these before you build:

Message posting: ~1 message/sec per channel (with burst tolerance)
Event API: 30,000 event deliveries per workspace per hour
Profile updates: 10/min for a single user, 30/min total
Message history (new restriction): Apps created after May 29, 2025 face strict limits on conversations.history and conversations.replies

Implement exponential backoff for all retries. When you receive a 429 Too Many Requests, read the Retry-After header and respect it exactly.

Slack Auth and OAuth Scopes

Request only the minimum scopes required:

chat:write — sending messages
channels:history — reading channel messages
assistant:write — required when using Agents & AI Apps
files:read — if the agent needs to access uploaded files

Use workspace-level tokens over user tokens wherever possible to reduce security surface area. Never log tokens or expose them in error messages.

Microsoft Teams: Full Technical Breakdown

Two Build Paths

Approach	Best For	Tradeoffs
Teams SDK (JS, C#, Python)	Complex, domain-specific agents	Full control, requires engineering
Microsoft Copilot Studio (low-code)	Simpler Q&A or guided flows	Faster to ship, less flexibility

Dev Environment Setup

You'll need:

Visual Studio Code
Node.js (or .NET/Python)
Microsoft 365 Agents Toolkit (VS Code extension)
A Microsoft 365 developer account
Azure OpenAI or OpenAI API access

The Microsoft 365 Agents Toolkit handles app manifest creation, bot registrations, and Azure resource provisioning. It also includes the Microsoft 365 Agents Playground — a local testing environment so you can chat with your agent without deploying to Teams.

Teams SDK v2 Core Components

Every Teams agent is built from these building blocks:

Activity handlers — respond to events like messages, mentions, or reactions
Conversation management — tracks state across multiple turns; the SDK handles this natively
Bot logic — where you integrate your AI model, implement tool calling, and define behavior
Tool definitions — specify which external actions the agent can take (search databases, call APIs, trigger workflows)

Agent-to-Agent (A2A) Protocol

The Teams SDK supports A2A communication — agents delegating subtasks to specialized agents via secure HTTP and JSON-RPC with built-in state tracking. A practical example:

A user asks: "Schedule a meeting about the bug in ticket 123."

Coordinator agent receives the request
Delegates to a ticketing agent → retrieves bug details
Delegates to a calendar agent → finds available times
Synthesizes and responds to the user

This architecture scales better than monolithic agents and lets you optimize each specialist independently.

Deploy Beyond Teams

One meaningful Teams advantage: the same agent can be deployed to Outlook, Microsoft 365 Copilot, and SharePoint with minimal additional work, using the Microsoft 365 Agents SDK. The SDK handles platform-specific differences so your core logic stays unchanged.

Bot Scopes

Define these in your app manifest — each requires different handling in code:

Personal scope — one-on-one, ideal for personal productivity or confidential workflows
Team scope — participates in team channels; users mention the agent, or it posts proactively
Group chat scope — smaller group conversations, balancing privacy and collaboration

Teams Auth

Authentication runs through Azure Active Directory with SSO baked in — users don't need a separate login step. When an interaction is triggered, Teams provides an auth token your agent uses to:

Verify user identity
Check data access permissions
Personalize responses by role
Maintain an audit trail

For external systems (Salesforce, GitHub, internal tools), implement OAuth token exchange so the agent can act on behalf of the user.

Teams Platform Limits

The most relevant constraints for agents:

Teams throttles bots that message the same channel too rapidly
Adaptive Cards have size limits — break long responses into multiple cards or use pagination
Message size limits and attachment restrictions apply throughout

Cross-Platform Deployment: Three Strategies

Strategy 1: Separate Implementations

Build one Slack-native agent and one Teams-native agent independently.

Pros: Full platform feature access; optimized UX per platform; clear separation of concerns Cons: Every feature, bug fix, or model change requires two deployments; implementations drift apart over time

Best for: Single-platform initial launch with the second platform added later, or agents with fundamentally different feature sets per platform.

Strategy 2: Shared Core + Platform Adapters

Extract all common logic into a shared core; write thin platform-specific adapters for each:

Core — AI model interaction, tool calling, prompt engineering, business rules, workflow orchestration
Slack adapter — translates Slack events → core inputs, core outputs → Slack messages
Teams adapter — same, for Teams events and message formats

Pros: Dramatically reduces duplication; core logic lives in one place Cons: Requires well-designed abstractions; platform API updates require changes in both the adapter and potentially the core; adds architectural complexity

The challenge is that platform-specific UI elements like Slack's Block Kit or Teams' Adaptive Cards don't map cleanly to each other and need careful handling at the adapter layer.

Strategy 3: No-Code/Low-Code Platform

Use a platform that handles multi-platform deployment natively — you define agent logic once and it handles the Slack and Teams integrations, OAuth, rate limiting, retry logic, and error handling.

Pros: Single implementation; automatic platform API updates; consistent cross-platform behavior; faster iteration Cons: Less control over platform-specific features; vendor dependency

Evaluate platforms against: model selection flexibility, ability to add custom code for complex logic, security certifications (SOC 2, GDPR/HIPAA), self-hosting options, and audit logging.

Security & Auth Architecture

OAuth Token Management

Both platforms use OAuth 2.0, but the details differ significantly:

Slack: Request scopes at app install; receive a bot token (and optionally user tokens) for subsequent API calls
Teams: Auth flows through Azure AD; your agent receives tokens from Teams to verify identity and access Microsoft services

Follow OAuth 2.1 guidelines even if not strictly required yet — specifically, mandate PKCE for all public clients and avoid insecure legacy auth flows.

Token Exchange (Brokered Credentials)

For agents that need to access third-party systems, implement the brokered credentials pattern:

Users authenticate through your identity provider
Their access and refresh tokens go into a secure credential vault (e.g., Auth0 Token Vault)
Your agent requests short-lived, scoped tokens from the vault on demand
The agent never sees or stores long-lived credentials directly

The Model Context Protocol (MCP) formalizes this pattern for AI agents — when a tool requires auth, the agent exchanges its current token for one scoped to that tool.

Least Privilege by Task

Design permissions around tasks, not roles. Example for an HR agent:

Read access to employee data → answering questions
Write access to time-off systems → processing requests
Read-only on payroll → explaining paystubs
No access to performance review data

Verify permissions at multiple levels: when the agent is invoked, when it accesses data sources, and when it takes actions in external systems.

For sensitive operations, build human-in-the-loop checkpoints — the agent drafts the action, a human approves before execution. This maintains automation efficiency without removing accountability.

Audit Logging

Every agent action needs to be logged. Capture:

Which user invoked the agent
What question or command was issued
Which data sources were accessed
What actions were taken in external systems
Precise timestamps for everything

Store logs in immutable storage — the agent should have no ability to modify them. This is non-negotiable for security investigations and compliance audits. Supplement platform-native logs (Slack admin console, Azure AD sign-in logs) with your own application-level logging.

Data Privacy

Key principles:

Minimize retention: Don't store chat data unless functionally required; when you do, retain only as long as necessary
Respect existing permissions: Never use service accounts with elevated privileges that bypass normal user permission checks
Encrypt PII: Email addresses, phone numbers, employee IDs — encrypt at rest and in transit
Implement GDPR/CCPA mechanics: Data subject requests, deletion workflows, and privacy notices from day one

Production Implementation Patterns

Long-Running Operations

For operations under a few seconds → use streaming.

For longer operations → implement an async pattern:

Acknowledge immediately: "Working on that report now. I'll send it when ready."
Process in the background using a queue or serverless function
On completion, send a new message and tag the original user for notification
In Slack, update the original message; in Teams, send a new message or update an Adaptive Card

For multi-hour or multi-day jobs → send periodic progress updates: "Still analyzing 10,000 records. 45% complete." This prevents users from assuming the agent failed.

Conversation Context Management

Maintain a context object per thread, keyed to the thread identifier:

thread_ts in Slack
Conversation ID in Teams

Each context object should store:

Previous user messages in the thread
Previous agent responses
Data retrieved during the conversation
Tools that have been called
Current state of any multi-step workflows

Be mindful of LLM token limits. As conversations grow long, summarize older messages to keep context manageable while preserving important information. Storing context in external persistent storage (database, Redis) also enables horizontal scaling — any agent instance can pick up any conversation — and graceful recovery after crashes or restarts.

Retry Logic

Implement exponential backoff as the default retry strategy. Different failure types warrant different approaches:

Error Type	Retry Strategy
Rate limit (429)	Wait exactly the `Retry-After` duration, then retry
Network timeout	Immediate retry once, then exponential backoff
Auth error	Do not retry — indicates a config issue
Server error (5xx)	Exponential backoff — often a temporary provider issue

Implement circuit breakers for repeatedly failing services: after N consecutive failures, stop calling the service for a cooldown period. This prevents pointless calls and reduces load on struggling services.

Error Communication

Translate HTTP errors into plain-language guidance for users:

Don't: HTTP 500 Internal Server Error
Do: "I couldn't access the customer database right now. Try again in a few minutes, or contact IT if this keeps happening."

For permission errors, be specific: "I don't have access to the finance channel where that data lives. Ask an admin to grant me access." Empower users to self-resolve.

Log errors with full technical detail (user, intent, which API calls failed, full error stack) — but never expose this to end users.

Stateless Design for Resilience

Assume your agent will restart. Design accordingly:

Store all persistent state in external systems — databases, Redis, cloud storage
On restart, reload active conversations from storage and resume any pending operations
Maintain a registry of active threads/conversations to pick back up after a restart
This design also enables horizontal scaling: multiple agent instances sharing state via external storage

Testing & Debugging

Local Development Environments

Slack: Use the Slack CLI to create an isolated development workspace. It handles HTTPS tunneling so Slack can reach your local server
Teams: The Microsoft 365 Agents Playground lets you test locally without deploying to Teams at all
Both: Tools like ngrok create public URLs that forward to your local machine for full end-to-end integration testing

What to Test

AI model non-determinism makes traditional unit testing insufficient. Focus on:

Test Area	What to Verify
Intent recognition	Multiple phrasings of the same request produce correct agent behavior
Tool calling	Agent calls the right tool with correct parameters
Error handling	Agent responds correctly when tools fail, return bad data, or are unavailable
Permission checks	No data leaks across user scopes
Conversation flow	Multi-turn context maintained; topic changes handled correctly

Build a test suite of common interactions with expected actions and tool calls (not exact response text, since that will vary).

Production Monitoring

Track these metrics continuously:

Response latency — time to first token and total conversation duration
Error rates — broken down by error type to identify patterns
Tool call success — track failures per external API to find problematic integrations
User satisfaction — thumbs up vs. thumbs down from feedback buttons; analyze negative feedback conversations
Conversation patterns — what users commonly ask, to inform prompt improvements and feature prioritization

Set up alerts for anomalies (error rate spikes, latency jumps, API failures) and implement distributed tracing to follow a request across agent logic, AI model, external APIs, and data sources.

Structured Logging

Structure every log entry with:

Conversation identifiers (thread ID, user ID)
User input and agent responses
Prompts sent to the AI model
Raw model outputs before post-processing
Tool calls made and their results
Timing for each operation
Full error details on failure

Use JSON or another structured format for searchability. Include correlation IDs that link all operations within a single conversation. Mask or redact PII, credentials, and confidential data before writing logs.

Platform-specific: Azure Application Insights provides built-in telemetry for Teams agents; Datadog, Splunk, or CloudWatch work well for Slack agents.

Performance Optimization

Reducing Latency

Five techniques that move the needle:

Send a typing indicator immediately — users need confirmation the agent received their input
Stream long responses — don't wait for full completion; start displaying tokens as they're generated
Cache common queries — with timestamps and invalidation logic so data stays fresh
Parallelize tool calls — execute independent API calls simultaneously, not sequentially
Right-size your model — use faster/smaller models for simple queries; reserve frontier models (GPT-4o, Claude 3.5+) for genuinely complex requests

Controlling AI Model Costs

Minimize context size — only include relevant information in prompts; long context windows cost more and don't always improve quality
Implement smart caching — cache embeddings for frequently accessed documents; cache responses for stable Q&A
Batch operations — where the model supports it, process multiple items per request
Set max output token limits — prevents unexpectedly long responses that spike costs
Monitor per-user and per-conversation token consumption — set budgets and cost alerts

Scaling Architecture

For serverless deployments (Lambda, Azure Functions), auto-scaling handles load spikes automatically. For containerized deployments, Kubernetes horizontal scaling works well — monitor CPU and memory to inform thresholds.

The bottleneck is typically external APIs, not your agent code. If you're hitting third-party rate limits, implement request queuing to smooth out spikes. Use separate queue priorities: high-priority for time-sensitive interactions, slow queues for batch operations.

For very high scale or latency-sensitive deployments, multi-region is worth considering — it reduces latency and provides redundancy if one region fails.

Prompt Engineering

Be explicit about output format — if you want JSON, say so; this reduces parsing errors and post-processing time
Provide few-shot examples — they help the model understand expected behavior and reduce follow-up correction loops
Use structured prompts — break into sections: instructions, context, examples, user input
Test model parameters — temperature, top-p, and other settings need tuning for your specific use case
Version your prompts — track changes so you can A/B test improvements and roll back when needed

Advanced Patterns & What's Coming

Multi-Agent Orchestration

The dominant architectural direction is moving away from monolithic agents toward coordinator + specialist systems.

A user asks: "Prepare for tomorrow's client meeting." A coordinator agent breaks this into subtasks and delegates:

Document agent → searches internal files on the client
Communications agent → summarizes recent email/message history
Calendar agent → checks team availability
Project agent → pulls latest project status

The coordinator synthesizes outputs into a complete brief. Each specialist is optimized for its domain. Adding new capabilities means building new specialists — not modifying a complex central agent. Both Teams (A2A protocol) and Slack (MCP support) are actively building infrastructure for this pattern.

Proactive Agents

Current agents are reactive. The next generation acts on events and patterns without waiting for a prompt:

An IT agent detects repeated login failures and sends password reset instructions before a ticket is filed
A project agent sees a milestone deadline approaching with incomplete tasks and alerts the team
A sales agent sees a high-value lead engage with content and notifies the AE immediately

The design challenge is avoiding notification fatigue while delivering timely value — user preference controls should be first-class features, not afterthoughts.

Voice & Multimodal

Teams already supports voice commands with AI-powered features expanding; Slack is exploring similar capabilities. Multimodal agents handling image inputs, chart generation, document processing, and presentation creation are maturing rapidly on both platforms. Build your agent's core logic in a way that doesn't assume text-only input/output.

Autonomous Workflows

Full end-to-end workflow handling — with human escalation only on exceptions — is the direction the technology is moving toward. An HR onboarding agent that detects a new hire, creates all accounts, sends welcome materials, schedules orientation, assigns training modules, checks in during week one, and only surfaces to a human when something is off.

This requires sophisticated governance: clear policies defining what agents can execute autonomously, defined approval gates for sensitive actions, and audit trails showing every agent decision.

Natural Language BI

Agents are beginning to bridge conversational interfaces with data warehouses. Users ask questions in plain language; agents translate them into queries, generate appropriate visualizations, and return results in chat. This democratizes analytics access across the organization without requiring SQL literacy.

Where to Start

Pick one high-value, repetitive use case. Get it working in production. Measure the time saved, error rates, and user satisfaction. Then expand. The organizations building agent infrastructure now accumulate compounding advantages as these platforms — and the underlying models — continue to improve.

Frequently asked questions

What is the ROI of deploying AI agents in Slack or Microsoft Teams?

Early enterprise adopters of agentic AI in Slack and Teams are reporting a 27% increase in revenue, 21% reduction in operating costs, and 31% improvement in employee efficiency. One financial services company processing 40,000 agent interactions per month saved $15,500/month on manual work — that's $186,000 annually from a single deployment. Slack integrations with AI have delivered 294–296% ROI over three years for service and sales teams, driven by reduced ticket handling times (10.7%), fewer escalations (17.4%), and an average of 3.5 hours saved per employee per week.

Should I build my AI agent for Slack first or Microsoft Teams first?

Start with wherever your target users already work. For B2B SaaS selling to SMBs and startups, Slack dominates. For enterprise, government, and regulated industries, Teams is often the primary collaboration tool — and it unlocks the broader Microsoft 365 distribution surface (Outlook, SharePoint, Copilot) with minimal extra effort. If your product is developer-facing, build Slack first; if your buyer is a CIO or enterprise IT team, build Teams first. If you're resource-constrained, build one to production before starting the second — the temptation to build both simultaneously usually results in neither being done well.

How long does it actually take to deploy an AI agent to Slack or Teams in production?

A focused engineering team (1–2 developers) can ship a basic Slack or Teams agent in 2–4 weeks for a well-scoped single use case. A no-code/low-code platform can cut that to 3–5 days for simpler flows. The timeline extends significantly when you add multi-step workflows, external integrations (CRMs, ticketing systems), compliance requirements, or cross-platform support. The biggest time sink is almost never the agent itself — it's OAuth flows, auth edge cases, rate limiting, and retry logic that consume the most engineering hours.

What are the most common production failures when deploying AI agents in Slack or Teams?

Context window overflow is the most common silent failure — long conversations exceed token limits and the agent loses coherence without any obvious error. The second is permission scope creep: agents granted broad access during development accidentally surface data to users who shouldn't see it in production. Third is poor async handling: agents that don't acknowledge long-running tasks immediately cause users to re-send requests, triggering duplicate actions. Microsoft's own developer community has documented cases of deployed Teams bots going silent with no error messages due to misconfigured Azure webhook endpoints — a problem that never appears in local testing.

How do I prevent my AI agent from giving confidently wrong answers to employees?

Grounding is the most important safeguard. Retrieval-Augmented Generation (RAG) — connecting the agent to a curated, version-controlled knowledge base rather than relying on the model's training data — dramatically reduces hallucination in enterprise contexts. Add explicit fallback behavior: when confidence is low or data is unavailable, the agent should say so rather than guess. Salesforce's internal 'Horizon Agent' (a text-to-SQL Slack agent used across the company) addresses this by returning the query it generated alongside the answer, letting users verify the logic before acting. Also set firm boundaries: route math, financial calculations, and legal questions to verified tools or humans, not the base LLM.

How do AI agents in Slack or Teams handle GDPR and CCPA compliance?

Compliance exposure is primarily determined by what data you store and for how long. The lowest-risk architecture retrieves Slack or Teams message data in real-time per interaction rather than ingesting and storing it — Slack's own developer guidelines explicitly recommend this approach. For GDPR, you need to handle Data Subject Access Requests (DSARs) and right-to-erasure requests, which means your agent's logs and any stored conversation data must be queryable and deletable by user ID. For CCPA, the disclosure requirement kicks in if your agent's data processing qualifies as a 'sale' of personal information. Treat EU employee data as the strictest case and design for it from day one — retrofitting compliance is significantly more expensive than building it in.

What's the difference between an AI agent and a Slack bot or Teams bot?

A traditional Slack/Teams bot follows pre-programmed, deterministic logic — it pattern-matches commands and returns scripted responses. An AI agent uses a large language model to understand intent in natural language, maintains context across a conversation, and dynamically decides which tools to call based on the situation. The practical difference: a bot requires you to enumerate every possible user input; an agent handles inputs you never anticipated. The tradeoff is reliability — bots behave predictably; agents can surprise you, which is why testing, fallback logic, and monitoring matter significantly more in agent deployments.

Can I deploy the same AI agent as a B2B SaaS product that each customer installs into their own Slack or Teams workspace?

Yes, and this is one of the highest-leverage distribution models for B2B AI companies. For Slack, you build a distributable app via the Slack Marketplace (public) or through direct install links (private). Each customer workspace gets its own OAuth token, and you're responsible for multi-tenant isolation — ensuring no customer's data leaks into another customer's context. For Teams, distribution happens through the Microsoft AppSource marketplace or organization-specific sideloading. The critical engineering requirement for both is a robust tenant management layer: every LLM call, tool invocation, and data retrieval must be scoped to the correct customer's credentials and data. Slack's new 'Agents & AI Apps' UI surface is particularly well-suited to this model because it gives your agent prominent placement in the Slack interface without requiring users to remember a specific command.

How much does it cost to run an AI agent in Slack at scale?

At 40,000 interactions/month (a meaningful production volume), the dominant cost is LLM API usage, not infrastructure. Using GPT-4o at ~$5/1M input tokens, a typical interaction consuming 2,000 tokens runs to roughly $0.01 per interaction — $400/month at that volume. Switch to a smaller model like GPT-4o-mini for routine queries and you're looking at ~$0.0004/interaction, or about $16/month at the same volume. Infrastructure costs (serverless functions, database, Redis) typically run $50–$200/month at this scale. The real cost lever is prompt engineering and model routing — companies that route query complexity to the right-sized model consistently report 70–85% lower LLM costs than those using a single frontier model for everything.

What's the right first use case for an AI agent in Slack or Teams for a startup?

Internal Q&A over your own documentation is the canonical first deployment for a reason: it has a clearly defined knowledge scope, the stakes for wrong answers are low enough to learn from, and every employee benefits immediately. A retail company that deployed a code review agent in Slack saved an estimated 450,000 developer hours annually — but that's a mature, high-confidence deployment. Start simpler: connect your agent to Notion, Confluence, or Google Drive and let it answer questions your team currently Slacks each other about. Once you've validated the reliability, accuracy, and usage patterns on internal workflows, the architecture is largely the same when you expand to customer-facing or revenue-critical use cases.

How do I stop employees from abusing or gaming an internal AI agent?

The main failure modes are prompt injection (users crafting inputs to make the agent ignore its instructions), scope creep (using an HR agent for tasks it wasn't designed for), and data fishing (trying to extract information above the user's permission level). Mitigate these through permission verification at the data layer, not just the prompt layer — the agent should be architecturally incapable of returning data the invoking user doesn't have access to, regardless of what they ask. For prompt injection, validate and sanitize inputs before they reach the model, and run adversarial testing before launch. Audit logs are your accountability layer: when you can show exactly what every user asked and what the agent returned, most abuse attempts become visible quickly.

Should I use the Microsoft Teams SDK directly or Microsoft Copilot Studio to build my agent?

Use Copilot Studio if you're building internal tooling with standard Q&A flows, need non-engineers to maintain it, or want to validate a use case before committing engineering resources. Use the Teams SDK directly if you're building a product (not just internal tooling), need fine-grained control over model selection and prompt engineering, plan to implement multi-agent orchestration, or have compliance requirements that need custom audit logging. The hidden cost of Copilot Studio for complex agents is the ceiling — you will eventually hit scenarios it can't handle, and migrating to the SDK is a rewrite. If you're a technical founder with engineering resources, build on the SDK from day one and treat Copilot Studio as a prototyping tool.

What tech stack should I use to build a Slack AI agent?

The standard production stack for a Slack AI agent is: Slack Bolt SDK (Python or Node.js) for event handling and API calls, FastAPI or Express as the backend server, OpenAI or Anthropic SDK for LLM calls, LangChain or LlamaIndex for orchestration and RAG pipelines, pgvector or Pinecone as the vector database, and Redis for conversation context storage. For deployment, most teams start with Railway or Render for simplicity, then move to AWS Lambda or Cloud Run for scalability. The Bolt SDK handles Slack's request verification, event routing, and OAuth automatically — don't reinvent that layer.

What is Slack's native AI versus a custom AI agent — which should I build?

Slack AI (the native product) is a first-party feature Salesforce/Slack sells as an add-on at $10/user/month, offering channel summaries, thread recaps, and search within Slack content. It cannot be customized, cannot access external systems, and cannot take actions. A custom AI agent is software you build that connects to your specific data sources, tools, and workflows. Slack AI is a productivity layer for end users; a custom agent is a programmable system you control. If you're a founder evaluating whether to build, Slack AI doesn't compete — it has no programmatic API, no ability to integrate with your CRM or ticketing system, and no mechanism to take actions on behalf of users.

How does Model Context Protocol (MCP) change how AI agents work in Slack and Teams?

MCP is an open standard that defines how AI agents connect to external tools and data sources — think of it as a universal plugin interface for agents. Slack has announced MCP support as part of its agent infrastructure, which means agents built against MCP-compliant tool servers can be connected to Slack without custom integration code per tool. In practice, this means an agent can call your internal Jira server, a SaaS API, or a vector database through a standardized interface rather than bespoke integrations. For founders, this matters because it significantly reduces the marginal cost of adding new capabilities to an existing agent — and it enables a marketplace model where third-party tool servers can extend your agent without your team writing the integration.

How do I connect an AI agent to Notion, Confluence, or Google Drive in Slack?

The standard pattern is RAG: index your documents into a vector database, then retrieve relevant chunks at query time before calling the LLM. For Notion and Confluence, use their official APIs to sync pages on a schedule (nightly or webhook-driven on updates) and embed them using a text embedding model (OpenAI text-embedding-3-small is a solid default). For Google Drive, the Drive API supports incremental sync via change tokens. Store embeddings in pgvector (if you're already on Postgres) or Pinecone. At query time, embed the user's question, run a similarity search, and inject the top 3–5 results into the prompt as context. The quality of your agent's answers is almost entirely determined by the quality of your index — noisy, outdated, or poorly chunked documents produce poor answers regardless of model choice.

How do I get enterprise IT teams to approve installing my AI agent in their Slack or Teams workspace?

Enterprise IT approval is as much a sales and documentation process as a technical one. You need to proactively produce: a security overview document covering data flows, what you store, where it's hosted, and encryption standards; a permissions justification explaining exactly why each OAuth scope is needed; evidence of SOC 2 Type II certification (or your roadmap to it); a data processing agreement (DPA) for GDPR; and clear answers to their standard questionnaire (most large enterprises use SIG Lite or CAIQ). On the technical side, request only the minimum required scopes, avoid requesting admin or broad channels:history access on install, and support IP allowlisting and audit log exports. The teams that close enterprise deals fastest treat security review as a product feature, not a legal checkbox.

What AI model works best for Slack and Teams agents — OpenAI, Anthropic, or Gemini?

The answer depends on your use case. GPT-4o leads on tool calling reliability and instruction following — critical for agents that need to call external APIs with precise parameters. Claude 3.5/3.7 Sonnet outperforms on long-context tasks (processing full documents, analyzing long threads) and produces more natural, nuanced prose responses. Gemini 1.5/2.0 Flash is the fastest and cheapest for high-volume, lower-complexity queries. Most production agents use a model routing strategy: a fast, cheap model handles intent classification and simple Q&A; a frontier model handles complex reasoning and multi-step tool calling. Don't hardcode a single model — abstract the LLM layer so you can swap models as benchmarks shift.

How do I measure whether my AI agent is actually working in production?

The three metrics that matter most are First Contact Resolution (FCR) — the percentage of requests fully resolved without human escalation; Mean Time to Resolution (MTTR) — how long it takes from request to answer; and containment rate — how often the agent handles a request completely autonomously. For an IT support agent, a 60–70% FCR with MTTR under 30 seconds is a strong baseline. Supplement with user satisfaction signals (thumbs up/down on responses), topic distribution (what are people asking), and failure mode analysis (what queries trigger escalations or fallbacks). The metric most founders ignore is negative feedback rate by topic — it tells you exactly where to invest in knowledge base improvements or prompt tuning.

Can an AI agent in Slack or Teams take real actions, or does it just answer questions?

Modern AI agents can take real, consequential actions — not just generate text. Common action categories include: creating and updating tickets in Jira, Linear, or ServiceNow; provisioning app access through Okta or Google Workspace; sending calendar invites; updating CRM records in Salesforce or HubSpot; triggering CI/CD pipelines; posting to channels on behalf of a workflow; and executing database queries. The architectural requirement is a well-defined tool layer where each action is explicitly coded, permissioned, and logged. The key design decision is where to require human approval — read operations (searching, summarizing) can typically run autonomously; write operations (sending emails, modifying records, provisioning access) should default to showing the user what the agent plans to do before executing.

How do I handle user onboarding and adoption for a new internal AI agent?

The two highest-impact adoption levers are meeting users where they already work (which is why Slack/Teams deployment works better than a separate portal) and demonstrating value in the first 60 seconds. On launch day, send a single channel message with the three most useful questions users can ask — don't explain the technology, demonstrate the output. Set up a #feedback-agentname channel for iteration. Avoid launching without a clearly scoped use case: agents that try to do everything confuse users and produce inconsistent results. One company that deployed an IT agent in Slack reduced support ticket volume by 34% within 60 days simply by posting the agent's best answers publicly in channels, teaching users what it could do through example.

How do I migrate from an existing Slack bot to an AI agent without breaking things?

Run both in parallel during transition. Keep your existing bot handling its established command patterns while the new agent handles everything that doesn't match a known command — this is the 'fallback handoff' pattern. Gradually migrate command patterns to the agent as confidence grows. The riskiest part of migration isn't the agent itself; it's auth and permissions — your new agent may need different OAuth scopes than your existing bot, which requires users to re-authorize. Draft a workspace admin communication explaining the re-auth requirement in advance. Log every interaction in both systems for 30 days post-migration so you can identify commands the old bot handled that the agent is misinterpreting.

What happens to my company's data when an AI agent processes Slack or Teams messages?

It depends entirely on your architecture. If you call OpenAI's API directly, your data is subject to OpenAI's data processing terms — by default, OpenAI does not use API data for training, but you should use their zero-data-retention endpoint for sensitive workloads. If you use Azure OpenAI, your data stays within your Azure tenant and is covered by Microsoft's enterprise data residency commitments. For the most sensitive environments, self-hosted open-source models (Llama 3, Mistral, Qwen) ensure data never leaves your infrastructure. Regardless of model provider, your vector database (where document embeddings live) should be hosted in the same region as your users to comply with data residency requirements. Document your data flow diagram before your first enterprise prospect asks — they will ask.

Can I build one codebase that deploys to both Slack and Teams?

Yes, using a shared core + platform adapter pattern. The core contains all business logic: LLM calls, tool definitions, RAG retrieval, prompt engineering, and workflow orchestration. Platform adapters handle the translation layer — Slack's event format to your core's input schema, and your core's output to Slack's Block Kit or Teams' Adaptive Cards. The challenge is that Slack and Teams message formats, interactive components (Block Kit vs. Adaptive Cards), and auth flows are structurally different enough that the adapters are non-trivial to write. In practice, teams using this pattern report 60–70% code reuse between platforms, with the remaining 30–40% being platform-specific adapter and UI code. The payoff is that every improvement to core agent logic — prompt changes, new tools, model upgrades — deploys to both platforms simultaneously.

How does multi-agent orchestration work in Slack and Teams?

Multi-agent systems use a coordinator agent that routes subtasks to specialized agents, rather than one agent that tries to do everything. A user sends a single request; the coordinator breaks it down and delegates: a ticketing agent checks Jira, a calendar agent checks availability, a documents agent searches Confluence. Each specialist is independently deployable, testable, and optimizable. Teams supports this natively via the Agent-to-Agent (A2A) protocol in Teams SDK v2; Slack supports it through MCP and workflow orchestration. The practical benefit is maintainability: when your Jira integration breaks, only the ticketing agent needs updating — not the entire system. Start with a single agent, validate it, then extract specialists only when the monolith becomes difficult to maintain or test.

What is the Slack Marketplace approval process for AI agents, and how long does it take?

Slack's marketplace review process (for public distribution) typically takes 2–6 weeks and requires: a publicly accessible privacy policy and terms of service; a support email or help page; a working demo environment Slack reviewers can access; OAuth scopes justified with clear descriptions; and compliance with Slack's app directory guidelines. The most common rejection reasons are requesting more OAuth scopes than the app demonstrably needs, insufficient privacy policy coverage of data handling, and missing error states in the demo. Scoping your initial submission narrowly accelerates approval — you can add scopes in subsequent updates. For Microsoft AppSource (Teams), the process is similar but goes through Partner Center and typically adds 1–2 weeks for security validation, especially for apps requesting admin-level permissions.

How do proactive AI agents work in Slack — can an agent message users without being asked?

Yes. Slack's API allows bots to post messages to any channel or DM they have access to, without a user trigger. The pattern is: an event or schedule triggers your backend → your agent evaluates whether a message is warranted → the agent posts via the chat.postMessage API. Examples: a monitoring agent that detects a deployment failure and DMs the on-call engineer; a sales agent that posts when a high-value prospect opens a proposal; a project agent that sends a daily standup summary each morning. The design risk is notification fatigue — proactive agents that message too often or without clear value get muted or removed. Best practice: give users granular control over which proactive alerts they receive, default to lower frequency, and make it easy to adjust preferences via a slash command.

Keep reading

#184 — How Agentic AI works

Every major AI agent runs the same core loop. The production-hardened version—with context compaction, loop detection, cost budgets, and graceful termination—is where things get interesting.

#185 — Your AI agent has a memory problem. Here's how to fix it.

Most AI agents don't have a memory size problem. They have an architecture problem. Here's a layered approach that separates demos from production.

#186 — The 95:5 rule: Why most of your GTM is wasted

95% of buyers are not in the market for many goods and services at any one time. This is a deceptively simple fact, but it has profound implications.

View all notes →