Real-Time Agents
Real-time agents are the specialists of a planning agent team that work the operating day: they monitor interval actuals against the reforecast and the published schedule, detect threshold breaches and patterns, issue incidents into the operation's incident process, propose events into the intelligence ledger, and carry reoptimization proposals to an action gate. The page's claim is that the value of a real-time agent team in its first form lies in what it writes, a clean incident record, a matched event, a proposal with its evidence, rather than in what it does to the platform, and that acting on routing or schedules within guardrails is a later step the team earns with a catch rate. This page gives the three agents, their outputs, and the boundary with the wiki's existing real-time pages.
What this page is not
The wiki already describes the real-time layer thoroughly. Real-Time Operations is the master reference; Real Time Threshold Alerts and Escalation Protocols gives the alert classes and escalation trees; Incident Management for Contact Centers gives the incident process, severity codes and closure; Daily ROC Routine gives the analyst's day; Level 3: The Automation Layer gives the rule-governed automation that senses variance and acts within seconds; and Real-Time Schedule Adjustment gives the levers. None of that is restated. This page describes the agents that sit beside a real-time analyst and write into those processes, and it says where they stop.
The three agents
| Agent | Reads | Does | Writes | Rung |
|---|---|---|---|---|
| Monitor | Interval actuals from the ACD feed; the current reforecast version; the published schedule; adherence | Compares actual to reforecast and scheduled to staffed by interval, channel and skill; maintains control charts on handle time, volume and staffing; distinguishes common-cause variation from a special cause[1] | An interval variance record, graded [M] and [C] | 1 |
| Detector | The monitor's records; the alert classes and thresholds in the profile; the events ledger | Detects threshold breaches per the operation's alert configuration; detects patterns across intervals and channels that no single threshold catches (a rise on one channel with a fall on another; a staffing gap that precedes a service miss); matches breaches to events whose effect window covers them | A detection with its pattern, its matched events, and a proposed severity from the operation's matrix, grade [C] | 1 |
| Issuer | Detections; the incident process's record format; the register | Issues an incident into the incident process with the standard record filled from the detection: time, channels, the fault arm per Real-Time Cause and Effect Fishbone, the matched events, the proposed severity; proposes an event into the intelligence ledger where the detection is not explained by one already there; carries any reoptimization proposal from the scheduling team to the action gate | Incident records; event proposals [A]; gate requests | — |
The rung column is the same rule as everywhere in the series. The detector may write "service level fell below target from 09:15 and staffing was 11 percent under schedule from 09:00"; it may not write that the second caused the first. The fishbone's four arms name where a miss can come from; the detector places the miss on an arm as association and the incident's post-mortem, run by people, decides cause.
The action gate
Every action a real-time team could take on the platform, a skill reassignment, a break move, an overtime offer, a routing change, passes through an action gate before the platform executes it. Inside guardrails, a real-time analyst approves; outside them, a manager. The agents propose; they do not execute. Real Time Threshold Alerts and Escalation Protocols, whose alert classes the detector reads, grants an autonomous-response branch in which the alert recipient acts without further approval; that authority is the human analyst's and is unchanged here. The gate on this page governs what an agent may execute, and the analyst's approval at the gate is the analyst's autonomous action. This is stricter than Level 3: The Automation Layer and Real-Time Schedule Adjustment describe for a mature rule-based layer, and deliberately so: the series describes the period in which a function is earning the evidence that would justify that layer, and the gate is where the evidence is produced. Each proposal at the gate is a row: proposed action, expected effect, evidence, decision, outcome. The catch rate and the outcome record together are what The Agentic Handover Gate requires before execution moves into the specified band.
The reason for insisting on it is the one the human-factors literature has made since the ironies of automation were first stated: an operator left with only the cases automation could not handle, and deprived of the routine that built the competence to handle them, is worse placed than before.[2] A real-time analyst who approves every proposal keeps the situation awareness the day requires; one who reads incident reports after the fact does not.[3]
The two things the team writes that nobody wrote before
Incidents with the evidence attached. An incident record raised by a person under pressure is usually a time and a symptom. The issuer's record carries the interval variance, the control-chart state, the fault arm, the matched events and the staffing picture, because the monitor and detector had already produced them. The post-mortem starts with the evidence rather than reconstructing it.
Event proposals. A real-time day is the richest source of events the intelligence ledger has, an outage at 10:20, a client's system release that changed the contact mix, a weather day, and almost none of it reaches the forecaster in most functions, because the analyst who saw it had no ledger to write it into. The issuer proposes each as an event with an effect window; a person confirms; the scout on The Intelligence Feed matches it to the next miss. The loop from the day back to the forecast, which WFM Processes names as the loop whose absence is a common failure mode and whose fix it describes as a weekly cross-function review, is closed by that one write.
Worked example
The series example, Wednesday 8 April 2026, the 38th day of the migration. At 09:15 the monitor's voice service-level record crosses below target; staffing was 11 percent under schedule from 09:00 [M], and handle time is on its post-migration level, in control. At 09:20 the detector matches the pattern to a known one, staffing shortfall preceding a service miss, finds no event whose window covers the morning, and proposes severity 2 from the operation's matrix. At 09:21 the issuer writes the incident: arm 3, "scheduled line does not match arrivals," ruled out; arm 1, "poor line adherence," indicated by the staffing gap; the matched-events field empty, the reoptimization proposal R-044 from the scheduling team (a break shift for 9 agents) carried to the action gate. The real-time analyst approves R-044 at 09:24; the platform executes it; service recovers by 09:50. The post-mortem that afternoon finds a training pull that took 14 agents off the floor for two days and was in nobody's calendar. The issuer's event proposal, "training pull, 8 to 9 April, voice, in-house cohort," is confirmed by the planner and enters the events ledger. On Thursday the daily loop's scout matches Wednesday's miss to it; the forecaster keeps the two days out of the demand trend estimate as a supply-side break, which without the event it could not have told apart from demand.
A leader asks that afternoon why service broke on Wednesday. The answer card that returns within the hour is on The Question Register and Knowledge Base.
What would change this
The no-execution rule is the load-bearing choice, and it is a sequencing rule, not a permanent one. A published catch rate on the detector's severities and a clean outcome record on the action gate would release the gate for that class of action, the condition Human Gates and Number Grades states. Three Bands of Work already sorts intraday reallocation within guardrails as specified work, and this page's gate is stricter than that sort for the period in which the evidence is earned; Level 3: The Automation Layer describes the gate-free operation. Field evidence that the gate's latency cost more service than the rule saved in errors would argue for a narrower guardrail set executed without a gate from the start.
How this connects
Real-time agents are a third team in the pattern of The Agent Team Model. Their incident records go into Incident Management for Contact Centers; their alerts follow Real Time Threshold Alerts and Escalation Protocols; their event proposals feed The Intelligence Feed and thereby The Short-Term Forecasting Loop with an Agent Team; their action gate is one of five on Human Gates and Number Grades. The day they write into is Daily ROC Routine's.
Maturity Model Position
A real-time analyst with wallboards and thresholds is Level 2 on the WFM Labs Maturity Model™. Agents that monitor, detect and issue with evidence attached, behind an action gate, are the Level 3 form described here, and the gate's outcome record is the evidence on which, per Human Gates and Number Grades, a gate is released for a class of action; that page also records that the wiki places gate-free guardrailed execution at more than one level, and this series takes no position on which. Level 4 adds the event loop back to the forecast as routine; Level 5 is not described.
See Also
- AI Agent Teams for Workforce Management — the series hub
- Scheduling Agents — where reoptimization proposals originate
- The Intelligence Feed — the events ledger the issuer proposes into
- Human Gates and Number Grades — the action gate
- Real-Time Operations — the master reference for the layer
- Incident Management for Contact Centers — the incident process the issuer writes into
- Real Time Threshold Alerts and Escalation Protocols — the alert classes the detector reads
- Level 3: The Automation Layer — the rule-governed layer the team grows into
References
- ↑ Montgomery, D. C. (2019). Introduction to Statistical Quality Control (8th ed.). Wiley. ISBN 978-1-119-39930-8.
- ↑ Bainbridge, L. (1983). "Ironies of Automation". Automatica 19(6), 775–779. doi:10.1016/0005-1098(83)90046-8.
- ↑ Endsley, M. R. (1995). "Toward a theory of situation awareness in dynamic systems". Human Factors 37(1), 32–64. doi:10.1518/001872095779049543.
