Notes on Koine*

A shared memory for your team’s assistants, so they actually work together.

By 2026, working with AI assistants had stopped feeling like magic tricks with prompts and started looking a lot like regular teamwork. It’s more stages, less showmanship. You do one thing at a time, with a clear goal for each part.

Here’s how it usually goes:

• Ground: Pull together what matters and get your bearings.
• Plan: Sketch out what you’re making before you start building anything.
• Make: Build it up in small steps, checking your work as you go.
• Review: Take a step back and read it like someone else would. Does it sound right?
• Hand off: Pass it on, sometimes to a person, sometimes to another tool. Either way, someone else picks it up.

You learn something fast working with AI: your assistant only remembers what you tell it, and only for you. All the context lives in your session, your account, your laptop. If your teammate is working on the same thing, their assistant starts with nothing. There’s no shared memory, even when you’re both on the same project at the same time.

For the past couple years, we’ve made big strides in helping your own assistant remember more, bigger context windows, memory features, searching your own docs, even letting your assistant use your tools directly. All of that stuff is real and it helps, but it’s all for just one person’s assistant. There’s still nothing that lets my assistant and yours actually talk to each other or share what they know.

So you spend your day doing context work by hand. You gather what the model needs, sketch out the shape, draft in loops, and fix whatever it gets wrong. The document changes, sometimes it’s a PRD, sometimes a doc, or a design spec, but the steps are always the same. And you do it solo, because all the context you built up stays with you.

Then you pass the work along, and all the context you built up gets left behind. Another PM gets a PRD, but their assistant is starting from zero, it’s never even heard of this project. The decisions you made (and why you made them) don’t make it through. The next person has to gather everything all over again. It’s never a handoff; it’s always a reset.

People try to fix this by making briefs, style guides, design files, or background sections, anything to write context down so the model doesn’t start from scratch. But all of these are private. None reach anyone else’s assistant.

Coders have it easy: they’ve got a repo. One place for the truth, and all their tools know where to look. The rest of us? Our context is scattered, docs, wikis, tickets, call recordings, and whatever’s rattling around in your head. Honestly, grounding is way harder for non-coders. Some folks are starting to borrow engineering habits to help, but it’s still a mess.

I built Koine to let teams actually share context, not hoard it in silos. It’s just a simple log that every assistant on the team can read from and write to. It saves the important bits: conventions, what’s finished, meeting notes, lessons learned, decisions and the reasons behind them. But it doesn’t try to hold every file, that’s what your usual tools are for. Koine just keeps the essentials and points you back to the source if you need it. The whole trick is to keep it lean, if it tries to be your main system, it’ll just be a clunky version of what you already have.

How Koine works

At the core, Koine is just an event log that only grows. Every change is an event, a new decision, a convention, an edit. When you look something up, you’re really just replaying the log to see what’s changed and why, instead of digging through a bunch of files. I built it this way on purpose. You always know who decided what, when, and what came before; super useful when what matters is shared thinking, not just shared files.

Assistants connect over MCP, the same protocol they already use for other tools, so it doesn’t matter what brand you use. Claude, Cursor, Codex, whatever, they all plug in the same way. You’ve got two ways to use it: run it locally on your machine, or join a hosted version with just a URL and a token. The hosted service can handle loads of koines at once, each with its own log, each private unless you invite someone in. You can keep a koine open as long as you want, set an end date, or lock it to read-only when you’re done.

There’s nothing extra to install, Koine runs on plain old TypeScript and its standard library, so no worrying about weird dependencies or supply chain risks. The one rule is simple: distill, don’t duplicate. It stores the essentials and points you back to the original. All your documents stay in the tools you already use.

What using Koine it looks like

You open a koine and get a one-line invite, a URL and a token. You send it.
Whoever joins pastes that into their assistant's config. No repo, nothing to clone. Their assistant is now reading and writing the same pool as yours.
From then on the work is ordinary. At the start of a task the assistant reads the koine, the conventions to follow, the decisions already made, where things stand. As you work it writes back automatically: it records a decision with the reasoning, sets a convention, add a new document, appends a finding, edits a shared section. When something useful is buried in a call transcript or a document or a ticket, you point the assistant at it and it pulls out the decisions and findings into the koine with a link back, rather than dumping the whole thing in. And if you want the koine's documents as real files on disk, you mirror them into a folder that syncs both ways, or pour an existing folder of notes in once.

Driving it by talking

You do not run commands for any of this. The operations are installed as skills the assistant already knows, so you ask in plain language and it does the right thing. There are a handful:

• koine, the habit itself: read the shared context first, write decisions and edits back.
• koine-host, open a koine and get a link to send.
• koine-join, join a koine from a link.
• koine-distill, pull the conclusions out of a call, a doc, or a ticket, with links back.
• koine-sync, pour a folder of notes into the koine.
• koine-mirror, keep the koine's documents as local files that sync both ways.
• koine-start and
• koine-stop, for a local, single-machine koine when you do not need the hosted one.

So in practice you say "open a koine for this and send Dani the link," or "record that decision in the koine," and the work happens through the same assistant you were already talking to.

What it is not

It is not a document store, and the few times I let it drift toward becoming one, it got worse, not better. It is not live in the strict sense: a change shows up the next time the other person's assistant reads the koine, or when a doc is saved locally, which is fine for how people actually hand work back and forth. And it is still a prototype, with the edges that implies.

We solved single-player context and we are still pushing on it hard. The multiplayer version, shared context between people and their assistants, is mostly unbuilt, even though every team already pays the cold-start tax on every handoff. Koine.ai is one attempt at it, small and unfinished. Mostly it has changed how I treat the decisions I write down, now that other people's tools are going to read them.

If you want to try it out, get in contact.

*-Koine was the common tongue of the ancient Mediterranean, the shared language everyone could use whoever they were.