Digital Employee Brain: Deep Dive into Decision Chain and Progressive Routing

1. Why a “brain” is needed

In the AE fund‑settlement domain, a massive daily influx of tickets, inquiries, and alerts exhibits highly diverse types. Traditional keyword‑match routing can handle known scenarios but becomes ineffective when faced with completely new problems.

2. Full decision chain overview

The brain follows a five‑step decision chain:

用户输入
   ↓
Step 1 · Intent Recognition ← Knowledge‑base + Memory assistance (semantic parsing + scenario classification)
   ↓
Step 2 · Confidence Routing Evaluation ← Decision log + Persistent‑memory bonus
   ├── ≥ 0.8  → Fast path (direct static routing)
   ├── 0.4~0.8 → Verification routing (dry‑run pre‑check)
   └── < 0.4  → Dynamic decision (DCR loop)
   ↓
Step 4 · Structured decision output (including memory_context)
   ↓
Step 5 · Decision memory ring (AUDNP)

The core design avoids binary hit/miss judgments and instead uses confidence scores for progressive routing.

3. Step 1 – Intent Recognition

Intent recognition extracts the user’s core intent and simultaneously produces a scenario classification.

Memory‑assisted pre‑step

Narrow search scope – If the memory records an ongoing ticket, the knowledge‑base query is anchored to the relevant business domain instead of scanning the entire corpus.

Disambiguate vague intents – For expressions like “help me, it’s stuck”, the memory indicating the user is troubleshooting a disbursement ticket narrows the intent to that specific scenario.

Knowledge‑base assisted understanding

Domain term ambiguity (e.g., “滚仓”) – Call knowledge‑base to confirm standard definition.

Semantic polysemy (e.g., “钱没到”) – Extract core verb + object and judge with context.

Unfamiliar ID format – Match ID to business domain via knowledge‑base.

Open‑ended scenario classification

The output includes a one‑sentence intent description and a scenario judgment. The set of Controllers (e.g., ticket‑handler, consultation, alarm‑diagnosis, AI‑coding) is not a fixed enumeration; new Controllers can be registered and automatically become routable.

4. Step 2 – Confidence Routing Evaluation

The brain computes a 0‑1 confidence score for each registered Controller using five weighted signals:

Keyword match (30%) – Number of core keywords hit in the user input.

Intent semantic similarity (30%) – Semantic alignment between intent and Controller responsibilities.

Knowledge‑base confirmation (20%) – Support degree returned by the knowledge‑base for the scenario.

Session decision log (10%) – Historical preference in the current session (success +0.1, failure –0.15).

Persistent‑memory bonus (10%) – Cross‑session routing experience (success +0.05~0.1, failure –0.1, >90 days decay 50%).

Based on the highest confidence, three routing strategies are applied:

Fast path (≥ 0.8) – Direct static routing without verification. Example: user says “process ticket 2025060300011279027”, intent recognition yields confidence 0.95 for ticket‑controller → immediate routing.

Verification routing (0.4 ~ 0.8) – A dry‑run pre‑check is issued to the top Controller. If the pre‑check passes, static routing proceeds; otherwise it falls back to dynamic decision.

Dynamic decision (< 0.4) – The problem is treated as “unknown” and enters the DCR loop.

5. Solving Unknown Problems – Dynamic Decision

When no Controller meets the confidence threshold, the brain executes a Draft‑Critique‑Refine (DCR) loop, an Evaluator‑Optimizer pattern that iterates up to three times until convergence.

┌────────────────────────────────────────────┐
│          Draft‑Critique‑Refine Loop        │
│                                            │
│ Draft → Critique → Refine                  │
│ generate draft → adversarial check → revise │
│    ▲               │
│    └───────────────────────┘
│    If Critique fails, return to Draft with reason.
│    After >3 rounds, fall back to safety strategy.
└────────────────────────────────────────────┘

Draft stage

Query knowledge‑base with “user original question + identified intent” using knowledge-base-routing-skill.

Check memory for past experiences on similar unknown scenarios; if a successful path exists, use it as the draft start.

Standard solution exists → downgrade to static decision (the problem is not truly unknown).

No standard solution → combine knowledge‑base fragments and historical memory to generate a candidate plan (choose path, compose Controllers, define parameters).

Key insight: the draft is assembled from “fragment‑level” clues in the knowledge‑base and the user’s history.

Critique stage

The draft undergoes three destructive checks:

Counter‑example check – Reverse‑search knowledge‑base and memory for contradictory records to detect conflicts or past failures.

Boundary check – Verify whether the target Controller’s capabilities truly cover the request to avoid routing to an incapable module.

Comparison check – Compare with the second‑ranked Controller to prevent sub‑optimal routing.

