Can One Skill Transform All Skills? The Boundary Debate Between Dify Workflows and Agents

A Seemingly Absurd Technical Proposition

In the practice of AI application development, there's a class of requirements that sounds rather philosophical: How do you transform a "Skill" into a visual workflow? Going further, can you construct a "meta-Skill"—one whose sole purpose is to transform any other Skill into a standard workflow?

This question was first raised half-jokingly by a Bilibili content creator, yet it unexpectedly touched the core of today's debate between the Agent and Workflow paradigms: Where exactly does the boundary lie between deterministic orchestration and dynamic autonomous decision-making?

On low-code AI application platforms like Dify, a Workflow is a directed execution graph formed by connected nodes. It allows the existence of "language model nodes" (LLM nodes) to handle tasks such as generation, judgment, and extraction, but it typically does not allow directly embedding an "Agent node"—that is, an intelligent unit capable of autonomous planning, tool invocation, and reflective looping.

Dify is an open-source large language model application development platform. After emerging in 2023, it quickly became one of the mainstream tools for building enterprise-grade AI applications. Its core design philosophy is to "productize" AI capabilities—enabling non-AI experts to build deployable AI applications through modules like visual Workflow orchestration, prompt engineering, and RAG knowledge base management. Within Dify's workflow node system, LLM nodes, code nodes, HTTP nodes, and conditional branch nodes all have clearly defined input-output contracts, and the overall execution graph must be a DAG (Directed Acyclic Graph) or a directed graph with controlled loops. This design gives workflows inherent observability and traceability, but it also means they cannot natively support the dynamic orchestration mode where "the model autonomously decides the next step."

This limitation is not a technical flaw of the platform, but a design tradeoff: workflows pursue predictable, debuggable, and reproducible execution paths, whereas Agents pursue the autonomy to flexibly handle unknown scenarios. The tension between the two is precisely the starting point of this discussion.

Can a Skill Transform a Skill?

The author's core idea has a certain recursive elegance: if there exists a Skill that can "perfectly" transform ordinary business Skills into workflows, then by simply applying this transforming Skill to itself, one could theoretically obtain a "workflow that transforms workflows."

This is essentially a self-reference problem. In computation theory, such constructs are not unfamiliar—a compiler can be written in the very language it compiles (bootstrapping), and a universal Turing machine can simulate any other Turing machine.

The ideas of self-reference and bootstrapping have deep roots in computer science. The most famous extreme example of self-reference is Gödel's incompleteness theorem—a sufficiently powerful formal system cannot prove its own consistency. In engineering practice, bootstrapping is more concrete: the GCC compiler is ultimately written in C, which means the boundary of a compiler's capability determines the boundary of its self-description. The author's analogy of a "meta-Skill transforming itself" to such self-referential constructs implies a deeper question: if the Skill-to-Workflow transformation is itself lossy or incomplete, then when the transformer is applied to itself, this incompleteness will be exposed or even amplified. This also echoes Turing's halting problem—certain computational boundaries are matters of principle, not of engineering.

The author's vision is essentially asking: Is the transformation from Skill to Workflow a process that can be fully automated and self-consistently closed?

If the answer is yes, it would mean that all Skills can essentially be "statically unfolded" into fixed execution graphs—the dynamism of AI applications would be merely superficial, with a deterministic process underneath. This would have profound implications for engineering practice: visual, auditable, and optimizable workflows could replace most black-box Agents.

The Precondition for Transformation: Execution Paths Can Be Statically Defined

The author particularly emphasized a key precondition—"the process must be reducible to a directed workflow." In other words, transformation only holds when a Skill's execution path can be pre-determined as a directed graph. Workflows allow LLM nodes to make local judgments and generations, but the branching structure of the entire process must be enumerable and statically describable.

This exposes the core of the problem: not all Skill execution paths can be pre-defined.

The Loop Architecture: A Counterexample That Cannot Be Workflow-ified

