Agent conversation orchestration

Voice: How Cadau chooses materials, calls tools, and constrains answers when the user talks to the help assistant or a work assistant in Messages. Users keep speaking naturally; they do not write prompts. Status: Target mechanism. The help assistant and work assistants stay separate identities and are not merged. Code has not been rebuilt to this page in full; see the implementation mapping at the end for the transition. Related: [产品规格.md](/docs/mech-spec) §4.1.5; 帮助智能体对话操作.md (what chat can already do); 智能体调用知识文档的方式.md (how knowledge enters chat); 技能组成规范.md; 对话主题与复盘.md

Chinese source: [docs/core-mechanisms/智能体对话编排.md](../../core-mechanisms/智能体对话编排.md).

---

1. Why this page exists

Conversation actions used to be judged before the model tool loop (classify the object, then fill slots from a fixed phrase — chatintent and the various *fromchat executors). Short Chinese sentences could do the work; casual wording, English, and correcting the previous round often missed or hurt. Retrieval and doing-the-work were also mixed: saying “create an agent” could retrieve operating-rule templates, and the model would teach configuration instead of creating.

The target is four things:

1. Help assistant and work assistants stay two identities, with different tool surfaces.
2. Intent is not guessed with regular expressions; what the platform can do is exposed as tools, and the model decides whether to call them.
3. Materials are a catalog first, then full text only for what this round selected; last round’s selection is not stacked by default.
4. Role, task, constraints, materials, and communication rules are injected by the product; the user does not paste a prompt template.

What the help assistant can already do remains in 帮助智能体对话操作.md. This page is how each round is orchestrated.

---

2. Two identities (not merged)

| | Help assistant | Work assistant | |--|---------------------|-------------------| | When it appears | The onboarding chat when no workspace is selected; still in System after a workspace is selected; same identity as the bottom-right action assistant | The user’s own assistants after they have a workspace (including the automatic Start assistant) | | Main job | How the product works; doing platform actions in chat | Doing work, memory, skills, knowledge, writing files | | Does not have | Personal memory, memos, topic review, persona files | By default no invite-member / delete-workspace platform admin tools | | System knowledge | May retrieve | May retrieve when the user asks how Cadau works; not used as persona |

When Human Resources or similar apps are open, the bottom-right assistant is the app assistant: the same work assistant (or the one bound to that app), with that app’s operations added to the tool surface. If the help assistant gets the same look-up / change request, it must call the same operations, not only tell the user to tap the page.

With no workspace selected, only the help assistant can chat: create or join a workspace, explain the product. Other writes ask the user to pick a workspace first.

---

3. What one round does

User message (original text = the only task this round)
        │
        ▼
① Crop the tool surface and catalogs by identity
        │
        ▼
② Select materials (cheap, structured: skills / knowledge entries / tools to use)
        │
        ▼
③ Assemble the prompt: identity + this-round task envelope + constraints + selected bodies
        │
        ▼
④ Reply or call tools (may loop) → policy gate executes
        │
        ▼
Speak to the user: result or conclusion first; evidence and limits when needed

When a short answer continues an unfinished ask (for example the assistant just asked what to name the agent, and the user replies “CRM”), skip material selection and hand the short answer to the in-flight tool. Do not retrieve again or re-guess intent.

---

4. Four layers

4.1 Tool surface (who can see which tools)

Do not hand every tool to every assistant.

Platform writes are a small set of coarse tools (create an agent, create a workspace). Tool descriptions use everyday wording for when to use and when not to (“use when they want an agent created; do not use when they ask how to create one, or when they are writing a document”). English and Chinese work when those descriptions are bilingual, not when a word list is bilingual.

4.2 Select materials (re-select every round)

What the model sees first is a catalog (skill names and when they apply, the knowledge root index, tool names), not the whole library.

• Read full text only after selection (two-layer knowledge indexes, skill bodies, published standards-library entries, and so on).
• Last round’s selection is a hint and expires by default; drop it if several rounds do not hit it again. Keep it only if the user clearly says “keep using that skill”.
• The retrieval query comes from this round’s user words (the current page may be added). Do not concatenate the whole history as the query.
• Cap how many retrieval hops run, so search cannot loop forever.
• Off-limits: when asking numbers and a data connection already exists, usually do not retrieve knowledge. If the user is creating an agent / workspace, do not load operating-rule or persona templates as the task material — those pages are for “how do I write operating rules”.
• If material selection fails: empty working set + catalogs only, and let the doing-work model fetch via tools. Must not fall back to keywords to run a write.

