PRIYAMWADA PANDEY

WORK

RESUME

CONTACT

PRIYAMWADA PANDEY

HOME

ASIMOV FOR TARS

Designing the Control Layer Behind Asimov, an AI Assistant for Slack.

WORK

Context

TIMELINE

Dec 2023 - Mar 2024

INDUSTRY

B2B SaaS

ROLE

Product Designer

TEAM

Founders, Developers, Me

I led the 0→1 design of Asimov, an AI assistant by Tars deployed in teams’ Slack workspaces to help them access shared knowledge, retrieve past conversations and automate common Slack-based workflows. As the lead product designer, I worked closely with the founders, front-end and back-end developers and early users to shape the product from concept through beta.

Beyond designing the Slack experience, the core work focused on designing the control layer behind Asimov, allowing team admins to manage the datasets feeding Asimov's LLM model, integrate third-party applications and configure RBAC (Role-Based Access Control), while maintaining visibility into Asimov’s performance.

impact

early impact of asimov among pilot teams

82.3%

Adoption in early pilot teams

Measured by the number of companies who installed Asimov compared to those who had joined the beta waitlist.

~74%

Reduction in task-related queries

From ICs, as reported by team managers after introducing Asimov into their Slack team workspaces.

86%

positive feedback from teams

Who were part of the beta release and successfully incorporated Asimov into their team workspace.

Design System Foundations

Interaction Patterns That Shaped the Product

As the product evolved, many of the interaction patterns and UI components I designed for Asimov contributed to the growing Tars design system and were later reused across the company’s product suite. I designed these components to work consistently across desktop and mobile surfaces, ensuring the system could scale as the product expanded.

Market requirement

Designing an AI Assistant That Teams Could Control

There are a number of teams who rely on Slack for communication and collaboration. However, critical knowledge shared in this workspace often gets buried across channels, long-running conversation threads and documents.

Finding the correct information means scrolling through threads, switching between applications or interrupting teammates. This slows down work and breaks productive momentum. As teams grow, these challenges compound, which makes it increasingly difficult to maintain a shared source of truth without adding more tools or manual overhead.

Asimov was designed to address this gap by acting as an AI assistant directly within Slack, allowing teams to retrieve knowledge, reference past discussions and automate common workflows without leaving their workspace.

Example of Asimov retrieving information from connected knowledge sources and presenting it in a structured response within Slack.

Research and analysis

What Teams Needed From the System

While the Slack interaction was user-facing, the real complexity of Asimov lived in the administrative layer behind it. To design this control layer, I needed to understand how teams managed knowledge, permissions and integrations across their existing tools.

I conducted interviews with team leads, CXOs and individual contributors across early pilot teams. These conversations helped uncover patterns in how teams were organizing and sharing information, and where breakdowns would occur when knowledge needed to scale across the organization.

Across 26+ interviews, three themes consistently emerged.

KNOWLEDGE LIVED ACROSS MULTIPLE SYSTEMS

Teams stored knowledge in external documentation platforms, CRMs, shared drives. For Asimov to be useful, it would need to ingest and retrieve information across these systems rather than relying solely on Slack messages.

ADMINS NEEDED CONTROL OVER WHAT ASIMOV COULD ACCESS

ADMINS NEEDED CONTROL over WHAT ASIMOV COULD ACCESS

While teams were excited that Asimov could retrieve information quickly, they also needed confidence that it would access the right sources and respect internal permissions. Admins needed to configure knowledge sources.

NEED FOR VISIBILITY INTO ASIMOV'S RESPONSE QUALITY

Teams wanted to understand how the Asimov arrived at answers, if it was helping and whether it was referencing reliable information. Without visibility into the assistant’s behavior, trust in the system would quickly erode.

HOW MIGHT WE DESIGN A CONTROL LAYER WHERE TEAMS COULD MANAGE WHAT ASIMOV KNOWS, INTEGRATIONS WITH TOOLS AND HOW IT BEHAVES AS USAGE SCALES?

