What Is Dify? Open-Source Agent & RAG Builder

// In plain English

Building an app on top of a large language model usually means writing a lot of plumbing by hand: call the model, manage the prompt, store conversation history, connect a vector database for RAG, wire in some tools, then wrap the whole thing in an API so a website or app can use it. That's a real project before you've shipped a single useful feature.

Dify is an open-source, low-code platform that bundles all of that into one place. Instead of writing the plumbing, you assemble your app in a visual builder: drag boxes onto a canvas, connect them with arrows, pick a model from a dropdown, point at a knowledge base, and press publish. Dify turns the result into a running chatbot, agent, or workflow with an API and a chat UI you didn't have to build.

Think of it like a kitchen with the appliances already installed. A framework hands you raw ingredients and a recipe book — powerful, but you do all the cooking. Dify is the fitted kitchen: the oven (the model), the fridge (your documents), and the worktop (the workflow canvas) are bolted together and ready, so you spend your time on the dish, not on the wiring.

// Why it matters

The hard part of an LLM product is rarely the single model call. It's everything around it. A platform like Dify exists to remove that surrounding work so a small team — or one person — can go from idea to a working app in an afternoon instead of a sprint.

• Faster prototyping. You can test whether an idea even works before committing engineering time. Change a prompt, swap the model, tweak retrieval, and see the result in the same screen — no redeploy, no rebuild.
• Less glue code. Conversation history, RAG ingestion and retrieval, tool calling, and a published API are built in. You don't reinvent the parts every LLM app needs.
• A shared canvas for mixed teams. A product manager or domain expert can read the flow and suggest changes to a prompt or a branch without reading source code. The diagram is the documentation.
• Self-hosting and openness. Because it's open-source, you can run Dify on your own servers, keep your data and prompts in-house, and inspect exactly what it does — important when a black-box SaaS tool won't pass a security review.

Who is it for? People who want to ship an internal assistant, a "chat with our docs" tool, or a customer-support bot quickly, and who'd rather configure than code. It's also a good way for engineers to learn the shape of an LLM app — the canvas makes the moving parts visible. Who is it not for? Teams that need fine-grained control over every step, custom infrastructure, or behavior the visual blocks can't express. We'll come back to that tradeoff.

// How it works

Dify sits between you and the raw model providers. You describe your app once — as a chat assistant, an agent, or a multi-step workflow — and Dify handles the rest: it calls the model, runs retrieval, keeps history, and exposes the whole thing as an API and a ready-made chat interface.

The building blocks

Most of what Dify offers falls into a few layers. You compose your app from the top layer; the lower layers do the heavy lifting underneath.

• Model layer. One adapter over many providers (hosted APIs and self-hosted models). You configure a key once and pick the model from a dropdown anywhere in the app, so switching models is a setting, not a rewrite.
• Knowledge bases (RAG). Upload PDFs, docs, or web pages and Dify chunks them, creates embeddings, and stores them in a vector store. At question time it retrieves the relevant passages for you — managed RAG without standing up your own pipeline.
• Orchestration canvas. Where you actually build: prompt nodes, a knowledge-retrieval node, an LLM node, conditional branches, tool/function calls, and code steps, connected as a flow.
• Publish targets. Every app becomes a hosted chat UI, an embeddable widget, and a REST API at the same time, so a front-end or another service can call it immediately.

From idea to published app

The end-to-end path is short and always looks roughly the same, whether you're building a tiny FAQ bot or a multi-step agent.

Two of those steps deserve a closer look. The agent type lets the model decide, on its own, which tools to call and when — the same loop behind any AI agent, but configured through a form. The workflow type is the opposite: you define the exact path — node A, then a branch, then node B — which is more predictable and easier to debug. Many real apps mix both.

// A worked example: a docs chatbot

Say you want a support bot that answers from your product documentation and never makes things up. In a code-first world you'd write an ingestion script, a retriever, a prompt template, history handling, and an API. In Dify the same app is a handful of configured nodes.

