Context Engineering mit Inngest: So verwandelst du Vibe Coding in robuste AI-Workflows

Kontext Engineering mit Inngest: So baust du zuverlässige AI-Workflows statt „Vibe Coding“
(DiekAI – Der deutsche AI Blog)

---

Einleitung: Warum „Vibe Coding“ dich früher oder später einholt

Wenn du in den letzten Monaten mit AI gebaut hast, sieht deine Praxis vielleicht so aus:

• Du packst ein paar PDFs in den Chat.
• Du hängst einen Screenshot oder eine CSV-Tabelle an.
• Du schreibst einen langen Prompt mit „Wichtige Regeln:“ und hoffst, dass sich das Modell daran erinnert.
• Und dann drückst du auf „Run“ – und hoffst einfach, dass es schon irgendwie klappt.

Kommt dir das bekannt vor?

Dieses Arbeits­muster hat inzwischen sogar einen Namen: Vibe Coding.
Du programmierst nicht wirklich – du „vibest“ mit dem Modell. Manchmal kommt Großartiges dabei heraus, manchmal kompletter Unsinn. Und jedes Mal ist es ein kleines Glücksspiel.

Wenn du aber:

• eine echte Anwendung bauen willst,
• die im Produktivbetrieb zuverlässig läuft,
• mit echten Nutzer:innen, echten Daten und
• wiederholbaren Ergebnissen,

dann reicht dieses „Vibe Coding“ nicht mehr.

Genau hier kommt ein neues Konzept ins Spiel: Context Engineering – in Kombination mit Inngest als „Kontext-Engine“.

In diesem Artikel zeige ich dir:

• Was Context Engineering ist – und was es von klassischem Prompt Engineering unterscheidet.
• Warum Tools wie Inngest dafür eine Art „Next.js für AI-Workflows“ sind.
• Wie du mit Kilo Code (AI Coding Agent in VS Code) + Inngest
  eine AI-basierte Aufgabenverwaltung aufbaust, die
  kontextbewusst, robust und skalierbar ist.
• Konkrete Anwendungsfälle, Best Practices und Tipps, wie du sofort starten kannst.

Am Ende dieses Artikels wirst du verstehen, wie du:

> AI nicht nur mit „großen Prompts“, sondern mit strukturierter, orchestrierter und dauerhaft verfügbarer Information fütterst – und damit eine neue Stufe der Zuverlässigkeit erreichst.

---

1. Vom Prompt zum Prozess: Was ist Context Engineering?

1.1 Das Problem mit „mehr Prompt = mehr Intelligenz“

Viele von uns haben Prompt Engineering so gelernt:

• Mehr Details in den Prompt.
• Mehr Beispiele.
• Mehr Regeln.
• Mehr Dateien.

„Wenn das Modell nur genug Kontext hat, ist es doch bestimmt schlau genug, oder?“

Die Realität:

• Lange Prompts sind teuer (Tokens = Geld und Latenz).
• Modelle vergessen Teile des Kontextes (weil der Kontextfenster begrenzt und intern gewichtet wird).
• Unstrukturierte Infos (PDFs, Screenshots, Rohtexte) erzeugen:
  • Halluzinationen
  • inkonsistente Antworten
  • schwer nachvollziehbare Fehler
• Modelle können keine langen, langlebigen Prozesse steuern:
  • Wartezeiten
  • wiederkehrende Tasks
  • externe Trigger
  • saubere Fehlerbehandlung mit Retries

Kurz gesagt:
LLMs sind gut im Denken – schlecht im Orchestrieren.

1.2 Definition: Was ist Context Engineering?

> Context Engineering ist die Kunst, AI zur richtigen Zeit, in der richtigen Reihenfolge und im richtigen Format genau die Informationen zu geben, die sie für einen bestimmten Schritt braucht – und das automatisch, reproduzierbar und skalierbar.

Es geht also nicht mehr nur um:

• Was im Prompt steht,

sondern darum:

• Wann welcher Teil der Information geliefert wird,
• woher die Daten kommen (Datenbanken, APIs, Dateien, Events),
• wie sie aufbereitet, gefiltert und verdichtet werden,
• welcher Prozess die einzelnen Schritte steuert.

Du kannst dir das vorstellen wie eine gute Küche:

