Warum wir für unsere 9-Agenten-Orchestrierung auf Prism PHP setzen
TL;DR: Eine KI-native Forge zu bauen bedeutet mehr, als Prompts zu verschicken. Es geht um planbare Orchestrierung. Wir haben Prism – das Laravel AI SDK – ins Herz von Craftly integriert, und das hat unseren Blick auf agentische PHP-Systeme verändert.
Das Problem mit rohen API-Aufrufen
Als wir mit dem Prototyping der 9-Agenten-Pipeline von Craftly begannen, lag der erste Schritt auf der Hand: die Anthropic-API direkt ansprechen. Ein Guzzle-Client, ein paar Umgebungsvariablen, ein Prompt-String – und an einem Nachmittag steht etwas, das funktioniert. Das Problem zeigt sich später, wenn „funktioniert“ nicht mehr reicht.
Rohe API-Aufrufe binden Ihren Code an das Request-Format eines einzelnen Anbieters. Jeder Agent in der Pipeline braucht eigenen Boilerplate-Code für Retries, Timeouts und Fehlerbehandlung. Structured Output wird zur manuellen JSON-Parsing-Übung. Für Tool Calling muss das Funktionsschema jedes Mal von Hand gebaut werden. Und wenn Sie bei einem bestimmten Agenten jemals Claude gegen GPT-4 tauschen – oder in der Entwicklung ein lokales Ollama-Modell laufen lassen – wollen, schreiben Sie neu, statt zu konfigurieren.
Genau dieses Problem löst Prism sauber.
Anbieterflexibilität ohne Abstraktions-Overhead
Prism kapselt Anthropic, OpenAI, Mistral, Gemini, Ollama und mehrere weitere Anbieter hinter einem einzigen Fluent Interface. In der Praxis heißt das: Unser MasterArchitect-Agent läuft wegen seiner starken Reasoning-Fähigkeiten auf claude-sonnet-4-6, während die Forge Workers auf claude-haiku-4-5 laufen, um die Generierungskosten niedrig zu halten – und beide teilen sich identischen Orchestrierungscode. Das Modell ist nur ein Parameter.
$response = Prism::text()
->using(Provider::Anthropic, 'claude-haiku-4-5-20251001')
->withSystemPrompt($workerSystemPrompt)
->withPrompt($architectureContext)
->generate();Die Forge Workers in einer künftigen Iteration auf einen anderen Anbieter umzustellen, erfordert die Änderung einer einzigen Zeile. Kein Refactoring, kein neuer HTTP-Client, kein angepasster Response-Parser.
Structured Output als First-Class-Konzept
Eine Multi-Agenten-Pipeline steht und fällt mit der Qualität der Daten, die zwischen den Agenten weitergegeben werden. Erzeugt der MasterArchitect ein Schema, das die Forge Workers nicht zuverlässig parsen können, entstehen stille Fehler – generierte Dateien, die plausibel aussehen, aber auf subtile Weise falsch sind.
Dank der Structured-Output-Unterstützung von Prism definieren wir PHP-Value-Objects und lassen sie direkt vom Modell befüllen; Prism übernimmt die Schema-Generierung und die Typumwandlung der Antwort. Der MasterArchitect liefert keinen JSON-Blob zurück, den wir defensiv dekodieren müssen – er liefert ein typisiertes ArchitectureSchema-Objekt, das schon beim Eintreffen validiert ist.
An dieser Stelle haben wir den Großteil der rund 5 % Edge-Case-Fehler beseitigt, die die frühere Version mit rohen API-Aufrufen plagten. Validierungsfehler treten jetzt an der Schema-Grenze zutage und werden nicht erst drei Agenten später entdeckt, wenn eine Migration auf eine Spalte verweist, die nie definiert wurde.
Tool Calling ohne Boilerplate
Der Validator-Agent – die letzte Stufe der Pipeline – muss externe Tools aufrufen: php artisan route:list ausführen, prüfen, ob sich die generierten Model-Beziehungen auflösen lassen, und sicherstellen, dass die Migrationen syntaktisch gültig sind. Über das Tool-Calling-Interface von Prism registrieren wir diese als First-Class-Tools mit typisierten Ein- und Ausgaben.
Der Agent entscheidet, welche Tools aufgerufen werden, Prism übernimmt die Function-Call-Schleife, und unsere Tool-Implementierungen bleiben saubere PHP-Methoden statt verschachtelter Callback-Arrays. Das Ergebnis ist ein Validator, der sich wie eine Laravel-Service-Klasse liest und nicht wie ein Prompt-Engineering-Experiment.
PHP als agentische Plattform
Worum es im Kern geht: Das PHP-Ökosystem muss seine KI-Patterns nicht aus der Python-Welt importieren. Das Modell „Agent als Queue Worker“ lässt sich perfekt auf die Job-Infrastruktur von Laravel abbilden. Prism liefert uns die Abstraktionsschicht für die Modelle. Structured Output liefert uns den Vertrag zwischen den Agenten. Tool Calling gibt uns die Möglichkeit, über das Modell hinauszugreifen, wenn es auf überprüfbare Fakten ankommt.
Das Ergebnis ist eine Pipeline, in der jeder Agent ein Laravel-Job ist: isoliert testbar, bei Fehlern wiederholbar, über Horizon beobachtbar und auf derselben Infrastruktur deploybar wie der Rest der Anwendung. Keine Python-Microservices, keine separate Orchestrierungsschicht, keine betriebliche Komplexität, die es in einem Standard-Laravel-Stack nicht ohnehin schon gibt.
Wo wir heute stehen
Der Laravel-Generator von Craftly braucht derzeit unter 2 Minuten Laufzeit und kostet rund 0,19 $ an Modell-Inferenz pro vollständiger Anwendung. Die Kostenverteilung spiegelt die zweistufige Modellstrategie wider: Der MasterArchitect (Sonnet 4.6, anspruchsvolles Reasoning) macht den Großteil dieses Betrags aus; die Forge Workers (Haiku 4.5, Ausführung im großen Maßstab) halten die Kosten pro Datei vernachlässigbar gering.
Prism war nicht die einzige Option. Wir haben geprüft, das Anthropic-SDK direkt aufzurufen, es selbst zu kapseln oder einen Python-Orchestrator über HTTP einzusetzen. Der Grund, warum wir bei Prism gelandet sind, ist einfach: Es ist die richtige Abstraktion auf der richtigen Ebene für ein Laravel-natives agentisches System. Es gibt uns Anbieterflexibilität, strukturierte Verträge zwischen den Agenten und Tool Calling – ohne eine Abhängigkeit einzuführen, die gegen das Framework arbeitet.
Wenn Sie KI-gestützte Funktionen in Laravel entwickeln und dabei zu rohen HTTP-Clients greifen, sehen Sie sich zuerst Prism an. Die Ergonomie ist es wert.