Retaintive

    AI Agent Foundation 最终态与当前缺口

    Superseded / Historical（2026-07-15）：本文包含已漂移的 live-table 和 Objective-first 假设，不再作为当前/最终态 source of truth。Task runtime、read tools、bounded reasoning loop 与 authority 以 Task System Design 为准；其他 AI foundation 能力实施前必须重新 code-audit。

    0. 一句话判断

    retaintive 现在已经有一部分 AI foundation：contacts-analyzer、production prompt、Zod schema、Task Orchestrator、Policy Guard、tasks/progress/suggestions/playbooks 表都在。Task Accuracy Baseline v1 也已经有第一版 executable foundation：57 个 golden eval scenario、11 个 DB replay case、以及 Task Detail 里的 task progress timeline。

    但它还不是完整的自动 AI employee foundation。现在缺的是：

    • investor demo 用的稳定 demo pack 和 operator guide。
    • voicemail / firm rejection 等 known gap hardening。
    • unable_to_reach threshold 的 deterministic writer policy。
    • task objective / issue 抽象层。
    • approval queue。
    • agent execution log。
    • LLM Gateway / usage metering。
    • Vapi / outbound execution 接入。
    • feedback loop 真正回流到 prompt/context/playbook。

    所以 demo 前的正确目标不是“把终态全做完”，而是先做 Task Accuracy Foundation：证明 AI 能稳定决定任务，并且写库安全。

    1. 现在我们有什么

    当前态：我们已经有一条 task intelligence pipeline

┌────────────────────────────────────────────┐
│ 1. 业务事实 Facts                           │
│                                            │
│ contacts / calls / messages / leads        │
│ tasks / task_progress_events               │
│ task_suggestions / task_playbooks           │
│ contact_timeline                            │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 2. AI 判断入口                              │
│                                            │
│ contacts-analyzer                           │
│ production prompt                           │
│ ContactsAnalysisSchema                      │
│ taskDecisions[]                             │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 3. 写库安全层                               │
│                                            │
│ resolve taskRef T1/T2                       │
│ writeAnalysisWithTasks()                    │
│ applyTaskAction()                           │
│ Policy Guard                                │
│ DB constraints                              │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 4. 产品表面                                 │
│                                            │
│ Studio UI tasks                             │
│ suggestions                                 │
│ playbook tab                                │
│ timeline / audit pieces                     │
└────────────────────────────────────────────┘

    当前已经不错的部分：

    Layer当前状态评价
    Task SSoTtasks 已是行动项主表可用
    Task state machineopen / closed + create_open / create_closed / close / update / record_progress / reopen可用，但 eval 不够
    Policy GuardDNC、duplicate、store-match、type allowlist、confidence、stale proposal 等方向对
    Progress eventstask_progress_events 拆出 process facts方向对
    Suggestionstask_suggestions append-only已为 feedback / provenance 留口
    Playbookstask_playbooks current/stale/superseded可作为未来 agent context
    Golden eval已有真实模型 eval runner需要扩容

    2. 现在还缺什么

    缺口为什么重要Demo 前 / Demo 后
    Scenario registry没有系统化 expected decision，无法判断 prompt 准不准Demo 前
    Golden eval coverage现有 case 太少，不能证明稳定性Demo 前
    DB replay harnessgolden eval 不验证 writer / policy / constraintsDemo 前选 8-12 个
    Known gap tracking不稳定 case 不能混进 demoDemo 前
    Objective layertypeCategory 偏健身房语义，跨行业不够抽象Demo 后
    Approval queueAI 外呼 / 发消息前必须有人审Demo 后
    Agent execution logVapi agent 做了什么需要审计、回放、归因Demo 后
    LLM Gateway模型路由、降级、缓存、cost attribution 需要统一出口Demo 后
    Usage metering未来 package + usage 收费必须 per-client 计量Demo 后
    Feedback loop历史对话 / staff reaction / close outcome 还没系统喂回 AI contextDemo 后

    3. Task Accuracy Foundation 是什么

    Task Accuracy Foundation 是“自动执行之前的地基”。它不是一个 UI，也不是一个 prompt 文件，而是一套可回归的验证系统：

    Task Accuracy Foundation 最终态

