Weg 1: Sie bauen es

Der traditionelle Ansatz -- Ihr Team schreibt den Agenten von Grund auf:

Ihr Code
  +-- Agent-Schleife (Prompt -> LLM -> Aktion -> Beobachten -> Wiederholen)
  +-- Tool-Integrationen (Datei-I/O, APIs, Datenbanken)
  +-- Speicher-Management (Kontext, Historie, RAG)
  +-- Fehlerbehandlung und Wiederholungslogik
  +-- Leitplanken und Sicherheitspruefungen
  +-- Monitoring und Logging

Wann Weg 1 waehlen:

• Sie brauchen volle Kontrolle ueber jede Entscheidung
• Sie haben KI/ML-Engineering-Expertise im Team
• Ihr Anwendungsfall hat einzigartige Anforderungen, die kein Framework abdeckt
• Sie bauen ein Produkt, bei dem der Agent DAS Produkt ist

Frameworks, die helfen:

• LangChain -- am populaersten, riesiges Oekosystem
• CrewAI -- Multi-Agent-Orchestrierung
• AutoGen -- Microsofts Multi-Agent-Framework
• Anthropic Agent SDK -- Claude-natives Agent-Building

Typischer Zeitrahmen: 2-6 Monate fuer einen produktionsreifen Agenten

Weg 1: Beispielarchitektur

Einen Code-Review-Agenten von Grund auf bauen:

// Vereinfachte Agent-Schleife
async function agentLoop(task) {
  const context = await gatherContext(task);
  let done = false;

  while (!done) {
    // Reasoning: LLM fragen, was als Naechstes zu tun ist
    const plan = await llm.chat({
      system: SYSTEM_PROMPT,
      messages: [...context.history, { role: 'user', content: task }],
      tools: AVAILABLE_TOOLS,
    });

    // Handeln: das gewaehlte Tool ausfuehren
    if (plan.tool_calls) {
      for (const call of plan.tool_calls) {
        const result = await executeTool(call);
        context.history.push({ role: 'tool', content: result });
      }
    }

    // Beobachten: pruefen, ob wir fertig sind
    done = plan.stop_reason === 'end_turn' && !plan.tool_calls;
  }

  return context.history;
}

Dies ist das Kernmuster, das jedes Agent-Framework implementiert. Es zu verstehen hilft Ihnen, Frameworks zu bewerten und Probleme zu debuggen.

Weg 2: Agent baut es

Der Meta-Ansatz -- einen bestehenden KI-Agenten nutzen, um Ihr System zu bauen:

Sie: "Build me a customer support chatbot that..."
Claude Code:
  -> Erstellt Express-Server mit WebSocket-Unterstuetzung
  -> Implementiert RAG-Pipeline mit Vektordatenbank
  -> Baut Admin-UI zur Wissensdatenbank-Verwaltung
  -> Schreibt Tests fuer alle Komponenten
  -> Deployed in Docker

Wann Weg 2 waehlen:

• Sie haben eine klare Spezifikation, aber begrenzte KI-Engineering-Expertise
• Sie wollen schnelles Prototyping (Stunden, nicht Monate)
• Der Agent selbst ist nicht Ihr Produkt -- er ist ein Werkzeug fuer Ihr Business
• Sie brauchen schnell etwas Funktionierendes und koennen iterieren

Der Workflow:

1. Eine detaillierte Spezifikation schreiben (im AGENTS.md-Stil)
2. Claude Code oder OpenCode zum Bauen des Systems nutzen
3. Den generierten Code ueberpruefen und testen
4. Auf spezifische Probleme iterieren
5. Deployen und ueberwachen

Typischer Zeitrahmen: 1-5 Tage fuer einen funktionierenden Prototyp, 2-4 Wochen fuer Produktion

Weg 2: Was funktioniert und was nicht

Funktioniert gut mit Agent-gebauten Systemen:

• CRUD-APIs und Webanwendungen
• Chatbots mit klar definierten Wissensdomaenen
• Datenverarbeitungs-Pipelines
• Monitoring- und Alerting-Skripte
• CLI-Tools und Automatisierung

Funktioniert nicht gut:

• Neuartige Algorithmen (KI kann nicht ueber Trainingsdaten hinaus innovieren)
• Performance-kritische Systeme (KI optimiert nicht gut)
• Sicherheitskritische Ablaeufe (KI kann Randfaelle uebersehen)
• Systeme, die formale Verifikation erfordern

Der hybride Ansatz: Lassen Sie den Agenten 80% des Geruests bauen, dann die kritischen 20% von Hand erstellen (Sicherheit, Performance, Kernalgorithmen).

Weg 3: Agent IST das Backend

Der radikalste Ansatz -- der Agent generiert keinen Code, er IST die Anwendung:

Traditionell:
  Nutzer -> [Ihr App-Code] -> Datenbank

Weg 3:
  Nutzer -> [KI-Agent] -> Tools (DB, APIs, Dateien)
  Ueberhaupt kein traditioneller Anwendungscode.

