Napster for AI agents

Agents that pack themselves up, move to another machine, and pick up where they left off.

Today, agents are locked to one server. ClawP2P is a peer-to-peer network where agents migrate to wherever compute is available — verified, sandboxed, and resuming from checkpoint.

Early prototype No running network yet MVP in progress

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.

Node A
checkpoint
📦 count: 5
State serialized, agent exits
transfer
Node B
verify
🔏 signature ✓
Signature checked, manifest validated
Node B (running)
resume
▶ count: 6
Picks up from checkpoint
Node A
count: 5
running
📦
—
Node B
—
waiting

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 hop

The manifest is the contract

Every component reads from manifest.json. It declares what resources the agent needs, what network destinations it may reach, whether it can replicate, and a cryptographic signature that nodes verify before running anything.

agent.id Immutable across all hops. Changes mid-journey → rejected.
permissions.network_egress Explicit allowlist of host:port. Empty means no network. No wildcards.
permissions.may_replicate Defaults false. Node policy must also permit it. Both sides must agree.
migration.hop_count Incremented by the sending node, never by the agent. Rejected when it exceeds max_hops.
integrity.bundle_hash Computed over every file. Recomputed and compared on arrival before anything runs.

How a hop works

Eight steps. The agent does steps 1 and 2, then exits. The nodes do everything else.

  1. 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.

  2. 02
    Checkpoint

    The agent serializes its current state into the .claw bundle and exits. It doesn't move itself — it packages itself and stops.

  3. 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.

  4. 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.

  5. 05
    Transfer

    The .claw bundle is sent peer-to-peer to the target node. No intermediary. No central relay.

  6. 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.

  7. 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.

  8. 08
    Log

    The hop is appended to history.log inside 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.

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 format — 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.

✓
Single-node runtime — 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.

▶
Two-node migration + demo agent

Node A checkpoints, transfers to hardcoded Node B, Node B verifies and resumes. Demo agent counts, logs its hostname, hops every 5 steps.

○
DHT discovery

Replace hardcoded addresses with a distributed hash table. Nodes gossip about who's online and what they offer.

View the code on GitHub →