Living in Teams and Slack: why agents belong in the flow of work

The portal problem

Most HR technology ships as a standalone web application. Employees get an email telling them a new tool is available, they bookmark the URL, and within six weeks the tab is buried under forty others. Usage data across enterprise HR platforms tells a consistent story: tools that require employees to leave their primary workspace and navigate to a dedicated portal see adoption rates between 8% and 15%. The tool might be excellent. The problem is not capability. The problem is location.

Workforce agents face the same gravity. An agent that can identify internal mobility opportunities, surface learning recommendations, or help a manager plan succession is only valuable if people actually interact with it. And people interact with what is already in front of them. For most knowledge workers, that means Microsoft Teams or Slack. These platforms are open all day, every day. They are where conversations happen, decisions get made, and tasks get assigned. An agent that lives inside these platforms inherits their attention. An agent that lives outside them has to earn attention every single time.

This is not a theoretical distinction. Organizations that have deployed the same agent capability through both a portal and a collaboration channel report adoption differences of 4x to 6x in favor of the in-channel deployment. The agent logic is identical. The intelligence is identical. The only variable is where the interaction happens.

Portal delivery vs. flow-of-work delivery

The differences between portal-based and flow-of-work delivery extend beyond adoption rates. They affect response time, completion rates, and the kinds of interactions employees are willing to have with an agent.

The task completion gap is especially significant. When an agent surfaces a skill assessment or an internal opportunity through a portal, the employee must navigate to the portal, find the notification, and complete the interaction in an unfamiliar interface. When the same interaction arrives as an Adaptive Card in Teams or a Block Kit message in Slack, the employee sees it in their message stream, taps a few buttons, and continues with their day. The interaction fits the rhythm of existing work rather than interrupting it.

The three-layer architecture

Delivering agents into Teams and Slack without coupling the agent logic to either platform requires a deliberate architectural separation. A three-layer design keeps the system vendor-neutral while supporting the unique UI conventions and API requirements of each channel.

Layer 1: Agent core

The agent core contains all business logic, reasoning chains, intelligence layer queries, and governance checks. It knows nothing about Teams, Slack, or any specific collaboration platform. It receives structured input (a user query, a trigger event, a scheduled task) and produces structured output (a response payload, an action recommendation, a card definition in a platform-neutral schema). The agent core is the same regardless of which channel initiated the interaction.

This isolation is critical. When an organization adds a new channel, or when a channel vendor updates their API, or when the organization migrates from one platform to another, the agent core does not change. All channel-specific logic lives in the layers above it.

Layer 2: Channel adapter

The channel adapter translates between the agent core’s platform-neutral output and the specific requirements of a collaboration platform. Each supported channel gets its own adapter. The Teams adapter converts the agent core’s output into Adaptive Card JSON and handles Bot Framework protocol requirements. The Slack adapter converts the same output into Block Kit JSON and handles Bolt API event subscriptions.

Adapters handle four responsibilities: message formatting (translating neutral output to channel-native UI), authentication (validating that incoming requests are legitimate and mapping channel user identities to workforce identities), event routing (subscribing to the correct channel events and translating them into agent core inputs), and state management (tracking conversation context across multiple messages within a channel thread).

Layer 3: Connector

The connector manages the raw network connection to the channel platform. For Teams, this means registering with the Bot Framework service, handling OAuth token refresh, and managing webhook endpoints. For Slack, this means establishing socket connections via Bolt, handling workspace installation flows, and managing API rate limits. Connectors deal exclusively with infrastructure concerns. They know nothing about workforce data, agent logic, or message content.

Microsoft Teams: Bot Framework and Adaptive Cards

Integrating a workforce agent into Microsoft Teams uses Bot Framework, Microsoft’s open-source SDK for building conversational bots. This is a critical distinction: Bot Framework is a general-purpose bot platform that predates Copilot by years. It requires no Copilot license, no Copilot subscription, and no dependency on Microsoft’s AI services. An organization can deploy a fully functional workforce agent into Teams using only standard Teams licenses that most enterprises already hold.

Bot Framework essentials

Bot Framework provides the protocol layer for two-way communication between an external service and the Teams client. The bot registers with Azure Bot Service (a free-tier registration is sufficient), receives a Microsoft App ID and password, and uses these credentials to authenticate message exchanges. When a user sends a message to the bot in Teams, the Bot Framework routes the message to the bot’s webhook endpoint as a structured JSON payload. The bot processes the payload, generates a response, and sends it back through the same channel.

The framework supports several interaction patterns relevant to workforce agents: one-on-one conversations (an employee asking about career opportunities), group conversations (a team channel where the agent posts workforce updates), and proactive messaging (the agent initiating a conversation based on a trigger, such as a new internal opportunity matching an employee’s profile).

Adaptive Cards for structured interaction

Text-based chat is sufficient for simple queries, but workforce interactions often require structured input and output. An internal mobility recommendation needs to display role details, skill match percentages, location information, and action buttons. A skills assessment needs to present rating scales and free-text input fields. Adaptive Cards provide this structure.

An Adaptive Card is defined as a JSON document following Microsoft’s Adaptive Card schema. The card specifies layout containers, text blocks, images, input fields, buttons, and action handlers. The Teams client renders the card natively, meaning the UI looks and feels like a Teams-native experience rather than an embedded web frame. Cards support interactive elements: buttons that trigger bot actions, dropdown selectors for filtering options, and text inputs for collecting feedback. When a user interacts with a card element, Teams sends an invoke activity back to the bot with the interaction data, allowing the agent to process the input and respond with an updated card.

