Rethinking Dify: DevOps for the Agent Era

By Evan (Xu Dabao AI)

A note from the Dify community: This article was written by Evan, a long-time member of the Dify open-source community. After spending months exploring Dify Agent, Skills, Linux Sandbox, and Agent Roster, he arrived at a reframing that resonated widely: Dify is not a low-code AI builder. It is the DevOps layer for the Agent era, a production system for orchestrating, running, observing, and governing AI at enterprise scale. We are sharing his perspective here, because we believe the best product understanding often comes from the people who use it every day.

I used to think of Dify in simple terms: an open-source, low-code AI platform. Drag a few nodes, plug in a large language model, attach a knowledge base, and you could spin up a chatbot, a customer service agent, or an internal Q&A tool in no time. Useful, convenient, but not exactly a deep technical bet.

Then I started looking more closely at Dify Agent, Skills, the Linux Sandbox, Agent Roster, and the team's continued investment in permissions, audit trails, and enterprise governance. I began to realize: we may have been underestimating Dify all along.

Dify didn't suddenly jump on the agent hype train. It looks more like a team with years of DevOps DNA, following their own engineering logic, arriving at agent operations step by step.

Low-code is just the most visible surface

When Dify launched in 2023, the hottest trend in the industry was wrapping ChatGPT with a thin UI. People were grabbing model APIs, writing a prompt, slapping on a chat interface, and calling the result an "AI application." Very few were seriously thinking about how to deploy, monitor, iterate, debug, or position these things when problems arose.

Dify's visual interface happened to be intuitive. You could configure prompts, hook up knowledge bases, swap models, and publish them as a WebApp or API, all without writing much code. So naturally, a lot of people filed it under "AI low-code platform."

That label isn't wrong, but it only captures the interaction layer, not what the product is actually solving for. Low-code answers the question "how do I build faster." Dify, from the very beginning, was tackling a different set of problems:

• How do you integrate models in a unified way?
• How do you manage and iterate on prompts?
• How does private data enter the context?
• How do you publish and keep applications running?
• How do you track invocation logs?
• How do you label and improve outputs?
• How do you deploy on-premises for enterprises?

These are not questions a page builder should worry about. They are closer to a full development, operations, and maintenance systems for AI applications.

To understand Dify, start with the team

Dify was founded in March 2023. Its founder, Zhang Luyu, and the early core team came primarily from the Tencent Cloud CODING DevOps group.

Zhang Luyu had spent years in developer tools, SaaS, and R&D collaboration products. He previously founded Feie, a software test engineering and collaboration SaaS product comparable to TestRail in the West. Feie was acquired by CODING, and Zhang later joined Tencent along with the CODING team.

This background explains nearly every product decision Dify has made since. DevOps was never just about "how to write code." It was about how software gets defined, collaborated on, tested, released, observed, and continuously improved. In the era of large models, the subject changed, but the questions stayed the same:

• Code became prompts, workflows, and skills.
• Software services became AI applications and agents.
• CI/CD became continuous evaluation and iteration.
• Log monitoring became model invocation and task-chain tracing.
• Development permissions became model, data, and tool permissions.

This is why Dify initially called itself an LLMOps platform, not a chatbot factory. Even the name "Dify" carries a hint: Define + Modify. Define an AI application, then continuously refine and improve it. A very DevOps way of thinking.

2023: turning AI from a chat window into a real application

Dify's earliest capabilities now look unsurprising: visual prompt orchestration, dataset management, RAG, model management, logging, annotation, WebApp and API publishing.

But in the context of 2023, this combination was remarkably forward-looking. Most products at the time were asking "what can a model answer?" Dify was asking "how does a developer turn model capabilities into a sustainable, production-grade application?"

The difference is significant. The first approach treats the large model as a smarter API endpoint. The second treats the model as just one component in a system, one that also needs data, workflows, state, feedback loops, and a runtime environment.

Today, when we talk about agents, we take tool-calling, memory, workflows, and observability for granted. But in 2023, the notion that "AI applications need to be engineered" hadn't yet become industry consensus. Dify was already on that side of the line, early.

2024: Workflow was not about adding features, but constraining uncertainty

In 2024, Dify's focus shifted decisively toward workflow. Conditional branching, variable aggregation, iteration, parameter extraction, tool invocation: these capabilities kept entering the product. Workflows could also be published as tools, available for other workflows or agents to call.

On the surface, it looked like a low-code platform getting richer node by node. But from the agent perspective, it reflected a critical judgment the team had made about the boundaries of large models: you cannot hand every decision over to a model in real business operations.

Large models excel at understanding intent, processing unstructured information, and making fuzzy judgments. But enterprise processes still contain vast amounts of steps that must be deterministic. An order has to check permissions first, then query inventory, and amounts above a certain threshold require approval. A report has to extract data first, compute metrics, and only then can a model generate conclusions. You cannot let the model improvise at every step. So a viable agent system must accommodate two kinds of capability at once:

