Banking · AI research agent

Deep Research Agent

An AI agent that writes client and market briefings for bank relationship managers, with a source behind every claim. I led UX research and product design from a blank page.

Role
Lead, UX research and product design
Users
Relationship managers, analysts, compliance
Made
60+ screens and a component library
Platform
Web and mobile, in English and German
The problem

A banker must defend a briefing to a client. A blank wait and an unsourced draft leave nothing to defend.

What I did

I made the agent’s work visible while it runs and every fact checkable: five named stages and a source on every claim.

The result

60+ screens, key ones in five states, in English and German, from one library. No outcome metrics to share.

A briefing in 30 seconds: one line in, five agents run, every claim comes back with its source. Film and soundtrack made in code from the product screens on this page, with an AI voice-over.

The problem

The agent can gather a meeting’s research in minutes, but nobody trusted it: while it ran the screen was blank, and when it finished every fact sounded equally sure.

Relationship manager
Asks
“What do I need before my meeting?”
Gets
A briefing with no training needed.
The analyst
Asks
“Can I trust this number?”
Gets
A source next to every claim.
Compliance
Asks
“How did it get there?”
Gets
Every step on screen, a person at both ends.

My part

I led UX research and product design, from a blank page to 60+ screens and a component library. Research defined three readers and the question each asks before trusting a briefing.

How a briefing gets made

Four steps, all visible. The agent never works out of sight, and nothing reaches the meeting without a source.

Key decisions

The idea behind every decisionTrust comes from being able to check: the agent’s work is visible while it runs, and every fact can be traced afterwards.

01 · Start

Start from a briefing type, not a blank prompt

Most AI tools open on an empty prompt, which assumes you know what to ask. Here you pick one of four briefing types and see its sections first; all four share one flow.

Instead of
An empty prompt box
Chose
Four briefing types, sections shown up front
02 · Briefing

Errors explained at the field, not in a banner

The agent needs one input, what the briefing is for, so that’s the only required field. If it’s empty, the message sits under it and the disabled button says why.

Instead of
An error banner at the top of the form
Chose
One required field, the message right under it
03 · Running

Show the agent’s work while it runs

Minutes of blank screen read as a black box. The screen names five stages, the current step and every source as it’s read. A stage that needs a person turns amber.

Instead of
A spinner and a wait
Chose
Five named stages, every source as it’s read
04 · Report

A source on every claim

A confident draft is a risk if nobody can tell which facts are solid. Every claim links to its source, and a claim without one is marked as a gap, not filled with a guess.

Instead of
A polished draft with no sources
Chose
A source tag on every claim, gaps marked
05 · Export

One page to take into the meeting

The report is for working in; the meeting needs one page. Export briefing sets it as a printable page: what matters at a glance, four talking points, the open items, and every line still numbered to its source. The gap travels with it.

Instead of
The working report, exported as it is
Chose
One page for the meeting, sources kept
06 · Sources

Catch a broken feed before a run does

An expired feed key would break a run halfway. All files, feeds and links live in one hub with a live status, so a broken source shows up first.

Instead of
Finding a broken feed when a run fails
Chose
One hub with a live status per source
07 · One system

One component set for two languages and the phone

Every screen exists in English and German from the same components, so a change lands in both. On the phone, Live Prep runs the same five stages.

Instead of
Separate screens per language and device
Chose
One component set for both languages and the phone

Results

60+ screens, each key screen in five states, in English and German, from one component library. No outcome metrics can be shared.

How success would be measured

  • Prep timeMinutes from opening a briefing to having it ready for the meeting.
  • Edits before useHow much a relationship manager changes in a briefing before relying on it.
  • Failed runsRuns that break on a missing or broken source.

What I’d change

  1. Running The steps have engineer names

    “Semantic Grounding” means nothing to a relationship manager. It names what the system does, not what the reader gets.

    Fix

    Lead with plain words, like “Adding sources”, and keep the technical name as a detail.

  2. Mobile Mobile was a guess

    Nobody tested the phone screens with relationship managers first.

    Fix

    Test one rough screen before building the set.

Numbers: no outcome numbers can be shared; counts come from the design file.

About the screens: rebuilt in HTML from the design file. Client names, dates and figures are examples.