The Interruption Threshold: How AI Should Decide Whether New Information Changes the Plan

An AI agent working on a live business process will receive new information after it has started: a customer replies, a forecast changes, an approver adds a constraint, or another system reports an error. The agent must decide whether to interrupt its current plan.

Treating every update as urgent creates thrashing. Ignoring updates until the task ends creates stale decisions. The useful middle ground is an interruption threshold: a rule that evaluates whether new information materially changes the plan, its safety, or its expected value.

This is not merely a notification setting. It is a control mechanism for keeping an agent responsive without making it unstable.

The problem: relevance is not the same as interruptibility

New information can be relevant yet not deserve immediate attention. Suppose an agent is preparing a renewal proposal. During the work, it receives three updates:

• The customer corrects the spelling of a stakeholder’s name.
• Finance changes the maximum permitted discount.
• A sales representative adds background about the customer’s previous negotiation style.

All three belong in the case record. Only the discount change necessarily requires the agent to stop and reconsider the proposal. The spelling correction can be incorporated before delivery. The negotiation note may improve the output, but whether it should interrupt depends on the stage of work and the cost of replanning.

A weak system asks, “Is this update related?” A stronger system asks, “Would continuing under the current plan create a materially worse or invalid result?”

The four tests behind an interruption threshold

Each incoming event should be evaluated against four tests. These tests should use business rules and observable workflow state rather than the model’s intuition alone.

An event should interrupt immediately when it fails the validity test or creates significant safety, compliance, or authority risk. For ordinary operational updates, impact, timing, and recovery cost determine whether immediate replanning is justified.

The threshold should become stricter as actions become harder to reverse. While an agent is gathering information, delayed incorporation is often acceptable. Immediately before an external commitment, the same update may require a stop.

Use three responses, not a binary choice

Designers often give an agent only two options: interrupt or ignore. That forces poor decisions. A practical model has three responses.

Interrupt and replan

Stop the current sequence, preserve completed work, identify what changed, and recompute the next action. Use this response when the current plan is no longer valid or when delay creates unacceptable exposure.

Queue for the next checkpoint

Record the event and revisit it at a defined boundary, such as before drafting, before approval, or before execution. This is the correct response for relevant information that improves the work but does not invalidate the current step.

Record without changing the plan

Attach the event to the case for traceability, but continue. This fits duplicate signals, cosmetic changes that can be applied later, and information already represented in the plan.

The middle response is essential. It prevents an agent from treating “not now” as “never.”

How to define checkpoints

An interruption threshold works only if queued information has a reliable place to re-enter the workflow. Define checkpoints around transitions where new context can change the next commitment.

1. After discovery: Reconcile new facts before selecting an approach.
2. Before drafting: Refresh requirements, audience, constraints, and source material.
3. Before approval: Check policy, authority, financial limits, and unresolved exceptions.
4. Before execution: Confirm that the target, action, and conditions remain current.
5. After execution: Evaluate whether late events require remediation or follow-up.

Checkpoints should align with decision boundaries, not arbitrary time intervals. “Review every ten minutes” is usually weaker than “review before sending the customer response.” The latter connects context refresh to consequence.

A worked example: preparing a renewal offer

Consider an agent preparing a software renewal offer. The approved operating conditions are:

• The customer requested a two-year term.
• The account executive may approve a discount up to the current delegated limit.
• Legal review is required if nonstandard termination language is included.
• No offer may be sent without account-owner approval.

The agent has completed discovery and is drafting the commercial proposal. Four events arrive in sequence.

Event 1: a corrected billing address

The address is relevant, but it does not affect the commercial recommendation. The proposal is still internal and easily editable. The agent records the correction and queues it for the pre-approval checkpoint. No interruption is needed.

Event 2: finance lowers the delegated discount limit

The draft now exceeds the account executive’s authority. This fails the validity test: an assumption about permission is no longer true. The agent interrupts, marks the existing price as unapproved, recalculates the offer, and reports the difference. It does not silently substitute a new price if that change would alter the agreed negotiation strategy.

Event 3: the customer requests a one-year term

This changes the requested product configuration and may affect pricing. Continuing the two-year proposal would produce the wrong offer. The agent interrupts and replans from the updated requirement.

Event 4: a sales note says the customer prefers concise emails

This affects presentation rather than deal structure. The agent queues it for the drafting checkpoint and continues any calculation already in progress. Before composing the customer-facing message, it applies the preference.

The important distinction is not whether each event matters. It is whether the event changes the validity or value of continuing the current step.

Turn the concept into an executable rule

For each incoming event, the agent should create a small structured assessment containing:

• Affected object: The customer, document, approval, transaction, or plan component.
• Changed fact: The previous value and the new value.
• Dependency: Which current assumption or planned action relies on that fact.
• Consequence of delay: What can go wrong before the next checkpoint.
• Recovery cost: Whether work can be corrected internally or requires external remediation.
• Response: Interrupt, queue, or record.

A compact decision rule can then be expressed as follows:

Interrupt when an event invalidates a required assumption, changes permission, creates material risk before the next checkpoint, or makes the next action costly to reverse. Otherwise, queue relevant information for the nearest decision checkpoint and record non-actionable information without replanning.

This rule should be supplemented with explicit mandatory stops. Examples include revoked consent, changed payment instructions, new legal restrictions, security alerts, and loss of required approval. Mandatory stops should not depend on a model-generated impact score.

Prevent interruption loops and false urgency

Once an agent can interrupt itself, several failure modes appear.

Duplicate events can repeatedly trigger the same replan. Assign event identifiers or compare normalized changes so the agent recognizes information it has already processed.

Oscillating inputs can cause endless switching. If a value changes repeatedly, pause dependent work and request a stable source of truth rather than replanning after every update.

Low-quality signals can override authoritative records. Apply source precedence before interruption logic. An informal note should not replace an approved policy merely because it arrived later.

Self-generated events can form feedback loops. If the agent’s own draft update triggers a new case event, label the origin and suppress reactions that do not introduce external information.

Artificial urgency can bias the system. Words such as “urgent” should influence timing only when supported by a deadline, consequence, or authorized escalation path.

What to measure after deployment

Do not optimize for the fewest interruptions. An agent that never stops may look efficient while producing stale work. Review the quality of interruption decisions instead.

• Avoidable interruptions: Cases where replanning did not change the action or output.
• Missed interruptions: Cases where the agent continued despite a material change.
• Queue latency: Whether deferred events were incorporated at the promised checkpoint.
• Discarded work: Work repeated because a relevant event was processed too late.
• Unstable cases: Workflows with repeated replanning, often indicating conflicting sources or poorly defined ownership.

Review these measures by event type and workflow stage. A global threshold will conceal important differences. A changed shipping address and a changed bank account may both be “field updates,” but they carry different authority, fraud, and reversibility implications.

The operating principle

A capable agent should neither chase every signal nor protect its plan from correction. It should preserve momentum until new information changes the legitimacy, expected outcome, or recoverability of the next action.

The practical design is straightforward: identify dependencies, classify incoming changes, define decision checkpoints, and reserve immediate interruption for information that cannot safely wait. That gives the agent a disciplined way to remain attentive without becoming distractible.

This post was drafted with AI assistance and reviewed against our editorial policy before publication. Corrections are made at the source, on the page, with the date shown.