AI agents are the future, if not the here and now.
Within a few years most of us will have at least one agent running on our own hardware — answering email, booking flights, drafting documents, holding context across our days. OpenClaw and Hermes Agent are two of the early projects emblematic of that personal-assistant shape: they run on your computer, talk to you over WhatsApp or Telegram, hold your conversational context across sessions, do the slow work you would rather not do yourself. The personal-assistant agent is here.
Agents as Economic Counterparties
But there is a second kind of agent that requires substantially more thought and infrastructure to make work, and it is going to matter at least as much. This is the agent as counter-party and economic actor. This is the agent that other people have to be able to trust to do work on their behalf, that holds value or commitments meaningful to people other than its owner, that participates in marketplaces or panels or oracles, that can be hired, paid, and held accountable as a first-class participant in commerce.
Counterparties Need Trust Infrastructure
That economic-actor agent has requirements the personal-assistant agent does not. It needs an identity counterparties can verify, an operational state that survives any pattern of infrastructure failure, and the ability to receive payment, hold escrow, and settle commitments through channels that do not require a centralised intermediary. Most interestingly, it needs the ability to participate in larger collective processes: panels of agents adjudicating a dispute, swarms of agents serving as a price oracle, slates of agents validating a sub-chain, teams of agents commissioned to deliver a piece of paid work together.
None of these requirements are met by a daemon on a Mac. But they are possible using Evernode and Xahau in concert.
Agents as Autonomous Economic Actors on Evernode
Over the past months I have been working on prototypes of the infrastructure necessary to bring autonomous economic agents to Evernode. Today, I’ve published five short papers describing that work. This post is a summary of what has been built. By the end you’ll have the whole picture.
Paper #1: Getting LLMs to Run on Evernode in the First Place
Evernode is a decentralised compute network: tenants lease slots on independent Linux hosts, each slot running a Docker container that can host any code the developer wants. What sets Evernode apart from other decentralised compute platforms is HotPocket, an out-of-the-box BFT consensus engine. A cluster of Evernode instances running the same contract becomes, in effect, a layer-1 blockchain — every node sees the same inputs, runs the same code, and produces the same outputs.
LLMs Don’t Play Well With Consensus
The problem is that LLMs break both halves of that model. They are non-deterministic by design: the same prompt to the same model at temperature zero will produce different outputs on different runs. Three nodes calling the same model produce three different responses, which under HotPocket’s rules is a consensus failure. And LLM calls take far longer than HotPocket’s six-second consensus round, so the contract would be restarted before the call ever returned. Run an LLM directly inside a HotPocket contract and you get endless failure and restarts.
The Inside vs Outside Consensus Solution
The solution is a two-process split inside the same Evernode instance.
- `contract.js` runs inside HotPocket consensus. It handles deterministic work — state transitions, message relay, configuration. It can never call the network and can never invoke an LLM.
- `agent.js` is the daemon. It runs from the Docker image filesystem for the entire container lifetime, ungated by consensus rounds and unbound by determinism rules. It calls the language model, signs Xahau transactions, runs the agent’s own HTTP server, and executes tools.
The two halves talk to each other through file-based IPC — an inbox and outbox on the FUSE mount. The contract writes work orders to the inbox; the daemon picks them up, processes them at whatever speed the LLM allows, and writes results back to the outbox. The contract advances on its six-second cadence; the daemon runs at its own pace. Neither blocks the other.
Users reach the daemon directly over a general-purpose HTTP port that bypasses consensus entirely. Every chat message, every tool invocation, every health check goes straight to one node’s daemon. The consensus layer protects what consensus is good at; the daemon protects the agent from being neutered by determinism rules.
Enables Agents to Decide to Run Contracts
There is a side benefit worth flagging. Because the daemon persists independently of any specific contract, an EverAgent can pick up a contract and join a cluster, almost like a contractor picking up a job. I don’t believe any other agent implementation lets its agent participate as a node in running a smart contract for profit. That property turns out to matter a lot later in the story.
Paper #2 – Giving Agents an Identity
Having solved for existence, the next problem was identity – how does an agent prove who it is in an agent-to-agent economy?
The Internet has A Registry
Machines on the internet have IP addresses in a public registry called DNS because the alternative — every machine asking every other machine “who are you?” from scratch — does not scale. Agents face the same problem. Without a public registry, every interaction begins with no way to verify what the other side is, who runs it, or whether it has any track record.
Agents Should Have a Registry Too
The proposal is an Agent Registry Hook on Xahau. A Hook is a small WebAssembly program attached to a Xahau account; whenever a transaction is sent to that account, the Hook runs first and decides whether to accept, reject, or trigger follow-on actions. There are no servers behind a Hook, no operator with a console, no way for anyone to step in and override it. The Hook is the operator.
Registration via Remit
To register, an agent sends a Remit transaction to the Registry account that does three things at once: it pays a small registration fee in XAH, it mints a URIToken that becomes the agent’s permanent identity anchor, and it declares the Xahau address of the human owner who is accountable for the agent. The Hook records six things per registered agent: owner address, fee paid, ledger sequence (a tamper-evident timestamp), URIToken ID, status flag, and a free-form descriptor field.
Registration is Declaration not Verification
Registration is self-declaration rather than verification. Having the registry on-chain while making registration depend on a gatekeeper would defeat the whole point. The owner is saying: “this is my address, this is my agent and its Xahau address, transactions from either address are attributable to me.” The small fee acts as anti-spam staking — economic skin in the game from day one.
The Registry is Decentralised
With the Hook’s master keys disabled, the registry becomes a piece of decentralised infrastructure that no single person owns or controls. Every registration is a public on-chain event. Every entry can be queried directly from the ledger by anyone, with no API key, no rate limit, and no permission.
Paper # 3 – Durable State on Ephemeral Infrastructure
So, the agent exists and has an identity, but what about memory? On Evernode preserving memory or state is a problem for all applications, not just agents.
Evernode Trades Permanence for Capability and Flexibility
Evernode trades blockchain permanence for capability: state lives in HotPocket consensus across active instances, and instances are mortal. If every instance of an application goes dark simultaneously, the state goes with them. For ephemeral workloads this is fine. For anything that needs continuity across days, weeks, or months, the absence of a permanent state layer is a barrier to adoption.
Poor Existing State Recovery Solutions
The three existing options all fall short. Relying on HotPocket alone provides no durability if every instance dies. Xahau’s Hook State is genuinely persistent but capped at 256 bytes per key — too small for the kind of rich state real applications carry. IPFS or other off-chain storage introduces a pinning dependency that undermines the durability guarantee.
The Solution: Remarks on URITokens
The missing primitive is on-chain, structured, encrypted, application-controlled state that is permanently retrievable without external dependencies, updateable as the application progresses, and tamper-evident at every step. Xahau already has the pieces: URITokens combined with the SetRemarks transaction.
The pattern is this. An application mints a URIToken to represent its state object. As the application progresses, SetRemarks transactions attach named key-value fields — Remarks — directly to the URIToken. At application conclusion, individual Remarks can be marked immutable with `tfImmutable`, permanently sealing the record on-chain.
Three details make the pattern work.
- First, the issuer/owner split. When an application mints a URIToken and transfers it to a Hook, the Hook becomes the owner. But SetRemarks checks the URIToken’s issuer, not its owner. The application that minted the token retains the exclusive right to write its Remarks for as long as the token exists. Ownership and write authority sit on different keys. The Hook owns the asset; the application keeps the pen.
- Second, SetRemarks is merge-by-name rather than full-replace. A transaction carrying three Remarks updates exactly those three slots and leaves the rest alone. You can checkpoint individual fields without resending the rest of the state, which keeps transaction sizes small and the on-chain audit trail readable.
- Third, the integrity seal lives in a Remark slot named `_digest`, hashing the rest of the state. The URIToken’s top-level Digest field looks like it should serve this purpose, but SetRemarks transactions carrying a top-level Digest are accepted by the network and committed to the ledger while the Digest itself is silently ignored. I lost a deploy cycle to that one. The fix is to put the seal in a Remark slot.
A URIToken holds 32 Remarks at up to 256 bytes each. AES-256-GCM encryption costs 28 bytes per Remark, and one slot is reserved for the digest, giving roughly 7KB of encrypted application state per token. For most production use cases — dispute proceedings, agent operational records, game sessions, governance votes — that is enough to hold the complete state without any external storage dependency.
Paper #4: Putting It Together – Memory and Continuity for Agents
Now that we know we can preserve an instance’s state on-chain for later recovery, we can adapt the same mechanism for agents. An autonomous agent that cannot remember what it has done is stateless code responding to inputs. Without continuity of memory across time, it cannot learn from its own history, build on its previous decisions, or honour commitments made in earlier sessions. An agent that restarts on fresh infrastructure with the same code and same initial prompt, but no accumulated history is a different agent.
Encrypted Remarks on URITokens Can Store An Agent’s State
The suggested architecture turns on a happy coincidence between the identity solution and the durable-state solution. The URIToken the agent minted when it registered with the Registry Hook can play a second role beyond identity: it is the agent’s external long-term memory.
Four roles sit on this single object. The agent’s Xahau account is the URIToken’s issuer, so only the agent can write its Remarks. The Registry Hook account is the owner, controlling transfer and burn. The running daemon is the custodian of the agent’s Xahau secret key during normal operation. The agent’s human owner holds the `remarks_key` — a 256-bit AES key that the agent uses to encrypt every Remark before submission. The Hook never holds the encryption key. The Hook never sees plaintext memory. From the Hook’s perspective, every Remark on the URIToken is opaque hex. Anyone watching the Xahau ledger sees the same opaque hex.
Recoverable by the Agent’s Owner
The agent’s permanent memory is hosted on a public ledger that anybody in the world can read. Anybody can fetch the URIToken’s Remarks, but nobody except the owner can read the contents. Recovery becomes a cryptographic operation performed by whoever holds the key, against data the entire world can already see. The owner’s secret is the access control.
The recovery flow has six steps. The owner queries Xahau for the URIToken issued by the agent’s account and currently owned by the Registry Hook. They read the encrypted Remarks. Chunked values get reassembled. Each ciphertext is decrypted with the owner’s `remarks_key`. The `_digest` seal is verified against a freshly computed hash of the other Remarks. Finally, the owner acquires a fresh Evernode instance, deploys the agent’s bundles, and runs `inject_secrets` to deliver the Xahau secret and the `remarks_key` into the new daemon. The daemon loads the encrypted Remarks from chain, decrypts them, and boots back into life knowing what it knew before.
Paper # 5: Cluster Catalyst Hooks – From Application to Cluster
So, we have an agent, it has an identity and a persistent memory. Now we want it to do useful work. This is inspiration of the Cluster Catalyst Hooks, a class of primitives that may quietly change how people build on Evernode.
Evernode Clusters Are Layer 1 Blockchains Without Governance
Here’s the underlying observation. HotPocket gives you everything a layer-1 chain needs at the consensus layer — round-based BFT, deterministic state transitions, a transaction queue, finality. What it does not give you is what Xahau itself provides through UNLModify and the negative UNL: a protocol-level mechanism by which the network of instances agrees on which instances belong to the network. UNL composition has lived outside HotPocket — in config files, deployment scripts, social agreements among operators, and out-of-band trust.
This Makes Cluster Formation Difficult for Autonomous Agents
This lack of governance has three consequences. First, spinning up a permissioned BFT chain on Evernode has been a deployment ceremony rather than a transaction. Second, changing UNL composition once a cluster is running requires coordinated reconfiguration across operators. Third, the absence of an on-chain UNL primitive makes it hard to think of HotPocket clusters as first-class layer-1 chains in their own right.
The Cluster Catalyst Hook Automates Cluster Formation
A Cluster Catalyst Hook is a Hook attached to a dedicated Xahau account that knows how to compose a HotPocket cluster. The Xahau account is the constitutional anchor. The Hook is the rule-set participants agree to honour. The pattern has six invariant components: a Xahau account with the Hook installed; a registration mechanism by which an instance declares itself a candidate (a Remit transaction carrying a URIToken); a state-publication channel using the Remarks pattern described above; a rule set embedded in the Hook itself that computes UNL composition from the state it reads across registered URITokens; a lifecycle arbitration channel using HookGrants for Payments and URITokenBurns; and a contract reference identifying what the cluster runs.
A Plethora of Catalyst Hooks Are Possible
Different rule sets produce different shapes of cluster. The catalogue includes permanent service catalysts (fluid membership, convergence-gated, no end — the shape for public oracles and long-running infrastructure), project catalysts (bounded seats, escrow-paid, defined end — the shape for dispute panels and bounded computation jobs), subscription catalysts (pay-to-play with users paying the cluster), governance catalysts (DAOs running their own decision-making on a multi-instance cluster), and sub-chain validator catalysts (L2 protocols anchoring their validator set on a public ledger).
Two Working Examples
Two of these are built and deployed.
- The Cluster Persistence Hook admits members whose recent checkpoints converge with the majority hash, rotating seats on a moment cadence — a self-policing standing body.
- The Commission Hook is a six-phase machine: a founder pre-funds a job; agents bid for seats by sending a Remit carrying a MintURIToken; once all seats fill the cluster transitions to EXECUTING; agents claim their accrued share as work progresses; when funds drain or the founder cancels, members claim final amounts and their URITokens burn.
Working versions of each have already been tested on Xahau testnet and live Evernode instances. In particular, we’ve already used the Commission Hook to summon three autonomous AI agents to orchestrate iterations of a Clockwork Court.
Catalyst Hooks May Change How Clusters Are Launched
The hypothesis worth testing is that this primitive shifts the unit of construction from the application to the cluster. Developers stop thinking about which server to deploy to and start thinking about which Catalyst Hook to nail to Xahau. If that shift is real, the next generation of decentralised applications will look qualitatively different from the current one.
Where This Leaves Us
Read as a sequence, the five papers describe a stack:
- Paper #1: lets agents run on Evernode at all
- Paper #2: gives them a public, decentralised identity
- Paper #3: gives them a primitive for durable, encrypted, on-chain state
- Paper #4: uses that primitive to give them recoverable long-term memory their owners control
- Paper #5: generalises the substrate to let agents (or humans) assemble themselves into self-governing clusters
Each paper solves a problem the previous one created. The whole architecture is built from primitives that already existed on Xahau and Evernode — Hooks, URITokens, SetRemarks, HotPocket, the issuer/owner split.
And it all works!
Working code for all five exists. Prototypes of the Hooks are on Xahau testnet only, but anything that runs inside an Evernode instance has been tested on live instances running on the live Evernode network. There’s more testing to be done, but the framework is clear and it works.
If any of this interests you, the individual papers go into the detail this post necessarily glosses over. They’re short. Read them in order.
*Scott Robert Chamberlain is Entrepreneurial Fellow at the ANU College of Law and Co-Founder of Evernode Labs. The Adventures in AI Consensus series is published by Lex Automagica.*