final design

How Teams Configure and Use Asimov

1 Connect the Workspace

Once teams receive access to Asimov, the first step is connecting it as an app within their Slack workspace. This allows the assistant to operate directly inside conversations, where most team collaboration already happens.

From Slack, teams can access the Asimov configuration settings and navigate to the web dashboard, which acts as the control layer behind the assistant. While Slack is where teams interact with Asimov, the dashboard is where administrators configure what the system knows and how it behaves.

Connecting the team’s Slack workspace allows Asimov to operate directly within conversations.

2 Define the Knowledge Base

After connecting Slack, administrators begin shaping the knowledge that Asimov can reference. Channels can be added to Asimov’s dataset so the assistant can retrieve insights from past conversations and shared discussions.

To keep the assistant up to date, admins can enable auto-sync so new messages are periodically incorporated into the knowledge base. Metadata such as the number of messages retrieved from each channel helps teams maintain transparency into what information Asimov is learning from

Connecting the Slack channels as resources to train Asimov on the team's data.

Since team knowledge rarely lives in Slack alone, administrators can also connect external sources such as Notion, Google Drive, and other documentation platforms. This allows Asimov to pull information from across the team’s ecosystem rather than relying on a single source.

3 Extend the System with Integrations

Beyond knowledge retrieval, Asimov also needed awareness of the tools teams used in their day-to-day workflows. Through the integrations hub, administrators can connect platforms such as Google Drive, HubSpot, and other internal systems.

This creates a unified layer where teams can view, manage, and control how Asimov interacts with external tools, ensuring the assistant has the context needed to surface accurate information.

The App Integrations hub where admins can connect and disconnect multiple apps.

4 Enable Automated Actions

With knowledge sources and integrations in place, Asimov can move beyond answering questions to executing tasks.

Administrators can configure what actions the assistant is allowed to perform through connected applications. From updating a deal in HubSpot to creating a note in Notion, Asimov can automate common workflows directly within Slack, reducing the need for teams to switch between tools.

Teams can also build custom tools, allowing Asimov to support workflows unique to their organization. By combining integrations with configurable actions, the assistant becomes more than a search tool, it becomes an active collaborator within the team’s workflow.

Setting actions that Asimov can perform and feature to create custom tools.

With knowledge sources and integrations in place, Asimov can move beyond answering questions to executing tasks.

design process

DESIGNING ASIMOV'S CONTROL LAYER

approach

Designing Asimov’s administrative layer meant tackling multiple complex problems at once. Rather than designing and then shipping the entire system upfront, the Asimov team decided to break the work into smaller features that could be designed, shipped and tested quickly. This allowed Asimov to launch early for teams in beta while we continued improving the product based on real usage and feedback. The process became a cycle of designing, shipping and iterating, which allowed the product to evolve alongside how teams actually used it.

MANAGING KNOWLEDGE SOURCES

The first feature I designed focused on how teams would connect existing datasets into Asimov. For the initial release, we wanted to keep the workflow simple. I designed a dashboard where teams could view the Slack channels connected to Asimov and add more channels to feed its dataset. We shipped this core feature alongside Asimov’s conversational capability on Slack.

First iteration of Asimov with just Slack channels connected as knowledge sources.

However, relying solely on Slack as the knowledge source quickly proved limiting, especially for teams whose information also lived across documentation platforms and shared drives.

In subsequent iterations, I evolved the dashboard into a 'Knowledge Base Management System' that allowed administrators to connect and manage multiple sources.

Second iteration with Slack and local files connected to Asimov.

incorporating advanced integrations

Since teams stored knowledge across multiple platforms, there was a need for a feature where admins could configure these connections. I designed a dedicated integrations section that allowed administrators to connect external tools such as Google Drive, OneDrive, HubSpot and others, enabling Asimov to retrieve and reference information across sources.