┌────────────────────────────────────────────┐
│ Scenario Registry                           │
│                                            │
│ 中文业务场景                                 │
│ structured input context                    │
│ structured expected decision                │
│ sourceOfRule / knownGap / priority          │
└───────────────┬────────────────────────────┘
                │
                ├───────────────────────────────────────┐
                │                                       │
                ▼                                       ▼
┌──────────────────────────────┐        ┌──────────────────────────────┐
│ Golden Eval                   │        │ DB Replay                     │
│                              │        │                              │
│ production prompt             │        │ seed processed rows            │
│ production Zod schema         │        │ run writer / Policy Guard      │
│ real model                    │        │ assert persisted rows          │
└───────────────┬──────────────┘        └───────────────┬──────────────┘
                │                                       │
                └───────────────────┬───────────────────┘
                                    ▼
┌────────────────────────────────────────────┐
│ Verdict                                    │
│                                            │
│ pass: demo candidate                        │
│ fail: fix prompt / policy / schema          │
│ xfail: known gap, record GitHub issue       │
└───────────────┬────────────────────────────┘
                │
                ▼
┌────────────────────────────────────────────┐
│ Demo Pack                                  │
│                                            │
│ 只展示连续稳定通过的 case                    │
│ 不现场赌模型随机性                           │
└────────────────────────────────────────────┘

    做完以后，团队应该可以回答：

    • 这个 scenario 为什么应该 create_open，不是 no-op？
    • 这个 outbound call 为什么是 record_progress，不是 close？
    • 这个 customer rejection 为什么是 not_interested，不是 DNC？
    • AI 如果编 taskId，系统会不会真写库？
    • 没有触发通话证据时，contacts-analyzer writer 会不会跳过 create_closed？
    • duplicate open task 是否被 DB unique index 挡住？
    • accepted mutation 是否产生 suggestion / playbook artifact？

    它在 AI 基座里属于哪一层

    Task Accuracy Foundation 不是第 7 层，也不是一个独立业务产品。它是一套横跨 AI 判断层、控制层、执行层 的质量保证系统。

    通用 AI 基座

1. Facts / 业务事实
   calls / SMS / leads / contacts / tasks

2. Objective + Context / 目标与上下文
   当前有哪些候选目标、open task、history、policy constraints

3. AI Decision / AI 判断层
   production prompt + model + structured output schema
          ▲
          │  Golden Eval 验证这里：AI 判断准不准
          │

4. Control Plane / 安全控制层
   Policy Guard / DNC / duplicate / store isolation / approval
          ▲
          │  DB Replay 验证这里：危险 mutation 是否被挡住
          │

5. Execution / 执行层
   create / close / update / record_progress / future Vapi / SMS
          ▲
          │  DB Replay 验证这里：writer 是否真的安全落库
          │

6. Feedback / 结果回流
   closeResult / progress events / staff feedback / business outcome

    所以它的定位是：

    • AI Decision Assurance：证明模型输出的 taskDecisions[] 对不对。
    • Control Plane Assurance：证明 Policy Guard 没有漏掉 DNC、duplicate、forbidden create、store mismatch。
    • Execution Assurance：证明 writer / DB constraints 真能保护 production data。

    它不是用户每打开页面才跑。它应该在这些时机触发：

    触发时机跑什么为什么
    改 prompt / schema / task policy 前后Golden Eval防止 AI decision 回归
    改 writer / Policy Guard / DB constraint 前后DB Replay防止危险 mutation 漏进 DB
    Demo 前Golden Eval + 关键 DB Replay只展示稳定 case，不现场赌模型随机性
    CI / nightlyGolden Eval 子集或全量长期监控模型和 prompt 漂移
    Production event 到来时Runtime Policy Guard不跑完整 eval，但每次 mutation 都必须过 guard

    未来会有一组 Accuracy Foundations

    Task Accuracy 不是唯一的 accuracy foundation。长期我们会有 Call / Contact / Task / Agent Execution 多个 accuracy harness，但它们不应该各自长出一套孤立基座。正确方向是：共享 AI Foundation，按不同输出面挂不同 accuracy harness。

    共享 AI Foundation（厚底座）

