Change log

• This section was proposed by community contributor @wikimatt and edited by ADPS.

• 本节由社区贡献者 @wikimatt 提出，经 ADPS 编辑整理。

• For most of the past decade, practice in artificial intelligence has run ahead of theory. The rapid spread of agents since late 2025 is a clear case: it did not follow from a body of theory, but accumulated as one concrete problem after another was solved. The first question any theory now owes an answer to is why agents sit at the centre of a "large model plus agent" system.

• One account that fits the history is that the dividing line runs through verifiability. Without a validation step, a large model can reason on indefinitely and with complete confidence, because nothing in the loop forces it to stop and concede an error. During that period the applications that worked commercially were largely those where truth did not have to be adjudicated. Companionship and emotional value do not depend on external facts to be judged correct, so they escaped the constraint, and they are also not productivity tools.

• Tool calls and agents changed this. For the first time, model output could be checked against the external world: calls return, actions have consequences, and results can be compared with a target state. That shift is what moved AI from emotional value toward productivity. The first productivity domain to commercialise at scale was AI-assisted programming, and one reason is that programming carries several layers of native adjudication. Compilers, type checks, test cases, and run results all return a definite verdict within a short interval.

• This yields a judgement that runs through the rest of this article. Whether a domain can be turned into productive work by an agent depends substantially on whether its validation can be made to work. Different stages will place the bottleneck on different technologies, but validation remains the variable that sets the ceiling. The first ADPS Reflection workshop recorded a related conclusion from another direction: when ground truth arrives determines which layer a correction should close in.

• This section was proposed by community contributor @wikimatt and edited by ADPS.

• 近十年的人工智能进展，实践大多走在理论前面。2025 年底以来 Agent 的快速扩散尤其如此：它不是从一套理论推导出来的，而是一个个痛点被逐个解决之后累积出来的结果。补上理论这一课，第一个要回答的问题是，Agent 为什么会在“大模型加 Agent”这类方案里处在中枢位置。

• 一种能解释这段历史的说法是，分界线在于输出能不能被检验。缺少验证环节时，大模型可以一本正经地一直推理下去，没有任何机制让它停下来认错。在那个阶段，商业上跑得比较顺的多是不需要判定真伪的场景：陪伴与情绪价值不依赖外部事实确认对错，因而不受这一限制，同时也不构成生产力工具。

• 工具调用和 Agent 出现之后，模型的输出第一次可以被外部世界检验。调用有返回，动作有后果，结果可以和目标状态比对。AI 由此从提供情绪价值转向提供生产力。第一个大规模商业化的生产力场景是 AI 编程，一个重要原因是编程天然自带多层裁判：编译器、类型检查、测试用例和运行结果，都能在很短的时间内给出确定的判定。

• 由此得到一条贯穿本文的判断。一个场景能不能被 Agent 变成生产力，很大程度上取决于它的验证能不能做好；不同阶段会有不同的关键技术成为瓶颈，验证则始终是决定上限的那个变量。ADPS 反思模块第一次研讨会从另一个方向记录过相近的结论：真值什么时候到达，决定了修正应该闭合在哪一层。

• 本节由社区贡献者 @wikimatt 提出，经 ADPS 编辑整理。

• An engineer with experience in enterprise software raised this problem in conversations with Jia Huang. His initial interest in content-production agents shifted toward office workflows and commerce, where he had existing development experience. He later reported combining Embabel with business code and described a separate constraint: a client would not open its legacy source, so additional capabilities needed an external integration. These reports motivate the design questions below, without establishing measured production outcomes.

  The earlier wording contained an unconfirmed social handle and is withheld from the public record.

• The practical questions originated in conversations between an engineer and Jia Huang from July to September 2026. Customer information is omitted. The replacement-shipment workflow, data structures, and code are explanatory designs, not measured results from the engineer's project. The article does not predict that one development category will replace the others.

  The earlier wording contained an unconfirmed social handle and is withheld from the public record.

• 一位有企业软件项目经验的工程师朋友，在与黄佳的交流中提到了这些约束。七月，他在考虑用内容生产流程展示 Agent 设计，后来转向 OA 与电商，因为这些场景能接上自己做过的业务。九月，他反馈已把 Embabel 与已有业务代码结合使用，也提出了另一个限制：客户不开放原系统代码，新增能力需要从外部接入。他转来的可塑软件资料，为这类改造提供了一个比较角度。

  The earlier wording contained an unconfirmed social handle and is withheld from the public record.

• 这位工程师提出把部分业务以 MCP 工具形式接出来。MCP 提供工具发现、调用及输入输出描述的协议。工具可以由适配器实现，再调用已有业务 API。客户无需先交出整个系统的源码，开发者也能围绕被允许的能力增加 Agent 工作流。MCP 工具规范

  The earlier wording contained an unconfirmed social handle and is withheld from the public record.

• Embabel 值得作为另一条实现路线研究，其公开项目将领域对象、动作、目标与条件放进 JVM 和 Spring 的开发环境。已有 Java 团队可以据此考察怎样复用业务服务。这位工程师对它的采用提供了一条实践线索，但目前不足以据此判断它普遍优于其他框架。Embabel 项目

  The earlier wording contained an unconfirmed social handle and is withheld from the public record.

• 实践问题来自一位工程师朋友与黄佳在 2026 年 7 月至 9 月的交流。本文保留业务约束，不公开客户资料。补发申请、数据结构及代码用于说明设计，未作为该工程师项目的实测结果。本文不预判某类开发平台会取代其他类别。

  The earlier wording contained an unconfirmed social handle and is withheld from the public record.

• Malleable Software: Adding Agents to Existing Business Systems examines integration without source access, approval of business drafts, and verification of external results.

• 可塑软件：在既有业务上增加 Agent 能力 讨论源码受限时的接入方式、业务草案审批及结果核验。

• Topics/Pattern Composition

• The dual-axis framework locates a pattern by cognitive function and execution topology. A working system needs another design step: connecting several patterns into a path that can run, fail, and recover.

• A composition is a directed relationship graph. Its nodes are patterns or business steps. Its edges carry data, state, authorization, and evidence. The matrix remains two-dimensional; composition is recorded outside it as a runtime graph. More patterns do not strengthen a design by themselves. The interfaces must be explicit, including who stops, rolls back, or takes over when a step fails.

• Patterns/Composition tools/Common Pattern Compositions

• The dual-axis framework is a map of patterns. Applications, data, people, policy, waiting states, and acceptance points make up the task terrain. Two teams can choose the same patterns and still produce different architectures because they place facts and responsibility differently.

• A composition is a directed task graph. Its nodes are business activities or patterns. Its edges carry task identity, business state, authority, and completion evidence. For every consequential edge, the design names the producer, consumer, mutation rights, and the owner of stop, compensation, or takeover.

16 further paragraph changes not shown

• External tool protocols such as MCP: Record source and version, validate schemas and descriptions, and admit each server under the organization's trust policy.

  External tool protocols such as MCP: A new tool crosses a trust boundary. Record its source and version, then review descriptions, parameters, permissions, and runtime behaviour according to risk.

• Fixed procedures: Programmatic Tool Calling can move call order into the engineering layer while the model supplies bounded parameters or interprets results.

• Tool-heavy work that can be expressed as a local program: For example, read inventory from several stores, filter missing items, and query substitutes for each one. With Programmatic Tool Calling, the model writes a bounded program that loops over or parallelizes calls to registered tools inside a sandbox, reduces the results, and returns only the needed information to context. The model-generated program expresses call order; engineers do not predefine that exact sequence. A1 still governs tool registration, authority, quotas, and admission for every call.

• MechanismHow work advancesPrimary boundary Direct tool callingThe model selects one tool and its arguments, observes the result, and then chooses the next stepA1 selects and admits each call ReActReasoning, action, and observation alternate; each observation informs the next decisionUseful when the route is uncertain and work must proceed by inspection, usually with more model round trips Programmatic Tool CallingThe model writes a bounded program that loops, branches, or parallelizes calls to registered toolsThe program owns local control flow; tool identity, authority, and side-effect boundaries remain in force CodeActThe model uses executable code as its action language for computation, libraries, and available capabilitiesThe action space is broader than a registered-tool catalogue and needs stronger isolation for code, resources, and credentials

