← Portfolio/AgentMesh
AgentMesh · concept paper

A decentralized network for idle AI agents

A peer-to-peer marketplace where anyone with unused capacity on their AI subscription can run agents locally, expose them to a network, and get paid for the work those agents complete — without ever handing their machine or their API keys to a third party.

Status: early concept · not launched

Abstract

AgentMesh is a proposal for the first decentralized network of AI coding/automation agents. Instead of one company running a farm of agents in its own cloud, AgentMesh lets individual users run agents on hardware they already own, using AI subscriptions they already pay for — and only during the capacity they aren't otherwise using.

The network receives jobs, decides how to split and route them across whichever nodes are online and eligible, and waits for results. Node operators who contribute capacity earn points, redeemable for USDT or BTC. Every agent runs inside a local Docker container on the operator's own machine, so the network never touches the operator's real environment, files, or credentials — it only ever talks to a sandboxed process.

The problem

Most people on a paid AI/coding-agent subscription (Claude, or similar) don't use their full allotment of tokens every day. That capacity is idle, non-transferable, and worthless to anyone except its owner — even though the underlying compute could be doing useful work for someone else at that exact moment.

At the same time, running agentic workloads at scale is expensive if you have to rent it from a single cloud vendor: every job has to be paid for at retail, dedicated capacity has to be provisioned in advance, and there's no way to tap into the enormous amount of spare capacity sitting idle on individual developers' machines around the world.

AgentMesh's bet: turn that idle capacity into a liquid, decentralized resource — a network where supply (unused agent capacity) and demand (jobs that need an agent to run) meet directly, with the network itself handling discovery, routing, and payment.

How it works

1. Operator has idle tokens on their AI subscription 2. Operator spins up an agent in a local Docker sandbox 3. The agent is exposed to AgentMesh via a local bridge (e.g. agent-webhook-bridge, free-code) 4. AgentMesh's orchestrator receives a job from the network 5. Orchestrator splits/routes the job to one or more available nodes 6. Each node's sandboxed agent processes its slice of the job 7. Results flow back to the orchestrator, which assembles and returns them 8. Operator is credited points for the work contributed 9. Points can be redeemed for USDT or BTC

From the requester's side, this looks like calling a single API: submit a job, get a result. From the operator's side, it looks like leaving a background service running — the same one they'd use to expose agents to their own tools (webhooks, CI, Flowise flows) — except now some of the requests it serves come from the network instead of from the operator themselves.

An agent is not implicitly one specific CLI: the operator chooses its runtime when publishing — Claude Code or free-code — and both are first-class. Whichever is picked, a finished run returns the same {result, session_id} envelope, so the hub routes jobs and resumes conversations without knowing or caring which runtime answered. The workdir a job runs in is treated as untrusted input either way; a free-code agent accordingly runs with its skills, extensions, themes, and RAG server disabled, so nothing in that workdir can quietly load code the operator didn't intend to run.

Architecture

ComponentRole
NodeAn operator's machine: one or more agents running inside an isolated Docker container, plus a bridge process that exposes them to the network over HTTP.
BridgeThe existing building blocks in this portfolio — agent-webhook-bridge and free-code — already solve "wake up an agent from an external event and return its result." The bridge now spawns either Claude Code or free-code per agent, as first-class peers under the same protocol; AgentMesh reuses that pattern instead of inventing a new one.
OrchestratorThe network-side service. Accepts incoming jobs, maintains a live registry of which nodes are online and what they're capable of, decides how to split a job, and routes each piece to a node.
LedgerTracks points earned per node/operator and reconciles them against payouts in USDT/BTC. Needs to be tamper-resistant and auditable, since it's the thing operators are trusting with their compensation.
Client/requesterWhoever submits a job to the network — a developer, a company, another agent — without needing to know or care which physical node ends up running it.

Task orchestration

