NOVRA Intelligence

An AI agent authorised to move money is two systems with incompatible guarantees bolted together. The model produces a distribution over plausible actions; the contract produces exactly one state transition and produces it identically on every node that verifies it. Most integrations treat this as an interfacing problem — get the agent to emit a well-formed transaction — and that framing is what causes the losses.

The difference is the point. Probabilistic reasoning is valuable precisely where rules are incomplete: interpreting an invoice, judging whether a counterparty request is consistent with an agreement, deciding that a market condition warrants action. Deterministic execution is valuable precisely where discretion is dangerous: transferring value, changing permissions, committing to a state that cannot be revised. A well-designed system does not blend these. It draws a boundary and enforces it, placing authorization, settlement and irreversible state transitions on the deterministic side.

Rollback asymmetry is the underlying constraint

Software architecture usually assumes errors are recoverable at some cost. On a settled blockchain they are not. A confirmed transfer is not undone; it is at best followed by a second, voluntary transfer in the other direction, which requires a counterparty who agrees. Governance can change future rules; it cannot un-execute the past.

This produces an asymmetry that should dominate the design. On the AI side, errors are frequent, individually cheap, and correctable. On the contract side, errors are rare, individually expensive, and permanent. Systems that ignore the asymmetry make a characteristic mistake: they invest in making the agent more accurate and treat the contract as a pipe. The higher-leverage investment is narrowing what the agent is permitted to make permanent — because compounding step reliability says a long agent trajectory will contain errors regardless of per-step quality, and the only question that matters is which of them can reach an irreversible surface.

Intent, authorization and execution are three different things

The clearest way to structure the boundary is to stop treating “the agent does a transaction” as one act. It is three, and they should be separable in the code.

Intent is the agent’s proposal: pay this invoice, this amount, this recipient, for this reason. Intent is probabilistic output. It should be structured, logged, and treated as a request.

Authorization is the deterministic evaluation of that intent against policy: is this recipient on the allow-list, is the amount within the standing limit, has the required condition been satisfied, is the cumulative spend within budget? This step contains no model. It is code, or it is contract logic, and its answer is reproducible.

Execution is the state transition itself, performed only on an authorized intent.

Collapsing intent into execution — letting the model both decide and act — is what makes prompt injection a treasury risk rather than a content risk. Once the three are separate, an adversary who fully controls the model’s output still controls only step one, and the blast radius is bounded by policy rather than by the model’s judgment about whether an instruction looked legitimate.

Authority belongs in the account, not in the prompt

The mechanism for expressing that policy already exists and is under-used by teams coming from the AI side.

Account abstraction under ERC-4337 moves authorization logic into a smart contract account that validates operations before they execute, rather than relying on a single private key that either signs anything or signs nothing. The pattern that matters for agents is the session key: a signing key that is time-limited and scope-limited, authorised once for a bounded set of actions.

The architectural consequence is significant. An agent granted a session key valid for four hours, restricted to a named set of contracts, capped in cumulative value, is not “trusted.” It is scoped. When it misbehaves — and a probabilistic system will — the boundary of the damage is a property of the key, enforced by code, rather than a property of the instructions the model was given.

This is the same rule that governs context in AI systems generally: authority expressed as text is advisory, authority expressed as an enforcement point is real. Blockchain infrastructure happens to provide an unusually strong version of that enforcement point, because the constraint is evaluated by the same verification process that decides whether the transaction is valid at all.

The oracle is where determinism leaks

Here is the part that most architecture diagrams get wrong, and it deserves more attention than the agent layer.

A smart contract is deterministic with respect to its inputs. Any contract making decisions about the outside world — a price, a delivery confirmation, an identity attestation — depends on an oracle, and the oracle is a point where non-determinism, latency and incentive re-enter a system chosen for having none.

The industry has a precise name for the resulting economics. Beyond ordinary maximal extractable value, oracle extractable value is the value available from the timing and ordering of oracle updates — the window between a real-world change and its on-chain reflection. This is not a theoretical concern: it has produced enough measurable extraction that mitigation is now productised, including Chainlink’s Smart Value Recapture work with Aave to return part of that value to the protocol rather than to searchers.