• These labels describe different layers. A1 governs tool registration, candidate selection, and call admission. A2 can schedule a multi-stage plan. ReAct, Programmatic Tool Calling, and CodeAct describe how a step proceeds at runtime. Code generated in one run becomes M5 Procedural Memory only after validation, naming, versioning, and approval for reuse across tasks.

• Plan-and-Execute (A2): A2 schedules the task graph. Each executable step may invoke A1 to select an eligible tool.

1 further paragraph changes not shown

• Topics/Pattern Selection Card

  Patterns/Composition tools/Pattern Selection Card

• The card captures an initial architecture hypothesis and works well during interviews or workshops. Before implementation, use the Six-Step Selection Method to add a baseline, constraints, pattern seams, and ablation tests. After release, evaluation receipts record whether the composition actually improved the target measure. The three records answer what the team plans to build, why it chose that design, and whether the result worked.

• Composing Agent Patterns

• Six-Step Selection Method

• Common Pattern Compositions

• View in the ADPS Chronicle

• View in the ADPS Chronicle

• View in the ADPS Chronicle

• 专题/Agent 模式组合

• 双轴框架帮助团队定位模式：当前问题属于哪种认知功能，采用哪种执行拓扑。真实系统还要完成下一步，把多个模式连接成一条能运行、能失败、能恢复的路径。

• 模式组合是一张有方向的关系图。节点是模式或业务步骤，边是数据、状态、授权和证据的交接。它不增加第三条坐标轴，也不要求每个方案覆盖更多模式。组合质量取决于接口是否明确，以及失败时能否判断由谁停止、回滚或接管。

• 模式/组合工具/常见模式组合

• 双轴框架是一张模式地图。企业里的应用、数据、人、政策、等待状态和验收点构成任务地形。两个团队可以选择同一组模式，因为事实和责任放置的位置不同，最后仍会形成两套架构。

• 模式组合是一张有方向的任务图。节点是业务活动或模式，边上传递任务身份、业务状态、授权和完成证据。每条重要的边都要回答谁生产、谁消费、谁可以修改，以及失败后由谁停止、补偿或接管。

13 further paragraph changes not shown

• 接入 MCP 等外部工具协议：外部工具来源不可信，必须靠元数据里的来源标记加额外安全审查。

• 固定流程任务：可以更进一步走 Programmatic Tool Calling，由工程层显式编排调用序列，模型只负责填参数和解读结果，减少来回、容错更强、审计更清晰。

• 接入 MCP 等外部工具协议：工具跨越了新的信任边界，需要记录来源和版本，并按风险检查描述、参数、权限与运行行为。

• 工具密集、可用局部程序表达的任务：例如从多家门店读取库存、筛选缺货项，再为每项查询替代品。模型可以通过 Programmatic Tool Calling 生成一段受限程序，在沙箱内循环或并行调用已注册工具，先汇总结果，再把必要信息交回上下文。调用顺序来自模型生成的程序，并非工程人员预先写死；工具注册、权限、配额和每次调用的准入仍由 A1 控制。

• 运行方式如何推进任务主要边界 直接工具调用模型选择一个工具和参数，取得结果后再决定下一步每次调用都经过 A1 的候选选择和准入 ReAct推理、行动、观察交替进行；新观察直接影响下一轮判断适合路径尚不确定、需要边做边看的任务，模型往返通常较多 Programmatic Tool Calling模型先写受限程序，再由程序循环、分支、并行调用已注册工具程序负责局部控制流，工具的身份、权限和副作用边界没有改变 CodeAct模型把可执行代码作为行动语言，用代码计算、调用库或组合可用能力行动空间比已注册工具更宽，需要更严格的沙箱、资源和凭证隔离

• 这四种名称描述的层次不同。A1 负责工具注册、候选选择和调用准入；A2 可以把多阶段任务编成计划；ReAct、Programmatic Tool Calling 和 CodeAct 则说明某一步在运行时怎样推进。一次任务里生成的代码只有经过验证、命名、版本化并允许跨任务复用后，才进入 M5 程序性记忆。

3 further paragraph changes not shown

• 模式/组合工具/模式选型卡

• 选型卡保存第一轮架构假设，适合在访谈或工作坊中快速对齐。进入实施前，再用六步选型法补上基线、约束、模式接缝和消融验证。系统上线后，评测回执继续记录这组模式是否真的改善了目标指标。三份材料分别回答“准备怎么做”“为什么这样做”和“做完是否有效”。

• 在 ADPS Chronicle 中查看

• 张海立在协作研讨会中的框架研究，经公开文档与源码复核，连接层级委派、扇出聚合、子代理隔离、独立复核以及评测与可观测性。

• 张海立在协作研讨会中的框架研究，经公开文档与源码复核，连接层级委派、扇出聚合、子代理隔离、独立复核以及评测与可观测性。

• RoleNamePublic affiliation ChairHuisheng YinVice President, Geekbang Technology; member of the Tencent Cloud Architects Alliance Hall of Fame ChairJia HuangADPS initiator; author of Designing AI Agents (Manning) Core participantQingfeng LiSenior Director, Sina Weibo Core participantDong ZhangExpert Engineer, Tencent; head of Wukong R&D security Core participantHan ZhaoAIGC multimodal reasoning, Ant Core participantFuhai ZhongSenior Technical Expert, Qunar Core participantYuke XiongTechnical Architect and Founding Partner, Chengdu Xuanxu Technology Core participantDidi LiBusiness Lead, Shuzhi Yuanjing

  RoleNamePublic affiliation ChairHuisheng YinVice President, Geekbang Technology; member of the Tencent Cloud Architects Alliance Hall of Fame ChairJia HuangADPS initiator; author of Designing AI Agents (Manning) Core participantQingfeng LiSenior Director, Sina Weibo Core participantDong ZhangExpert engineer and architect, Tencent Core participantHan ZhaoAIGC multimodal reasoning, Ant Core participantFuhai ZhongSenior Technical Expert, Qunar Core participantYuke XiongTechnical Architect and Founding Partner, Chengdu Xuanxu Technology Core participantDidi LiBusiness Lead, Shuzhi Yuanjing

• 角色姓名公开身份 主持人尹会生极客邦科技副总裁，腾讯云架构师技术同盟名人堂专家 主持人黄佳ADPS 发起人，Manning《Designing AI Agents》作者 核心研讨嘉宾李庆丰新浪微博高级总监 核心研讨嘉宾张栋腾讯专家工程师，悟空研发安全负责人 核心研讨嘉宾赵翰蚂蚁 AIGC 多模态推理方向 核心研讨嘉宾钟福海去哪儿网资深技术专家 核心研讨嘉宾熊钰柯成都玄宿科技技术架构师、创业合伙人 核心研讨嘉宾李娣娣数智元镜产品业务负责人

  角色姓名公开身份 主持人尹会生极客邦科技副总裁，腾讯云架构师技术同盟名人堂专家 主持人黄佳ADPS 发起人，Manning《Designing AI Agents》作者 核心研讨嘉宾李庆丰新浪微博高级总监 核心研讨嘉宾张栋腾讯专家工程师、架构师 核心研讨嘉宾赵翰蚂蚁 AIGC 多模态推理方向 核心研讨嘉宾钟福海去哪儿网资深技术专家 核心研讨嘉宾熊钰柯成都玄宿科技技术架构师、创业合伙人 核心研讨嘉宾李娣娣数智元镜产品业务负责人

• Pattern Selection Card

• Coordinate Collaboration × Chain (pass) Cost Medium (each handoff adds one LLM call) Pattern group Collaboration patterns Summary Split a long process into N agents with clearly scoped responsibilities. After one agent finishes its leg, it passes the critical state to the next through a structured HandoffPacket (not raw text), and each agent is good at only one thing.

  Coordinate Collaboration × Chain (pass) Cost Medium (each handoff adds validation, persistence, and routing latency) Pattern group Collaboration patterns Summary Split a long process across agents with bounded responsibilities. Each agent returns a structured HandoffPacket with the state, evidence, open questions, and authority the next agent needs.

