„Agentische KI" ist einer dieser Begriffe, der durch hundert Pitch Decks gewandert ist, bis er jede Bedeutung verloren hatte. Fangen wir also damit an, was er tatsächlich beschreibt: ein System, bei dem ein LLM nicht einfach auf einen einzelnen Prompt antwortet, sondern Tools aufruft, auf Basis der Ausgabe verzweigt und bei Fehlern neu versucht. Ein Agent im sinnvollen Sinne ist eine Schleife — beobachten, entscheiden, handeln, Ergebnis prüfen.
Das ist alles. Kein Zauber. Keine autonome Intelligenz. Ein Funktionsaufruf, der andere Funktionen aufrufen kann, wobei ein LLM entscheidet, welche.
Wenn man es so formuliert, wird die Frage nach den Tools konkret: Was ist der günstigste, wartbarste Weg, diese Schleife für einen bestimmten Anwendungsfall zu verdrahten?
Was Dify ist
Dify ist ein Open-Source-Framework für LLM-Anwendungen. Es liefert einen visuellen Workflow-Builder, eine Prompt-IDE, eingebautes RAG (Dokumentenaufnahme + Vektorsuche) und eine REST-API, die man aus jedem Backend aufrufen kann.
Man kann die Cloud-Version nutzen. Oder es selbst hosten — und das ist der Teil, der es für die Setups, die ich baue, interessant macht.
Dify selbst hosten auf Hetzner
Eine Dify-Instanz auf einem Hetzner CX21 (2 vCPU, 4 GB RAM) läuft bei leichten bis mittleren Workloads komfortabel. Kosten: rund 5–10 € pro Monat, je nachdem was noch auf der Maschine läuft. Deployment via Docker Compose. Entweder auf die eigene Postgres- und Redis-Instanz zeigen oder Dify die Container selbst verwalten lassen.
Das praktische Ergebnis: volle Datenkontrolle, kein Per-Seat-Pricing, kein Vendor Lock-in auf der Orchestrierungsebene. OpenAI oder Anthropic zahlt man weiterhin per Token — daran ändert Dify nichts — aber die Workflow-Logik und die eigenen Dokumente bleiben auf der eigenen Infrastruktur.
Für DSGVO-sensible Anwendungsfälle ist es relevant, Dokumentenaufnahme und -abruf im eigenen Haus zu behalten. Kundenverträge oder interne Wissensdatenbanken zu einem extern gehosteten Orchestrierungstool zu senden, ist ein Compliance-Gespräch, das man lieber nicht führen möchte.
Wann Dify gewinnt
Schnelles Prototyping von mehrstufigen LLM-Workflows
Difys visuelles Canvas ist für mehrstufige Pipelines tatsächlich schnell: extrahieren → klassifizieren → routen → generieren → nachbearbeiten. Nodes ziehen, verbinden, in einer Stunde läuft etwas. Kein Boilerplate, kein SDK-Setup.
Für frühe Validierung — erzeugt diese Pipeline überhaupt brauchbare Ergebnisse? — zählt diese Geschwindigkeit. Die Idee testen, bevor man in Produktionscode investiert.
Teams, die Prompt-Kontrolle ohne Code-Deployments brauchen
Das ist Difys stärkstes Argument in der Praxis. Prompts ändern sich ständig in den ersten Wochen jedes LLM-Produkts. Wenn jede Prompt-Änderung eine Code-Änderung, einen PR und ein Deployment erfordert, entsteht unnötige Reibung zwischen den Menschen, die die Domäne verstehen (Gründer, PMs), und dem System, das sie abstimmen wollen.
Mit Dify lebt der Prompt in der UI. Jemand ohne Engineering-Zugang kann ihn ändern, im eingebauten Playground testen und veröffentlichen. Keine Deploy-Pipeline nötig.
RAG-Pipelines mit eingebauter Dokumentenaufnahme
Dify liefert eine Dokumentenaufnahme-Pipeline mit: PDF oder URL hochladen, das System zerlegt es in Chunks, erstellt Embeddings (über OpenAI, Cohere oder ein lokales Modell), speichert sie in pgvector oder Weaviate und macht sie als Wissensdatenbank verfügbar, die man an jeden Workflow-Node anhängen kann.
Das von Grund auf mit LangChain oder der rohen OpenAI Files API zu bauen kostet Zeit. Dify macht daraus ein 10-minütiges Konfigurationsproblem. Für ein Startup, das eine interne Wissensdatenbank oder ein Dokument-Q&A-Feature braucht, ist das ein bedeutender Vorsprung.
Ein konkretes Beispiel: Dokumentenklassifizierungs-Pipeline
Hier ein Beispiel für das, womit Dify sauber umgeht.
Anforderung: Eingehende PDFs (z. B. Lieferantenrechnungen) müssen in Kategorien klassifiziert und basierend auf dem Ergebnis an verschiedene nachgelagerte Systeme weitergeleitet werden.
Pipeline:
- HTTP-Trigger-Node — nimmt das hochgeladene PDF per Webhook entgegen
- Dokumentenextraktions-Node — parst das PDF, extrahiert den Textinhalt
- LLM-Node (gpt-5.4 oder claude-sonnet-4-6) — empfängt extrahierten Text plus einen Klassifizierungsprompt:
Du bist ein Dokumentenklassifizierer. Klassifiziere das folgende Dokument in eine dieser Kategorien:
RECHNUNG, VERTRAG, QUITTUNG, SONSTIGES.
Antworte nur mit dem Kategorie-Label.
Dokument:
{{document_text}}
- Condition-Node — verzweigt auf Basis der LLM-Ausgabe: bei
RECHNUNG→ Route A, beiVERTRAG→ Route B, sonst → Route C - HTTP-Output-Nodes — jeder Branch ruft einen anderen Downstream-Webhook auf, mit Klassifizierungsergebnis und extrahiertem Text
Das Ganze läuft als Dify-Workflow, der per REST-API aufgerufen wird. Man schickt eine PDF-URL vom Backend aus. Man bekommt eine Kategorie zurück, das nächste System übernimmt den Rest.
Das ist etwa 45 Minuten Arbeit in Dify. In reinem Code schaut man auf mehr — File-Handling, SDK-Aufrufe, Verzweigungslogik, Error-Handling, API-Oberfläche. Der Unterschied ist für einen Senior Engineer nicht riesig. Aber für einen Prototypen, bei dem man noch herausfindet, ob gpt-5.4 (oder claude-sonnet-4-6, wenn man Anthropic evaluiert) die eigenen spezifischen Dokumententypen zuverlässig klassifizieren kann, ermöglicht Dify die Validierung zuerst.
Wann Dify verliert
Komplexe Verzweigungslogik, die echten Code braucht
Difys Condition-Nodes können einfache if/else-Verzweigungen. Sobald man mehr als zwei oder drei Logikebenen braucht, oder in einem Branch etwas Nicht-triviales machen muss (Datenstrukturen transformieren, mehrere APIs mit unterschiedlicher Authentifizierung aufrufen, Teilausfälle abfangen), kämpft man gegen die visuelle Abstraktion.
Ab diesem Punkt schreibt man besser eine Python- oder TypeScript-Funktion. Das OpenAI SDK ist ein paar Imports entfernt:
import OpenAI from "openai";
const client = new OpenAI();
const completion = await client.chat.completions.create({
model: "gpt-5.4",
messages: [{ role: "user", content: prompt }],
});
Alles andere ist einfach Code. Volle Kontrolle, volle Testbarkeit, volle Debuggbarkeit. Kein visuelles Node-Diagramm, das man entwirren muss, wenn etwas kaputt geht.
Latenz-sensible Pipelines
Dify fügt Netzwerk-Hops hinzu. Das Backend ruft die Dify-API auf, Dify ruft den LLM-Anbieter auf, Dify gibt zurück. Für eine Pipeline, bei der man 4–5 LLM-Aufrufe verkettet und die Gesamtantwortzeit unter 2 Sekunden bleiben muss, fällt dieser Overhead ins Gewicht.
Direkte SDK-Aufrufe entfernen eine Schicht. Für alles User-Facing mit engen Latenzanforderungen: Orchestrierungs-Middleware weglassen.
Teams, die bereits in Code arbeiten
Wenn das Team mit TypeScript oder Python vertraut ist, ist ein visueller Workflow-Builder oft mehr Hindernis als Hilfe. Man verliert Typsicherheit, Git-Diffs sind unschön (JSON-Blobs), und das Debugging erfordert einen Kontextwechsel zu einer Browser-Oberfläche.
Das Vercel AI SDK, das OpenAI SDK oder eine einfache LangChain-Chain fühlen sich natürlicher an und bieten bessere Observability. Was das Team um 2 Uhr nachts durchdenken kann, wenn etwas kaputt geht — das ist der richtige Stack.
Dify vs n8n für KI-Workflows
Beide sind selbst hostbar. Beide haben visuelle Builder. Sie lösen unterschiedliche Probleme.
n8n ist eine Automatisierungsplattform, die KI-Nodes hinzugefügt hat. Seine Stärke sind Integrationen: Slack, Notion, HubSpot, Google Sheets, 200+ Konnektoren. Wenn man einen LLM-Schritt innerhalb einer größeren Geschäftsautomatisierung braucht — eine Notion-Seite zusammenfassen, eine Slack-Nachricht posten, einen CRM-Eintrag aktualisieren — ist n8n das richtige Tool. Das LLM ist ein Node in einem breiteren Workflow.
Dify ist ein LLM-Application-Framework, das einige Integrationsfähigkeiten hinzugefügt hat. Seine Stärke ist Prompt-Management, RAG und mehrstufiges LLM-Reasoning. Wenn das LLM das Produkt ist — Klassifizierung, Extraktion, Generierung, Q&A — ist Dify besser geeignet.
Die praktische Aufteilung: n8n bei der Automatisierung von Geschäftsprozessen, bei denen gelegentlich ein LLM gebraucht wird. Dify beim Aufbau eines LLM-nativen Features, das gelegentlich einen externen Dienst aufrufen muss.
Für eine Dokumentenklassifizierungs-Pipeline, die zu verschiedenen Webhooks routet: Dify. Für einen nächtlichen Job, der neue Notion-Dokumente abruft, durch gpt-5.4-mini oder claude-haiku-4-5 schickt und Zusammenfassungen in Slack postet: n8n.
Das ehrliche Fazit
Dify ist ein legitimes Tool für eine spezifische Teilmenge von Anwendungsfällen. Es beseitigt echte Reibung rund um Prompt-Iteration und Dokumentenaufnahme. Der Selbst-Hosting-Pfad auf Hetzner macht das Datenkontroll-Argument glaubwürdig, ohne teuer zu sein.
Es ist kein Abkürzung an Engineering-Urteilsvermögen vorbei. Man muss die Pipeline trotzdem entwerfen, gute Prompts schreiben, Fehlerszenarien behandeln und entscheiden, wann der Workflow den visuellen Builder herauswächst. Dify automatisiert diese Entscheidungen nicht — es gibt nur einen schnelleren Weg herauszufinden, ob der eigene Ansatz funktioniert.
Für das Prototyping von LLM-Features mit nicht-technischen Stakeholdern im Loop, oder für RAG-Pipelines, bei denen man eine verwaltete Dokumentenaufnahme will, ohne sie von Grund auf zu bauen, verdient es seinen Platz im Stack.
Für Produktionssysteme mit komplexer Logik, hohem Durchsatz oder engen Latenzbudgets: das SDK nehmen.