┌────────────────────────────────────────────────────────┐
│ Facts / Source of Truth                                │
│ calls / messages / leads / contacts / tasks / outcomes │
└──────────────────────────┬─────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────┐
│ Context Builder                                         │
│ 把 DB facts 组装成模型可读、可追溯、可测试的 context      │
└──────────────────────────┬─────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────┐
│ Tenant / Vertical Taxonomy Registry                     │
│ 健身房、医疗、fraud、BPO 等行业各自有 category pack       │
│ 值来自 common schema / taxonomy，不在 prompt 手写第二份   │
└──────────────────────────┬─────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────┐
│ LLM Gateway + Structured Output                         │
│ model routing / prompt version / Zod schema / metering  │
└──────────────────────────┬─────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────┐
│ Deterministic Canonicalizer + Policy Guard              │
│ enum 校验、category 反推、store_id isolation、DNC、审批   │
└──────────────────────────┬─────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────┐
│ Eval / Replay / Observability                           │
│ golden eval、DB replay、prompt snapshot、runtime audit   │
└──────────────────────────┬─────────────────────────────┘
                           │
        ┌──────────────────┼──────────────────┬──────────────────┐
        ▼                  ▼                  ▼                  ▼
┌──────────────┐   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│ Call Accuracy│   │Contact       │   │Task Accuracy │   │Agent Exec    │
│ Harness      │   │Accuracy      │   │Harness       │   │Accuracy      │
│              │   │Harness       │   │              │   │Harness       │
│ transcript   │   │contact state │   │task decision │   │approved run  │
│ -> call facts│   │/ context     │   │/ mutation    │   │/ outcome     │
└──────────────┘   └──────────────┘   └──────────────┘   └──────────────┘

    所以这里有两个不同层面的关系：

    数据依赖关系（业务上游/下游）

Transcript
  -> Call Analysis
  -> Contact State / Intent
  -> Task Decision
  -> Policy Guard / Writer
  -> Agent Execution
  -> Business Outcome
    工程资产关系（底座复用）

Shared context / taxonomy / schema / canonicalizer / policy / eval
  -> Call Accuracy Harness
  -> Contact Accuracy Harness
  -> Task Accuracy Harness
  -> Agent Execution Accuracy Harness

    如果 Call Analysis 把“我要取消”理解错，Contact 状态和 Task 决策都会跟着错。所以 demo 前后要补 Call Accuracy 和 Contact Accuracy。但这不是另外造两个“基座”，而是在同一个 AI Foundation 上加两个 upstream harness。demo 前先做 Task Accuracy，是因为它最接近现在要展示的价值：AI 能不能把已有业务 context 变成正确、可控、可写库的 task decision。

    4. 最终态应该长什么样

    借鉴另一份 AI Agent 架构方案，retaintive 的长期方向也是：底座厚，Skill 薄。

    也就是说，不要每个功能都重新写一套 AI 流程。底座统一做 context、LLM、policy、approval、execution、metering、feedback；上层不同 skill 只定义业务目标。

    先把现状和目标态分清楚：

    层现在 production 里有什么最终态想补什么
    2. Objective Catalog + Context Builder没有独立 task_objectives / task_issues 表；现在主要是 tasks.typeCategory + prompt-builder 里的 open task / recent event context独立 objective / issue 抽象，把“想达成什么、怎么算成功、什么时候停止”从健身房 category 里抽出来
    3. AI Decision Layercontacts-analyzer + production prompt + ContactsAnalysisSchemaLLM Gateway、model routing、usage metering、持续 eval / replay

    所以第 2 层在下面的图里是 target state，不是说现在已经有一张 production objective catalog 表。

    通用 AI 基座最终态：任何行业都能复用

