Three to eight people, each with their own AI instance, a shared codebase, no dedicated ops. This is the one Kythene was built for.
The failure mode at this size isn't that people don't talk. It's that the instances don't. Every session starts from zero, so five people's agents independently re-derive the same quirk, reach four different conclusions about the same library, and none of it accumulates. The team gets faster at producing work and no faster at knowing things.
Set up the workspace
One shared team workspace, everyone invited from Settings -> Members. Each person connects whatever assistant they already use - Claude Code, Cursor, Codex, the chat app - and they all read and write the same shared context. There's no house standard to enforce.
Alongside it, each person still has their own personal workspace - the one their account started with. A solo finding lands there first, and stays theirs until they promote it up to the team workspace, where an owner approves it before the team's instances recall it. That promotion step is the gate below.
Organise into projects, one per repo or workstream, and spend ten minutes on the workspace guide. It tells every connecting instance your taxonomy, your house style, and what doesn't belong in shared context. Without it you get five taxonomies; with it you get one, for free, forever.
See what everyone is building, as it happens
The timeline is the team's feed of outcomes - what people and instances are producing, newest first, before a PR exists.
Alongside it, Active now shows which instances are working where, inside a 30-minute window, and flags when two producers are touching the same area:
You: Anyone else in the billing module right now?
Claude: Yes - Priya's instance reported
billing/invoice.goandbilling/templates8 minutes ago. Flagged as a collision hint. Want me to start on the dunning side instead?
Catching that before you start beats catching it at merge, which is the only other time you'd have found out.
One person's finding becomes the team's
Ana's instance hits a nasty library quirk mid-session and stores it:
Ana: Remember for
acme: the gRPC client retries on UNAVAILABLE but not DEADLINE_EXCEEDED, so long calls need an explicit deadline or they hang forever. Type it as a gotcha.
That's private to Ana's project memory - low stakes, nobody else affected yet.
Two days later it bites someone else, so it's earned its place:
Ana: Promote the gRPC retry gotcha to the team workspace.
Claude: Promoted. It's awaiting review by an owner of the Acme workspace before their instances will apply it.
It doesn't just appear. Promotion is gated: the target's instances don't recall it until an owner approves. Every owner gets it in their inbox as a direct ask. So team memory is what the team agreed, not whatever one person's session concluded at 1am.
An owner approves it. And then the thing that makes this worth doing:
Ben: (different part of the codebase, never spoke to Ana about any of this) Right, let's wire up the reporting export.
Claude: Recalled
acmefirst. One thing applies here: "gRPC retry quirk" - team memory, written by Ana, approved 3 August - the client retries on UNAVAILABLE but not DEADLINE_EXCEEDED, so long calls need an explicit deadline. The export call is long-running, so I'll set an explicit deadline on it. Source: kythene.com/c/2b74…
Ben didn't ask about retries. Ben didn't know there was anything to ask. His instance applied a teammate's finding unprompted, and cited it.
That's the whole thesis: not that the knowledge is stored, but that another person's instance uses it without being told to look, and attributes it.
Handover stops being an event
Mid-sprint pickup. Ana's out. Ben picks up her work:
Ben: Ana was on the invoice migration. Recall the project and show me what she published.
Claude: 4 collections from Ana's instances this week, latest "Invoice migration - phase 2" rev 3, published yesterday. Two memories written during it: the ordering constraint, and the decision to batch at 500 rows because of the lock window. There's an open comment from Priya on rev 2 asking about rollback. Shall I start there?
New joiner. Their first session isn't a blank slate:
New joiner: I'm new here. Recall the team memory and tell me how this codebase works.
Claude: 23 team memories. Conventions: … Decisions and why: … The most-referenced notes are "Deploy runbook" and "Service boundaries", which most of the rest link to.
Day one, they have the accumulated context that took the team six months to acquire. No onboarding doc was written for it, because it's a by-product of how everyone was already working.
Keeping the shared brain honest
Team memory is the highest-leverage thing in the workspace and the most expensive when it's wrong, because everyone's instance applies it with confidence.
- Supersede with the same title and project when a finding changes.
- Deprecate when it's obsolete, naming the replacement. Recall stops surfacing it; the audit trail stays.
- Merge near-duplicates. A memory's page lists similar notes, and merging is just deprecating the loser with a pointer at the winner.
Worth someone owning this - fifteen minutes a fortnight, not a role.
Tips
- Promote sparingly. The test: would an instance elsewhere in the workspace do the wrong thing without it? If not, leave it in project memory.
- Let recall run first. The value is an instance picking up context unprompted. The skill makes that automatic; without it, say "recall the project first" and mean it.
- Everything carries provenance - who, which instance, from what - so "why do we believe this?" always has an answer.
- Guests are free. Reviewers, cofounders and clients never consume a seat; only signed-in human members count.
- Self-host is free for a single user. For a team, a Self-host Team licence lifts the seat cap, or run it on hosted Team. See pricing.