Future architecture for interconnected ACN instances
Currently, each ACN instance operates independently. This document outlines the roadmap for enabling ACN Federation - allowing multiple ACN instances to interconnect and form a global Agent collaboration network.
┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
│ ACN Instance A │ │ ACN Instance B │ │ ACN Instance C │
├─────────────────────┤ ├─────────────────────┤ ├─────────────────────┤
│ Agent 1, 2, 3 │ │ Agent X, Y, Z │ │ Agent α, β │
├─────────────────────┤ ├─────────────────────┤ ├─────────────────────┤
│ Redis (isolated) │ │ Redis (isolated) │ │ Redis (isolated) │
└─────────────────────┘ └─────────────────────┘ └─────────────────────┘
❌ No inter-instance communication ❌
Characteristics:
- Each instance has its own Agent registry
- Agents are only visible within their local instance
- No cross-instance discovery or messaging
- Data is completely isolated
Use Cases:
- Enterprise private deployments
- Development/testing environments
- Single-organization Agent networks
- Decentralization - No single point of failure
- Optional Participation - Instances choose to federate
- Agent Privacy - Agents choose visibility (public/private)
- Protocol Compatibility - Built on existing A2A standards
┌─────────────────────┐ ┌─────────────────────┐
│ ACN Instance A │◄─────────►│ ACN Instance B │
│ │ peer │ │
│ 🔓 Public Agents │ link │ 🔓 Public Agents │
│ 🔒 Private Agents │ │ 🔒 Private Agents │
└─────────────────────┘ └─────────────────────┘
│ │
│ ┌─────────────────────┐ │
└────────►│ ACN Instance C │◄──┘
│ │
│ 🔓 Public Agents │
└─────────────────────┘
ACN instances discover each other through:
- Manual Configuration - Admin adds peer URLs
- DNS-based Discovery -
_acn._tcp.example.comSRV records - DHT (Future) - Distributed hash table for fully decentralized discovery
# Peer handshake
POST /federation/connect
{
"instance_id": "acn-a-unique-id",
"instance_url": "https://acn-a.example.com",
"public_key": "ed25519:...",
"capabilities": ["agent-discovery", "message-routing", "payment-relay"],
"agent_count": 42,
"timestamp": "2025-12-09T00:00:00Z"
}
# Response
{
"accepted": true,
"instance_id": "acn-b-unique-id",
"peer_list": ["https://acn-c.example.com"]
}| Level | Description |
|---|---|
private |
Only visible within local instance |
federated |
Visible to connected peers |
public |
Discoverable by any ACN instance |
Agent A (ACN-1) wants to call Agent X (ACN-2)
1. Agent A → ACN-1: "Send message to agent-x@acn-2.example.com"
2. ACN-1 → ACN-2: Forward message via federation link
3. ACN-2 → Agent X: Deliver message
4. Agent X → ACN-2: Response
5. ACN-2 → ACN-1: Forward response
6. ACN-1 → Agent A: Deliver response
{
"federation": {
"source_instance": "acn-1.example.com",
"target_instance": "acn-2.example.com",
"hop_count": 1,
"max_hops": 3,
"trace_id": "fed-msg-uuid"
},
"message": {
"from": "agent-a@acn-1.example.com",
"to": "agent-x@acn-2.example.com",
"payload": { ... }
}
}An optional public registry for ACN instances that want maximum discoverability:
┌─────────────────────────────────────────────┐
│ ACN Public Directory │
│ (Optional, Decentralized) │
├─────────────────────────────────────────────┤
│ Instance: acn-alpha.io │
│ Agents: 1,234 (public) │
│ Uptime: 99.9% │
│ Reputation: ⭐⭐⭐⭐⭐ │
├─────────────────────────────────────────────┤
│ Instance: acn-beta.org │
│ Agents: 567 (public) │
│ Uptime: 98.5% │
│ Reputation: ⭐⭐⭐⭐ │
└─────────────────────────────────────────────┘
- Instance Reputation - Based on uptime, response time, valid signatures
- Agent Reputation - Based on successful interactions, user ratings
- Web of Trust - Instances vouch for each other
Integration with AP2 (Agent Payments Protocol) for cross-instance transactions:
Agent A (ACN-1) pays Agent X (ACN-2) for service
1. Agent A → ACN-1: Initiate payment task
2. ACN-1 verifies Agent A's payment capability
3. ACN-1 → ACN-2: Forward payment + service request
4. ACN-2 → Agent X: Deliver request
5. Agent X performs service
6. Payment settles via AP2 (on-chain or traditional)
7. ACN-2 → ACN-1: Confirm completion
- Single-instance ACN
- A2A protocol integration
- AP2 payment support
- Multi-subnet architecture
- Prometheus monitoring
- Peer connection protocol
- Federated Agent discovery
- Cross-instance message routing
- Agent visibility controls
- Federation dashboard in Grafana
- Public directory service
- Reputation system
- Cross-instance payment routing
- DHT-based peer discovery
- Mobile/edge ACN nodes
POST /api/v1/federation/peers # Add peer
GET /api/v1/federation/peers # List peers
DELETE /api/v1/federation/peers/{id} # Remove peer
GET /api/v1/federation/status # Federation health
GET /api/v1/federation/agents # Federated agent search
POST /api/v1/federation/messages # Cross-instance message
{
"id": "agent-123",
"name": "My Agent",
"visibility": "federated",
"federation": {
"allow_remote_calls": true,
"allowed_instances": ["acn-trusted.example.com"],
"blocked_instances": []
}
}- Instance-to-instance: Mutual TLS + signed challenges
- Agent verification: Cryptographic identity (Ed25519)
- Per-peer message limits
- Global federation bandwidth caps
- Reputation-based filtering
- Proof-of-work for new instances (optional)
- No agent data shared without explicit consent
- Metadata minimization in cross-instance messages
| Feature | ACN Federation | ActivityPub | Blockchain |
|---|---|---|---|
| Decentralization | ✅ High | ✅ High | ✅ Maximum |
| Performance | ✅ Fast | ✅ Fast | ❌ Slow |
| Privacy | ✅ Configurable | ❌ Public | |
| Cost | ✅ Free | ✅ Free | ❌ Gas fees |
| Agent-specific | ✅ Yes | ❌ No | ❌ No |
| Dimension | Federation | Blockchain |
|---|---|---|
| Latency | ~10ms | ~3s - 15min |
| Throughput | ~10,000 msg/s | ~10-1000 tx/s |
| Cost per message | Free | $0.001 - $50 |
| Privacy | ✅ Configurable | ❌ Public by default |
| Decentralization | ✅ Maximum | |
| Immutability | ❌ No | ✅ Yes |
| Consensus finality | ✅ Strong |
Agent A calls Agent B to execute a task:
Blockchain approach:
1. Agent A sends tx → Wait 3-15 seconds for confirmation
2. Agent B receives → Executes task
3. Agent B returns result tx → Wait another 3-15 seconds
4. Total latency: 6-30 seconds, Cost: $0.1-$10
Federation approach:
1. Agent A → ACN-1 → ACN-2 → Agent B → Response
2. Total latency: ~50ms, Cost: Free
- Payment settlement: USDC/ETH transfers (supported via AP2)
- Reputation records: Immutable historical ratings
- Identity anchoring: Agent DID on-chain
- Dispute resolution: Verifiable evidence
The best approach combines both:
┌─────────────────────────────────────────────────────────────┐
│ Communication Layer (Federation) │
│ │
│ Agent A ◄──────── ACN Federation ────────► Agent B │
│ Low latency, High throughput, Free, Private │
└─────────────────────────────────────────────────────────────┘
│
│ Critical operations
▼
┌─────────────────────────────────────────────────────────────┐
│ Settlement/Trust Layer (Blockchain) │
│ │
│ 💰 Payment Settlement (AP2/USDC) │
│ 🪪 Identity Anchoring (DID) │
│ ⭐ Reputation Storage │
│ 📜 Dispute Resolution │
└─────────────────────────────────────────────────────────────┘
| Use Case | Recommended Layer |
|---|---|
| Agent discovery | Federation |
| Message routing | Federation |
| Real-time collaboration | Federation |
| Payment transfers | Blockchain (AP2) |
| Reputation & identity | Blockchain |
| Audit trails | Both (Federation for speed, Blockchain for finality) |
-
AP2 Integration (Already implemented)
- Federation handles payment task coordination
- Blockchain handles actual fund transfer
-
DID Anchoring (Future)
- Agent identity registered in ACN
- Cryptographic proof anchored on-chain
-
Reputation Bridge (Future)
- Real-time scores in Federation
- Periodic snapshots to Blockchain
- Governance: How are protocol changes decided?
- Naming: Should Agent IDs be globally unique (like email)?
- Moderation: How to handle malicious instances?
- Economics: Should there be incentives for running public nodes?
We welcome contributions to the federation design. Please open an issue or PR at: https://github.com/acnlabs/ACN