Einstein Case Classification trains on closed cases and predicts field values for new ones (Salesforce n.d.-a). It went GA in the Spring '19 release (Salesforce 2019). The design choice worth recording is the confidence ladder: the admin sets thresholds per field, and the more automated the action, the higher the confidence needed. Below the auto-fill threshold Einstein falls back to preselection, then to a top-three recommendation.

Einstein Case Routing is not a separate model. After classification writes the fields, Einstein can rerun case assignment rules or skills-based routing rules on the updated case. Priority is one of the predictable fields, and priority selects the milestone targets downstream, so the classifier chooses the clock; the clock does not inform the classifier.

Not an AI feature, but it is the one place in the Salesforce stack where a milestone deadline is a routing input. The Route Work flow action takes an Acceptance Due Date. Omni-Channel orders by primary priority, then secondary priority, then Acceptance Due Date (earliest first), then time in queue (Paterson 2025). The date can be a formula (NOW() + 2/24 for a two-hour tier) or the TargetDate of the open case milestone, which reuses entitlement processes as they stand. The SLA clock breaks ties only among items with equal priority; it does not override priority. The source is a Salesforce product manager's post on UnofficialSF; the release notes were not checked.

Agentforce Service Agent went GA on 29 October 2024 with prebuilt topics for case management, order inquiries and account management, and handoff to a human rep with the conversation attached (Salesforce 2024). It is the customer-facing successor to Einstein Bots. A third-party migration guide reports no published retirement date for Einstein Bots, and that the two products share no authoring objects, so dialogs and intent training sets do not carry over (Salesforce Dictionary 2026).

The Implement Agentforce Service trail places SLA management, entitlements and milestones in the same curriculum (Salesforce n.d.-b), but this pass found no documented out-of-box action through which the agent reads milestone time remaining or breach state. An admin can expose that through a custom flow or Apex action; whether Salesforce ships one is unconfirmed. Milestone violation and warning actions remain time-triggered workflow, outside the agent.

A Salesforce engineering blog describes LLM classification of inbound email into intent ("Feature Request" vs "Critical Outage") and reason, a vector search against knowledge, and a platform event fired on "High-Severity Technical Issue" patterns that sets ownership and priority (Sethuraman, Sarkar, and Chinnangolla 2026). It is a reference pattern with no product SKU. Severity is derived from text; the entitlement clock is not consulted.

CRMArena is the closest thing in the area to a public triage benchmark (Huang, Prabhakar, Dhawan, et al. 2025). Of its nine tasks, New Case Routing is triage: assign an incoming case to the best human agent. The ground truth is a three-tier policy: issue expertise (most closed cases on the most similar issue), then product expertise, then workload (fewest non-closed cases). Neither SLA nor case age enters the policy. Handle time and transfer count appear only as analytic questions about agents.

CRMArena-Pro extends this to 19 tasks over sales, service and CPQ, in B2B and B2C orgs, and adds multi-turn interaction; leading agents drop from about 58% single-turn success to about 35% multi-turn, with near-zero unprompted confidentiality awareness (Huang, Prabhakar, Thorat, et al. 2025). Whether any Pro task includes a time contract is unconfirmed from the abstract.

Intelligent triage writes four predictions into ticket fields, each with a confidence field, and those fields become available to "views, triggers, automations, macros, SLAs, queues, and the ticket API" (Zendesk n.d.-a). Classifications are on by default with the Copilot add-on and off otherwise. The launch release is dated 13 September 2022 (Zendesk 2022).

The SLA relationship runs one way. Zendesk SLA policies key every target (first reply, next reply, total resolution, periodic update and others) by ticket priority, with a business-hours flag per metric, and filter conditions select which policy applies (Zendesk n.d.-c). A trigger can set priority from a predicted Topic or Sentiment, which selects the target. The model does not read elapsed time.

When ordering by SLA is on, "tickets are ordered by nearness to SLA breach, beginning with those that have already breached", and all tickets with an SLA sort ahead of those without, regardless of priority (Zendesk n.d.-b). This is stronger than the Salesforce equivalent: in Zendesk the breach time replaces priority as the sort key, where Salesforce's Acceptance Due Date only breaks ties within a priority. Neither is an AI decision. The clock is a router input in both.

Zendesk bought Ultimate in March 2024 for its autonomous agents (Zendesk 2024) and announced the purchase of Forethought on 12 March 2026, described as its largest acquisition in two decades (The Next Web 2026). Forethought's Triage product is covered separately below. Zendesk bills AI agents per automated resolution; a secondary source reports a 2026 split between LLM-verified resolutions, which are billed, and contained ones, which are not. That split is unconfirmed against Zendesk docs.

Auto Triage predicts Priority and Group directly, the two fields that most help desks use to select an SLA target and a queue (Freshworks n.d.). The Manual/Automatic choice is made per field, and "Automation Rules always take precedence over AI suggestions", so a rule-set priority wins over a predicted one. The docs say nothing about SLA policies or due dates.

Fin Attributes are admin-defined fields that Fin fills while it handles a conversation; they drive workflow branches and escalation rules (Intercom n.d.-d). Detection happens only after a "Let Fin handle" block runs, not before and not without Fin. Classification is a side effect of the resolve attempt.

Intercom's SLA handling is the most explicit about where the clock starts when an agent goes first. SLAs are applied by a workflow step and honour office hours: a 15-minute first-response target on a message received at 17:50 against 09:00-18:00 hours is due at 09:05 the next working day (Intercom n.d.-c). With the bot inbox enabled, an admin can "exclude the time conversations spend in the bot inbox from SLA targets", so the human SLA timer starts only when Fin hands off (Intercom n.d.-b). That makes the SLA a contract on the human alone. Intercom's own example of combining the two is an inbox view, which a person reads: "Fin Attribute: Issue = Technical + SLA due in < 30 min".

HubSpot splits triage into small generative features: descriptive ticket names, categories, language and summaries, which routing rules then consume (HubSpot n.d.-b). The Customer Agent resolves or hands off; HubSpot defines a resolution as no human handoff within 72 hours, the only time window in the HubSpot material, and it measures the agent, not the customer's wait (HubSpot n.d.-a). The vendor's own figures differ by page (65%, 70%, 50% more resolutions); none cites a method.

KustomerIQ introduced ML conversation classification feeding queues that also weigh agent skills and team capacity (Smart Customer Service n.d.). The fall 2025 release adds business-hours-aware routing, follow-up on abandoned conversations, manager reassignment to AI agent teams, and audit logs that record why a routing decision was made (Kustomer 2025). The routing audit log is uncommon in this area. SLA appears only as an input to workforce forecasting.

Gorgias uses a fixed e-commerce taxonomy (Order/Cancel, Refund/Request, Shipping/Status, Subscription/Cancel and others) rather than per-tenant training; each message gets one sentiment label (Gorgias n.d.). Decisions are made by rules over those labels. The fixed taxonomy trades fit for zero setup.

Front's AI Tagging required an admin to approve ten example emails per tag before tagging began, up to 50 tags per inbox, and is now closed to new users in favour of Topics and Autopilot branching (Front n.d.). Autopilot, announced 30 September 2025, lets admins choose which Topics the agent may handle and which go to humans (Front 2025). Front's rule engine can start SLA timers and act on unreplied time, but nothing documented passes that timer to Autopilot.

Unified routing keeps the model and the decision apart: sentiment prediction and intelligent skill finder write values, and "queue and assignment rules still determine the destination" (Microsoft 2026d). Effort estimation, announced in 2021, generates a work estimate from historical data (Microsoft 2021); a secondary summary says an SLA can serve as the effort definition, which is unconfirmed in Microsoft's text. The Case Management Agent creates and updates cases from chats and email and drafts follow-ups (Microsoft 2025c).

Zia's overview lists auto-tagging by keyword clusters, field prediction for category and priority, sentiment and tone, and anomaly detection on ticket volume (Zoho n.d.). The anomaly detector watches volume, not per-ticket clocks.

Forethought is the vendor that named a product "Triage". It tags and prioritises so that the host system's rules route the ticket (Forethought n.d.). "Prediction rate" measures coverage, the share of tickets that receive a prediction; the page gives no accuracy figure. The product's future inside Zendesk is unconfirmed.

SupportLogic is the one system in this area whose documented model input includes the SLA clock. The Escalation Agent produces a continuous risk score per open case that "updates as new activity occurs and as the case ages", combining sentiment, account health, ARR and "SLA age" (SupportLogic n.d.). Its framing is a critique of SLA-ordered queues: a high-ARR account with compounding negative interactions can sit behind tickets nearer breach. Here the SLA is one feature among several and does not set queue order on its own.

Plain and Pylon are B2B help desks where tier, contract and SLA sit on the customer record. Plain's workflows assign threads to Ari by tier, label, channel or business hours (example: free-tier chat goes to Ari) (Plain n.d.). That uses the contract to decide whether an agent gets the item at all, which is a different use from ordering a queue. A search snippet claimed Ari raises priority to High for security requests and Urgent for incident reports; the current Ari doc does not say so, so it is unconfirmed. Pylon describes agents with "full account and product context" and approval gates, with no triage or SLA specifics (Pylon n.d.).

Sierra's research contribution is tau-bench: a simulated user, typed tools, a written policy, and success judged by comparing the final database state to an annotated goal (Yao et al. 2024). Its pass^k metric (all k trials succeed) measures consistency, which matters more for triage than single-run accuracy because the same ticket should route the same way twice. The benchmark has no clock.

Decagon's triage step is intent extraction followed by AOP selection, with RAG as the fallback when no AOP matches (Decagon n.d.). Escalation Drivers reports which guardrail or AOP produced each handoff, which treats escalation as the measured output of triage.

Ada's contribution is a published definition of its headline metric: a conversation counts as automatically resolved only if relevant, accurate, safe and contained, assessed by AI; before 31 July 2024 only a statistical sample was assessed (Ada n.d.). The only clocks are idle timeouts that end a conversation.

Wise.io sold ML ticket routing and auto-response into Zendesk and Service Cloud before either vendor shipped its own. GE acquired it in November 2016 and spun the support product out as SmartAssist.io, which raised a $5M Series A in August 2017 with Twilio, MailChimp and Zendesk as customers (TechCrunch 2017). Its later status is unconfirmed.

Three generations coexist. Per-tenant supervised classifiers (Wise.io before 2016, Einstein Case Classification 2019, KustomerIQ, Zendesk intelligent triage 2022, Dynamics skill finder 2021, Freddy, Zia, Forethought Triage) write predictions into ticket fields. Fixed-taxonomy and few-shot classifiers (Gorgias intents, Front AI Tagging) trade fit for setup cost. LLM agents (Agentforce, Fin, Breeze Customer Agent, Zendesk AI agents, Autopilot, Sierra, Decagon, Ada, Ari) resolve first and classify as a side effect; Fin Attributes are detected only while Fin handles the conversation.

The SLA enters triage in four ways, and only one of them is an agent input.

1. Triage selects the clock. The commonest pattern. A classifier writes priority (Einstein, Freddy, Zia, Forethought) or a field a trigger maps to priority (Zendesk Topic and Sentiment), and the SLA policy keyed on priority selects the target. The model never reads elapsed time.
2. The clock orders the queue. Deterministic routers consume breach time: Zendesk omnichannel routing can sort by nearness to breach ahead of priority; Salesforce Omni-Channel's Acceptance Due Date (Winter '26) breaks ties within a priority, optionally from the case milestone's target date. No AI in either.
3. The clock is paused for the agent. Intercom can exclude bot-inbox time from SLA targets, so the contract binds the human after handoff, not the agent. Business hours are honoured by Intercom, Zendesk and Kustomer routing.
4. The clock is a model feature. Only SupportLogic documents "SLA age" as an input to a learned score (escalation risk), combined with sentiment and ARR, and it argues against SLA-only ordering.

No LLM agent in this area documents reading the SLA clock (time to breach, business hours remaining) when it decides to resolve, escalate or change priority. Plain uses the contract (tier, business hours) to decide whether the agent gets a thread at all, which is the nearest case.

