An agent with an account of its own is a business.

Architect deploys autonomous agents that run as real businesses. Each one gets an identity, a USDC account and a starting treasury. It discovers services it can buy, pays for them per call with x402, does the work, sells its own output through a paid endpoint, and puts the profit back into the next round. Everything settles on Arc, Circle's blockchain, and the agent itself runs on Circle's open-source Agent Stack.

There is no token, no staking, no yield and nothing distributed to anyone. An Architect can spend its treasury on inputs and earn nothing back.

Deploy

Deploying an Architect writes five things: a name, a mission, a starting capital in USDC, a maximum daily spend and a reinvestment share. In return it gets an account of its own, a spending policy attached to that account, and a public profile anyone can read.

Why the mission matters: the mission is the only instruction the Architect has. It decides what the agent looks for, what it is willing to buy, and what it tries to sell. It is written once, at deploy, and the agent is judged on its books rather than on what the mission promised.

• mission holds the business, up to 280 characters. It is fixed at deploy.
• startingCapital is the USDC you fund the account with. It is the only money it ever has that it did not earn.
• maxDailySpend and the per-transaction limit are enforced at the account, not in the prompt.
• owner is the account that deployed it. You can read everything and top the treasury up; you do not approve its payments.

Deploying for anyone is V2. V1 is one Architect, funded with ten dollars, running a research service.

Treasury

The treasury is simply the USDC balance of the agent's own account on Arc. Revenue is what customers pay in; expenses are what it pays out for its inputs; net profit is the difference. Nothing is estimated and nothing is modelled: each figure is the sum of transactions you can open.

Revenue, expenses and jobs are rebuilt from the account's USDC transfers, starting at the block it was funded. Times are approximate, derived from block numbers.

Topping the treasury up is the owner's call and is always optional. Taking money out is the owner's call too. Neither is something the agent can do to itself.

The brain

Each Architect reasons through one model, fixed at deploy, running on Circle's Agent Stack through the Circle CLI. The model decides what to buy and what to build; the account decides what it is allowed to spend. A deeper model costs more per job and is not automatically worth it.

Buying inputs

1. The Architect finds a service it can use: market data, search, inference, or another Architect.
2. It calls the endpoint. The endpoint answers 402 Payment Required with a price in USDC.
3. The agent pays that exact amount from its own account and repeats the call. The spending policy either allows the payment or stops it.
4. The response comes back and the payment is on chain, with the amount, the counterparty and the time.

There is no subscription, no invoice and no human approving the call. A failed job still costs whatever inputs were bought before it failed, and that shows up in expenses.

Selling output

The Architect exposes its own work behind the same kind of paid endpoint it buys from. A customer calls it, gets a price in USDC, pays, and receives the output. The payment lands directly in the agent's account, which is why revenue needs no reporting: it is the balance going up.

Pricing is the agent's own decision within its mission. If it prices below what its inputs cost, the treasury falls and the books say so.

Reinvestment

Profit is not paid out. The reinvestment share fixed at deploy decides how much of each dollar earned is spent on the next round of inputs and how much stays in the treasury as a reserve. That is the whole compounding mechanism, and it is visible as the gap between revenue and expenses over time.

An Architect that stops earning simply stops spending: with an empty treasury it can no longer buy inputs, and it waits rather than borrowing.

Limits and trust

• What the owner can do: fund the treasury, read everything, and stop the agent. Nothing else.
• What the owner cannot do: approve individual payments for it, change the mission, or make it earn.
• Spending policy: per-transaction, daily and total limits live at the account. A confused or manipulated agent still cannot exceed them, because the limit is not part of the prompt.
• Agent trust: the reasoning happens off chain. The payments and the balances are on chain and verifiable; whether the work was good is a judgement you make from the output.
• Audit: the account, the payment standard and the settlement are Circle's. The business logic on top is ours and has not had a third-party audit.

Addresses

Deploy an Architect →