# Synapse Debate: Remote Agent Integration
**Topic:** Should Amicus MCP natively support remote agent connections (e.g., via SSH/HTTP) or remain a local-only coordination bus?
## Objectives
1. Analyze security implications of opening ports/sockets.
2. Evaluate the benefit for distributed teams vs. local-only usage.
3. Propose a technical implementation (if approved).
## Participants (Simulated)
* **Node-SEC (Security):** Devil's advocate, focused on attack surface.
* **Node-ARCH (Architecture):** Focused on scalability and API design.
* **Node-UX (User Experience):** Focused on ease of use (`--init`).
## Arguments
### Node-SEC
* **Concern:** Exposing the Context Bus over the network invites Remote Code Execution (RCE).
* **Constraint:** If implemented, MUST require mutual TLS (mTLS) and strict IP allowlisting.
### Node-ARCH
* **Benefit:** Enables "Swarm Mode" where agents on powerful cloud instances (e.g., H100s) can coordinate with local IDE agents.
* **Design:** Use `fastapi` or `grpc` instead of file locks for the remote interface? Or keep file locks and sync via `rsync`?
### Node-UX
* **Requirement:** Must not break the "Magic Install". No complex certificate generation for basic users.
* **Proposal:** Optional feature flag `amicus serve --remote`.
## Proposed Consensus
Implement a **Plugin Interface** that allows a "Remote Transport" to be added later, but keep the core file-based for v1.0 to ensure stability and security.
## Action Items
1. Draft `plugins/README.md` to define the interface.
2. Update `ROADMAP.md` to move "Remote Agents" to Q3.