The public benchmarks have no clock either. CRMArena's New Case Routing ground truth is issue expertise, product expertise, then open-case workload; tau-bench judges final database state under a written policy. Both report low consistency (CRMArena under 55% with function calling; tau-bench pass^8 under 25% on retail), which bears on any triage agent whose routing must be repeatable.

Metrics are vendor-reported and defined differently: Ada and HubSpot publish definitions of "resolution" (contained, or no handoff within 72 hours); Zendesk reportedly bills only LLM-verified resolutions; Forethought's "98% prediction rate" measures coverage and says nothing about accuracy. No independent evaluation of any production triage classifier in this area was found.

Open questions:

• Does any Agentforce, Fin or Zendesk AI agent action expose milestone time remaining to the LLM, out of the box? Not found; worth a direct test in a sandbox org.
• Would an agent that reads time to breach make different escalation decisions than a router that sorts on it? No study in this area tests this.
• How do SLA-paused-for-bot schemes (Intercom) affect reported first response time? The customer's wait includes the bot time; the metric does not.
• Dates still unconfirmed: Zendesk Answer Bot (2017) and Intercom Resolution Bot retirements, DigitalGenius, MonkeyLearn (acquisition by Medallia unconfirmed), Freddy Auto Triage launch, Gorgias intents launch.

Predictive Intelligence is the classic-ML layer under ServiceNow's later generative products. The out-of-box incident solutions are four classifiers (assignment group, category, service, configuration item), each fed by the short description alone, and a family of similarity solutions over short description and description, including major-incident detection (ServiceNow n.d.-b). The page lists no regression or clustering solution for incident, and none of the solutions reads priority, SLA or elapsed time.

"SLA breach prediction" is not an out-of-box Predictive Intelligence solution on that page. Partners describe training a custom model for it, and the platform supports regression solutions that could predict time to resolution, but a shipped ServiceNow breach-prediction model is unconfirmed. The SLA reaches the AI stack later, and only as something to explain (see 8.3.2).

Now Assist for ITSM summarizes incidents, chats and sidebar discussions and drafts resolution notes (ServiceNow n.d.-a). In January 2025 ServiceNow announced AI Agents and an AI Agent Orchestrator; the ITSM set includes an incident categorization agent that infers category, subcategory and the likely CI from the assets assigned to the caller (ServiceNow 2025a). Orchestration is described as specialist agents invoked by a planner. The servicenow.com announcement pages returned 403 to the fetcher, so the agent list is from syndicated copies.

The Explain SLA agentic workflow (Zurich release, docs updated 2026-03-12) is the clearest case in this area of an LLM reading the SLA clock (ServiceNow 2026). It picks the most critical SLA on the task and reports target, elapsed time, breach likelihood, pause/resume events, reassignment patterns and breach causes. It explains; it does not act. It has no trigger, so the SLA is an input to an answer a person asks for, not to routing or priority.

Moveworks Triage intercepts new tickets that pass customer filters, embeds them, retrieves the ten nearest historical tickets by cosine similarity and writes the most common field value if its confidence clears a customer-set threshold (Moveworks n.d.). Phone and walk-up tickets are excluded. The 2020 design post frames the motivation in time terms: an average of five hours before a human first looks at a ticket, against under a minute for the model (Mairena and Kala 2020).

The Equinix numbers come from a devops.com piece and are vendor-reported; the date is unconfirmed. ServiceNow completed the acquisition on 2025-12-15 (ServiceNow 2025b), so Moveworks Triage and Predictive Intelligence assignment now overlap inside one vendor.

AI triage in JSM is a bulk action. An agent selects requests with no type, the model proposes a request type per issue, and on acceptance it rewrites the type and fills that type's fields from the body (Atlassian n.d.-c). The virtual service agent, GA in November 2023 on Slack, Teams, email and the portal, answers from linked knowledge and hands off what it cannot resolve (Atlassian 2023).

The request type matters for the clock: JSM SLA goals are usually keyed on request type and priority, so a reclassification can change which SLA applies. Atlassian does not document that interaction, and nothing found shows the triage model reading the SLA.

The Jira Triage Agent reviews a new work item, compares it with similar items, and proposes field updates and duplicate or related links, each with a stated reason (Atlassian n.d.-d). It can be bound to a board column so that moving an item into "Triage" runs it. Every suggestion needs explicit acceptance. Its quality depends on graph connectivity: practitioner posts note that an empty Component field leaves the agent unable to route.

Rovo's service-management agents (a service-request helper that summarizes, drafts replies, recommends experts and surfaces past tickets) sit on the same graph (Atlassian n.d.-a). No Rovo agent found reads SLA time remaining.

Opsgenie itself never shipped an LLM triage agent. Atlassian folded its alerting into JSM (and Compass), where alert grouping by semantic similarity of title, description and tags, and an LLM-drafted post-incident review, went GA around June 2024 (Atlassian 2024). Opsgenie stopped selling on 2025-06-04 and shuts off on 2027-04-05, with data not yet migrated deleted (Atlassian n.d.-b). It belongs in the survey as the deprecated end of the line.

PagerDuty's noise reduction predates its LLM features. Alert grouping uses ML, content rules or time windows (PagerDuty n.d.-b). Auto-Pause is the one feature in this area where elapsed time is a direct decision input: it learns which alerts usually resolve on their own within a short period, pauses notifications for that period, and only pages if the alert is still open when it ends (PagerDuty n.d.-a). It trades a bounded delay in MTTA against pages that would not have mattered.

The 98% and 87% reduction figures appear on marketing pages without a stated baseline and are vendor-reported.

PagerDuty Advance (July 2024) added generative summaries and audience-specific status-update drafts; the 15-minute saving comes from early-access customer interviews (PagerDuty 2024). The October 2025 suite added an SRE Agent, Scribe (call transcription), Shift (schedule conflicts) and Insights (PagerDuty 2025). The SRE Agent reads logs and runbooks through connectors, recalls similar incidents, prioritises its recommendations "by urgency and impact" and leaves execution to the responder (PagerDuty n.d.-c).

It can run as a virtual responder triggered from an incident workflow, and PagerDuty recommends scoping that trigger to high-urgency incidents. That is the time contract entering as a gate on whether the agent runs at all, not as a variable it reasons over. Escalation timeouts and acknowledgement are not mentioned in the agent docs.

incident.io's launch post walks through a 2 a.m. payment outage: the agent names a memory leak from a specific PR at 2:01, opens a fix PR at 2:05, and service is restored at 2:15 (incident.io 2025). The example is narrated by the vendor. Its design point is citation: each hypothesis links the PRs, past incidents and dashboards it rests on. incident.io has also published a critique of a competitor's accuracy claims, which is vendor-against-vendor and not independent evidence.

Rootly investigates when an alert fires and returns ranked causes with confidence scores (Rootly n.d.). The service catalog gives it owners and dependencies, which is the routing metadata other tools lack. Severity or SLO does not appear as a decision input on the product page.

FireHydrant's March 2024 release covers summarization only: a summary pushed to each new responder, call transcription, status-page drafts and retrospective drafts (FireHydrant 2024). It is in the survey as the early, narrow form of "AI in incident response". Freshworks closed its acquisition in January 2026 to pair it with Freshservice (Constellation Research 2026).

Copilot for Service (GA 2024-02-01) is an assist layer that also works over Salesforce, ServiceNow and Zendesk (Redmond Magazine 2024). The Case Management Agent goes further: it builds a case from a chat or an email, keeps fields current as mail arrives, drafts and sends replies from the detected intent, and closes the case or escalates to a person (Microsoft 2025b). D365 has SLA timers and breach warnings on the case entity, so the clock is one join away; Microsoft's material does not say the agent reads it. This overlaps area 01 (CRM).

This is the longest-running line of work on the exact object of this survey. "An Empirical Investigation of Incident Triage" (ICSE SEIP 2019) measured reassignment on real systems (Chen, He, Lin, Xu, et al. 2019). DeepCT (ASE 2019) treats triage as continuous, re-predicting the owning team as discussion accumulates; across 8 systems 5.43% to 68.26% of incidents were reassigned (Chen, He, Lin, Zhang, et al. 2019). DeepTriage (KDD 2020) is an ensemble in Azure since October 2017, with F1 82.9%, motivated by the observation that a wrong assignment raises time to mitigate by 10x (Pham et al. 2020).

The LLM turn starts with Ahmed et al. (ICSE 2023), who evaluated GPT-3.x models on over 40,000 incidents for root cause and mitigation, with human evaluation by incident owners (Ahmed et al. 2023). RCACopilot (EuroSys 2024) routes each incident to a handler by alert type, collects diagnostics, and has an LLM predict the root-cause category with an explanation (Chen et al. 2024). Triangle (ASE 2025) uses multiple agents that negotiate ownership across teams, reporting accuracy up to 97% and Time to Engage cut by up to 91% (Yu, Fang, et al. 2025).

Across all six papers, time is the dependent variable. None feeds the remaining SLA or severity clock into the model as a feature; severity appears only as a slice for evaluation (DeepTriage reports F1 76.3% to 91.3% on high-impact incidents).

The newest Microsoft claim moves the model out of routing. Microsoft-Decision-1 was announced on 2026-10-09 as "better and faster than an LLM" for retrieving knowledge across logs, tickets, calls and messages during live incidents, with no number attached (8.8.3). That is a decision model used as a relevance scorer for the on-call engineer, not as the triage step these papers measure.

BMC's Ticket Resolver predicts urgency and impact from incident data (BMC Helix n.d.). In ITIL-shaped tools priority is computed from urgency and impact, and the SLA is chosen by priority, so this agent sets the contract rather than reading it. That is a distinct position: the agent decides which clock starts. The docs do not say whether the predicted values write through or wait for approval below version 26.3.

Ivanti Neurons classifies incidents at creation from the subject line and adds generative summaries and knowledge-article drafts (Ivanti 2025). Its agentic solution brief is the only vendor document in this area that names SLA awareness as an agent property (Ivanti n.d.), but it gives no mechanism, so the claim is unconfirmed.

ITSM records carry the richest time contract of any area in this survey, and the agents mostly ignore it. Three positions appear.

1. Clock as gate. PagerDuty's SRE Agent runs only on incidents that pass an urgency filter; Auto-Pause holds a page for a learned window. Time decides whether the AI acts; the conclusion ignores it. Auto-Pause is the only feature found where elapsed time is a model-adjacent input, and it predates the LLM features.
2. Clock as subject. ServiceNow's Explain SLA reads target, elapsed time, pauses and breach likelihood, then explains them to a person on demand. It does not change priority or reroute.
3. Clock as output. BMC's Ticket Resolver predicts urgency and impact, which set priority, which selects the SLA. JSM's request-type triage can change the applicable SLA as a side effect. Here the agent starts the clock, often without saying so.

Everywhere else (Predictive Intelligence, Moveworks, Jira Triage Agent, incident.io, Rootly, FireHydrant, the Microsoft papers) time is the metric reported afterwards: MTTR, TTE, time to mitigate, ticket lifespan. The research line is explicit that misrouting costs time (10x time to mitigate in DeepTriage), yet no model found takes "minutes until breach" as a feature.

The decision mix also splits by item type. ITSM tickets get classification and routing from cheap similarity models (short description in, assignment group out); LLMs arrive as summarizers and, from 2025, as agents that categorise by reading the caller's assets. Incident tools skip classification, since the alert source already names the service, and spend the LLM on investigation and root cause. Human approval is the default everywhere; BMC 26.3 is the only documented confidence-and-risk-gated autonomous execution.

Open questions:

• Does any shipped ServiceNow model predict SLA breach, or is it partner build-on-PI only? (unconfirmed)
• When a JSM or BMC agent changes request type or priority, is the SLA recalculated from creation time or from the change? Neither vendor documents it.
• Would a breach-aware router (route to the team with headroom, not the best-matching team) beat accuracy-optimised routing on SLA attainment? None of the surveyed papers tests it.
• Vendor MTTR claims (50%, 80%, 10x) have no stated baseline. Independent evaluation exists only for the Microsoft papers, on internal data.

