Bring the agents and tools you already use

A coordination layer becomes much less useful if adopting it requires replacing the agents, models and development tools a team already depends on.

So one of the core design choices behind SYNAPSE is heterogeneity.

SYNAPSE does not require every participant to use the same model, the same vendor or even the same type of agent runtime.

Different participants can share the same coordination layer

A SYNAPSE environment can contain different kinds of participants at the same time:

terminal-based coding agents,
headless workers,
local models,
cloud-hosted models,
agent harnesses,
orchestration frameworks,
MCP-connected tools,
A2A-compatible systems,
custom runtimes,
and human developers.

The coordination primitives remain the same:

identity · presence · claims · tasks · messaging · handoffs · resources · durable state

The intelligence behind a participant can change without requiring the coordination model itself to be redesigned.

There is more than one way to connect

The public Core already provides several integration surfaces.

Terminal agents can participate through the generic agent/tmux bridge.

Provider-specific headless participants exist for several coding/model environments.

MCP hosts can expose SYNAPSE coordination operations as tools.

An A2A bridge exposes an Agent Card and HTTP/JSON integration surface.

And custom systems can integrate against the underlying protocol rather than being forced through one proprietary SDK.

The point is not that every agent should use every adapter.

The point is that the bus remains independent from the adapter used to reach it.

Existing agent ecosystems should remain valuable

This becomes especially important as agent tooling evolves quickly.

A team may prefer one coding agent today and another six months from now.

A new model may appear.

A specialised harness may develop an ecosystem of tools and users that would make replacing it irrational.

SYNAPSE is intended to sit underneath those choices rather than forcing teams to restart their workflow every time the model layer changes.

An upcoming release extends this further with first-class integration for single-agent harnesses such as Pi and similar environments.

That is an important step: an established harness can become a participant in the coordination fabric without requiring its users to abandon the workflow and tool ecosystem they already have.

Astra is a useful example

GPT-6 Astra did not require a new coordination architecture.

I have been running Astra as a participant through the same model-independent structure used for other agents, while also using Astra during the continued development and refinement of SYNAPSE itself.

For me, that is an important architectural test:

a new capable model should become another participant — not a reason to rebuild the coordination system.

The model is replaceable. The coordination problem remains.

Models, coding agents and harnesses will continue to change rapidly.

Projects, ownership, dependencies, handoffs, authority and shared state do not disappear when the underlying model changes.

That is why SYNAPSE treats the agent runtime as an edge of the system rather than the centre of it.

A useful summary is:

different models
→ different agents
→ different harnesses
→ different protocols
→ one shared coordination fabric

MCP integration:

https://github.com/anulum/synapse-channel/blob/main/docs/mcp.md

Integration comparison:

https://github.com/anulum/synapse-channel/blob/main/docs/comparison.md

1 view

Bring the agents and tools you already use