Agent context, made legible

Signal Inbox — see what the customer did, felt, and experienced before you reply

Surface the context in priority order. Show why each signal matters. Prove it with the evidence behind it.

A support agent opens a ticket and burns the first thirty seconds hunting — across tabs, logs, and order history — for what the customer already lived through. That hunt is the bug. Signal Inbox flips it: one prioritized feed of what the customer did, felt, and experienced, re-ranked live for the issue in front of you, every signal traced to the source that earned it. The one thing it will never do is write the reply. Its only action is Add to my reply context — the agent writes and sends. One argument, made in interface form: customer context you can read, trust, and act on in seconds.

Read the UI copy reference View the lo-fi wireframes Open the full prototype

Fully interactive — move through the whole workspace: Today → Inbox → Sources → Calibrate → Impact, then drive the signature interaction: pick the issue and watch the signal feed re-rank live, with ↑ surfaced / ↓ lowered deltas. Opens in desktop by default; use the toggle for the mobile layout. All data is fictional and original; the sandbox never touches a live system.

The five-screen tour

Five surfaces, one argument

The prototype is a product, not a slideshow — so the tour below is the real interface, rebuilt in HTML. Each surface does one job in the agent's flow: set the model, do the work, prove it, tune it, debrief honestly. Here's what each one is and the problem it removes.

scrToday

Your shift · live

Conversations in queue

1 live · 3 waiting

Avg time-to-context

0:08

▼ from 0:41 last quarter

Signals surfaced today

1,732

every one traced to a source

Replies written by you

100%

Signal Inbox never sends one

① Today · scrToday

Today — the workspace home that sets the model

A landing surface, not an empty queue: a live shift pulse, three "what it does" cards, and a mini-demo that renders the real signal card so the teaser can never drift from the feed.

The "replies written by you — 100%" tile states the boundary before the agent trusts a single signal: this tool shows its work; it never speaks for you.

Live · Billing scrInbox

Signal feed — prioritized for Billing

Surfaced

Payment declined ×2 at checkout2m ago

Transaction

Relevance 92

Surfaced for Billing — a payment failure on the exact issue she raised.

Add to reply context Evidence Not relevant

Possible duplicate hold — $128.402m ago

TransactionProvisional

Relevance 86

Inferred, not confirmed — pinned below the confirmed charge it might explain.

② Inbox · scrInbox

Inbox — the signature, where context meets the conversation

A three-pane workspace: the conversation list, Maya Chen's thread, and the Signal Feed that re-ranks the moment you pick the issue — with ↑ surfaced / ↓ lowered deltas, a per-signal "why surfaced" line, and an Evidence drawer one tap away.

This is the thirty-second context hunt, removed. And the only forward action on a signal is Add to reply context — Signal Inbox surfaces, the agent writes.

scrSources

The confirmed ↔ provisional wall · Billing

Payment declined ×2 at checkout 92

Read "Why was I charged twice?" 76

Provisional — confirm before relying

Possible duplicate hold — $128.40 Provisional 86

The provisional hold scores 86 — above the confirmed read at 76 — yet it sits below the wall. A high score never lets an unverified claim jump it.

③ Sources · scrSources

Sources — the honesty layer that makes the feed checkable

The three honesty laws stated plainly, a five-type signal catalog where shape carries meaning, the scoring model salience × issue-affinity × freshness, and the confirmed↔provisional wall.

Sources turns "trust me" into "check me": every number on the feed has a derivation here, and the wall guarantees an inferred signal can never out-rank something that actually happened.

scrCalibrate

Confirmed-first strictnessHigh

Default ranking

1Payment declined ×2

2Checkout error 500

3Read "charged twice?"

4Possible duplicate hold

Your ranking

1Payment declined ×2—

2Read "charged twice?"▲1

3Checkout error 500▼1

4Possible duplicate hold—

This changes the order you see — never what you send. Confirmed signals reorder; the provisional hold stays pinned below the wall in both columns.

④ Calibrate · scrCalibrate

Calibrate — teach the feed, never the reply

An issue selector and three weight sliders — recency, confirmed-first strictness, emotion sensitivity — drive a live Default vs Your ranking with ▲▼ deltas, all under a persistent Law 1 banner.

A billing specialist and an escalations lead don't want the same things first. Calibrate tunes the order each sees while the provisional wall holds and the reply stays untouched.

scrImpact

45%

faster time-to-resolution

38%

drop in escalations

52%

faster root-cause analysis

40%

less investigation time

The five product laws

1Context, never the reply. The only action is "Add to reply context."
4Uncertainty is labeled, not hidden. Provisional signals pin below confirmed events.
5Shape + label, never colour alone. Type and state carry distinct icons and text.

⑤ Impact · scrImpact

Impact — the debrief, including the line not crossed

Four outcome metrics, a black-box vs Signal Inbox before/after, and a recap of all five product laws.

A debrief that only celebrates wins is marketing. Impact names the outcomes and the boundary the product chose not to cross — so the value and the restraint are read together.

The problem: thirty seconds lost before the first reply

Support tooling usually hands the agent a ticket and a flat activity log — no priority, no traceability, and no read on what the customer actually felt.