Amazon Connect Cases has the most explicit time contract in this area. An SLA is a related item on the case with a name, a target date, a target field value and a computed status; "time to breach" keeps counting negative once overdue (Amazon Web Services n.d.-f). SLAs attach automatically through conversational-analytics rules keyed on case template and field values, and a "Case SLA Breach" rule trigger can escalate or reroute (Amazon Web Services 2025d). The announcement's example is a high-priority case reviewed within 4 hours and closed within 24 hours.

The generative layer sits beside this clock. AI case summaries (November 2025) condense a multi-contact case into background, actions and next steps for the human agent (Amazon Web Services 2025a). No documentation found says the summary, or any Connect AI agent, reads the SLA status. The breach decision is a rule; the model writes prose. Business-hours calendars for case SLAs are not mentioned on the SLA page: unconfirmed.

Contact Lens lets a supervisor write a category as a question ("did the customer try to make a payment on their balance?") and labels matching contacts with the supporting transcript points (Amazon Web Services 2024a). A match can raise an alert or create a task. That is post-contact triage: the item is already handled, and the category decides who looks at it next. Earlier Contact Lens categories were keyword and phrase rules; the generative match replaces the keyword list with a sentence.

Q in Connect is the conversation-time assistant: it reads the live contact and suggests answers, and from December 2024 it also runs self-service flows that take actions before a human is involved (Amazon Web Services 2024b; Amazon 2023). It triages by resolving or deflecting, not by classifying a queue. A November 2025 extension runs the same assistance inside Salesforce Contact Center with Amazon Connect (Amazon Web Services 2025b). Routing decisions in Connect remain the routing engine's (queues, routing criteria); whether the AI agent writes routing attributes beyond handoff is unconfirmed.

AWS put the AI in front of its own case queue. A customer describes the issue in prose, the assistant asks follow-up questions and proposes fixes, and only then offers a case with fields already filled (Amazon Web Services n.d.-a). For operational issues it can hand the problem to AWS DevOps Agent, which streams its investigation into the support interaction.

The response-time contract here is commercial. The support plans page lists first-response targets per plan for critical cases: under 30 minutes for Business Support+, under 15 for Enterprise Support, under 5 for Unified Operations (Amazon Web Services n.d.-c). The plan restructure retires Developer, Business and Enterprise On-Ramp on 2027-01-01 (Amazon Web Services n.d.-d). Severity is still what the customer picks when the case opens; no source says the AI front door sets it. Whether AWS uses models internally to route or prioritize cases among its engineers is not publicly documented: unconfirmed.

DevOps Agent is the incident-side counterpart to the support front door. The preview post lists three triggers: ServiceNow tickets through a built-in integration, CloudWatch alarm state changes, and PagerDuty through configurable webhooks (Stormacq 2025). GA added Azure and on-premises targets and custom skills (Amazon Web Services 2026c). Its pricing ties it to the support contract: Support customers get monthly DevOps Agent credits equal to 30% (Business Support+), 75% (Enterprise) or 100% (Unified Operations) of the prior month's support spend.

The agent triages by investigating. It does not reorder a queue; it shortens the time from page to root cause. The source ticket's priority arrives with the trigger, but no documentation says the agent changes depth or behaviour by priority or by time remaining.

The preview launched at re:Invent 2024 under the Amazon Q Developer brand (Amazon Web Services 2024c) and reached GA in June 2025 as a CloudWatch feature at no additional cost, which can be started from more than 80 AWS consoles and from alarm actions (Amazon Web Services 2025e). The rename matters for a survey: the same capability appears under two product names a few months apart. The item is an alarm, not a ticket, and an alarm's time contract is implicit in whoever is paged.

DevOps Guru is the earlier, non-LLM generation of AWS operational triage, and the first dead entry in this area. AWS's end-of-support page recommends CloudWatch for anomaly detection and alarms and Amazon DevOps Agent "for AI-assisted operational investigation and insight enrichment" (Amazon Web Services n.d.-b, 2026d). Teams that piped DevOps Guru insights into ticketing systems through its API lose that feed on 2027-09-30. The succession is direct: classifier-style anomaly grouping is replaced by an agent that investigates.

This sample is the minimal event-driven shape: a write to a ticket table fires a stream, a Lambda invokes the agent, and the agent either grants access through action groups or escalates (Amazon Web Services n.d.-e). "Access Duration" is the only time field, and it describes the grant, not the response.

The state machine runs two harness invocations with different system prompts and records the result in DynamoDB (Amazon Web Services n.d.-g). It is the only official AWS template found with "triage support tickets" in its title. Urgency is inferred from text alone.

The repository targets Jira Server users who lack Jira Cloud's automation (Amazon Web Services 2024d). The purpose stated in the companion community post is reporting (how teams spend time), not live routing (AWS Community n.d.). Classification after the fact has no clock to respect.

This is the most careful sample in the area. The schema states its own taxonomy version and human-review rubric, and the results document records its limits: synthetic inputs, a single reviewer, a reused test split (Amazon Web Services 2026b). One rule stands out for this survey: "Customer tier is context only. Never change category, priority, confidence, or needs_human solely because of customer tier." The entitlement that would carry an SLA in a real desk is deliberately cut off from the priority decision, and the ticket has no creation time at all.

The post uses the LLM as a labeller, not as the production classifier: Bedrock generates a balanced ground-truth set, and a cheaper model is trained on it (Amazon Web Services 2025c). The post sits in the AWS Support category of the ML blog, which suggests the data is AWS Support's own cases; the post does not say so outright: unconfirmed.

The sample makes the split explicit: the model picks where the case goes (service and category), and a human-set tag picks how fast AWS must answer (Al Okeh 2023). It is the clearest example found of a designer keeping the time contract out of the model's hands.

Contact Center AI launched at Cloud Next '18 as Virtual Agent plus Agent Assist, in alpha (SiliconANGLE 2018). The September 2024 relaunch as Customer Engagement Suite added Gemini-based knowledge assist, coaching, summarization with sub-five-second latency, smart reply and translation, and renamed CCAI Insights to Conversational Insights (Lennox 2024). Insights produces "inquiry topic categories to prioritize": prioritization of topics for managers, not of individual items in a queue. Agent Assist triages the conversational turn; the ticket queue is out of its scope.

Investigations accept a description, an error, a log snippet or an observation time, and return ranked observations and root-cause hypotheses (Google Cloud 2025b). The handoff is the triage link: one click turns the investigation into a Google Cloud support case that carries the observations, and Cloud Assist fills case fields in advance from the chat (Google Cloud n.d.-b). From 2026-04-10, creating and running investigations requires a Premium Support contract or account-team approval (Google Cloud n.d.-a). The agent is gated by the same contract that sets support response times, but nothing documents the response target as an agent input.

No Google paper was found on LLM classification or routing of Google Issue Tracker bugs: the brief's "Google internal bug-triage research" has no direct hit. The nearest work sits on either side of triage. Auto-Diagnose reads integration test failure logs and posts a diagnosis into Critique; it reports 90.14% accuracy on 71 failures and use on 52,635 distinct failing tests (Ziftci et al. 2026). Passerine samples 178 bugs from Google's issue tracker (78 human-reported, 100 machine-reported) and fixes them; the gap between machine-reported and human-reported bugs (73% versus 25.6% plausible patches) is a triage signal in itself (Rondon et al. 2025). Google's security team reports that LLM-drafted incident summaries were written 51% faster (Google Security Blog 2024). ClusterFuzz, the non-LLM baseline, automates filing, dedupe, bisection and closure of fuzzer bugs (Google n.d.-a).

Azure SRE Agent makes ticket priority a routing key. A response plan matches incoming PagerDuty or ServiceNow incidents by service, incident type, priority (for example P1 and P2) and title keywords, and Azure Monitor alerts by severity, then hands the incident to a chosen custom agent (Microsoft n.d.-b, 2026c). The run mode decides whether mitigations wait for approval. Priority thus selects the agent and, through the plan, its autonomy; the time remaining on the incident is not an input in any page read. Microsoft's internal predecessors are covered under 8.3.13.

The observability agent is alert-noise triage: it correlates related alerts into Azure Monitor issues and investigates each, so on-call starts "with a short list of explained issues instead of a flood of raw alerts" (Microsoft n.d.-f). It overlaps Azure SRE Agent; the boundary between the two products is not documented in the pages read.

Microsoft's official training used ticket triage as the multi-agent example. The 2025 lab built a triage agent that delegated to priority, team and effort agents through Foundry "connected agents" (Microsoft Learning n.d.). Connected agents is now a classic feature: the Foundry classic agents are deprecated with retirement on 2027-03-31, and the docs point to workflows (Microsoft 2025a). The replacement task inverts the design: one agent returns `category` and `confidence` as JSON and Python code owns the routing, so business rules stay testable outside the prompt. Neither version has a timestamp or an SLA.

The tutorial pipeline runs classification, ticket creation, runbook lookup, remediation and summary in sequence; for an existing ticket the coordinator skips the pipeline and calls tools directly (IBM n.d.). It targets the repetitive low-complexity tail where resolution is a known runbook. The ticket is created by the agent, so no contract exists until the agent opens one.

Oracle names the agent after the job: categorize, check that the SR has enough information, set severity and sentiment, then pass to a resolution agent (Oracle n.d.). Asking for missing information is the distinctive decision; most samples in this area classify whatever text arrives. Secondary coverage of Oracle's October 2025 agent release says the agents ship at no additional cost in Fusion Applications; the press release itself returned 403 to the fetcher (Oracle 2025).

Three patterns hold across the cloud platforms.

First, the clock and the model live in different components. Amazon Connect Cases has a full SLA object with time to breach and breach-triggered rules, and its LLM writes summaries beside it. AWS support plans publish response targets (under 30, 15 or 5 minutes for critical cases) and put a generative front door before the case, but the customer still sets severity. The CloudWatch-to-Support sample routes with the model and sets severity from a human tag. The Nemotron cascade forbids customer tier from moving priority. Azure SRE Agent uses priority and severity as routing keys for response plans, the closest any product comes to letting the contract steer an agent, and it still routes on priority alone. No product or sample read here passes elapsed time, time to breach or business-hours state to a model.

Second, the operational side has converged on investigation agents, and the older ML generation is being retired. DevOps Guru (anomaly grouping, 2020) enters sunset with AWS DevOps Agent as its named successor; Amazon Q Developer operational investigations became CloudWatch investigations within six months; Azure Monitor investigate became the Azure Copilot observability agent. Each hands off to the vendor's own support queue: DevOps Agent opens an AWS Support case with findings, Gemini Cloud Assist converts an investigation into a case, and AWS bills DevOps Agent against support spend while Google gates investigations behind Premium Support. The support contract has become the agent's entitlement; it is still absent from the agent's input.

Third, the sample code teaches classification without a timestamp. Every reference sample found (the AWS sample repositories, the Step Functions template, the Microsoft Learn labs, the IBM tutorial) takes the body and at most a title or tier, and emits category, priority, team or urgency inferred from text. Microsoft's 2026 lab moves routing out of the prompt into code, and the Nemotron cascade publishes its rubric and a single-reviewer evaluation; both are steps toward auditable triage, neither touches the clock.

Microsoft's internal incident-triage work (DeepTriage, RCACopilot, Triangle, the ICSE 2026 Intelligent Triage paper (Liu et al. 2026)) is the exception on metrics: it measures time to engage and time to mitigate as outcomes; see 8.3.13. GitHub-issue triage on Foundry (IssueLens) is under 8.5.18.

Open questions: whether AWS, Google or Microsoft use models to route or prioritize their own customers' support cases among engineers (no public source found); whether Connect AI agents can read case SLA status as context; whether Oracle's triage agent reads Fusion milestones; and when, if ever, Gemini Cloud Assist investigations leave preview.

GitHub ships two Actions on top of the GitHub Models inference API: github/ai-assessment-comment-labeler and github/ai-moderator (GitHub 2025d). The labeler is opt-in per issue: nothing happens until a person or a workflow applies the trigger label. Output is a comment plus a structured label, and the comment can be suppressed so that the label alone drives project automation. Authentication is the workflow GITHUB_TOKEN with models: read, so no external key is needed.

