An entire process instance is cancelled. All active tasks are terminated and no further execution occurs. The entire case (process instance) is withdrawn — no output is produced and no continuation path exists.
A multi-stage AI investment analysis pipeline has three agents running in parallel: Market Researcher, Founder Checker, and Financial Modeler. While all three are mid-execution, the startup sends an email: "We are withdrawing our application." The Application Withdrawn event fires. All three agents are terminated immediately. The case is closed with no output — no IC brief, no partial analysis, no summary. The process instance ceases to exist.
The key insight: no continuation path makes sense after case withdrawal. Unlike Cancel Activity (60.61), which routes to an alternative task, Cancel Case has nowhere to go. The entire reason the process exists is gone. Continuing with a partial analysis, a fallback, or a summary would be meaningless — the startup is no longer in the pipeline. The process must be cleanly terminated and all associated compute freed.
| Metric | Signal |
|---|---|
| Mean time to full termination | Time from Cancel Case signal to all agents acknowledged-terminated — measures cancellation completeness and speed |
| Compute reclaimed per cancellation | GPU/LLM tokens saved by early termination across all cancelled agents — quantifies cost efficiency |
| Orphaned resource rate | Fraction of cancellations that leave unreclaimed external resources — monitors compensation coverage |
| False cancellation rate | Fraction of Cancel Case events that were incorrect (case was still valid) — monitors signal reliability and the cost of false positives |
| Node | What it does | What it receives | What it produces |
|---|---|---|---|
| Market Analysis | Researches TAM, competitive landscape, market timing for the startup. Long-running — may be 5..15 min deep web search. Cancellable at any point. | Deal submission + market scope | Market analysis report (if completes normally) |
| Founder Check | Runs background checks on all founders in parallel. Queries LinkedIn, Crunchbase, public records. Cancellable at any point. | Founder profiles + check scope | Founder dossier (if completes normally) |
| Financial Model | Builds financial projections from submitted financials and comparable companies. Cancellable at any point. | Financial statements + comparable data | Financial model (if completes normally) |
| Application Withdrawn | Receives the withdrawal signal. Sends cancellation to all three active analysis agents. Bypasses the Close Case node and routes directly to end — no output is produced. | Withdrawal signal (external event) | Termination signals to all active tasks; case closure event |
| Close Case | Normal completion path only — consolidates completed analyses into IC brief. This node is never reached on the cancellation path. | All three completed analyses | IC brief (normal path only) |
| Origin of Value | Where it appears | How it is captured |
|---|---|---|
| Conditional Action | All three active analysis agents | Immediate termination reclaims compute for other pipeline instances. A 15-minute analysis cancelled at minute 5 saves 10 minutes of GPU and LLM cost — multiply by pipeline throughput for total savings. |
| Governance | Application Withdrawn event | Processing a withdrawn application wastes analyst attention, risks generating reports on a company that no longer consented to the analysis, and creates data retention obligations. Cancellation enforces data minimization. |
| Risk Exposure | Side effects from cancelled tasks | Cancelled tasks may have already written to external systems (CRM, deal tracker, database). Cancel Case must trigger compensating writes — remove in-progress entries, clear reserved resources, log the cancellation event. |
Cancel Case vs. Cancel Activity. Cancel Activity is surgical: one task stops, the process adapts. Cancel Case is total: the process instance ceases. The decision criterion is whether a meaningful output remains possible. If yes — Cancel Activity with fallback. If no — Cancel Case.
The Financial Modeler is running a long external computation and does not poll for cancellation signals. The Market Researcher and Founder Checker terminate cleanly. The Financial Modeler runs to completion 10 minutes later and attempts to write its output to Close Case. The Close Case node no longer exists — the case was cancelled. Fix: all agents must implement cancellation polling with a maximum interval (e.g., every 5 seconds). The case manager must also track which instances have acknowledged termination and escalate unresponsive agents.
All three analyses complete at t=12 minutes. The withdrawal email arrives at t=13 minutes. The Application Withdrawn event fires, but the Close Case node has already produced the IC brief. Fix: implement an idempotency check at the Application Withdrawn handler — if the case is already in "completed" state, the withdrawal event is logged but produces no action (case was already closed normally).
The Market Researcher provisioned a temporary cloud VM for a long research task. The VM is mid-computation when the cancel signal arrives. The agent terminates but does not release the VM. The VM runs for hours at cost. Fix: resource provisioning must be tracked in a case-level resource registry. On Cancel Case, the case manager iterates the registry and releases all provisioned resources, independent of whether the agent acknowledged cancellation.
The withdrawal detection system misparses an email as a withdrawal signal when it was actually a clarification question. Cancel Case fires, all agents are terminated, and 12 minutes of analysis is lost. The deal is still live. Fix: cancellation signals for high-value cases require confirmation — either a second verification signal or a brief hold period before execution, during which a human can override.
| Variant | Modification | When to use |
|---|---|---|
| Confirmed Cancel | Cancel Case requires a second confirmation signal before executing | High-value cases where false cancellations are costly; confirmation adds latency but prevents irreversible errors |
| Audit-Preserving Cancel | Before termination, each active agent writes a snapshot of its in-progress state to an audit log | Regulatory or compliance requirements mandate that all process activity — including cancelled work — is recorded and retrievable |
| Graceful Shutdown | Agents receive a "shutdown requested" signal and have a grace period to reach a safe checkpoint before forced termination | Agents write to external systems that require transactional integrity; hard cancellation would leave external state corrupt |
| Pattern | Relationship |
|---|---|
| 80.81 Cancel Activity | Surgical variant — cancels a single task while the process continues via a fallback path |
| 20.23 Orchestrator-Workers | Cancel Case often applies to orchestrated pipelines — the orchestrator is the natural entry point for the cancellation signal |
| 20.22 Human-in-the-Loop | High-stakes cancellations benefit from a human confirmation gate before the Cancel Case executes |
| 60.62 MI Design-Time | Multiple parallel agents require bulk cancellation — Cancel Case terminates all instances in a single operation |