Skip to main content
Agents are created by developers using Natural to enable autonomous Payments workflows. Developers can use agents to request payment authority from their customers, represented by another Party. Developers can also use their own Party to send payments on behalf of themselves. A developer can register multiple agents on Natural, each of which can execute on behalf of multiple parties on Natural. Each agent and agent-party pair can have granular permissions, limits, and escalations, all managed through an Agent Delegation requested by the developer to the party. Developers and their customers can subsequently update or revoke any Agent Delegation via the Dashboard or by API.

​
Agent delegation model

Alice (Developer) proposes an Agent Delegation to Bruce (Business) with specific permissions and limits. Bruce reviews and approves the Agent Delegation: 
1. Alice (Developer)
   └─ Creates Agent (Carrier Payment Agent)
   └─ Proposes Agent Delegation to Bruce
       └─ Permissions: [payments.create, payments.read]
       └─ Limits: $1000 per payment, $5000 daily

2. Bruce (Business)
   └─ Approves Agent Delegation

3. Alice (Developer)
   └─ Uses Agent to pay Terri (Contractor) on behalf of Bruce
Delegations can include the following permissions:
  • payments.create - Create payments
  • payments.read - Read payment status
  • wallets.read - Check wallet balance
  • party.read - View party information
Agents operate within configurable limits:
  • Per-transaction limit - Maximum amount per payment
  • Daily limit - Maximum total per day
  • Weekly limit - Maximum total per week
When an agent attempts to exceed limits, the transaction is blocked and escalations are triggered. Escalations can be configured via SMS or email through the Dashboard. Developers do not need to store information around permissions, limits, and escalations.

​
Agent authentication

Agents authenticate via our SDKs using API keys that the developer owns, allowing Natural to verify the agent has permission to act on behalf of the business party. For maximum transaction observability, developers are recommended to pass in an instance_id when making executions on Natural.

​
Agent instances

An instance_id is an identifier that groups related agent executions together. In other common frameworks like LangGraph or OpenAI Assistant API, this is represented by a thread_id. While Natural tracks every payment individually, an instance_id allows developers to correlate multiple actions belonging to the same logical workflow. For example, if your agent processes a multi-step payment execution (outbound contractors → negotiate rates → send multiple payment), you can tag all actions with the same instance_id to view them as a single workflow in the audit trail. Instances are developer-controlled. Developers should pass instance_id as an idempotent string to Natural that helps group their agent executions together.

​
Audit trail

All agent actions are logged and auditable, with clear grouping by requests and instances. These will include intents such as tool calls as well as internal execution mechanics such as limits being hit or escalations having been triggered. Developers can review agent activity to ensure compliance and detect anomalies.
  • Parties - Party identities that agents operate on behalf of
  • Users - Users who create and manage agents
  • Payments - Payment transactions executed by agents