The most valuable part of this discussion comes precisely from the "breakthrough" case the author himself provided. He pointed out that we now have the Loop architecture—a mechanism that lets the model orchestrate its own process and dynamically generate the next action at runtime.

The Loop architecture is a key paradigm in modern AI Agent implementation, often also called the ReAct (Reasoning + Acting) or Plan-and-Execute framework. Its core mechanism is: at each step, the model outputs the "next action" based on the current context, executes that action, feeds the result back to the model, and the model then decides whether to continue looping or terminate. In this architecture, the "graph structure" of the execution path is not predefined but dynamically constructed by the model at runtime—each iteration produces a new edge until the model judges the task complete. OpenAI's Function Calling, Anthropic's Tool Use, LangGraph's state machine graphs, and AutoGen's multi-agent conversations are all different implementation variants of the Loop architecture. The power of the Loop architecture lies in its ability to handle open-ended tasks where "you don't know how many steps are needed," but the cost is that the execution path cannot be pre-audited, token consumption is hard to estimate, and error propagation paths are complex.

With the Loop architecture, the model can decide at runtime what to do next, which tool to invoke, and whether to continue iterating—based on intermediate results. This "execution path determined only at runtime" is, in principle, impossible to unfold in advance into a fixed directed graph—because the shape of the graph itself grows dynamically during execution.

In other words, as long as the model is allowed to perform unbounded self-orchestration at runtime, it is inevitable that a "Skill that cannot be workflow-ified" can be constructed. This is precisely the fundamental divergence between the Agent paradigm and the Workflow paradigm:

• Workflow: The execution graph is determined at the design stage; runtime merely follows the graph. Predictable and reproducible, but limited in flexibility.
• Agent (Loop architecture): The execution path is dynamically generated at runtime, giving it the ability to handle open-ended scenarios, but making it difficult to statically audit and reproduce.

Practical Takeaways from This Discussion

What seems like lighthearted technical banter actually offers valuable reference for AI application architects.

First, most enterprise-grade AI requirements can be workflow-ified. Many scenarios that appear to require an "agent" turn out, upon decomposition, to have enumerable execution paths—implementing them with a workflow containing LLM nodes is often more stable, lower-cost, and easier to troubleshoot. This is precisely the product logic behind why platforms like Dify insist on restricting Agent nodes and prioritizing workflows. In enterprise deployment, the core advantage of workflows lies in SLA (Service Level Agreement) commitability—because the execution path is fixed, latency, cost, and output format are all predictable, facilitating billing, monitoring, and compliance auditing. Microsoft in Azure AI Foundry and Google in Vertex AI both prioritize deterministic pipelines over open-ended Agents, precisely because of enterprise customers' strong demand for predictability.

Second, what truly requires Loop/Agent are tasks with unpredictable paths. For example, open-ended research, multi-round autonomous exploration, and scenarios requiring dynamic strategy adjustment based on environmental feedback. Such requirements cannot be solved through static orchestration; forcing them into workflows only produces a bloated and incomplete "branch hell." By contrast, Agent/Loop architectures are better suited to scenarios with greater fault tolerance, such as internal tools, research assistance, and creative generation.

Third, the "meta-Skill that transforms everything" is unrealizable in the face of the Loop architecture. This is not a capability issue but a boundary at the level of computability—just as no universal program can determine whether all programs will halt. A practical architectural decision framework is: if a task's "set of execution steps" can be fully enumerated at design time, choose a workflow; if the set of steps depends on runtime state and is unknowable at design time, choose an Agent. Acknowledging this boundary actually makes architectural selection clearer: first ask "can this task's path be pre-defined?" and then decide whether to use a workflow or an Agent.

Conclusion

From the recursive fantasy of "using one Skill to transform all Skills" to the self-negation of "the Loop architecture constructing a Skill that cannot be workflow-ified," this brief line of thought fully plays out the core contradiction of today's AI application development. The answer may not be romantic: there is no universal transformer, but precisely because of this, workflows and Agents each hold an irreplaceable position. Understanding the boundary between the two has greater engineering value than pursuing a unified "silver bullet."

Key Takeaways