GitHub's documentation describes the tool as "AI-powered issue intake" and tells the maintainer to "review the suggestions provided by the tool and take appropriate action" (GitHub n.d.-b). The design is a labeler: one prompt, one verdict, no retrieval of other issues, and no notion of how long the issue has waited.

actions/ai-inference is the generic primitive: an Action that sends a prompt to a GitHub Models endpoint and returns text (GitHub 2025a). GitHub's open source programs office published five recipes on top of it: duplicate detection (pelikhan/action-genai-issue-dedup), completeness checks, spam and slop detection, a "continuous resolver" for stale or already-fixed issues, and first-contributor onboarding (Wolf 2025).

The resolver is the only recipe that touches time, and it does so the way the stale bot does: a scheduled sweep that asks the model whether an old issue is still live. Age is a selection criterion for the sweep, not a feature the model weighs against a deadline.

GitHub Next's gh aw extension turns a Markdown file of instructions into a GitHub Actions workflow that runs a coding agent with scoped tools (GitHub 2026a). Issue triage is the introductory example and is described by its authors as "triage labelling of issues and pull requests and not much more" (GitHub Next 2026). The distinctive part is the permission model: the agent reads with a read-only token and writes only through declared safe outputs, for example "add one of these seven labels". Argo CD runs a variant that also closes duplicates (Argo CD project n.d.).

The coding agent sits downstream of triage: assignment to Copilot is the routing decision, made by a human (GitHub 2025c, 2025e). It matters to this survey because it changes what "route" means on a code host. The assignee field can now hold an agent, so a triager that routes can route to a machine. Linear made the same move with delegation (below).

Issue forms move triage work to the reporter: required fields, dropdowns and default labels replace a first-pass classifier (GitHub 2021). Organization-level issue types (GA April 2025) give every repository the same type field to classify into (GitHub 2025b). In June 2026 GitHub added duplicate suggestions in the creation form and let MCP clients read and write issue fields, so an external agent can file "fully triaged" issues with priority and dates already set (GitHub 2026b). The host supplies the schema; the clock, if any, is a date field that nothing on GitHub enforces.

The stale bot is the baseline that every LLM triager on GitHub should be compared to, because it is the only widely deployed GitHub automation whose decision is a function of elapsed time (GitHub n.d.-a). Its contract is inverted relative to a support SLA: the clock measures the reporter's and maintainers' silence, and expiry closes the item rather than escalating it. The Probot app that popularised the pattern is archived and points to the Action (Probot 2017).

GitLab's AI triage arrived in layers. Discussion summary and issue description generation are single prompts on one issue (GitLab n.d.-a). The Duo Agent Platform's Planner agent works over the backlog, applies prioritization frameworks, and edits labels and milestones after confirmation (GitLab n.d.-c). In July 2026 GitLab added a "work item created" trigger and published a two-agent flow that measures each team member's open-item load and assigns the new item to the least-loaded person with no human step (GitLab 2026). That flow routes on capacity, not on urgency or on the severity SLOs GitLab itself publishes (next entry).

GitLab is the one code host whose own engineering process states a time contract per severity and automates against it (GitLab n.d.-b). The gitlab-triage gem expresses policies as conditions plus actions, with date conditions such as "updated more than 5 days ago and unlabeled" (GitLab 2025). Weekly triage reports per product group, generated since 2019, include heatmaps of bugs that have missed their SLO (GitLab Bot 2019). The SLO is a rule input. As of this pass, no source connects it to Duo: the LLM agents in the previous entry neither read nor set the severity clock (unconfirmed for internal GitLab tooling).

Linear's engineering write-up describes two generations: a first version on GPT-4o mini and Gemini 2.0 Flash with "tightly scoped prompts and rigid workflows", then an agentic version on GPT-5 and Gemini 2.5 Pro that fetches extra context itself (Linear 2025b). Each suggestion carries a natural-language rationale, and teams can steer it with written guidance (Linear n.d.-c).

Linear also ships SLAs: deadlines applied by rule (defaults Urgent 24 hours, High 1 week), risk bands from low to breached, alerts 24 hours before breach, and an option to exclude non-working days (Linear n.d.-b). SLA rules key on priority and labels, which Triage Intelligence can set. So the coupling runs one way: the model's label or priority choice can start a clock, but no documentation says the model reads an SLA or its risk band when it suggests.

Linear treats agents as workspace members that can be mentioned, added to teams, and delegated issues (Linear 2025a). The delegation model is the distinctive part: the issue keeps a human assignee and gains an agent delegate, so accountability for the time contract stays with a person while the work moves to a machine (Linear n.d.-a).

Seer turns Sentry's triage into a two-stage gate. A cheap scan scores every new issue for actionability, meaning how likely a code change fixes it, and projects set a minimum score above which Seer starts an Issue Fix automatically (Sentry 2025). The automation stops at the point the project picks (Sentry n.d.-b). Separately, Sentry's issue priority combines log level with, on Business plans, the error message, handledness and past actions on similar issues; a volume surge "escalates" the issue and bumps priority unless a human has set it by hand (Sentry n.d.-a). Time enters only as event rate, not as a response deadline. The Sentry agent for Linear lets a Linear user delegate an issue to Seer (Sentry n.d.-c).

Dosu is the most widely deployed LLM triage bot in open source by its own count (16,000+ repositories, CNCF adoption) (Intel n.d.). Its documented technique is continual in-context learning: a webhook records every label a maintainer adds or removes after Dosu acts, and the correction becomes a retrievable few-shot example for later runs (LangChain 2024). The time contract appears only as a motivation (reporters waiting weeks for a reply) and as a monitored latency, never as a model input.

Probot (Node.js framework for GitHub Apps, 2017) carried the first wave of triage bots: stale, first-timers, and duplicate detection apps (Attard n.d.). Issue Label Bot, by Hamel Husain and Jeremy Lewi, was the first ML labeler offered as a hosted GitHub App, and Kubeflow retrained it on its own issues (Husain and Lewi 2019). Its end is a data point for the cost question: the owners shut it down because hosting inference for free did not pay. The abstain-when-uncertain rule is the same design later used by BugBug and VS Code.

KEP-1553 made "not yet triaged" an explicit state: every new issue gets needs-triage, and only a SIG member's /triage accepted removes it (Kubernetes SIG Contributor Experience 2020). The lifecycle robot then runs a 150-day inactivity contract that ends in closure (Kubernetes n.d.). It is a time-based SLA in practice, enforced on the project rather than on a vendor. The contract measures neglect of the item, not urgency, and the classifier (which SIG, which kind) is still a human with a slash command.

Triagebot is the counter-example: a large project that automated the plumbing of triage (labels, pings, review assignment, Zulip topics) and kept the judgement human (Rust project n.d.). Regression and soundness labels auto-add I-prioritize, which posts to a Zulip stream for the prioritization working group. The urgency signal is the label kind (regression-from-stable-to-stable, I-unsound); elapsed time plays no part.

VS Code ran one of the longest-lived ML issue classifiers in open source. The "deep classifier" assigned feature-area labels and owners when confidence cleared a per-category threshold, and a human on weekly inbox rotation caught the remainder (Microsoft 2020, n.d.-c). The time rules sit beside the model rather than inside it: needs more info closes after 7 days, and feature requests in Backlog Candidates close after 60 days unless they reach 20 upvotes (Microsoft n.d.-e). The 60-day/20-vote rule is a time contract with a demand signal attached, which no LLM system in this area reproduces. The repository was archived in November 2025; this pass found no public description of what replaced it.

BugBug answers one triage question per model: component, defect type, regression, spam, severity, and more (Mozilla n.d.-a). The component model moves a bug out of "Untriaged" only above 60% confidence; Mozilla reported more than 80% precision and contrasted it with roughly a week of manual routing (Castelluccio and Ledru 2019). BugBot, the rule engine formerly called autonag, applies the model and needinfos or emails triage owners when severity or priority is missing (Mozilla Release Management n.d.).

Mozilla is the strongest case in this area of a stated time contract sitting next to a classifier. The triage policy says new bugs are "fully triaged, or under active investigation, within one week", S1 and sec-critical bugs are assigned within 2 business days, and needinfo requests unanswered for 10 days need attention (Mozilla n.d.-b). The classifier shortens the first leg of that contract; the rules enforce the remaining legs. BugBug also ships a fixtime model that labels historical bugs by whether their time-to-fix fell above or below the median and learns to predict that class. This pass found no evidence that its output feeds routing or nags (unconfirmed).

IssueLens draws the line that Copilot coding agent does not: it triages and plans, and states that "planning approval does not implement changes" (Microsoft n.d.-d). Reports go to email or Teams, which moves the triage output to where maintainers already watch, rather than into labels alone.

Kilo's feature is representative of the 2025-2026 crop of hosted triage add-ons: retrieval for duplicates, a four-way classifier with a confidence score, and a review dashboard (Kilo n.d.). It is included for breadth; nothing distinguishes its handling of time.

Anvik, Hiew and Murphy framed triage as "who should fix this bug?" and learned a developer recommender from Eclipse and Firefox history (Anvik, Hiew, and Murphy 2006). DeepTriage replaced bag-of-words with an attention-based bidirectional RNN and released a benchmark of 383,104 Chromium, 314,388 Mozilla Core and 162,307 Firefox reports (Mani, Sankaran, and Aralikatte 2019). A 2023 comparison found DeBERTa the strongest fine-tuned transformer for developer and component assignment (Dipongkor and Moran 2023). The 2025 instruction-tuned LLM work reports a near-zero Top-1 on Mozilla next to 0.753 Hit@10, which restates the task as shortlist generation for a human (Kiashemshaki et al. 2025). Across two decades, the input is text plus history; creation time appears only as the split between training and test data.

Runeson, Alexandersson and Nyholm showed at Sony Ericsson that NLP retrieval finds about two thirds of duplicates (Runeson, Alexandersson, and Nyholm 2007). Sun et al.'s REP extended BM25F to weight both text and categorical fields, and it remains the baseline that LLM papers beat (Sun et al. 2011). Cupid keeps REP and uses ChatGPT only to extract the essential sentences of each report first, an early example of an LLM as a preprocessor rather than a decider (Zhang et al. 2024). GitHub's 2026 duplicate suggestions at filing time (GitHub Issues structure) are the product form of this line.

The NLBSE tool competition fixed a shared benchmark for the bug/feature/question split on GitHub issues (Kallis et al. 2022). Heo and Lee's 2025 replication found prompted GPT-4o only about one F1 point above GPT-3.5 and roughly level with the fine-tuned transformers (Heo and Lee 2025). That plateau near 0.87 F1 is the accuracy the GitHub and Kilo labelers inherit for the same three-way task.

SWE-bench turned "resolve this GitHub issue" into a benchmark of 2,294 tasks from 12 Python repositories (Jimenez et al. 2024). Localization, finding where the fix goes, became its own subtask: Agentless runs a fixed localize-repair-validate pipeline (Xia et al. 2024), LocAgent searches a heterogeneous code graph (Chen et al. 2025), and OrcaLoca adds priority scheduling and context pruning to the search (Yu, Zhang, et al. 2025). For triage, localization is a routing signal: the file a fix touches implies an owner. None of this work treats the issue's age or urgency as an input; the benchmark issues are already resolved.

Three generations, one decision set. Rule bots (Probot, Prow, triagebot, gitlab-triage, BugBot) handle state and time. Classifiers (Issue Label Bot, VS Code deep classifier, BugBug) handle route and type, with an abstain threshold (BugBug 60%, VS Code per category). LLM systems (GitHub labeler, gh-aw, Dosu, Linear, Duo, Seer, Kilo, IssueLens) add duplicate linking, rationale text and, for Seer and Copilot, a fix attempt. The decisions barely changed. What changed is that the output now carries an explanation and can include a pull request.