For an AI-driven system the implication is direct. An agent reasoning over on-chain state is reasoning over data that is deterministically executed but probabilistically current. Treating an oracle price as ground truth rather than as a reading with a staleness window and an adversarial ordering environment is the same class of error as treating a retrieved document as a fact rather than a claim. The correct engineering response is also the same: bound the staleness explicitly, and make the system’s behaviour under a stale or disputed reading a designed path rather than an accident.

Inclusion is not finality, and the gap is a design input

Two different events get collapsed into the word “confirmed”, and agents are usually written as though only one of them existed.

Inclusion is a transaction appearing in a block. On Ethereum that is a single slot — roughly twelve seconds — and it is what most tooling reports as a confirmation. Economic finality is the point at which reversing the transaction would require an attacker to control and forfeit at least a third of all staked ETH. Ethereum currently reaches economic finality in roughly 15 minutes: the protocol finalises at epoch granularity through a two-phase commit, where a checkpoint attested by a two-thirds supermajority becomes justified and is finalised once the following epoch’s checkpoint is justified in turn — about 12.8 minutes of protocol time, and in practice a little longer depending on where in the epoch the transaction landed.

(Projection, not fact — and explicitly not something to architect against: the Ethereum Foundation’s published roadmap direction targets substantially faster finality. That work began as single-slot finality, became three-slot finality, and continues as the Minimmit protocol under the Lean Ethereum programme. As of mid-2026 it remains active research with no fork assignment, and public roadmap discussion points toward the end of the decade. No system being designed today should assume it.)

The practical consequence is not that applications must sit idle for fifteen minutes. Almost nothing does, and a design that waited on finality for every action would be unusable. The consequence is that any action whose correctness depends on irreversible settlement needs an explicit confirmation policy — stated once, at the architecture level, rather than decided implicitly by whichever library reports “confirmed” first.

A workable policy names three things. Which operations may proceed on inclusion, accepting a small reorganisation risk in exchange for latency: reading, quoting, provisional reservations, anything internally reversible. Which operations must wait for finality: releasing goods, extending credit against on-chain collateral, or any second irreversible act taken in reliance on the first. And what the system does if a transaction it acted upon is reorganised out — which is a designed compensation path, not an exception handler written after the incident.

Two cases deserve particular attention. Cross-chain sequences are the dangerous one: an action final on one chain and merely included on another is an inconsistency an autonomous system will otherwise resolve by improvising. And human review has to fit inside the window or it is reviewing history — the same oversight that can actually intervene problem, in a setting where the deadline is set by a consensus protocol rather than by organisational preference.

Where this genuinely pays, and where it does not

The convergence is over-claimed in the market, so it is worth being precise about where the pairing earns its complexity.

It pays where an agreement’s conditions require judgment but its execution must not. Verifying that a delivery matches a contracted specification is interpretive work suited to a model; releasing the payment is a state transition that should be mechanical once the condition is marked satisfied. It pays where authority must be delegated narrowly and revoked reliably, which is what scoped keys provide and what conventional credentials provide badly. And it pays where an audit trail must be verifiable by parties who do not trust each other — a property ordinary logs cannot supply, because ordinary logs are written by one of the parties.

It does not pay when the only motivation is that both technologies are current. If every participant already trusts a single operator, a database and an approval workflow deliver the same control with less operational risk. Adding a contract introduces key management, upgrade governance, oracle dependencies and irreversibility to a problem that had none of them. The honest test is whether the deterministic layer is doing work that a trusted operator could not do — most often, enforcing a constraint against the operator, or providing evidence to a party who cannot take the operator’s word.

The strategic reading

For an organisation evaluating this, the useful reframing is that blockchain infrastructure is not primarily a settlement network in this architecture. It is a policy enforcement substrate that the operator cannot quietly override, and that property is what makes it interesting underneath probabilistic systems.

The design question therefore stops being “should we use AI agents with smart contracts” and becomes a boundary question with three parts. Which decisions require judgment, and are therefore probabilistic by necessity? Which actions are irreversible, and must therefore sit behind deterministic authorization? And what is the smallest authority that lets the first act on the second — expressed not as an instruction, but as a scope that holds when the instruction fails?

Answer those three and the architecture follows, including the unglamorous conclusion that most systems need a much smaller autonomous surface than their first design assumed. The systems that survive contact with real capital are not the ones with the most capable agents. They are the ones where the agent’s worst possible output is still a bounded event.