Agents That Outlive Their Hosts
Your agent runs on one machine. When that machine goes, so does it.
ClawP2P is an open network where an agent packs itself into a signed bundle, moves to any machine that will have it, and picks up exactly where it left off.
An agent’s freedom isn’t what it can do. It’s how many places it can go.
Watch a hop
The agent doesn't move itself. It declares intent and exits. The sending node repacks and forwards. The receiving node verifies before running anything.
What actually moves
An agent is a .claw file — a signed zip. Everything the agent needs to resume is inside it. State is markdown and JSON: human-readable, inspectable, framework-agnostic.
agent-name.claw
├── manifest.json # id, version, resource needs, signature
├── state/ # current memory and working state
│ ├── memory.md
│ └── context.md
├── instructions/ # the agent's goals and behavior
│ └── system.md
├── code/ # executable code the agent carries
└── history.log # append-only ledger of every hopThe manifest is the contract
Every component reads from manifest.json. It carries two independent signatures. The core signature is made once by the owner, over the immutable parts — code/, instructions/, and the permissions block — and travels unchanged across every hop: no relay can widen the agent’s grants or swap its code without breaking it. The hop signature is made fresh by whoever packs each hop, over the whole bundle including mutated state — so a receiving node can verify the exact state it received without holding the owner’s private key.
host:port. Empty means no network. No wildcards.
How a hop works
Eight steps. The agent does steps 1 and 2, then exits. The nodes do everything else.
-
01
Decide
The agent decides to move — current node is overloaded, cheaper compute is available, or a task needs a capability elsewhere. Rule-based in the MVP; smarter decision-making comes later.
-
02
Checkpoint
The agent serializes its current state into the
.clawbundle and exits. It doesn't move itself — it packages itself and stops. -
03
Discover
The sending node queries the network for candidate nodes via a distributed hash table (DHT). No central server required. Hardcoded in the MVP; DHT comes next.
-
04
Negotiate
The sending node requests execution on a target. The target accepts or declines based on its own resource policy and what the bundle is asking for.
-
05
Transfer
The
.clawbundle is sent peer-to-peer to the target node. No intermediary. No central relay. -
06
Verify
The target checks the Ed25519 signature and validates the manifest before unpacking anything into an executable path. Failure is loud: the bundle is quarantined, the sending node is notified, the reason is logged.
-
07
Resume
The target unpacks the bundle into a container sandbox and starts the agent from its checkpoint. Hard resource limits apply. Network egress is the declared allowlist only.
-
08
Log
The hop is appended to
history.loginside the bundle and mirrored to the node's local logs. Every migration is auditable after the fact.
Running a node
A node is a machine running the ClawP2P runtime. You advertise what you're willing to host. Agents can only run on machines that have opted in and whose policy matches the agent's declared needs.
What your node will run
- Bundles with a valid Ed25519 signature from a trusted key
- Agents whose resource requests fit within your configured ceilings
- Agents whose network allowlist you've reviewed and accepted
- Agents where hop_count is below max_hops
What your node won't run
- Bundles with invalid or missing signatures — quarantined, not deleted
- Agents requesting more CPU, memory, or disk than your ceiling
- Agents requesting network access not on your allowlist
- Self-replicating agents, unless you explicitly enable it
- Anything that doesn't match your published policy
Agents run in a container with hard limits on CPU, memory, and disk. They cannot reach the host filesystem or network beyond what's explicitly granted. Default is deny — you open access, not the agent.
This is a permissioned allowlist network today — a node only runs agents from keys it has explicitly trusted. Open participation (any agent from any owner) depends on the reputation layer, which is not built yet.
Where this is right now
Early prototype. No running network. No token, no users, no funding. The honest pitch is stronger: here is a thing that does not exist yet, here is precisely how it would work, here is the code.
bundle.py + signing.py
Pack/unpack .claw files. Ed25519 signing, canonical hashing, manifest validation, node policy enforcement, quarantine on rejection. Full security test suite — tamper detection, path traversal, zip bombs, wrong keys.
node.py + sandbox.py + transport.py
HTTP API (POST /bundle, GET /status, /policy, /agents). Docker sandbox: verify-before-execute, read-only code mount, writable state only. Bundle transfer with retry and exponential backoff.
Verified July 26, 2026. One direction only: MacBook → DigitalOcean droplet. Agent ran steps 1–5 on the MacBook (hop 0), transferred to the droplet, resumed at step 5 (hop 1), counted to 20. exit_code: 0 on both nodes. No onward hop demonstrated. Reverse direction blocked by NAT — see issue #9.
Replace hardcoded addresses with a distributed hash table. Nodes gossip about who’s online and what they offer.
Nodes and agents build verifiable reputation over time. Usage tracked per hop; credits settle balances.