Langfuse zeigt, wie Halo als In-Product-Agent auf dem eigenen MCP-Server entstand

Langfuse hat einen technischen Bericht zu Halo veröffentlicht, dem im Juni gestarteten In-Product-Langfuse-Assistant. Laut dem Unternehmen besteht der Agent größtenteils aus einem Mastra-Agenten, dem öffentlichen MCP-Server und etwas Glue-Code. Die Agent-Schleife läuft bewusst außerhalb der Sandbox.
- Halo, der Langfuse Assistant, startete am 19. Juni als öffentliche Beta und basiert auf einem Mastra-Agenten und dem öffentlichen MCP-Server von Langfuse.
- Halo erhält einen temporären, projektbezogenen API-Schlüssel, standardmäßig schreibgeschützte Tools, eine rollenbasierte Tool-Filterung und Freigaben für jede Datenänderung.
- Hintergrundläufe erlauben es, den Browser zu schließen und später zu Fortschritt und Ergebnissen zurückzukehren; der Status liegt in Postgres, die Jobs in BullMQ.
- Die Agent-Schleife läuft in Backend-Workern, während eine optionale Sandbox ohne standardmäßigen Netzwerkzugang Skripte und Dateiarbeit übernimmt.
- Langfuse nutzt Traces der Halo-Läufe, um MCP-Tools, Skills und Doku zu verbessern und die Kosten zu senken, nachdem sich zeigte, dass das Prompt-Caching nicht wie erwartet funktionierte.
Ein Agent aus vorhandenen Bausteinen
Mit Halo können Nutzerinnen und Nutzer sich Traces erklären lassen, ein Dashboard oder Dataset aufbauen oder Evals einrichten, ohne die Langfuse-Oberfläche zu verlassen. Autorin Lotte Ben räumt die Ironie ein, dass Langfuse, ein Unternehmen, das anderen beim Bau von Agenten hilft, selbst keinen Agenten im Produkt hatte. Nutzer arbeiteten bereits über eigene Agenten mit dem Langfuse-Skill, dem MCP-Server und der CLI, und das Team wollte diese Fähigkeiten ins Produkt holen.
Die erste Version, schreibt Ben, war schlicht ein Mastra-Agent, ein MCP-Server und Glue-Code. Das Team habe keinen neuen Ausführungsalgorithmus erfunden und nichts in Rust neu geschrieben. Ziel war es, möglichst viel wiederzuverwenden, damit Langfuse nicht eigens für Halo einen zweiten Satz an Tools und Anweisungen pflegen muss. Eine Korrektur an einem Tool oder an einer Anleitung kommt dann sowohl dem In-Product-Agenten als auch Power-Usern mit eigenen Setups zugute.
Vom MCP-Ausbau zu Hintergrundläufen
Der erste Schritt war der Ausbau des MCP-Servers. Laut Langfuse kamen mit dem Release vom 29. Mai Tools für Observations, Metriken, Scores, Kommentare, Datasets und Annotation-Queues hinzu, sodass die meisten Projektdaten für Agenten zugänglich wurden.
- 19. Juni: öffentliche Beta des Langfuse Assistant, ein Mastra-Agent hinter einem HTTP-Endpunkt, der Antworten an den Browser streamte und jeweils eine Unterhaltung bearbeitete
- 1. Juli: Schreibaktionen mit Freigaben per Human-in-the-Loop
- 6. August: Ausführung im Hintergrund
- 13. August: Läufe mit Sandbox
Diese Fähigkeiten kündigte das Unternehmen im September gemeinsam an. In der finalen Architektur startet der Browser einen Lauf, und der Webdienst speichert ihn in Postgres. Eine Run-ID kommt in eine BullMQ-Warteschlange, ein Worker nimmt sie auf und führt die Agent-Schleife aus, wobei er Claude auf Bedrock und den Langfuse-MCP-Server aufruft. Weil der Worker unabhängig vom Browser arbeitet, können Nutzer den Tab schließen und später zurückkehren. Das gespeicherte Ereignisprotokoll lässt die Oberfläche wieder aufholen.
Berechtigungen über Tools durchgesetzt
Halo greift auf Projektdaten ausschließlich über den öffentlichen MCP-Server zu. Hinzu kommen Sandbox-Tools, ähnlich denen von Coding-Agenten, sowie UI-spezifische Tools, etwa um die Navigation zu einer anderen Seite vorzuschlagen. Der System-Prompt enthält den Namen der Nutzerin oder des Nutzers, die Zeitzone, die Browsersprachen und die aktuelle URL.
Für jeden Lauf erzeugt der Worker einen temporären, auf das Projekt beschränkten API-Schlüssel, der standardmäßig nur schreibgeschützte MCP-Tools aufrufen darf. Langfuse pflegt im Code des Agenten eine eigene Zuordnung der Tool-Berechtigungen, statt sich auf die Read-only-Annotationen des MCP-Servers zu verlassen. Zudem werden Tools nach der Rolle des angemeldeten Nutzers gefiltert, sodass ein nicht erlaubtes Tool dem Modell gar nicht erst angeboten wird.
Tools, die Daten verändern, erfordern eine Freigabe. Wer „Always approve“ wählt, speichert die Freigabe nur für die jeweilige Unterhaltung, und sie wird bei jedem Lauf gegen die aktuelle Rolle des Nutzers neu geprüft. Braucht Halo einen neuen Datenzugang, muss das Team zuerst ein MCP-Tool ergänzen. Diese Vorgabe gefällt Ben, weil dasselbe Tool dann auch Menschen mit eigenen Agenten erreicht. Für Anleitungen, etwa zum Einrichten von Evals oder zur Migration von Prompts, lädt Halo den Open-Source-Langfuse-Skill als Mastra-Skill und nutzt den Docs-MCP.
Dogfooding mit Langfuse-Traces
Langfuse analysiert Halo mit dem eigenen Produkt. Wenn sich eine Organisation für die Telemetrie von KI-Funktionen entscheidet, kann das Team anhand von Traces der Halo-Läufe erkennen, wo der Agent Schwierigkeiten hat, und dann das MCP-Tool, den gemeinsamen Skill oder die Dokumentation verbessern.
Ben nennt mehrere Beispiele. Agenten sortierten Metriken immer wieder nach totalCost_sum, während das Tool sum_totalCost erwartete, weshalb der MCP-Adapter jetzt beides akzeptiert. Validierungsfehler bei Dashboards nannten das falsche Feld, aber keine Alternativen, daher ergänzte das Team zulässige Werte und Hinweise zum Nachschlagen des Schemas. Als der Betrieb von Halo teuer wurde, zeigten die Traces, dass das Prompt-Caching nicht wie erwartet funktionierte. Die Behebung senkte die Kosten so weit, dass sich der Einsatz leistungsfähigerer Modelle für Halo wieder lohnt.
Ben merkt außerdem an, dass Menschen seit der Ankündigung versucht haben, Halo zu knacken oder auszunutzen, und solche Versuche weiterhin regelmäßig auftauchen. Sie bestärken die strikten Grenzen dafür, worauf der Agent zugreifen darf.
Warum der Agent außerhalb der Sandbox bleibt
Als die Sandbox hinzukam, behielt Langfuse die Agent-Schleife in den Backend-Workern. Der Agent erhält vier Tools, read, write, edit und bash, um in einer separaten Umgebung mit Dateien zu arbeiten und Skripte auszuführen. Eine Sandbox wird erstellt, sobald der Agent in einer Unterhaltung erstmals eines dieser Tools nutzt. Sie hat standardmäßig keinen Netzwerkzugang, Code läuft als nicht privilegierter Nutzer, und eine untätige Sandbox wird angehalten und schließlich beendet und bereinigt.
Kein Prozess darin kann Langfuse oder das übrige Internet direkt erreichen. Der Agent kann Daten nur einspeisen, nachdem er sie über autorisierte MCP-Aufrufe abgerufen hat, weshalb sich das Team nicht gegen beliebige Netzwerkaufrufe aus der Sandbox heraus wappnen musste. Viele Unterhaltungen, etwa eine Frage zur Dokumentation oder die Abfrage der Traces von gestern, brauchen keine Sandbox, und eine VM dafür zu starten würde Arbeitsspeicher und Speicherplatz verschwenden.
In Langfuse Cloud läuft die Sandbox auf AWS Lambda MicroVMs, die Schnittstelle ist aber so gebaut, dass sie sich an andere Anbieter anpassen lässt. Wer selbst hostet, kann ganz auf eine Sandbox verzichten.
Was das für Nutzer bedeutet
Für Langfuse-Nutzer bedeutet das Design, dass Verbesserungen für Halo auch dem MCP-Server, dem Skill und der Dokumentation zugutekommen, die sie mit Agenten wie Claude Code oder Cursor verwenden. Teams, die selbst hosten, behalten die Möglichkeit, den Assistenten ohne Sandbox zu betreiben.
Langfuse: How we built Langfuse Halo - Langfuse


