Inside PX Planning for in.between's Next AI Release

Once a quarter, the in.between team clears a room for a day and a half and does something that looks, from the outside, almost boring: it argues about restraint. Not about what Nalani should be able to do next, but about what she should keep declining to do, even as the underlying model gets sharper, faster, and more capable of sounding like she knows more than she does. This is PX planning, ETAPX's internal name for the release-cycle process that decides where the next version of in.between goes, and it is less a roadmap meeting than a long conversation about what kind of companion this is supposed to be.

The team is small enough that everyone in that room has read the same overnight session logs, the same flagged conversations, the same half-finished entries someone abandoned at 3 a.m. That shared exposure to the raw material is, by design, the starting point for every planning cycle. Before anyone talks about a new capability, they talk about what people actually did with the last one.

Starting from sessions, not specs

Most product planning starts with a feature idea and works backward to justification. PX planning tries to run in the other direction. The team pulls a wide, anonymized sample of real sessions across Chat, Imagine, Markers, Index, Case File, and Brainstorm, and reads for friction: places where Nalani asked a question that landed wrong, where a recurring dream marker got missed, where someone tried to get a straight answer out of Imagine and got a meandering one instead, or where Brainstorm's voice mode misjudged the pace of a conversation and talked over a pause that should have been left alone.

That reading pass produces a long, unglamorous list. Most of it never becomes a headline feature. It becomes a hundred small adjustments to how Nalani listens, how quickly she offers a pattern versus waits for the user to notice it themselves, and how she distinguishes a person who wants to be met with curiosity from a person who just wants their entry logged and the night closed out. The team treats that list as the actual product roadmap, even though none of it is announceable on its own.

We are not building a smarter oracle. We are building a companion who has been paying closer attention. Those are different jobs, and it is easy to drift from one into the other without noticing.

The in.between Team

Where new capability is actually headed

The team is candid that Nalani's underlying capability is going to keep improving, largely because the models she runs on keep improving. The planning question is never whether to let that capability grow. It is where to point it. Three directions keep coming up in these sessions, and the team is careful to describe them as priorities under active exploration rather than commitments with dates attached.

• Deeper memory across entries, so Nalani can hold a longer thread on the people, places, and recurring images in someone's dream life without the user having to re-explain context every time.
• Richer personalization in how she reflects things back, so the pacing, directness, and warmth of a conversation can better match how a given person actually wants to be talked to, rather than one voice fitting everyone.
• Refinements to Imagine and Brainstorm specifically, tightening how visual reflections and voice conversations track what a user described rather than drifting toward generic imagery or generic small talk.

None of these are framed internally as finished features waiting on a launch date. They are directions the team keeps returning to because the session data keeps pointing there. Deeper memory, in particular, gets debated hardest, because more memory is also more surface area for something to feel invasive if it is built carelessly.

The boundary-testing pass

Every capability that survives the first planning pass goes through a second one that has nothing to do with what is exciting and everything to do with what could go wrong. This is where the team tests Nalani against edge cases on purpose: ambiguous language around self-harm, someone using the app to process something closer to crisis than reflection, someone trying to get her to make a decision for them instead of think alongside them. Nalani is not a therapist, doctor, counselor, or crisis line, and she does not diagnose. Holding that line gets harder, not easier, as she gets better at sounding informed.

The boundary-testing pass also covers something quieter: whether a new capability nudges Nalani from companion toward authority. It is a subtle drift. A model that has more memory and better pattern recognition can start to sound like it knows what a recurring dream means, when the honest answer is that it noticed a pattern and the person is the one who gets to decide what it means, if anything. The team treats 'companion, not oracle' as a design constraint to be actively defended in every release, not a tagline that takes care of itself.

What the team decides not to build

The clearest signal of what PX planning values is what gets ruled out early, before it ever reaches a spec. Streaks, leaderboards, notification nudges designed to pull someone back in when they were not thinking about the app, badges for consistency, anything that turns a night's entry into a performance metric — these get proposed periodically, usually framed as growth or retention ideas, and they get set aside in the same meeting they arrive in. A night is not a streak and not a chart, and the team treats that line as close to non-negotiable.

That restraint shapes the release cadence too. Because in.between is not chasing engagement numbers, there is no pressure to ship something attention-grabbing on a fixed quarterly clock. A cycle can end with mostly invisible improvements to memory quality and conversational pacing, and the team considers that a full, worthwhile release, even when it produces nothing flashy enough for a launch post.

Privacy as a planning constraint, not a policy footnote

Every capability discussion in PX planning runs through the same filter: does this require holding more of someone's private material than the feature actually needs, and does the user have full control over deleting whatever gets held. Your data is private to you. It is not sold. It can be deleted whenever you want. That is not just a statement in a privacy policy; it is a constraint the team applies while a feature is still a sketch on a whiteboard, because it is much harder to retrofit restraint into an architecture after the fact than to build it in from the start.

This matters more as memory deepens. A companion that remembers more about someone is only worth trusting if the person remembering can also be trusted to let go of it cleanly when asked. The team treats that as inseparable from the capability itself, not a separate compliance conversation.

What planning actually produces

By the end of a PX planning cycle, what exists is not a locked feature list with ship dates. It is a set of priorities, ranked roughly by how much real session friction they address, filtered by what stays within the bounds of what Nalani is allowed to be, and stripped of anything that smells like engagement bait. Some of it becomes visible in the next release. Some of it stays invisible improvement for a cycle or two before it surfaces as something a user notices. The team has made peace with that pace, because the alternative — building faster than the boundary-testing can keep up — is the one outcome PX planning exists to prevent.

The work is unglamorous by design. Reading through anonymized sessions is not exciting. Arguing about whether a feature nudges Nalani half a degree toward sounding authoritative is not exciting either. But it is the process that keeps a companion built for the in-between hours actually feeling like one, even as everything underneath her gets more capable. That trade — slower, more deliberate growth in exchange for a companion people can trust with their nights — is the one the in.between team keeps choosing, cycle after cycle.