AI Agent Actions
Overview

Teaching an LLM to touch data safely

To help Ada evolve from NLU chatbot to LLM-powered AI Agent, I designed Actions (how it calls APIs) and co-led design on Rules (guardrails on tool use) — enabling Ada to lauch the first AI Agent for CX in Fall 2023.

First to market

AI Agent for customer service, launched October 2023

2x

revenue growth quarter-over-quarter after the AI Agent launched

>50%

adoption among client deployments
Role
Product Designer
Team
Actions: 1 PM, 1 EM, 5 Engineers
Rules: 1 other Product Designer
Timeframe
Apr — Oct 2023 (7 months)
SCope
End-to-end design, user research, AI/ML application, prototyping
TL;DR:

Key Themes

Guardrails you can't misconfigure

The LLM decides when to act, but it can never edit endpoints, tokens, or input/output values. Safety is built into the architecture, not left to configuration. Rules are checked by the system, not the LLM, so they hold 100% of the time.

"Policies" would be renamed "Rules".

Rethinking dynamic data for LLMs

"Variables" as fill-in-the-blanks made sense for prebuilt flows. In a generative system, dynamic data becomes whole concepts an LLM can reason over. For this feature, we added the concept of "inferred data": the AI figures out how to find what it needs in the conversation, but this data can't be used within trusted guardrails like Rules.

A diagram comparing how the declarative and generative systems make use of variables.

Making the technical feel touchable

Ada's users were often non-technical. Inspired by Spotify's API docs, I designed an interaction where users test a real API call, then simply click the parts of the response the AI should see — no JMESPath syntax required.

View full process

See the full context, including my end-to-end process, trade-offs, and learnings.

Enter Password