1. Create a knowledge base and upload your docs. Dify chunks and embeds them automatically.
2. Create a chatbot (or a workflow) and add a knowledge-retrieval node pointed at that knowledge base.
3. Add an LLM node with a system prompt like "Answer only from the retrieved context; if it isn't there, say you don't know."
4. Connect retrieval → LLM so the retrieved passages flow into the prompt as context.
5. Test it in the built-in chat, then press publish to get an API endpoint and a shareable chat page.

Once it's published, calling it from your own code is a normal HTTP request — no Dify-specific SDK required. Conceptually it looks like this:

curl -X POST 'https://your-dify-host/v1/chat-messages' \
  -H 'Authorization: Bearer YOUR_APP_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "inputs": {},
    "query": "How long is the refund window?",
    "user": "user-123",
    "response_mode": "blocking"
  }'

// Low-code platform vs. coding with a framework

The big decision isn't "Dify or not" — it's whether a visual platform or a code framework fits your project. They sit at opposite ends of a control-vs-speed tradeoff.

A healthy way to think about it: low-code is fastest where your app looks like a common pattern (chatbot, RAG assistant, simple agent), and code wins where it doesn't. Many teams prototype in Dify to validate the idea, then decide whether to keep running it or rebuild the proven flow in code. Choosing your language for that rebuild is its own question — see Python vs TypeScript for AI.

Dify also isn't the only visual builder. Tools in the same space (Langflow, n8n, Flowise, and others) make similar tradeoffs; they differ mainly in how much they lean toward RAG, toward general automation, or toward agents. The mental model in this article transfers to all of them.

// Common pitfalls

Low-code removes the plumbing, not the thinking. The mistakes that sink a Dify app are mostly the same ones that sink any LLM app — they're just easier to overlook when everything "just works" in the demo.

• Treating the demo as done. It answered three questions correctly in the chat panel — that's not a test. RAG quality lives and dies on retrieval; you still need to measure it. See how to evaluate a RAG system.
• Ignoring cost. Every message hits a model, and retrieval-heavy apps send a lot of tokens. A flow that's cheap for you alone can be expensive at a thousand users a day — estimate it early (cost estimation).
• Leaking keys. The convenience of a one-click published API makes it easy to paste the app key somewhere public. Keep it server-side.
• Outgrowing the canvas. When a flow needs dozens of branches and custom logic, a visual graph can become harder to follow than code. That sprawl is often the signal it's time to graduate to a framework.
• Untrusted retrieved text. Documents pulled into a RAG prompt are untrusted input and can carry hidden instructions — prompt injection. Using a platform doesn't make that risk go away.

// Going deeper

Once the basic chatbot clicks, a few directions are worth exploring as your needs grow.

Workflows vs. agents, deliberately. Reach for a fixed workflow when you want predictable, auditable behavior — a known sequence of steps with clear branches. Reach for the agent type when the path can't be known up front and you want the model to choose tools dynamically. Production systems often nest the two: a structured workflow that calls an agent only for the open-ended part keeps most of the app debuggable.

Tools and external actions. Beyond answering questions, nodes can call external APIs, run code, or invoke your own functions, which is how an app moves from talking to doing (creating a ticket, querying a database). Each tool you add widens what the app can do and what can go wrong, so add them one at a time and test each.

Self-hosting and operations. Being open-source, Dify can run on your own infrastructure for data control. That also means you own the operational side — the database, the vector store, backups, and updates. Weigh that against a hosted option when you plan your deployment, and where the platform fits in your overall AI app stack.

Managing conversations and rollout. As usage grows you'll care about how chat history is stored and trimmed (managing chat history) and how to roll changes out safely with feature flags rather than editing the live flow.

The durable lesson: a low-code builder changes how fast you assemble an LLM app, not what makes it good. Good retrieval, careful prompts, real evaluation, and cost awareness still decide whether your app is useful. Dify gets you to the part that matters faster — it doesn't do that part for you.