Actions and context

An action describes what the agent wants to do. Its type is a stable operation name; attributes contains the operation’s parameters.

{
  "type": "refund.create",
  "attributes": {
    "amount_minor": 8000,
    "currency": "GBP",
    "customer_id": "cus_123"
  }
}

This represents £80 in minor units. Use the same unit in the policy, application, and provider adapter. For counts and monetary sums, use exact integer values.

Supply trusted business facts

The separate context object carries facts needed to decide authority, such as a customer’s account status or a resource classification.

{
  "customer": {
    "fraud_flagged": false,
    "tier": "standard"
  }
}

Populate authority-relevant facts from trusted sources. Do not let an agent assert its own permissions, customer risk status, or allowed spending limit. Send only the data required for the control and investigation; avoid credentials and unnecessary personal data.

Keep field names and types stable. A policy written for a number should not receive a numeric string, and a policy written for action.attributes.amount_minor should not silently receive a different field.

Identity, retries, and counters

The connection key establishes the agent and workspace. Bind the SDK to the agent ID in setup. With HTTP, the decision endpoint can infer the agent from the key; if supplied, the ID must match that connection.

One logical action keeps the same request body, mode, and idempotency key across retries. Changing its input is a different request.

Actera supplies managed counter values during real evaluation. Your application provides the grouping and contribution fields the counter needs, such as customer ID and amount; it does not supply an authoritative balance.