Conversational Design Natural Language Processing Sentiment Analysis Generative AI

[****]

A working rebuild of a multi-agent conversational support tool I designed at a previous company. The original never shipped.

This is my independent rebuild — the architecture, the classifiers, the response logic, the demo — built to prove the system can do the harder thing: read how a person is actually doing beneath what they say, and respond accordingly.

03 — The people

Frontline workers and government employees

The original product was scoped for people who carry load for a living. The personas anchored that scope.

Jakob B.

Firefighter & hazmat technician
Missoula, MT

Recovering High-risk role Stoic

Mindset

• Recovering from second-degree burns taken during a chemical plant emergency
• Talks about getting back to light duty, not about the doubts that come with the recovery
• Frames vulnerability as weakness; turns inward when overwhelmed
• Will engage with the product if it doesn't feel like therapy

Bravado as armor. Says “I'm good” even when he isn't.

Full persona PDF →

Evelyn R.

Document examiner & title clerk
San Diego DMV

Caregiver Working parent Sandwich generation

Mindset

• Primary caregiver for two parents with advanced dementia
• Mother of two teenage sons; the home shift starts the moment the work shift ends
• Didn't know she was burned out; a friend told her
• Most likely to attribute exhaustion to personal failing rather than depletion

Self-erasure. Treats her own needs as the line item she cuts first.

Full persona PDF →

Kyler Z.

Advanced EMT
Cobb County, GA

High-adrenaline Identity-fused Skeptical

Mindset

• Good at the job and addicted to the urgency of it
• Coworkers worry he's burning himself out; he'd tell you he's fine
• Sees calm as boredom; the next call is the regulator
• Will engage if the product feels useful in a way he can quantify

Deflection through busyness. Movement as the substitute for processing.

Full persona PDF →

The pattern that shows up in all three is the same: bravado, deflection, denial. They say one thing and mean another. The product's job is to read the gap and not respond to the surface.

04 — Three types of people

Why personas alone weren't enough

Personas tell you who you're designing for. They don't tell you what state someone is in when they show up. In a product like this, the same person is a different user at week one, week twelve, and year three — and treating all of them the same is how engagement collapses.

I borrowed an archetype model from Nielsen Norman Group's work on complex applications. Three states the same human moves through: Learner, Legend, Legacy. The personas don't map one-to-one to the archetypes — each persona can occupy any of the three states depending on where they are in their journey. The archetypes are the design lens. The personas are the actual people.

The takeaway from the second slide is the framing the rest of the product hangs on: Learners blame themselves for not finding features. Legends creatively exploit shortcuts. Legacy users want it the way it was, and will tell you (in caps) when it isn't. A behavioral support tool that doesn't adapt to those states is going to feel wrong to everyone — too hand-holdy for the Legend, too brisk for the Learner, too unfamiliar for the Legacy.

05 — Scaffolding

Meeting users where they are

The intro flow is the first place the system has to demonstrate that it sees the user as more than a generic new account. Three different opening sequences, one per archetype, calibrated to where the user is — emotionally, cognitively, and in terms of how much they want to be talked to.

Learner

Basic onboarding — Kyler

Short, low-pressure framing. No vocabulary the user has to look up.

Legend

Deeper engagement — Jakob

Belief-and-mindset framing for the user who is already past the surface.

Legacy

Retention — Evelyn

Identity-affirming language. The product's job here is to remind the user why they keep coming back.

Three intros, same product, three different reads on what the user actually needs in the first 30 seconds. The shape extends to every part of the experience downstream — the questions the classifier prioritizes, the tone of the response generator, the moments the system chooses to stay quiet.

Note: the intro card screenshots above still show the original product's name — they'll be re-rendered once the rebuild's product name is set.

Service blueprint

Every technology in the system — and where it sits in the service — in one interactive view.

07 — Product strategy & model design

What the product teaches, what it avoids

For an AI-first product, model design and product strategy are the same conversation. The strategy statement says what the product is for. The objectives table below says what the model is allowed to do. They collapse into one artifact — and if they don't, one of them is fiction.

Strategy. Help users self-reflect through conversational support.

The objectives table is a scoping tool for the classifier and response layers and the grading criteria for Section 11 (the feedback loop). It defines the topical range the model is allowed to operate inside, and the categories where it should decline, deflect, or hand off. A therapeutic-support tool that tries to teach everything ends up teaching nothing — worse, it starts practicing outside its lane.

Below that sits the technical layer — the decisions that shape how the model actually represents the world. These are placeholder-level right now (revisit when the embedding and training concepts are more solid), but the shape matters: some decisions are the designer's to make, some are the model's.

Placeholder — created during a CME295 follow-along session. Revisit once the embedding and training concepts are more solid.

08 — System prompt anatomy

Where the intelligence actually lives

The system prompt is the core intelligence of the bot. It isn't code — it's language that shapes how the model behaves in every conversation. Most of the product intelligence lived here, not in the model weights or the infrastructure. That's the leverage point.

The prompt was organized into seven sections, each doing distinct work:

Requirements is the load-bearing section. Twenty-three rules, each with a description of why it exists, not just what to do. The reasoning matters because a rule without a why becomes brittle the moment the model encounters an edge case the author didn't anticipate.

