Warum sind AI-Agent-Frameworks so komplex? Es braucht ein revolutionäres Framework wie Rails

Die wichtigsten Probleme aktueller AI-Agent-Frameworks

• Erschöpfung des Kontextfensters
  • Bei komplexen Aufgaben vergisst das Modell das ursprüngliche Ziel
  • Halluzinationen und Endlosschleifen treten auf
• Frameworks fungieren nur als dünne Wrapper
  • Modellauswahl, Embedding-Anbieter, Tool-Strukturierung usw. werden auf Entwickler abgewälzt
  • Verstößt gegen das Prinzip „Don’t make me think“
• Verwirrung durch zu viele Tools
  • Unnötige Bewertung von Optionen verschwendet Kontext

Vorgeschlagene Lösung: eine Subagenten-zentrierte Architektur

• Subagenten als First-Class Citizens nutzen
  • Natürliche Delegation wie bei Function Calling
  • Besitzen einen unabhängigen Kontext → der Eltern-Agent bleibt fokussiert
  • Beispiel: Ein Subagent zur Codebase-Suche gibt nur relevante Dateipfade zurück
• Wirkung
  • Einzelner Agent: verbraucht 90 % des Kontexts
  • Mit Subagenten: nur 25 % des Eltern-Kontexts werden genutzt

Rails-Lehre anwenden: Convention over Configuration

• Standardkonventionen zuerst
  • Automatische Modellauswahl (basierend auf der Aufgabenkomplexität)
  • Vererbung des Kontextbudgets zwischen Eltern und Kind
  • Automatische Erstellung von Checkpoints für riskante Aufgaben
• Einführung von Archetypen
  • Searcher: nur Such-Tools
  • Writer: nur Schreib-Tools
  • Researcher: nur Webzugriff → verhindert Tool-Überladung

Praktische Designprinzipien

• Aufgabenorientiertes Design
  • Statt „Welches Modell sollen wir verwenden?“ steht die reale Aufgabe im Vordergrund (z. B. Validierung eines Registrierungsformulars)
• Temporärer Kontext für Subagenten
  • Nur die Zusammenfassung der Zwischenschritte wird an den Eltern-Agenten zurückgegeben
• Abgrenzung zwischen Tool und Subagent
  • Tool: zustandslos (Datumsformatierung, JSON-Parsing)
  • Subagent: erfordert Wiederholung und Urteilsvermögen (Suche, Analyse)

Technologieentscheidung: TypeScript

• Mehr Typsicherheit (Branded types, discriminated unions)
• Kompatibel mit Entwicklungsökosystemen (VS Code usw.)
• Mit Bun zu eigenständigen ausführbaren Dateien kompilierbar

Noch ungelöste Aufgaben

• Gemeinsame Kontextnutzung zwischen Subagenten (projektbezogene Wissensbasis)
• Zusammenarbeit zwischen gleichrangigen Agenten (Nachrichtenübermittlung)
• Agentenbewertung (Szenarien aufzeichnen und wiedergeben; Kriterien: Erfolg, Konsistenz, Präferenz)

Fazit

• Frameworks sollten nicht zusätzliche Komplexität schaffen, sondern die „richtige Komplexität“ bereitstellen
• Ein revolutionäres Framework wie Rails könnte die Entwicklung von Agenten grundlegend verändern
• Weniger Plumbing-Arbeit → mehr Fokus auf das Kernproblem

[nomak]

Wird 2026 nicht vielleicht ein neues Tool erscheinen? Es wird zwar anders als Rails sein, aber etwas stärker abstrahiert … Ich bin gespannt.

[ahwjdekf]

Agenten-Frameworks … der Name klingt großspurig, aber am Ende sind sie nur Werkzeuge, die alles an das LLM weiterreichen. Eine leere Hülle.

[click]

Rails ist praktisch, weil es Konventionen erzwingt und unter der Abstraktionsschicht viel Magie betreibt, auch wenn das mit dem Trade-off geringerer Performance einhergeht. Das kostet aber nicht sofort Geld, während man sich fragen muss: Wenn das Framework eigenmächtig das Modell auswählt und dadurch der Token-Verbrauch explodiert, wer übernimmt dann die Verantwortung dafür ...?