Most software that wants to help two people talk to each other starts by asking both of them to download something. That is the first place these products lose. Getting one person to install an app is a conversion problem. Getting two specific people — who are, by the nature of the product, currently not in perfect agreement about anything — to both install the same app, create accounts, and show up in it at the same time is not a conversion problem. It is a wall.

Therapist Harry is a conversational AI that facilitates couples therapy over SMS. Both partners text one number. There is nothing to install.

This case study is about the build. It makes no claim about what the product does for a relationship, and it should not be read as one. Therapist Harry is in private beta, its own site states plainly that Harry is not a licensed therapist, and it carries a 988 crisis referral. Those are the product's own boundaries, and the engineering described below sits inside them.

Why SMS is the hard choice, not the easy one

Choosing SMS as the interface looks like a shortcut. It is the opposite. An app gives you named sessions, per-user state, a login, a screen you control, and a UI that can stop someone from doing the wrong thing. SMS gives you a stream of short text messages arriving from phone numbers, in any order, at any hour, with no structure whatsoever.

Everything an app would hand you for free has to be built.

The payoff is that the product meets people where they already are. There is no onboarding funnel between a couple and the thing they are trying to do. That trade — accept substantially harder engineering in exchange for removing the install step entirely — is the central decision of this build, and most of what follows is the cost of it.

Threading two people through one number

Both partners text the same number. That single sentence contains the whole problem.

A conversation over one shared number is not a conversation with one user. It is a three-party exchange where two of the parties are humans with their own history, their own phone, their own sense of what happened last Tuesday, and their own idea of what they want out of the exchange. The system has to know, on every inbound message, which of the two people is speaking, what that person has already said, what the other person has already said, and which of those things the other person is allowed to see.

That last part is not a feature toggle. It is a structural decision that has to be made once, correctly, at the point where messages are threaded — because a system that gets it wrong does not degrade gracefully. It says something to the wrong partner, and there is no undo on a text message.

One question at a time

Harry asks one question at a time. This is the kind of product constraint that sounds like a UI preference and is actually load-bearing.

A model given room to run will produce a paragraph containing three questions, a reflection, and a suggestion. In a chat window that is merely dense. Over SMS, delivered to two people who are texting from different rooms, it is chaos: each person answers a different part of it, the replies interleave, and the thread loses any shared sense of where it is.

Holding the exchange to a single question per turn is what keeps two asynchronous humans on the same step. It also makes the state tractable — at any moment there is exactly one open question, and the system knows who it is waiting on.

Keeping participation balanced

In any conversation between two people, one of them talks more. Left alone, a responsive system amplifies that: the person who replies faster gets more turns, more follow-ups, and more of the model's attention, and the exchange quietly becomes a conversation with one partner while the other watches.

Balanced participation is an explicit product behaviour in Therapist Harry, which means it is an explicit engineering behaviour. The system has to track turn distribution as a first-class piece of state and act on it, rather than simply responding to whoever texted last. Responsiveness is the default behaviour of every messaging system ever built; deliberately not being purely responsive is the work.

Memory that persists between sessions

Harry remembers between sessions. Without that, every exchange restarts from nothing, and a couple has to re-explain their situation each time — which is both tedious and, for this subject matter, actively corrosive to the point of the exercise.

Persistent memory across sessions introduces the problems that persistent memory always introduces: what is worth keeping, how it is summarised, how it stays accurate as the situation changes, and how it is retrieved without dragging the entire history into every turn. Over SMS those problems arrive with an extra constraint attached — there is no session boundary to hang state on. A text message arriving three weeks later looks exactly like one arriving three minutes later. Continuity has to be reconstructed rather than resumed.

Staying non-partisan

Therapist Harry is explicitly non-partisan. It does not take a side.

This is the requirement most likely to be quietly violated by a language model doing what language models do. Models are agreeable. Given a one-sided account of a disagreement, the natural output is sympathy with the account it just read. Do that twice, to two different people, in the same thread, and the system has told each partner they are right — which is worse than useless in a shared conversation, because both of them can see it.

Non-partisanship is therefore not a line in a prompt. It is a property that has to survive across a two-party thread, across a long memory, and across every turn where the easy response is to agree with whoever is currently typing.

Shipping carefully

Therapist Harry is in private beta with limited onboarding and no pricing shown. For a product in this category that is the correct posture, and the site's own disclaimers — not a licensed therapist, plus a 988 crisis referral — are part of the build rather than legal decoration bolted on at the end.

The engineering interest here is that almost none of the difficulty is in generating text. It is in threading, turn-taking, balance, memory, and restraint — the state machine wrapped around the model, not the model itself. That is true of most useful AI products, and it is the part that gets underestimated.