
FIELD NOTES / PRODUCT DESIGN
AI Foundation—agentic guidelines
Eleven entry points into Drata AI, prototyped against the production codebase. Each one carries the page’s context into chat, and every action waits on a confirmation scaled to how reversible it is.
Overview
Drata is a compliance automation platform. Its job is to help companies prove they’re operating securely—SOC 2, ISO 27001, HIPAA—by continuously collecting evidence, managing controls, and keeping audit trails current. It’s the kind of product where wrong answers have consequences, and where trust isn’t a feature you layer on top—it’s the prerequisite for the whole thing working at all.
Adding AI to this context is a different problem than adding AI to a help center or a settings page. The question wasn’t just what can we automate? It was: what should AI be allowed to do, on whose behalf, with what level of oversight—and how do we make sure every team building into this product is asking those questions the same way? Our job was to help answer that before anyone shipped anything.
Roles & responsibilities
Interaction Design, AI UX Strategy, Cross-functional Collaboration
Tools
FigJam/Figma for collaboration and flows, Claude Chat/Cowork for automating writing and checks against documentation, Notion to house documentation, v0 as a transitional prototyping tool, Claude Code for the design system bounded solution.
Defining how AI should behave
The first thing the team needed wasn’t a product spec—it was a framework. I co-authored the guidelines for AI in Drata’s product: what autonomy levels are appropriate for different types of actions, when an agent should act versus surface and confirm, what events need to be logged, and how to communicate AI-driven changes in a product where transparency isn’t optional.
Principles are easy to write and easy to ignore. The guidelines had to be specific enough to do real work—something a PM or designer could apply to an actual feature decision, not a document that captures a week of workshops and then goes unread.
One concrete output was the trust arc: four AI personalities—Sentinel, Advisor, Collaborator, Operator—that define how AI shows up at different levels of autonomy. Sentinel watches and surfaces. Advisor recommends without acting. Collaborator executes step-by-step with checkpoints. Operator acts in the background within limits the user has already set. Every AI feature in the product could be mapped to one of them, which gave the team a shared vocabulary for a lot of decisions that would otherwise get relitigated from scratch.
AI Personalities

Chat entry points
I owned the interaction model for Drata’s agentic AI—how users enter, how the AI knows what it’s working on, and how it hands work back. That meant more than the chat UI itself. I defined chat as the orchestration layer running beneath four distinct rendering contexts: a utility panel for ambient, context-aware quick interactions; full-screen chat for complex multi-step work spanning sessions; a dashboard for persistent outputs the user returns to; and a canvas for structured review of what the agent has produced. Each context has a specific job and a set of entry points that hand context into it.
I also wrote the entry point guide the design team used for any agentic flow: a diagnostic that asks what mental state the user is in at the moment of entry, maps that to the right pattern and rendering context, and defines exactly what context the entry point hands to chat. Five user mental states, five entry point scopes, and a checklist that surfaces the questions designers miss—like whether an active session already exists for the object the entry point is about to fire on.
In a compliance context, users aren’t just consuming AI output. They’re often the accountable party. A SOC 2 auditor doesn’t care that an agent marked a control as complete—they care whether the person responsible understood what happened and signed off on it. The design had to keep that visible.
Composer

The user stories I wrote for this surface were specific to the compliance context in ways that shaped most of the design decisions. A few examples: the audit trail story required that every agent action be logged with timestamp, triggering input, affected objects, and reasoning—and that any action could be undone directly from the log, not just within the session it happened. The confirmation gate story required that the approval gesture scale with reversibility and scope—a narrow, reversible action gets a passive notification; a broad or irreversible one gets an explicit approval with an affected-object summary. A separate story drew a hard line between “the agent can’t do this” and “you don’t have permission to do this”—because in a compliance product, those require different responses and different next steps.
Agentic Chat Surfaces

Message Thread

User input

Getting the product team building consistently
Writing the guidelines once wasn’t enough—especially on a team growing quickly, with new PMs and engineers regularly picking up AI work mid-stream.
I built two tools to do something about that.
The first was an interactive e-learning module to onboard the product team to the AI guidelines. Not a slide deck. An interactive experience that asked the team to apply the principles to scenarios and figure out where the lines were, rather than just read about them.
The second was a Claude skill: a tool that takes a product doc, feature description, or user value statement and walks the author through an AI opportunity assessment. Is this feature better as an agentic flow or not? What autonomy level fits? What events need logging? Which guidelines apply? It turned a document into a working session, which is a better way to internalize guidelines than reading them and hoping something sticks.
This phase
There’s no clean “before” here because the product didn’t exist in this form yet. There’s no single screen that represents the work—the output was a shared framework, a set of constraints, and two tools that turned guidelines into something the team could actually use.
The decisions made during this phase—what the AI is allowed to do, how users see it acting, how the team thinks about it when building—will be present in every feature that ships after it. That’s the leverage of foundation work: invisible when it’s right, expensive when it’s missing.
The trust arc and AI UX Modes Framework were collaborative—Marcela Espinosa was the primary author. The interaction model, entry point guide, and internal tooling described above were my work. The project was in active development at time of writing.