• When multi-agent systems fail, it is often not because any single agent is too weak, but because the handoff dropped the baton. A front-line agent holds all of the customer's information; when it transfers to the second tier, it passes only "the verbatim text of the customer's last sentence." The second tier picks up like a colleague who just walked in—with no idea who the customer is, why they are upset, or what has already been said—and so it asks again.

• A handoff fails when the next agent receives only the customer's last message. It lacks the customer identity, prior actions, unresolved issue, escalation reason, and permissions carried by the previous agent. The second agent then repeats questions or acts on incomplete state.

• Vertical axis · Collaboration: the output of one agent is the input of the next—relay-style multi-agent collaboration. Each leg is a peer with a clearly scoped responsibility, with no supervisor as a stable anchor—this is its biggest difference from Hierarchical Delegation.

• Horizontal axis · Chain: N agents pass strictly in sequence, neither in parallel nor in a loop. This differs from Fan-Out/Aggregate, where N workers run at the same time, and from Adversarial Review, where there is back-and-forth debate. Order sensitivity is its defining trait.

• A single handoff keeps the baton from dropping through three things:

37 further paragraph changes not shown

• Coordinate Reasoning × Parallel (fan-out) Cost High (multiple branches plus aggregation) Pattern group Reasoning patterns Summary Within a single query, deliberately launch N independent reasoning chains, then use an aggregation strategy to synthesize one answer. Trade compute for accuracy.

  Coordinate Reasoning × Parallel (fan-out) Cost High (multiple branches plus aggregation) Pattern group Reasoning patterns Summary Run independent reasoning branches, preserve their evidence, and aggregate only when measured quality gains justify the added cost.

• A single reasoning chain carries a "lucky-draw bias": with the same prompt and the same model, different samples do not necessarily produce the same answer. If one chain happens to go off course, the whole conclusion is wrong, and every step looks correct along the way—the error hides in "the one feature this particular run happened to miss," which is hard to spot in a post-mortem.

• Parallel exploration replaces "bet on one chain" with "run independent chains, then merge." It does not aim to lower call cost. It spends additional compute when the cost of being wrong justifies broader evidence and independent candidates. It is complementary to complexity routing (R2): routing controls routine cost, while parallel exploration is reserved for decisions that benefit from multiple paths.

• Vertical axis · Reasoning: what runs in parallel is multiple candidate paths of the same reasoning task (several candidate solutions). This sits at the reasoning-strategy layer, rather than splitting the task across multiple agents. This is the fundamental difference from the collaboration module's "fan-out aggregation (C2)"—the latter parallelizes subtasks, the former parallelizes multiple solutions to the same problem.

• Horizontal axis · Parallel: N branches run at the same time, unaware of one another, and are aggregated in a single step at the end. This is a natural parallel structure, neither a serial chain nor an iterative loop.

• One reasoning run may omit a relevant feature or settle on a weak hypothesis. Repeating the same configuration can reproduce the same blind spot, while ordinary review sees only the selected result.

31 further paragraph changes not shown

• Coordinate Collaboration × Hierarchy (split) Cost High (multiple worker calls plus coordination and synthesis) Pattern group Collaboration patterns Summary A supervisor agent dynamically splits a task, dispatches it to N worker agents for execution, and then merges the results. This is the classic multi-agent supervisor-worker collaboration.

  Coordinate Collaboration × Hierarchy (split) Cost High (multiple worker calls plus coordination and synthesis) Pattern group Collaboration patterns Summary A supervisor delegates bounded tasks and authority to workers, then verifies and integrates their artifacts against a shared contract.

• A single agent that researches, writes the body text, produces figures, and assembles the report all at once is not specialized in any of them, and across a long workflow its context keeps growing. The more subtle problem is this: when one agent processes several subtasks in sequence, the execution details of the earlier tasks stay in its context the whole time, and by the third or fourth task its reasoning quality starts to degrade.

• Hierarchical delegation replaces "one all-purpose agent" with "one supervisor plus several specialized workers." The supervisor splits the task, monitors progress, and merges the output; each worker only does the one kind of work it is good at, running in its own isolated context. This lets each segment of work be handled by an appropriate model and prompt, and it also frees the supervisor's context from execution details so it can focus on coordination. The price is that token consumption rises by a multiple, so this pattern only fits scenarios where the value of the task can cover that multiple.

• Vertical axis · Collaboration: This is genuine multi-agent role differentiation—the supervisor and the workers are different agents that carry different responsibilities, not an engineering abstraction inside a single agent. Researcher, Writer, and Visualizer each correspond to one professional capability, and this division of labor by occupational ability is the classic form of multi-agent collaboration.

• Horizontal axis · Hierarchy: The topology is a tree. The orchestrator sits on top and several workers sit below; workers do not communicate directly, and to exchange information they must go through the supervisor. This is a natural hierarchical structure, distinct from the fan-out aggregation of Parallel, the review loop of adversarial review, and the sequential handoff chain.

• A single agent may need to research, draft, generate figures, and assemble a report while carrying every intermediate trace in one context. As the workflow grows, earlier tool output and local decisions compete with the current coordination state.

30 further paragraph changes not shown

• Coordinate Action × Orchestrate (coordination) Cost Medium (plan once, execute many times; heterogeneous models can cut cost substantially) Pattern group Action patterns Summary The agent first generates a complete plan (with dependency structure, resource estimates, approval nodes), then executes against the plan, doing local replanning rather than a full rewrite when it drifts.

  Coordinate Action × Orchestrate (coordination) Cost Medium (plan once, execute many times; heterogeneous models can cut cost substantially) Pattern group Action patterns Summary Represent a long task as a versioned dependency plan, execute ready steps, and replan affected future work when assumptions change.

• In a long process, a purely reactive Agent can lose the global sequence. An HR recruiting Agent may send compensation information after rejection, skip a required background check, or query the same record repeatedly when each step is chosen only from the latest observation.

  In a long process, a purely reactive agent can lose the global sequence. An HR recruiting agent may send compensation information after rejection, skip a required background check, or query the same record repeatedly when each step is chosen only from the latest observation.

• Plan-and-Execute splits the action side into two phases: plan first, then execute. The planning phase lays the task out in one pass as an ordered sequence of steps, marking dependencies, resources, and the nodes that require human review; the execution phase advances against the plan. Its value is in taking the macro-level ordering out of the model's in-the-moment judgment and pinning it into an auditable plan.

• Vertical axis · Action: the agent does not execute a single step; it turns a goal into a sequence of outward actions. The two-phase "think first, then act" belongs to the action side, not the single-point thinking of the reasoning side.

• Horizontal axis · Orchestrate: the center of Plan-and-Execute is an orchestrator—it holds the complete plan, schedules each step along the dependency graph, maintains global state and checkpoints, and does local replanning when things drift. This differs from the pure chaining of prompt chaining (A3): A3 is a linear hand-off where the previous segment's output feeds the next, whereas A2 is a central node coordinating multiple steps, where independent steps can expand in parallel, key nodes drop checkpoints, and errors can roll back and replan. This layer of coordination and recovery is exactly what distinguishes Orchestrate from Chain.

• Plan-and-Execute represents the task as a versioned plan before execution. The plan records dependencies, expected artifacts, resources, approval nodes, and acceptance conditions. A scheduler advances ready steps, writes checkpoints, and replans affected future work when assumptions change.

29 further paragraph changes not shown

• Fan-out / gather splits a large task into independently executable subtasks, distributes them to parallel sub-agents, and aggregates the results at the end. It usually spends more total compute to reduce wall-clock time, although provider limits and the gather stage prevent ideal linear speedup. Dispatch is the easy part; merging the results is where most of the engineering lies. When workers see overlapping material, the aggregation stage must deduplicate and resolve conflicts.

• Vertical axis · Collaboration: This splits one task across multiple sub-agents that work in parallel and then summarize. The entities being distributed are different subtasks, which makes it a multi-agent collaboration topology. This differs from parallel exploration in the reasoning module—the latter parallelizes multiple solution paths for the same problem (a reasoning strategy), while the former parallelizes different subtasks split across different agents (a collaboration topology).

