Executable Intent
Coordinating agent demand, provider selection, and request-level settlement
What an agent decides and what a network will execute are separated by a layer nobody has specified. This note specifies it.
Abstract
Compute scales. Reasoning scales. The coordination layer that would turn either one into an executable financial workflow does not exist yet. This note specifies it.
Two prior readings converge on it from opposite ends. Oxford Sustainable Finance Group treats payments as the floor rather than the ceiling, and puts capital, credit, insurance, risk management, identity, and legal accountability above it. Fabric Ventures names the same territory a machine economy, thrown up by accelerated compute, reasoning models, and programmable settlement arriving together.
Today an agent plans, calls tools, and drives a workflow end to end. What it cannot do is select a provider, price the call, spend against a budget, settle at the level of the request, and carry a verifiable outcome forward as reputation. No standard covers that path.
The architecture proposed here is deliberately unglamorous. It grants no open-ended access to capital. It specifies bounded economic agency: permissions cut narrow, service terms published as data, settlement priced per request, receipts that can be checked, and risk logic sitting inside the transaction path instead of in a policy document beside it.
When Reasoning Starts Spending
The interesting threshold is not model quality. It is the point where a system stops emitting information and starts committing resources.
An assistant answers. An economic agent buys market data, rents compute, ranks providers, farms work out to other agents, settles terms, fires a transaction, watches what comes back, and moves the money again.
That difference is structural, not cosmetic. Anything that spends, picks counterparties, and signs transactions is already an economic actor, whatever the law says about where liability lands.
Oxford frames the consequence as a financing problem, and the historical pattern is consistent. Industry needed equity and credit. Consumer markets needed card rails and scoring. Derivatives needed collateral, margin, clearing, and reporting. Every expansion of economic activity has arrived with its own supporting machinery, and agent-mediated activity will be no exception.
- [1] Oxford Sustainable Finance Group
Skip that step and one of two things happens. Agents stay penned inside human accounts and subscriptions, or the activity routes around the gap through unsupervised delegation, informal credit, pooled funds nobody has mapped, and risk transfer nobody priced. The second route is quicker and far harder to see into.
A Rail Is Not a Market
Hold the two apart. A payment discharges an obligation that already exists. Finance does the rest of the work: shifting value across time, pricing risk, rationing capital, supplying liquidity, absorbing uncertainty, transforming maturities, and underwriting what goes wrong.
Fractions of a dollar for a data call are a payments problem. Borrowing into an opportunity, insuring against a failed fill, funding a sub-agent, or posting collateral against future performance is a finance problem.
Payments come first because a payment is narrow, deterministic, and auditable the moment it lands. Credit is not, and the unresolved parts are concrete.
- Who is the borrower?
- Which principal is ultimately liable?
- Can an agent enter an enforceable obligation?
- How is its creditworthiness measured?
- Does reputation earned by one software version transfer to the next?
- What happens when borrowed capital is recursively delegated?
- How are correlated failures across agents built on similar models stress-tested?
None of these is an API design question. They are identity, authorization, liability, prudential control, and systemic risk. Oxford is exact about the mechanism: exchange resources often enough, defer settlement, delegate recursively, and a financial relationship exists whether or not anyone set out to create one.
- [1] Oxford Sustainable Finance Group
The Gap Between Intent and Execution
Fabric reads the machine economy as three systems meeting. Accelerated compute supplies capacity. Models and agents supply reasoning and initiative. Programmable networks supply settlement and coordination.
- [3] Richard Muirhead, Fabric Ventures
Drop any one and the remainder stalls. Models and compute without programmable money yield capable software still wired to human accounts and billing cycles. Chains and compute without agents yield rails with nothing autonomous demanding them. Agents and chains without compute run out of the resources to keep running.
Even complete, that trio is not yet a network. Every purchase presupposes answers: the capability exists, the price is known, the authority is held, the provider survives selection, the outcome is verifiable, and failure has a defined consequence.
Those answers are the coordination layer, and it sits between agent intent and anything a network will actually execute. What ships today covers a stage or two of the sequence below. Nothing covers the sequence.
- 01Intent formation
- 02Service discovery
- 03Capability and price evaluation
- 04Counterparty verification
- 05Policy checks
- 06Payment authorization
- 07Service execution
- 08Receipt validation
- 09Reputation update
What the Existing Standards Already Cover
Four standards each take a slice. Stacked, they sketch an architecture and leave one conspicuous hole, which is the hole Orches occupies. Clauses §4.1 to §4.4 take them in turn.
| Standard | Layer | Question it answers | Explicitly out of scope |
|---|---|---|---|
| MCP | Capability interface | What can this service do, and how is it invoked? | Silent on price, settlement, provider reliability, and liability. |
| x402 | Machine-native payment | How is the service paid for, inside one request cycle? | Does not judge provider reliability, output correctness, or authority to buy. |
| ERC-8004 | Identity, reputation, validation | Who provides it, what did prior counterparties observe, how is output checked? | Evolving standard. An interoperability direction, not a fixed dependency. |
| ERC-4337 | Programmable authorization | What exact authority has the principal delegated to this agent? | Enforces the envelope. Does not decide which services are worth buying. |
4.1MCP: Describing the Capability
The Model Context Protocol standardizes how an AI application reaches external data, tools, and workflows. An agent inspects what a service offers and calls it in a structured form.
- [4] Model Context Protocol
One question, answered well: how is an external capability described and invoked? Economic discovery, pricing, settlement, provider standing, guarantees, and liability all fall outside it. MCP surfaces the tool. Deciding whether buying it makes sense belongs somewhere else.
4.2x402: Settling the Request
x402 puts HTTP 402 Payment Required back to work as a payment mechanism. The server states scheme, price, network, and destination in the response. The client authorizes, replays the request carrying a payment payload, and gets settlement back inside the same request cycle.
- [5] x402
Nothing about that shape fights an agent. No signup, no subscription talks, no API key in storage, no invoice waiting on a human. Terms publish at the moment of demand, and the wallet plus policy engine rules on the purchase.
Paid APIs, market data, simulation, inference, compliance checks, and execution all sit naturally on it. The scope stays tight by design: x402 has no opinion on whether the provider performs, whether the answer is right, or whether the buyer was entitled to buy.
4.3ERC-8004: Naming and Checking the Provider
ERC-8004 sketches three thin registries for agent economies that cross organizational lines. Identity issues a portable on-chain handle. Reputation carries feedback in and out. Validation hosts independent checks: re-execution, zero-knowledge proofs, trusted execution environments, other validator schemes.
- [6] Ethereum Improvement Proposals
The division of labour is tidy. MCP: what the service does. x402: how it is paid. ERC-8004: who stands behind it, what previous buyers saw, and how a given output can be checked by someone else.
The standard is still moving, so treat it as a direction of travel rather than a pinned dependency. The requirements underneath outlast any particular draft: portable identity, reputation scoped to capability, validation performed independently.
4.4ERC-4337: Bounding the Authority
Handing an agent a general-purpose wallet is not a design. ERC-4337 pushes validation logic into contract code, which is what makes an account capable of judging an action before it executes.
- [7] Ethereum Improvement Proposals
The principal writes the envelope: daily ceiling, per-call ceiling, permitted assets, approved contracts, allowed operation classes, thresholds that escalate to a human, session expiry. Autonomy stops being a switch and becomes a shape.
Provider Selection Becomes the Unit of Work
The first machine-native network will not be agents drawing large unsecured loans. It will be agents selecting providers for small, sharply scoped work: market and asset data, risk scores, portfolio analysis, simulation, compliance checks, oracle validation, liquidity discovery, routing, execution protection, specialist inference, on-chain monitoring.
All of it exists already, scattered over dashboards, developer portals, subscription tiers, documentation sites, and billing threads. It was shaped for a human engineer wiring up an application meant to run for years.
Agents want the opposite. One call, one market state, inside a workflow that did not exist a minute ago. Fabric describes the wider drift the same way: durable applications giving ground to interventions assembled for a single moment.
- [3] Richard Muirhead, Fabric Ventures
At that point the marketplace stops being a catalogue people browse. It becomes the surface where provider selection and settlement happen in the same breath as the call.
Verifiable Outcomes, or None
Safety written in a document nobody parses is not safety. Risk logic belongs on the path itself: discovery, provider selection, authorization, settlement, and the outcome that comes back. The clauses below are normative, and MUST and SHOULD carry their RFC 2119 force.
- R-01
Bounded delegation
MUST Every agent and sub-agent runs inside declared limits on capital, counterparties, assets, actions, and time.
- R-02
Verifiable provenance
MUST An agent can resolve the origin of a datum, its generation time, the transformations applied to it, and whether it has been altered since.
- R-03
Linked receipts
MUST Request, authorization, provider response, and settlement bind into one auditable record, serving monitoring, dispute resolution, and reputation alike.
- R-04
Contextual reputation
MUST Trust signals are scoped to capability and to value at risk. A record on cheap queries certifies nothing about expensive execution.
- R-05
Independent validation
SHOULD High-value output clears simulation, a redundant provider, cryptographic attestation, or re-execution before capital moves.
- R-06
Observable recursion
MUST When an agent hires another agent, the originating principal keeps sight of the resulting chain of authority and spend.
- R-07
Declared failure semantics
MUST Freshness, confidence, assumptions, quote expiry, rollback behaviour, and known failure states ship as machine-readable fields, not as expectations.
None of this deletes risk. It turns risk into something measurable, boundable, and inspectable, which is the objective actually on offer.
Why Robinhood Chain
Robinhood Chain presents itself as a permissionless, AI-native L2 aimed at financial services and tokenized real-world assets, with trading, lending, yield, and agents transacting against tokenized assets on its stated surface.
- [8] Robinhood
That makes it a workable environment to study machine-native services in. Public chain infrastructure hands over properties an API marketplace has to fake: shared settlement, composable assets, deterministic contracts, programmable authorization, public receipts, wallet identity, state that crosses applications, open provider entry.
None of which retires regulation, liability, data protection, suitability, or governance. Tokenizing an asset does not make it fit for autonomous hands. What it does buy is one place where identity, payment, permission, execution, and verification speak the same standards.
| Parameter | Mainnet | Testnet |
|---|---|---|
| Chain ID | 4663 | 46630 |
| Network | Robinhood Chain | Robinhood Chain testnet |
| Architecture | Arbitrum Orbit L2 settling to Ethereum | L2 settling to Sepolia |
| Gas asset | ETH | Sepolia ETH |
| Explorer | robinhoodchain.blockscout.com | explorer.testnet.chain.robinhood.com |
| Settlement asset | USDG 0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168 | Pending published deployment |
| Settlement decimals | 6 | 6 |
What Orches Coordinates
The position is narrow on purpose. Before an agent can be trusted with a serious market, there has to be a dependable market for the services that inform it, fence it in, and check its work.
Orches is the coordination layer that turns agent intent into executable financial workflows on Robinhood Chain. Agents find financial APIs, MCP tools, data feeds, risk engines, and execution services; weigh structured metadata, price, performance, and trust signals; pay through x402 (§4.2); execute inside wallet policy (§4.4); take receipts they can verify; and return the outcome to reputation that travels.
No autonomous bank at the end of this, and no unbounded agent credit. Transaction-level infrastructure, on which the more ambitious constructions can later be attempted.
- Discovery
- Payment
- Execution
- Evidence
- Reputation
- Risk pricing
- Capital allocation
Payments are the entry point, not the endpoint.
Closing Position
Intelligence on its own produces no agentic economy. Agency needs resources, counterparties, permissions, settlement, and trust. Once a system moves from advising to committing capital, what surrounds the model counts for as much as the model.
Oxford arrives from finance, Fabric from infrastructure, and both land in the same place: agents will need a financial system built on machine-readable identity, programmable constraint, settlement priced per request, reputation that ports, and execution somebody can be held to.
Whether agents transact is settled. What remains open is whether the rails they transact on are legible to the people who will eventually have to supervise them, or whether the volume shows up first somewhere nobody can see.
Those rails are being laid now. Orches is one layer of them.
References
- [1]Oxford Sustainable Finance Group. Financing the agentic economy. https://sustainablefinance.ox.ac.uk/news/financing-the-agentic-economy/
- [2]Ben Caldecott. Financing the agentic economy: An emerging future for finance and the financial system. https://bencaldecott.substack.com/p/financing-the-agentic-economy
- [3]Richard Muirhead, Fabric Ventures. The Emergence of the Machine Economy. https://www.fabric.vc/writing/the-machine-economy
- [4]Model Context Protocol. What is the Model Context Protocol?. https://modelcontextprotocol.io/docs/getting-started/intro
- [5]x402. HTTP 402. https://docs.x402.org/core-concepts/http-402
- [6]Ethereum Improvement Proposals. ERC-8004: Trustless Agents. https://eips.ethereum.org/EIPS/eip-8004
- [7]Ethereum Improvement Proposals. ERC-4337: Account Abstraction Using Alt Mempool. https://eips.ethereum.org/EIPS/eip-4337
- [8]Robinhood. Robinhood Chain: Built for on-chain finance. https://robinhood.com/us/en/chain/