Reactive Wakeup Signaling (Event-Driven Execution Protocol)
Overview
When an agent launches a long-running background command (e.g., Docker container build, complete test suite run, database seed migration), naive agents fall into an Active Polling Loop:
- Turn 1: Launch background task
task-101 - Turn 2: Call
manage_task(Action: "status", TaskId: "task-101")$\rightarrow$ "Still running" - Turn 3: Sleep $\rightarrow$ Call
manage_task(Action: "status")$\rightarrow$ "Still running" - ... (Repeated 15 to 25 times)
Active polling burns 30,000+ context tokens purely re-sending transcripts to check a boolean status flag, while locking the agent in a busy-wait loop.
The Reactive Wakeup Signaling Protocol leverages event-driven agent architectures: the agent launches the command, yields execution immediately by stopping tool calls, and allows the runtime event loop to automatically re-wake the agent upon process termination.
Active Polling Busy-Wait vs. Reactive Event Wakeup
┌─────────────────────────────────────────────────────────────┐
│ Background Task Management │
│ │
│ Active Polling Busy-Wait (20 Turns / 38,000 Tokens): │
│ • Turn 1: `launch_task(npm test)` │
│ • Turn 2: `status_check()` ──► "running" │
│ • Turn 3: `status_check()` ──► "running" │
│ • ... (20 turns re-sending entire conversation transcript) │
│ ↳ 38,000 tokens billed, $1.14 wasted purely on status pings│
│ │
│ Reactive Event Wakeup Protocol (1 Launch + 1 Wakeup): │
│ • Turn 1: `launch_task(npm test)` ──► STOP CALLING TOOLS │
│ • (Agent sleeps at zero token cost while process runs) │
│ • System Event: Process PID 4821 finished with exit code 0 │
│ • Turn 2: Agent automatically resumes with test results │
│ ↳ 2 Turns Total, 1,200 tokens billed (96.8% Savings!) │
└─────────────────────────────────────────────────────────────┘
The 3 Rules of Reactive Task Execution
┌───────────────────────────────────────────────────────────────────────────┐
│ 1. NEVER WRITE SLEEP OR POLLING LOOPS IN CHAT │
│ Do NOT loop on `manage_task(Action: 'status')` or run `sleep 5` │
│ │
│ 2. YIELD EXECUTION IMMEDIATELY AFTER LAUNCH │
│ After launching a background job, stop calling tools to end your turn │
│ │
│ 3. TRUST THE REACTIVE WAKEUP BUS │
│ The runtime environment monitors subprocess PIDs and injects the │
│ completion payload into the next invocation when the task terminates │
└───────────────────────────────────────────────────────────────────────────┘
Tool Invocation Workflow
Step 1: Launch Background Job & Yield
{
"CommandLine": "npm run test:e2e",
"Cwd": "c:/Users/ASUS/Documents/Newfolder/Antigravity/Major AI Skills",
"WaitMsBeforeAsync": 500,
"toolAction": "Launching E2E test suite in background",
"toolSummary": "Background Test Launch"
}
Agent stops tool calls and ends its turn. Runtime monitors task.
Step 2: System Automatically Wakes Agent on Completion
The runtime injects the completion notification as an incoming message:
<!-- SYSTEM REACTIVE NOTIFICATION -->
[Background Task 'npm run test:e2e' finished. Exit Code: 0]
Output: 42 passed, 0 failed, 120s total duration.
Agent resumes on Turn 2, inspects the success result, and presents the final walkthrough to the user.
Benchmark Comparison
Running a 3-minute continuous integration test suite:
| Task Management Strategy | Agent Turns Billed | Tokens Consumed | Cost Impact |
|---|---|---|---|
Active Polling (manage_task status) |
24 turns | 44,500 tokens | $0.667 |
| Reactive Wakeup Protocol | 2 turns | 1,400 tokens | $0.021 (96.8% Savings!) |
Agent Operational Directive
MANDATORY: Agents must NEVER poll in loops waiting for asynchronous commands or background tasks. Launch the command and end the turn immediately. The system will automatically wake and resume agent execution when the task finishes.