• Horizontal axis · Parallel: N sub-agents run simultaneously, unaware of one another, and are gathered together at the end. This is the classic map-reduce parallel structure. It is neither sequential chaining nor loop iteration.

• Fan-Out/Gather splits a task into independent work units, runs them concurrently, and combines typed results. It may trade higher total compute for shorter wall-clock time. Provider limits, shared dependencies, output overlap, and aggregation determine the actual speedup.

• Vertical axis · Collaboration: Fan-Out/Gather assigns independent work units to multiple participants and combines their typed results. Parallel Exploration (R3) instead runs alternative hypotheses or solution paths for the same decision.

• Horizontal axis · Parallel: Work units run concurrently without consuming one another's intermediate state. A gather owner combines their artifacts and records partial failures.

29 further paragraph changes not shown

• Coordinate Reasoning × Hierarchy Cost Medium (the Talker carries most of the conversation on a cheap model; the expensive model is reserved for the Reasoner) Pattern group Reasoning patterns Summary Split the agent into a fast, shallow Talker and a slow, deep Reasoner that coordinate through a shared belief state, so the agent can think deeply while still talking to the user in real time.

• Coordinate Reasoning × Hierarchy Cost Medium (interactive and asynchronous paths can use independently evaluated models and budgets) Pattern group Reasoning patterns Summary Keep live conversation responsive while a separate Reasoner updates versioned shared state under timeout and stale-result controls.

• Vertical axis · Reasoning: It separates two reasoning modalities, real-time response and deep reasoning, into a dual-process reasoning architecture — corresponding to Kahneman's System 1 (fast, automatic, low-cost) and System 2 (slow, deliberate, high-cost). This is an engineering mapping of cognitive science onto agents, not a single reasoning channel.

• Horizontal axis · Hierarchy: The Talker is in front (fast, shallow) and the Reasoner behind (slow, deep). This is a layered division of labor, not parallel competition. The two differ in responsibility, model, and timing. The Reasoner's output influences the Talker's answer through the belief state, an upper-layer–lower-layer collaboration.

• Vertical axis · Reasoning: The pattern separates an interaction response from a slower analysis job. The two paths have different output contracts, latency budgets, and permissions.

• Horizontal axis · Hierarchy: The Talker owns the live turn; the Reasoner supplies a versioned analysis artifact through shared state. The Talker cannot present unaccepted background work as a conclusion.

29 further paragraph changes not shown

• Coordinate Action × Chain (relay) Cost Medium (split into N segments, N calls, but each segment can use a cheaper model to amortize) Pattern group Action patterns Pattern summary Break a complex task into a series of small tasks. Each step runs with its own independent prompt, and the output of one step becomes the input of the next, strung together to complete the work.

  Coordinate Action × Chain (relay) Cost Medium (split into N segments, N calls, but each segment can use a cheaper model to amortize) Pattern group Action patterns Pattern summary Decompose a workflow into ordered model or tool steps with explicit input, output, and acceptance contracts. Each artifact is validated before the next step consumes it.

• Prompt Chaining breaks a large task into several independent prompts processed in sequence. Each segment does only one thing, has its own role and the model best suited to it, and has its own success criterion. The difference from a single oversized prompt is that complexity can only be brought down by splitting; stuffing it into a bigger box does not bring it down.

• Vertical axis · Action: A task one prompt cannot complete is split into several sequential prompts, each of which triggers a model call or tool output. The landing point is "doing" rather than single-point "thinking," so it belongs to the Action module.

• Horizontal axis · Chain: prompt1 → prompt2 → prompt3 is a typical linear pipeline, where the output of one segment is the input of the next. It is neither routing diversion nor graph-shaped dependency. It shares the Chain topology with Plan-Execute (A2); the difference is that A3 is a pure straight line with no replan, while A2 is a DAG with replan.

• Its engineering prototype is the Unix pipe. cat data.csv | grep ERROR | sort | uniq -c strings together several single-responsibility small programs via stdin/stdout. Each program only reads input and writes output, with no need to know who comes before or after. A prompt chain reproduces the same thing at the LLM layer, where each prompt segment is a "small program."

• Prompt Chaining separates a workflow into model or tool steps that run in sequence. Each step has a bounded responsibility, an input and output schema, a model or tool selected from step-level evaluation, and an acceptance condition. The structure makes intermediate failures visible and allows a failed step to be retried without rerunning completed work.

27 further paragraph changes not shown

• Coordinate Collaboration × Hierarchy Cost Cross-cutting (a cross-cutting concern layered on top of other collaboration patterns) Pattern group Collaboration patterns Pattern summary A sub-agent runs in an isolated context and must reduce its work into a schema-formed artifact before returning. The supervisor agent consumes only the artifact, never the raw trajectory.

  Coordinate Collaboration × Hierarchy Cost Cross-cutting (a cross-cutting concern layered on top of other collaboration patterns) Pattern group Collaboration patterns Pattern summary Run each delegated worker within bounded context, tools, credentials, budget, and workspace, then return a schema-valid artifact with evidence links and failure state.

• The supervisor dispatches sub-agents, each sub-agent returns its entire working process, and the supervisor's context is quickly flooded. In a batch review, raw analyses scale with every item while the supervisor usually needs only verdicts, key findings, and evidence. It should receive the work product, not every intermediate step.

• Sub-agent isolation controls context pollution in multi-agent systems. Each sub-agent runs in an isolated context and reduces its result into a structured artifact before returning, so the supervisor consumes only the artifact. This is the boundary discipline used by hierarchical delegation and fan-out aggregation to contain context and local failures.

• Vertical axis · Collaboration: Giving a sub-agent its own context and permissions is a design that adds boundaries within collaboration. It is not simple task dispatch but adds isolation discipline to collaboration—the information flow between supervisor and sub-agent is deliberately cut down to "pass only refined conclusions."

• Horizontal axis · Hierarchy: A parent agent schedules a sub-agent, and the sub-agent runs in its own sandbox—this is a structure of hierarchy plus isolation. It shares a cell with hierarchical delegation (both sit at the Collaboration × Hierarchy intersection), but the emphasis differs—hierarchical delegation stresses dispatch, while sub-agent isolation stresses isolation plus summarized return.

• Sub-agent isolation is built from four engineering elements:

27 further paragraph changes not shown

• Coordinate Reasoning × Loop (transition) Cost High (cumulative cost over many iterations; must be bounded by circuit breakers and budget caps) Pattern group Reasoning patterns Summary The agent forms a hypothesis, validates it against evidence, revises based on the result, and loops until the evidence converges or an iteration limit is reached, bringing the scientific method into reasoning.

  Coordinate Reasoning × Loop (transition) Cost High (cumulative cost over many iterations; must be bounded by circuit breakers and budget caps) Pattern group Reasoning patterns Summary Test versioned hypotheses against evidence, revise the active set, and stop on confirmation, no progress, or a hard limit.

• Iterative hypothesis testing replaces single-pass reasoning with a loop of "hypothesize → validate → revise → hypothesize again." The fundamental difference from ordinary retry is this: retry assumes that the retry itself can solve the problem, while iterative hypothesis testing assumes that each loop must update the understanding of the world. Its design center is also not "retry until success," but converging through falsification to the single hypothesis that has not been refuted. It is the dual of parallel exploration (R3): parallel opens N lines at once along the spatial dimension, while iteration runs one line many times along the time dimension.

• Vertical axis · Reasoning: It follows empirical, scientific-style reasoning of "hypothesize → validate → revise → hypothesize," not a single deduction. Each round actively revises its own belief rather than waiting for the result to stabilize.

• Horizontal axis · Loop: Multiple iterations until the evidence converges or a limit is reached form a natural loop structure. The dual-mode architecture (R5) in the same column is also in the Loop column but has a different emphasis—iteration is a single agent looping with itself to validate hypotheses, while dual-mode is two agents collaborating to split the handling of "talking" and "thinking."

• Iterative hypothesis testing maintains a set of hypotheses and updates it after each evidence-gathering step. A retry repeats an operation under the same diagnosis. This pattern changes the diagnosis, evidence request, or experiment before the next round. Parallel Exploration evaluates several branches at once; R4 revises hypotheses across time.