Where the clock is. On code hosts the time contract is mostly an inactivity rule, and it lives in the rule layer: stale at 60 days on GitHub's default, a 150-day stale-rotten-close chain on Kubernetes, 7 and 60 days on VS Code. Stated deadlines exist at Mozilla (triage within one week, S1 assigned in 2 business days), GitLab (S1-S4 fix SLOs of 30-120 days, with a missed-SLO label) and Linear (SLAs with risk bands and non-working-day exclusion). In every case found, the clock is enforced by rules next to the model, and no LLM triager reads it. The closest couplings are indirect: Linear's model sets the priority that starts an SLA, Sentry escalates on event rate, and BugBug trains a fix-time model whose deployment is unconfirmed.

Accountability for the clock stays human. Linear's delegation keeps a human assignee next to the agent; Copilot asks the assigning person for review; GitLab's assigner flow routes on workload alone. Agents get the work, people keep the deadline.

Open questions. Would a triager that saw "S2, 41 of 60 days elapsed" or "needs-more-info, day 6 of 7" make different decisions than one that sees only text? No surveyed product or paper tests this. The literature drops time entirely; the benchmarks (DeepTriage, NLBSE, SWE-bench) contain only resolved history. What replaced VS Code's classifier after November 2025, and whether GitLab's internal triage-ops consumes Duo output, are unconfirmed.

The guide (Anthropic n.d.-f) is the clearest case of the pattern this area keeps finding. Its "understand your current support approach" section asks "What criteria are used to determine what SLA/service offering is applied?", and the categories list includes "Emergency support: time-sensitive problems". The prompt template that follows takes a single f-string variable, ticket_contents, and returns intent and reasoning. No creation time, customer tier or SLA field enters the call.

The success-criteria list is the most complete in the area: classification consistency (95% or higher), adaptation within 50–100 samples, edge-case accuracy of at least 80%, routing accuracy of 90–95%, average assignment under 5 minutes, rerouting below 10%, escalation below 20%. These are targets the guide proposes. They are not measured results. Time-to-assignment is the only time metric, and it measures the router's latency, not the ticket's remaining SLA budget. The integration section offers push (webhook from Zendesk) or pull (scheduled poll), which is where a clock would enter if one were used.

The ticket-routing guide links here and cites "71% accuracy to 93%". The notebook as fetched on 2026-10-08 reports ~70%, then 94% with retrieval, then 97% with chain of thought (Anthropic n.d.-b). The two Anthropic pages disagree on the numbers. Both are vendor-reported on a vendor test set. The dataset has no timestamp column.

The parent note already treats this backend as its baseline; see 2. Two facts matter for this survey and are not stated there. First, it is the one vendor fixture in this area that hands the model the ticket's age: _serialize_ticket emits created_at as ISO-8601, and the generator back-dates tickets by up to 48 hours (Anthropic n.d.-d). Second, nothing consumes it. The reference determine_priority rule maps keywords ("locked out", "urgent") to urgent and billing to high, and there is no response target against which 48 hours would mean anything. The older customer_service_agent.ipynb is a chat bot with three tools (get_customer_info, get_order_details, cancel_order) and no queue.

This is the most complete vendor-operated triage system in the area, and it splits the work cleanly by clock. The LLM part is event-driven and clock-free: /triage-issue (Anthropic 2025c) reads the issue and its comments through a restricted gh.sh wrapper and may only add or remove labels from the existing list. It may not comment. Write, Edit, WebFetch and WebSearch are disallowed, and CLAUDE_CODE_SCRIPT_CAPS limits the label script to two calls per run. The prompt never mentions the issue's age.

The time contract lives in TypeScript that never calls a model. scripts/issue-lifecycle.ts is the "single source of truth" for five lifecycle labels and their timeouts (Anthropic 2026). sweep.ts runs at 10:00 and 22:00 UTC, marks issues stale after 14 days without update, and closes labelled issues once the label is older than its timeout. lifecycle-comment.ts posts the nudge with the deadline the moment a label lands. auto-close-duplicates.ts closes an issue three days after the dedupe comment unless the author objects. The model's one time-relevant act is choosing needs-repro or needs-info. That choice starts a seven-day clock it never sees. The prompt warns that "false positives are worse than missing labels" for exactly that reason.

The contract here is a closure deadline on the reporter, not a response deadline on the maintainer. No rule measures how long an issue waits for first maintainer contact. Compare the stale-bot baseline in the code-hosts area, 8.5.6.

The published examples (Anthropic 2025b) are the portable subset of the claude-code repository's setup: issue-triage.yml, issue-deduplication.yml, and an "Issue Auto-Triage and Labeling" recipe in docs/solutions.md. The recipe asks the model for a priority but gives it no timestamp and no schedule. The lifecycle sweep, which is what carries the clock in Anthropic's own repository, is not part of the published example. Adopters copy the classifier without the timer.

No Agent SDK example targets support tickets. The nearest is this email client (Anthropic 2025a). Triage lives in listeners such as boss-urgent-watcher.ts, which notifies at high priority when the subject contains "urgent" or "asap". The urgency signal is a keyword in the text, not the age of the message.

Anthropic's own customer support runs on a vendor product built on Claude, not on its cookbook patterns (Intercom n.d.-a). Segmenting by customer type (free versus enterprise) is the only routing input the case study names. It is the customer-type factor the ticket-routing guide lists and its example leaves out. Intercom's SLA features are covered with the CRM area. Whether they apply to Anthropic's queue is unconfirmed.

Swarm (OpenAI 2024b) and the "Orchestrating agents: routines and handoffs" notebook (OpenAI 2024a) fixed the meaning of "triage agent" for a generation of examples: a router whose only job is to pick the next agent. The triage_agent example has three agents and one instruction line. Triage in this sense is conversational routing, with no queue, no item metadata and no clock.

The demo (OpenAI 2025b) and the smaller examples/customer_service in the Agents SDK (OpenAI n.d.-b) carry Swarm's shape forward with typed context and guardrails. The context model has 13 fields. None is a timestamp for the conversation, a wait time, or a customer tier.

This is the most recent vendor support-agent cookbook in the area (OpenAI 2026) and the only one that splits work by latency tier: customer-facing work stays synchronous, follow-up work (QA, analytics tagging, routing audits) moves to Batch or flex processing. The deadline it optimises is the API's, not the customer's. The phrase "carrier SLA tables" appears once, inside INTERNAL_POLICY_APPENDIX, a block of filler repeated 45 times so the baseline prompt is oversized. In this cookbook the SLA is context bloat to be trimmed.

The cookbook has no notebook dedicated to support-ticket classification. As of 2026-10-08 the classification notebooks are Classification_using_embeddings, Zero-shot_classification_with_embeddings, Fine-tuned_classification, and two transaction-classification notebooks (OpenAI n.d.-a). They are recorded for completeness; none has an item with a creation time.

OpenAI described its support organisation in September 2025 (OpenAI 2025a). The post is a feedback loop: reps flag interactions as test cases and build classifiers. Presence productises the loop (Help Net Security 2026). Coverage of the launch reports no SLA, wait-time or priority mechanism. The openai.com page returned 403 to the fetcher, so the September post's details here come from secondary summaries and are unconfirmed.

No xAI example classifies or prioritises a queue. The closest is the refund agent with human approval (Zakariasson 2026), published three days before this survey. Its contribution is durable approval: the run stops before an irreversible tool call, survives a server restart, and resumes exactly once. The only clock is the 30-day refund window. It is a property of the order, and policy applies it without asking anyone. Grok Bot's support guide (xAI n.d.) advertises "connectors, triage jobs, and routines that keep tickets moving" but, as fetched, gives no fields, rules or metrics. An xAI page on internal tools describes a ticket helper with "severity classification" in search snippets; the page returned 403 and the claim is unconfirmed.

Google's equivalent of claude-code-action ships the triage pair as examples (Google 2025). The scheduled prompt defines priority/p1 as "a critical issue requiring immediate attention" and maps priority to keywords. gemini-cli's own gemini-scheduled-issue-triage.yml (Google n.d.-c) fetches open issues with --json number,title,body,labels. The field list omits createdAt and updatedAt. The model cannot tell a one-hour-old p1 from a one-month-old p1.

Neither Google repository has a ticket-triage notebook as of 2026-10-08. The Gemini cookbook offers Basic_Classification and Text_Classification (Google n.d.-b). The Vertex "customer support use case" (Google Cloud 2025a) is a furniture-shopping assistant. It answers questions and does not triage. Recorded as an absence.

Mistral's bank-inquiry prompt (Mistral AI 2024) is a textbook support-routing prompt, also taught in the DeepLearning.AI Mistral course. The Classifier Factory cookbooks (Mistral AI 2025) fine-tune intent and moderation classifiers. On 2026-09-07 they moved into a deprecated_cookbooks folder. The deprecation status of the Classifier Factory product itself is unconfirmed. The Agents API cookbook prd_linear_ticket creates Linear tickets from a PRD; it writes tickets rather than triaging them.

Cohere's tutorial (Cohere 2022) is the oldest vendor ticket-routing example in this area. It dates from September 2022, before the chat-model wave, and it is the same insurance-email shape that Anthropic's classification cookbook later used. On 31 January 2025 Cohere deprecated Classify with default embed models. Only fine-tuned models remain supported (Cohere 2025). The tutorial now sits in the docs archive.

This is LangChain's reference ambient agent (LangChain 2025a), built for the Interrupt 2025 workshop. The triage step is a three-way router whose output schema is reasoning plus classification. The evaluation file (LangChain 2025b) creates a LangSmith dataset named "Interrupt Workshop: E-mail Triage Dataset" and scores exact match on the triage label. A second set of LLM-judge evals grades the response agent's tool calls.

The time handling is the sharpest example of the area pattern. The input schema EmailData declares send_time. parse_email returns author, to, subject and thread and drops it, and triage_user_prompt has four variables, none temporal. The current date does appear: it is concatenated into the response agent's system prompt so that schedule_meeting gets the right day. The model knows today's date when it books a meeting, and does not know how long the email has waited when it decides whether to answer it.

The predecessor of agents-from-scratch (LangChain 2025c). It introduced "ambient agent" and the Agent Inbox as LangChain terms. It learns triage from corrections stored as few-shot examples. It has the same four inputs, and again none is temporal.

Every assistant prompt in this tutorial ends with "Current time: {time}.", bound with .partial(time=datetime.now) (LangChain n.d.). It is the one framework example found where the wall clock reaches every model call. It serves domain reasoning (is the flight in the past?), not a response target. The interrupt before sensitive tools is the human-approval pattern that the xAI refund agent later made durable.

Named "triage" by its authors (LlamaIndex 2025), this is the only example in the area that extracts a deadline from the item. The invoice schema has due_date. The workflow branches on document type and on amount (under 1000 accepted), and the due date ends up only in the LLM-drafted acknowledgement. GitHub code search over the run-llama organisation found no support-ticket triage example; a web search was not possible in this pass.

The crew (CrewAI 2025) defines three tasks, filter_emails, action_required_emails and draft_responses. The tasks.yaml in the same directory, as fetched on 2026-10-08, defines only send_followup_email, a recruiting task, so the example appears not to run as checked in. That is unverified by execution. The email record keeps a snippet, not the body, and no date. Time appears only as the one-day search window and the poll interval.

AutoGen's version of the OpenAI Swarm pattern (Microsoft n.d.-a). It is included because it is the framework's documented customer-support example. It is deprecated in practice: the repository README declares maintenance mode and points new users to Microsoft Agent Framework.

DSPy's tutorial (DSPy 2025) is a ReAct airline agent. It sits at the resolve end of the decision list. DSPy's distinctive offer, compiling a prompt against a labelled metric, would suit a triage classifier. A published DSPy triage example was not found.

Haystack has no ticket-triage cookbook found by repository search. The issue-resolver recipe (deepset 2025) works after triage: given an issue URL, it proposes a fix plan. Haystack's routing components (ConditionalRouter, LLMMessagesRouter, metadata routers) are building blocks a triage pipeline would use. None ships with a support example.

Twenty-five systems were surveyed. Three patterns hold across the area.