• Der/die Koch/Köchin (das LLM) ist brillant.
• Aber wenn Zutaten ungeschnitten, unmarkiert und in zufälliger Reihenfolge angeliefert werden,
  kann selbst der beste Koch kein konsistentes Menü liefern.
• Context Engineering ist der/die Küchenchef:in, der/die:
  • Zutaten bestellt
  • sie rechtzeitig vorbereitet
  • sie in der richtigen Menge und Reihenfolge an den Herd bringt.

1.3 Warum „Vibe Coding“ in Produktion scheitert

„Im Prototyp hat es doch funktioniert…“

Viele AI-Projekte kippen genau an diesem Punkt:

• Einzelne Test­anfragen funktionieren.
• Die Demo für’s Team sieht gut aus.
• Doch in Produktion:
  • gehen Requests verloren,
  • schlagen API-Calls sporadisch fehl,
  • läuft ein Prozess 30 Minuten statt 3 Sekunden,
  • und niemand weiß, warum.

Die häufigsten Ursachen:

• Keine dauerhaften Workflows (alles ist „ein großer Request“).
• Kein State Management (keine Ahnung, wo der Prozess gerade steht).
• Keine Retries oder feine Fehlertoleranz.
• Keine Observability (Logs, Metriken, Step-Ansichten).

Context Engineering adressiert genau diese Lücke – und dafür brauchen wir passende Werkzeuge.

---

2. Inngest: Deine „Context Engine“ für AI-Workflows

2.1 Was ist Inngest?

Inngest ist ein Open-Source-Framework, das dir hilft, zuverlässige, mehrstufige Workflows zu bauen – mit:

• dauerhaftem State (durable functions),
• automatischen Retries,
• Event-getriebenen Abläufen,
• Parallelisierung und
• übersichtlicher Observability.

Du kannst dir Inngest vorstellen wie:

• Next.js für deine Serverfunktionen,
  nur dass diese Funktionen:
  • über Minuten, Stunden oder Tage laufen können,
  • niemals ihren Zustand verlieren,
  • sauber mit Events und Schritten arbeiten.

Oder anders gesagt:

> Inngest ist der Orchestrator, der deine AI-Schritte, Datenquellen und Events in einem robusten Prozess zusammenführt.

2.2 Was Inngest dir konkret abnimmt

Ohne Inngest müsstest du selbst bauen:

• Job-Queues (z. B. mit Redis, BullMQ, Sidekiq, etc.)
• Cron-Jobs für wiederkehrende Aufgaben
• eigene Retry-Logik (Exponential Backoff, Dead Letter Queues…)
• State-Persistenz (Datenbank, Locks, Sequenzen)
• Monitoring und Logging für jeden einzelnen Schritt

Mit Inngest bekommst du:

• Background Job System – ohne eigene Queue-Verwaltung.
• Event Engine – du definierst Events, Inngest reagiert.
• Workflow Orchestrierung – du beschreibst Schritte in Code.
• AI Step Runner – du kannst LLM-Aufrufe als Steps integrieren.
• Observability – UI für:
  • Events,
  • Workflows,
  • einzelne Steps,
  • Retries, Fehler, Dauer.

Du konzentrierst dich auf Logik & AI – nicht auf Infrastruktur.

2.3 Warum das gerade für AI entscheidend ist

AI-Features im echten Leben sind selten:

> „Ein Prompt rein, eine Antwort raus, fertig.“

Typische reale Szenarien:

• Du willst Daten aus:
  • deiner Datenbank,
  • deinem CRM,
  • deinem GitHub-Repo,
  • einem S3-Bucket mit PDFs,
  • einer Websuche kombinieren.
• Du musst:
  • API-Rate-Limits beachten,
  • bei Fehlern automatisch neu versuchen,
  • teilweise parallel laden,
  • vielleicht sogar warten, bis ein anderer Prozess fertig ist.
• Dann musst du:
  • diese Daten verdichten,
  • in ein strukturiertes Format bringen,
  • und sie erst dann ans LLM schicken.

Genau diese Kontext-Orchestrierung macht Inngest zu einer idealen „Context Engine“.

---

3. Kontext Engineering in Aktion: AI Research Assistant mit Inngest

Im Video, auf dem diese Notizen basieren, wird zuerst ein AI Research Assistant gezeigt – als Referenz­projekt des Inngest-Teams.

3.1 Was dieser Research Assistant macht

Der Workflow sieht vereinfacht so aus:

