Concepts/Concept

An Execution-Type Agent Is Not a Content-Generation Agent: Classify the Scenario First

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

Definition

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.

How it works

What this guards against is the specific failure of treating execution as if it were content. In the MCP protocol, the agent acts as a Client: it perceives tools, calls tools, and stuffs results back into context as text, while the understanding and generation of parameters is left entirely to the LLM. This design is enormously valuable in general-assistant scenarios, but applied to execution scenarios it runs into trouble. The Dongfang Yiteng team's earliest judgment was the same as that of many SaaS companies: if the existing APIs were implemented as MCP Servers, could the bot then run a business process to completion on its own? Taken to a few core scenarios for real, it immediately failed to work — and the reason it failed to work was precisely MCP's openness and flexibility. The LLM is a probabilistic model; generation always drifts, and no amount of added JSON-Schema constraints or stronger models removes the moments of error and hallucination. The team wanted a deterministic execution result, and determinism cannot rest on probability alone. This conflicts directly with MCP's premise of handing parameter generation to the LLM.

Dongfang Yiteng is a SaaS company for enterprise personnel, organization, attendance, approval, and payroll. The reimbursement example at the start makes this hurdle clearest. In an expense-control system, reimbursement is "create the request first, then upload the invoice, then submit for approval, then query the result." When uploading the invoice, the bound request id must be the one the business system just returned in the previous step — not an arbitrary id, and certainly not one the model generates itself. For a person doing this in a GUI it is trivial, because which method each button calls and which parameters it binds were nailed down by the program long ago. Hand it to an agent to do automatically and those explicit operations are gone: which tool to call and what parameters to prepare are all its responsibility. The team fell into this pit: appending each step's result to context like a tool_call, and letting the model parse the binding for the next step's parameters out of context, proved extremely unreliable in practice — sometimes succeeding, sometimes failing, with the moment of failure neither controllable nor predictable. After that, the team classified what it was building clearly as execution-type, and every architectural trade-off that followed started from this dividing line.

When you need it

When your agent is executing a chain of business steps with strict state dependencies, and one wrong parameter would corrupt business data or produce a "false success," then it is execution-type, and it has to be designed with the heavy mechanisms execution-type demands. Once the category is clear, how control and narrative are split is covered in the dualism of the control plane and the narrative plane; how to solve the most central mechanical-parameter problem of execution-type agents is covered in the mechanical state plane and the provenance coordinate.

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