Kochi
Context
Teams building AI products were increasingly relying on prompts, rules, and product-specific context to shape how their systems behaved. As that logic was reused across prompts and tools, it became harder to keep consistent or understand what would be affected when something changed.
Kochi’s product hypothesis was to treat important AI instructions as reusable shared behavior rather than isolated prompt text. I led the detailed product definition for what that model meant in practice.
Outcomes
Shipped the shared-block system into beta. Teams could reuse AI instructions across prompts while keeping versions, updates, conflicts, attribution, and publishing states visible.
Established a common product contract for shared behavior. Design and Engineering had explicit rules for how shared and local changes should behave instead of resolving them feature by feature.
Made implementation more direct. Engineering reported shorter implementation cycles after we moved toward component-level behavioral specs and visual references, with some UI work completed in a single pass.
Role
I shared product responsibility with the founder/CEO, a former Head of Product, and led the detailed product definition for the shared-block system. I worked directly with Engineering from product modeling through coded prototypes, implementation, and behavioral QA.
Scope: product modeling · interaction design · coded prototyping · design system · implementation partnership
The Problem
Shared AI behavior was easy to copy and hard to manage
Through customer conversations, consulting work, and product partnerships, we saw the same problem from two sides.
For people building AI products, useful experiences depended on increasingly specific context: product knowledge, business rules, workflow instructions, and constraints.
For the teams maintaining that behavior, the same context was often scattered across prompts, documents, chat threads, workflow builders, and internal tools. Reusing it usually meant copying it.
That worked when one person owned the workflow. It broke down as the same behavior spread across a team.
For example, a team might rely on an approval rule:
“Do not publish, export, or send analysis outside the workspace without human approval.”
Once copied into several prompts, that rule could drift. One version might prohibit all exports without approval, another only external messages, while another still used older language.
The drift wasn't caused by carelessness. The system made shared behavior easy to copy and hard to trace.
As teams built faster across different models and tools, that drift became more consequential. Some instructions were not merely prompt preferences; they represented company-level rules around security, approval, brand, or workflow behavior that needed to remain consistent.
Kochi addressed that by turning repeated instructions into shared blocks that could be reused across prompts.
That solved duplication, but created a new product problem: how do you preserve shared rules without preventing people from adapting their own work?
Defining the Product Model
Making behavior reusable meant balancing two needs: teams needed a reliable shared source of truth, while individual prompts still needed room to evolve.
I defined the model around three principles.
Preserve shared rules without freezing local work
Some instructions needed to remain consistent across a company, while others could be adapted for a specific prompt or workflow.
Kochi kept the relationship between a shared block and the prompts using it visible, so users could understand what was centrally managed, what had changed locally, and where an update would have consequences.
Make changes visible and resolvable
Shared updates needed more than a visual diff. The product distinguished between current blocks, newer versions available for review, and conflicts where a shared update collided with local edits.
Users could compare versions, accept the shared update, or keep their local version. Unresolved conflicts blocked publishing, making consequential differences visible without requiring users to understand the underlying versioning model.
Hold AI to the same rules
Cowork could suggest or apply changes, but AI-generated edits followed the same model as human ones: changes remained attributable, reviewable, and reversible.
Core principle: The agent acts. The author owns.
Representative screens built with Claude Code to quickly model block state behavior, test interface logic, and give the team a shared reference for review and implementation. Best viewed on desktop.
Approach
I started with the state model rather than the interface. I mapped each block’s source, where it was reused, which version a prompt was using, whether local edits existed, and whether the resulting state was safe to publish. This gave Design and Engineering a shared definition of what each state meant and which actions should be possible.
Because the interactions depended on combinations of states, static Figma screens were not enough. I prototyped the flows in Claude Code using Kochi’s production components and tokens, which let me test transitions and implementation constraints in the product environment and gave Engineering a more precise reference for implementation.
Representative screens — coded with Claude Code, reusing Kochi's production design tokens and components. Best viewed on desktop.
Results and impact
The shared-block model shipped into beta across the prompt editor and Cowork.
For users, it created a visible relationship between shared company behavior and local prompt changes. Teams could keep instructions such as security, approval, or brand guidance shared while still reviewing or resolving changes in the prompts that depended on them.
For Design and Engineering, the work replaced a looser feature-by-feature approach with a common behavioral contract. The implementation process also became more direct: Engineering reported shorter cycles after we moved toward component-level specs and visual references, with some UI work completed in a single pass.