The timestamp is in the data model and out of the prompt. Anthropic's cookbook Ticket has created_at. agents-from-scratch's EmailData has send_time. The LlamaIndex invoice has due_date. The claude-code and gemini-cli workflows run against GitHub issues that carry createdAt and updatedAt. In every case the triage prompt omits the field, or receives it with no rule that uses it. The Anthropic tool_use fixture does pass created_at to the model, with no SLA to compare it against. The only example where the clock reaches every call is the LangGraph airline tutorial, and it uses the clock for flight logic. No example in this area computes time remaining against a target, or breach risk.

Where a time contract exists, it is in deterministic code beside the agent. Anthropic's own repository is the clearest case. The model chooses needs-info. A five-entry TypeScript table and a twice-daily sweep turn that choice into a seven-day deadline. The model never sees it. The xAI refund agent's 30-day window and the CrewAI one-day search window are of the same kind: a time rule, applied outside the model's judgement. A deterministic timer cannot hallucinate a deadline, which favours the split. It also means the published examples teach classification and leave out scheduling. claude-code-action's public examples ship the classifier without the sweep.

Vendor guides name the SLA and then drop it. Anthropic's ticket-routing guide lists "urgency, customer type, SLAs" as routing factors and asks how SLAs are assigned today. Its prompt takes one variable. Its only time metric, time-to-assignment under 5 minutes, measures the router. OpenAI's optimisation cookbook measures latency per run and moves non-urgent work to a 24-hour batch window. Its one mention of SLA is filler in a prompt to be trimmed. Where frameworks use the word "triage" (Swarm, Agents SDK, AutoGen, LangGraph), it means conversational routing, the choice of the next agent, not queue prioritisation.

Open questions for the synthesis pass:

• Does a measurable gain follow from passing age and SLA remaining into the triage prompt, or is a deterministic re-sort after classification enough? No example in this area runs the comparison.
• Anthropic's and Google's own repositories label priority but publish no accuracy or time-to-label metrics. Statsig logging in claude-code suggests the numbers exist internally.
• The two Anthropic accuracy figures for the same classification recipe (71%→93% in the guide, ~70%→94%→97% in the notebook) need reconciling.
• Presence and Fin are the vendors' production answers. Neither public account says whether the agent reads queue time or SLA policy.

The backend is the subject of the parent note (REPL-Driven Ticket Triage) and its empirical companion Compaction Against a Beads Backend. It wraps the beads tracker (Yegge n.d.) in two EDN tool definitions and a dispatch function, and drives them with a Clojure port of Anthropic's automatic-context-compaction cookbook (Anthropic n.d.-a). The baseline it replaces is the mock customer_service_api in the cookbook's tool_use/utils (Anthropic n.d.-c).

The ordering is (sort-by (juxt :priority :created_at)) in ready-queue, so age breaks ties within a priority bucket and does nothing else. The trimmed map handed to the model (:id :title :description :status :priority :issue_type :acceptance_criteria :dependencies) has no timestamp at all, so the agent cannot reason about age even if prompted to. The token numbers are from one run per arm and measure context management. No triage-quality or accuracy metric exists for this backend.

cinque-ports is the only project here built to answer the survey's question directly. A coordinator Claude Code session ran four, later ten, worker sessions, each building one triage option as a Ruby reference with a spec extracted from it. All ten score against the same language-neutral vectors and JSON schemas (ticket, proposal, verdict). The ADR scores the options on four scenarios (visibility into reasoning, bad input data, misclassification, offline grading) and seven concerns, and proposes a composite, explicitly "not a decision": a classifier as baseline and eval harness, Jira Service Management as system of record, Claude via MCP in propose-only mode as the reasoning layer. Refutation condition R2 says the LLM layer is unjustified for classification if the classifier alone meets the reassignment-rate target.

The time contract is the gap the project's own reviews found. The simulated CIO review lists "No SLA, support-hours, or incident-response evaluation for any option" as finding 5 and calls the gap uniform across all ten options. The simulated CPO review answers that SLA timers come with the system of record (options 6 and 9 have native timers), so the triage layer need not carry them. The specs agree with the CPO by construction. Build 03 MUST be deterministic and forbids any wall-clock read that is not already a field on the ticket. Build 01 uses created_at only to require that a duplicate candidate predate the subject. The only "clock" implemented anywhere is build 08's SessionClock, which models the 8-hour session ceiling of the vendor runtime, not a customer deadline. Build 04 ("local LLM worker") ran against a deterministic stub; real-model behaviour is marked [H], so no live LLM result exists. All accuracy numbers are on synthetic data the project generated, and two builds flag their own scores as corpus-invertibility or sighted-label artifacts.

The simulator (crowsnest-grind --mode itil4) exists to stress crowsnest's status coercion: ITIL states such as breached and on_hold are outside the receiver's {ok,error,unknown} enum and collapse to unknown. The crowsnest PBT grinder note records that loss. The crowsnest v3 spec then sketches the generalization to ITIL monitoring: a standing-state fold per monitored entity with sla : { window, breaches } as a derived aggregate. That is the closest any of our designs comes to computing an SLA. It remains a draft section marked for review against Datadog monitors, PagerDuty services and ServiceNow configuration items, with no implementation.

This is triage without a model. The labeller classifies a PR from its diff (standard is the complement of normal, which actions/labeler cannot express, so a shell step derives it), and guards read a Google Calendar change schedule at the moment of deploy. It is the one project here where time is an input to the decision. The input is a window (may this act now?), not a deadline (how long until this is late?). The scenarios document records the failure that motivated "at reliance": a PR carried itil:emergency from an earlier exercise, so classification must be re-confirmed when the change is activated. A triage label goes stale as the world moves, which is the SLA problem seen from the other side.

ChangeFlow exposes change triage as tools for an LLM client rather than embedding an LLM. The MTTR "SLA" in test/battle-test.scm is an output of a simulation (approval time plus a fixed 8-minute implementation time against a 15-minute target), not an input to scoring. The metrics tool is a stub. Two siblings in the same org are adjacent and also dormant: guile-pr2cr (2025-09-28) turns a GitHub PR plus its Jira ticket into an ITIL change-request document, and guile-deploy-ledger (2026-04-11) computes MTTR and lead time from deployment events with a 1,800-second MTTR alert threshold. Neither performs triage.

The annotation-systems spec describes the queue as "the queue the grind draws from". It is triage of claims, not tickets, and the routing decision is which verifier type a heading needs. Time appears as staleness: the spec requires second precision in VERIFIED_AT because minute precision broke the staleness sort. That gives an age, and the age orders the queue, but no rule says a verdict expires.

Several repos use beads as a shared work queue for agents. hydra-setup/bin/session-supervisor sends each tmux session "Check open beads with 'bd ready'". sage.el/bin/dx-swarm tells a swarm to close finished work, claim from bd ready, and file blockers at priority 0. The bd skill in aygp-dr/skills names bd stale, bd blocked and bd orphans as "Triage" and forbids an agent from bypassing the ready queue. Priority is set by whoever files the item. The only time signal is staleness, and it is a report, not a trigger.

The coordinator prompt pins its own date to 14 September 2024 and lists "Task Triage and Assignment" as one of six duties. Urgency is a word in the prompt, not a field. The queue stores created_at, assigned_at and completed_at, which would support time-in-queue measurement, but nothing reads them back into the decision.

The agentic research crawler note states C-003 as a falsifiable claim about triage metadata. The repo's conjecture-validation document argues against it from other tools: abstracts, venue and author are triage fields that the five-field schema omits. It is the only project here that treats "which metadata does triage need" as an experiment. Nothing has run the experiment yet.

The schema makes abstention a categorical route, not a low confidence score, because a route is a labelled event the review loop can later confirm or contradict. That is a design choice the survey's vendor systems rarely expose. An URGENT route implies a response-time contract, but the schema stops short of stating one. Its receivedAt field is modelled for re-identification risk, not for deadline arithmetic.

The skill is a classification procedure with no queue. It is the only triage-named procedure in the skills repo. Its question ("what did our contract fail to say?") is the same move cinque-ports makes with numbered clarifications. The other triage-named skills (code-search-triage, emacs-config-triage) choose tools and debug configs and are out of scope.

Atlassian Team '26 Europe (6 to 8 October) lists a hands-on "build your first Rovo triage agent" session (Tuesday 15:00, repeated Thursday 10:00) and a service-desk session on the customer-service side of the Teamwork Graph. Our note records titles and slots, not content. PyTorch Conference 2026 lists Meta's "Fighting Agents with Agents: Bringing Claude to PyTorch CI, triage, and PR review" for 20 October. EmTech AI lists a ServiceNow keynote on agentic workforces. The Boston AI Week note's 27 research-relevant picks contain no triage-specific session (searched 2026-10-08). Areas 02 and 04 cover these vendors directly.

Three patterns hold across our own work.

First, the clock is never an input to an agent's triage decision. The beads backend strips timestamps before the model sees a ticket. cinque-ports puts created_at on every ticket and uses it only to order duplicate candidates; its determinism rule forbids wall-clock reads. The crowsnest simulator's sla_breached is a coin flip. The annotation queue and bd stale compute age but only report it. The one decision that does read time, standard-change's freeze and window guard, is rule-based and asks "may this act now", not "how long until this is late".

Second, where an SLA is discussed, it is assigned to the system of record. The cinque-ports CPO review states this outright: SLA timers come with Jira Service Management or the OSS helpdesk, so the triage layer does not carry them. The CIO review counts the same fact as a gap uniform across all ten options. That disagreement is the open design question for this survey. Is breach risk a feature the triage agent should see, or a constraint enforced around it?

Third, evaluation is offline and synthetic. cinque-ports is the only project with accuracy numbers, and they come from a seeded synthetic corpus with self-reported caveats. No project here measures MTTA, time-in-triage or breach rate on real items, though cinque-ports lists time-in-triage among the telemetry its options would emit, and builder-workspace stores the timestamps that would allow it.

Open questions:

• Would adding created_at and an SLA target to the beads tool result change the agent's ordering, or only the explanation? The backend makes this a one-line select-keys change and a rerun.
• Can a cinque-ports vector express a time contract? The verdict schema has no field for "proposed escalation because breach is imminent". Adding one would be a G2 schema clarification.
• Does the standing-state SLA fold in crowsnest v3 belong to the triage agent's inputs or to the dashboard's outputs? The draft does not say.

Strands Decider (Brooker, Chambers, and Nonato de Paula 2026) is AWS's entry in a class its authors call decision models or "system one" models. The model cannot write text. It scores the options the request supplies, so label sets live in the request, not the weights, and every answer carries a probability. The launch example is triage. --state "Help! My payouts have been failing for 3 days!" with --choice "Which team should handle this?=billing,sales,retail" returns billing at 0.835 confidence, and the noul question "Does this convey urgency?" returns 0.875 (Strands Labs 2026).

The model fills a triage field; it has no notion of when. There is no timestamp, SLA or business-hours input. The three days of failure reach the model only because the customer typed them. Because several questions about one state cost little more than one ("the text is read once and each question adds only its own tokens"), a caller could add "Has this ticket waited past its first-response target?" as one more noul. The model would then be reading a computed fact as text. The repository warns that the README's v21 and v19 columns are "two single runs, not a measured gain", and that a difference under about 10 of 231 tasks is unresolved. That is the most careful self-description of any model in this area. No ticket-domain evaluation is published.

The Pydantic AI pages (Pydantic 2026a) are the fullest public account of putting a small decision model in front of an LLM for triage. The support-desk example maps each field of a Triage model to one question. A route the decision model cannot fill, such as Reply with its free-text field, raises UnfillableRoute and hands the whole step to the language model. Microsoft's Agent Framework ships a matching connector whose sample asks for department, frustration and is_urgent (Microsoft 2026b). The same interface runs local models through Ollama's /v1/systemone endpoint. The local example labels "Our checkout has returned 500 errors since 9am." as bug.