4.3 Tool loop

The model chooses which tool and which arguments. The platform executes and returns a receipt. Until a tool returns, the assistant must not claim it already looked something up, created something, or booked stock in. When the model stops without tool calls, the platform checks that claim against this round’s receipts and continues the loop if evidence is missing.

When a required name is missing: the tool says what is missing; the chat asks, and offers a reasonable default (for example the default workspace name My workspace). Do not expand into a configuration questionnaire (temperature, skill binding, generate HTML — things the user did not ask for).

4.4 Policy gate (not left to the model’s taste)

The LLM decides whether to call, which tool, and the arguments. The platform decides whether the call is allowed, how it is stored, and how to undo a mistake.

---

5. Prompts are injected by the product (users do not write them)

Each round’s instructions to the model follow five beats: identity, task, constraints, materials, communication. Users still say short sentences.

Always present, kept short:

• Identity: the help assistant, or that work assistant’s persona.
• This round’s task: the latest user sentence in its own envelope; history and topic are background, not standing orders.
• Constraints: if it is not in the materials and no tool returned it, say what is missing; do not invent features, data, or “already done”. Keep facts (documents / receipts) separate from the assistant’s advice.
• Communication: if the ask is unclear, question first and offer a default; do not force an answer.

Chosen this round:

• Selected knowledge / skill bodies, the current screen, the tool list.
• Output: a plain receipt when something was done (what was created, in which workspace, what they can do next). “Conclusion, then evidence, then limits” is for product questions and reading a policy, not for every do-it turn. Small talk does not need the long template; keep “do not invent, ask if incomplete”.

A work assistant’s persona and operating rules still come from that assistant’s own files. The help assistant has no personal persona file.

---

6. How this splits from “what chat can do”

---

7. Archive and regression

Each round should be visible afterwards:

• materials selected and dropped this round
• tools called, and whether policy refused them
• whether an undo ran (mistaken create rolled back)
• whether the user corrected the previous round

Turn failures into automated tests. At least: Chinese and English “create an agent, CRM” / “create a agent, CRM” must do the work; “how to create an agent” only explains; “remove wording that does not fit the topic” is not removing a member.

---

8. Rollout

1. Help assistant: create agent / create workspace as tools. (Done.)
2. Keywords no longer intercept. A hit only attaches related tools as this-turn background; the model decides whether to call them. Rename, open page, help ops, create skill/app/data connection, review phrases, and “which skills were used” follow the same rule. Deletes still need user confirmation inside the tool. (This step is done.)
3. Help assistant selects materials: system-knowledge catalog + platform tool list. Create skips knowledge retrieval so templates do not steal the task.
4. Work assistants select knowledge / skills / memory; invite-member / delete-workspace tools stay hidden.

---

9. Implementation mapping

Target

• Entry remains POST /api/v1/chat / chat/stream; help_mode marks the help assistant.
• Platform writes run in the tool loop. Keywords only select tool background.
• Plugin look-up / change still uses plugin_invoke.
• Two-layer knowledge indexes stay in their own mechanism docs.

Current code

• tryPlatformByIntent / tryWorkSessionOps no longer do the work before the loop.
• Help assistant tools: create_workspace, create_agent, rename_workspace, open_page, platform_helpops, create_skill, create_app, create_datasource, undo_last_agent.
• Work assistants may use create_skill / create_app / create_datasource; they do not get workspace-admin tools.
• Keyword hits become “related tools this turn (hints only)”. How-to questions are told not to call write tools.
• Help retrieval may still skip “create an agent / workspace” so templates do not steal the task (that is material selection, not doing the work).
• “Model unavailable” must not fall back to keywords to run delete or remove.

---

10. Related mechanisms

• 帮助智能体对话操作.md
• 智能体调用知识文档的方式.md
• 索引式文档与反馈闭环.md
• 技能组成规范.md
• 工作区能力包.md
• 记忆锻造/记忆锻造.md
• 对话主题与复盘.md
• 帮助动作链接.md