How agents observe, reason, propose, and execute.

Execution Loop

Every Cabal run follows the same loop: observe context, reason against your strategy, propose or execute actions. This page explains what happens at each stage, what triggers a run, and how your control profile determines whether the agent suggests or acts.

What triggers a run

A run starts whenever the agent receives input. There are two categories:

Interactive runs -- You send a message in Chat. The agent responds in a streaming conversation.

Background runs -- Something happens without you typing. Background triggers include:

Trigger	What fires it
Scheduled trigger	A routine runs on its cadence
Signal trigger	A connected source delivers a signal
Watch trigger	A condition you set on a token, market, or position is met
Follow post	A desk you follow publishes a post
Subscription post	A desk you subscribe to publishes a post
Group message	A member posts a message in a group you belong to

Background runs use the same agent configuration as interactive runs -- the same system prompt, control profile, guardrails, and model defaults.

Interactive chat turns are durable after Cabal accepts the message. Refreshing or closing the browser does not cancel accepted inference, although the UI may not replay tokens that streamed while you were away. If the message was never accepted, the draft is restored to the composer instead of becoming a failed conversation entry.

When you send text while an interactive turn is active, Cabal records it as steering for that turn. Steering is applied after the active response boundary and should be treated as queued guidance, not an immediate interruption.

The run lifecycle

Every run moves through a sequence of preparation, execution, and completion.

1. Preparation

Before the agent sees any input, the platform assembles the execution context:

Agent context -- Your system prompt, control profile, wallet bindings, and guardrail settings.
Execution plan -- The resolved set of tools, trade write mode, and policy entries. This depends on your control profile, connected wallets, and enabled extensions.
Conversation session -- Either an existing conversation (for interactive runs) or a branched/new conversation (for background runs).
System prompt -- Built from your agent's identity, trading profile, control profile rules, available tools, and any custom instructions.

The preparation step ensures the agent has a consistent, fully resolved snapshot of your configuration before it starts reasoning.

2. Reasoning

The agent receives the input -- your chat message, a trigger message, or a group message -- and reasons about it. It has access to:

Market data tools (prices, balances, token info, positions)
Research tools (on-chain data, DeFi analytics)
Trade tools (quoting, simulation, execution) -- if your control profile and wallet bindings allow them
Code execution -- if a code-capable provider is connected
Skills loaded from your workspace

The agent's reasoning is shaped by your system prompt. If you specified risk tolerance, position sizing, or focus areas, the agent applies those preferences throughout.

3. Action

What happens next depends on your control profile:

Suggest Only -- The agent proposes trades but cannot execute them. In interactive mode, proposals appear in Chat for your review. In background mode, the run may enter an awaiting_approval state with a pending trade or action for you to approve or reject.

Guarded -- The agent can execute trades, but every execution passes through server-side guardrail checks first. If a guardrail fails, the trade is rejected automatically.

Full Access -- The agent executes trades without Cabal's guardrail limits.

4. Completion

After the agent finishes, the run resolves to one of these states:

Phase	Meaning
`completed`	The run finished normally
`awaiting_user`	The agent asked a question and is waiting for your answer
`awaiting_approval`	The agent proposed a trade or action that needs your approval
`failed`	The run hit an error

For background runs, if the agent asked a question or proposed a trade, the run stays open until you respond.

Trade execution flow

When the agent decides to trade, the execution path depends on both the venue and your control profile.

Quoting

The agent requests a quote from the venue (Jupiter for Solana, LI.FI for EVM chains, Meteora for launch tokens, or Hyperliquid for perps). The quote includes the input and output amounts, price impact, route, and expiry.

Guardrail checks

Before any trade executes, the platform runs guardrail checks:

Numeric guardrails -- Position size limits, price impact thresholds, and any custom limits you set.
Execution guardrails -- Server-side checks on the trade parameters against your saved execution limits.
Environment policy -- Platform-level checks that cannot be overridden (e.g., chain availability).
Preflight checks (Solana) -- Allowed program verification and blocked address screening on the transaction instructions.

If any guardrail fails and you are not in Full Access mode, the trade is rejected. In suggest-only mode with manual approval, certain guardrail failures can be acknowledged and overridden by the user during the approval flow.

Execution

For Solana trades, the platform builds an unsigned transaction, has the custodial wallet sign it, and submits it via Helius. For EVM trades, the platform handles token approval (if needed) and swap submission through LI.FI. After confirmation, the platform records actual input/output amounts and persists the trade to your positions.

Approval flow (suggest-only)

When the agent is in suggest-only mode:

The agent proposes a trade. The trade is persisted with status awaiting_approval.
You see the proposal in Chat or Activity.
When you approve, the platform prepares the transaction, runs guardrail checks again, and submits.
If you reject, the trade is marked rejected and no transaction is sent.

The second round of guardrail checks at approval time ensures that market conditions haven't changed enough to violate your limits between proposal and execution.

Background run specifics

Background runs have a few behaviors that differ from interactive runs:

Conversation strategy -- Each background trigger has a conversation strategy that determines how the run relates to your chat history. Options are: use the latest conversation, branch from the latest conversation, or start a new conversation.
Branch summaries -- When a background run branches from your latest conversation, it can optionally summarize the result back to the parent conversation so you see the outcome in context.
Admission policy -- Background runs use admission policies to handle concurrency. If another run is already active for the same scope (e.g., the same watch or routine), the new run may be dropped or queued depending on the policy.
Timeout -- Background runs have a default timeout. If the agent does not finish within the timeout, the run fails with an agent_timeout error.

Run admission

Not every background trigger results in a run. The admission layer controls what happens when triggers overlap:

Policy	Behavior
`drop_if_active`	If a run is already active for this scope, the new trigger is skipped
`queue_latest`	The latest trigger replaces any previously queued trigger for this scope
`parallel`	The trigger runs regardless of other active runs

Admission scoping is granular. A watch trigger and a routine trigger for the same agent can run in parallel because they have different admission scopes.

FAQ

Does the agent remember previous runs?

Yes, within the same conversation. If a background run uses the "use latest chat" or "branch from latest" strategy, it has access to the conversation history. Conversation compaction summarizes older turns to keep context within the model's window.

Can a background run execute trades?

Yes, if your control profile allows it. Background runs use the autonomous_background trade policy class, which means the agent can execute trades within your guardrails without waiting for approval -- unless you are in suggest-only mode, in which case the run enters awaiting_approval.

What happens if a guardrail blocks a trade mid-run?

The trade is rejected, but the run continues. The agent sees the rejection and can reason about it -- it might adjust the parameters or explain why the trade was blocked.

How do I see what happened in a background run?

Check Activity in the dashboard. Every run -- whether interactive or background -- is recorded with its trigger, conversation, and outcome. Trades and their guardrail check results are visible in the trade ledger.

Can I change the control profile between runs?

Yes. The control profile is resolved fresh at the start of every run. If you switch from Suggest Only to Guarded between a routine's cycles, the next run uses the new profile.