This entry states the time boundary most plainly of any source in the survey. A datetime is on the list of field types that fail before a request is sent. TypeSafe's published limits, as quoted in the Pydantic AI docs, say Jev "reads dates as text rather than as ordered quantities. Compute these in Python and ask Jev about the result" (Pydantic 2026b). The urgent field's BoolCriteria defines yes as "The customer is losing money or has a deadline today": a deadline the customer states, read from prose. The ticket's own age is not modelled. The design implies the split the model-vendors area found in Anthropic's lifecycle sweep. Code computes the clock, and the model judges text.

Both independent tests of this model class on tickets are negative. On the Tobi-Bueck queues, zero-shot Jev scored 0.5458 against a fine-tuned ModernBERT's 0.7294 and did not beat the 0.5946 majority-class baseline; see 8.8.6. Liquid's d1-3B, run locally on the same tickets, scored 0.5752 and did not beat it either (8.8.4).

Microsoft's entry in the decision-model class (Srivastava 2026) is the first of the decision models covered here to name incident response as a use. The claim in full: "Our on-call engineers use AI to retrieve relevant knowledge to respond to live incidents across logs, ticketing systems, calls, messages, and other data sources. Microsoft-Decision-1 performed better and faster than an LLM for knowledge retrieval." No number, baseline model or method is given. The shape is still readable. Retrieval with a decision model is scoring: each candidate passage from a log, ticket or call is asked "is this relevant to the incident?", and the probabilities rank them. That puts the model where a reranker sits, beside the incident triage line Microsoft Research has run since 2017 (8.3.13), and it says nothing about routing the incident itself.

The robustness figure answers the weakness this area found in Jev. Zero-shot Jev lost to the majority class on the Tobi-Bueck queues and was right 65% of the time at 0.98 confidence (8.8.6). Microsoft reports a 1.3% flip rate under perturbation, a measure of stability, not of calibration, and no calibration error. The comparison that would settle it, Decision-1 zero-shot against the fine-tuned ModernBERT on the same held-out tickets, has not been published.

Size bears on where it can run. The base is a 9B model; the open model nearest to it, autotrust/JEV-9B on the same Qwen3.5-9B base, is 18.4 GB at bf16 on the Hub (autotrust 2026), more than the whole memory of a 16 GB laptop; it would run there only quantised. With no weights released, Decision-1 runs only as a hosted API.

Two facts from OpenRouter's listing (OpenRouter 2026) bear on using it as an evaluation target. The weights "are updated continually while the API shape stays the same", so a score measured against it is a measurement of one week's model, and a regression can arrive with no version to pin. And its measured p50 through OpenRouter is 0.23 to 0.25 s end to end, about twice Decider's local median and two orders of magnitude above GitHub's encoder; the vendor's 35x is against a frontier LLM, not against a local classifier. In its first three days the listing shows about 469M prompt tokens against 1.85M completion tokens, the shape of a model that reads and does not write; one of the five public apps sending it the most traffic is a loan-event triage tool.

Liquid's d1 (Liquid AI 2026) is the decision model that fits on a laptop: the 4-bit file is under 2 GB, and a GGUF build means llama.cpp-family runtimes can load it. Its card names "routing and triage" and "reranking" first among its uses, the two jobs this area and Microsoft's incident claim are about, and its interface is the same three question types as Decider and Jev (noul, choice, score). The latency table carries the caveat that matters for tickets: one question costs 30 ms on an M5 Pro, but a 3.4k-token state costs 640 ms, so a long ticket thread, not the number of questions, sets the price. Several questions over one state are read in one pass (three questions, 41 ms). d1-omni is the more interesting of the two for this area. Its base is a 350M encoder, so it sits between OpsPilot's fine-tuned 149M ModernBERT and the 2B-to-9B decoder torsos of Decider, Jev and Decision-1: an encoder that takes its labels in the request rather than in its weights. Nobody has published its accuracy on tickets.

We ran d1-3B on the tickets OpsPilot used to test Jev: the 3,562-ticket validation split, the same seven-queue question copied word for word, the 4-bit file served by llama.cpp on a 16 GB M1 Pro. It did not close the gap.

d1 beats Jev by three points (exact McNemar p = 1.8e-6) and is better calibrated, but it does not clear the 0.5946 majority-class baseline, and it trails ModernBERT by fifteen points (p = 7.5e-74). The 3,563-ticket test split agrees: 0.5790 against ModernBERT's 0.7398 and a 0.5947 baseline, ECE 0.2010 against 0.0803. It sends 70% of tickets to the technical queue; recall on returns is 0.03, on human resources 0.09, and on the merged customer/general queue 0.13. The small queues and the merged one are where both zero-shot models fail, which is the curation effect OpsPilot reported. The median ticket took 750 ms at 515 input tokens; the card's 30 ms is one short question on newer hardware, and ticket length, not the question, set the cost here. ECE is computed one way for all three rows, on the top-1 probability, so Jev's figure differs from OpsPilot's 0.2896; d1's own confidence field is the top-two margin, not a probability. This is one quantisation and one wording; the card's figures are for bf16. The scripts and predictions are in experiments/d1-opspilot-queues in this site's repository.

The class is now large enough to need a filter. On 2026-10-09 the Hub gave decision models a decision-model tag, applied to GGUF uploads automatically from their llama.cpp metadata (Hugging Face 2026). Two days later the tag listed at least 1,000 repositories, 341 of them GGUF, most of them quantisations by third parties. The most downloaded were TypeSafe's JEV-27B-VL (1.54M) and GEV-26B-Decide, JEV-9B, a community decider-2b, and GLiNER2.5-Decide, which, like d1-omni, puts the decision interface on an encoder. No Microsoft repository carries the tag.

The only sample in strands-agents/samples named "triage" (Strands Agents 2026) is clinical. The industry folder has an SRE incident-response agent and a Jira scrum-master assistant, which belong with the incident and code-host areas. No Strands sample triages a support queue. The Decider is the Strands project's actual answer to ticket routing.

OpsPilot (Joshi 2026) is the strongest evidence found for and against the user's claim, from one author on one dataset. For: a 149M-parameter encoder routes queues at 74% with calibrated confidence. At a 0.80 threshold it auto-routes 62.5% of tickets at 85.0% accuracy, in 57 ms. Against: the largest gain in the table came from curation. Accuracy went from 0.5229 to 0.7313 when four overlapping queues were merged into two (10 to 7 classes). The author writes that "queue design mattered as much as architecture", and flags the 10-class split as unrecorded. Macro-F1 lags accuracy by 16 points because the majority queue carries the score.

The time contract is named as the missing input. Priority prediction scores 0.5240, and the README attributes it to the data: SLA and tier are not in the text. The dataset has no timestamp column, so the fix the author proposes (add ticket_type, tags, channel) cannot add age either. The same repository holds the paired comparison against Jev described above, on the 3,562-ticket validation split (ModernBERT's 0.7294 is its validation score; 0.7398 is test): McNemar p = 5.5e-91, and Jev's expected calibration error is 0.2896 against 0.0841. Where Jev reported 0.98 confidence it was right 65% of the time. Its saved predictions carry ticket ids, which is what let us score d1-3B on the identical tickets.

Not ticket triage, but the strongest production case for the fine-tuned encoder route in this area (GitHub 2026c). GitHub found LLM pipelines less precise for this decision. The labels are fixed, the decision runs on every push (a blocked secret "at least once every second"), and the budget is milliseconds. Those are the conditions under which OpsPilot's ModernBERT beat zero-shot Jev. A decision model asks for a different trade: labels per request, at Decider's median of 115 ms.

This is the one published three-arm comparison found between a fine-tuned small model and a large prompted model on ticket triage (Khan 2026). Fine-tuning on 1,414 synthetic tickets lifts category accuracy from 25.0% (zero-shot 3B) to 80.4%. That is 16.9 points above Llama 3.3 70B, with 100% valid JSON against 99.3%. The result splits by field. The 70B model is better on urgency (71.6% against 66.2%) and on sentiment (87.2% against 86.5%). Category is a filing convention the fine-tune learns from labels. Urgency is a judgement about consequences, where the larger model's general knowledge still wins.

The caveats are the author's own: the data is fully synthetic, the test set is drawn from the same generator, and the model card says ~155 test tickets where the README says 148. None of the 8 categories or the urgency field uses a timestamp.

A course assignment ("AICB-P2T3 Day 21, Track 3") produced a cluster of *-vi-ticket-triage-lora adapters on the Hub in one day. The best-documented one (licht666 2026) publishes the number most cards omit. It gains 0.205 field accuracy over a properly prompted base and fails its own regression gate. General knowledge drops 0.080 against a 0.020 tolerance, because all 225 training examples map ticket to JSON. The card calls this "textbook catastrophic forgetting". It also reports latency of 1,331 ms for the adapter against 991 ms for the prompted base. That a ticket-triage fine-tune is now a day-21 exercise says the technique is commodity. None of the cohort's schemas include time.

The Hub search for "ticket" returns dozens of fine-tunes, nearly all single-author and created in 2026. Three show the range. The qwen2.5-1.5b-ticket-classifier card (Singh 2026) reports 0% schema compliance for the base model and 95.6% after LoRA. Its cost table ("<$25 / month" against "$750 - $1,500" for a GPT-4o class API) is an estimate; nothing was measured. ticket-triage-qwen3-2b (dvr76 2026) extracts maintenance fields from tenant messages. Its example input carries its own clock ("from yesterday morning"). The output schema has urgency but no time field. adaptive-classifier/support-ticket (Sharma 2025) is a ModernBERT prototype classifier trained on 20 examples (5 per class). It is the smallest credible instance of the few-shot route, but publishes no accuracy. No SetFit ticket model with a published evaluation was found; one SetFit customer-support classifier exists with an empty card.

This is the distillation route on real enterprise tickets (staerkjoe 2026). The problem it names is taxonomy cold start: a newly introduced ServiceNow taxonomy with no labelled history. A frontier model labels; small models learn the labels. The headline number is agreement with the teacher, not accuracy against people, so the students inherit any teacher error. The 84% figure is fidelity to GPT-5, and the thesis reports no human gold set in the summary read. Macro-F1 near 65% again shows the long tail of small queues. Zero-shot students score about 0% on the proprietary taxonomy, which is the clearest statement in the area that the labels, not the model, carry the knowledge.

TickIt (Liu et al. 2025) is the industrial counterpoint to the small-model results. On a real escalation task, embedding classifiers trail an LLM with chain of thought by 2 to 5 F1 points, and fine-tuning the LLM on its own corrected reasoning adds 4 more. The decision here is escalation, which depends on the ticket's state as it evolves, not on its first message. That is closer to the time contract than queue routing is. The paper motivates escalation with SLAs and MTTR. The pages read do not show elapsed time as a feature, so its role is unconfirmed.

The hyperscalers sell distillation as a managed step, but none of the pages read uses support tickets as the worked example. Bedrock Model Distillation (Amazon Web Services 2024e) requires teacher and student from the same family. Its accuracy claim names RAG as the use case. AWS's Slemify sample (Amazon Web Services 2026a) is closer to triage. One YAML file declares the labels. Bedrock writes 1,200 synthetic pairs, which a person checks. A frozen encoder with a logistic head trains on CPU, and the report compares held-out accuracy against a majority-class baseline. Its diagram is the cascade pattern: confident answers from the small model, the rest to an LLM. AWS's own ticket versions are in the cloud area: 8.4.11 and 8.4.12. OpenAI's distillation and fine-tuning guides returned 403 to the fetcher and are unconfirmed here beyond the cookbook in the model-vendors area. No Vertex AI ticket-tuning recipe was found.

The general result predates the agent wave and has not reversed. Bucher and Martini (2024) compared ChatGPT and Claude Opus zero-shot with fine-tuned encoders across sentiment, stance and topic tasks. Fine-tuning won in every case (Bucher and Martini 2024). None of their tasks are tickets. SetFit (2022) is the few-shot route: contrastive fine-tuning of a sentence encoder, then a classification head, with no prompts (Tunstall et al. 2022). ModernBERT (2024) is the encoder most 2026 ticket projects start from (Warner et al. 2024).

On tickets specifically, the ITSM papers are sober. A centroid classifier on 8,968 tickets across 123 categories matches an SVM (hierarchical F1 0.731 against 0.727) and updates 152 times faster (Mohanna and Ait-Bachir 2025). It cites real-world BERT and XLNet F1 of 38–55% on IT tickets, and a negative correlation between model complexity and F1 below 10,000 examples. AutoML gives usable support-ticket classifiers without specialists (Truss and Boehm 2024). Uber's COTA (2018) already ranked thousands of ticket classes and suggested answers to agents, with "speed" in its title as the goal rather than as an input (Molino, Zheng, and Wang 2018).

Every structured-output library uses a support ticket as a showcase, and every one models priority as an enum inferred from text. The Outlines "Customer Support Triage" example (dottxt n.d.) is typical. A 3.8B-parameter Phi-3-mini fills ServiceTicket(priority, category, requires_manager, summary, action_items) under a grammar, so the output always parses. The deadline in the email (a presentation in an hour) is exactly the time contract. It reaches the model as prose and leaves as the token urgent. Instructor's auto-ticketer (567 Labs 2023) turns a meeting transcript into tickets with PriorityEnum and assignees. It creates tickets rather than triaging them.

The hosted APIs now constrain decoding natively. Claude's structured outputs use "constrained sampling with compiled grammar artifacts" (Anthropic n.d.-e). The supported JSON Schema features include enum and the date-time string format, but not minimum or maximum. A schema can therefore require a timestamp field, while a confidence or hours-remaining number cannot be range-checked by the grammar. Constrained decoding guarantees a well-formed priority. It says nothing about whether the priority accounts for time. Guidance has no ticket example; OpenAI's structured outputs and Agents SDK handoffs are in the model-vendors area.

The evidence on whether reasoning helps triage is mixed, and none of it measures the time contract. A meta-analysis of over 100 papers and 20 datasets found chain of thought helps mainly on math and logic, with "much smaller gains on other types of tasks" (Sprague et al. 2024). Deliberation can hurt: on tasks where thinking makes humans worse, o1-preview lost up to 36.3 points against GPT-4o (Liu et al. 2024). On tickets, two results point the other way. Anthropic's classification cookbook reports chain of thought as its best step, and TickIt's best configuration is SFT plus chain of thought (F1 0.862 against 0.819 for chain of thought alone).

On format, "Let Me Speak Freely?" reported that JSON constraints degrade reasoning (Tam et al. 2024). dottxt's replication attributes the drop to prompt differences, and notes the paper itself found structured generation better on several classification tasks (Kurt 2024). Latency is the cost side. The Vietnamese LoRA card measures 991–2,946 ms per ticket for a 4B generator. The Decider and OpsPilot report 57–153 ms for non-generating models. A reasoning model adds thinking tokens on top of the generator's figure. For a first-response clock measured in hours, either latency is negligible. For an interactive router it is not.

The datasets most small-model projects train on have no time column. That is the strongest finding in this area for the time contract. Tobi-Bueck/customer-support-tickets (Bück and Softoft 2025), the most-downloaded ticket set on the Hub and the source for OpsPilot, has 61,765 rows. Its columns are subject, body, answer, queue, priority, type, language, version and eight tags, with no timestamp. Its card promotes a synthetic ticket generator; whether these rows are synthetic is not stated, so unconfirmed. Bitext's 26,872 utterances (Bitext 2023) are "hybrid synthetic" and mark dates as slot placeholders ({{Date}}, {{Shipping Cut-off Time}}): time is a template variable with no value.

The clock existed and was dropped in one lineage. Kaggle's "Customer Support Ticket Dataset" (2023) lists First Response Time, Time to Resolution, Ticket Channel and Date of Purchase among 17 fields (suraj520 2023). A Hub derivative with the same 8,469 rows keeps six columns: email, product, type, subject, combined text and priority (gorkemsevinc 2023). The derivation is inferred from row count and column names. Every time field went in the conversion to a classification set.

Three sets keep time. The Mendeley "Help Desk Tickets" data (Abdellatif 2023) covers January 2007 to March 2023 at one software company: 66,691 issues with creation and resolution timestamps, total workflow time, and processing steps. Version 3 adds holidays_by_country.csv, the only business-calendar input found in any public ticket set. It defines no classification target. The synthetic KameronB/synthetic-it-callcenter-tickets (27,602 rows) has date, resolved_at, resolution_time and reassigned_count (KameronB 2025). Console-AI/IT-helpdesk-synthetic-tickets has createdAt, but its 500 rows were stamped within seconds of each other on 2024-10-28 (Console AI 2024). A generation timestamp that looks like a creation time is a trap for any model that learns from it.

The Support Integrity Auditor (arshit-0101 2026) is the one small-model pipeline found that uses time as a feature. It uses it to audit labels after resolution. Normalised resolution time is one of three signals that decide whether a ticket's recorded priority was wrong. Across 20,000 tickets (source unconfirmed), 28.9% were flagged. If that rate holds anywhere near real data, priority is the noisiest label a triage model learns from. A model trained on it learns the desk's habits, including its mistakes.

The other curation evidence points the same way. OpsPilot's 10-to-7 queue merge outweighed its architecture change, and its roadmap's first item is hand-labelling 50 disagreements to test whether "the 73% partly measures memorized convention". ModelForge (rubiatExe 2026) measures label noise directly but only on template-generated tickets, where 30% noise costs 4 points. Its frontier comparison was never run ("Requires paid API credentials"). For drift, the description-refinement method in arXiv 2508.00957 lets users add or redefine ticket categories in prose and reports small accuracy shifts on unseen classes, measured on AGNews and DBpedia rather than tickets (Rajeev et al. 2025). The centroid classifier's 152x faster incremental update is the same need met statistically. The production correction loop is Dosu's, in the code-host area: 8.5.12.

Synthetic tickets are the default eval set in this area. Almost every fine-tune above trains and tests on generated data. This repository (Mehmood 2026) is worth recording for two disclosures. First, labels are sampled before the ticket is written, and a human still rejected 9 of 50, an 18% label error in a generator designed to avoid it. Second, the generator is also one of the compared models, so "its phrasing is built into the data". The AWS cascade sample, the Bilingual adapter, the Vietnamese cohort and cinque-ports in our own projects all evaluate on corpora they generated. None of the generators emit a creation time, a business-hours window or a customer tier. The Nemotron cascade's tier field is the exception, and that sample forbids it from changing priority. A synthetic corpus could cheaply include the clock. None found does.

The board vendors put triage at the front of their agent pitches. Asana AI Studio's page lists "Prioritize and triage every request" and "Categorize, normalize, score, and apply SLA rules" (Asana n.d.). It is the only work-management product found that puts SLA rules in the same sentence as AI scoring. The page does not say whether the rule is an input to the model or a step after it. monday service advertises "Smart intake & triage" with "automatic categorization, summarization, and routing" (monday.com n.d.). Notion's Custom Agents (Notion 2026) name "Task Routing Agents" and a co-founder's agent that routes product feedback. Neither page mentions a deadline or an SLA.

Trello's AI pages did not load, so its triage features are unconfirmed. GitHub Projects has no triage agent of its own. Issue fields and Copilot assignment are in the code-host area. This is the genre the user describes: staff engineers demonstrating agents on a Kanban board. The board supplies the visual queue and due dates. The demos found route by content. The due date is a column on the board. None of these pages says the agent reads it.

Microsoft's Agent Framework, the successor that AutoGen's README points to, ships a six-agent CustomerSupport workflow (Microsoft 2026a). A TicketRoutingAgent picks one of seven teams through a RoutingResponse(TeamName: str) schema. The mock TicketItem has five fields and no time; send_notification is the escalation. Semantic Kernel's repository has no triage sample. The Foundry training lab built on these pieces is in the cloud area: 8.4.19.

Google's adk-samples repository triages its own issues with gemini-3.5-flash through the Antigravity CLI. The design note says "the model only DECIDES which labels apply" and has no GitHub token; CI validates the JSON against the real label set (Google 2026). The input is {number, title, body}, the same field list without createdAt that the model-vendors area found in gemini-cli. Mastra's customer-refund and security-incident-triage templates (Mastra 2026) are the most finished demos in this group. Both have a support dashboard, policy retrieval, and durable suspension at an approval step. Neither carries a response clock. smolagents has no triage or support sample. Pydantic AI's support desk is under 8.8.2.

Zello is a push-to-talk walkie-talkie app for frontline teams. Its AI features are a knowledge assistant, transcription, live translation, and "operational intelligence" mined from radio chatter (Zello n.d.). It has dispatch tooling but no ticket or queue triage. The name was probably misremembered. Given the Kanban framing, Trello is the likeliest intended product. Zendesk and Zoho Desk are covered in the CRM area.

The claim under test was that small, fine-tuned or reasoning models with structured output cover the core triage cases when the data is curated. The evidence splits it in two.

Category and queue routing: supported, with curation doing most of the work. A fine-tuned 3B model beat a prompted 70B model by 16.9 points on category. A 4B LoRA beat a hand-prompted base by 20.5 points. Two 8B students reached 84% agreement with GPT-5 on a real ServiceNow taxonomy at a twelfth of the cost. ModernBERT routes 62.5% of tickets at 85% accuracy in 57 ms. In each case the gain came from labels the model could not infer. OpsPilot's 10-to-7 queue merge moved accuracy by 21 points. Zero-shot students scored about 0% on a proprietary taxonomy. A zero-shot decision model lost to the majority-class baseline; the vendors' answer so far is stability figures (Microsoft-Decision-1: 1.3% of perturbations flip), not a ticket benchmark. The caveat is the evidence base. Nearly every result is single-author, single-run, and on synthetic data scored against labels from the same generator. One human check of such labels found 18% wrong. The only industrial paper, TickIt, found the LLM ahead of embedding classifiers by 2 to 5 F1 points, and further ahead after fine-tuning.

Priority and urgency: not supported, and the cause is missing inputs. OpsPilot's priority accuracy is 0.524, and its author names SLA and customer tier as the absent features. In the three-arm study the 70B model beat the fine-tune on urgency while losing on category. The Support Integrity Auditor flagged 28.9% of recorded priorities as inconsistent with how long tickets actually took. Priority is the field the time contract governs. It is the noisiest label and the one text alone cannot predict.

Where the clock is. In this area time reaches the model only as prose the customer wrote: "failing for 3 days", "since 9am", "3 hours ago", "a client presentation in an hour", "from yesterday morning", "it is getting very late". No small-model pipeline found passes ticket age, time to SLA breach, or business hours as a column. The decision-model interface makes the boundary explicit. A datetime field is refused, and the vendor advice is to compute dates in code and ask about the result. The datasets enforce the same boundary from below. The most-used sets have no timestamp, and one apparent derivative lacks the first-response and resolution times its Kaggle source lists. Only the Mendeley help-desk data carries creation, resolution and holiday calendars, and it defines no label. The one pipeline that does use time, the Support Integrity Auditor, uses resolution time after the fact to audit labels.

The demo genre. Board vendors (Asana, monday.com, Notion) and frameworks (Agent Framework, ADK, Mastra, Strands, Pydantic AI) all ship triage as the first example. Asana alone puts "apply SLA rules" next to AI scoring. The mechanism is unconfirmed. Every framework sample's ticket model lacks a timestamp, and the human step in each is approval of an action (a refund, a containment), not a check on the response deadline.

Open questions for the synthesis pass:

• Does adding hours_open, hours_to_breach and customer_tier as columns lift priority accuracy for a small classifier? The Mendeley data has the timestamps and holiday calendar to compute them; nobody has run it.
• Does a decision model asked "Has this ticket passed its first-response target?" over a computed fact add anything over the same comparison in code? The vendor guidance implies not.
• How much of the small-model category advantage survives a human-labelled test set? Only the CBS thesis and TickIt use real tickets, and neither compares against a frontier model on human gold.
• Microsoft-Decision-1 was "better and faster than an LLM" for incident knowledge retrieval. Against which LLM, on what measure, and does the same hold for routing the incident rather than retrieving for it?
• Asana AI Studio's "apply SLA rules" needs a primary source: is the SLA a model input, a post-classification rule, or a field the workflow sets?