"Agentic AI" is one of those phrases that got laundered through a hundred pitch decks until it lost all meaning. So let's start with what it actually describes: a system where an LLM doesn't just answer a single prompt, but calls tools, branches on the output, and retries when something fails. An agent in the useful sense is a loop — observe, decide, act, check result.
That's it. No magic. No autonomous sentience. A function call that might call other functions, with an LLM deciding which ones.
Once you frame it that way, the tooling question becomes concrete: what's the cheapest, most maintainable way to wire up that loop for a given use case?
What Dify Is
Dify is an open-source LLM application framework. It ships with a visual workflow builder, a prompt IDE, built-in RAG (document ingestion + vector search), and a REST API you can call from any backend.
You can use the cloud version. Or you can self-host it — which is the part that makes it interesting for the setups I build.
Running Dify on Hetzner
A Dify instance on a Hetzner CX21 (2 vCPU, 4 GB RAM) runs comfortably for light-to-moderate workloads. Cost: around 5–10€/month depending on what else shares the box. You deploy it via Docker Compose. Point it at your own Postgres + Redis, or let it manage its own containers.
The practical outcome: full data control, no per-seat pricing, no vendor lock-in at the orchestration layer. You're still paying OpenAI or Anthropic per token — Dify doesn't change that — but the workflow logic and your documents stay on your infrastructure.
For GDPR-sensitive use cases, keeping document ingestion and retrieval in-house matters. Sending customer contracts or internal knowledge bases to a third-party hosted orchestration tool is a compliance conversation you'd rather not have.
When Dify Wins
Rapid prototyping of multi-step LLM workflows
Dify's visual canvas is genuinely fast for sketching multi-step pipelines: extract → classify → route → generate → post-process. You drag nodes, connect them, and have something runnable in an hour. No boilerplate, no SDK setup.
For early-stage validation — does this pipeline even produce useful output? — that speed matters. You want to test the idea before you invest in production code.
Teams that need prompt control without code deploys
This is Dify's strongest real-world argument. Prompts change constantly in the first weeks of any LLM product. If every prompt tweak requires a code change, a PR, a deploy, you're creating unnecessary friction between the people who understand the domain (founders, PMs) and the system they're trying to tune.
With Dify, the prompt lives in the UI. Someone without engineering access can change it, test it in the built-in playground, and publish it. No deploy pipeline involved.
RAG pipelines with document ingestion built-in
Dify ships with a document ingestion pipeline: upload a PDF or URL, it chunks it, embeds it (via OpenAI, Cohere, or a local model), stores it in pgvector or Weaviate, and surfaces it as a knowledge base you can attach to any workflow node.
Building this from scratch with LangChain or the raw OpenAI files API takes time. Dify makes it a 10-minute configuration problem. For a startup that needs an internal knowledge base or document Q&A feature, that's a meaningful head start.
A Concrete Example: Document Classification Pipeline
Here's the kind of thing Dify handles cleanly.
Requirement: Incoming PDFs (say, supplier invoices) need to be classified into categories and routed to different downstream systems based on the result.
Pipeline:
- HTTP trigger node — accepts the uploaded PDF via webhook
- Document extraction node — parses the PDF, extracts text content
- LLM node (gpt-5.4 or claude-sonnet-4-6) — receives extracted text plus a classification prompt:
You are a document classifier. Classify the following document into one of:
INVOICE, CONTRACT, RECEIPT, OTHER.
Respond with only the category label.
Document:
{{document_text}}
- Condition node — branches on the LLM output: if
INVOICE→ route A, ifCONTRACT→ route B, else → route C - HTTP output nodes — each branch calls a different downstream webhook with the classification result and extracted text
The entire thing runs as a Dify workflow exposed via REST API. You call it from your backend with a PDF URL. You get back a category and the next system handles the rest.
This is maybe 45 minutes to build in Dify. In raw code, you're looking at more — file handling, SDK calls, branching logic, error handling, API surface. The gap isn't enormous for a senior engineer. But for a prototype where you're still figuring out if gpt-5.4 (or claude-sonnet-4-6, if you're evaluating Anthropic) can reliably classify your specific document types, Dify lets you validate first.
When Dify Loses
Complex branching logic that needs real code
Dify's condition nodes handle basic if/else branching. Once you need more than two or three levels of logic, or need to do anything non-trivial in the branch (transform data structures, call multiple APIs with different auth, handle partial failures gracefully), you're fighting the visual abstraction.
At that point you're better off writing a Python or TypeScript function. The OpenAI SDK is a few imports away:
import OpenAI from "openai";
const client = new OpenAI();
const completion = await client.chat.completions.create({
model: "gpt-5.4",
messages: [{ role: "user", content: prompt }],
});
Everything else is just code. You get full control, full testability, full debuggability. No visual node graph to untangle when something breaks.
Latency-sensitive pipelines
Dify adds network hops. Your backend calls Dify's API, Dify calls the LLM provider, Dify returns. For a pipeline where you're chaining 4–5 LLM calls and need the total response under 2 seconds, that overhead matters.
Direct SDK calls remove one layer. For anything user-facing with tight latency requirements, skip the orchestration middleware entirely.
Teams that already live in code
If your team is comfortable with TypeScript or Python, a visual workflow builder is often more hindrance than help. You lose type safety, version control diffing is ugly (JSON blobs), and debugging requires switching context to a browser UI.
The OpenAI SDK, Vercel AI SDK, or even a simple LangChain chain will feel more natural and give you better observability. Use what your team can reason about at 2am when something breaks.
Dify vs n8n for AI Workflows
Both are self-hostable. Both have visual builders. They're solving different problems.
n8n is an automation platform that added AI nodes. Its strength is integrations: Slack, Notion, HubSpot, Google Sheets, 200+ connectors. If you need an LLM step inside a larger business automation — summarize a Notion page, post a Slack message, update a CRM record — n8n is the right tool. The LLM is one node in a broader workflow.
Dify is an LLM application framework that added some integration capabilities. Its strength is prompt management, RAG, and multi-step LLM reasoning. If the LLM is the product — classification, extraction, generation, Q&A — Dify is better suited.
The practical split: use n8n when you're automating business processes and occasionally need an LLM. Use Dify when you're building an LLM-native feature and occasionally need to call an external service.
For a document classification pipeline that routes to different webhooks, Dify. For a nightly job that pulls new Notion docs, runs them through gpt-5.4-mini or claude-haiku-4-5, and posts summaries to Slack, n8n.
The Honest Take
Dify is a legitimate tool for a specific slice of use cases. It removes real friction around prompt iteration and document ingestion. The self-hosted path on Hetzner makes the data control argument credible without being expensive.
It's not a shortcut around engineering judgment. You still need to design the pipeline, write good prompts, handle failure modes, and decide when the workflow outgrows the visual builder. Dify doesn't automate those decisions — it just gives you a faster path to finding out if your approach works.
For prototyping LLM features with non-engineering stakeholders in the loop, or for RAG pipelines where you want managed document ingestion without building it from scratch, it earns its place in the stack.
For production systems with complex logic, high throughput, or tight latency budgets, reach for the SDK.