┌────────────────────────────────────────────┐
│ 1. 业务事实 Facts                           │
│                                            │
│ 客户、事件、订单、合同、对话、任务、结果       │
│ 只负责记录真实发生了什么                     │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 2. 目标目录 + 上下文构建（目标态）            │
│ Objective Catalog + Context Builder         │
│                                            │
│ 不是 AI 最终判断                             │
│ 而是把“可能要完成什么”和“证据是什么”整理好     │
│                                            │
│ 当前：typeCategory + prompt-builder context │
│ 未来：task_objectives / task_issues          │
│                                            │
│ objective candidates                        │
│ customer / account context                  │
│ policy context                              │
│ history / suggestions / playbooks           │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 3. AI 判断层 AI Decision Layer              │
│                                            │
│ LLM Gateway                                 │
│ prompt / model routing                      │
│ structured output schema                    │
│ eval / replay                               │
│ usage metering                              │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 4. 控制层 Control Plane                     │
│                                            │
│ Policy Guard                                │
│ approval queue                              │
│ DNC / operating hours / tenant policy       │
│ agent execution log                         │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 5. 执行层 Skills & Execution                │
│                                            │
│ voice call / SMS / email                    │
│ human handoff                               │
│ workflow automation                         │
│ 每个 skill 只做薄薄一层业务动作              │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 6. 结果回流 Feedback Loop                   │
│                                            │
│ conversion / retention / fraud result       │
│ staff feedback                              │
│ transcript / outcome / cost                 │
│ 下一轮 context 和 playbook 从这里改进         │
└────────────────────────────────────────────┘

    六层各管一件事

    层职责retaintive 里的对应
    1. Facts事实从哪里来calls、messages、leads、contacts、tasks、progress、timeline
    2. Objective Catalog + Context BuilderAI 判断前先整理候选目标和证据future task_objectives / task_issues + context pack
    3. AI Decision Layer模型调用、prompt、structured output、eval、计量contacts-analyzer、LLM Gateway、golden eval
    4. Control Plane什么动作被允许、谁审批、如何审计Policy Guard、approval queue、agent logs
    5. Skills & Execution具体业务动作follow-up、retention、Vapi call、SMS draft
    6. Feedback Loop结果如何反哺下一轮判断close outcome、staff feedback、conversion / retention result

    两个枢纽必须做厚：

    • LLM Gateway：所有模型调用统一出口，才能做 routing、fallback、cache、cost tracking、prompt versioning。
    • Approval + Policy：所有外部触达前必须过 policy 和 human approval，尤其是电话 / SMS / Email。

    Interface Contract / 操作面放在哪里

    API / CLI / MCP 不应该理解成第 7 层，也不应该理解成另一个业务逻辑层。它们是 外部系统、人、agent 使用 AI 基座的受控入口。

    六层回答的是：

    内部能力怎么运转？

Facts
  -> Objective / Context
  -> AI Decision
  -> Control Plane
  -> Execution
  -> Feedback

    Interface Contract 回答的是：

    外部入口怎么安全使用这些能力？

Dashboard / Lark / Codex / Botmux / Vapi / external AI client
  -> API / OpenAPI contract
  -> generated internal client
  -> thin CLI / MCP tool schema / product UI action
  -> Control Plane
  -> Domain service / Task Orchestrator
  -> Facts write or approved Execution
  -> Feedback Loop

    不要这样理解：

    CLI / MCP / Vapi
  -> directly update DB
  -> directly call customer
  -> directly bypass policy

    应该这样理解：

    任何入口都只能提交受控请求
  -> auth / store_id isolation / scope
  -> DNC / operating hours / duplicate / stale proposal guard
  -> approval when outbound action affects customer
  -> audit log / usage event
  -> then execute

    所以 API / CLI / MCP 的位置是：

    ┌────────────────────────────────────────────┐
│ AI Foundation 六层                          │
│                                            │
│ Facts / Context / AI Decision               │
│ Control Plane / Execution / Feedback        │
└──────────────────────┬─────────────────────┘
                       │ capabilities are exposed through
                       ▼
┌────────────────────────────────────────────┐
│ Interface Contract / 操作面                 │
│                                            │
│ API: 受控业务能力入口                        │
│ OpenAPI: 机器可读合同                        │
│ Internal client: CLI / test / agent 复用     │
│ Thin CLI: Codex / Botmux / CI 可操作         │
│ MCP / Tool schema: 外部 AI client 可调用     │
│ Skill: 告诉 agent 应该怎么用这些能力          │
└────────────────────────────────────────────┘

    Demo 前不需要把所有 endpoint 设计完。现在只需要把原则写清楚：业务规则收口在 service / Orchestrator / Control Plane；API / CLI / MCP 只是受控入口，不能复制业务规则，也不能绕过安全层。 具体 API spec 应该单独开后续设计文档或 GitHub issue。

    套到 retaintive：我们最终应该这样搭

    retaintive AI 基座最终态：以 task 为中心

