Skip to content

ADR-0003: Agentic Escalation Path and Governance Separation

  • Status: accepted
  • Date: 2026-09-26
  • Deciders: Huashan Wang

Context

The current bot fleet answers questions from knowledge sets (ADR-0002). A future class of bots will need to execute: write to Odoo, send WeCom messages, manipulate records. This raises the question of whether agentic capability is an in-place enhancement or a fundamentally different solution.

The two classes differ technically by one dimension — the brain behind the WeCom bot — but differ sharply in risk class:

Q&A bot Agentic bot
Failure cost A wrong answer confuses one colleague A wrong write corrupts business data
Access Read-only (knowledge set) Write to Odoo / WeCom / customer data
Governance needed Accuracy review Permissions, audit, approval flows, blast-radius control

WeCom Smart Robot natively supports a three-stage ladder, and everything invested at stage 1 carries forward:

  1. Q&A — knowledge set only (current state).
  2. Tool-assisted — 拓展能力: attach API/MCP plugins and custom workflows to the same bot.
  3. API mode — swap the brain: an external orchestration (Tencent Cloud ADP agent, WorkBuddy gateway, own model) behind the same WeCom bot surface.

The WeCom surface (bot identity, groups, visibility), the knowledge files (COS stays the source of truth; ADP connects object storage directly), and the sync script persist unchanged across all three stages.

A governance gap exists at stage 2: WeCom's native 拓展能力 has thin execution governance. Anything touching Odoo transactions or customer data requires a governance layer (ADP's permission/audit stack, or an own gateway) in front of the tools.

Decision

  1. One technical architecture, not two. Agentic capability is the next stage of the same architecture: same WeCom surface, same KB staging, same sync script. Bots escalate in place through the three stages above.
  2. A separate project with separate deliverables is opened when a bot first needs write access. The trigger is operational, not calendar-based. The new project's deliverables are governance artifacts: a permissions model ADR, audit requirements, approval flows, and an explicit forbidden-actions list per bot.
  3. Sensitive writes never run on native 拓展能力 alone. They require ADP governance or an own gateway (WorkBuddy) between the bot and the target system.
  4. Engineering home stays here. The agentic project's ADRs live in this repo; user-facing adoption/training material lives in wecom-suite (see wecom-suite ADR-0006 for the separation of concerns).

Consequences

Benefits

  • Deployment speed now: stage 1 costs configuration only, no governance tax.
  • No rewrite later: the stage-1 investment (KB packages, bot identities, group exposure) is fully reused.
  • The governance burden is paid exactly when — and only when — a bot earns write access.

Trade-offs

  • Stage-2 plugins must be re-evaluated against governance requirements before any production write path uses them.
  • Two project structures (this repo's Q&A bots vs. the future agentic project) must be kept coordinated through cross-linked ADRs.