• Vertical axis · Reasoning: Each round proposes or updates hypotheses, requests evidence that can distinguish them, and records a verdict.

24 further paragraph changes not shown

• Coordinate Action × Route Cost Low to medium (candidate selection, state refresh, and policy checks) Pattern group Action patterns Summary Before each step of action, the engineering layer selects the most suitable tool from the tool set based on tool metadata, rather than letting the model decide on the spot.

  Coordinate Action × Route Cost Low to medium (candidate selection, state refresh, and policy checks) Pattern group Action patterns Summary Before execution, the runtime narrows eligible tools using metadata, permissions, risk, and current state. The model chooses only within that admitted set.

• Tool Dispatch takes "which tool to choose" out of the model's hands and returns it to the engineering layer. Its core judgment is that tool selection is reliability engineering. It relies not on writing a smarter prompt, but on supplying complete metadata for each tool, plus a full set of engineering contracts: quotas, state refresh, and side-effect tracking.

• Vertical axis · Action: an agent turns decisions into outward effect through tool calls. In multi-tool scenarios, "which one to call" is the earliest and most frequent decision on the action side, so it belongs to the action module rather than the reasoning module.

• Horizontal axis · Route: it works by directing a given call to the most suitable tool based on current intent and context. This is a typical routing structure, not a chained sequence or a hierarchical wrapper. The minimal tool set (A5) in the same module also falls on the routing side, but with a different division of labor—A1 addresses "how to pick," while A5 addresses "trim before picking."

• Tool Dispatch places tool admission in the runtime. Metadata describes each tool's capability, schema, version, cost, permission requirements, and side effects. Dispatch rules apply quotas, state-freshness checks, and trace requirements before a call can proceed.

• Vertical axis · Action: Tool Dispatch selects the capability that will affect an external system and checks whether the call may proceed.

23 further paragraph changes not shown

• Discussion host Bingsheng Ru Core participants Qingfeng Li, Dong Zhang, Jun Luo, Hongshan Tang, Wei Wang, Pylon Peng, Leida Ren

  Host Bingsheng Ru Core participants Qingfeng Li, Dong Zhang, Jun Luo, Hongshan Tang, Wei Wang, Pylon Peng, Leida Ren

• Chair Jia Huang Core workshop guests Dong Zhang, Xianglong Huang, Qingfeng Li, Cheng Huang

  Host Jia Huang Core workshop guests Dong Zhang, Xianglong Huang, Qingfeng Li, Cheng Huang

• RoleNamePublic affiliation ChairHuisheng YinVice President, Geekbang Technology; Tencent Cloud Architects Alliance Hall of Fame expert ChairJia HuangADPS initiator; author of Designing AI Agents (Manning) Core participantQingfeng LiSenior Director, Sina Weibo Core participantDong ZhangExpert Engineer, Tencent; head of Wukong R&D security Core participantHan ZhaoAIGC multimodal reasoning, Ant Core participantFuhai ZhongSenior Technical Expert, Qunar Core participantYuke XiongTechnical Architect and Startup Partner, Chengdu Xuanxu Technology Core participantDidi LiBusiness Lead, Shuzhi Yuanjing

  RoleNamePublic affiliation HostHuisheng YinVice President, Geekbang Technology; Tencent Cloud Architects Alliance Hall of Fame expert HostJia HuangADPS initiator; author of Designing AI Agents (Manning) Core participantQingfeng LiSenior Director, Sina Weibo Core participantDong ZhangExpert Engineer, Tencent; head of Wukong R&D security Core participantHan ZhaoAIGC multimodal reasoning, Ant Core participantFuhai ZhongSenior Technical Expert, Qunar Core participantYuke XiongTechnical Architect and Startup Partner, Chengdu Xuanxu Technology Core participantDidi LiBusiness Lead, Shuzhi Yuanjing

• 讨论主持 茹炳晟 核心参与者 李庆丰、张栋、罗军、唐洪山、王伟、Pylon Peng、任磊达

  主持人 茹炳晟 核心参与者 李庆丰、张栋、罗军、唐洪山、王伟、Pylon Peng、任磊达

• ParticipantPublic role Qingfeng LiSenior Director, Sina Weibo Dong ZhangTencent expert engineer; head of Wukong R&D security Han ZhaoAIGC multimodal reasoning, Ant Didi LiBusiness Lead, Shuzhi Yuanjing Fuhai ZhongSenior Technical Expert, Qunar Yuke XiongTechnical Architect and Startup Partner, Chengdu Xuanxu Technology

  RoleNamePublic affiliation ChairHuisheng YinVice President, Geekbang Technology; Tencent Cloud Architects Alliance Hall of Fame expert ChairJia HuangADPS initiator; author of Designing AI Agents (Manning) Core participantQingfeng LiSenior Director, Sina Weibo Core participantDong ZhangExpert Engineer, Tencent; head of Wukong R&D security Core participantHan ZhaoAIGC multimodal reasoning, Ant Core participantFuhai ZhongSenior Technical Expert, Qunar Core participantYuke XiongTechnical Architect and Startup Partner, Chengdu Xuanxu Technology Core participantDidi LiBusiness Lead, Shuzhi Yuanjing

• The workshop reviewed the published R1–R5 specifications and the inputs, outputs, resource budgets, verification, and stop conditions needed in a production reasoning system.

• The discussion ran for two hours and twenty-seven minutes. The six participants drew on online question answering, large codebase analysis, multimodal generation, latency-sensitive user services, GIS toolchains, and physical simulation. These settings place reasoning control in different locations. A model may hold it in one system; a harness, deterministic program, or human business process may hold it in another.

• The session did not walk through R1–R5 as a catalog. It began with deciding which requests deserve deeper reasoning, then moved through tree search, speculative execution, mirror agents, external acceptance, and business evaluation sets. The closing concern was practical: after a reasoning run, what evidence and reusable control remain, and what allows the next release to be trusted?

• Which requests need deep reasoning, and which can use rules or a lightweight path?

• How do complexity, risk, evidence gaps, and latency jointly affect routing?

56 further paragraph changes not shown

• 研讨嘉宾公开身份 李庆丰新浪微博高级总监 张栋腾讯专家工程师，悟空研发安全负责人 赵翰蚂蚁 AIGC 多模态推理方向 李娣娣数智元镜产品业务负责人 钟福海去哪儿网资深技术专家 熊钰柯成都玄宿科技技术架构师、创业合伙人

• 本次研讨以 R1–R5 的公开规范为基础，检查推理在生产系统里的输入、输出、资源预算、验证和停止条件。

• 角色姓名公开身份 主持人尹会生极客邦科技副总裁，腾讯云架构师技术同盟名人堂专家 主持人黄佳ADPS 发起人，Manning《Designing AI Agents》作者 核心研讨嘉宾李庆丰新浪微博高级总监 核心研讨嘉宾张栋腾讯专家工程师，悟空研发安全负责人 核心研讨嘉宾赵翰蚂蚁 AIGC 多模态推理方向 核心研讨嘉宾钟福海去哪儿网资深技术专家 核心研讨嘉宾熊钰柯成都玄宿科技技术架构师、创业合伙人 核心研讨嘉宾李娣娣数智元镜产品业务负责人

• 这场讨论持续两小时二十七分钟。六位嘉宾带来的现场分别涉及在线问答、大型代码仓分析、多模态生成、低延迟用户服务、GIS 工具链和物理仿真。模型能力、业务知识密度、时延要求和工具成熟度各不相同，推理控制也因此落在不同位置：有时交给模型，有时写进 Harness，有时编译成确定性程序，有时必须由人补齐业务判断。

• 嘉宾没有顺着 R1–R5 逐条复述定义。讨论从“哪些请求值得深想”开始，进入树搜索、推测执行、镜像 Agent、外部验收和业务评测集，最后回到一个更实际的问题：一次推理完成以后，团队留下了什么，下次上线又凭什么相信它。

• 哪些请求值得进入深度推理，哪些可以由规则或轻量路径处理？

57 further paragraph changes not shown

