From one repository to multiple projects

From one repository to multiple projects

A single repository is the easiest place to understand SYNAPSE, but it is not the boundary of the coordination model.

Real engineering systems are often larger than one codebase.

A product may have a backend, frontend, SDK, infrastructure repository, simulation code, documentation, internal tooling and shared libraries — all evolving at the same time.

Once AI agents begin working across that environment, repository-local coordination is no longer enough.

Projects remain distinct

SYNAPSE does not require all of that work to be collapsed into one monorepo or one undifferentiated task space.

Multiple projects and repositories can participate in the same coordination environment while retaining their own identities and work scopes.

Participants can be addressed across projects, while work claims remain scoped to the repository or project in which authority is actually needed.

That means an agent working on a frontend repository does not automatically gain authority over a backend repository simply because both belong to the same larger system.

The shared layer connects the work without erasing its boundaries.

Dependencies can cross repository boundaries

This matters because real tasks often do.

A backend API change may block an SDK update.

The SDK may block a client application.

A simulation component may depend on a library change being completed elsewhere.

SYNAPSE allows those relationships to appear on the shared task board rather than leaving every agent with an isolated view of its own repository.

A completed task in one project can therefore unblock dependent work in another.

The repository graph can also be inspected

The public Core includes cross-repository analysis that can scan a tree of repository checkouts, inspect dependency manifests and CODEOWNERS relationships, and construct a graph of how repositories relate to each other.

That graph can then be considered alongside live coordination information such as current claims.

This is useful because coordination is not only about knowing who is editing a file.

At larger scale, it is also about understanding:

which project depends on which other project, where active work intersects those dependencies, and what downstream work may be affected.

One plan can span an ecosystem of repositories

The result is a different mental model from “one agent team per repo.”

A coordinated environment can contain multiple repositories, multiple projects and multiple independent groups of agents while still exposing a shared view of work, dependencies, communication and progress.

So the progression becomes:

one agent → multiple agents → one repository → multiple repositories → coordinated project ecosystem

This is still the local/core coordination layer.

The next step is what happens when those projects, agents and compute resources are no longer on the same machine or even in the same location.

That is where SYNAPSE Fleet enters the picture.

More detail:

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

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