> ## Documentation Index
> Fetch the complete documentation index at: https://conto.finance/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# How Conto works

> Who sets the rules, how organizations, agents, wallets, and policies relate, and which payment records Conto keeps.

Three questions define a setup: who can spend, which wallet they can use, and which controls must
pass. The agent owner or budget holder owns that configuration through their organization. The
agent uses its own SDK key.

## Who does what

The owner can be a person, a team, or a business that runs agents for its customers. A platform
that integrates Conto for its customers keeps each customer's policies in its own workspace.

| Who | What they do |
| - | - |
| You | Set budgets, allowed recipients, which wallets or cards each agent can use, and who approves. |
| Your agent | Asks Conto before it pays, with the amount, currency, recipient, and purpose. It uses its own SDK key. |
| Conto | Checks the agent's policies and limits, then approves, holds for review, or denies. Records every result. |
| Approver | A person you choose. Approves or denies held payments, within the limits you set. |
| Signer | The code that signs the payment or uses the card. It waits for Conto's approval, then reports what happened. |
| Merchant or recipient | Sends the price and payment details, takes the payment, and delivers. |

A merchant's invoice or checkout page cannot approve the payment or change your policies.

## Resource relationships

```mermaid theme={null}
flowchart TD
  Org[Buyer organization / budget holder] --> Agent[Agent]
  Org --> Wallet[Wallet]
  Org --> Policy[Policies]
  Agent --> Access[Agent-wallet access and limits]
  Wallet --> Access
  Policy --> Decision[Payment decision]
  Access --> Decision
  Intent[Payment request] --> Decision
  Decision --> Review[Approval request when review is needed]
  Decision --> Tx[Transaction when execution starts]
```

| Resource | What it represents | What your application retains |
| - | - | - |
| Organization | The buyer workspace that owns resources and spending authority | Organization context for provisioning |
| Agent | A runtime identity with its own keys and status | Agent ID. Its SDK key stays in a secret store |
| Wallet | A stablecoin address and its signing/control model | Wallet ID, address, chain, and currency |
| Agent-wallet link | Permission to use a particular wallet, with limits and time windows | The assigned wallet ID and its limits |
| Policy | Rules applied at organization, agent, or wallet scope | Policy assignment and configuration for the use case |
| Counterparty | A recipient and the organization's relationship with it | Address, chain context, and review/approval decisions |

One wallet can serve multiple agents with different limits. An agent can have multiple wallets.
Use `walletId` when the payment must use a particular wallet or chain. A key authenticates the
agent. Wallet access and policy evaluation constrain its payments.

Each agent has an environment: `DEV` (the default), `STAGING`, or `PROD`. Only `PROD` agents can pay
from mainnet wallets.

## Three records, three purposes

A **payment request** is the intent and authorization decision. An **approval request** is the
human review record when a workflow needs a decision. A **transaction** records execution and
settlement progress. These IDs are not interchangeable.

For example, a research agent requests 12 pathUSD. Its policy requires review above 10 and denies
above 15. The payment request waits for review. An authorized human decides, and the application checks
the original payment request. Execution creates a transaction, which may still be processing.
The application waits for completion before treating the purchase as paid.

See [the payment lifecycle](/docs/guides/payment-lifecycle) for status values and recovery steps.

## Where controls apply

Organization policies apply to every agent in the organization. Assigned policies apply to one agent
or wallet. All applicable controls must pass. A high-priority allow does not override a denial.
Priority determines evaluation order.

Wallet limits are another layer. A policy that permits 50 does not override a wallet cap of 20.
A wallet limit of `0` blocks all payments through that link, and `null` removes the cap. Omitted
limits get defaults. See [Defaults](/docs/reference/defaults#agent-wallet-links) before changing caps.

[Test allow, review, and deny](/docs/guides/policy-testing) to see these rules together.

## Who signs

The code that signs must get a Conto approval before it signs or uses credentials. Do not give the
model unrestricted payment keys and rely on it to follow the rules. A changed amount, recipient,
currency, or material purchase detail needs a fresh check.

* **Managed wallets** use request, then execute. Conto signs after your controls pass.
* **External wallets** use approve, your own transfer, then confirm. Your agent signs, and Conto
  cannot block a transfer sent outside its flow. See [wallet custody](/docs/guides/custody-modes).
* **x402 and MPP** clients call pre-authorization before they sign a payment or fund a session. An
  approved grant reserves the amount against your limits for 10 minutes. The client still signs
  and pays.
* **Connected cards** (Builder and Enterprise): Conto releases a single-use, merchant-locked,
  amount-capped credential only after policy, limits, and the purchase authorization the
  cardholder verified all allow the purchase. The agent never sees the underlying card. Cards have
  their own spending controls, separate from wallet limits. See
  [connected cards](/docs/guides/connected-cards).

## Three testing terms

* **Anonymous sandbox:** simulated settlement, no signer or funded wallet needed.
* **Testnet:** actual blockchain transactions using test tokens.
* **Mainnet:** actual blockchain transactions using real funds.

A receipt with `settlementMode: "live"` identifies an onchain transfer and can still be a testnet
transfer. Verify its chain as well as its status. Check [flows and prerequisites](/docs/guides/choose-your-integration).

## Next steps

[Run the quickstart](/docs/quickstart/setup), [choose an integration](/docs/guides/choose-your-integration),
or read [API conventions](/docs/reference/api-conventions) for units and identifiers.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.