The surface in which users interact with an AI agent has a dramatic impact on adoption, engagement, and long-term stickiness. This often matters more than the underlying capabilities of the agent itself. Through first-hand experience building and deploying AI tools at Aloa, we discovered that moving the exact same AI functionality from a standalone interface (Claude Code) into a familiar work surface (Slack) led to significantly higher usage and a qualitatively better experience. This pattern is validated by consumer products like Poke (an AI assistant that lives in iMessage) and has direct implications for how we architect AI solutions in verticals like healthcare.
Core Concept: Form Factor as an Adoption Lever
"Form factor" in this context refers to the interface surface where an AI agent lives and where users interact with it. The thesis is simple: AI agents deployed into surfaces users already inhabit daily will see higher adoption, lower friction, and greater long-term retention than functionally identical agents deployed as standalone tools.
Why It Works
- Zero context-switching cost: Users don't have to leave their workflow to access the AI. It's already in the tool they have open.
- Familiar interaction patterns: Users interact with the AI using the same gestures they use with colleagues, like @mentions, emoji reactions, file sharing, and threaded replies. No new UX to learn.
- Multi-device continuity: Platforms like Slack and iMessage already sync across phone, desktop, and wearables. The AI agent inherits this portability for free.
- Lower perceived effort: Even when performing the same task, interacting via a chat bot in Slack "felt more fun" and less like "work" compared to a terminal-based interface.
Case Study: Aloa's Sales Intelligence Agent
The Problem
Aloa's sales process involves complex technical scoping across multiple client calls. Requirements, feature lists, and integration details are spread across call transcripts, internal documents, and third-party API documentation. Manually consolidating and validating all of this is time-consuming and error-prone.
Phase 1: Claude Code (Standalone)
The team built an AI agent with access to the full corpus of internal documents and sales call transcripts. Using Claude Code locally, the agent could:
- Consolidate features and requirements from multiple client calls into a single view
- Look up third-party API documentation for required integrations
- Cross-reference discussed features against actual API endpoints to validate feasibility
- Dynamically search call transcripts on demand for specific details
As a result, the agent delivered significant efficiency gains and improved accuracy by catching integration issues that would have been missed in manual review. However, the experience still felt like "work" and was limited to one user at a time.
Phase 2: Slack Bot (Embedded)
The same agent was repackaged as a Slack bot using the Claude Agent SDK and deployed into existing sales channels. Functionally identical to Phase 1.
The result was a notable increase in usage, even by the original developer who already had direct access via Claude Code. The team could now collaboratively interact with the agent in existing sales channels. The experience felt more natural and enjoyable, and the tool became part of the daily workflow rather than a separate step.
External Validation: Poke by Interaction
Poke is a proactive AI assistant that integrates with email, calendar, and other productivity tools. Its differentiator is its delivery surface: it lives inside iMessage (with support for WhatsApp and Telegram). Despite general skepticism toward standalone AI assistant apps, the iMessage form factor drove meaningful personal adoption. This reinforced the same pattern observed with the Slack bot. Users who wouldn't download a dedicated AI app engaged regularly when the same capabilities were delivered through a messaging platform they already use throughout the day.
Application to Healthcare: The Case for EMR Integration
The Problem with Standalone Healthcare AI Tools
Aloa built a standalone application for a healthcare client that allowed clinicians to drag-and-drop medical documents, generate AI-powered reports, and re-upload results to their chart system. While the tool delivered clear value, the form factor created friction: it was a separate application outside the clinician's primary work environment (the EMR). Initial enthusiasm is likely to degrade over time as the overhead of switching between tools compounds.
The Solution: HL7 FHIR Integration
Aloa is actively exploring an HL7 FHIR integration to embed the AI agent directly into the clinician's EMR workflow. This mirrors the Slack bot and Poke patterns: bringing the AI into the native work surface rather than asking users to come to the AI.
For the marketing team, the following technical context may be helpful:
- HL7 FHIR (Fast Healthcare Interoperability Resources): The modern standard for exchanging healthcare data between systems. It provides RESTful APIs that allow third-party applications to read and write clinical data within an EMR.
- EMR (Electronic Medical Record): The clinician's primary work surface, much like Slack is for a knowledge worker or iMessage for a consumer. This is where clinical data lives and where care is documented.
By integrating via FHIR, the AI tool can surface insights, generate reports, and assist with documentation directly within the EMR. This eliminates the context switch and replicates the adoption dynamics seen with the Slack bot deployment.
Key Takeaways
Same AI, different adoption curve. The underlying model and capabilities are necessary but not sufficient. The deployment surface is a critical variable in whether users actually adopt and stick with the tool.
Meet users where they already work. Slack for teams, iMessage for consumers, the EMR for clinicians. The best AI agent is the one that doesn't require the user to change their behavior.
Natural interaction patterns drive stickiness. When users can @mention an AI bot, share files with it, and use emojis, the same way they interact with colleagues, friction drops and engagement rises.
Standalone tools create compounding friction. A separate app may impress in a demo but degrade in daily use. Integration into existing workflows is what makes AI tools sustainable.
In healthcare, the EMR is the work surface. HL7 FHIR integration is the mechanism to bring AI into that surface, and it's the same strategic play as putting a bot in Slack or an assistant in iMessage.