Video summary

Agentic Design Process at Mercury

Main summary

Key takeaways

Technology

Technological Concepts & Product Ideas (Agentic AI for Fintech)

“Agentic design process” for AI-assisted banking (Mercury “Command”)

Mercury’s “Command” experience is designed so an LLM agent can both:

  • Answer questions using account data, and
  • Take actions such as navigating to dashboards, creating drafts, or initiating money movements.

Mental model shift vs. traditional banking UI

  • Traditional fintech: users navigate via sidebar/home to find information.
  • Command: users lead with intent in chat, and the system then:
    • Takes them to the right page with relevant filters already set, and
    • Can also perform actions.

Core capability: context → thinking → legible results

The agent:

  1. Retrieves context/data
  2. Performs “thinking/crunching”
  3. Produces legible outputs without requiring users to calculate or hunt through hidden UI controls.

Deterministic action confirmation for safety

Because real finance operations have high stakes, the agent must use structured UI confirmation (e.g., buttons/canonical controls) rather than “casual chat execution” to ensure users intentionally approve actions.

Key Product Features Highlighted

Search + chat combination

  • Early exploration focused on merging search and chat so the system can:
    • Interpret intent, and
    • Present relevant results.

Cross-page agent presence & navigation

  • Command is accessible via a floating chat popover meant to “live” across the dashboard, enabling users to ask questions anywhere.
  • A major UX goal is that LLM-generated links must be reliable, so navigation is handled with backend-controlled link generation rather than random links.

Data insights via natural language

  • The agent can fetch time-bounded data (month/quarter), compute comparisons, and generate a financial summary.
  • Example:
    • “What are my top transactions from last quarter?”
    • The system links to the transactions page with details opened.

Action workflows with elicitation and drafts

Example: “Transfer money from Treasury to checking”

  • The agent performs elicitation, asking follow-up questions to gather missing parameters (initially in plain text), such as:
    • source account
    • destination account
    • amount
  • It uses a reasoning state / tool-call style progression while collecting required inputs.
  • It creates a draft money movement object (a canonical) and requires explicit user confirmation before proceeding.
  • It supports edit-after-draft:
    • If the user changes dates/amounts, the UI re-enters an editable flow,
    • A new draft is generated,
    • The experience returns to confirmation.
  • Planned improvement: replace some free-text elicitation with multiple-choice options.

Safety & UX constraints for fintech

Mercury emphasizes avoiding “eager execution” and prioritizing correctness, since money movement is higher stakes than typical assistant actions.

Cards management features

  • The cards page supports spending monitoring and actions such as:
    • Freeze cards
    • Merchant locks

Design Process, Guides, and Review/Tutoring Elements (How Mercury Teams Build)

Prototyping approach

The team began with high-level, loose concepts and high-level diagrams to align on the system and user mental model.

They then iterated through:

  • Low-fidelity concept exploration (e.g., chat on homepage, back/breadcrumb patterns)
  • Stakeholder previews using screenshots/links and Figma walkthroughs
  • Vibe coding to simulate chat/interaction timing that Figma prototypes can’t capture well

Why vibe coding

  • Turn-by-turn chat prototyping in Figma is difficult.
  • Vibe coding tools referenced include:
    • Cursor
    • V0
    • Magic Patterns
    • Figma Make
  • Limitation encountered:
    • Early vibe code depended on deterministic backend behavior, which didn’t fully match non-deterministic agent response patterns.
  • Mitigation:
    • They later added a more “working system prompt” integration.

Ground truth requirement

A key takeaway: designers needed to work as close to production code / real data / real system prompt as possible to validate the true response architecture and user experience.

Product reviews cadence

  • Reviewed weekly in leadership/product review meetings (most Wednesdays), starting early in the year (example: Jan 7).
  • Early reviews focused on scope and architecture decisions, including:
    • homepage
    • insights
    • sidebar
    • where Command lives
    • which workflows the system supports

Handling exec stakeholder feedback

  • Feedback was captured via Figma comments tied to prototypes/states (including clarity of canonical object states like editing/created/draft).
  • Follow-ups happened in:
    • later workshop/product review cycles, or
    • sometimes quickly via Slack

UI Craft Details for Agentic Data Primitives

Designing “data primitives” inside conversation

A major emphasis is on:

  • Typography and hierarchy, and
  • Canonical UI rendering for objects like:
    • recipients
    • vendors
    • transactions
    • invoices

Craft-iteration example (Craft Crit)

  • Designers aligned text weight/size consistency so visual cards and reference values don’t cause confusing eye jumps.

Data primitive visual consistency

  • Reuse existing Mercury design system visuals (cards, avatars/user profile visuals) when rendering conversation objects.

Invoice visual exploration outcome

  • The team explored showing file attachments inside the invoice primitive, but removed it due to confusion/less clean presentation.
  • Relevant information remained represented as text.
  • The team remains open to revisiting visuals later if they improve clarity.

Reasoning / “Thinking State” UX for Agents

Reasoning state debate

The team discussed whether to show the agent’s “thinking.”

  • Observed issues:
    • long “thinking” output (tool calls / chain-of-thought-like detail) can feel too slow
    • it can overwhelm the UI

Final direction

  • Use a succinct loading/thinking line summarizing what the agent is doing (e.g., “searching for card data…”).
  • Offer an option to expand for deeper details later.

Main Speakers / Sources

  • Jay (host/interviewer): explains context and asks process questions
  • Carol (Mercury designer): primary speaker describing the agentic design process and prototypes
  • COO Jason (exec feedback referenced in Figma comments): e.g., canonical state clarity
  • Wendy (designer): mentioned as leading/working on reasoning-state animation discussions
  • Mercury leadership / product review group: recurring stakeholder feedback and alignment

Original video