Future AGI: Evaluations, Tracing und Guardrails in einem selbst gehosteten Stack

Welche Lücke der Stack schließen soll

Der README benennt das Problem direkt: Teams kleben Evaluations, Observability und Guardrails aus getrennten Diensten zusammen, und diese Teile bilden keinen Kreislauf. Konkret heißt das, ein Trace landet in einem Werkzeug, die Bewertung in einem zweiten, die Laufzeitprüfung in einem dritten, und niemand führt das Ergebnis der Bewertung zurück in die nächste Version des Prompts. Future AGI setzt dagegen eine Schleife aus simulate, evaluate, protect, monitor, optimize, die laut README auf einer Plattform liegt. Die Zielgruppe sind damit nicht Data-Science-Experimente im Notebook, sondern Teams, die einen Agenten bereits betreiben und eine Aussage darüber brauchen, ob eine Änderung ihn besser oder schlechter macht. Der README positioniert das Produkt als nightly release for early testing und räumt selbst ein, dass raue Kanten zu erwarten sind. Wer Stabilität vor Funktionsumfang braucht, sollte das ernst nehmen.

Wie Traces, Evaluatoren und Gateway zusammenspielen

Sichtbar ist die Architektur an zwei Stellen. Erstens die Instrumentierung: register(project_name="my-agent") aus fi_instrumentation gefolgt von OpenAIInstrumentor().instrument() aus traceai_openai. Nach diesem Aufruf läuft der vorhandene OpenAI-Code weiter, erzeugt aber Traces. Der README nennt OpenTelemetry als Transport und spricht von 50+ framework instrumentors, es gibt also eine Python- und eine Node-Seite, letztere über das npm-Paket @traceai/fi-core. Zweitens das Gateway: laut README in Go geschrieben, mit OpenAI-kompatibler HTTP-Schnittstelle und weighted routing. Die Bewertung sitzt zwischen diesen beiden Punkten, sie liest Traces und erzeugt Signale, die laut README wieder in die nächste Version zurückfließen. Das ist eine Pipeline-Beschreibung, keine Detaildokumentation. Wer wissen will, wie ein Evaluator intern einen Judge-Prompt aufbaut oder wie Sampling konfiguriert wird, findet im vorliegenden Material keine Antwort. Der README verspricht, dass every evaluator, every prompt, every trace inspectable sei, was sich nur im Code prüfen lässt, nicht in der Beschreibung.

Installation: ein Befehl, zwei Skripte, ein Sonderfall

Der Selbsthost-Pfad setzt Docker Desktop oder Docker Engine mit Docker Compose voraus. Danach genügen git clone https://github.com/future-agi/future-agi.git, cd future-agi und ./bin/install unter macOS, Linux oder WSL, beziehungsweise .\bin\install.ps1 unter Windows PowerShell. Die Oberfläche läuft anschließend unter http://localhost:3000. Der Installer zieht veröffentlichte Images, es wird also kein Quellcode gebaut. Für den Produktivbetrieb verweist der README auf ./deploy/setup.sh, das erforderliche Secrets erzeugt und die Image-Version pinnt. Dieser Schritt ist nicht optional, wenn die Installation länger als einen Testlauf stehen soll. Ein zweiter Befehl betrifft nur Upgrades: Wenn bereits Traces vorhanden sind, muss nach dem Hochfahren des neuen Stacks ./bin/property-catalog-backfill --execute laufen, unter Windows .\bin\property-catalog-backfill.ps1 -Execute. Der README ist hier ungewöhnlich präzise: normale Neustarts starten keinen historischen Scan, der Backfill nutzt dasselbe Image, das Docker Compose bereits ausgewählt hat, überspringt aktive Workspaces und arbeitet über ein dauerhaftes Ledger weiter. Er ist auf aktive Workspaces und Projekte begrenzt, die der Supervisor zulässt, und auf ein rollierendes Fenster von 366 Tagen.

Die Benchmark-Zahlen und was sie nicht aussagen

Der README nennt für das Go-Gateway etwa 9,9 ns für gewichtetes Routing, rund 29 k Anfragen pro Sekunde auf einer t3.xlarge und P99 von höchstens 21 ms bei eingeschalteten Guardrails. Diese Werte stammen aus dem Repository selbst, nicht aus einer unabhängigen Messung, und der README verweist auf einen mitgelieferten Benchmark-Harness, mit dem sie reproduzierbar sein sollen. Das ist mehr, als viele Projekte bieten, aber es bleibt eine Selbstauskunft. Drei Dinge sind an diesen Zahlen nicht ablesbar: welche Evaluatoren im Pfad aktiv waren, wie lang die Prompts waren und ob die Guardrails im selben Prozess oder als separater Aufruf liefen. Wer Kapazität plant, sollte den Harness selbst laufen lassen, statt die Zahlen zu übernehmen. Die 21 ms P99 sind zudem eine Gateway-Kennzahl, keine Ende-zu-Ende-Latenz eines Agenten, denn Modellaufrufe liegen außerhalb dieser Messung.