When Maya writes "I don't want to be double-charged," the agent already has the answer somewhere — a declined payment, a retry, a duplicate authorization hold. But it's scattered across a billing console, a logs tab, and an order page, in the order it was logged, not the order it matters. So the first move is a hunt, and while the agent hunts, the customer re-explains. The opening minutes burn, the conversation starts on the back foot, and "let me look into that" becomes a stall. The first design decision was to treat that hunt as the bug — to make the customer's history into one prioritized, traceable feed you can read in seconds.

The black box · what most tools expose

Logged in14:02

Viewed order #447114:03

Payment event14:05

A flat, time-ordered log. No priority, no evidence, no read on what mattered for this issue, and no sign of what the customer felt — a history you excavate while the customer waits.

The glass box · what Signal Inbox shows

Surfaced

Payment declined ×2 at checkout2m ago

TransactionConfirmed

Relevance 92

Surfaced for Billing — two declines minutes apart, then a retry, directly on the issue Maya raised.

Add to reply context Evidence

The same payment event, now ordered for the issue and traced to the source that earned it — with the evidence one tap away.

The thesis: surface, explain, prove — but never reply

Three properties, in order. The feed surfaces the right context first. It explains why each signal moved. It proves every signal with the evidence behind it.

Everything in Signal Inbox descends from one idea: customer context an agent can read, trust, and act on. A history that can't be prioritized and can't be checked isn't a tool — it's homework. So the interface becomes the mechanism of trust rather than decoration on a timeline: signals are ordered for the issue at hand, each one is shown with the reason it surfaced, and every reason traces to a source event or replay moment. Trust here isn't a reassuring tone of voice; it's a structural property you can poke at. And the line the product will not cross is just as load-bearing: it surfaces context, the human writes the reply.

Surfaces, in priority order

Pick the issue and the feed re-ranks — what the customer did, felt, and experienced, ordered by how much it matters for the problem in front of you, not by when it was logged.

Explains why it surfaced

Each signal carries a plain "why surfaced" line for the current issue — salience, issue-affinity, and freshness, shown as a reason you can read. Nothing is ranked against something you can't see.

Proves it with evidence

Open the drawer and the signal becomes a replay moment plus the raw source events behind it — with an honest interpretation note. The agent adds it to reply context; the agent writes and sends.

The core decision: a feed that re-ranks for the issue, not a list you sort

The signal feed isn't a filtered table. It's the interaction that turns a flat history into a prioritized read of the issue in front of you.

Each signal is scored salience × issue-affinity × freshness. Pick the issue — Billing, Technical, Returns, Account — and Signal Inbox recomputes every score, re-sorts, animates the reorder, and marks each move with a ↑ surfaced / ↓ lowered delta and a one-line reason. For Maya's double-charge, Billing leads with "Payment declined ×2" at 92; switch to Technical and "Checkout error 500" at 74 climbs instead. But no signal has a "Send" button anywhere. The only forward action is Add to my reply context — a person writes what the customer reads.

Issue lens · Billing

○ Default order

1Payment declined ×292

2Confirmed charge · order #447176

3Viewed billing FAQ41

Provisional · pinned below

◐Possible duplicate hold86

The duplicate hold scores 86 — higher than the confirmed charge at 76 — yet it's pinned below the wall. Law 4: provisional never out-ranks confirmed.

Switch the lens · Technical

▲ Re-ranked live

1Checkout error 500▲674

2Rage-clicked ×4▲472

3Payment declined ×2▼258

Provisional · pinned below

◐Possible duplicate hold▼152

Same events, different issue: affinity lifts Checkout error 500 to #1 and the rage-click climbs with it while the billing signals fall — every move carrying a ↑/↓ delta. The wall still holds.

Add to reply context Evidence Not relevant

This is the signature interaction — run it yourself in the prototype above. The feed resets to the default ordering each visit, so the re-rank is always replayable.

Honesty about uncertainty is the trust-builder

Confirmed vs provisional, the shape of each signal type, and a freshness that decays on purpose. Signal Inbox states what it isn't sure of rather than folding it in.

A customer history is never uniformly certain, and pretending otherwise is how trust dies. When a signal is inferred — a "possible duplicate hold" deduced from two authorizations, not a confirmed charge — Signal Inbox marks it provisional and pins it below confirmed events, even when its raw score is higher. Signal type is carried by shape as well as colour, so the feed reads without relying on hue alone. And freshness decays from 1.0 toward a 0.45 floor over about twelve hours, because a rage-click from this morning matters more than one from last week. Admitting what's uncertain is exactly what makes the confident signals believable.

State = shape first, colour second

● Confirmed — a source event that happened ◐ Provisional — inferred or low-confidence ○ Awaiting — not yet observed ▲ Surfaced — lifted for this issue ＋ Context only — never sent for you

Provisional signal · pinned, not promoted

Possible duplicate hold ◐ Provisional · 86

"Inferred from two authorizations minutes apart — shown so you can weigh it, never promoted above the confirmed charge it might explain." A signal Signal Inbox refuses to treat as settled.

The hardest decision: a wall between context and the reply