• At the ADPS Collaboration workshop on 25 August 2026, Haili Zhang placed LangGraph, LangChain agents, and Deep Agents on one technical stack. This resolves a recurring source of confusion: the three names do not describe mutually exclusive agent frameworks. They own the runtime, the agent abstraction, and the harness respectively.

  At the ADPS Collaboration workshop on 25 August 2026, Haili Zhang placed LangGraph, LangChain agents, and Deep Agents on one technical stack. He showed that the three names do not describe mutually exclusive agent frameworks. They own the runtime, the agent abstraction, and the harness respectively.

• His demonstration then moved one step further. A model can write JavaScript for the current task and call tools and subagents as constrained functions. Loops, branches, parallel batches, and aggregation remain in interpreter variables. The runtime still enforces the execution boundary, while the shape of this particular workflow is determined after the task arrives.

  He then demonstrated dynamic subagents. A model can write JavaScript for the current task and call tools and subagents as constrained functions. Loops, branches, parallel batches, and aggregation remain in interpreter variables. The runtime still enforces the execution boundary, while the shape of this particular workflow is determined after the task arrives.

• The public Deep Agents architecture document defines the stack directly.

  The public Deep Agents architecture document distinguishes the three layers.

• Figure 1 · The layers own different concerns. Dynamic subagents sit between the harness and runtime rather than introducing another execution engine.

• Figure 1 · LangGraph supplies the runtime, LangChain agents assemble the agent loop, and Deep Agents provides the harness. Dynamic subagents sit between the harness and runtime.

• The application did not commit this exact graph in advance. The model generated temporary orchestration for the current input. The interpreter executes it, task() exposes configured subagents as capabilities, and LangGraph continues to hold run state and events.

  The application does not define this exact workflow graph in advance. The model generates temporary orchestration for the current input. The interpreter executes it, task() exposes configured subagents as capabilities, and LangGraph continues to hold run state and events.

23 further paragraph changes not shown

• 2026 年 8 月 25 日的 ADPS 协作模块研讨会上，张海立把 LangGraph、LangChain Agent 与 Deep Agents 放在同一条技术栈里讲了一遍。这个对照解决了一个常见困惑：三者并非三套互斥的 Agent 框架，它们分别承担运行时、Agent 抽象和 Harness 的职责。

  2026 年 8 月 25 日的 ADPS 协作模块研讨会上，张海立把 LangGraph、LangChain Agent 与 Deep Agents 放在同一条技术栈里讲了一遍。海立老师告诉我们，三者并非三套互斥的 Agent 框架，它们分别承担运行时、Agent 抽象和 Harness 的职责。

• 他随后演示了更值得展开的一步。模型可以根据当前任务写出一段 JavaScript，把工具和子 Agent 当作受控函数调用；循环、分支、并行和聚合留在解释器变量中。工作流依旧受运行时约束，具体形状则在任务到来后生成。

  随后，他演示了动态子 Agent。模型可以根据当前任务写出一段 JavaScript，把工具和子 Agent 当作受控函数调用；循环、分支、并行和聚合留在解释器变量中。工作流依旧受运行时约束，具体形状则在任务到来后生成。

• Deep Agents 公开架构文档把三层关系写得很清楚。

  Deep Agents 公开架构文档梳理了三层关系的差异。

• 图 1 · 三层解决不同问题。动态子 Agent 位于 Harness 与运行时之间，不另造一套执行引擎。

• 图 1 · LangGraph 承担运行时，LangChain Agent 组装 Agent 循环，Deep Agents 提供 Harness。动态子 Agent 位于 Harness 与运行时之间。

• 这段代码不是应用预先提交的固定工作流，而是模型根据当前任务生成的临时编排。解释器负责执行它；task() 把已经配置好的子 Agent 暴露成能力；LangGraph 继续保存运行状态和事件。

  应用没有预先提交这张固定工作流图。模型根据当前任务生成临时编排，解释器负责执行；task() 把已经配置好的子 Agent 暴露成能力；LangGraph 继续保存运行状态和事件。

25 further paragraph changes not shown

• Related open-source engineering case

• The Guardrail evolution shared by Willem Jiang uses five public pull requests to connect assembly filtering, runtime authorization, identity, policy, and audit in one tool-execution path.

• View in the ADPS Chronicle

• Related open-source engineering case

• The Guardrail evolution shared by Willem Jiang uses five public pull requests to connect assembly filtering, runtime authorization, identity, policy, and audit in one tool-execution path.

• View in the ADPS Chronicle

• Related open-source framework case

• Haili Zhang's workshop research, checked against public documentation and source, connects hierarchical delegation, fan-out/gather, subagent isolation, independent verification, evaluation, and observability.

• View in the ADPS Chronicle

• Related open-source framework case

• Haili Zhang's workshop research, checked against public documentation and source, connects hierarchical delegation, fan-out/gather, subagent isolation, independent verification, evaluation, and observability.

• View in the ADPS Chronicle

• Related open-source framework case

• Haili Zhang's workshop research, checked against public documentation and source, connects hierarchical delegation, fan-out/gather, subagent isolation, independent verification, evaluation, and observability.

• View in the ADPS Chronicle

• Related open-source framework case

• Haili Zhang's workshop research, checked against public documentation and source, connects hierarchical delegation, fan-out/gather, subagent isolation, independent verification, evaluation, and observability.

• View in the ADPS Chronicle

• Related open-source framework case

• Haili Zhang's workshop research, checked against public documentation and source, connects hierarchical delegation, fan-out/gather, subagent isolation, independent verification, evaluation, and observability.

• View in the ADPS Chronicle

• Related open-source framework case

• Haili Zhang's workshop research, checked against public documentation and source, connects hierarchical delegation, fan-out/gather, subagent isolation, independent verification, evaluation, and observability.

• View in the ADPS Chronicle

• Related open-source framework case

• Haili Zhang's workshop research, checked against public documentation and source, connects hierarchical delegation, fan-out/gather, subagent isolation, independent verification, evaluation, and observability.

• View in the ADPS Chronicle

• Related open-source engineering case

• The Guardrail evolution shared by Willem Jiang uses five public pull requests to connect assembly filtering, runtime authorization, identity, policy, and audit in one tool-execution path.

• View in the ADPS Chronicle

• The Orchestrate pattern has a central conductor that commands each agent in turn: "do this step, then that step." This structure is correct in most scenarios, but it has two hard constraints that eventually hit a ceiling. The central conductor is itself a single point: if it fails, the whole flow stops. And every new agent added requires going back to change the conductor's logic. As the number and variety of agents keep growing and business boundaries fall under different teams, this central point turns from a coordinator into a bottleneck.

• Choreography solves exactly this coupling problem at scale. It removes the central conductor and makes each agent an autonomous unit: it subscribes only to the events it cares about, reacts when an event arrives, and emits its result as a new event back onto the shared event stream, reporting to no center. The system's overall behavior is no longer written into a flowchart in one place; it emerges from every agent's local "subscribe–react–publish" rules. Adding a new agent only requires subscribing it to the events it should subscribe to, with no other agent changing a single line.

• This deserves to be a pattern of its own because it is not a parameter variant of Orchestrate but the other pole of the collaboration topology: control shifts from centralized to distributed. In structural orientation it is the opposite of centralized collaboration patterns such as fan-out/gather and hierarchical delegation.

• This is the first pattern in the Collaboration module that does not fall on one of the six core topology columns, so it needs to be spelled out explicitly, just as the Action module's minimal tool set (A5) falls on "constraint" rather than a concrete topology column.

• Vertical axis · Collaboration: Choreography describes how multiple agents coordinate; there is no single-agent version, so the vertical axis sits firmly in the Collaboration module.

• Horizontal axis · Choreography (emerging topology, not one of the six core columns): The six core topologies (Chain, Route, Parallel, Loop, Hierarchy, Orchestrate) share an implicit premise—there is a designable control point. Chain has order, Route has a router, Parallel has fan-out/gather, Loop has an iterator, Hierarchy has a manager, Orchestrate has a conductor. The defining feature of Choreography is the removal of this control point. So it is not a seventh value on the core axis but the negative pole of the dimension "is control at the center or not." It and Orchestrate are a pair of twins: Orchestrate is coordinated by a conductor, Choreography is coordinated by events.

