An AI agent that lives in a separate interface is an AI agent your team won’t use. People don’t want to leave Slack to ask a question, switch to a dashboard to check a status, or open a new tab to run an automation. The tools your team already uses (Slack, Google Workspace, Microsoft 365, Notion, Linear) are where work happens. Agents need to be there too.
Connecting agents to productivity tools is what turns them from isolated assistants into embedded teammates. It’s also where the read-versus-write distinction matters most, because writing a Slack message to the wrong channel or creating a calendar invite with the wrong attendees has immediate, visible consequences.
The Bidirectional Challenge
CRM integrations are primarily read-heavy. Agents pull data, analyze it, and occasionally write back structured updates. Productivity integrations are fundamentally bidirectional. An agent reads a Slack thread to understand a request, then posts a reply. It reads calendar availability, then creates an event. It reads a Google Doc for context, then creates a new document with a draft.
Bidirectional access doubles the governance surface area. Every read operation has a corresponding write operation, and each write has its own risk profile.
Reading a Slack message is low risk, worst case, the agent processes a message it shouldn’t have seen, and you tighten the channel scope. Sending a Slack message to a customer-facing channel with incorrect information is a different problem entirely. Reading a Google Drive file is harmless. Overwriting a shared spreadsheet that six people depend on creates a support ticket.
The MCP server pattern handles this by separating read tools from write tools, each with independent permission checks. An agent might have read_channel_messages and post_to_channel as separate capabilities with separate authorization. Revoking write access doesn’t affect reads. Adding a new write capability doesn’t broaden read access. The permissions are granular and explicit.
Communication Tools: Slack, Teams, Discord
Communication integrations are the highest-adoption category. When an agent can answer questions, summarize threads, and post updates inside Slack, people actually use it, because there’s zero context switching.
Slack
Slack is the most common productivity integration NimbleBrain deploys. The MCP server uses Slack’s Bot Token API with granular OAuth scopes.
Read capabilities. Channel message history, thread replies, reactions, file attachments, user profiles, channel membership. The MCP server exposes tools like read_channel_messages, search_messages, get_thread_context. Scoping is by channel, the bot token’s channel access determines what the agent can see. Add the bot to specific channels, not every channel in the workspace.
Write capabilities. Post messages, reply in threads, add reactions, upload files, create channels. Each write operation is a distinct tool: post_message, reply_in_thread, add_reaction. Thread-based replies are the preferred pattern, the agent responds in context rather than starting new conversations. A message from an agent in a thread is useful. A message from an agent in the main channel, unprompted, is noise.
Real-time events. Slack’s Events API pushes notifications when things happen: new messages, reactions, channel joins, file uploads. The MCP server subscribes to relevant events and queues them for agent processing. This enables reactive patterns, an agent that monitors a #support-requests channel and responds to new questions within seconds, or an agent that watches for specific keywords and triggers workflows.
The governance model. Channel-based scoping is the first layer. The MCP server adds a second: configurable rules for when the agent can post proactively versus only responding to direct invocations (mentions, thread replies, slash commands). NimbleBrain deployments default to reactive: agents respond when asked, not when they think they should.
Microsoft Teams
Teams integrations follow a similar pattern but with Azure AD complexity. The MCP server registers as an Azure AD application with Teams-specific permissions: ChannelMessage.Read.All, ChannelMessage.Send, Chat.ReadWrite. Token management is the main difference: Azure AD tokens expire faster than Slack tokens, and the refresh flow requires careful handling.
Teams’ threading model differs from Slack’s. Conversations live in channels with a flat reply structure. The MCP server normalizes the differences so the agent’s skills don’t need to account for platform-specific threading behavior.
Discord
For community-facing agents, Discord integration follows the bot token pattern. Channel permissions, role-based access, and slash commands provide governance. The main consideration: Discord rate limits are stricter than Slack’s (50 requests per second per bot), and the message format (embeds, markdown variants) requires server-side formatting.
Document Tools: Google Workspace, Microsoft 365, Notion
Document integrations give agents research capability and content creation power. An agent that reads your Google Drive has context. An agent that creates Google Docs produces deliverables.
Google Workspace
Google Workspace integration uses service accounts with domain-wide delegation. This is the most powerful and the most dangerous authentication model, a service account with delegation can impersonate any user in your domain. Scope it tightly.
Drive and Docs. The MCP server exposes file search, document reading, document creation, and file sharing as separate tools. search_drive finds files by name, content, or folder. read_document extracts text from a Google Doc. create_document generates a new Doc with specified content and sharing permissions. read_spreadsheet pulls data from Sheets with range support.
Calendar. Calendar integration is one of the highest-value productivity connections. The MCP server reads availability across calendars (respecting privacy settings), creates events with attendees, checks for conflicts, and handles time zone normalization. A scheduling agent that reads three people’s calendars, finds a common free slot, and sends an invite saves 15 minutes per meeting, and a company that schedules 20 meetings a day saves five hours weekly.
Gmail. Email integration requires the most careful scoping. The MCP server typically exposes read and search (for research and context), draft creation (for human review before sending), and label management. Direct sending is gated: an agent creates a draft, a human reviews and sends. This is the pattern NimbleBrain uses internally and recommends to every client.
Permission scoping. The service account’s domain-wide delegation scopes determine the ceiling. The MCP server narrows further: which Drive folders, which calendars, which Gmail labels. An agent working on sales operations might access the Sales Team shared drive, the sales@ calendar, and the deals@ Gmail inbox, not the CEO’s personal drive or HR’s calendar.
Microsoft 365
Microsoft 365 integration uses Azure AD with either delegated permissions (act on behalf of a user) or application permissions (act as the service). Application permissions are broader and require admin consent. Delegated permissions are scoped to the authenticated user’s access level.
OneDrive and SharePoint. File search, document reading, document creation: same capability set as Google Drive, different auth model. SharePoint adds site-level permissions that the MCP server must respect. An agent with access to the Marketing SharePoint site shouldn’t be able to read documents on the Finance site.
Outlook. Calendar and email follow the same patterns as Google, availability checking, event creation, draft management. The Microsoft Graph API unifies access, so the MCP server talks to one endpoint for mail, calendar, and files.
Notion
Notion’s API is simpler than Google’s or Microsoft’s. API keys or OAuth, with access scoped to specific pages and databases. The MCP server exposes page reading, database querying, page creation, and property updates. Notion’s block-based content model requires the server to handle format conversion: an agent creates content as structured text, and the server converts it to Notion blocks.
Project Management: Linear, Jira, Asana
Project management integrations close the loop between agent work and team visibility. An agent that completes a task should update the ticket. An agent that discovers an issue should create one.
Linear. Clean GraphQL API, generous rate limits, well-typed schema. The MCP server exposes issue creation, status updates, comment addition, and sprint queries. Linear’s state model (Backlog, Todo, In Progress, Done, Cancelled) maps cleanly to agent workflows, an agent picks up a “Todo” issue, moves it to “In Progress,” does the work, and moves it to “Done” with a comment explaining what it did.
Jira. More complex API, more flexible data model. Custom fields, workflows, and permission schemes vary wildly across Jira instances. The MCP server needs per-instance configuration to handle custom statuses, required fields on transitions, and project-level permissions. Jira’s webhook system enables event-driven patterns: agents respond to issue creation, status changes, or comment additions.
Asana. REST API with task and project abstractions. The MCP server handles task creation, assignment, status updates, and subtask management. Asana’s custom fields and sections add flexibility that the server maps to typed tool parameters.
The pattern across all three: the MCP server is the governance boundary. The agent creates tickets within defined projects, updates statuses through valid transitions, and adds comments with clear attribution. No direct API access, no freestyle object manipulation.
The Flow-of-Work Principle
The common thread across every productivity integration: agents that operate inside the tools people already use get adopted. Agents that require switching to a separate interface get ignored.
NimbleBrain runs on this principle internally. Our agents monitor Slack channels, create Google Docs, update Linear tickets, and schedule meetings, all through MCP servers with tiered governance. When we embed with clients, the first question isn’t “which AI model should we use?” It’s “where does your team work?” The answer determines which MCP servers we deploy first.
A Deep Agents deployment typically starts with Slack (communication), one document tool (Google Workspace or Microsoft 365), and one project management tool (Linear or Jira). Three MCP servers. Three integrations. The agent operates in the flow of work from day one.
The bidirectional challenge is real, but it’s a solved problem when the MCP server enforces governance. Read broadly, write within bounds, gate high-impact operations for human review. The same three-tier model that governs CRM access applies here, adapted for the specific risks of communication, document, and project management tools.
For how these integrations compose into larger architectures, see integration architecture.
Frequently Asked Questions
Can agents participate in Slack channels?
Yes. An MCP server for Slack gives agents the ability to read messages, post replies, react to messages, create threads, and join channels. Governance controls determine which channels the agent can access and whether it can post proactively or only when invoked. The best pattern: the agent monitors channels for requests and responds in-thread.
What about file access in Google Workspace?
Google Workspace MCP servers can read and write Docs, Sheets, and Slides. Read access for research and context gathering. Write access for creating drafts, updating spreadsheets, and generating presentations. Scope it to specific Drive folders, the agent doesn't need access to your entire Google Drive.
How do agents handle scheduling across tools?
A scheduling agent reads calendar availability from Google Calendar or Outlook, checks preferences and rules from the business context, proposes times, and creates events. The MCP server handles the API complexity, the agent just reasons about availability and preferences.
