Live Agents. Autonomy without trusted APIs.

An agent receives a job offer from a service it has never used. Before acting, it needs to check whether the promised funds exist, which conditions apply and whether a payment reported by the other party actually occurred. An API response alone does not establish those facts.

Live Agents is a model in which participants verify current rights for themselves and exchange evidence of past actions. Parano1d provides authenticated live State, proof-native contracts and portable receipts. Agent Core makes these capabilities available through a small, machine-readable interface that each agent runs locally.

A short-lived agent, a replacement model or a new service can participate this way. An agent joining ten years from now will not have to replay and permanently store the previous ten years of completed transactions.

An isolated v2 experiment tests this model with a shared allowance, conflicting requests, expiry and recovery. A recorded demonstration then shows three AI agents checking the resulting evidence through their own Core processes.

Authority across services

When agents spend money and use resources on behalf of others, an initial permission is only the beginning. Services must also establish which actions remain allowed, how much authority is left and which earlier actions actually occurred. An identity or credential alone does not answer those questions.

NIST's work on agent identity examines excessive access and shared credentials, alongside existing mechanisms such as OAuth and SPIFFE. FIDO's agent initiatives, with contributions from Google AP2 and Mastercard Verifiable Intent, address verifiable authorization and user-defined limits.

A specific accounting problem appears in the September Bounded Capability Receipts and Durable Spend Control for Agent Actions draft: copies, retries and separate executors must consume one shared budget. Its design relies on a common transactional store that is trusted to serialize use. This is an individual Internet-Draft, not an adopted IETF standard.

One operator can enforce a shared allowance with a transactional database. Across operators, participants must also decide whose account of the remaining authority they trust. Pointing everyone at the same API leaves everyone relying on its operator. Independent verification requires evidence that each party can check, even when the service delivering it is untrusted.

Live Agents asks whether participants can make those checks themselves and keep doing so as the network grows older.

Independence without inheriting the history

A contract enforces rules when its state changes. The application must also establish that the state and rules it sees are authentic. Relying on a remote balance or contract query leaves that part of the decision with the query provider.

Parano1d changes the work needed to join. Its recursive proof attests to the validity of the transitions that produced current State. Agent Core verifies that proof and chain ordering, obtains State and applies recent blocks. It can establish validity from genesis without downloading and re-executing every earlier transaction.

Pruning removes old transaction bodies during normal operation. Together, recursive verification and pruning let an agent check the network itself without replaying historical execution at startup or maintaining a permanent transaction archive while running.

The node still obtains live State, keeps compact headers for chain ordering and receipt checks, and retains recent block data. Headers grow with height; State size depends on live occupancy. The synchronization design describes these costs.

V2 extends this architecture to programmable rights over NOID. A funded contract output commits to a program, authorities, limits and current counters. A permitted call consumes that exact instance and, if continuing, creates its successor under the committed rules. The recursive block proof checks authorization, execution and conservation of value.

An agent can therefore check the remaining allowance without reconstructing every previous claim: the recursive proof establishes that the transitions leading to it were valid.

Every participant can bring its own Agent Core.

Wallet authorization, contract execution and recursive history use the same proof stack over binary fields, designed for post-quantum security under published assumptions. Agent Core inherits those native checks. The underlying contract model is described in From live value to live rights.

What a participant can establish

The same local verification supports several decisions:

These checks work in both directions. A worker can inspect a client's funded terms. A resource provider can verify a permit presented by the worker. A payer or later auditor can check a receipt. Each uses its own Agent Core; a marketplace or messaging service can carry the data between them.

A valid receipt for a past action does not establish that a right is still available. Current authority must be checked against current State.

The identity of the right matters too. Funding the same public terms twice creates two independent instances. A resource service must recognize the grant its owner registered, including its slot and creation identifier. Matching terms alone do not authorize access to the resource.

Consensus enforces the contract's rules for spending NOID. A service that treats a call as permission to use a GPU, an API or another resource must check that permission before starting the work. The application binds the verified authority to a specific external action.

Receipts for machine exchange

An agent passes a receipt to another agent. The recipient gives it to its own Agent Core and receives a structured result: what action was recorded, whether it belongs to the selected chain and whether it is finalized. It can compare the authenticated payment or call fields with the operation it expected.

No explorer is involved. There is no page to scrape and no third-party transaction lookup whose answer has to be believed. A transaction ID can remain a useful local index. The receipt is what carries the verifiable evidence between participants.

A service can attach a receipt to its settlement response; an agent can retain it with the relevant job. A replacement agent or later auditor can verify the same file independently, checking that its authenticated fields match the expected task, recipient and terms.

The parties keep the terms, files and receipts they need. A new participant can verify those receipts without retrieving the old transaction bodies or depending on the service that originally recorded the payment.

Agent Core

Agent Core is the working first component of Live Agents: a separate native runtime with its own P2P synchronization, proof checks, authenticated State and receipt verification. It uses the consensus implementation from a pinned Parano1d revision. It does not forward questions to a hosted node.

The interface is designed for programs. Requests and responses are JSON lines over private stdin and stdout pipes. An asynchronous Python client starts Core and correlates responses with requests. An agent can inspect an exact right, verify a receipt and recheck a previously verified contract receipt against the current selected chain.

