If an Agent Goes Off-Script#
If an agent action is blocked, that usually means the control system is working as intended.
Hightop agents do not get open-ended power. They operate inside a ruleset enforced onchain by open-source, verifiable smart contracts. When an action falls outside that ruleset, it is blocked before funds move — not by app logic alone, but by the same onchain control layer.
This page explains the most common reasons an action is blocked and what to do next.
Quick example: Your research agent tried to pay a new data provider $200 and was blocked. Why? The provider is not in the agent's approved recurring vendor list. Fix: add the provider as a recurring vendor with the right limits, or use a one-off payment instead.
How to Think About a Blocked Action#
Start with three questions:
- What was the agent trying to do?
- Which path was it using?
- Which rule did it hit?
Almost every blocked action comes down to one of a handful of causes.
That framing matches the control layer itself: the account, the agent, and the specific action path can each block execution before funds move.
Common Reasons an Action Gets Blocked#
The agent is not active#
Example: Your operations agent's 90-day expiry passed and it stopped making payments to your compute providers.
What happened:
- the agent was never activated
- the agent expired
- the agent was removed or revoked
What to do:
- confirm the agent is active
- check whether it expired
- recreate or replace it if needed
The agent lacks permission#
What happened:
- the agent tried to perform an action it is not allowed to perform
Examples:
- sending a payment without payment permission
- creating a one-off payment without one-off payment permission
- using trusted transfers without trusted-transfer permission
What to do:
- review the agent's permissions
- add the missing permission only if the agent truly needs it
The action exceeded a limit#
Example: Your research agent tried a $600 payment, but it has a $500 per-transaction cap.
What happened:
- the amount was above the per-transaction cap
- the daily, weekly, or monthly budget was already used
- the lifetime cap was reached
What to do:
- reduce the amount
- check the account-wide rule, the agent rule, and the payment-path rule if one applies
- wait for the period reset
- widen the limit if appropriate
The cooldown has not elapsed#
Example: Your agent paid a compute vendor 30 minutes ago, but has a 1-hour cooldown between payments.
What happened:
- the agent is allowed to act, but not yet
What to do:
- wait until the cooldown expires
- reduce or remove the cooldown only if that matches your risk tolerance
The asset or venue is not allowed#
What happened:
- the agent tried to use an asset outside its approved set
- the agent tried to use a venue or market it is not allowed to touch
What to do:
- use an approved asset or venue
- expand the allowed set only if you want that capability
The recipient is not approved for the chosen payment path#
What happened:
- the agent tried to send a recurring payment to an unapproved vendor
- the destination is not configured for the selected payment type
What to do:
- add the destination to Recurring Payments if this is an ongoing relationship
- use One-Off Payments if the payout is ad hoc
- use Trusted Transfers only if the destination is one of your own highest-trust addresses
The one-off payment is not ready#
What happened:
- a review delay has not elapsed yet
- the one-off payment expired
- the payment was cancelled
These are enforced states, not just UI labels.
What to do:
- wait for the review window to end
- create a new one-off payment if needed
- verify that the payment still exists and is valid
The trusted destination is not configured#
What happened:
- the destination is not approved for Trusted Transfers
- it may still be in a pending state
Pending and active are enforced states, not just labels in the app.
What to do:
- verify the destination is configured correctly
- wait for activation if a delay applies
- do not use this path for ordinary vendors or casual recipients
A safety check blocked the action#
What happened:
- a protective check blocked execution
Examples:
- invalid amount
- unsupported asset state
- pricing or safety validation failure
- another protective boundary being hit
What to do:
- inspect the exact action request
- verify the asset, amount, and venue
- retry only after understanding which rule failed
A Quick Debugging Flow#
When an action is blocked, work through this sequence:
- Identify the action category: pay, get paid, earn, borrow, convert, or transfer.
- Identify the specific path: recurring payment, one-off payment, trusted transfer, or another action type.
- Check whether the agent is active and has the right permission.
- Check the three rule layers: account-wide rules, agent-specific rules, and path-specific rules.
- Check the relevant limits, cooldowns, allowed assets, allowed venues, and recipient configuration.
This usually reveals the problem quickly.
These checks mirror the actual enforcement layers Hightop evaluates when the action is attempted.
Why This Is a Feature, Not a Failure#
When an agent goes off-script, the goal is not to "let it through anyway." The goal is to stop the action before funds move.
That is what makes the control model trustworthy. The rules are enforced by the onchain control layer and can be verified in open-source contracts.
Where to Go Next#
- Read AI Agents to understand the agent model.
- Read Agent Permissions and Limits to understand the rules layer.
- Read Recurring Payments, One-Off Payments, or Trusted Transfers for the specific payment path involved.