Announce-then-execute: a pattern for human-in-the-loop autonomy

Most autonomous systems are silent. They make decisions, they execute them, and the operator finds out after the fact — usually by reading a log, usually because something went wrong. The trade-off this design makes is the wrong one. Silence costs more than people think and saves almost nothing.

The pattern I want to argue for is announce-then-execute. The system is fully autonomous — it makes decisions on its own schedule, without human input — but before acting, it posts a structured announcement to a channel the operator monitors and waits a configurable interval for an override signal. After the interval expires, execution proceeds. If an override arrives in time, the action is cancelled and logged. Either way, the announcement persists as a record.

I run this pattern in Cerberus Markets, the Kraken-backed crypto trading harness I’m building, where every real-capital trade gets announced to Discord with a 60-second cancel window. But the pattern generalizes. It’s not specific to trading and it’s not specific to Discord. This post is the general argument.

What the pattern looks like

The implementation is small. Pseudocode:

def execute_with_announcement(intent):
    announce_to_channel(intent)
    started_at = now()
    while (now() - started_at) < CANCEL_WINDOW_SECONDS:
        if check_for_cancel_signal(intent.id):
            log_cancelled(intent)
            return
        sleep(POLL_INTERVAL_SECONDS)
    execute(intent)
    log_executed(intent)

Three configurable parameters: where to announce (a Discord channel, a Slack channel, an SMS gateway — the medium doesn’t matter), how long the cancel window stays open, and what counts as a cancel signal (a button click, a reply with a keyword, a webhook from another system).

The announcement payload should be structured. Free-text “I’m about to do something” announcements are noise. A useful announcement names the action concretely: what entity is being affected, what change is being applied, when execution will proceed, how to cancel. For a trade, that’s pair / direction / quantity / entry price / strategy name / cancel button. For a deployment, that’s target environment / commit SHA / changed files / cancel command. The shape of the payload follows the shape of the action.

What the pattern buys you

Observability that compounds. Every announcement persists as a record, whether or not it gets cancelled. After a month of operation, you have a complete log of what the autonomous system intended to do, in order, with timestamps. This is usable for retroactive analysis in ways that an “executed actions” log isn’t — because the announcement captures intent, while the executed-action log only captures outcomes. The difference matters when you’re debugging a system whose intent was right but whose execution was blocked by an unexpected condition.

Override capability without dashboard complexity. The classic alternative to autonomous systems is a dashboard with an approval queue: actions land in a queue, an operator reviews each one, the operator clicks approve, the action proceeds. This works but it’s tedious and it bottlenecks throughput on operator attention. Announce-then-execute flips the default — the action proceeds unless an operator cancels — which keeps the system effectively autonomous while preserving an override path. The dashboard isn’t the bottleneck; attention to the channel is, and only when something looks wrong.

A debugging surface for the operator’s intuition. Operators notice patterns that the system doesn’t have rules for. A trader will notice “this strategy is firing every time crypto Twitter posts the same meme” before the system has a feature for memes-as-input. A deploy operator will notice “this deploy is going out right before the quarterly close, which we said we wouldn’t do” before the deploy system has a calendar awareness feature. Announcements expose the system’s intent to the operator’s pattern-matching, which is the only mechanism available for catching the classes of problems the system isn’t aware of yet.

Failure mode insurance. Every autonomous system has at least one failure mode where the system thinks it should act but actually shouldn’t. The cost of those failure modes varies — in trading, a wrong action costs money; in deploys, a wrong action takes a service down; in healthcare, a wrong action can be much worse. Announce-then-execute caps that cost at “the operator can press the cancel button before execution proceeds,” which is often the difference between a near-miss and an incident.

What the pattern costs

The honest costs:

Latency on every action. The cancel window is a fixed cost on every action. For my trading system, 60 seconds is the right tradeoff — crypto markets move slowly enough that an extra minute of slippage exposure rarely changes the outcome materially, and the override value is high. For systems where milliseconds matter, the pattern doesn’t apply directly. For systems where actions are infrequent (a deploy every few days, a trade every few hours), the latency cost is invisible.

Attention demand on the operator. Announcements are only useful if someone reads them. A channel that nobody monitors is the worst of both worlds — you have the latency cost without the override benefit. The pattern requires operator buy-in: someone has to subscribe to notifications, treat them as actionable, and respond when needed. This is a real organizational cost, not just a technical one.

Cancellation correctness. The cancel mechanism has to work. If a cancel signal arrives mid-execution and the system can’t actually stop the action — because the action has already been committed to an external system, or because the cancel signal got lost in a queue — you’ve created an illusion of override that doesn’t exist. The cancel path has to be tested with the same rigor as the execute path.

Discoverability and training. New operators need to know the cancel exists and how to use it. The cancel mechanism should be one tap from a phone notification, not a workflow that requires opening a dashboard, finding the action, and clicking through three confirmations.

Where the pattern works best

The pattern earns its keep when three conditions hold:

The actions are individually consequential. If every action is small and reversible, the override value is low and the latency cost isn’t worth it. If actions are large or irreversible, override value is high.

Actions are infrequent enough that an operator can plausibly review them. Hundreds of actions per minute drowns the channel; tens per day is comfortable. The right cadence depends on the channel and the operator’s attention budget.

The action can wait. If the action must execute at a specific instant — a market-microstructure trade, a real-time control loop, a safety-critical interrupt — the latency cost is fatal. The pattern is for actions where “this happens in 60 seconds instead of now” doesn’t materially change the outcome.

Cerberus Markets satisfies all three: trade actions move real capital, the system fires on the order of tens of trades per day, and 60 seconds of additional slippage exposure is small relative to the position-sizing strategy.

Where it doesn’t fit

The pattern is wrong for systems where:

Throughput is the primary constraint. A high-frequency request handler can’t pause for human review without becoming a different product.

The action is its own undo. If the action can be reversed cheaply and the cost of a wrong action is bounded, the pattern adds cost without proportional value.

There’s no plausible operator audience. Building announcement infrastructure for a channel nobody reads is worse than building no announcement infrastructure.

The action is part of a tightly-coupled flow. If the autonomous action is one step of a chain that has to complete in order, pausing for review breaks the chain. Either the whole chain gets the pattern or none of it does.

The deeper observation

The reason this pattern feels novel to people is that most autonomous-system design has been shaped by the assumption that automation should replace human attention. That’s the wrong frame. The right frame is that automation should redirect human attention — from doing the work to checking the work for the cases the system isn’t yet aware of.

A system that’s announce-then-execute is, structurally, asking the operator a different question than a system with an approval queue. The approval queue asks “should this happen?” The announcement asks “is there any reason this shouldn’t happen?” The default flips. The operator’s attention is required only for exceptions, not for routine cases. And the operator’s intuition — the part of human attention that’s hardest to automate — is exactly the part the pattern is designed to leverage.

I think 60-second cancel windows belong in a lot more systems than have them today. Trading systems. Deploy systems. Outbound communication systems. Anywhere an autonomous action affects something an operator might want to stop.

The pattern is cheap. The bar to add it is low. The return is leverage on the operator’s intuition for the failure modes the system can’t enumerate yet.