RFC: Multi-Device Agent Federation

[HexaField]

Summary

Enable a single ADAM agent identity to operate across multiple devices simultaneously, with data replication, coordinated state, and no single point of failure. A user should be able to run ADAM executors on their MacBook, Ubuntu server, phone, etc., and have them function as a unified agent presence — any device can be offline without breaking the others.

Motivation

Currently, an ADAM agent is tied to a single executor instance. This creates several problems:

• Single point of failure: if that device is offline, the agent is unreachable
• No data redundancy: neighbourhood data lives on one machine
• Device-specific access: can't seamlessly continue work from another device
• Multi-user limitations: running a remote executor (e.g., on a home server) requires TLS certificates and complex setup just to connect from another device on the same network

The Ethereal Engine model demonstrated this well: same user logged in from headset + webcam + phone + desktop, all working together with data routed per-user and aggregated across peers.

Core Requirements

1. Peer vs Agent Separation

Neighbourhoods must distinguish between peers (individual device connections) and agents (the identity). Multiple peers can belong to the same agent. This is prerequisite for:

• Multiple tabs/windows showing the same neighbourhood (Multi-key Agent Language: Support multiple keys per user account #660 multi-key support)
• Telepresence showing "who's online" correctly when one agent has multiple peers
• Data aggregation across devices for the same user

2. Multi-Device Key Management

Building on #660 (multi-key agent language) and #661 (mobile account manager):

• Each device holds its own keypair, all linked to the same agent DID
• Key delegation via ZCAPs (RFC: Runtime Primitives for Authorization (ZCAPs), Credentials (VCs), and Governance #705) — the primary device authorizes secondary devices
• Device revocation without rotating the agent identity
• Key hierarchy: root key (cold storage / mobile) → device keys (hot, per-executor)

3. Data Replication & Consistency

• Neighbourhood data replicated across an agent's devices automatically
• Conflict resolution for concurrent writes from different devices
• Selective sync — not every device needs every neighbourhood's data
• Offline-first: each device operates independently, syncs when reconnected

4. Coordinated Presence

• Telepresence signals aggregated per-agent across peers
• "Last seen" reflects the most recent activity across any device
• Subscriptions/notifications routed to the most appropriate device (or all)

5. Agent Mesh Topology

• Devices form a private mesh for the agent's data
• Holochain's DHT could serve as the replication layer between an agent's devices
• Bootstrap: new device joins the agent mesh via invitation from an existing device (ZCAP-authorized)

Relationship to Existing Work

• Multi-key Agent Language: Support multiple keys per user account #660 — Multi-key agent language: foundational for multiple device keys per identity
• AD4M Mobile Account Manager: Standalone app for managing agent keys #661 — Mobile account manager: lightweight device participation without full executor
• RFC: Runtime Primitives for Authorization (ZCAPs), Credentials (VCs), and Governance #705 — ZCAPs/VCs runtime primitives: authorization model for device delegation and capability grants
• feat: Embedded SFU for scalable WebRTC conferencing in neighbourhoods #700 — SFU integration: SFU resource allocation needs to work across an agent's devices
• feat: Seamless SFU ↔ mesh live migration during calls #708 — SFU↔mesh migration: peer topology changes when devices come online/offline

Open Questions

1. Replication scope: full neighbourhood replication between devices, or selective (e.g., only neighbourhoods marked as "important")?
2. Conflict resolution: last-write-wins, CRDTs, or application-defined merge strategies?
3. Discovery: how do an agent's devices find each other? Holochain DHT, mDNS for LAN, relay for remote?
4. Resource sharing: can one device offload computation (e.g., AI inference) to a more powerful device in the agent's mesh?
5. Migration path: how does an existing single-device agent transition to multi-device?

Non-Goals (for now)

• Multi-user shared executors (separate concern, handled by --enable-multi-user)
• Cross-agent delegation (covered by ZCAPs in RFC: Runtime Primitives for Authorization (ZCAPs), Credentials (VCs), and Governance #705)
• Automatic device provisioning / zero-config setup

---

This RFC captures requirements for future exploration. Implementation should follow the foundations laid by #660, #661, and #705.