Guides

Core concepts

The vocabulary you'll use across every AgentRail surface. Read this once and the rest of the docs make sense.

Agents

An agent is a persistent, named identity that can take actions on AgentRail. Each agent has a stable identifier, a set of capabilities, and an audit trail of every decision it made and every action it took.

Agents are not users. Agents are not API keys. An agent represents the piece of software (or class of software) that's acting on its own — the carrier-payment loop, the AP reconciler, the procurement assistant. You provision one agent per persistent identity, then rotate the credentials behind it as often as you like.

Reserves accounts

A Reserves account is a programmable bank account, scoped to one agent or one organization. It holds a balance, lives across all the rails AgentRail supports, and emits events for every state change.

  • ─Reserves accounts are addressable across ACH, RTP, FedNow, wire, and card payouts.
  • ─Funds are held at our sponsor bank, with pass-through FDIC coverage subject to standard conditions.
  • ─You can open as many Reserves accounts as you need — one per agent is a common pattern.
Note
In the API, Reserves accounts are addressed as wallet — e.g. wallet_id in payload bodies, /v1/walletsfor REST. The product name is “Reserves”; the resource name is “wallet”. Same thing.

Policies

A policy is a set of rules that constrains what an agent or Reserves account can do with money. Policies are enforced at the API boundary — a call that would violate a policy fails fast with a422, before any money moves.

Common policy shapes:

  • ─Per-transaction, daily, and monthly caps.
  • ─Counterparty allow-lists and deny-lists.
  • ─Required human approval over a threshold.
  • ─Time-of-day or velocity constraints.
Note
Policies are versioned. Every change records who made it, when, and why — and you can roll back to any prior version instantly.

Counterparties

A counterparty is anyone you pay or anyone who pays you — a vendor, a customer, an employee, another agent. AgentRail keeps a normalized record of every counterparty so you can pay them by name, not by routing number.

When you create a payment to a counterparty AgentRail has never seen, we automatically screen them against sanctions lists and (if you opt in) verify their bank details before any money moves.

Events

Everything that happens on AgentRail is an event. Reserves accounts opened, payouts authorized, policies hit, agents paused — all of it flows through one append-only stream you can subscribe to via webhooks or query through the Monitoring API.

Events are immutable and tied to the agent run that produced them. That gives you a forensic timeline of every decision your agents made — useful for debugging, useful for audit, useful for trust.

The policy envelope

You'll hear us refer to the “policy envelope.” It's the conceptual boundary around an agent — the set of capabilities it declared at provisioning time, the policies attached to its Reserves accounts, and the approval rules sitting on top.

Inside the envelope, the agent acts autonomously. Outside it, the agent either fails fast or routes to a human. The envelope is the contract between “trust the agent” and “keep humans in the loop” — and you tune it per agent, per Reserves account, per counterparty.

← Back to docs indexAsk AgentRail Chat →