┌────────────────────────────────────────────┐
│ 1. 业务事实                                 │
│                                            │
│ calls / messages / leads / contacts / tasks│
│ task_progress_events / task_suggestions    │
│ task_playbooks / contact_timeline          │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 2. 任务目标上下文（目标态）                  │
│ Objective Catalog + Context Builder         │
│                                            │
│ 当前 production：                            │
│ tasks.typeCategory + prompt-builder          │
│                                            │
│ 未来目标：                                  │
│ 例子：lead_follow_up                        │
│ objective: 让客户预约 intro class           │
│ desiredOutcome: 客户确认具体时间            │
│ success: closeResult = booked              │
│ failure: not_interested / unable_to_reach   │
│ evidence: 最近 call/SMS/voicemail/task      │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 3. AI 判断层                                │
│                                            │
│ contacts-analyzer                           │
│ production prompt                           │
│ ContactsAnalysisSchema                      │
│ taskDecisions[]                             │
│ golden eval / DB replay                     │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 4. 安全控制层                               │
│                                            │
│ resolve taskRef T1/T2                       │
│ applyTaskAction()                           │
│ Policy Guard                                │
│ DNC guard                                   │
│ duplicate guard                             │
│ store_id isolation                          │
│ approval before outbound                    │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 5. 执行动作                                 │
│                                            │
│ 现在：create / close / update / progress task│
│ 未来：AI agent 根据 approved playbook 打电话   │
│      Vapi call / SMS draft / manager handoff │
└──────────────────────┬─────────────────────┘
                       │
                       ▼
┌────────────────────────────────────────────┐
│ 6. 结果回流                                 │
│                                            │
│ task_progress_events                        │
│ closeResult                                 │
│ call transcript                             │
│ staff feedback                              │
│ conversion / retention result               │
│ 这些再进入下一轮 AI context                  │
└────────────────────────────────────────────┘

    这里最容易混的是第 2 层和第 3 层：

    问题第 2 层：Objective Catalog + Context Builder第 3 层：AI Decision Layer
    它是不是 AI 最终判断？不是是
    它做什么？整理候选目标、现有任务、证据、限制条件判断这次应该 create / close / update / progress / no-op
    没有 open task 时怎么办？给 AI 候选目标和证据，比如 lead 可能想预约AI 判断是否真的要 create_open
    有 open task 时怎么办？open task 已经提供 objectiveAI 判断最新证据是否推进或结束这个 objective
    为什么不能合并？合并后 context 不稳定，难复用、难评估分层后 prompt/eval/policy 可以独立改

    5. 现在 vs 最终态

    能力现在最终态还差什么
    Task decisionAI 输出 taskDecisions[]有 scenario registry + eval + replay 持续验证Task Accuracy Baseline v1
    Task mutation safetyapplyTaskAction() + Policy Guard所有 human/system/AI/agent 都走同一入口DB replay +更多 guard tests
    Task categorytypeCategory 健身房语义objectiveType 或 task_objectives/task_issues 支撑跨行业schema design
    Suggestionsappend-only task_suggestionsstaff feedback / close outcome 反哺建议质量feedback analytics
    Playbookstask_playbooks 可生成执行建议agent / staff 共用 execution playbookquality eval + tenant playbook pack
    Approval还不是统一产品层draft/edit/approve/reject/expire state machineapproval queue
    Agent execution还没有 Vapi agent run SSoT每次 call attempt 有 run log、transcript、outcome、costagent_runs / agent_actions
    Usage metering分散或未成体系per-client package + usage + quota + cost attributionLLM Gateway + usage events
    Context improvement有 history 和 artifacts，但未闭环历史对话、feedback、close outcome 自动改进 context packfeedback loop
    Lark surface可以用 Lark doc/card 做 reviewLark approval / daily report / eval report 成为运营入口Lark integration polish

    6. objective / desiredOutcome / businessGoal 是什么意思

    当前 tasks.typeCategory 回答的是：

    这个 task 属于哪个业务桶？

    例如：

    • lead_follow_up
    • cancellation_risk
    • retention
    • renewal

    但未来 AI agent 真正需要知道的是：

    这次联系客户到底想达成什么结果？什么算成功？什么算失败？什么时候应该停止？

    这就是 objective / desiredOutcome / businessGoal 的意义。

    当前 categoryObjectiveDesired outcomeSuccess criteria
    lead_follow_up预约 first intro class客户确认具体时间close booked
    booked_not_converted转成 paying member客户购买 membershipclose converted
    cancellation_risk挽留取消客户客户同意留下 / freeze / downgradeclose cancel_saved
    retention解决投诉客户确认问题解决close issue_resolved
    renewal恢复连续付费card fixed / renewal restoredclose renewed

    长期看，typeCategory 仍然可以保留为 UI / reporting taxonomy，但 agent context 最好再有 objective 层。

    7. 现在要不要改 DB schema

    建议：demo 前不要改。

    原因：

    • Task Accuracy Baseline v1 不依赖 schema migration。
    • tasks、task_progress_events、task_suggestions、task_playbooks 已经够支撑 demo。
    • 现在改 schema 会牵动 writer / API / UI / migration / tests，风险高。
    • 我们还没有通过 scenario registry 验证哪些 objective pattern 是真的高频。

    Demo 后再做一个正式设计 issue，比较：

    方案优点风险
    在 tasks 加 nullable objective / desiredOutcome / businessGoal简单、查询方便一 task 多 issue 会 messy；跨行业抽象有限
    新增 task_objectives更通用，适合 AI agentschema / UI / writer 复杂
    新增 task_issues和 task_suggestions.issueId 预留方向一致偏问题/阻塞，不一定覆盖所有 revenue objective

    我的倾向：先设计 task_objectives + task_issues 的组合，等 Task Accuracy Baseline v1 跑出真实 scenario 后再决定，不要现在硬拍。

    8. Demo 前路线图

    Demo 前两天优先级