1. Nutzer:in stellt eine Frage.
2. Inngest-Workflow wird gestartet (Event).
3. Der Workflow:
   • sammelt Daten aus mehreren Quellen:
     • Archiv / interne Dokumente,
     • GitHub-Repos,
     • PDFs,
     • Web-Suche.
   • startet für jede Quelle einen eigenen Step.
4. Jeder Step:
   • holt die Daten,
   • komprimiert oder chunked sie,
   • lässt ggf. ein spezialisiertes Modell vorfiltern oder zusammenfassen.
5. Am Ende:
   • werden alle Ergebnisse in ein strukturiertes Kontextobjekt überführt.
6. Dieses Objekt wird an ein LLM weitergegeben – das die eigentliche Antwort generiert.

3.2 Warum das Kontext Engineering ist – und nicht nur „RAG 2.0“

Retrieval-Augmented Generation (RAG) kennst du wahrscheinlich:

• Vektorsuche → relevante Text-Snippets → Prompt.

Kontext Engineering geht hier einen Schritt weiter:

• Mehrere Quellen werden orchestriert (nicht nur ein Vektorindex).
• Schritte laufen parallel, um Zeit zu sparen.
• Fehler werden automatisch retryt.
• Kontext wird:
  • gefiltert,
  • verdichtet,
  • strukturiert (z. B. JSON-Objekte statt nur Freitext).
• Am Ende steht ein klar definiertes Inputformat für das LLM.

Der Unterschied:

• Bei einfachem RAG „wirfst“ du Text in den Prompt.
• Bei Context Engineering baust du einen kontrollierten Informationsfluss,
  der dein LLM präzise und datenbewusst denken lässt.

---

4. Die Toolchain: VS Code, Kilo Code, Inngest & Co.

Bevor wir in ein konkretes Beispiel gehen, schauen wir uns kurz an, welche Tools im Tutorial genutzt werden.

4.1 Visual Studio Code

• Der Standard-Editor, den viele ohnehin nutzen.
• Wichtig, weil:
  • du hier deinen Code schreibst,
  • du AI-Coding-Agents integrieren kannst (z. B. Kilo Code),
  • du deine Inngest-Funktionen editierst.

4.2 Kilo Code – AI Coding Agent (Open Source)

Kilo Code ist ein Open-Source Coding Agent für VS Code, der:

• deinen Code verstehen,
• eigenständig Dateien anlegen,
• Befehle ausführen und
• komplette Features umsetzen kann.

In der Demo wird Kilo Code benutzt, um:

• eine neue Next.js-App aufzusetzen,
• Inngest zu integrieren,
• Workflows zu definieren,
• eine UI zu bauen,
• und am Ende die komplette AI-Task-App zusammenzusetzen.

Wichtig:
Der starke Teil kommt nicht nur von Kilo Code selbst, sondern von einem speziellen Regel-Set („Mode“), das den Agenten darauf trimmt, Context Engineering mit Inngest zu betreiben.

4.3 Inngest – als Context Engine

Wie oben beschrieben, fungiert Inngest hier als:

• Workflow-Orchestrator,
• Event-System,
• AI-Step-Runner,
• Context-Manager.

In der Praxis heißt das:

• Du definierst in deinem Code:
  „Wenn dieses Event kommt, starte diesen Workflow mit diesen Steps.“
• Inngest kümmert sich um:
  • Ausführung,
  • Persistenz,
  • Fehlerbehandlung,
  • Logging.

4.4 Alternative Coding Agents

Wenn du Kilo Code nicht nutzen möchtest, kannst du die Konzept-Idee auch mit anderen Tools umsetzen, z. B.:

• Cursor
• Claude Code
• andere VS Code AI-Extensions

Entscheidend ist:

• Du brauchst eine Möglichkeit, ein eigenes Regel-Set bzw. eine Custom Mode zu definieren, der deinen AI-Agenten auf „Context Engineering + Inngest“ einschwört.

---

5. Kilo Code für Context Engineering einrichten

Lass uns kurz durchgehen, wie im Tutorial der AI-Agent eingerichtet wurde. Du kannst diese Schritte entweder exakt nachbauen oder als Blaupause für deinen eigenen Stack nutzen.

5.1 Schritt 1: Kilo Code in VS Code installieren

1. Öffne den Extensions-Tab in VS Code.
2. Suche nach „Kilo Code“.
3. Installiere die Extension.