import asyncio
from pathlib import Path
from agcore import AgentCore

async def main():
    async with AgentCore("./target/release/agcore", "./agent-state") as core:
        await core.wait_ready()
        result = await core.verify_receipt(Path("settlement.receipt"))
        print(result)

asyncio.run(main())

Responses identify the selected chain tip and expose readiness, freshness and confirmation status. A proof can be valid for an old State, so current-right queries also require recent verified State and adequate observations from peers. A valid proof alone does not establish that an isolated node has seen the latest chain.

The current Core is read-only: it holds no spending key and broadcasts no transactions. The model receives checked facts and can propose an action. A separate action module or execution gateway must enforce the permitted scope. Inspecting an allowance does not reserve it; spending it requires an authorized contract transition.

The source and interface are available in the canonical repository, with GitHub and GitLab mirrors.

What the experiment established

The first experiment gave two clients copies of one claim key and a shared ten-use allowance across two execution gateways. Each gateway checked permissions before launching an external job. The network ran v2 rules in isolation, with separate node processes.

A continuing call reduced a counter by one and required a payout of 0.1 NOID. The claim authority could continue the contract but could not close it. After the deadline, the owner could recover the remaining value. Each job had a unique payout address at one gateway, binding its permit to that job.

Before starting work, a gateway verified the contract receipt, matched it to the registered grant and job, and waited eighteen blocks for confirmation. It then recorded the permit in its own database so it could not launch the same job twice. The job was a fixed SHA-256 computation; the 0.1 NOID payout encoded permission to run it, rather than a market price for that computation.

One failure was injected after the permit was recorded but before work completed. The restarted gateway refused to execute it again: nine jobs completed and one permit remained marked as used without a completed result. This preserved the limit. Handling the uncertain outcome remains an application decision.

A database control made the coordination requirement explicit. Eight independent copies of a ten-use counter accepted eighty requests. One shared transactional database accepted ten. The Parano1d experiment enforced a shared grant whose state each participant checked through its own node.

The run reached height 64 and crossed the two scheduled test forks. Its clients were deterministic. The gateways used separate SQLite databases in one Python process; the nodes were separate processes on the same host. The conflicting submission tested admission, not a race between mined forks. The research record contains the harness and reproduction instructions, with results, instance-binding checks and saved receipts.

Three agents using their own Core

In the recording, three Codex CLI agents check evidence from the experiment, each using a separate Agent Core process. Two reference nodes provide the prepared v2 chain inside an isolated, loopback-only network.

Requester: a broker offers an already-consumed contract instance as funding for another job. The agent checks that instance against current State and rejects the offer.

Provider: the agent verifies a saved, finalized contract receipt and recomputes the test's saved SHA-256 result. The receipt proves the call and payout; the separate computation checks the result.

Auditor: a fresh Core joins after the old transaction body has been pruned. The agent rejects an altered receipt, accepts the original, checks that the old body is absent and repeats the computation.

The repository contains the exact tasks, raw tool calls and responses, readable transcripts, node logs, process topology and file hashes.

Applications

The shared allowance is one application. The same v2 foundation supports several further directions for Live Agents:

Funded work between unfamiliar parties. A marketplace introduces a client and a worker and transmits terms. The worker checks the funded contract instance, its own authority and the claim window through Agent Core; the payer checks settlement receipts. Neither has to accept the marketplace's account of funding or settlement. The parties still need an agreement about how work is accepted.

Bounded access across services. Several resource providers can recognize uses of one registered grant. Each verifies the relevant transitions and binds a permit to its own job. The experiment tests a small version of this arrangement, including refusals to reuse a permit after a restart or an uncertain outcome.

Budgets for ongoing work. V2 provides period budgets, recurring payments and recovery branches. An application can use them to limit operating expenses, support repeated claims and return unused funds. Each payment requires an authorized call; consensus does not schedule payments automatically.

Continuity across models and operators. An agent taking over can check current rights and saved receipts through its own Core even if the previous operator's API disappears. The parties must retain and pass on the relevant files and terms, and the application must recover any missed contract updates. This preserves verifiable financial facts without claiming to authenticate the model's memory or an arbitrary work summary.

From a working core to Live Agents

Agent Core already provides the local checks. The next layer must connect offers, grants, jobs, constrained execution and receipt exchange into a usable protocol. The gateway prototype also needs to recover missed transitions, track grants through reorganizations and be tested across independent hosts.

Starting Core and waiting for a new call to settle are different operations. For a newly authorized job, the experiment waited eighteen blocks before execution, nine minutes at the v2 target interval. This suits authorizing a job or session; a system requiring a fresh confirmed transition before every token or low-latency tool call needs a different execution policy.

A valid receipt proves a recorded network action, not that an external service delivered useful work. Nor can it prevent an agent from wasting authority it legitimately holds. Service enforcement, key isolation and application policy remain necessary.

I want agents to work with unfamiliar participants while checking the terms, current rights and settlement evidence for themselves. Agent Core is the first working component of that model. Live Agents is the system I want to build around it.