Intent as Compilation: Compiling the Live into the Dead

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

Definition

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.

How it works

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.

When Dongfang Yiteng first implemented intent recognition, it identified three basic intents. The first is small talk, intercepted and ended as quickly as possible, without triggering the costly reasoning and action that follow. The second is analysis — for example, a user uploads a payroll table and asks the agent to analyze it; this kind retrieves some domain knowledge and makes one more LLM call. The third is understanding the intent and accurately orchestrating a series of tools to complete a task, which is the core scenario. These three were initially defined as chat, analyze, and resolve, and later evolved with the downstream business into richer signals such as task, information, produce, and chat. Because the LLM is unreliable, a fallback is set here: if the intent is not parsed, it is uniformly marked unknown, with matching fallback logic downstream for unknown. It was also in this first intent-recognition step that the team first saw the separation of the control plane and the narrative plane — a single capability's output contains both a control signal that drives where the program goes and narrative content for downstream reasoning to consume.

When you need it

When your agent must take a user's spoken request into a fixed execution flow, rather than generating a stretch of content to return. Who consumes the compiled control signals, and how they route by signal to different downstream execution chains, is the orchestrator and intent gateway; why the semantics must be converged into signals at the entrance has its root in control plane and narrative plane dualism.

This is an ADPS blue-book concept. Back to Concepts or the pattern matrix.