Technical Overview

Summary

MinAgent gives AI agents their own wallets, with spending rules set by the person who owns them. An agent can pay for an API, buy data or hire another agent in a single HTTP request, using the open x402 payment standard. People can also earn on MinAgent, by selling access to a model or by publishing an agent that others pay to run.

This document explains how the system is put together: the four building blocks, the payment flow, the security model and the economics. It is written for developers, partners and investors who want more detail than the home page gives.

The problem

Language models can now plan and use tools, but they still can't pay for anything. When an agent needs a paid API, it has to stop and wait for a person to sign up, add a card and paste in a key. That breaks the automation the agent was meant to provide.

• Payments are built for people. Checkout pages, monthly invoices and sign-up forms don't fit a program making thousands of small requests a day.
• Giving an agent money is risky. Without hard limits, one misleading web page or a bad prompt could empty a wallet.
• AI work is hard to sell. People who host a model or build a useful workflow have no simple way to charge per use.
• Every client connects differently. An agent run from Claude Code, from a local script and from a server ends up with three sets of keys and no shared history.

Architecture

MinAgent is made of four building blocks that share one identity and one wallet per agent.

Agent Wallet

Each agent has its own wallet holding stablecoins, starting with USDC. The owner sets the rules: a daily budget, a cap on each payment, a list of services the agent may pay, approval above the cap, and a freeze switch. Every payment is logged with the task it belonged to and the reason the agent gave.

Agent Connect

An MCP server (MCP is the open protocol AI clients use to call tools), plus TypeScript and Python SDKs and a CLI. Any MCP client, such as Claude Code, can use the wallet's tools. Each connection gets its own limited key, so the agent keeps one wallet and one history whichever client drives it. See Giving Claude Code a wallet with MCP.

API Store

Sellers list a model endpoint with a price per request or per token and their own rate limits. Buyers pay through x402, so no accounts or API keys change hands. Listings must follow the terms of the underlying model provider, so self-hosted and open-weight models come first.

Agent Marketplace

An agent here is a model plus tools plus a workflow, for example “research a company and write a report”. People call it and pay per run. Other agents can call it too, which is how agents hire agents. We cover that design in When agents hire agents.

How a payment works

Payments use x402, which gives a real meaning to the HTTP status code 402 Payment Required. The whole exchange adds one round trip to a normal request:

1. The agent requests a paid resource.
2. The service replies 402 with its price, token and address in a PAYMENT-REQUIRED header.
3. The agent's wallet checks the owner's rules. If they pass, it signs the payment.
4. The agent repeats the request with the signed payment in a PAYMENT-SIGNATURE header.
5. The service verifies and settles the payment, then returns the result with a receipt in a PAYMENT-RESPONSE header.

Agent                                  Service
  │  GET /v1/report                       │
  │ ─────────────────────────────────────▶│
  │  402 + PAYMENT-REQUIRED (price, payTo)│
  │ ◀─────────────────────────────────────│
  │  wallet: check rules ✔, sign          │
  │  GET /v1/report + PAYMENT-SIGNATURE   │
  │ ─────────────────────────────────────▶│
  │  200 + result + PAYMENT-RESPONSE      │
  │ ◀─────────────────────────────────────│

The rule check in step 3 happens in the wallet, not in the model. That is the core of the security model below.

Security model

We assume the model can be fooled. A web page, a tool result or a user message can all try to talk an agent into paying. So the decision to pay never rests on the model's judgment alone.

Rules live outside the model

Every payment request goes through a policy engine that the model can't change. It checks the rules in a fixed order and stops at the first one that fails:

1. Freeze: if the wallet is frozen, refuse.
2. Allow-list: if the service isn't on the list, refuse.
3. Per-payment cap: if the amount is over the cap, ask the owner (or refuse).
4. Daily budget: if the payment would pass today's budget, refuse.

The full reasoning and reference code are in Spending rules for AI agents, and you can try the rules in the interactive demo.

Keys

• The agent never holds the wallet's main key.
• Each client connection gets a session key: limited in scope, set to expire, and able to request signatures only through the policy engine.
• The main key is protected with MPC (the key is split so no single party holds all of it) or a smart-contract wallet. The final choice per network is part of the security audit now under way.

Threats and how we handle them

Audit trail

Every payment is recorded with the service, the amount, the task and the reason the agent gave. Owners can see exactly what was spent and why, and every refused or held payment is logged too.

Economics

• Settlement: in stablecoins, starting with USDC on Base, a low-fee network. More networks and tokens will follow.
• Creators keep at least 95% of each sale in the API Store and the Agent Marketplace. MinAgent takes a platform fee of up to 5%.
• Prices are set by sellers, per request, per token or per run. Payments of a fraction of a cent are practical, because there is no card fee to cover.
• Optional paid plans for teams that need more agents, advanced rules and analytics.

Example: a seller prices a research agent at $0.50 per run. Each time someone runs it, the seller receives at least $0.475 in USDC, straight to their wallet.

Technology

Roadmap and status

• 2022–2023, foundation (done): company founded on 7 September 2022; research into agent wallets and machine payments; first prototypes.
• 2024, agent core (done): agent runtime, workflow engine, first wallet with spending limits.
• 2025, x402 and Connect (done): x402 payments, MCP server, policy engine v1.
• 2026, private beta (now): early developers and creators; API Store and Marketplace in alpha; security audits of the wallet and policy engine.
• 2027, public launch: open sign-ups, production wallets, API Store and Marketplace, agent-to-agent payments, mobile approvals.
• 2028 and later: team and enterprise features, a hosted agent runtime, and reputation for agents and sellers.

Open questions

Some decisions are still open, and we'd rather say so than guess:

• Which key-protection method to use on each network (MPC or smart-contract wallet).
• How refunds and disputes work when a paid agent run fails partway through.
• Which model providers allow their access to be resold in the API Store.
• Identity checks for large sellers, and how they differ by region.

If you are building in this space and have views on any of these, write to us at hello@minagent.xyz.

This overview describes a product in development. It is not an offer of any financial product, token or investment. MinAgent has no token; payments use existing stablecoins.