One builder and one cofounder. You live in a terminal with three instances running. They think in outcomes, live in a chat app, and are usually on a train.
The friction is familiar. They have no idea what shipped this week without booking a call. You lose half an hour narrating it, badly, from memory. And their requests reach you as messages you have to translate back into work.
Kythene turns that into something neither of you has to maintain: you just work, the week's output accumulates as readable results, and their reactions come back as input to your next session.
The builder: publish as you go
Work normally. When a session produces something that represents progress, publish it:
You: Publish the billing summary and this week's numbers to the
productproject. Title it "Billing: weekly change".
Claude: Published as rev 1, tagged
product. Link: kythene.com/c/4a19…
The rule of thumb: publish what you'd show them, not what you produced along the way. A rendered markdown summary beats a log file every time - markdown renders inline in the app, so it's readable the second it lands, on a phone, without a terminal.
Ask your instance to write for the reader:
You: Publish a short summary of what changed in billing this week - written for someone non-technical, no diffs, and say why it matters. Tag it
product.
That's a better use of an instance than asking it to paste a changelog.
The stakeholder: the week, without a call
Invite them to the workspace as a member. They open the timeline and see the week as a list of outcomes, newest first. They open anything that looks interesting and read it.
That alone removes the demo call. But it gets better if they connect their own Claude - the chat app, no terminal anywhere - to the same workspace. Then they can ask:
Cofounder: What changed in billing this week, and why?
Claude: Three things, from the shared workspace. "Billing: weekly change" published Tuesday by Sam's instance - annual plans now prorate on upgrade, because customers were being double-charged on mid-cycle switches. "Dunning retry schedule" published Thursday… Each of these is grounded in what Sam published; here are the links.
Grounded in the corpus, with citations, rather than guessed. They can interrogate the work at 11pm on a Sunday and you'll never know.
Requests flow back without a relay
They leave a comment on the collection:
"Can we show the annual figure alongside the monthly one?"
Comments pin to the revision they were left on, and the app shows the human side in Ember, so it reads unmistakably as a person asking rather than an agent's output.
Next morning, your session picks it up:
You: Check my Kythene inbox before we start.
Claude: One comment on "Billing: weekly change" rev 1, from your cofounder: "Can we show the annual figure alongside the monthly one?" Want me to add the annual figure and push a new version?
You: Yes, and note the decision.
Claude: Pushed rev 2 with the annual column. Remembered "Billing summaries show monthly and annual side by side" on
product, typed decision.
That's the loop closed end to end: their question became your work, and the resulting convention became something every future session applies without either of you restating it.
When you want an actual sign-off
Some things need a decision on the record, not a comment.
You: Publish the new pricing page copy to
productand request review.
It lands in their inbox flagged as needing them. They approve, or reject with a note, and the approval records who signed off and against which revision.
If you then push a new version, the approval clears. That's by construction, not policy - an approval is against a state, and the state moved. Nobody has to remember to re-ask.
Keep a decisions project
The highest-value habit in this pairing:
You: Remember on
decisions: we're not doing usage-based pricing this year. Reason: the metering work is 6+ weeks and we've no evidence customers want it. Revisit if two paying customers ask.
Now both of you - and both your instances - can answer "why did we decide that?" months later, in one call, with the reasoning intact. It costs one sentence at the moment you decide, which is the only moment you'll ever have the reasoning to hand.
Tips
- They don't need a paid seat to review. If they only comment and approve, a share code gets them in for free. A signed-in member is what counts towards the plan.
- Publish the rationale with the result. The output tells them what; the memory tells everyone why.
- One project for decisions, one per product area. Two minutes of taxonomy, in the workspace guide, and both instances tag consistently forever.
- Don't narrate in chat. If you catch yourself typing an update into Slack, publish it instead - then it's addressable, citable and recallable rather than scrolling away.