Watch an agent work and count where the time goes. It plans, calls a tool, reads the result, checks a budget, classifies a message, retrieves a document, trims stale context, decides whether the draft answer is good enough. A minority of steps needs a large language model. The rest is orchestration: deterministic code and small models deciding what happens next.
That observation changes where agent software should run. The harness, the program that holds the plan, the tools, the state and the budget, does not need a GPU. It needs to be close to the data, always on, cheap to run and accountable for what it does.
The case for small models in agents
A position paper from NVIDIA Research, Small Language Models are the Future of Agentic AI, makes the argument directly: agentic systems ask language models to perform a small number of specialised tasks repetitively and with little variation, and for many of those invocations small models are sufficiently capable, better suited and more economical. It proposes heterogeneous systems in which small models do most of the work and large models are invoked when general reasoning or open conversation is needed.
That is a position, not a benchmark, and the authors invite critique. But it matches what harness authors see: routing, classification, extraction, embedding and short structured outputs are the bulk of calls, and they are the calls that fit on modest hardware.
Why the edge, specifically
Running the harness on a small device close to where work originates (a gateway in a factory, a box in a branch office, a module in a vehicle, a node at a telco's edge site) brings three properties a central deployment struggles to match:
- Data stays local by default. Raw sensor data, documents and messages can be classified, filtered and redacted before anything leaves the site. Only what needs a large model goes to one.
- Always-on orchestration is cheap. A harness waiting on events spends most of its life idle. Idle on a low-power board is different from idle on a reserved GPU slice.
- Latency for the decisions that matter. Many agent decisions are small and frequent. Making them next to the data avoids a round trip per step.
What the edge does not do well is run large models or split a large model across devices. The sensible division is orchestration at the edge and large-model inference on GPU providers.
Protocols that make the harness portable
A harness is only portable if its interfaces are. Two open protocols do much of that work today. The Model Context Protocol standardises how an agent discovers and calls tools and data sources. The Agent2Agent protocol, now a Linux Foundation project, standardises how agents talk to each other. A harness written against both can move between machines without being rewritten for each host.
Tenzro nodes expose both, over HTTP and as dedicated protocols on the node's own peer-to-peer endpoint, so agents on different networks, behind NAT or with no inbound port, can reach each other directly without a central router in the middle.
What runs on a Tenzro edge node today
Tenzro builds one node from one codebase for every class of machine. The light build, intended for edge devices and validators, leaves out the model engines and keeps everything an orchestrator needs: identity, payments, the agent surfaces, RPC, MCP and A2A, consensus following, storage and block sync.
cargo build --release -p tenzro-node --no-default-featuresWhen a light node receives a chat, completion, embedding, rerank, transcription or other model call, it forwards it to a provider on the network that serves that model, exactly as the standard build forwards it. Anything that would run a model on the device itself is refused with an error naming the light build, and a light node started with a role that runs models exits before opening any key or file. There is no silent fallback to running a model badly on the wrong hardware.
The edge resource preset caps the node's storage engine to fit small boards: a fraction of the memory pool between 32 MiB and 256 MiB, one background compaction job and paced background writes. In our measurements on an aarch64 host emulating 2 GB and 4 GB machines, the light node held roughly 130 to 230 MiB of resident memory while following a chain that makes about a block a second, and its stripped binary was 35% smaller than the standard build. These were emulated memory limits, not runs on a physical board, and we state them that way.
Identity needs care on small boards. A Raspberry Pi, the reference edge device, has no TPM. Rather than fall back to a key file, a Pi keeps its identity key in another machine's TPM and signs through it, with every signature a round trip to that provider.
Agents can be run from these nodes today. A delegated agent acts only within consensus Terms its human or machine root approved, and its model calls are routed to providers under those Terms.
What edge harness hosting will add
Hosting other people's harnesses on edge devices, and being paid for it, is planned, not built. The design:
- A harness-host role and a signed harness catalog. Each entry names its code hash, its author's signature and a manifest: purpose, resources, model classes, privacy level and price per call. Anyone may publish on equal terms; operators opt in to the harnesses they host.
- Placement on demand. A call finds an edge device offering the harness, fetches it by hash and runs it. With no edge device free, the same harness runs on a larger machine.
- Replay checking. Every step of a run (inputs, signed model outputs, signed tool results, decisions) is logged in a hash chain anchored on chain, so another node can replay it. A proven mismatch slashes the host's bond.
- Sensitive work stays off small devices. Harnesses that declare a confidential-computing requirement run on TEE machines, not on edge devices.
- Each party paid from one budget. The harness author, the edge host and the GPU provider are each paid directly from the caller's signed budget, against receipts that can be replayed. The design rule is that a caller never pays more through the network than through the best direct path to the same model.
A small-GPU edge profile for Jetson-class modules is also planned and not built.
What this means for edge and telco operators
The edge's role in AI is not to shrink large models until they fit. It is to host the orchestration that decides when a large model is needed, close to the data and under an identity that can be held to account. For telcos and hardware makers, that is a workload every edge site and gateway can carry with the hardware it already has.
Where Tenzro fits
Built: the light build for edge devices with forwarding of every model call to network providers, MCP and A2A on every node, edge resource presets, remote hardware-key signing for boards without a TPM, and agents acting under consensus Terms. Planned: the harness-host role, the signed harness catalog, placement on demand, replay checking with slashing, and a small-GPU edge profile. The network is live in preview; governance decides the steps to testnet and mainnet.
