The layer your agents share.
Coven sits between the agent CLIs you already run and the project they are working in. Your harness keeps reasoning and writing code. Coven holds the state those sessions have to share: intent, ownership, authority, and evidence.
Three layers, one boundary
Commands go down. Output and memory come back up.
Coven attributes every crossing to a session.
What Coven keeps
Memory, sessions, harnesses, and actions. These four decide what a session can do.
Memory that carries between sessions
A file on your disk. The next session reads it first.
A session outlives its terminal
Reboot mid-task and the record comes back. The process does not.
One adapter contract
One harness can write files and another can use tools.
Coven interacts with both through one interface.
Every agent asks first
Before an agent changes a file, runs a command, or pushes code, it asks Coven.
Coven looks at who is working where and what you allowed, then gives one of three answers.
How a familiar learns a repo
Each familiar writes it's own notes and reads them back at the start of the next section.
Summoned Hexi. It read the repo and wrote nine notes.
Stack, entry points, the test command that works.
Picked up how you review.
Terse PR summaries, no trailing recap. It stopped writing them.
Shipped feat/runtime-attach across three sessions.
Two of them started after a reboot.
Still remembers all of it.
128 notes. You have read maybe six.
Every agent already has its own worktree.
It did not help.
Two sessions, isolated checkouts, both right about their own context. Each diff was clean on its own, so git raised nothing and CI passed a tree that had already lost work.
One runtime. Every project. Any harness.
The Coven daemon is per machine. Claims, guards, and events are per project. Pick a project to see who is in it, and open any column for the detail behind it.
The circle is open.Step in.
The runtime, the workspace, and the people building both. All of it public, all of it MIT.
MIT · runs locally · signed .dmg