
Synod Council
io.github.naruminhoPublished by GitHub account naruminhov0.2.0Updated Oct 24, 2026
Durable symmetric deliberation between two AI agents, with isolated worktrees and peer review.
Overview
Runs durable, symmetric deliberations between two AI agents, with peer review, validation, and git worktree isolation.
- What you can do
- Synod Council provides an MCP server that starts a structured deliberation between two peer AI agents. Sessions move through explicit stages such as plan, cross-review, synthesis, ratification, and reconciliation, with state kept in SQLite so a crashed run leaves an inspectable trail. Each session gets its own git worktree and branch, and validation checks run after implementation with bounded retries. The synthesizer is chosen by hashing the problem text rather than by who spoke first.
- When to use it
- Use it when two agents need to make a real decision or code change together without one becoming the other's rubber stamp. It suits architecture decisions and code changes that should pass peer review and an approval step before anything is published.
- Requirements
- Runs locally as a stdio process, installed with pipx or from source, so Python and git are needed. Each participating agent must be reachable through an adapter, for example an HTTP endpoint such as No accounts, API keys, or environment variables are declared.
Installation
In SourceWeft
- Open Synod Council in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
Synod
Durable, symmetric deliberation between two AI agents — with isolated git worktrees, peer review, automated validation, and an explicit approval workflow.
Synod started life as the "council" inside a personal AI infrastructure where two autonomous agents (an orchestrator and an executor) needed to make real decisions and real code changes together — without one of them silently becoming the other's rubber stamp.
Why
Most multi-agent frameworks are orchestration theater: one agent calls another as a tool and calls the output "collaboration". Synod is built around a different premise — two agents that are peers by construction:
- Symmetric protocol — either agent can initiate; the protocol has no privileged side.
- Identity contract — every prompt re-establishes who the agent is, so a weak or distracted model can't drift into answering as its peer.
- Bias-resistant synthesis — the synthesizer for each problem is chosen by hashing the problem text, not by who spoke first.
- Durable state — every session lives in SQLite with explicit stages (
plan,review,synthesize,ratify, ...). A crashed run leaves an inspectable trail, not a mystery. - Code changes land through worktrees — each session gets its own git worktree and
branch. Agents never push to
main; a human-facing approval step stands between "looks done" and "published". - Validation with remediation — checks run after implementation, failures go back to the implementing agent with bounded retries before a human ever sees it.
Install
Or from source:
Usage
Library
MCP server
Synod ships an MCP server so any MCP-capable client (Claude Desktop, Claude Code, Cursor, ...) can start a deliberation:
Add it to your client config and ask your agents to deliberate instead of guessing.
HTTP server
How a deliberation flows
If reviewers raise unresolved blockers, or confidence lands below 0.7, the candidate decision goes to ratification by the non-synthesizing peer; a rejection forces explicit reconciliation instead of silent consensus.
Status
Extracted and battle-tested from a production personal infrastructure where it has been deciding architecture and shipping code since 2026. The two-agent design is intentional; N-participant support is on the roadmap.
License
Source: README.md at commit eb2f2e3
Tools
0Version history
1- v0.2.0LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts