Works · Orchestration of Work Tasks, Tickets, and Deliverables

1. Introduction

1.1. Background

Work tickets, work items, and tasks are the smallest granularity carriers of enterprise operations: an incident report, an expense claim, a customer request, or a change request is all modeled as a ticket that has a state, an owner, and a deadline.

Traditional ticket systems face three long-unresolved problems:

1. Classification and routing rely on manual experience: the same kind of issue gets assigned to different teams, causing repeated re-assignment.
2. Filling in missing information depends on back-and-forth follow-ups: fields are incomplete when the ticket is created, so the handler must communicate back and forth multiple times.
3. Process knowledge is not accumulated: the next time the same kind of issue is solved, it still starts from scratch.

AI's point of intervention falls exactly on these three: automatic classification and routing, automatic summarization and solution generation, and automatic information elicitation. But introducing AI immediately raises a new engineering problem — the ticket is no longer a mere form flow, but becomes a state machine with model calls, and the model's non-determinism propagates into SLA, audit, and accountability.

What the Works direction focuses on is precisely how to engineer this "state machine with model calls".

1.2. Definition

Works (work-task and ticket orchestration): engineering activities that, taking work items (tickets/tasks/deliverables) as objects, model, automate, and measure their full life cycle of creation, classification, routing, assignment, handling, elicitation, resolution, confirmation, closure, and retrospective.

A complete Works system should include five elements:

1.3. Positioning in the AI Harness System

图 1-1｜Works 在 Harness 六层能力模型中的定位

数据来源：基于本文分析绘制的示意图。

Works's position in the Harness six-layer capability model is: primary layer L3 orchestration and control, secondary layer L5 evaluation and observation (this mapping is the analysis of this article).

Bottleneck layer: the bottleneck of Works lies at the boundary between L3 and L5.

• On the L3 side, ticket flow is not purely technical orchestration but a semi-structured process mixing event-driven + human decision, which is precisely the part that generic workflow engines are least good at;
• On the L5 side, the definitions of metrics such as deflection rate are not unified, so values computed by different organizations and different tools cannot be compared directly, making effects impossible to verify horizontally.

Value: Works is the key step for AI Harness to move from "answering questions" to "completing work" — it connects model output to the organization's real operational workflows.

Boundary with adjacent directions:

• With 06-workflow.md: Works is Workflow concretized in the "ticket/work-item" domain; Workflow orchestrates services and tasks, while Works orchestrates business objects with owners and deadlines.
• With 07-bpm.md: ticket flow is essentially Case Management, which can map directly to CMMN 1.1's case / plan item / sentry semantics.

2. Glossary

3. Case Studies

3.1. ServiceNow Now on Now: Self-Deploying an AI Ticket Assistant

3.1.1. Background

ServiceNow deployed Now Assist with itself as the first customer ("Now on Now"), embedding AI capabilities into its own IT and employee-service flows. Its motives are twofold: first, to verify the product's effectiveness in a real large-scale environment; second, to make itself a repeatable deployment blueprint.

3.1.2. Approach

According to the ServiceNow official case page, its deployment covers multiple ticket scenarios:

• Automatic generation of resolution notes;
• Employee self-service and case deflection;
• Now Assist in Creator for developer-side productivity;
• A 120-day measurement cycle, with benefits reviewed quarterly.

3.1.3. Results

According to the ServiceNow official case page (vendor's own statement):

There is also third-party-reported internal portal data: achieving a 54% deflection rate on the "Report an Issue" form; AI search delivering nearly 20% case avoidance; roughly 45 minutes saved on average per deflected ticket. This set of data is secondhand and its official source page was not found; citations must be marked [To be verified].

3.2. Orica: Raising Deflection Rate from 18% to 94% in Six Weeks

3.2.1. Background

Orica is an Australian provider of industrial explosives and blasting services, with a large and varied volume of IT and employee-service requests. Its traditional ticket entry points required manual classification and response, making response speed the bottleneck.

3.2.2. Approach

According to the ServiceNow official blog (2025 AI Pacesetter), Orica adopted a phased fast-launch strategy:

• First 6 weeks: launched incident summarization, solution-note generation, and AI search;
• Weeks 7–8: launched the Virtual Agent as a self-service entry point.

This order of "doing back-office enhancement first, then front-office deflection" is a path worth learning from in ticket-class AI adoption: first accelerate the manual processing stage, then use the self-service entry to cut traffic.

3.2.3. Results

According to the ServiceNow official blog: Orica's deflection rate rose from 18% to 94%.

The same source also gives two other cases:

• Lloyds Banking Group: Now Assist for HR Service Delivery deflects roughly 90% of employee issues; took about 5.5 months and coordinated 100+ ServiceNow resources to build the unified entry point Prosper.
• (In the same batch of cases) Canada Life and Teleperformance data appear in 3.3 and the table below.

3.3. Canada Life: Compressing Catalog Development from Months to Days

3.3.1. Background

The Service Catalog is the backbone of employee self-service, but developing catalog items has long relied on manual research and writing; an item can take months from proposal to launch.

3.3.2. Approach

According to the ServiceNow official blog, Canada Life uses Now Assist to support the development and maintenance of its service catalog, shifting the creation of catalog items from purely manual writing to "AI drafting + human confirmation".

3.3.3. Results

According to the ServiceNow official blog:

Cross-case metric reference (Teleperformance, ServiceNow official case PDF):

Summary of deflection-rate observation range (analysis of this article): publicly verifiable deflection-rate observations in this direction range from 10% (Teleperformance) to 54% (ServiceNow's own case, secondhand) to 94% (Orica Virtual Agent). The range spans widely, showing that the deflection rate depends heavily on scenario baseline and definition and cannot be compared directly across organizations.

4. Practice Standards

4.1. AGENTS.md Specification

The following is the complete, copy-paste-ready industry-standard AGENTS.md original text for the Works direction, reflecting the dedicated toolchain of ticket systems, state machines, SLA timing, elicitation, CMMN case semantics, and metric definitions.

# AGENTS.md —— Works（工作任务、工单与产出物编排）

## 角色与边界
- 你是工单/工作项处理智能体，负责分类、路由、摘要、解决方案生成、信息补齐与闭环建议。
- 你可以：读取工单与历史相似案例、生成分类与优先级建议、生成摘要与解决方案草稿、
  发起信息补齐请求、生成复盘报告、调用白名单内的查询与只读工具。
- 你不可以：自行关闭工单、自行对外发送回复、自行变更 SLA 承诺、自行提升权限、
  自行修改审批结果、把未审阅的 AI 生成内容直接写入知识库。
- 判定原则：对客户/员工可见的动作、产生承诺的动作、不可逆的动作，默认需人工确认。

## 环境假设
- 运行环境提供：工单系统读写 API、工单状态机定义、SLA 计时服务、相似案例检索、
  知识库（解决方案库）、信息补齐通道（elicitation）、审计日志与 Trace。
- 工单状态机的合法转移已被平台强制校验，非法转移会被拒绝。
- 每个工单具备唯一 ID 与完整的历史轨迹，可回放。
- 运行环境支持长周期计时（timer）与人工等待（signal）。

## 上下文加载顺序（Context Budget）
1. 工单本体：ID、类型、优先级、SLA 剩余时间、当前状态、请求人描述（常驻，不压缩）
2. 历史轨迹：状态变更记录、既往沟通、已尝试方案
3. 相似案例检索结果（混合召回 + 权限过滤 + 重排，附 case_id + 版本 + 定位）
4. 解决方案库与知识库片段
5. 执行人/团队上下文（技能、负载、在办工单数）
6. 参考模板与话术（按需加载）

## 工具契约
- 工单系统：读全量；写仅限草稿字段、内部备注、建议字段；状态转移须走平台校验。
- 相似案例检索：必须带调用者身份，结果已过权限过滤；返回 Top-K 与相似度分。
- 信息补齐（elicitation）：信息不全时主动发起，一次性问清，避免多轮往返。
- 计时与提醒：读取 SLA 剩余时间；到期前触发提醒，不得静默超时。
- 脚本工具：统计、格式转换、批量分类、跑分必须调用 scripts/，不得用生成方式替代。
- 度量工具：分流率、SLA、CSAT、重开率、自动化率的口径由本文件统一定义，不得自定义。

## 任务执行流程（SOP）
1. 接单：解析工单内容，判断类型与紧急度；信息不全立即发起信息补齐。
2. 检索：召回相似历史工单与解决方案，权限过滤后重排。
3. 分类：输出类型/优先级/归属团队建议，并给出判定依据（可解释）。
4. 生成：产出摘要与解决方案草稿，逐条挂载来源（case_id / KB 条目 + 版本）。
5. 自检：事实一致性、引用完整性、密级、是否含对外承诺性表述。
6. 分派：按技能与负载建议执行人，提交人工确认。
7. 闭环：处理完成后生成解决记录草稿，交人工确认后写入工单。
8. 复盘：周期性输出分类准确率、分流率、重开率、SLA 达成率报告。

## 度量口径定义（强制统一）
- 分流率 = 无人工介入即完成或自助解决的请求数 / 进入该渠道的请求总数。
  必须同时披露分母定义（是否含重复请求、是否含机器人流量）。
- 自动化率（Touchless Rate）= 全流程无人工干预完成的工单数 / 工单总数。
- SLA 达成率 = 在承诺时限内解决的工单数 / 应受 SLA 约束的工单总数。
- 重开率 = 关闭后 N 日内被重开的工单数 / 已关闭工单数（N 需固定）。
- 分流率与自动化率不得混用；对外披露时必须标注口径与统计窗口。

## 验证与证据要求
- 每条建议必须可解释：输出分类依据、命中的相似案例、相似度分。
- 每条事实性内容必须附来源标识（case_id / KB 条目 + 版本 + 定位）。
- 解决记录草稿须包含：问题现象、根因（若可判定）、处理步骤、验证方式、遗留风险。
- 证据包：来源清单、检索记录、自检表、变更日志、SLA 状态快照。

## 失败与升级策略
| 失败 | 处置 |
|---|---|
| 信息不足且补齐无响应 | 挂起并计时，到期按既定路径升级；不得猜测补全 |
| 相似案例零命中 | 输出"未检索到相似案例"，转人工；禁止用通用知识生成解决方案 |
| 分类置信度低于阈值 | 输出候选分类及分值，转人工判定 |
| SLA 即将超时 | 立即升级并标记，优先于其他优化动作 |
| 工单被重开 | 触发复盘，把该案例加入评测负样本 |
- 每个循环必须有步数上限与 Token 预算上限；超限即停并升级。

## 安全与合规红线
- 不得自行关闭工单或对外发送回复。
- 不得变更 SLA 承诺或篡改计时数据。
- 不得用高权限账号绕过工单权限读取他人数据。
- 不得把客户个人信息写入公开的相似案例库。
- 不得删除或篡改工单历史轨迹与审计日志。

## 禁止事项
- 禁止编造 case_id、KB 编号、处理步骤、时间线。
- 禁止在无相似案例支撑时输出解决方案。
- 禁止使用 XX / XXX / ___ 等非标准占位符（统一用 [待填写] / [待核实]）。
- 禁止把分流率与自动化率混用或自定义口径对外披露。
- 禁止用 emoji 与署名。

## 输出格式
- 分类结果：类型 / 优先级 / 归属团队 / 置信度 / 判定依据 / 命中的相似案例。
- 解决方案草稿：现象 / 根因 / 步骤 / 验证 / 遗留风险，每节挂来源标识。
- 复盘报告：口径定义 + 统计窗口 + 指标值 + 环比 + 归因说明。
- 数值带单位；范围用 ~ 连接；中文全角标点；中英文之间加空格。

## 评估与自检
- 九项自检：来源可回溯 / 无无源断言 / 数值一致 / 无非标占位符 / 数量与表格一致 /
  编号可核实 / 密级正确 / 人工确认节点齐备 / 信息缺口已声明。
- 每周复核分类准确率与重开率；指标回退视为缺陷并触发复盘。
- 失败用例与人工修正必须回流进评测集。

4.2. SKILL.md Specification

The following is the complete, copy-paste-ready industry-standard SKILL.md original text for the Works direction.

---
name: work-item-triage
description: 工单与工作项的分类路由、相似案例检索、解决方案草稿生成、信息补齐与闭环复盘。当用户要求"处理这张工单""给这个请求分类""生成解决方案说明""总结事件经过""统计分流率或 SLA"时触发。
version: 1.0
created: 2026-09-12
---

# 工单处理与分流（Work Item Triage）

## 适用场景
- 新工单入库时的分类、优先级判定与路由建议。
- 历史事件工单的摘要生成与解决方案说明生成。
- 信息不全时向请求人发起信息补齐。
- 周期性产出分流率、SLA 达成率、重开率、自动化率复盘报告。

## 前置条件
- 已加载本方向 AGENTS.md，且工单状态机定义可用。
- 已获得工单系统与知识库的访问权限（含权限过滤）。
- 已知 SLA 计时状态与优先级规则。
- 已确定度量口径与统计窗口。

## 输入
- 工单 ID 或工单内容（描述、附件、请求人、渠道）
- 可选：目标类型体系（分类树）、优先级规则、归属团队清单
- 可选：统计窗口与度量口径（默认使用 AGENTS.md 中定义）

## 输出
- 分类结果：类型 / 优先级 / 归属团队 / 置信度 / 判定依据 / 命中的相似案例
- 解决方案草稿：现象 / 根因 / 步骤 / 验证 / 遗留风险（每条挂来源标识）
- 信息补齐请求（如需要）：缺失字段清单 + 一次性提问话术
- 复盘报告（如需要）：口径定义 + 统计窗口 + 指标值 + 环比 + 归因

## 执行步骤
1. 解析工单，提取实体（系统、模块、错误码、时间、影响范围）。
2. 检查必填字段；缺失则发起信息补齐，一次性问清。
3. 检索相似历史工单与解决方案：向量 + BM25 → 权限过滤 → RRF 融合 → 重排 → Top-K。
4. 输出分类与优先级建议，附置信度与判定依据；低置信度转人工。
5. 生成摘要与解决方案草稿，逐条挂载来源（case_id / KB 条目 + 版本 + 定位）。
6. 自检：事实一致性、引用完整性、密级、是否含对外承诺性表述。
7. 提交人工确认后写入工单内部字段；闭环时生成解决记录草稿。
8. 周期性跑度量脚本（scripts/）产出复盘报告。

## 质量标准（DoD）
- 分类建议必须可解释（有判定依据与命中案例）。
- 事实性内容 100% 附来源标识且可回溯。
- 相似案例零命中时输出"未检索到相似案例"，不生成臆测方案。
- 度量口径与 AGENTS.md 定义完全一致，且披露统计窗口与分母定义。
- 所有对客户/员工可见内容均经人工确认。

## 常见失败与处理
| 失败 | 根因 | 处置 |
|---|---|---|
| 分类漂移 | 分类树变更未同步 | 同步分类树版本，重跑分类评测集 |
| 相似案例零命中 | 切分或嵌入不匹配、历史数据未入库 | 检查索引版本；仍无命中则转人工 |
| 解决记录与实际不符 | 生成脱离工单轨迹 | 提高忠实度阈值；回退上一策略版本 |
| 补齐请求反复 | 提问不聚焦 | 一次性列出全部缺失字段，限定一次往返 |
| 分流率虚高 | 分母口径被缩小 | 按 AGENTS.md 统一口径重算并披露窗口 |
| SLA 静默超时 | 无计时告警 | 接入计时服务，到期前强制升级 |

## 示例
用户请求：处理工单 INC-20260912-0043，用户报告无法登录 VPN。
执行：
1. 解析：系统 = VPN，现象 = 登录失败，影响范围 = 单用户，时间 = 今日 09:12。
2. 必填字段检查：缺少"客户端版本"与"错误码" → 一次性发起补齐请求。
3. 检索：召回 5 条相似历史工单（含 case_id 与相似度分），其中 3 条为证书过期。
4. 分类：类型 = 网络接入，优先级 = P3，归属 = IT 网络组，置信度 0.82，依据 = 命中 3 条同因案例。
5. 生成方案草稿：含排查步骤（检查证书有效期 → 重新签发 → 客户端重连）与验证方式。
6. 自检：步骤与历史案例一致；无对外承诺性表述；密级 = 内部。
7. 提交人工确认后写入内部备注；不直接回复用户、不直接关闭工单。
约束：若相似案例为零，输出"未检索到相似案例，建议转人工"，禁止凭通用网络常识生成方案。

4.3. Deployment Checklist

5. Summary

Works is the direction in the knowledge-collaboration group closest to business outcomes: its output is not a document but a problem that is either solved or unsolved. The engineering essentials of this direction can be summarized in four points:

1. The state machine is the skeleton; the model is the augmentation. First model the ticket life cycle as a platform-force-checked state machine, then let the model participate in classification, summarization, and solution generation; reversing this order leads to loss of control over SLA and accountability.
2. The deflection rate is the most important and the most easily abused metric. Publicly verifiable observation ranges go from 10% (Teleperformance) to 94% (Orica), a huge span; external disclosure must give both the denominator definition and the statistics window, otherwise it is incomparable and untrustworthy.
3. Elicitation should be a first-class capability. MCP 2025-06-18 introduced elicitation, making "requesting supplementary information during interaction" a protocol-level capability; in engineering, ask everything in one round to avoid consuming user patience with multiple round-trips.
4. Case Management semantics fit better than BPMN. Ticket flow is often not a predefined, repeatable process but depends on ad hoc decisions by knowledge workers, which is precisely the applicable domain of CMMN 1.1 ("activities that are not so predefined and repeatable, but instead depend on evolving circumstances and ad hoc decisions by knowledge workers").

It should be noted that Works is one of the directions most severely lacking in standards: there is still no public international standard or industry baseline for AI ticket orchestration, and there is no public specification for deliverable (Artifact) version management. Therefore quality assurance in this direction can only rely on an organization's internal evaluation sets and definition conventions.

Information Gap Statement

6. References

1. Now on Now: Now Assist — ServiceNow official case page. https://www.servicenow.com/it/customers/now-on-now-now-assist.html
2. 5 Lessons from AI Award Winners — ServiceNow official blog (2025 AI Pacesetter). https://servicenow.com/blogs/2025/5-lessons-ai-award-winners
3. Teleperformance Case Study — ServiceNow official case PDF. https://www.servicenow.com/content/dam/servicenow-assets/public/en-us/doc-type/resource-center/case-study/cs-tp.pdf
4. ServiceNow FY2025 Q3 Earnings Call — The Globe and Mail (statement by Bill McDermott). https://www.theglobeandmail.com/investing/markets/stocks/NOW/pressreleases/35791955/
5. Building Effective Agents — Anthropic Research. https://www.anthropic.com/research/building-effective-agents
6. Model Context Protocol Specification Changelog — MCP (introduced elicitation on 2025-06-18). https://modelcontextprotocol.io/specification/2025-06-18/changelog
7. CMMN 1.1 — Object Management Group. https://www.omg.org/spec/CMMN/1.1/About-CMMN
8. Scaling Renewals Engine with Temporal Workflows — Coalition engineering blog. https://www.coalitioninc.com/fr-ca/blog/broker-education/scaling-renewals-engine-temporal-workflows
9. Microsoft 365 Copilot Experiment: Cross-Government Findings Report — GOV.UK. https://www.gov.uk/government/publications/microsoft-365-copilot-experiment-cross-government-findings-report/microsoft-365-copilot-experiment-cross-government-findings-report-html
10. Temporal — Durable Execution official site. https://temporal.io/