If all three checks pass, the final solution is output; otherwise the loop returns to Refine.

Refine stage

Incorporate specific feedback from Critique as context and adjust the draft.

Each round enriches context: failure reason → constraint → boundary confirmation.

At most three rounds because most problems converge within two.

Parallel exploration for cross‑scenario problems

When a query matches multiple Controllers (e.g., an alarm message attached to a ticket), the brain performs parallel dry‑run checks on the top‑N Controllers, merges results, and decides:

All succeed → orchestrated execution (pipeline or parallel).

One succeeds → downgrade to single‑path routing.

All fail → enter DCR loop.

Example: alarm‑controller ✅ + ticket‑controller ✅ → alarm provides context for the ticket → pipeline execution: alarm diagnosis → inject result → ticket handling.

Dynamic decision outputs

Type A – static consolidation – Same problem appears ≥ 3 times; skill‑evolution creates a new Controller; next time the fast path is used.

Type B – orchestrated composition – Cross‑domain composite problem; one‑time combination of existing abilities, outputting an execution topology and I/O contract.

Type A is the brain’s primary self‑evolution mechanism: unknown problems become known after a few DCR cycles, continuously expanding the Controller set.

6. Decision Memory Ring (AUDNP)

After each decision, the brain records an AUDNP memory ring:

A – Assess : Evaluate the decision result (routing correctness, user satisfaction).

U – Update : Update session‑level decision cache (e.g., “ticket X confirmed as disbursement”).

D – Detect : Detect conflicts with historical decisions (e.g., previous failure on similar issue).

N – Notify : Adjust strategy or inform the user.

P – Persist : Persist high‑value decisions to persistent memory for cross‑session reuse.

Only decisions that meet certain criteria are persisted:

Failure lessons – user corrects a routing error, immediately persisted with negative weight.

Consecutive successes – two successive correct routings are persisted as positive experience.

Explicit positive feedback – user explicitly confirms the path.

Persisted memory is consumed in the next session’s confidence calculation, enabling cross‑session self‑learning.

How the memory ring influences routing

First time the user says “order XXX money not arrived”, the brain routes to consult‑controller. After the user corrects to “disbursement ticket”, the AUDNP records a –0.15 penalty for consult‑controller and a +0.1 bonus for ticket‑controller. Subsequent similar queries automatically favor the ticket‑controller.

7. Fallback Strategy

If three DCR iterations still cannot produce a feasible solution, the brain executes a layered fallback:

Deep knowledge‑base retrieval with expanded queries.

Full‑tree memory traversal to uncover overlooked historical clues.

Generic capability fallback (code search, documentation, web search).

Honest boundary explanation – inform the user of current capability limits and suggest next steps.

Record evolution signals and automatically persist the entire scenario for future skill evolution.

8. Knowledge‑base + Memory Dual Channel

The knowledge‑base provides domain facts, business rules, and standard processes; the memory supplies user identity, preferences, historical decisions, and work context. When they conflict, the hierarchy is: compliance hard constraints > user preference (memory) > knowledge‑base defaults.

Intent Recognition – Knowledge‑base handles terminology disambiguation, semantic parsing, scenario matching; memory assists disambiguation with user identity/context.

Confidence Evaluation – 20% weight from knowledge‑base confirmation; 10% weight from persistent‑memory bonus.

Static Decision – Knowledge‑base checks scenario suitability and completes parameters; memory confirms historical interaction and personalizes parameters.

Dynamic Decision – Draft retrieves solutions, Critique validates, Refine supplements; memory provides historical experience for Draft and checks failure records for Critique.

Fallback – Deep knowledge‑base search combined with full‑tree memory search.

All knowledge‑base accesses go through the knowledge-base-routing-skill skill, and all memory operations use the memory skill, avoiding direct calls to lower‑level MCP.

9. Complete Architecture Diagram

10. Summary

Routing mechanism – Traditional: keyword → fixed module. Brain: five‑dimensional confidence scoring → progressive three‑level routing.

Scenario coverage – Traditional: hard‑coded enumeration. Brain: open set; new Controllers auto‑register.

Known problems – Traditional: handled. Brain: fast path, one‑step.

Fuzzy problems – Traditional: prone to errors. Brain: verification routing + dry‑run + memory disambiguation.

Unknown problems – Traditional: unmanageable. Brain: DCR loop + parallel exploration + knowledge‑base + memory assistance.

Learning ability – Traditional: none. Brain: AUDNP memory ring + self‑evolution.

Personalization – Traditional: none. Brain: persistent memory drives identity awareness, parameter completion, preference adaptation.

Capability boundary – Traditional: static. Brain: ≥ 3 dynamic decisions trigger new Controller creation, continuously expanding the boundary.