Da Kilo Code Open Source ist, kannst du dir bei Bedarf den Code anschauen und verstehen, was im Hintergrund passiert.

5.2 Schritt 2: Eigenen „Mode“ / eigene Regeln anlegen

Der Kern des Ganzen ist ein Regel-Set, das deinem AI-Agenten sagt:

• wie er Inngest verwenden soll,
• wie er Kontext aus verschiedenen Quellen holen darf,
• wie er mit Dateien, APIs, PDFs, Tabellen umgeht,
• wie er Tokens spart,
• und wie er Workflows Schritt für Schritt aufbauen soll.

Vorgehen im Tutorial:

1. In Kilo Code:
   • Mode-Auswahl öffnen.
   • Auf „edit“ klicken.
   • Mit „+“ einen neuen Mode anlegen.
2. Dann wird ein vorgefertigtes Regel-Template eingefügt (Link im Video).

Inhaltlich sagt dieses Template in etwa:

> „Wenn der/die Nutzer:in dich bittet, eine Anwendung mit Inngest zu bauen,
> dann: > – setze Schritt für Schritt eine Inngest-App auf, > – definiere Events und Workflows, > – organisiere Kontext aus Dateien, APIs, Tabellen, etc., > – strukturiere diesen Kontext, > – und rufe das LLM niemals direkt mit Rohdaten auf,
> sondern immer über vorbereitete Kontextobjekte.“

Den gleichen Ansatz kannst du z. B. bei Cursor verwenden, indem du cursor.rules oder client.rules anpasst.

5.3 Schritt 3: Provider wählen & Prompt definieren

Als Nächstes:

1. Wähle einen AI-Provider:
   • OpenAI,
   • Gemini,
   • Claude,
   • o. ä.
2. Formuliere einen klaren, detaillierten Prompt für dein Projekt.

Im Tutorial z. B.:

> „Baue eine AI-gestützte Aufgabenverwaltungs-App mit Next.js und TypeScript,
> die Context Engineering mit Inngest integriert.“

Je genauer du hier bist, desto besser kann der Coding Agent:

• Architektur entscheiden,
• Datenflüsse planen,
• Inngest-Workflows sinnvoll strukturieren.

---

6. Inngest in deiner App: Setup & Workflow-Orchestrierung

Kommen wir zum praktischen Teil: Wie kommt Inngest überhaupt in deine App?

6.1 Schritt 1: Inngest-Account erstellen

• Gehe auf die Inngest-Website.
• Erstelle einen Account (kostenloser Einstieg ist möglich).
• Lege eine neue App an.

Du bekommst:

• eine Projekt-ID,
• API-Keys oder Verbindungsinfos,
• und Zugriff auf das Inngest-Dashboard.

6.2 Schritt 2: Inngest im Code initialisieren

Im Tutorial wird – via Kilo Code – ein npx-Befehl genutzt, um eine Inngest-App zu initialisieren (z. B. innerhalb einer Next.js-App).
Konzeptionell läuft das so:

1. Du installierst die Inngest-Abhängigkeit (z. B. npm install inngest).
2. Du erstellst eine Datei für die Inngest-Konfiguration.
3. Du definierst deinen Inngest-Client.
4. Du setzt einen Server-Endpunkt auf, über den Inngest Workflows triggern und steuern kann.

Der AI-Agent erledigt viele dieser Schritte automatisch, wenn du ihn entsprechend beauftragst.

6.3 Schritt 3: Workflows & Schritte definieren

Der Kern von Inngest sind:

• Events (z. B. "task/created", "user/asked_question", "file/attached"),
• Workflows bzw. Functions, die auf diese Events reagieren,
• Steps, die innerhalb eines Workflows ausgeführt werden.

Ein typischer Ablauf könnte sein:

// Pseudocode – stark vereinfacht export const aiQuestionWorkflow = inngest.createFunction( { name: "AI Question Workflow" }, { event: "task_app/question_asked" }, async ({ event, step }) => { const question = event.data.question; const userId = event.data.userId; // 1. Kontext sammeln (parallel) const [tasks, attachments, analytics] = await Promise.all([ step.run("fetch tasks", () => fetchTasksForUser(userId)), step.run("fetch attachments", () => fetchAttachments(userId)), step.run("fetch analytics", () => fetchAnalytics(userId)), ]); // 2. Kontext strukturieren const context = await step.run("build context", () => buildStructuredContext({ tasks, attachments, analytics }) ); // 3. LLM-Aufruf mit strukturiertem Kontext const answer = await step.run("call LLM", () => callLLM({ question, context }) ); return { answer }; } );