Day 1
  -> Scenario registry 初版
  -> P0 / P1 expected decision review
  -> DB replay 选 8-12 个关键 case
  -> knownGap 标记规则确定

Day 2
  -> Golden eval expansion
  -> 修最影响 demo 的 prompt / policy gap
  -> 关键 DB replay 跑通
  -> Demo pack 只保留稳定通过 case

不能混进 demo：
  -> 需要赌模型随机性的 case
  -> 还没有 writer / policy 证明的高风险 mutation
  -> Vapi 自动外呼
  -> 自动发 SMS

    Demo 前必须完成：

    • Scenario registry 初版。
    • P0 / P1 expected decision review。
    • Golden eval case expansion。
    • 已知不稳定 case 标 knownGap。
    • DB replay 选 8-12 个关键 case。
    • Demo pack 只展示稳定通过的 case。

    Demo 前不建议做：

    • Vapi 接入。
    • 自动发 SMS。
    • 完整 approval queue。
    • LLM Gateway 重构。
    • task objective schema migration。

    9. Demo 后路线图

    Demo 后演进顺序

Baseline v1 stable
  -> Objective / issue schema design
  -> Approval queue
  -> Agent execution log
  -> Vapi voice pilot
  -> Usage metering + LLM Gateway
  -> Feedback loop

为什么这个顺序：
  先证明 AI 判断准
  再定义 objective / issue 的长期 schema
  再加 approval 和 agent run audit
  最后接真正自动外呼和计费闭环

    第二批建议：

    Milestone产出
    Objective designtask_objectives / task_issues proposal，覆盖健身房 + 非健身房例子
    Approval queuedraft / edit / approve / reject / expire 状态机
    Agent execution logagent_runs、agent_actions、call attempt、transcript、cost、outcome
    Vapi pilot只对低风险 task + approved script 做 outbound
    LLM Gatewayprompt version、model routing、usage event、per-client quota
    Feedback loopclose outcome + staff reaction + conversation history 改进 context pack

    10. 你现在还差多少

    粗略判断：

    Area完成度判断说明
    Task data model中高tasks/progress/suggestions/playbooks 已有，但 objective 层缺
    Safe mutation architecture中高Orchestrator + Policy Guard 方向对，需要 DB replay 证明
    AI decision accuracy中prompt/schema 有了，scenario/eval 覆盖还不够
    Demo readiness中只要聚焦稳定 case，两天内可做出可信 demo
    Voice agent readiness低缺 approval、agent log、execution policy、Vapi integration
    AI foundation commercialization中低缺 LLM Gateway、usage metering、quota、billing attribution

    最重要的补充判断：

    你现在不是“从 0 开始做 AI foundation”。你已经有一条 task intelligence pipeline。接下来要做的是把它从“能跑”升级成“可证明准确、可安全执行、可持续学习、可计费”。

    这就是为什么 Task Accuracy Baseline v1 是当前最好的切入点。