• Agents handle judgment and selection.
• Workflows handle sequence and boundaries.

Dify later embedded agents inside workflows and packaged workflows as tools that agents could invoke. This wasn't the product team throwing features together at random. It was a deliberate response to a production-level problem: how do you take the inherent uncertainty of a model and fit it inside a process that the enterprise can control?

2025: Agent is no longer an application type, but an intelligent node

In Dify's earlier versions, an agent was essentially an advanced mode of a chat assistant. Hook up search, a calculator, or a business API, let the model pick the right tool for each question, and it could already handle a meaningful range of tasks. But this kind of agent was still monolithic and conversational.

By 2025, Dify's treatment of agents began to change. Agent Node, Agent Strategy, the plugin system, MCP, and external observability tools kept filling out the picture. An agent could now enter a larger workflow, and it could invoke pre-packaged business capabilities.

This meant the agent was no longer responsible for everything. It could focus solely on the parts of a process that require judgment: analyzing intent, selecting tools, planning the next step. Deterministic steps, high-risk actions, and handoffs to upstream or downstream systems could still be delegated to workflow.

This design isn't "sci-fi" enough, but it is far better suited to the enterprise. Because what enterprises need is not an omnipotent autonomous agent. They need an intelligent component that knows what it should do, what it should not do, and that can be invoked systematically by the rest of the organization.

2026: Giving agents a body and a set of rules

The latest evolution of the Dify agent pushes this trajectory to a much more explicit position. The new agent experience introduces the Linux Sandbox, Skills, Agent Roster, and a two-way composition of agent and workflow. Agents can install dependencies, execute code, read and write files, and they can also be saved, reused, and managed centrally. This is no longer the agent of the past, the one that "calls a few APIs from inside a chat window." It now has a real execution environment.

But with greater capability comes greater risk. An agent that can only generate text lets you rewrite the answer when it gets something wrong. An agent that can execute shell commands, access files, and invoke enterprise APIs can cause real damage with a single wrong move. This is why Dify is simultaneously emphasizing a set of less glamorous capabilities:

• Sandbox isolation
• Least privilege
• Execution logs
• Human-in-the-loop confirmation
• Multi-tenancy management
• Plugin governance
• Audit and compliance
• Cost and performance observability

This signals that Dify's understanding of agent has shifted from "how to build a single intelligent entity" to "how an enterprise manages a fleet of intelligent entities." The first framing is about building a developer tool. The second is about building organizational infrastructure.

Agent governance is not a pivot, but the extension of a DevOps logic

Looking back now, Dify's product roadmap is remarkably coherent:

• 2023: How AI applications get built and operated.
• 2024: How model capabilities enter deterministic workflows.
• 2025: How agents invoke tools, embed in processes, and connect to external systems.
• 2026: How agents get executed, reused, observed, and governed.

Each step landed on the most pressing real-world problem of its moment.

Of course, we shouldn't reverse-engineer the present and claim Dify had the agent endgame fully mapped out in 2023. It started as an LLMOps platform centered around AI applications. The Linux Sandbox, Skills, and organizational-level agent management that exist today had not yet taken shape back then.

But the team saw one thing clearly, and held onto it: Large-model capabilities won't stay confined inside chat windows forever. They will inevitably enter software systems, business processes, and enterprise organizations. Once they do, the competitive axis shifts. It is no longer about how smart the model is. It is about who can orchestrate it, run it, constrain it, and catch it when things go wrong. That is exactly the battlefield Dify knows best.

What Dify is really building may be DevOps for the Agent era

In 2026, Dify announced a $30 million Pre-A round. The company's stated priorities for the next phase go beyond building more powerful agents.

They include production reliability, performance, permissions, audit, and enterprise compliance. This further confirms that Dify's ambition is no longer to add a few more node types or to become the most user-friendly AI flow-chart builder. What it is reaching for is a longer chain: Build agent → Connect data and tools → Orchestrate business processes → Publish and run → Observe outcomes → Manage permissions → Continuously improve.

This chain closely mirrors the lifecycle that traditional DevOps uses to manage software. The only difference is that in the software era, you managed code and services. In the agent era, you also have to manage a model's judgment, a tool's permissions, and the uncertainty inherent in every execution.

So calling Dify an "AI low-code platform" today already undersells it. The visual interface is how it lowers the barrier to entry. Open source is the path it uses to expand the ecosystem. But the real throughline of the product is this: transforming uncontrollable model capabilities into a production system that can be run, delivered, and governed.

Dify may not have known from the start what agents would ultimately become. But it knew from the start that AI can only truly enter the enterprise when it can be orchestrated, operated, observed, and governed.

This isn't a pivot chasing the latest trend. This is a DevOps team, in the agent era, finding its way back to the course it was always meant to sail.

Original article↗