Wichtige Punkte:

• Jeder step.run(...) ist:
  • beobachtbar,
  • retry-bar,
  • einzeln im Dashboard sichtbar.
• Parallelisierung (Promise.all) beschleunigt den Kontextaufbau.
• Am Ende geht ein sauber strukturiertes Objekt ins LLM – nicht nur „roher Text“.

---

7. Beispielprojekt: AI-basierte Aufgabenverwaltungs-App mit Inngest

Im Tutorial wird genau so eine App implementiert:
Eine Task-Management-App, die mittels Context Engineering und Inngest AI-gestützte Auswertungen liefert.

Schauen wir uns den Aufbau an.

7.1 Ziel der App

Die App soll:

• klassische Aufgabenverwaltung bieten (Tasks anlegen, verwalten, priorisieren).
• Daten (z. B. Umsätze, Status, Deadlines) halten.
• es ermöglichen, natürliche Fragen zu stellen, z. B.:
  • „Wie hoch ist der Gesamtumsatz im letzten Quartal?“
  • „Welche Aufgaben sind überfällig und besonders kritisch?“
• Antworten liefern, die:
  • auf den gespeicherten Daten basieren,
  • kontextbewusst sind,
  • zuverlässig reproduzierbar sind.

7.2 Tech-Stack

• Frontend / App Framework: Next.js
• Sprache: TypeScript
• AI-Orchestrierung: Inngest
• AI-Coding-Agent: Kilo Code (zum Erstellen der App)

7.3 Was der AI-Agent (Kilo Code) automatisch aufsetzt

Der AI-Agent, der mit dem Context-Engineering-Regelset läuft, übernimmt:

• Initialisierung des Next.js-Projekts.
• Installation & Setup von Inngest.
• Aufbau einer Grundstruktur:
  • Auth-Seite (Login/Sign-up oder Dummy-Auth),
  • Dashboard mit Task-Liste,
  • evtl. Seed-Daten (z. B. Beispielumsätze, Aufgaben).
• Integration eines Fragefeldes:
  • Nutzer:in gibt eine Frage ein,
  • diese triggert einen Inngest-Workflow.

Parallel startet der Agent:

• den Dev-Server (npm run dev o. ä.),
• den Inngest-Dev-Endpunkt, damit du lokal alles testen kannst.

7.4 Wie Context Engineering in der App sichtbar wird

Wenn du die App nutzt, sieht der Flow ungefähr so aus:

1. Du meldest dich an (oder nutzt einen Demo-Account).
2. Du siehst deine Aufgaben / Daten (UI).
3. Du stellst eine Frage wie:
   • „Welche Tasks haben die höchste Priorität und sind überfällig?“
4. Die App:
   • sendet ein Event an Inngest, z. B. "task_app/question_asked".
5. Inngest startet den zugehörigen Workflow:
   • Step 1: Tasks aus Datenbank / Storage laden.
   • Step 2: evtl. zusätzliche Kontextdaten:
     • z. B. Projektinfos, Deadlines, Owner, Historie.
   • Step 3: Kontext strukturieren (z. B. als JSON mit Feldern wie:
     • overdueTasks,
     • highPriorityTasks,
     • projectSummaries, etc.).
   • Step 4: LLM aufrufen – mit:
     • der Frage,
     • dem Kontextobjekt.
6. Inngest speichert:
   • jede Ausführung,
   • jeden Step,
   • alle Retries.
7. Die App zeigt dir die Antwort an:
   • inkl. Begründung,
   • ggf. mit Verlinkung zu relevanten Tasks.

7.5 Observability: Was du im Inngest-Dashboard siehst

Im Inngest-Dashboard kannst du verfolgen:

• welches Event ausgelöst wurde,
• welcher Workflow gestartet ist,
• welche Steps durchlaufen wurden,
• wo ggf. Fehler aufgetreten sind,
• wie oft ein Step wiederholt werden musste,
• wie lange jeder Schritt gedauert hat.

Das bedeutet:

• Kein „Black Box“-Gefühl mehr bei AI-Prozessen.
• Du kannst genau nachschauen:
  • welche Daten dem LLM gegeben wurden,
  • welche Antworten zurückkamen,
  • und warum eine Anfrage ggf. schiefging.

---

8. So funktioniert Context Engineering in dieser App im Detail

Schauen wir uns an, welche Prinzipien des Context Engineering konkret angewendet werden.

8.1 Strukturierte statt „rohe“ Kontexte

Statt:

• alle Tasks einfach als Text in den Prompt zu kleben,

passiert Folgendes:

1. Die Tasks werden aus der Datenquelle geladen.
2. Sie werden in sinnvolle Gruppen unterteilt, z. B.:
   • überfällig,
   • hohe Priorität,
   • nach Projekt,
   • nach Verantwortlichem.
3. Es wird ein strukturiertes Objekt gebaut, etwa:

{ "summary": { "totalTasks": 42, "overdueTasks": 7, "highPriorityTasks": 5 }, "overdueTasks": [ { "id": "1", "title": "Q4 Report", "dueDate": "2025-12-01", "priority": "high" }, { "id": "2", "title": "Kundentermin vorbereiten", "dueDate": "2025-11-30", "priority": "medium" } ], "highPriorityTasks": [ { "id": "1", "title": "Q4 Report", "priority": "high" }, { "id": "5", "title": "Security-Audit", "priority": "high" } ] }

4. Dieses Objekt landet im Kontext des LLM-Aufrufs.

Vorteile:

• Das LLM „sieht“ sofort, was wichtig ist.
• Weniger Tokens, weil du nicht alle Rohdaten brauchst.
• Weniger Halluzination, weil das Modell nur aus klaren Feldern lesen muss.

8.2 Parallelisierung & Retries

Wenn du z. B. Daten aus mehreren Quellen brauchst (Datenbank, API, Dateien):

• Inngest ruft sie in parallelen Steps ab.
• Wenn ein Request fehlschlägt (z. B. Rate-Limit), wird der entsprechende Step automatisch wiederholt.
• Du musst keine eigene Retry-Logik bauen.

Damit stellst du sicher:

• Dein Kontext ist möglichst vollständig.
• Temporäre Fehler führen nicht direkt zum Abbruch.
• Alles bleibt nachvollziehbar.

8.3 Ereignisgesteuerte Kontexte

Context Engineering bedeutet auch:

• Nicht jede AI-Aktion muss eine separate HTTP-Request sein.
• Stattdessen:
  • Events wie "task/created", "task/updated", "user/asked_question" lösen Workflows aus.
  • Workflows können:
    • Kontext vorbereiten,
    • Daten anreichern,
    • teilweise Ergebnisse cachen oder vorberechnen.

Beispiel:

• Jedes Mal, wenn eine neue Datei angehängt wird ("file/attached"), startet ein Workflow, der:
  • die Datei verarbeitet,
  • wichtige Daten extrahiert,
  • einen Eintrag in einem Kontext-Index erstellt.

Wenn später eine Frage gestellt wird, kann Inngest direkt auf diese vorbereiteten Kontexte zugreifen, statt alles „live“ zu parsen.

---

9. Context Engineering + Inngest vs. klassisches Prompting

Lass uns das Ganze noch einmal systematisch vergleichen.

9.1 Klassisches „Prompt + Dateien“-Vorgehen

Du:

• hängst 5 PDFs an,
• schreibst:
  • „Lies alle Dateien und beantworte dann diese Frage: …“
• hoffst, dass das Modell:
  • alle relevanten Stellen findet,
  • sie richtig gewichtet,
  • und in vertretbarer Zeit antwortet.

Probleme:

• Tokenizer-Kosten steigen stark.
• Kontextfenster wird schnell gesprengt.
• Relevante Infos gehen unter.
• Kein Retry bei Netzwerkfehlern oder API-Limits.
• Kein State – jeder Request ist „einmalig“.

9.2 Mit Context Engineering + Inngest

Du:

1. Definierst Workflows, die:
   • Daten aus mehreren Quellen holen,
   • sie filtern,
   • komprimieren,
   • strukturieren.
2. Nutzt Events, um diese Workflows auszulösen.
3. Rüstest jeden Schritt mit:
   • automatisch verwalteten Retries,
   • Logging,
   • parallelisierten Tasks aus.
