Keep the thread, wherever the work goes
Across contributions merged on October 13, 21, and 22, 2026, I worked on making Kenzai’s account and conversation transitions less disruptive. These were contributions to the Kenzai team’s product, not a solo project or a confirmed production rollout. The connecting lesson is simple: changing a view or granting access should not silently change what a user has already decided.
October 22: Account setup without a connection prerequisite
Development work restores authenticated account setup for accounts without stored connections. Setup completion is preserved across reloads and retries. My October 22 contribution addresses a boundary that is easy to overlook: having an account and having a connected service are different conditions. An account-only user still needs a coherent setup path.
Finishing or skipping setup should represent a durable decision, rather than something the interface forgets when it reloads. The reviewed change also keeps other users’ data unchanged. My reusable engineering lesson is to treat completion as user-specific state, not as an inference from whatever connections happen to exist. This is development work; deployed onboarding remains unverified.
October 22: Google identity is not Gmail permission
Development work adds identity-only Google login and signup. Account access is separated from optional Gmail linking. In this contribution, merged on October 22, the important change is the distinction between identifying a person and asking that person to connect an additional service. Those are separate product decisions and should remain separate in the interface.
I see this as a useful consent-design principle: ask for the capability needed at the current step, rather than bundling an optional integration into entry. It makes the account model easier to reason about without claiming an observed conversion improvement. Live Google sign-in and onboarding acceptance are still pending, so I would not describe this merge as a launched sign-in experience.
October 21: Expand the workspace, not a new conversation
A development improvement carries the same conversation from the sidebar into Work. Drafts, attachments, audience and model choices, and pending actions stay intact. My October 21 contribution focuses on what an expansion action should mean: more room for the same activity, rather than a reset disguised as navigation.
The engineering lesson is to define the entire continuity contract before treating a view transition as complete. Preserving messages alone is insufficient if an attachment, an unsent thought, or a pending action disappears. I think of those choices as part of the conversation, not disposable details of its current container. Production availability is not established; the merge should be read as development progress.
October 13: Put the assistant beside the task
Development adds an agent chat sidebar beside the task board. Enter sends a message, while Shift+Enter inserts a new line. This October 13 contribution gives the assistant a place alongside ongoing work: it docks beside the board on wide screens and slides in from the right on smaller screens. Suggested prompts and a new-chat button provide explicit entry points.
What matters to me is the combination of spatial behavior and input behavior. A responsive panel should adapt its placement without making the writing interaction ambiguous. The reusable lesson is to specify both: where the tool appears at different screen sizes, and what familiar keyboard actions do. The reviewed source describes development, not a verified live release.
October 13: Reserve reset for an explicit New chat action
Kenzai is developing a full-page agent chat interface that preserves conversations and unsent drafts across workspace views. A separate New chat action starts a fresh session. My contribution merged on October 13 makes a useful distinction between moving through the workspace and intentionally beginning again.
That distinction gives the later sidebar-to-Work continuity change a clear product direction: navigation should retain the current activity; reset should be an explicit action. I would reuse this rule anywhere a composer can appear in multiple views. Drafts are user effort, even before they become submitted content. This full-page interface remains a draft release candidate, not a production launch.