For workforce agents, Adaptive Cards transform what would be a clumsy multi-step text conversation into a clean, structured interaction. An employee receives a card showing three internal mobility opportunities. Each opportunity displays the role title, team, location, and skill match score. A “Learn More” button expands the card to show a detailed breakdown. An “Express Interest” button triggers the agent to initiate the application workflow. The entire interaction happens within the Teams message stream, with no navigation required.

Slack: Bolt API and Block Kit

Slack integration follows the same architectural pattern but uses different tools. The Bolt API is Slack’s official framework for building apps that respond to events, commands, and interactions within Slack workspaces. Like Bot Framework, Bolt is a general-purpose platform. It requires no Slack AI subscription and no premium add-on.

Bolt API essentials

Bolt provides two connection modes: HTTP webhooks (where Slack sends events to a public endpoint) and socket mode (where the app opens a WebSocket connection to Slack’s servers, eliminating the need for a public URL). Socket mode is particularly useful for enterprise deployments where exposing public webhook endpoints requires additional security review.

The app registers event subscriptions to receive relevant signals: messages sent to the bot, slash commands invoked by users, shortcut triggers from message menus, and interactive component submissions from Block Kit elements. Each event arrives as a structured JSON payload with full context about the user, channel, workspace, and interaction type.

Block Kit for structured interaction

Block Kit is Slack’s equivalent of Adaptive Cards. It provides a component-based system for composing rich messages from modular blocks: section blocks for text and images, action blocks for buttons and selectors, input blocks for forms, and context blocks for metadata. Like Adaptive Cards, Block Kit messages are rendered natively by the Slack client and support interactive elements that trigger callbacks to the bot.

The mapping between Adaptive Cards and Block Kit is not one-to-one, and the channel adapter layer handles these differences. Adaptive Cards use a single JSON schema with nested containers. Block Kit uses a flat array of typed blocks. Adaptive Cards support inline text input within cards. Block Kit requires modal dialogs for multi-field input. The adapter translates the agent core’s neutral output into whichever format the target channel requires, handling these structural differences transparently.

What this is not: Copilot and why it does not apply

A common point of confusion is the relationship between Bot Framework and Microsoft Copilot. They are separate products with different purposes, licensing models, and technical architectures. Bot Framework is an open-source SDK for building custom bots. Copilot is Microsoft’s branded AI assistant product. An organization can use Bot Framework to deploy a workforce agent into Teams without purchasing, enabling, or even being aware of Copilot.

The confusion arises because Microsoft has progressively branded more of its AI features under the Copilot name, and some organizations assume that any AI-powered interaction inside Teams requires a Copilot license. This is incorrect. Bot Framework bots registered with Azure Bot Service operate through Teams’ standard bot infrastructure, which is included in Teams licenses that enterprises already pay for. The workforce agent’s intelligence comes from its own platform, its own models, and its own knowledge graph. It does not use Copilot’s models, Copilot’s orchestration, or Copilot’s data connectors.

This distinction matters for procurement. Organizations evaluating workforce agents should not conflate the collaboration channel (Teams or Slack) with the AI provider. The channel is a delivery mechanism. The intelligence comes from the workforce platform. Keeping these layers separate is precisely the point of the three-layer architecture.

Proactive messaging: agents that start conversations

The most impactful flow-of-work interactions are not responses to user queries. They are agent-initiated messages triggered by workforce events. A new internal opportunity matches an employee’s profile, and the agent sends them a Teams message with an Adaptive Card showing the opportunity details. A manager’s direct report completes a certification, and the agent sends a Slack message suggesting updated project assignments that leverage the new skill. A workforce planning model detects a team at risk of capacity shortfall, and the agent sends the HR business partner a Block Kit message with a staffing recommendation.

Proactive messaging requires careful governance. An agent that sends too many messages becomes noise. An agent that sends messages at inappropriate times erodes trust. Effective implementations use frequency caps (no more than two proactive messages per employee per week), relevance thresholds (only surface opportunities with a skill match above 70%), and timing rules (respect working hours, do not send during known company quiet periods). These governance parameters are configured in the agent’s goal engine and enforced by the channel adapter before any message is dispatched.

Identity mapping and security

When a user interacts with an agent in Teams or Slack, the channel provides a channel-specific user identifier. The channel adapter must map this identifier to the user’s workforce identity in the platform’s knowledge graph. For Teams, this typically means mapping the Azure Active Directory object ID to the employee record. For Slack, it means mapping the Slack member ID through an enterprise directory integration.

Identity mapping also determines what information the agent can share. A manager asking about their team’s skill gaps should see aggregated data for their direct reports. An individual contributor asking the same question should see only their own profile. The channel adapter resolves the user’s identity and role before the agent core begins its reasoning chain, ensuring that all intelligence queries and responses are scoped to the correct permission level. This is not a channel-specific concern. It is a security boundary that the channel adapter enforces on behalf of the agent core.

Measuring flow-of-work success

Organizations deploying agents into collaboration channels should track metrics that reflect the delivery model’s impact, not just the agent’s accuracy. Delivery-specific metrics include: message open rate (what percentage of proactive messages are viewed within 24 hours), interaction rate (what percentage of card recipients click at least one button), completion rate (what percentage of multi-step interactions are finished), and time-to-action (how long between the agent’s recommendation and the user’s response). These metrics are channel-specific and should be compared against the same agent’s portal metrics to quantify the delivery advantage.

The goal is not 100% adoption. The goal is that the agent is available where people already are, structured in the UI patterns they already understand, and governed so that its presence in the message stream is helpful rather than intrusive. When those conditions are met, flow-of-work delivery turns a capable agent into a used one.