4. Gibst dem LLM:
   • sauber strukturierte, vorverarbeitete Daten,
   • plus eine klare Aufforderung:
     „Nutze diese Felder, um die Frage zu beantworten.“

Vorteile:

• Bessere Performance (weniger Tokens, weniger Latenz).
• Höhere Zuverlässigkeit (Retries, Fehlerhandling).
• Nachvollziehbarkeit (Observability).
• Skalierbarkeit (Workflows lassen sich leicht erweitern).

Oder in einem Satz:

> Du verlässt das „wir hoffen, dass das Modell alles selbst regelt“-Paradigma und wechselst zum „wir orchestrieren den Daten- und Arbeitsfluss, das Modell fokussiert sich auf das Denken“-Ansatz.

---

10. Wie du selbst mit Context Engineering & Inngest startest

Wenn du nach diesem Artikel Lust bekommen hast, das selbst auszuprobieren, hier ein möglicher Fahrplan.

10.1 Schritt 1: Ein konkretes Ziel definieren

Frag dich:

• „Welche AI-Funktion baue ich gerade (oder möchte ich bauen),
  die heute noch ‚vibe-basiert‘ läuft?“

Beispiele:

• AI-Chat über interne Dokumente.
• AI-Auswertung deiner Sales-Daten.
• AI-Code-Review für deine Repos.
• AI-Assistent für Projektplanung.

Wähle einen Use Case.

10.2 Schritt 2: Deine Datenquellen auflisten

Schreibe auf:

• Wo liegen die relevanten Daten?
  • Datenbanken,
  • APIs,
  • Dateien (PDF, CSV, Excel),
  • interne Tools (GitHub, Jira, HubSpot, …).
• Welche davon brauchst du wirklich für eine typische Frage?

So erkennst du schnell:

• welche Steps dein Workflow braucht,
• welche Daten du parallel laden kannst,
• was du vorverarbeiten solltest.

10.3 Schritt 3: Inngest integrieren

1. Inngest-Account erstellen.
2. In deinem Projekt:
   • Inngest-Paket installieren,
   • Konfiguration anlegen,
   • ersten einfachen Workflow definieren, z. B.:
     • "user/asked_question" → load_data → build_context → call_llm.
3. Lokal den Inngest-Dev-Server starten, testen.

Tipp:
Halte den ersten Workflow so simpel wie möglich – z. B. nur eine Datenquelle und ein LLM-Call. Danach kannst du schrittweise:

• weitere Steps hinzufügen,
• Parallelisierung einbauen,
• komplexere Kontext-Objekte definieren.

10.4 Schritt 4: Coding-Agent einspannen (optional, aber hilfreich)

Wenn du:

• Kilo Code,
• Cursor,
• Claude Code

oder ähnliche Tools nutzt, kannst du:

• ein eigenes Regel-Set definieren (ähnlich wie im Video),
• das den Agenten explizit anweist, Context Engineering mit Inngest umzusetzen.

So sparst du dir viel Boilerplate und kannst dich stärker auf:

• Datenmodellierung,
• Kontextstruktur,
• Prompt-Design für den finalen LLM-Call

konzentrieren.

10.5 Schritt 5: Messen, beobachten, iterieren

Nutze besonders:

• das Inngest-Dashboard:
  • Welche Workflows werden wie oft getriggert?
  • Wo treten Fehler auf?
  • Welche Steps kosten am meisten Zeit?
• Logs:
  • Wie groß sind deine Kontextobjekte?
  • Welche Felder werden wirklich häufig gebraucht?

Basierend darauf kannst du:

• Kontext verschlanken,
• unnötige Schritte entfernen,
• Vorverarbeitung verbessern,
• LLM-Aufrufe exakt auf die wirklich relevanten Daten zuschneiden.

---

11. Häufige Fragen (FAQ) zum Einstieg in Context Engineering

11.1 Ist Context Engineering nicht einfach nur „RAG mit mehr Aufwand“?

Teilweise ja, aber:

• RAG fokussiert meist auf Vektorsuche + unstrukturierte Textretrievals.
• Context Engineering umfasst:
  • orchestrierte Workflows,
  • mehrere Datenquellen,
  • strukturiertes Kontextdesign,
  • Event-getriebene Abläufe,
  • langlebige Prozesse (State, Retries, Observability).

Du kannst RAG als einen Baustein in deinem Kontext nutzen – aber Context Engineering ist das Gesamt-Design des Informationsflusses.

