Scaling an AI agent to 82% pilot adoption through configurable workflows
Shipped (Beta)
Jan 2024
Industry
B2B SaaS
Role
Product Designer
Team
Founders, Developers
TL;DR
As generative AI capabilities emerged in 2023, we saw an opportunity to rethink workplace productivity: instead of asking people to switch between tools, could an AI agent help them work directly where conversations already happened?
I designed Asimov from its first prototype into a broader AI teammate inside Slack, creating experiences for knowledge discovery, app integrations and automated workflows. The beta release helped the Tars team reduce repetitive task-related queries by ~74%.
Pilot adoption
82%
Reduction in queries
~74%
Positive feedback
86%
Core Features
From thread summaries to an AI-enabled workspace
The product began with a single capability: summarizing Slack threads. Each release expanded what Asimov could understand, connect to and eventually do on a team's behalf.
Knowledge Dashboard
Teams connected sources like Notion and Google Drive so Asimov could answer questions using company knowledge beyond Slack. Admins could monitor sync status and control how often each source was refreshed.
Integrations Hub
One place to connect an app, see what it's linked to and what information Asimov is accessing from it.
Action Configuration
Teams configured third-party app actions and built custom ones that, combined with Slack context, enabled Asimov to automate recurring workflows.
Opportunities & Research
Designing an AI that could do more than answer
I interviewed customer success, sales, engineering, design and marketing to understand how work moved across conversations, tools and teams.
Rather than validating a specific feature, I wanted to identify where an AI teammate could meaningfully participate in daily work and boost productivity.
Opportunity 1: Conversations were only the beginning
Slack conversations often triggered work elsewhere.
Customer-facing teams moved from a discussion to updating HubSpot, writing reports or sharing project updates, carrying the same context across multiple tools.
Summaries reduced reading time, but they didn't reduce the work that followed.
Example scenario of Asimov summarizing threads.
Opportunity 2: No two teams worked the same way
Engineering wanted GitHub workflows, sales wanted CRM updates and marketing wanted content generation. The pattern that emerged was a need for flexibility.
Instead of designing automations for every use case, I designed a system that let teams define their own actions on top of connected tools.
Example scenario of Asimov integrating with other apps.
Deep Dive
Designing the foundation for Asimov
Asimov's experience started with a simple setup: connect Slack, define knowledge sources and choose what context the AI could access.
Once configured, teams could interact with Asimov directly inside Slack, where it used that context to summarize conversations, retrieve information and complete workflows.
Building trust through knowledge controls
Asimov's usefulness depended on the context it could access. I designed the knowledge setup experience to help teams connect relevant sources while maintaining visibility into what information the AI could use.
The experience balanced flexibility with control: teams could add different knowledge sources, select specific Slack channels and monitor sync status from one place.
Connecting AI to the tools teams already used
Knowledge answered questions based on databases, but real work happened in tools like HubSpot. I designed the integrations experience to make connecting external systems feel transparent, showing what was connected, what data Asimov could access and where teams could manage permissions.
This helped position integrations as something teams could understand and trust, rather than a hidden system running in the background.
Configuring custom actions
No predefined set of actions could cover every team's workflow. Instead of shipping one-off automations, I designed a system that let teams decide what Asimov could do and define new capabilities as their needs evolved.
Teams could enable or disable built-in actions for connected tools and create custom actions through a configurable schema, giving them control over both permissions and extensibility.
Blockers
Trust became the biggest design challenge
Early versions of Asimov focused on what the AI could do. As its capabilities expanded, a different question emerged: who should be allowed to configure those capabilities?
A full role-based permission system required backend support beyond the beta timeline. I designed the future access model while relying on Slack's existing administrator permissions as a temporary solution.
Reflections
What I'd take into the next project
Power requires permissions, not just capabilities
As Asimov evolved from a summarizer to knowledge access and taking actions, I realized that trust depended as much on permission models as on AI capabilities.
Today, I would design governance alongside the feature instead of treating it as a later phase.
AI products become platforms faster than you expect
What started as a single Slack capability quickly expanded into a system of knowledge, integrations and custom actions.
The project reinforced the importance of designing scalable foundations that can accommodate new capabilities without breaking the entire experience.