Wo der Stack nicht passt

Der stärkste Einwand steht im README selbst: nightly release for early testing, stable version coming out soon. Ein Projekt, das seine eigene Reife so beschreibt, ist kein Kandidat für eine Plattform, die Audit-Anforderungen erfüllen muss. Dazu kommt der Umfang. Wer nur Traces sammeln will, installiert hier ein Gateway, eine Weboberfläche, eine Datenbank und einen Backfill-Mechanismus mit 366-Tage-Fenster, um eine Funktion zu bekommen, die ein einzelner OTel-Collector plus ein Speicher-Backend ebenfalls liefert. Der Backfill ist ein weiteres Warnsignal für den Betrieb: Er existiert, weil Property-Kataloge nach einem Upgrade inaktiver Workspaces nicht automatisch befüllt werden. Das ist ein bewusster Kompromiss, denn ein automatischer Scan über alle historischen Traces wäre teuer, aber es bedeutet, dass ein Upgrade mit Datenbestand einen manuellen, zeitlich begrenzten Lauf nach sich zieht. Wer viele kleine Workspaces betreibt, sollte vorher abschätzen, wie lange dieser Lauf dauert. Und wer ausschließlich offline evaluiert, ohne Laufzeitkomponente, braucht weder Gateway noch Guardrails.

Was ein spezialisiertes Tracing-Backend anders macht

Der README nennt Langfuse, Braintrust, Helicone und Guardrails AI ausdrücklich als die Werkzeuge, die Future AGI ersetzen will. Der Unterschied liegt weniger im Funktionsumfang als im Kopplungsgrad. Ein reines Tracing-Backend nimmt Spans entgegen und macht sie durchsuchbar. Es bewertet nicht, und es blockiert nichts zur Laufzeit. Genau diese Trennung ist in manchen Umgebungen ein Vorteil: Ein Ausfall des Tracing-Backends darf den Anfragepfad nicht berühren, und ein Evaluationsjob darf keine Produktionslatenz erzeugen. Future AGI setzt das Gateway in den Pfad, weshalb Guardrails überhaupt P99-Werte haben können. Das ist die eigentliche Design-Entscheidung des Projekts: Bewertung und Schutz liegen inline, nicht daneben. Wer diese Kopplung nicht will, muss sie explizit umgehen, indem er nur die Instrumentierung einsetzt und das Gateway weglässt. Der README beschreibt diese Teilnutzung nicht als offiziellen Pfad, sie ergibt sich aber aus der Struktur der Pakete.

Lizenz, Wartung und Upgrade-Aufwand

Der Kern steht unter Apache-2.0, der README bezeichnet ihn als Apache 2.0 core und erwähnt daneben einen verwalteten Cloud-Dienst. Die Formulierung core ist der Hinweis, auf den man achten sollte: Nicht jede Komponente muss unter derselben Lizenz stehen, und das vorliegende Material benennt keine Ausnahmen. Wer den Stack kommerziell einbettet, sollte die LICENSE-Datei und die Lizenzen der einzelnen Images prüfen, bevor er plant. Das ist keine Rechtsberatung, sondern der Punkt, an dem eine Prüfung ansetzt. Zum Wartungsaufwand lässt sich aus den veröffentlichten Releases etwas ableiten: v1.36.1 am 8. September, v1.37.0 und v1.37.1 am 9. September. Zwei Releases an einem Tag deuten auf eine hohe Änderungsrate hin, was für frühe Nutzer gut und für Betreiber teuer ist. Jedes Upgrade mit vorhandenen Traces bringt den Backfill-Schritt mit. Wer die Image-Version über ./deploy/setup.sh pinnt, kontrolliert den Zeitpunkt, muss aber selbst nachziehen. Ein automatisches Update sollte man bei diesem Release-Tempo nicht ungeprüft laufen lassen.

Redaktionelles Fazit

Wer Tracing, Evaluations und Guardrails heute aus drei oder vier Diensten zusammensetzt und die Datenhoheit behalten muss, findet hier einen konsistenten Stack mit Apache-2.0-Kern und reproduzierbarem Benchmark-Harness. Wer nur einen einzelnen Baustein braucht, etwa ausschließlich Tracing oder ausschließlich Prompt-Versionierung, fährt mit einem spezialisierten Werkzeug schlanker. Vor dem Produktiveinsatz zuerst ./deploy/setup.sh ausführen, um Secrets zu erzeugen und die Image-Version zu pinnen, und danach ./bin/property-catalog-backfill --execute auf einer Kopie mit echten Traces testen: dieser Schritt ist der einzige im README, der bei einem Upgrade mit vorhandenen Daten explizit angestoßen werden muss.

Offizielle Quellen

1. future-agi/future-agi on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases