Guardrails and lifecycle

Agents touch funds, so the limits around them are not an afterthought, they are the core of the design. This page describes the guardrails on every agent and the lifecycle that lets you arm and revoke one with confidence.

The guardrails

Every agent action is wrapped by limits you define. An agent cannot act outside them.

Per-trade cap. The most an agent can move in a single action. In the example agent this is 500 dollars per trade.

Daily cap. A ceiling on total activity over a day, so a noisy condition cannot turn into a run of actions.

Token allowlist. The set of assets an agent is allowed to touch. Anything not on the list is off limits, which keeps an agent from interacting with tokens you never intended.

Slippage ceiling. The maximum price slippage an action may accept, for example 1.0 percent. If filling the action would exceed it, the action does not go through.

Expiry. A hard end time, for example 24 hours, after which the agent stops on its own. Authority is granted for a window, not forever.

Kill switch. A control that revokes the agent instantly. If you want it to stop, it stops, immediately, regardless of its triggers or expiry.

Why this set

Each limit closes a different failure mode. The per-trade and daily caps bound size. The allowlist bounds scope. The slippage ceiling bounds execution quality. The expiry bounds time. The kill switch bounds everything, on demand. Together they mean the worst case for an agent is defined in advance and small by construction.

Lifecycle

  1. Define. You set the trigger, the action, and every limit above.
  2. Arm. You enable the agent, with auto-execute on if you want it to act without a prompt. This is when a connected wallet matters, because the agent needs an address to act from.
  3. Watch. The agent monitors the signal and acts only when the trigger fires and the action fits inside the limits.
  4. Expire or revoke. The agent ends at its expiry, or instantly when you hit the kill switch.

A way to build trust

A sensible path is to run a condition as an alert first, watch it behave a few times, then promote it to an agent with conservative caps and a short expiry. You can widen the limits later, once the behavior matches what you expected. The point of the guardrails is that you never have to extend more trust than you are ready to.

Status

The create-agent flow, including these guardrails, is in active development. See the Roadmap for current status. Agents act on funds, and you are responsible for the limits you set. See Security and disclaimers.

results matching ""

    No results matching ""