Automation Agents
Policy-gated software that watches every transfer, decides from real signals, and acts within hard bounds.
Transvia's automation is not a chatbot and not an improvising "AI co-pilot." It is policy-gated software: a bounded agent that watches the rail, evaluates signals, and executes a fixed set of actions — every one of them logged.
The loop
Every cycle runs the same six steps:
OBSERVE → GET DATA → CHECK POLICY → DECIDE → EXECUTE → AUDIT| Step | What happens |
|---|---|
| OBSERVE | A tick fires — on API reads/polls or via POST /api/agent/tick |
| GET DATA | Sweep active intents: timeouts, amounts, in-flight corridors |
| CHECK POLICY | Every candidate action is checked against the policy constants |
| DECIDE | A decision is formed from the signal — never from a free prompt |
| EXECUTE | Refund, hold-and-escalate, or buy an FX feed — nothing else |
| AUDIT | The decision is persisted with its signal for public inspection |
The same loop as a UML activity diagram — ● is the initial node, ◇ the
decision, ◉ the final node:
UML activity diagram — one compliance-agent tick
● start (tick fires)
│
▼
[OBSERVE] ──▶ [GET DATA] ──▶ [CHECK POLICY] ──▶ ◇ verdict?
│
┌────────────────┬──────────────────────┼─────────────┐
│ auto │ review │ blocked │
▼ ▼ ▼ │
[EXECUTE] [ESCALATE] [REJECT] │
refund · buy hold + human no fund │
FX feed · book 2-of-3 quorum movement │
fee split (COMPLIANCE_HOLD) (WATCH only) │
│ │ │ │
└────────────────┴──────────────────────┼─────────────┘
▼
[AUDIT] signal → decision persisted
│
▼
◉ endWhat the agent can actually do
Four action types, no more:
TIMEOUT_REFUND. Every transfer carries a 90-second claim window. If a
transfer is still in flight past its timeout, the agent triggers
agentFallback(TIMEOUT) on the escrow — the full amount returns to the
sender. Claimable transfers are never touched; the agent only watches them
until the recipient claims.
COMPLIANCE_HOLD. Transfers above 5,000 USDC are held and escalated to human approval (a 2-of-3 quorum). The agent cannot move funds above policy — by design, enforced in code, not by prompt.
FX_FEED_PURCHASE. While transfers are in flight, the agent buys fresh FX feed updates via x402 at $0.000001 per call — nanopayments for rate freshness. See x402.
FEE_SPLIT_BATCH. At settlement, the agent books the fee split (FX 0.35% · protocol 0.10% · automation 0.05%) as one batched, gasless settlement action.
Bounded by construction
- Hard-coded policy. Thresholds live in one policy module — the 5,000 USDC compliance limit, the 90-second claim window, the 0.000001 FX feed cost. Tune policy, not prompts.
- Deduplicated. One action of each kind per intent — no feed spam.
- Fail-safe. Agent failures never break the settlement feed, and a reentrancy guard stops overlapping ticks.
- Non-custodial reach. The agent can only refund pre-settlement intents to the original sender. It can never redirect a payout — the recipient is fixed at deposit, onchain.
The audit trail
Every decision is written to the agent action log with its signal, its decision, and (when applicable) its x402 cost:
curl -s https://transvia.xyz/api/agent/actions{
"actions": [
{
"id": "act_…",
"kind": "COMPLIANCE_HOLD",
"intentId": "int_…",
"signal": "amount 7500 USDC > policy limit 5000",
"decision": "Raised a Privy intent for async human approval (2-of-3 key quorum). Agent cannot move funds above policy — by design.",
"x402Cost": null,
"createdAt": "2026-01-15T12:03:40.000Z"
}
]
}The same log powers the automation surfaces in the product. See Automation for the consumer view, Policies for the rules engine, and API for the endpoint.