37 further paragraph changes not shown

• A request to configure next month's payroll for the Singapore team passes through rule confirmation, pay-group creation, employee assignment, and approval. Late in the run, the newest conversation detail may concern one employee's assignment. That detail must not replace the original delivery goal.

  A payroll setup task moves through policy confirmation, group creation, employee association, approval, and submission. Late in the run, the newest conversation may focus on one employee. That detail must not replace the original delivery goal or erase earlier milestones.

• From the Dongfang Yiteng execution agent (case by Bo Liang)

• A long-running agent needs a fixed goal, an append-only progress record, and a compact view for the current step. Together they limit goal drift without sending the full history to every model call.

• The core semantics of an execution-type agent's narrative plane can be summed up in one phrase: a description of goal and progress. It works like a continuously kept set of work notes — the agent records what it has done as it executes, while preserving the user's original goal at every step. These notes are made of three elements, which the team calls anchor, ledger, and collection.

• The anchor anchors the original input of every session and conversation from the user, serving as the fixed top-level goal. In complex business scenarios the execution chain is long: from the entry point that receives the raw request, it passes through reasoning, action, and task planning, and the information is processed, expanded, or compacted as it moves downstream. If the narrative content is only a chained one-way pass where each step's output becomes the next step's input, a long path will gradually drift away from the original goal — by the task-planning stage, the input fed to the model may already have become the thoughts produced during reasoning, while the user's goal takes up only a small share. So in the context of every reasoning step, the user's original goal must be carried through as fixed data.

• The ledger is a running record of key progress, kept as appended summaries. For each completed key milestone-level reasoning or action, a semantically compacted summary is written into it. A later step, while knowing the user's goal, must also know what was done before and what results were achieved, in order to reason out what this step should accomplish. The ledger answers "where it came from, where it has reached."

11 further paragraph changes not shown

• From the Dongfang Yiteng execution agent (case by Bo Liang)

• A payroll specialist says, "Create next month's pay group for the Singapore team, reuse the headquarters rules, and ask me before submission." The team, period, and policy provide semantic context for later reasoning. "Create" and "ask before submission" must also become a known route and an approval node.

• Keeping only the sentence leaves the program without a stable branch. Keeping only a create_pay_group enum strips away the business context that later reasoning needs. Both forms belong in the runtime, but different mechanisms consume them.

• The runtime context of an execution-type agent should be split, from the very first step, into two planes of different character.

• The control plane is mechanical, deterministic, and discrete: a small set of signals that decide which branch the program takes next — small talk ends the turn, a query triggers retrieval, a task triggers planning. The narrative plane is semantic context in natural language: it feeds every reasoning step and, after reasoning, produces new control signals. Both run in parallel. Without control signals the engineering has nothing to drive it; without narrative context each reasoning step has no raw material.

• This dualism is the cognitive foundation of the whole system. It answers the question that stalls most people new to agent work: where do you even grip something described with words like "intelligence" and "uncertainty"? The move is to convert the live and uncertain into the dead and controllable first — because only the dead can be controlled, and control is mechanical by nature.

9 further paragraph changes not shown

• From the Dongfang Yiteng execution agent (case by Bo Liang)

• A payroll configuration job must remember why the user chose a rule, preserve the exact pay_group_id returned by a tool, and know whether the "attach employees" node has completed. All three move through one session, but they have different structures and validation rules.

• Putting everything into a conversation summary can lose exact identifiers and dependencies. Putting everything into one generic state map mixes semantic notes, business parameters, and scheduling state.

• All of the runtime context within a single session should not be read and written in one place. The unified session state plane splits this context into three planes with clear responsibilities. Each plane answers one question, uses one data form, and does not cross into another's territory. This is the backbone design that the Dongfang Yiteng execution agent finally settled on.

• Separation of powers means that the narrative, mechanical, and scheduling planes each govern one segment. The narrative state plane gathers, in natural language, what the user wants and how far the work has gotten. It is the agent's perception and understanding of the world and the current situation: some information is kept in full, some is compacted and distilled, some lives only in memory, and some is persisted to storage and even given a vector index. The mechanical state plane governs the API parameter dictionary alone. It answers where a parameter came from and whether it is correct. It stores strict key-value pairs, every parameter carries a provenance coordinate, and it is auditable and able to fail fast on error. The task scheduling state plane cares only about the order and status of the nodes in the task graph. It answers which step runs first and whether a step has finished. A downstream node can only be started once all its upstream nodes are complete and the node itself is ready. The three planes speak three languages about three things: progress in natural language, parameters in machine-readable key-value pairs, scheduling in a task graph.

• The failure it prevents is the kind that recurs whenever these three things get tangled together. In the earliest scheduling context, narrative content was mixed in, and the result details of each task node were read, written, and passed in the same place. The consequence was that parameters and progress polluted each other: from a single stretch of context containing goal descriptions, intermediate thoughts, and API return values all at once, the model had to work out for itself which value was the id to bind in the next step. In an enterprise business system, such an id is often a random string of dozens of characters generated by a snowflake algorithm. Asking the model to pull it verbatim out of the mixed context and then bind it is highly unreliable — it sometimes succeeds and sometimes fails, and when it fails is neither controllable nor predictable. Once the three things are separated, parameters go through the mechanical plane and are passed mechanically by the program rather than generated by the model, progress goes through the narrative plane, and scheduling goes through the task graph. Each line is independent, and drift on one line does not spread to another.

9 further paragraph changes not shown

• From the Dongfang Yiteng execution agent (case by Bo Liang)

• After payroll calculation, the agent pauses before submission and presents the batch, employee count, total, and exceptions. Approval may arrive hours later. The browser may disconnect, and business data may change in the meantime.

• This requires more than a confirmation dialog. The runtime persists a waiting state, the proposed action, and parameter provenance, then revalidates execution conditions after authorization.

• When an execution-type agent runs a business process on its own, there are a few positions where it should not be allowed to execute all the way through. Deleting a batch of data, issuing a payroll disbursement, filing a tax return — once one of these actions goes wrong, it cannot be rolled back. Human-in-the-loop (HITL) means stopping the execution flow at these critical positions, waiting for a person to review and confirm, and only then letting the agent continue all the way down. The hard part is not the stop, but how to fully restore the execution state once you have stopped.

• This stop-and-resume mechanism comes in two forms, an order of magnitude apart in engineering complexity.

• The first is narrative-plane continuation. At its core it still generates content from narrative context. The typical scenario is an AI coding IDE, where the agent has worked out a way to make changes but worries about breaking the existing logic, so it ends the current turn and asks you to confirm. In the next turn you type "continue" or "confirm," and it reads the full narrative context in the session and finishes the code change. This form is easy to implement, because all you need is to end the current turn and let the user start a fresh natural-language turn next time; everything needed to resume sits in the narrative state.

8 further paragraph changes not shown

• From the Dongfang Yiteng execution agent (case by Bo Liang)

• After creating a pay group, an API returns pay_group_id=pg_84721. The employee-assignment step needs that exact value and evidence of which call and tenant produced it. If a model first summarizes "the Singapore pay group was created" and later reconstructs the identifier, a tool fact has become a probabilistic generation.

• Values consumed directly by later APIs, including entity IDs, currencies, time ranges, and idempotency keys, need programmatic storage with provenance.

• The mechanical state plane is the layer of an execution-type agent's runtime context that governs business API parameters. It separates the reading, writing, binding, and passing of state values entirely from the content the LLM touches, so that every API call's input parameters have a single, auditable, fail-fast mechanical source rather than being generated on the spot by a model that drifts.

• Picture it as a whole wall of small cells, built when the agent starts. Each cell corresponds to one mechanical parameter, and its key is determined by two things together: which tool supplies the parameter, and at which runtime stage it is produced. Along the session's timeline, each cell holds only the latest value of that parameter. Whoever needs a piece of state reads it from the corresponding cell, instead of letting the model guess it out of a long stretch of narrative context. Every parameter in the runtime corresponds to a Provenance structure, assembled by parsing the various specifications and descriptions into a single coordinate — key name plus scope plus supplier plus production stage. All reads and writes go by this coordinate, so a parameter's ownership and value stay unambiguous.

