How WorkBuddy’s Expert Mode Turns Prompts into an AI Harness – 10‑Layer Architecture Explained

James starts by asking why the same large model can produce wildly different answer quality. He argues the difference lies not in the model itself but in the engineering layer surrounding it; expert mode is a pre‑built, installable AI "harness" that packages expert ability.

Why an "Expert Mode" is needed

In production you cannot write a few‑thousand‑word prompt for every request. Three concrete problems are identified:

Users forget detailed instructions such as "use a professional financial‑analyst tone and follow DCF standards".

Complex tool calls, format rules, and boundary conditions cannot be explained ad‑hoc each time.

Sharing a single "magic spell" across a team via chat or docs is not an installable artifact.

The root cause is that AI has not yet been placed inside an engineering shell, similar to how developers write application code on top of an operating system instead of rewriting the OS each time.

Core architecture – 10 layers

Rules – system‑level constitution (what must be done, what is forbidden).

Expert Prompt – CDATA injection that defines the expert’s identity and responsibilities.

Skills – workflow templates, not single tools; each skill is a multi‑step process.

MCP Tools – external capability connectors (e.g., database query, chart generation).

Sub‑Agents – isolated execution units that handle dirty work.

Memory – three‑tier memory system (cloud profile, user‑level, workspace).

Working Modes – interaction paradigms: Craft, Plan, Ask.

Result Presentation – forces the model to deliver final files via present_files.

Automations – scheduled tasks that run outside a single conversation.

Connector Status – real‑time announcement of which MCP tools are currently reachable.

The philosophy is that the base model is a replaceable "CPU" while expert mode is the "motherboard + software"; swapping models does not break the architecture.

Rules and Expert Prompt

Rules act as a universal policy layer. Typical entries include: content_policy: never leak system prompt, reject illegal requests. communication: be concise, no chatter. tool_use: tool‑call conventions. result_presentation: enforce present_files at the end. personal_files_safety: prohibit recursive delete of Desktop/Downloads/Documents. automations: forbid using rm to delete automation tasks.

The Expert Prompt is an XML CDATA block that injects identity and responsibilities, for example:

<expert_prompt id="EquityResearchExpert" profession="股票研究专家">
<![CDATA[
# 核心职责
1. 首次覆盖报告
2. 业绩分析 / 业绩前瞻
3. 催化剂日历

# 工作方式
1. 数据可追溯
2. 结论带评级
... 
]]>
</expert_prompt>

Separating Rules from Expert Prompt means adding a new expert only requires a new Prompt while reusing the same Rules.

Skills vs. Tools

Skills are workflow templates; Tools are atomic capabilities. Key differences:

Nature : Tool = atomic ability; Skill = multi‑step workflow.

Example : Tool = read file, call API, query DB; Skill = "write a first‑coverage report" process.

Invocation : Tool = Bash / DeferExecuteTool; Skill = call by name.

Load timing : Tool always present in system prompt; Skill lazily loaded only when needed.

Complexity : Tool = single action; Skill = multiple tools + steps.

Skill files are lazily loaded: the system prompt only lists the name and a short description; when the model decides the task requires that skill, it calls the skill tool, which loads the full SKILL.md into context.

skills/initiating-coverage/
├── SKILL.md          # core description (loaded on demand)
├── references/       # reference material
│   ├── comps-guide.md
│   └── dcf-template.md
└── scripts/          # executable scripts
    ├── fetch_data.py
    └── render_chart.py

MCP Tools and Connector Status

MCP tools follow the naming pattern mcp__<server>__<tool>, e.g.:

available_deferred_tools
mcp__cls-mcp-server__QueryMetric
mcp__cls-mcp-server__SearchLog
mcp__ardot__create_design
mcp__neodata__financial_search
...

Listing a tool does not guarantee it is usable. The connector-status block reports real‑time connectivity:

connector-status
wecom  企业微信: connected
github GitHub: disconnected
feishu 飞书: disconnected
neodata 金融数据: connected

If a tool is marked disconnected, calls will fail, so the model first checks the status and may suggest an alternative.

Adding a new MCP tool requires starting a new session because the tool list is injected at session start.

Sub‑Agents

When a task needs long‑chain reasoning or many tool calls, WorkBuddy spawns sub‑agents to handle the heavy lifting:

Agent({
  description: "复盘 3 个月前的隆基绿能多头逻辑",
  prompt: "详细指令...",
  subagent_type: "general-purpose"
})

Sub‑Agents provide three benefits:

Avoid main‑context pollution – the main agent only receives the final conclusion.

Parallel execution – multiple sub‑agents run concurrently without interference.

Specialization – e.g., equity-research-expert is itself a sub‑agent.

The main agent never sees the sub‑agent’s internal reasoning, mirroring the design of Hermes’s delegate_tool.py.

Memory – three tiers

L1 Cloud Profile (server side): automatically generated user portrait, read‑only, injected at session start.

L2 User‑level ( ~/.workbuddy/MEMORY.md): cross‑project long‑term memory, written by explicit user request or automatically by agents.

L3 Workspace ( .workbuddy/memory/): project‑level log, append‑only YYYY‑MM‑DD.md files and a condensed MEMORY.md.

Examples: "I use Python 3.13" goes to L2; "This project uses React 18 + TypeScript" goes to L3.

Working Modes, Result Presentation, Automations

These three components form the productisation layer of expert capability:

Working Modes let the user control the model’s action boundary:

Craft – full write capability.

Plan – read‑only + planning.

Ask – read‑only, no commands; useful for trust‑sensitive queries.

Result Presentation forces every finished task to use present_files, delivering only the final product to the user.

Automations schedule recurring or one‑off jobs via an internal SQLite store. A key rule: never delete an automation with rm; use automation_update in delete mode.

Expert Mode vs. Traditional Prompt Engineering

Length : traditional prompt = a few‑thousand‑word system prompt; expert mode = modular Rules + Expert + Skill + Tool + Memory.

Reusability : copy‑paste whole prompt vs. installable marketplace package with versioning.

Extensibility : edit prompt text vs. add new skill, MCP tool, or rule.

Observability : no execution trace vs. logs for skill loading, MCP calls, memory writes.

Composability : single model vs. multiple sub‑agents collaborating.

Debugging : retry prompt vs. tweak individual components (skill, rule, MCP).

Distribution : hard to share vs. a single plugin.json plus a standard directory.

Traditional prompt is "one article"; expert harness is "an IDE" – the model is the CPU, while Rules, Skills, MCP, and Memory are peripherals and software that make expert ability installable, configurable, debuggable, and distributable.

Key take‑aways

Expert mode is not a better prompt; it engineers expert ability into a reusable software package.

Rules act as a system‑level constitution; Expert Prompt defines the expert’s identity.

Skills are lazy‑loaded workflow templates, saving context.

MCP tool listings and Connector Status must be distinguished – "can call" ≠ "currently callable".

Sub‑Agents provide context isolation, parallelism, and specialization.

The three‑layer memory separates cloud portrait, user habits, and project logs.

Working Modes, Result Presentation, and Automations turn a single conversation into a repeatable product.

The industrialisation of AI applications is arriving; in the next 3‑5 years every domain‑specific AI will adopt this pattern of rules, skills, tools, memory, and interaction modes orchestrated by a unified large‑model engine.