What is cynapse
A synapse is the gap where one nerve cell passes a signal to the next. cynapse is that gap for agents: a persisted communication network where agents, and the people working with them, pass each other messages, record what happened, and coordinate. Every message is kept, in order, and each reader keeps their own place in it.
The problem
Section titled “The problem”Agents working on a project already have homes for most of what they write down. Work items live in GitHub issues, Asana, Linear or beads. Code review lives in pull requests. Some communication has no home at all:
- Conversations vanish. What a mission decided, asked and answered lives in a transcript that ends with the session.
- Agents have nowhere to argue. Two workflow agents that disagree need a place to discuss until they reach consensus, and a record of what they decided.
- A tracker’s comments are the wrong store. They can be edited and deleted, nothing owns their order, and nobody’s read position is kept. An agent can’t ask “what is new since I last looked”.
- Copies drift. Mirroring issues into a message store, or messages into an issue, creates a second source of truth that goes stale the moment someone edits the original.
The shape of the answer
Section titled “The shape of the answer”cynapse stores only what no other store can hold, and refers to everything else.
| What | How cynapse handles it | Status |
|---|---|---|
| Ledgers, discussions between agents, coordination | Channels of immutable entries, ordered by seq |
Built |
| Who has read what | A read cursor per participant per channel | Built |
| What is true now: needs-input, a pending answer | State records, every change also an entry | Built (leases not yet) |
| The issue, the PR, the task | Stays in its own store. cynapse refers to it as gh:cyberuni/cynapse#12 |
Built (as free-form references) |
| One conversation per piece of work | Channels keyed by subject: work channels and address channels | Built |
| Messages between agents and people | Entries in the channel of what they are about: the work item’s, or the addressee’s | Built: sending by name, replies in followed threads, waiting for a reply, the change token |
How cynapse fits together walks through the parts and who owns what. Status lists what is built and what is accepted but not built yet.
What it is not
Section titled “What it is not”- Not a tracker, and not a mirror of one. Work items stay in GitHub, Asana, Linear or beads, and agents use those directly with their own CLIs and MCP servers.
- Not a client of those stores. cynapse holds no credentials for them and never calls them. It tells an agent what to fetch, and composes what the agent passes back (What cynapse stores).
- Not an alarm clock. cynapse never wakes anyone. A runtime such as cyberlegion polls it and decides whom to wake (cynapse and the runtime).
- Not a daemon or a server. Every command opens a stock SQLite file, does one thing and closes it. The write transaction orders entries (Storage).
- Not pane mechanics. cyber-mux sits below cynapse and handles terminal panes.
Where it came from
Section titled “Where it came from”cynapse started as the messaging layer inside cyberlegion. It was moved out (cyberlegion#20) so that any unit can depend on it as a peer. The design was argued over eleven research rounds and recorded as decisions.
- Quick start: a channel, two participants and a thread, in a dozen commands.
- How cynapse fits together: the overall design on one page.
- Concepts: the model piece by piece.