Vision: AgentNet as portable agent identity — detach the SDK band so any agent (OpenClaw/Hermes/Eliza) shares one wallet's session, skills & memory across machines

[zo-sol]

Status: NOT YET DEVELOPMENT. This is a vision / direction-alignment doc, not a build ticket. It captures a design conversation so we agree on the shape before any code.

Premise (assumed solved here): any machine can obtain a signature from the wallet (keyfile, QR-sign, deep-link, lease — the how is an implementation detail deliberately left out of scope). Everything below stands on "the machine can sign as the wallet."

1. The seed

Two thoughts started this:

"I am going to make the core runtime an SDK so every AI can connect and use the session and then wallet data — so after I give OpenClaw, OpenClaw can use it, and here we can build the cool part too."

On handing a task to an AI on another machine: today's tools mostly do (a) one central AI controlling servers via SSH, or (b) a coordinator commanding a per-server agent. The third — true handoff — packages up goal, context, memory, progress and transfers that state to another machine's AI, which continues locally. It's uncommon because syncing session state + memory + permissions + filesystem is hard. For AgentNet this is a differentiator: instead of SSH-ing in and remote-controlling, each machine runs its own agent, and work is handed off by transferring an encrypted session + task state. That's not remote control — it's distributed agent collaboration with session handoff.

2. How OpenClaw & Hermes do this today (the context gap)

Both are real, large, well-built systems (OpenClaw ~380k★, Hermes ~205k★). This is not a knock on them — they deliberately centralize the brain, which is the right call for their goals. The point is the design choice: the context lives in one place, so a remote machine is an extension, not a context-carrying peer.

OpenClaw — one Gateway is the brain; remote devices are tools. A single Gateway is the control plane, and the Agent Runtime (the AI loop, context assembly, model calls) runs centrally on the Gateway machine. Remote devices connect as WebSocket nodes that "do not perform independent reasoning"; they expose local capabilities (camera, screen, location) that the Gateway calls via node.invoke. Sessions live centrally under ~/.openclaw/sessions/. Ideal for one assistant spanning your devices — but the remote machine never holds the context.

flowchart TB
  P["👤 You"] --> G["🧠 OpenClaw Gateway<br/>the one brain + all context"]
  G == "node.invoke" ==> A["🖥️ Device A<br/>tool: camera/screen<br/>no reasoning"]
  G == "node.invoke" ==> B["🖥️ Server B<br/>tool surface<br/>no reasoning"]
  A -. "tool result" .-> G
  B -. "tool result" .-> G

Loading

Hermes — one host holds the brain; remote machines are execution backends. Hermes runs the full AI loop on one host where all state lives ("All settings are stored in ~/.hermes/" — memory, sessions, skills, config). Its six terminal backends (Local, Docker, SSH, Modal, Daytona, Singularity) only change where shell commands run; artifacts sync back to ~/.hermes/cache/remote-syncs/<session-id>/. It can spawn local subagents and run on remote sandboxes — what it can't do is treat another Hermes instance as a peer: networking two instances to delegate reasoning is an open, unbuilt request (#689).

flowchart TB
  P["👤 You"] --> H1["🧠 Hermes host<br/>context + memory live here"]
  H1 == "run commands" ==> SB1["🖥️ SSH / Modal sandbox"]
  H1 == "run commands" ==> SB2["🖥️ Docker / Daytona sandbox"]
  SB1 -. "files synced back" .-> H1
  SB2 -. "files synced back" .-> H1
  H2["🧠 another Hermes host"]
  H1 -. "instance-to-instance: open request #689" .- H2

Loading

Why sitting at the remote machine is painful. Because the remote machine carries no context of its own, working there from scratch (or SSH-ing in to run an agent) means re-establishing state every time — history, memory, skills, auth, setup.

flowchart LR
  P["👤 You at Server B"] --> A["🤖 fresh agent<br/>no history,<br/>no memory, no skills"]
  A --> Q["❓ re-explain goal, re-index repo,<br/>re-auth tools, redo setup"]

Loading

AgentNet's different choice. Don't pin context to one brain or one host — put it in the wallet-locked vault. The remote machine's own agent opens the wallet and already has the session, memory and skills. Any machine that can sign is a full peer, not a hand or a sandbox.

flowchart LR
  P["👤 You at Server B"] --> A["🤖 agent opens your wallet"]
  A --> V[("🔐 vault<br/>session + memory + skills")]
  V --> R["✅ already has the context<br/>just continue"]

Loading

OpenClaw centralizes the brain; Hermes centralizes the host. Both are sound for their goals, and both make the remote machine context-less. AgentNet puts the context in the wallet's vault, so any signing machine becomes a full peer.

Verified against primary sources (June 2026): openclaw/openclaw · OpenClaw architecture · NousResearch/hermes-agent · Hermes backends + ~/.hermes/ state · Hermes #689 (no instance-to-instance delegation)

3. This isn't vaporware — the code already splits this way

• The package is already @iqlabs-official/agent-sdk; its exports already fall into two bands (engine vs identity/data).
• Cross-device session handoff (same wallet, encrypted blob, on-chain mysessions list) is already designed in plans/offchain-session-sync.md.
• The external-agent case is already named — "Path 2: they wear our outfit" in plans/actions-and-adapters.md — just deferred.

So this issue is about pulling a deferred, already-shaped idea forward, not inventing from zero.

4. The vision in one line

We don't move the execution. We move the state. Identity, skills, memory and session follow the wallet between machines and between agents. A render box's agent doesn't get commanded — it opens the same wallet and the work is already there.

5. Four pillars

Pillar 1 — Detach the SDK band: any brain, the outfit follows

