Keep the thread: designing account and conversation boundaries
My contributions to the Kenzai team’s product, merged on October 13, 21, and 22, 2026, share a design problem: a transition should not erase a decision that still applies.
These changes are development work, not a confirmed production rollout.
1. Separate identity from integration consent
The October 22 Google sign-in contribution adds identity-only login and signup, separating account access from optional Gmail linking. Live Google sign-in and onboarding acceptance are still pending.
The reusable lesson is to distinguish two questions:
- Who is signing in?
- Which additional service does that person want to connect?
Treating those questions independently avoids making optional integration consent part of the account-entry requirement. This is a design principle, not a claim about measured signup performance.
2. Give setup completion its own meaning
Another October 22 contribution restores authenticated setup for accounts without stored connections. Finishing or skipping setup preserves each user’s completion state across reloads and retries, without changing other users’ data. Deployed onboarding remains unverified.
A useful modeling rule follows: connection presence and setup completion are not interchangeable. An account can have no stored connections and still have a meaningful setup decision.
When designing a comparable flow, define what finishing means, what skipping means, and which user owns that state. Do not let a reload redefine a decision the user already made.
3. Define continuity beyond message history
The October 13 work includes a full-page agent chat interface that preserves the current conversation and unsent drafts across workspace views. A separate New chat action starts a fresh session. This remains a draft release candidate.
The October 21 contribution extends the continuity principle to moving the same conversation from the sidebar into Work, preserving drafts, attachments, audience and model choices, and pending actions. Production availability is not established.
For a similar interface, write down a continuity checklist before wiring navigation:
- Current conversation
- Unsent draft
- Attachments
- Audience selection
- Model selection
- Pending actions
This is a suggested engineering checklist, not a report of additional testing. Its purpose is to prevent a narrow definition of state preservation in which message history survives but the user's current work does not.
4. Specify placement and input together
The October 13 sidebar contribution docks agent chat beside the task board on wide screens and slides it in from the right on smaller screens. It includes suggested prompts, a new-chat button, Enter to send, and Shift+Enter for a new line.
Responsive placement is only half of the interaction contract. Keyboard behavior also needs an explicit meaning. Moving a composer should not make writing feel like a different operation.
The boundary rule
Navigation preserves activity. Reset is explicit. Optional consent remains separate from identity. Those rules are useful because they make product behavior understandable before any implementation detail enters the discussion.
Finally, keep evidence language precise: a merged contribution establishes a merge, not deployment or a customer outcome.
Build notes and sources: https://www.harshith.com/diffs/build-notes-2026-10-23-1839228855
Top comments (0)