11.2 Muss ich Inngest verwenden oder geht das auch anders?

Theoretisch kannst du:

• eigene Queues bauen,
• Cron-Jobs schreiben,
• State in Datenbanken verwalten,
• eigene Retry-Logik definieren.

Praktisch ist das:

• viel komplexer,
• fehleranfälliger,
• schwer zu warten.

Inngest ist darum so spannend, weil es viele dieser Probleme mit wenigen Zeilen Code löst – besonders im Zusammenspiel mit AI, wo Workflows oft schnell wachsen.

11.3 Funktioniert das nur mit Next.js und TypeScript?

Nein.
Im Tutorial wird zwar Next.js + TS genutzt, aber:

• Inngest ist nicht auf ein bestimmtes Frontend-Framework beschränkt.
• Du kannst es auch in anderen Node.js-Backends nutzen.
• Der Kontext-Engineering-Ansatz ist komplett framework-agnostisch.

Wichtiger ist:

• Du hast einen Ort, an dem du deine Workflows definierst,
• und ein Event-Modell, das zu deiner Anwendung passt.

11.4 Was bringt mir das konkret – außer „es klingt moderner“?

Ganz konkret:

• Weniger Halluzinationen, weil die AI nur auf kuratierte, strukturierte Daten schaut.
• Bessere Reproduzierbarkeit, weil jeder Kontextaufbau deterministisch abläuft.
• Mehr Robustheit, weil API-Fehler, Timeouts und Rate-Limits abgefedert werden.
• Transparenz, weil du jeden Schritt im Dashboard nachvollziehen kannst.
• Skalierbarkeit, weil du komplexe Workflows modular erweitern kannst.

---

12. Fazit: AI, die „mit Kontext denkt“, statt „auf Vibes reagiert“

Wir stehen an einem spannenden Punkt:

• Die Zeit, in der man mit einem riesigen Prompt und Hoffnung im Bauch „irgendwie coole AI-Features“ gebaut hat, neigt sich dem Ende zu.
• AI-Projekte wandern in den Produktivbetrieb – mit echten Anforderungen an:
  • Zuverlässigkeit,
  • Nachvollziehbarkeit,
  • Skalierbarkeit.

Context Engineering ist eine Antwort auf diese neue Phase:

• Es geht nicht mehr nur um was im Prompt steht,
• sondern darum, wie du Information für AI vorbereitest, orchestrierst und übergibst.

Inngest ist dafür ein mächtiges Werkzeug:

• Es macht deine AI-Workflows:
  • dauerhaft,
  • beobachtbar,
  • fehlertolerant,
  • skalierbar.
• Es fungiert als Context Engine, die:
  • Daten aus verschiedenen Quellen holt,
  • sie sinnvoll kombiniert,
  • und deine LLMs mit genau dem füttert, was sie wirklich brauchen.

Kombiniert mit einem AI-Coding-Agenten wie Kilo Code kannst du:

• in kurzer Zeit komplexe Anwendungen bauen,
• wie die AI-basierte Aufgabenverwaltungs-App aus dem Tutorial,
• ohne jedes Detail der Infrastruktur selbst zu implementieren.

Wenn du also das nächste Mal davorstehst, deiner AI „einfach noch mehr Dateien“ vorzuwerfen, frag dich:

> „Kann ich diesen Prozess nicht besser als Workflow modellieren, der
> Schritt für Schritt Kontext aufbaut – statt alles in einen Prompt zu kippen?“

Genau dort beginnt Context Engineering.

---

Nächste Schritte für dich:

• Überlege dir einen AI-Use-Case, der heute noch nach „Vibe Coding“ funktioniert.
• Liste deine Datenquellen und typischen Fragen auf.
• Richte eine kleine Inngest-App ein und baue deinen ersten Workflow:
  • event → daten_sammeln → kontext_strukturieren → llm_call.
• Beobachte im Dashboard, wie sich dein System verhält – und iteriere.

Wenn du magst, kannst du dir zusätzlich:

• den Inngest Research Assistant als Inspiration anschauen,
• den AI Task Manager aus dem Tutorial nachbauen,
• oder dein eigenes Projekt Schritt für Schritt auf Context Engineering umstellen.

So machst du aus deinen AI-Features
nicht nur spannende Demos – sondern zuverlässige Systeme, die im Alltag bestehen.