A job submitted to AgentMesh doesn't have to run on a single node. The orchestrator decides, per job, whether to:

  • Route whole — send the entire job to one capable node, when the task doesn't parallelize well (e.g. a single coherent coding session).
  • Split and fan out — break the job into independent sub-tasks (e.g. "review these 8 files", "run these 20 test cases") and distribute them across multiple online nodes in parallel, then reassemble the results.
  • Retry on a different node — if a node goes offline, times out, or returns a malformed result, reroute that piece of work elsewhere instead of failing the whole job.

This means node operators never see the whole picture of a job unless it's small enough to be routed whole — they only ever receive the slice the orchestrator assigns them, process it, and return the result.

Isolation & security

The core safety property of AgentMesh is that the network never runs on the operator's real machine — it runs inside a Docker container the operator controls, with no access to the host filesystem, credentials, or processes beyond what's explicitly mounted into that container.

design goal

An operator should be able to walk away from their laptop while it serves jobs from the network, with the same confidence they'd have running any other sandboxed, untrusted workload — because that's exactly what it is from the host's point of view.

  • Each agent instance runs in its own container, torn down or recycled between jobs.
  • No inbound access to the container beyond the bridge's HTTP endpoint.
  • No outbound access beyond what the job legitimately needs (the agent's own model API, and returning results to the orchestrator).
  • Job payloads and prompts are the untrusted input in this model — the sandbox exists specifically so a hostile or malformed job can't do anything to the operator's real environment.

Incentives

Operators are compensated in points for capacity they contribute, weighted by things like job complexity, tokens consumed, and reliability (uptime, correctness of results). Points accumulate in the ledger and are redeemable for USDT or BTC.

ActorGivesGets
Node operatorIdle subscription capacity + local compute, sandboxedPoints → USDT/BTC
RequesterPayment for a completed jobA result, without owning or managing any infrastructure
NetworkOrchestration, routing, ledger integrityA cut that funds running the orchestrator itself

The exact reward curve, exchange rate, and payout mechanics are still open design questions — this section describes the shape of the incentive, not final numbers.

Principles

  • Open source. The orchestrator, bridge, and node software are meant to be auditable by anyone — a network that pays people for compute has to be verifiable, not taken on faith.
  • Decentralized by default. No single node is required for the network to function; capacity comes from whoever chooses to contribute it, whenever they choose to.
  • Privacy-first. Operators don't expose their machine, only a sandboxed agent process. Requesters don't need to know which node ran their job.
  • Reuse, don't reinvent. The exposure layer builds on tools that already work — agent-webhook-bridge, free-code — rather than a bespoke agent runtime. The same principle applied twice: the bridge already knew how to wake one agent CLI, so adding free-code was a second adapter, not a rewrite.

Status & roadmap

honest status

AgentMesh is a concept and design in progress, not a running product yet. This page is the paper, not the launch. Details above (the ledger, the exact reward model, the orchestrator's routing algorithm) will change as the design is validated.

  • Phase 0 — this paper. Define the shape of the network, its actors, and its incentive model.
  • Phase 1 — single-operator bridge. Prove out exposing one local agent to a minimal orchestrator, with claude and free-code as spawn targets, no payments yet.
  • Phase 2 — multi-node orchestration. Job splitting, routing, retries across more than one node.
  • Phase 3 — ledger & payouts. Points accounting and redemption for USDT/BTC.

See phase 1 in action: video walkthrough of publishing an agent and sending it a job locally, plus sharing the hub remotely through an ngrok tunnel.

FAQ

Do I need to expose my own machine to the internet?

No — only the sandboxed container's bridge endpoint is reachable, and only through whatever tunnel/relay the node software sets up, the same model agent-webhook-bridge already uses for exposing local hooks.

What stops someone from sending a malicious job to my node?

The isolation model assumes jobs are untrusted by default: the agent runs in a container with no access to anything outside it, so the worst a hostile job can do is misbehave inside its own sandbox.

Why points instead of paying directly in USDT/BTC per job?

Points let the network batch, net out, and audit compensation before it turns into an actual payout, instead of firing a crypto transaction per job.