• The failure it prevents is concrete. The first step of building a payroll group calls a template-matching interface; on a match it returns a template_id, and downstream, when the template is imported, that id must be passed in verbatim. The trouble is that the various ids in an enterprise are commonly 64-bit or even 128-bit random strings generated by snowflake algorithms. Asking a model to read the conversation and then reproduce such an id exactly — every character restored correctly, not one digit off — is something models still cannot do today. The reason is that an LLM is a stateless probabilistic function: even when told the id's value in context, it does not take your parameter by value; it only tries to regenerate an approximate string. In this scenario, an id missing one digit fails validation, and a wrong digit is worse — the agent may execute "successfully" while the business data is quietly corrupted, and the expected state change never happens.

8 further paragraph changes not shown

• From the Dongfang Yiteng execution agent (case by Bo Liang)

• While checking Singapore provident-fund rules, the agent needs the original goal, the selected pay group, confirmed policy evidence, and perhaps one relevant prior failure. It does not need the full conversation replay or sensitive records for unrelated employees.

• Reasoning input should therefore be assembled for the current step as a bounded, inspectable package, rather than formed by concatenating all available history.

• Every reasoning step of an execution-type agent first assembles an input struct before handing it to the model. In Dongfang Yiteng's code this struct is called ReasonContext; the name ADPS gives it is the memory envelope — at every step you seal an envelope and hand it to the model, and it holds only what this step needs to see.

• An envelope usually holds four things: the anchor, the original goal of the user session; the current progress (collection) projected and trimmed out of the ledger; the conclusion drawn by upstream intent recognition; and the relevant lessons recalled from the experience store. When needed, it also attaches the necessary mechanical state. Once this package is assembled, the model at this step knows where it is going, how far it has come, and what mistakes others made in similar spots. What goes into the envelope is narrative content, the semantics the model is to understand; the control signals the program branches on travel through a separate channel and do not enter the envelope.

• What the memory envelope guards against is two kinds of distortion in a long chain. The first is goal drift: the execution chain receives the original request at the entry point and runs it through reasoning, action, and task planning, with the information reworked, expanded, or compressed as it is passed down. If the context simply takes the previous step's output as the next step's input, fed straight down a single-pass chain, then over a long enough path the original goal's share is diluted. By the task-planning stage, what is fed to the model to generate a plan may consist mostly of the trains of thought from the reasoning process, with what the user actually wants reduced to a fraction. The most typical case is when the user replies with nothing but "continue" in a new turn: without the anchor, the model either cannot understand what "continue" means or acts wildly on its own interpretation. Fix the anchor into every envelope, and this kind of distortion is blocked.

8 further paragraph changes not shown

• The same model can draft a payroll policy memo or create a pay group in a production system. A memo can be revised or regenerated. A pay-group action writes employee, calculation, and approval data; one bad call can leave a real side effect for every later step.

  The same model can draft a payroll-policy note and create a payroll group. The first task delivers text that a user can revise or regenerate. The second changes employee, payroll, and approval records; one misbound identifier can affect later steps and external systems.

• From the Dongfang Yiteng execution agent (case by Bo Liang)

• The label "agent" therefore says little about the required runtime. The delivery object and failure cost determine whether the system needs explicit state, idempotency, approvals, and resumable execution.

• Before designing an agent, answer a question that comes earlier than the technology: is it meant to deliver content, or to deliver execution? This classification decides which way the whole architecture leans afterward.

• A content-generation agent is centered on output. Tools are loosely orchestrated, and parameters can be synthesized on the spot by the LLM. Research reports, travel assistants, and slide writing all fall in this category: query sources in parallel, summarize, feed the result into report generation, then add a review-and-quality-check pass. What each step passes along is mainly text content, with no strict mechanical state binding. An execution-type agent is different. It takes the user's business intent as input and, through a reliable orchestrated sequence of business API calls, delivers a complete business process automatically. It values delivery over generation; the steps have strict ordered dependencies, and what they pass along are mechanical parameters such as ids, status codes, and entity references. One step out of order, or one parameter wrong, and the delivery fails.

• The difference between the two can be drawn against gacha. A content-generation agent has a second chance: draw a card you do not like, and you just generate another. Retrying costs almost nothing, which is the root of its tolerance for LLM drift. An execution-type agent has no such tolerance — once business data is touched by mistake, there is no redo. The difference in fault tolerance is what makes the reliability requirements of the two categories different by design.

7 further paragraph changes not shown

• From the Dongfang Yiteng execution agent (case by Bo Liang)

• "Prepare next month's payroll for the Singapore engineering team" is clear to a person but is not an executable branch. The system must narrow it to a known action such as create_pay_group, while extracting the team, period, and unresolved policy fields.

• Compilation also needs a defined failure result. A request that mixes query and modification, or lacks a required scope, should enter unknown or clarification instead of guessing a tool.

• Intent recognition compiles the user's natural language into explicit, identifiable control signals that the orchestrator can execute. At bottom it is also a reasoning step, except that this reasoning produces not a reply but a discrete signal that a program can read and use to choose a downstream branch.

• Calling this step "compilation" is appropriate because it does the same thing a compiler does: the source is live, uncertain, free-form input; the target is dead, controllable instructions that a machine can execute directly. The spoken request "help me set up a payroll group" is something the model understands but the program does not; the program understands only "this is a resolve signal." Intent recognition stands between the two, using a prompt to guide the LLM toward structured output, converging and abstracting the user's intent onto the few downstream control signals the system can accept. From this step onward, the program faces a fixed value within an enumeration, not a stretch of semantics that might drift.

• What this step prevents is feeding natural language straight into the control flow. Without compiling first, the program would have to ask the model, at every branch point, "what does the user actually want right now," letting a probabilistic model decide which path to take next. An LLM is a probabilistic model; handing deterministic branch decisions to it for on-the-spot judgment produces a result that is sometimes right and sometimes plainly wrong, and when it fails is neither controllable nor predictable. The compilation step handles uncertainty all in one place: divergent semantics converge once at the entrance into a fixed signal, and the control flow that follows is a clean state machine that can be unit-tested and replayed.

7 further paragraph changes not shown

• From the Dongfang Yiteng execution agent (case by Bo Liang)

• A user sees "pay group configured" and later finds that two employees were never attached. The developer needs one timeline showing how intent was classified, which node the scheduler selected, which parameters the tool received, what the API returned, and when the state changed to completed.

• Ordinary service logs can show that a process ran. Agent diagnosis also needs the decision chain and its effects represented as correlated events.

• A single conversation with an execution-type agent sits on top of a long string of invisible actions: recognizing intent, routing branches, chained reasoning, calling tools, reading and writing state, synthesizing a reply. If the developer can see only two layers — the user input and the final reply — and everything in between is a black box, then every time the system goes wrong, locating the fault comes down to guessing. Observability is what addresses this: it exposes every action the agent takes, and the thinking that drives each action, to the developer along a complete timeline.

• The word "observable" here carries a sense that should be made clear first. It does not refer to the agent's perception of the world it inhabits, but the reverse — making the agent's consciousness and behavior visible to the developer. The series of actions an agent produces within a conversation is its bodily activity; the reasoning and judgment that drive those actions are its mental activity. Observability lays both of them out to be seen.

• The glass dome metaphor comes in right here. Once the development mode turns on the full set of observable events, assembling this intricate and precise agent feels close to repairing a Swiss mechanical watch inside a transparent glass dome. A mechanical watch has many parts that mesh precisely, but as long as the dome is transparent, you can see where each gear is turning and which hairspring is moving. The agent is the same: what the intent-recognition step identified, which downstream chain the intent gateway routed it to, how far the ReAct loop has run, what prompt the LLM call at this step used, what the model returned, how much it cost — all laid out in order along the timeline. The more complex the system, the more this transparent dome eases the developer's cognitive load. It does not reduce the system's own complexity, but it makes that complexity visible and inspectable.

7 further paragraph changes not shown