This case study contains selected product and systems work that is not publicly indexed. Enter the portfolio password to continue.
← Back to selected workDesigning the system around an emotionally sensitive AI product.
Kohra began as a conversational product for helping people move from insight into action. As the prototype grew, my role expanded into defining what the product was, how the AI should make decisions, what needed to be deterministic, how uncertainty should change its behavior, and how the team could maintain the system over time. I led product design across strategy, conversation architecture, confidence scoring, safety, evaluation, the AI document library, and the user-facing experience.
Mission, user model, product promise, acquisition and retention logic
State machine, routing, consent gates, anti-loop logic, safety constraints
Four internal confidence signals help determine pacing, depth, and next move
27 source-of-truth documents for behavior, knowledge, tone, process, and safety
Before the team could make good implementation decisions, we needed a stable definition of the product. I created and maintained Kohra's Product Definition Page so product, design, and engineering had somewhere to return when we disagreed about who we were building for, what problem mattered most, why someone would come back, or whether a feature belonged in the MVP.
It became the document we returned to when a feature, prompt, or technical decision started pulling the product in a different direction.
Named the problem. We used the Wisdom-Action Gap to describe what we kept seeing: people could have a real insight and still lose access to it under ordinary stress.
Worked out why people would return. The Door was the acute need that brought someone in. The Living Room was the quieter daily experience that made Kohra useful between hard moments.
Made the audience more concrete. Sustainers, Optimizers, and Seekers gave us different starting points without pretending every user arrived with the same problem.
Used the feature matrix to say no. It helped us separate frequent, low-friction habits from deeper episodic work and ask what value each feature was actually creating.
Early failures showed up as loops, premature session endings, and moments when a response sounded right while the system made the wrong decision about what should happen next. Editing prompts helped individual turns, but the same structural problems kept returning. I started separating what the model could interpret from what the product needed to enforce.
Before implementation, we needed a stable target. Product Clarity, ethical constraints, tone and sovereignty guidance, and shared definitions gave the team a place to resolve product questions without improvising them inside a prompt.
Once we saw where the experience could fail, I moved those decisions out of prose wherever possible. State logic, routing, confidence thresholds, consent gates, anti-loop behavior, safety overrides, and memory rules constrained the interaction at runtime.
Other parts of the experience needed room for interpretation. Pattern references, reflection examples, belief work, correction language, and anchor examples could be retrieved and adapted without hard-coding the response itself.
I ran recurring evaluations with the eval lead, partnered on PostHog instrumentation, and defined human-in-the-loop escalation paths for cases requiring clinical sign-off. If we could not see why the system failed, we could not improve it reliably.
That work also led me to create a four-layer taxonomy for deterministic and agentic behavior. It gave product and engineering a practical way to decide, feature by feature, how much freedom the model should have.
The flow map supported implementation across entry points, phases, gates, stored outputs, check-ins, Growth Reports, and account surfaces. It is one artifact inside the wider architecture rather than the architecture itself.
One recurring risk was that the model could make a plausible interpretation and act on it too confidently. I designed four internal confidence signals so uncertainty changed what Kohra was allowed to do. The scores stayed behind the scenes and influenced pacing, depth, routing, and whether the system should proceed at all.
One of four internal inputs used to calibrate how confidently the system should act on its current interpretation.
The signals were evaluated together and remained invisible to the user during the experience.
Lower confidence could slow the interaction down or create space for clarification before the next move.
The control layer helped keep a plausible interpretation from automatically becoming an action.
As the system grew, product strategy, safety rules, therapeutic methodology, tone guidance, examples, and runtime behavior were beginning to compete for space and authority inside prompts. I split the system into 27 source-of-truth documents, each with a specific job, so we could change one part without accidentally rewriting another.
Each document had a defined job in the broader behavior system.
Defines what Kohra is and the boundaries it should preserve.
Defines what happens, when, and under what conditions.
Turns the methodology into implementable phase behavior.
Supplies reusable knowledge without hard-coding every response.
The document boundaries made ownership visible. A safety change could stay a safety change. A tone update did not have to alter routing logic. A new example did not quietly become a new product rule.
A person checking in after a win did not need the same experience as someone who was overwhelmed in the middle of the day. And neither necessarily needed a full Soul Loop. Celebrate Mode, Quick Help, and Soul Loop let the product change its depth and pacing without making every interaction feel like the same process.
Help the user fully receive a win, understand what it means, and connect it to who they are becoming.
Bring the user toward clarity and calm when they do not have enough time or capacity for a full rewiring process.
Support deeper transformation through regulation, belief identification, somatic rewiring, aligned action, and integration.
By this point, Kohra was becoming more than a chat screen. Reminders, Growth Reports, and account controls all had to support the same experience without adding more cognitive load. I kept the interface deliberately restrained and let the conversational behavior do most of the work.
Suggested entry prompts lowered blank-page friction and helped route users toward calm, clarity, decision support, or a lighter interaction.
Monthly reports gave users a place to revisit patterns and progress beyond an individual conversation.
Alpha UI shown here includes earlier Inner Sage naming in a few screens. The product was later renamed Kohra.
I was watching closely for whether people felt helped without feeling directed by the product. The feedback that mattered most was specific: people described new clarity, emotional release, repeat-use value, and, importantly, a sense that they still owned the insight and the decision. Names below are pseudonyms used for privacy.
“It was a beautiful surprise this morning to gain new insight about myself, feel supported, on the right track, and I didn’t give away my agency at all.”
“I would use this daily, in the same way someone would hire an assistant for administration, I would use this as a guide or coach when life becomes foggy, heavy, or stormy.”
Jonah also described gaining clarity that brought tears to his eyes and leaving with greater self-awareness, empowering beliefs, and simple actions he could apply immediately.
“Knowledge alone can’t fix it. I integrated a practice for my body, and it led me to break down.”
Eli described the release as something that had felt stored in his chest for years. His feedback reinforced the role of embodiment in the deeper Soul Loop experience.
The most useful outcome was that fewer decisions were being rediscovered inside individual prompts. Product, engineering, and evaluation had clearer rules to work from, and the system had more explicit ways to recover when a conversation went off track.
After repeated prompt edits failed to solve the same structural issues, moving those decisions into the conversation architecture reduced failure rates.
The guidelines gave product and engineering a shared reference point, so fewer implementation questions had to be resolved from scratch.
Behavior, safety, process knowledge, tone, and longitudinal logic each had an explicit home instead of accumulating inside one prompt.
I came into Kohra thinking a lot about conversation quality. I came out of this work thinking much more about control.
The hardest failures were not always bad responses. They were moments when the system made the wrong decision about what to do next: moving forward too early, looping backward, treating uncertainty like certainty, or continuing when it should have slowed down. That is now one of the first things I look for when I design an AI product.