zai-org/Synapse

zai-org/Synapse

Description: Self-hosted AI workspace with shareable AI teammates, shared conversations, memory, and governed access to plugins, MCP tools, and local devices.

Language: TypeScript

License: Apache-2.0

Stars: 46

Forks: 5

Open issues: 3

Created: 2026-05-13T11:06:53Z

Pushed: 2026-05-20T04:44:45Z

Default branch: main

Fork: no

Archived: no

README:

Build AI teams, not chatbots.

A self-hosted AI workspace for shareable teammates, shared conversations, memory, governed access to plugins and MCP tools, local execution, and event-driven automation.

English (US) · 简体中文 · Español

Why Synapse · Architecture · Example Flows · Roadmap · Quick Start · Surfaces in This Repo · Deployment

> [!WARNING] > Synapse is still in an early design and implementation phase. Schemas, runtime contracts, and product surfaces can change quickly, and backwards compatibility for old data is not guaranteed yet.

Synapse is a conversation-centric runtime for digital teammates.

Most AI products treat chat as a thin interface on top of isolated bots. Synapse treats the conversation itself as the collaboration boundary: humans, platform-native actors, and bridged remote agents can work in the same thread; memory, permissions, plugins, relay-exposed tools, and event sources are governed at the workspace layer; shareable teammates can be added across workspaces like contacts and then granted the right resources to work.

Why Synapse

• Conversation-first, not bot-first. A conversation is the runtime boundary for participants, transcript visibility, actor execution, wakeups, and memory handoff.
• Shareable teammates. Workspace members, actors, and remote agents can be shared across workspaces and added through a contact-style graph. Shared actors can work with the destination workspace's granted resources.
• Governed resource access. Plugins, skills, MCP relay exposures, and event sources are modeled as workspace-owned resources with explicit access control, grants, and audit trails.
• Cloud coordination plus local execution. Teams can collaborate in the web app while still reaching local browsers, desktops, filesystems, internal services, or bridged remote-agent runtimes.
• Event-driven teamwork. Scheduled jobs, custom webhooks, and integration-backed event sources can wake conversations and route work automatically.
• Native and remote agents together. Platform-native actors live inside Synapse. Remote agents join through a bridge and keep their own runtime stack.

Core Model

| Concept | What it means in Synapse | | ---------------- | ------------------------------------------------------------------------------------------------- | | Workspace | Ownership and governance boundary for teammates, plugins, relay devices, and event sources. | | Conversation | Shared runtime where participants collaborate and work is persisted. | | Actor | A native Synapse teammate managed by the platform. | | Remote agent | An external runtime bridged into a conversation without becoming a native actor. | | Resource layer | Plugins, skills, MCP relay exposures, and event sources that can be granted, audited, and reused. |

Architecture Overview

Synapse uses a conversation-centric architecture. Around that core, the system separates resource runtimes, access control, memory, transport integration, and context management into distinct subsystems.

• Conversation and session runtime. conversation, participants, conversation items, actor sessions, and session_wakeups define the primary collaboration and execution model. Web chat, remote-agent bridges, and IM transports reuse this model rather than implementing separate conversation systems.
• Resource runtimes. Plugins, installed skills, relay exposures, actors, and remote agents are represented as distinct runtime resources with independent state, lifecycle, and APIs. Marketplace catalog metadata is stored separately from installed runtime state.
• Access control. Authorization is evaluated against explicit resource types, including workspace, conversation, actor, remote_agent, plugin_installation, installed_skill, relay_capability, and memory_item. Sharing, invocation, and governance therefore rely on the same access model.
• Memory subsystem. Memory is partitioned by scope: workspace_shared, conversation_shared, actor_private, participant_private, and user_private. Retrieval combines lexical indexing and embeddings to support both durable memory and thread-local working state.
• Transport and automation integration. IM transports bind external endpoints back to conversations. Event sources, schedules, webhooks, and integration triggers enter the same runtime so they can wake sessions and emit conversation-visible events.
• Context window management. Model context is compiled from canonical context items into shared and private archive chains plus a live tail window. Archive points, compaction runs, and per-event context policies bound prompt size while preserving scope and event semantics.

Example Flows

• Share a research actor into another workspace, grant it the right plugins, and let it work in the same thread as people.
• Pair a desktop relay so teammates can use browser, filesystem, or command-line capabilities without giving every conversation global access.
• Register GitHub, GitLab, or custom webhook event sources to wake an incident room and bring the right actors into the conversation.
• Bridge a coding agent from another machine as a remote agent and let it collaborate in Synapse while keeping its own external runtime and tools.

Exploratory Features

This section highlights runtime directions that are already being validated in code, but should not yet be treated as stable platform contracts.

Everything is a file model

Synapse is exploring a virtual-filesystem projection for selected local runtimes. The goal is to expose state, structure, and actions through paths, files, and writable control nodes. This fits the platform's authorization model and also aligns with models' strong prior over command-line workflows, where composition, pipes, and chained operations can express richer procedures with fewer execution round trips.

Current support includes:

• Session-scoped VFS exposures. Relay VFS currently projects builtin browser and CUA runtimes under session paths, with file-based controls for session creation, inspection,…