Beyond UI: what it takes to design an AI teammate
Shipped in
2026 (Private Beta)
My role
Product design, tone of voice, message architecture
Team
Myself + Data Analyst + Front-end Engineer
For most of Metica's history, answering a customer's question meant an analyst pulling SQL, writing a Slack message, and hoping it landed. Metica AI replaced that loop. A Slack-native agent, living inside shared channels, delivering analysis in plain language with a consistent voice.
The impact
20-40 hrs analyst time saved per week, across 81 live
81 live games covered by automated weekly reporting
~80% of messages approved without edits in early beta
Three agents, one voice
The system is built on three agents working in sequence. An Analytics agent runs the SQL, calculates uplift, and produces a raw analysis. A Knowledge agent, built on Onyx, holds context at three levels: Metica-wide, per customer, and per game. Metica AI picks up both, formats the message according to guidelines I wrote, and posts it for human approval before anything reaches a customer.
The design challenge was making that pipeline feel like one thing. Customers don't need to know about the handoffs. They need to read the message, trust it, and act on it. Every decision about tone, format, and structure was in service of that.
Linear as the connective tissue
We used Linear as the handoff layer between agents. The Analytics agent opens a ticket and assigns it to Metica AI. If Metica AI needs more data, it assigns back. Customer Success uses Linear labels to route work. It sounds mundane, but it mattered: every message became inspectable. You could always trace where it came from, what context it used, and why it said what it said.
Loosely coupled agents with visible handoffs turned out to be easier to debug, easier to trust, and easier to improve than a single opaque system would have been.
A human in the loop, by design
No message reaches a customer without approval. Every outbound message routes through a private #metica-ai-approvals Slack channel first. Reviewers have four options: approve and send, edit inline (the agent revises and re-posts), send back to the analyst to generate more data, or drop it entirely.
The approval flow was non-negotiable from the start. The agent is confident when it has the data to be confident. When it doesn't, it stays quiet. That constraint shaped a lot of the tone decisions, since a system that hedges or guesses loses trust faster than one that says nothing.
Writing the agent's voice
The agent's job isn't done when the data is correct. It's done when the customer reads it and trusts it. I wrote the message format guidelines (KNOWLEDGE.md) and the tone of voice doc that drives every response. The rules: lead with outcomes not process, write like a sharp Slack message not a report, no hedged guesses, no AI clichés, no filler sign-offs.
The tone also shifts contextually. Confident when reporting wins. Calm when flagging anomalies. Direct when something went wrong. Getting that right took iteration across real messages before it felt consistent.
How it evolved
It started as a weekly performance recap. Over time the same agent extended to handle @mentions in any shared channel, follow-ups on existing threads with full context retained, and direct replies to client questions. Same voice, same approval loop, more surfaces.
The expansion happened because the foundation held. Once the tone and format were stable, adding new trigger points was mostly an engineering problem.
One teammate, not three agents
The first internal demo was received very well, in particular from the Customer Experience team head. His reaction said more than any metric could.
