Product

Building the Conversation State Model

A useful inbox model needs to know more than whether somebody replied.

The first version of Sidekick Log looked for signals inside messages: urgency, pricing questions, buying intent, follow-up language.

That worked until it did not.

A message can look important while the conversation is already resolved. A reply can look healthy while nothing actually moved. A quiet thread can be fine because the next move belongs to someone else.

The product needed state.

From signal to state

The earliest visible model used four simple states: Window Closing, Needs You, Changed, and In Orbit.

Those labels were designed for a user, not for the classifier. Underneath them, the working model became more specific: is the thread waiting on me or them? Did a material change occur? Did someone make a placeholder commitment? Did the loop actually resolve?

A good state model tells you what the conversation means now, not merely what the last message said.

Why state is harder than classification

A classifier can inspect one message and produce a label. State requires comparison.

You need to know what happened before, who acted last, whether the owner of the next move changed, whether a promise aged past its expected window, and whether the latest reply actually closed the loop.

That is why the model depends on lightweight memory. Gmail stores the messages. Sidekick Log stores enough derived state to notice when the meaning of the thread changes.

The design constraint

More states are not automatically better.

The internal model can be nuanced while the user-facing surface stays small. If the software needs twelve labels to explain what the user should do, the judgment work has been pushed back onto the person.

The point of the state model is compression: take a messy conversation history and preserve the one fact that changes what deserves attention.

Where the model is going

Conversation state is still only the thread-level view.

The broader question is whether the same logic can recognize a latent opportunity or a pattern distributed across several weak signals. That requires moving from “what state is this thread in?” toward “what changed in the user’s world that is now worth noticing?”

State is the foundation. Judgment is the harder layer above it.