# How Catena works Catena is built around a few basic concepts and financial primitives. People and agents act in an organization; roles limit what people can do, and policies limit what agents can do. Intents, transactions, and records then show what happened. ## Organizations and people An organization is your customer account in Catena. It owns the accounts, counterparties, agents, and policies, and each person in it has one of three roles: | Role | Description | | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Viewer | Viewers can read everything, including balances, history, agents, and policies. Viewers cannot change settings or move money. | | Operator | Operators can do everything a viewer can, plus create agents (without assigning a policy), add counterparties, and request payment details. Operators cannot send, transfer, approve, or manage secret keys. | | Admin | Admins have full access. They can move money, approve, write and assign policies, manage the team and settings, and complete verification. | You can read more about each role in [Team and roles](https://docs.catena.com/team.md). ## Live and sandbox Each organization can have a sandbox (a separate organization that runs on test money). Agents, policies, approvals, the CLI, the MCP connection, and the SDK work the same way in the sandbox as they do in live. However, an agent connected to the sandbox is connected only to the sandbox. See [Sandbox](https://docs.catena.com/sandbox.md). ## Agents An agent in Catena is an identity, which you connect to the software that runs your agent (for example, a coding agent in a terminal or a service you deploy). Each request the software makes will carry that identity, which tells Catena which agent is asking and which policy applies. You can connect an agent in one of three ways: | Method | For | | ------------- | ------------------------------------------------------------------- | | CLI | Agents that run in a terminal | | MCP connector | Desktop and web apps | | Secret key | Cloud sandboxes, deployed services, and code you write with the SDK | See [Connect an agent](https://docs.catena.com/connect.md) for each method. ## Policies A policy is a set of rules you attach to one or more agents. It grants three capabilities, and you'll configure each one separately: | Capability | Sets | | ---------- | ---------------------------------------------------------------------------------------------------------------------------- | | View | Which accounts the agent can see. | | Transfer | Moves between your own accounts, and their limits. | | Send | Which accounts the agent sends from, its spending rules, which counterparties it can pay, and when a payment needs approval. | Each spending rule will either block an action or send it to a person for approval. An agent with no policy can identify itself, but it can't do anything else. See [Policies](https://docs.catena.com/policies.md). ## Intents Every governed action is an intent. Intents cover sends, transfers, new counterparties, requests for payment details, payments to x402 or MPP (Machine Payments Protocol) endpoints, and requests for a temporary limit increase. We check each intent against the policy and return its status. Below are the statuses an intent may have: | Status | Meaning | | ------------ | --------------------------------------------------------------------------- | | `completed` | The action succeeded. | | `pending` | The intent is waiting for a person to approve. | | `processing` | The intent has been accepted and is in progress. | | `blocked` | The policy stopped the action, or a person denied it. This status is final. | | `failed` | The action did not complete, or it expired. This status is final. | Reads, such as balances and transaction history, don't create intents. See [Intents and retries](https://docs.catena.com/intents.md). ## Approvals When a policy sends an action for approval, the action will appear under **Approvals** in the console, and we notify admins by email or Slack. An admin can then approve or deny the request. If nobody acts, the request will expire. See [Approvals](https://docs.catena.com/approvals.md). ## Approval and execution After an admin approves a payment, the payment still has to be signed and sent, and it can still fail or expire. **A payment is done when its intent reads `completed` or its transaction shows it settled.** See [Approval and execution](https://docs.catena.com/approvals.md#approval-and-execution). ## Accounts and counterparties Accounts hold your organization's money as stablecoins, on more than one chain (USDC on Base and Arc, and OUSD on Base). After your organization is verified, accounts can also receive USD and pay bank accounts by ACH and wires. See [Create and fund accounts](https://docs.catena.com/accounts.md) and [Get USD access](https://docs.catena.com/fiat-access.md). A counterparty is someone you pay, such as a vendor, a contractor, or a service. Each counterparty has one or more rails. A rail is the bank account or wallet address a payment goes to, and an agent's payment names the rail. For example, if Cora's Coffee pays its supplier Bea's Beans by wire, Bea's Beans is a counterparty and its bank account is a rail. See [Counterparties](https://docs.catena.com/counterparties.md). ## Records We record each action by a person or an agent. **Activity** in the console lists them, and the **Transactions** tab lists money movement. In addition, admins can export two CSV reports: agent money activity and operational exceptions. See [Analytics and reporting](https://docs.catena.com/reporting.md). ## Up next [Sandbox](https://docs.catena.com/sandbox.md): step 4 of 5 in Get started.