Rolling memory windows. The prompt carried memory across four time horizons — the last 60 days, 30 days, 7 days, and 1 day. That let the bot reference patterns in the user's life over time without making them re-explain themselves every session. Memory here is a feature of the prompt, not the model.

What made the prompt unusual. The reasoning behind each rule was included, not just the rule itself. Some rules used direct, human-voiced language (“Hey. Eyes on me for a sec.”) — the author understood the model needed emphasis, not just instruction. Emotional safety was treated as a design constraint, not an afterthought. The anti-parroting and no-forced-choice rules are the fingerprints of someone who has watched a lot of therapeutic conversations fail in the same handful of ways.

Notes carried into the rebuild. The 23 requirements are the starting point for this build's requirements. Memory windows are treated as a first-class feature to design for, not an afterthought. Crisis handling (988) is explicit. The “not a therapist” framing sets user expectations correctly from the first turn.

Placeholder — attribution notes will be added as authorship becomes clearer during the rebuild.

Reference — What language is doing

Eight jobs a sentence can hold

A basis document for everything that follows. Most language isn't primarily transferring information — it's performing one of several distinct functions. Classifying an utterance by its function, not its content, is the first move in both signal detection and reply strategy: a system that answers a social-connection message with a representation-style reply is being accurate and wrong at the same time.

11 — Human in the loop

Reinforcement Learning from Human Feedback

The debugger interface shown in the rebuild — thumbs up / thumbs down grading beside each response — is a working RLHF (Reinforcement Learning from Human Feedback) implementation. It's the same methodology major AI labs (Anthropic, OpenAI) now use to teach models what good responses look like. The interface was built before the methodology had a name attached to it.

The loop is the whole point. A single graded response teaches the model almost nothing; a thousand graded responses shape a personality that stays inside its lane. The grading criteria come directly from the objectives table in Section 07: a response is desirable if it aligns with what we teach, undesirable if it crosses into what we avoid. That's the whole rubric.

Placeholder — grading criteria to be defined once Strategy and Objectives are more solid. Worth noting in portfolio context that the interface design preceded the naming of the methodology it now implements.

13 — Comparison

What it actually changes

Same persona. Same opening message. Different system behavior over a four-turn exchange. The tags above each turn are the design intent — scan them vertically and the difference reads instantly.

A “turn” is one full back-and-forth: user says something, system responds, conversation state updates. Turns are the unit a designer thinks in because the system makes a decision at every turn — what to perceive, what to remember, what to say, what to suppress.

15 — Modern AI UX patterns

Translating this into the language product teams actually use

The design decisions on this page have specific names in the vocabulary that modern AI product roles are hiring against right now. This section maps what the system does to what those hiring managers and design leads recognize on a resume or portfolio conversation.

Suppression as a first-class UI element. Most AI products hide what the model decided not to say. This one surfaces it. That's a novel disclosure pattern — it gives users a way to verify agent judgment rather than trusting it blindly.

Debugger as portfolio artifact. The debugger isn't just a developer tool. It's a trust signal made visible. It shows how the agent thought, what it considered, and what it chose. That's a mature disclosure pattern applied at the surface of the product.

Prompt as design surface. The 23 requirements in Section 08 treat interaction choices as design decisions, not engineering afterthoughts. Anti-parroting rules, no forced-choice questions, no sign-offs — these are all interaction pattern decisions embedded in language.

Human-in-the-loop grading as trust infrastructure. The RLHF interface in Section 11 lets a human shape what the agent learns is desirable. Trust infrastructure built into the product, not bolted on.

A designed demonstration of an AI support architecture that treats trust signals, disclosure patterns, and interaction choices as first-class product decisions rather than post-hoc guardrails. The debugger interface exposes agent judgment through a suppression panel — a novel disclosure pattern that gives users visibility into what the agent chose not to surface. The system prompt encodes 23 interaction rules with reasoning, and the human-in-the-loop grading interface establishes an RLHF-style feedback loop for shaping response quality.

Gaps to fill. Two of the five patterns above still need work before the case study reads as complete:

Living doc — expand as the rebuild progresses and the case-study narrative sharpens.

16 — Honest framing

What this is and isn't

This is a designed demonstration of an architecture I created. It is not a claim of a shipped product. The original engagement never went to market during my time there. The rebuild is mine, built independently from the original company's code or assets, and runs against the Anthropic API as a working proof of the architecture.

What it would take to deploy this responsibly

A product like this can't go live without clinical oversight, real escalation protocols, licensed clinicians on call, and a much more developed understanding of how it should behave across the populations it's most likely to encounter. The matrix above is the start of that work. None of it replaces real care.

One thing worth saying

The original business model required strong intrinsic motivation and consistent daily engagement to qualify for the financial incentive that drove early-user behavior. That design choice structurally excluded many of the people who might most benefit from a solution-focused conversation tool — the people who already feel like therapy isn't for them, the people who don't know where to start, the people whose lives are too chaotic to commit to a daily streak.

If a product like this is going to do real good in the world, it has to be honest about who it filters out, and design specifically to reach the people on the wrong side of that filter.