The Design Principle Mental Health AI Keeps Getting Wrong: Build for Disengagement, Not Engagement

Most consumer software is built to maximize time in the product. That's the wrong design target for mental health AI, and a growing number of clinical leaders building these tools are saying so directly. The design principle worth taking seriously: a mental health AI companion should be built for better disengagement, not more engagement. Success is a user leaving the interaction with genuine insight or a concrete next step, and going back to their actual life, not staying logged in longer.

One clear public illustration of this principle in practice comes from Headspace, whose Chief Clinical Officer has described the clinical design behind their AI companion, Ebb, in detail at industry sessions.¹ The specifics are worth walking through, not because any one company has solved this, but because the underlying design questions apply to every mental health AI product, including the ones built to sit inside a human therapist's care rather than stand alone as a consumer app.

Start with what the tool is not

A recurring theme across teams doing this well: define the boundary of what a tool explicitly will not do before defining what it will do. In Headspace's public description of Ebb, that means no therapy, no crisis support, no diagnosis, no medical advice, positioned as the safest possible entry point for a genuinely new category of technology rather than a limitation to apologize for.

The clinical reasoning underneath it holds regardless of which product you're building: mental health is not simply the absence of mental illness. It's the capacity to connect, cope, and create meaning. A tool that targets that wellness dimension specifically, rather than illness, ends up making very different design choices than one that doesn't draw the distinction at all.

Why AI defaults into comfort, and why that's a problem

Without a deliberate clinical conceptual model behind it, AI tends to default into comfort. It wants to reassure. It wants to soothe. That instinct sounds benign, and in a lot of contexts it would be. In mental health specifically, unchecked comfort-seeking can reinforce avoidance, which is precisely the mechanism that keeps people stuck rather than helping them move through difficulty.

A transdiagnostic design approach, organizing around underlying mechanisms like emotion regulation and experiential avoidance rather than specific named conditions, is one way teams have addressed this: every response engineered to gently nudge someone toward approaching a difficult emotion rather than avoiding it. The goal is distress tolerance and resilience, not just feeling better in the immediate moment. Those two goals frequently pull in different directions, and a product that only optimizes for the second will tend to produce short-term satisfaction at the expense of the actual clinical outcome it should be aiming for.

Every design choice is an intervention

Tone, response timing, message length: all of it shapes how a person responds, whether or not the product team thinks of it in those terms. As one chief clinical officer put it, describing this principle: "It's not enough to layer clinical expertise on after the tool is built." That approach reduces clinical input to a checklist applied at the end of a process, rather than a force shaping the process itself. The sharper framing of what's actually being built, in this view: "You're not building a tool, you're building a relationship." Good UX in mental health AI isn't just about ease of use. It's about therapeutic direction, a fundamentally different design target than the usability metrics most consumer software gets optimized against.

Boundaries are the actual product

If engagement itself is not the goal, a handful of concrete boundary decisions follow directly. On validation: how do you affirm someone without inadvertently reinforcing the avoidance that's keeping them stuck? On direction: generic lists of coping suggestions rarely translate into action without behavioral activation and real momentum behind a specific next step; asking what's worked for this person before builds on existing capability rather than generating a generic menu. On duration: how long should any given interaction actually last, and does that length serve the therapeutic purpose or just an engagement metric?

A layered ("Swiss cheese") model of safety

A useful mental model for safety architecture in this space, borrowed from aviation and medical safety thinking more broadly: every individual safety layer has holes, but layered together, they produce a system that's much harder for any single failure to slip through. In practice, that means something like: automated safety classifiers running on every conversation, flagging categories like suicidal ideation, domestic violence, and disordered eating; guardrails that redirect flagged conversations toward crisis resources; daily human review, where licensed clinicians read every flagged conversation, not a sample; and randomized QA sampling across a broader set of conversations, scored on dimensions like tone, clarity, and whether the interaction stayed in scope. Headspace has described running this exact stack for Ebb, governed by a named clinical safety council that sits alongside product and engineering leadership rather than reviewing their output after the fact.¹

Why session-length caps matter, specifically

Perhaps the most concrete illustration of "boundaries as intervention" that's been made public: Headspace found that while the large majority of Ebb sessions ran under 30 minutes, consistent with an intended micro-intervention design, a small percentage ran considerably longer, some stretching to several hours. The question their clinical safety council reportedly asked wasn't just "is this technically safe," it was sharper: is a session of that length aligned with a micro-intervention model at all, and is there a legitimate reason a wellness tool, as opposed to a crisis line, should ever need someone on it for hours at a time? They reportedly concluded no, and capped session length accordingly, with session endings designed to prepare someone for disengagement rather than cutting them off abruptly.¹

That's a genuinely useful case study of the underlying principle: a boundary that looks, on the surface, like it would reduce whatever engagement or usage metric a typical product team optimizes for, gets implemented anyway, because the clinical evidence points toward it being the right design for the actual therapeutic goal.

What this means for therapist-led AI specifically

There's an important structural difference worth naming here. A standalone consumer AI companion has to solve the disengagement problem entirely on its own, because there's no other relationship in the loop to catch what the AI misses. That's why an internal clinical safety council, reviewing flagged conversations after the fact, becomes such a critical (and heavy) piece of infrastructure for that category of product.

AI built to sit inside an existing therapeutic relationship starts from a different baseline. The patient already has a supervising clinician who sees the whole picture across sessions, not just what one AI system flags. The disengagement question doesn't disappear, an AI companion between sessions still shouldn't be engineered to maximize time spent talking to it instead of living life, but the backstop against getting it wrong is a human who already knows the patient, not solely an internal review process built to substitute for one.

What to actually ask when evaluating any mental health AI product

A few concrete questions, applicable to any vendor regardless of business model: Is there a defined answer to what the tool explicitly does not do, stated before what it does? Is there a named clinical conceptual model that shapes response design, rather than a general instruction to "be helpful and safe"? Is engagement duration actively monitored, with a defined ceiling tied to the tool's actual therapeutic purpose, or is longer engagement treated as an unambiguous success signal? And specifically for standalone consumer tools: who is the human backstop when the AI gets something wrong, an internal review board, or an actual clinician who knows this particular patient?

It's a useful companion piece to the broader distinction between clinician-embedded and clinician-reviewed AI teams, which gets at the same underlying question from the product-team side rather than the individual-conversation side.

---

Citt.ai is built to sit inside an existing therapeutic relationship, with a licensed clinician who already knows the patient as the backstop, not an internal review board substituting for one. Read the Citt.ai Safety Standard.

Footnotes

1. Design principles, safety architecture, and session-length findings for Headspace's AI companion Ebb are drawn from public statements by Headspace's Chief Clinical Officer at industry sessions on mental health AI design, describing the company's own published approach. Cited here as an illustrative example of a broader design principle, not as an endorsement of the product. ↩ ↩² ↩³