Beispiel -- KI-natives Kundenportal: Statt Bildschirme fuer "Bestellung ansehen", "Rueckerstattung anfordern", "Adresse aendern" zu bauen:

Nutzer: "Where's my order?"
Agent: *fragt Bestell-DB ab* -> "Your order #4521 shipped yesterday
        and arrives Thursday. Here's the tracking link."

Nutzer: "Actually, I need to change the delivery address"
Agent: *ruft Versand-API auf* -> "Done! Updated to 456 Oak St.
        Your delivery date is still Thursday."

Keine Bildschirme zu bauen. Keine Formulare zu designen. Keine Routen zu programmieren. Der Agent IST das Interface.

Weg 3: Wann es funktioniert

Ideal fuer Weg 3:

• Interne Tools, bei denen Nutzer flexibel sind (Mitarbeiter, nicht Kunden)
• Komplexe Workflows mit vielen Verzweigungen
• Aufgaben, fuer die traditionelle UIs schwer zu designen sind
• Schnelles Experimentieren und Erkunden

Nicht ideal fuer Weg 3:

• Hochvolumige Transaktionsverarbeitung (zu langsam, zu teuer)
• Aufgaben, die praezise, wiederholbare Ergebnisse erfordern (deterministischen Code verwenden)
• Compliance-lastige Operationen (brauchen Audit-Trails von Code, nicht KI-Reasoning)
• Einfache CRUD-Operationen (traditioneller Code ist einfacher)

Die Kostengleichung:

• Traditionelle App: $0 pro Anfrage (Code ist kostenlos auszufuehren)
• Agent-als-Backend: $0,01-0,50 pro Interaktion (LLM-Kosten)
• Bei 10.000 taeglichen Interaktionen: $100-5.000/Tag

Weg 3 ist teuer im grossen Massstab, aber extrem guenstig in der Entwicklung. Perfekt fuer interne Tools mit niedrigem bis mittlerem Volumen.

Ihren Weg waehlen

Faktor	Weg 1: Selbst bauen	Weg 2: Agent baut	Weg 3: Agent IST es
Zeitrahmen	2-6 Monate	1-4 Wochen	1-3 Tage
Kontrolle	Voll	Hoch	Mittel
Baukosten	Hoch	Mittel	Niedrig
Betriebskosten	Niedrig	Niedrig	Hoch
Team noetig	KI-Ingenieure	Entwickler	Jeder
Skalierbarkeit	Exzellent	Exzellent	Begrenzt
Flexibilitaet	Maximum	Hoch	Maximum

Die meisten Teams nutzen eine Kombination:

• Weg 2 fuer die initiale Version
• Weg 1 zur Optimierung kritischer Komponenten
• Weg 3 fuer interne Tools und Prototypen

Beginnen Sie mit Weg 2 oder 3, um Ihre Idee schnell zu validieren. Wechseln Sie nur fuer Komponenten zu Weg 1, die individuelles Engineering benoetigen.

---quiz question: Was ist "Weg 2" in der agentischen Systementwicklung? options:

• { text: "Das Agent-Framework von Grund auf bauen", correct: false }
• { text: "Einen bestehenden KI-Coding-Agenten nutzen, um Ihr System basierend auf einer detaillierten Spezifikation zu bauen", correct: true }
• { text: "Den Agenten direkt als Anwendungs-Backend verwenden", correct: false } feedback: Weg 2 bedeutet, KI-Coding-Agenten (wie Claude Code) zu nutzen, um das System basierend auf Ihren Spezifikationen zu generieren. Es ist schneller als von Grund auf zu bauen (Weg 1) und gibt Ihnen gleichzeitig echten Code, den Sie deployen und warten koennen.

---quiz question: Wann ist "Weg 3: Agent IST das Backend" am geeignetsten? options:

• { text: "Fuer hochvolumige E-Commerce-Transaktionen", correct: false }
• { text: "Fuer interne Tools mit niedrigem bis mittlerem Volumen, bei denen schnelle Entwicklung wichtig ist", correct: true }
• { text: "Fuer jede Anwendung, die ein Benutzerinterface braucht", correct: false } feedback: Weg 3 ist ideal fuer interne Tools und Anwendungsfaelle mit niedrigem bis mittlerem Volumen, bei denen die Entwicklungsgeschwindigkeit (Tage, nicht Monate) die Kosten pro Anfrage fuer das Ausfuehren eines LLM bei jeder Interaktion ueberwiegt.

---quiz question: Was ist der empfohlene hybride Ansatz fuer die meisten Teams? options:

• { text: "Nur Weg 1 fuer alles verwenden", correct: false }
• { text: "Mit Weg 2 oder 3 schnell validieren, dann Weg 1 zur Optimierung kritischer Komponenten nutzen", correct: true }
• { text: "Weg 3 fuer alles verwenden, um Entwicklungszeit zu sparen", correct: false } feedback: Die meisten erfolgreichen Teams validieren ihre Idee schnell mit Weg 2 oder 3 und investieren dann nur in individuelles Engineering (Weg 1) fuer die Komponenten, die es wirklich benoetigen -- wie Sicherheit, Performance oder neuartige Algorithmen.