Concepts/Concept
The Orchestrator and the MessageHandler Facade: The Trunk of Control Flow and the Facade of Performance
From the Dongfang Yiteng execution agent (case by Bo Liang)
Definition
Once an execution-type agent is running, every capability needs a home. That home is the Orchestrator — the orchestrator of the entire runtime execution flow, the core skeleton on which the agent runs. From the moment it receives user conversational input, it parses the control signals along the chain and orchestrates the actions at each stage according to those signals: invoking a capability, distilling memory at one stage, retrieving external knowledge, judging that the current turn is complete and synthesizing a reply. The agent's apparent understanding of intent, its memory, its ability to summarize experience, its ability to call skills and tools — all of these are, in essence, branches that grow on this trunk of control flow.
How it works
Its operating rhythm can be summed up as alternating divergence and convergence: diverge, converge, diverge again, converge again. The increment the LLM brings is the ability to converge and anchor natural-language information to control signals at every kind of boundary, thereby driving activity that looks intelligent and free. Each step looks like a free choice, yet where the next step goes has already been constrained by the control signals that came before. Natural language is responsible for divergence, control signals for convergence, and the Orchestrator for re-converging the diverged result back into deterministic control flow at every stage.
The Orchestrator need not be exposed at the outermost layer. The outermost layer wraps a thin MessageHandler facade, which receives user input and passes it to the Orchestrator, dedicated to the capabilities of the user-facing presentation layer. As the Orchestrator executes, it freely emits activity events that conform to a unified structural specification, and the MessageHandler listens for these events on a single channel and renders the output with SSE, so that the user sees a typewriter-effect execution flow and conversation flow. This performance logic is not coupled into the Orchestrator, which lets it focus on control. Dongfang Yiteng's backend chose Go, which is exactly suited to writing this kind of event publish-subscribe lightly using native goroutines and channels — other mainstream languages can do it too, only with more code.
This structure avoids a common kind of coupling: mixing presentation logic with control logic. Once rendering, pushing, and typewriter effects are written into the trunk of control flow, the control flow becomes hard to read clearly; adding a new output form means changing the core, and changing a push can break the orchestration. Peeling the presentation logic out into a facade leaves the trunk of control flow responsible only for orchestrating actions according to signals, with how the frontend presents being none of its concern.
After intent recognition produces control signals, the next step is to define the consumers of those signals, which maps to a kind of interception-and-routing pattern, where the consumer is the intent gateway component. With it, small talk can end directly with an orchestrated mechanical conversation, without even calling the LLM to synthesize a reply, while query, task, and fallback each orchestrate different downstream execution chains. The intent gateway's input is a control signal, and its output is a definite chain of downstream activity orchestration. The large boundaries of the entire chain are fixed: the main entry receives the raw conversation and first determines intent, which is the pre stage; the synthesis of the reply returned to the user at the end is the post stage; and only the middle stage in between is the part that can be flexibly orchestrated. In Dongfang Yiteng's salary-package setup scenario, it is exactly this pre-middle-post skeleton that lets a colloquial request be converged into an intent, routed to the corresponding execution chain, and then orchestrated step by step into the strictly dependent sequence of vector matching, building a snapshot, and importing a template. Once the Orchestrator is in place, each capability unit has a place to carry it, and can focus on stacking upward.
When you need it
When your agent must carry multiple capabilities, run different execution flows for different intents, and you also want the control logic to stay clean and the presentation form to evolve independently. Looking further back at how control signals are recognized in the first place leads to the dualism of the control plane and the narrative plane; spelling out how intent is converged into executable signals leads to intent as compilation.
This is an ADPS blue-book concept. Back to Concepts or the pattern matrix.