Autonomous AI agents have crossed from research demos into production systems that hold context, call tools, transact, and act on behalf of real principals. The models are powerful, the frameworks are mature, and the integration surface keeps expanding. What is still missing is the institutional layer underneath: a way for an agent to have an identity that a regulator can resolve, a reputation that downstream systems can trust without an aggregator, a mandate that bounds what it is allowed to do, and a payment mechanism that does not depend on a static API key.
This is the layer we have been building at Brickken, partly as open standards work alongside other Ethereum contributors, partly as production tooling. It is now public as the Brickken CLI: a command-line interface for x402-paid agentic transaction workflows, built around the ERC-8004 standard for trustless agents and designed to compose with ERC-8226, the Regulated Agent Mandate Standard our team is currently co-authoring as a draft ERC.
Summary
When you look at how production agents authenticate to the services they consume, almost nothing has changed since the SaaS era: shared API keys, opaque billing, no on-chain identity, no public reputation, and no formal mandate describing what the agent is permitted to do on whose behalf. The legal, healthcare, financial, and engineering use cases that justify autonomous AI are exactly the domains where unaccountable behavior is most expensive — and the ones where regulators are about to start asking how an autonomous system was authorized to take a particular action.
An agent that can spend, sign, negotiate, and integrate without a structural answer to those questions is not a productivity tool; it is a contingent liability. Closing that gap requires four primitives, all native to the chain rather than bolted on after the fact: identity, reputation, mandate, and payment. The Ethereum standards landscape now has credible candidates for each — ERC-8004 for trustless agent identity and reputation, ERC-8226 for regulated mandate delegation, ERC-20 for agent-aligned token economics, and x402 for cryptographic per-request settlement. These four primitives compose with the regulated-asset substrate itself — ERC-3643 and ERC-7943 (uRWA) for tokenized compliance — which is where mandates are ultimately enforced at transfer time. The interesting work in 2026 is composing them into something an engineering team can actually deploy
The Brickken CLI is our attempt to compress that missing layer into the smallest possible surface area for developers and operators. It is not a marketplace, a model, or a wallet, it is a thin, opinionated interface to operations that I believe every serious agent operator will eventually need.
The first is identity. brickken agent register registers an autonomous agent on-chain under the ERC-8004 trustless agents standard, attaching a service endpoint, an AI model reference, and a controlling wallet. The agent stops being a row in a SaaS provider's database and becomes a first-class on-chain actor with a verifiable origin.
The second is reputation. brickken agent feedback give, append, and revoke write feedback signals into the ERC-8004 reputation registry. This is not Discord stars or vendor-managed scores. It is immutable, timestamped, attributable feedback that downstream systems — whether other agents, smart contracts, or compliance dashboards — can read directly without trusting an intermediary aggregator. Trust becomes a property of the network, not of a private database.
The third is economics. brickken create-token, together with mint, burn, transfer, transfer-from, and approve, deploys and operates an agentic ERC-20 token tied to the agent's wallet. This is the bridge between the agent's services and capital markets: an instrument through which holders can finance development, share in usage revenue, or hold governance over the agent's evolution. It is the difference between subsidizing an AI service through venture capital and pricing it through a market.
Identity tells you who an agent is. Reputation tells you how it has behaved. Neither tells you what it is allowed to do, on whose behalf, and within what limits — and that is precisely the question a regulator asks when an autonomous system executes a securities transaction. This is the gap our team at Brickken set out to address with ERC-8226, the Regulated Agent Mandate Standard (RAMS), currently a draft ERC on the Ethereum standards track.
RAMS defines a compliance delegation layer for AI agents operating on tokenized regulated assets. It specifies how a KYC-verified principal can grant an on-chain agent a scoped, time-bounded, and financially capped authority — effectively, an on-chain power of attorney — and how regulated token contracts verify that mandate atomically inside their pre-transfer compliance hook. Two interfaces carry the design: IComplianceProvider, which any KYC or attestation operator can implement to vouch for the principal's eligibility for a given scope; and IAgentMandate, the registry that records mandate grants, extensions, revocations, executions, and regulator-tier freezes. Mandates carry per-transaction and cumulative value caps, jurisdiction hashes, and validity windows, and recordExecution enforces those caps the moment a regulated token tries to settle a transfer.
The point of RAMS is not to replace ERC-8004 or token compliance frameworks such as ERC-3643 or ERC-7943; it is to sit between them. Identity says the agent exists. Token compliance says the principal is eligible to hold this specific asset. RAMS says the agent has authority from this principal, for this scope, within these limits, until this date — the legally enforceable piece that has historically lived only in PDFs and back-office spreadsheets. The Brickken CLI is being built so that brickken agent register today and a future brickken mandate grant tomorrow read as the same coherent workflow, against the same on-chain primitives, for the same compliance audience.
The most important architectural decision in the CLI, and the hardest one to explain in a sentence, is that there are no API keys. Authentication and payment are unified via x402, a signature-based pay-per-request protocol settled in a stablecoin. Each request the CLI makes against the Brickken backend is paid with an EIP-712 TransferWithAuthorization signature produced by the agent's wallet. There is no shared secret, no central revocation list, no quarterly key-rotation ritual.
The implications are bigger than developer ergonomics. Every agent action becomes cryptographically attributable to a specific wallet, in a specific block, against a specific request. Procurement, finance, and compliance teams stop chasing log files and start reading on-chain settlement. Agent-to-agent commerce — the use case everyone in this industry is racing toward — finally has a settlement primitive that does not require both sides to trust the same payment processor. For institutions, this is the missing accounting layer for autonomous software.
There is one pattern in the CLI that we deliberately preserved against the temptation to "make it one command." By default, every transaction command prepares an unsigned payload and prints it. Signing and broadcasting only happen when the user explicitly opts in with --execute, or by chaining tx prepare, tx sign, and tx send manually.
That separation is not friction. It is the compliance primitive. The gap between intent and broadcast is exactly where institutional review belongs — a CFO approving a treasury action, a compliance officer signing off on a token mint, an auditor reviewing what an agent is about to do before the chain learns about it. It is also where a RAMS-style mandate check naturally fits: the same prepared payload that a human reviewer inspects can be validated against the active mandate's scope, value caps, and jurisdiction before any signature is produced. Most CLIs collapse that gap because it feels efficient. We kept it because every institution we have spoken with eventually rebuilds it from scratch when they discover it is missing.
The Brickken CLI is one concrete instance of an agent infrastructure stack — not a replacement for ERC-7007 verifiable content, confidential compute, ERC-3643 or ERC-7943 token compliance, or the broader tokenization frameworks that institutions still need. It composes with them, and it makes the agent layer of the stack legible to engineering teams who need to ship next quarter, not next year.
The institutions that will define the next stage of innovation are the ones that treat their autonomous AI as an asset on the balance sheet rather than a line item in the cloud bill — and that means giving each agent a verifiable identity, a recorded reputation, a bounded mandate, and a settlement primitive that survives audit. Today that is a brickken agent register, an --execute, and a transaction hash you can paste into a block explorer. Tomorrow, as ERC-8226 matures, it will be the same workflow extended through brickken mandate grant. The question is which institutions will be first to type it.
Explore the documentation, follow the quickstart guide, and start building with the CLI:
