A Healthy Oracle Sample Shouldn’t Automatically Resume an AI Agent

A long-running AI agent checks oracle conditions and receives a halt recommendation. Its strategy pauses.

The next sample looks healthy. Should the agent immediately resume?

I would treat recovery as a separate decision. A single healthy response does not establish that an incident has ended, and a process restart should not erase the pause.

Here is how I approach that boundary with Insight Oracle Watch.

Keep the halt across restarts

Oracle Watch can retain states such as halted, recovering, and monitor_unavailable through a stateAdapter.

The adapter must use storage appropriate for your deployment. An in-memory map will lose its state on restart; multiple workers need a shared, coordinated store.

This example accepts the store and application actions as dependencies:

import {
  InsightGuard,
  type OracleWatchTarget,
  type WatchStateAdapter,
} from 'oracle-insight-guard';

const target: OracleWatchTarget = {
  symbol: 'ETH',
  chain: 'ethereum',
};

export function startGuardedWatch(
  guard: InsightGuard,
  stateAdapter: WatchStateAdapter,
  pauseNewActions: (reason: string) => Promise<void>,
  notifyOperator: (message: string) => Promise<void>,
) {
  return guard.watch(target, {
    stopOnHalt: false,
    recoveryHealthySamples: 2,
    stateAdapter,

    onHalt: async (signal) => {
      await pauseNewActions(`Oracle Watch: ${signal.reason}`);
    },

    onIncident: async (state) => {
      await pauseNewActions(`Watch incident: ${state.incidentKind}`);
      await notifyOperator(`Watch incident: ${state.incidentId}`);
    },

    onRecoveryReady: async () => {
      await notifyOperator('Fresh samples are ready for review');
    },
  });
}

export function assertCanStartNewAction(
  guard: InsightGuard,
): void {
  if (guard.isHalted(target)) {
    throw new Error('Oracle Watch requires operator review');
  }
}

Connect pauseNewActions to your strategy controller. Call assertCanStartNewAction() at the application’s execution boundary. If you use the Guard’s swap execution flow, pass the same watchTarget so its Watch halt is applied there too.

Callbacks provide notifications and application behavior. The execution boundary must still check the halt state.

Recovery has two steps

With stopOnHalt: false, Watch continues collecting signals after a halt.

In this example, two consecutive fresh healthy samples make recovery ready for review. They do not clear the execution halt.

After the operator reviews the incident and current conditions, the application can call:

await watch.acknowledgeRecovery();

Here watch is the handle returned by startGuardedWatch(). Acknowledgement clears the Watch halt when its recovery conditions are satisfied. It does not call a wallet, submit a trade, or resume your strategy on its own.

The application must make its own subsequent execution decision, including any current pre-trade assessment and authorization requirements.

Treat monitoring availability as a state

A failed Watch request, exhausted API budget, or storage failure also matters to a running strategy.

Preserve the incident reason and make monitoring availability visible. The SDK retains a local halt when durable state cannot be saved. Your execution path should check its gate instead of assuming that missing monitoring means healthy conditions.

Oracle Watch’s default cadence is 15 minutes, matching Insight’s published snapshot cadence. It provides scheduled monitoring, not second-by-second market observation.

The design question

A useful state machine separates:

• Halted: a signal or monitoring incident stopped new actions.
• Recovering: fresh healthy samples have arrived; the halt remains active.
• Acknowledged: recovery conditions were reviewed and the Watch halt was explicitly cleared.

For an automated strategy, what evidence should be required before a halted agent can take its next action?

References

• Insight SDK: watching a running strategy
• Durable Watch incidents
• Insight