In subsequent iterations, this hub was also designed to serve as the source of truth for the Actions section. Administrators could not only connect third-party applications but also control the permissions Asimov had when accessing these tools. Full control over what Asimov could access remained with the admins, they could disconnect an application at any time.

First iteration of the Data Integration hub.

The connected sub-section showing Asimov's current connections.

Designing the actions feature

Over time, we began receiving requests from teams to define custom tools that Asimov could execute. This feature was more complex, so I needed some grounding before beginning the design. I started by studying shipped implementations of this use case. In early 2024, this included OpenAI’s GPT Builder, whose advanced configurations closely matched what teams were asking for.

First iteration of the Actions feature, previously called 'LLM Tool Builder'.

The design evolved through several iterations as I explored different layouts and levels of LLM configuration, while ensuring the experience remained understandable for non-technical users. The first version allowed teams to add custom tools by configuring the tool’s schema and authentication.

In the next release, we expanded the feature’s capabilities. Since the integrations section had already been shipped, and our interviews revealed that teams often performed actions within third-party tools, we introduced the ability for Asimov to execute those actions. For example, a team member could ask Asimov to update a client’s deal in HubSpot and add notes based on a Slack conversation, saving time switching between applications.

Subsequent iteration of the Actions builder feature, called LLM Tools - Builder.

The challenge with this particular feature, for me as the designer, was ensuring teams could extend Asimov's capabilities and customize it to their needs, without creating overly complex configurations.

Early RBAC Considerations

As the first version of Asimov was released, teams began experimenting with it. Access control quickly became a concern. With additional data sources now being connected to Asimov, team leaders and CXOs needed confidence that the assistant would respect internal permissions and only surface information appropriate for different roles.

I went back to the drawing board and after several conversations with the developers, we realized that implementing a full role-based access system at the dashboard level would require deeper backend considerations. As a result, we explored an early workaround.

Team member access settings via the Slack interface

This was introduced directly within Asimov’s Slack settings to manage access during the beta phase. With this approach, Asimov admins could control who had access to the system. We also introduced multiple instances of Asimov so teams could deploy it across different organizational levels — ICs, team leads, executives, and CXOs.

However, this implementation had a drawback. Administrators would need to manage multiple instances of Asimov and update data sources separately for each one. This created friction in the setup process and could become a blocker for enterprise teams adopting Asimov in their workflow. While I continued designing and shipping the next set of features, the backend team began exploring a more robust RBAC architecture. Since I left Tars shortly afterward, the final implementation of this system is not reflected in the designs presented here.

Reflections & Learnings

working on asimov came with challenges and lessons

Designing Asimov strengthened my ability to think beyond individual features and consider how systems, teams, and product strategy evolve together. The project showed me that building AI tools requires more than designing conversational interfaces. Teams building AI-driven workflows also need ways to control what the system knows, how it accesses information, and how it behaves within their workflows. This experience shaped how I approach designing AI-powered systems today.

Cross-functional collaboration

I worked closely with product leadership, developers, sales, and customer success teams throughout the project. These conversations helped me understand how design decisions connect to technical constraints, customer needs, and product strategy.

constraints & resource bandwidth

Some areas required trade-offs due to technical constraints and timelines. For example, role-based access control (RBAC) was initially handled through a temporary workaround during beta. This reinforced how important strong system foundations are for products that need to scale.

designers influencing roadmap discussions

While the Actions feature introduced automation, focusing on RBAC earlier might have created a stronger foundation for enterprise adoption. This experience reinforced that designers should help shape what gets prioritized in the product roadmap.

RESUME

CONTACT

priyamwada.dzn@gmail.com

RESUME

CONTACT

priyamwada.dzn@gmail.com

RESUME

CONTACT

priyamwada.dzn@gmail.com

RESUME

CONTACT

priyamwada.dzn@gmail.com