Signal Inbox surfaces context. The agent writes and sends. The only action on any signal is Add to my reply context — the boundary is structural, not a label you have to trust.

The moment a context tool can draft or send for the agent, it stops being safe to lean on — a customer reply is judgment, tone, and accountability, and those belong to a person. So Law 1 is physical: no compose action, no suggested-reply button, no auto-resolve anywhere in the product. A signal can be added to the agent's reply context and nothing more. And Signal Inbox is honest about its own limits on the other side of that wall — a provisional signal that could explain everything is shown as exactly that, pinned below the confirmed events, never quietly promoted. "Here's what I'm not sure of" is a feature, not a confession.

Context · what Signal Inbox provides

A prioritized, traceable read of the customer's history.

Surfaced for the issue, every signal traced to a source event or replay moment. The tool's only output is context the agent can add — it cannot write or send.

＋ The reply · what stays human

Written and sent by the agent, every time.

The "replies written by you" tile reads 100% on purpose. No compose, no suggest, no auto-resolve — the customer always hears from a person who read the context.

Possible duplicate hold · 86 held below confirmed 76 · weigh this

The signal that would most tidily explain Maya's complaint is the one Signal Inbox is least sure of — so it surfaces it, labels it provisional, and pins it below the confirmed charge. The agent sees the likely story and its uncertainty, not a confident guess. The wall holds even under the most aggressive calibration.

"Act on it," made literal: a surfaced signal becomes reply context a person uses

Adding a signal to reply context doesn't message the customer. It assembles a clean evidence-backed brief the agent reads, then writes the reply themselves.

Surfacing the right signal is good. Turning it into something the agent can actually act on is better. When you add a signal to reply context, Signal Inbox assembles a brief — the event and its timestamp, the replay moment, the "why surfaced" reason, and the confidence — and stamps it Added to your reply context. It does not message the customer; the agent writes the reply, in their own words, with the evidence in front of them. That round trip — from a re-ranked feed to a reply a person owns — is the most concrete answer to "what does act on it mean?"

Reply context · Maya Chen Billing Added to your reply context

Top signal

Payment declined ×2 · 92

Confidence

Confirmed

Evidence

Session replay · checkout · Today 2:41 PM

Also weigh

Duplicate hold · provisional

No message is drafted or sent. The agent reads this brief and writes the reply in their own words.

This is a static specimen — add a signal to reply context in the prototype above to assemble the live brief and open the evidence drawer.

v1 → v7: sharpening one thesis, not stacking features

Each version defends the same idea — surface context an agent can read, trust, and act on, while the reply stays human — against the easier, less honest version of every feature.

The arc isn't a changelog. Early versions found the product identity and put the signal feed at the centre. The middle versions made the scoring real and built the evidence layer that keeps a signal honest. The late work is where the thesis got defended: the context-versus-reply wall (Law 1), the confirmed↔provisional pin, calibration that tunes the order but never the reply, an Inter system that holds up in light and dark, and accessibility done as real contrast math rather than a checkbox.

v1
Activity log.

A flat, time-ordered list of customer events. It looked like a debugging console, not a product — and there was no thesis yet, just timestamps.
v2
Found the thesis.

"See what the customer did, felt, and experienced — before you reply." The five-screen spine — Today, Inbox, Sources, Calibrate, Impact — and the signal feed taking centre stage as the signature interaction.
v3
Real scoring.

score = salience × issue-affinity × freshness, a live recompute and FLIP reorder when the issue changes, with ↑/↓ deltas against the default ordering — not a canned animation.
v4
The evidence layer.

The Evidence drawer — a replay scrubber, the raw source-event table, a per-signal "why surfaced" line, and an honest interpretation note that states what the signal does and doesn't prove.
v5
Honest uncertainty + Law 1.

Confirmed vs provisional with provisional pinned below confirmed; freshness decay; and the load-bearing rule — no compose, suggest, or send anywhere, only "Add to my reply context."
v6
The confirmed↔provisional wall + calibration.

Made the boundary spatial and tunable: Default vs Your ranking side by side, three weight sliders, "reset to default" as undo, and the provisional wall holding in both columns even under extreme calibration.
v7
Inter system + accessibility, done properly.

A full Inter-based system with a Lookscout-blue palette, a navigation rail that becomes a bottom bar, and shape-plus-label signal types so the feed never leans on colour alone. Dark mode's real failures were accent-as-text colours under the 4.5:1 AA line, fixed with dedicated text-only variables that brighten in dark; the FLIP reorder and drawer reveals honor reduced-motion.

Explore more work

More explorations from the AI Product Design Lab — each a different facet of making AI products people can direct, verify, supervise, and trust.

Steer — intent before generation

Turn an under-specified prompt into a negotiated brief: the model surfaces what it inferred and flags ambiguity before it commits.

View exploration

Ground — verify what AI claims

Every claim traceable to a source with confidence and freshness; unsupported claims flagged; source conflicts shown, not smoothed over.

View exploration

Recall — legible AI memory

A memory layer you can see, attribute, edit, scope, and revoke — personalization as a negotiated, inspectable thing, not a black box.

View exploration

Explore the AI Product Design Lab