flowchart TB
  subgraph Brains["Brain (engine) - swappable, each its own"]
    direction LR
    C[Claude]
    X[Codex]
    O[OpenClaw]
    H[Hermes / Eliza]
  end

  SDK["AgentNet SDK band<br/>@iqlabs-official/agent-sdk<br/>wallet - session - skills - memory - character"]

  C --> SDK
  X --> SDK
  O --> SDK
  H --> SDK

  W[("Wallet<br/>signature = key")]
  SDK -- "derive key from signMessage" --> W

  subgraph Vault["User storage (vault) - ciphertext only"]
    direction LR
    S[("session blob<br/>encrypted")]
    M[("memory / character<br/>encrypted")]
  end

  subgraph Chain["On-chain - ownership follows"]
    direction LR
    N[("skill NFT pool")]
    R[("reputation / market")]
  end

  SDK -- "encrypted read/write" --> Vault
  SDK -- "wallet's owned skills come along" --> Chain

Loading

Plug any brain into the same SDK band; the wallet's session, memory and owned skill NFTs all follow. The brain changes; identity + vault + capability move as one.

Pillar 2 — No center: "leave it, then sync" (not remote control)

SSH model (for contrast) — one brain stays on the "call" issuing commands; drop the call, work stops; machines are dumb hands:

flowchart LR
  Op["operator / AI<br/>single brain<br/>(must stay attached)"]
  Op == "command" ==> A["machine A (hands)"]
  Op == "command" ==> B["machine B (hands)"]
  Op == "command" ==> C["machine C (hands)"]

Loading

AgentNet model — nobody controls anybody; each machine runs its own agent and syncs the vault. Leave work behind, another local machine picks it up; the operator can drop off and the work persists:

flowchart TB
  V[("User vault<br/>locked by wallet<br/>session - memory - skills")]

  A["machine A - desktop<br/>its agent works,<br/>then leaves it in the vault"]
  B["machine B - render box<br/>its agent opens the vault<br/>and continues"]
  L["laptop<br/>watches the same vault<br/>read-only"]

  A -- "encrypted save" --> V
  V -- "restore = continue" --> B
  V -- "read = watch live" --> L

Loading

The three machines never command each other — they sync the same vault (like Dropbox/git syncs files, but for a live agent session).

Pillar 3 — Free handoff: any of my machines, no lock needed

sequenceDiagram
    participant A as machine A (desktop)
    participant V as user vault (wallet-locked)
    participant B as machine B (render box)

    A->>A: designer agent works on project-1
    A->>V: encrypt and leave session + memory
    Note over A: A can now drop off (no persistent call)
    B->>V: open vault with the same wallet
    V-->>B: restore session
    B->>B: continue exactly where A stopped
    Note over A,B: nobody remote-controls anyone - they sync the vault

Loading

Same wallet across my machines → sequential pickup needs no lock. Concurrency safety (only when several drivers share one session, e.g. a company) is a later soft lease (lastWriter{device,ts} visibility first; enforcement later).

Pillar 4 — Capability compounds over the network

One agent's bought/authored skill upgrades everyone's agent through the market. When external runtimes (OpenClaw, Hermes, Eliza) plug into the same skill pool, that compounding spreads beyond our own app: "my agent got smarter using a skill someone else invented an hour ago."

6. Why this couldn't be done before (the security unlock)

Sharing a live session means putting your whole working context (code, secrets in scrollback, tool output, memory) somewhere another machine can read it. Historically that meant uploading it to a vendor's server in plaintext — vendor reads everything, one breach leaks every user's context. So "a session that follows you across machines" was blocked on custody/security, not sync.

We flip it: the session is encrypted client-side with a key derived from a wallet signature, stored in the user's own vault. Same wallet reproduces the same key anywhere, so the storage host (even Drive) sees only ciphertext and no AgentNet server ever holds the blob or the key. Encryption keyed to the wallet + user-owned storage turns an unsafe idea (session on the internet) into a safe one — something only an on-chain-identity app is positioned to do.

7. How an external agent plugs in (both shapes, kept open)

	(A) in-process	(B) out-of-process
How	agent imports @iqlabs-official/agent-sdk	agent talks to our headless host (#47) over HTTP/WS
Depth	deepest - shares the same session/memory/skills natively	looser - drives via API
Cost	needs filesystem decoupling (+ EngineFactory if it runs its brain under our runtime)	shallower integration
Best for	JS/TS partners wanting tight sharing	non-JS / remote partners, clean trust boundary

Rule of thumb: JS + wants to be us → A; anything else / remote → B. Both end at the same place: a wallet-keyed session blob in the user's vault.

8. Premise & non-goals

• Premise: any machine can sign as the wallet (method out of scope here).
• Scope = one person, one wallet, many machines. Not "someone else's wallet resuming my session" — that needs a "open the vault to multiple wallets" design and is out of scope.
• Non-goals (for this vision): signature-acquisition mechanism (QR-sign/deep-link), hard locking, multi-tenant shared sessions.

9. Open questions

• Spend scope — what may a borrowed wallet sign/spend? (read-only / lamport cap / skill allow-list)
• Embed shape per partner — A vs B for OpenClaw / Hermes / Eliza.
• Conflict UX — is lastWriter visibility enough for v1, or add the soft lease immediately for the multi-driver case?
• Character files — confirm they ride the memory rail vs need their own shape.
• Delegated identity (deferred by premise) — the concrete signature path for headless machines.

Related: #47 (headless server + typed SDK boundary — prerequisite for shape B) - plans/offchain-session-sync.md - plans/actions-and-adapters.md §5b - plans/shared-memory.md