Mastra: TypeScript-Framework für Agenten, Workflows und MCP-Server

Welche Lücke Mastra im TypeScript-Stack schließt

Ein Agent ist in TypeScript schnell gebaut: Modell aufrufen, Werkzeuge registrieren, Schleife laufen lassen. Mühsam wird der Rest. Wo wird der Gesprächsverlauf gespeichert, wenn der Prozess neu startet? Wie pausiert ein Lauf, bis ein Mensch eine Freigabe erteilt? Wie wird ein mehrstufiger Ablauf mit Verzweigungen und parallelen Zweigen beschrieben, ohne dass daraus ein Callback-Geflecht wird? Mastra setzt genau an dieser Stelle an und liefert diese Bausteine als Pakete, statt sie jedem Team separat nachbauen zu lassen. Die Zielgruppe sind TypeScript-Entwickler, die bereits React, Next.js oder Node einsetzen und ihre KI-Funktionen nicht in einem zweiten Sprach-Ökosystem betreiben wollen. Das README formuliert den Anspruch als Framework für KI-Anwendungen und Agenten auf einem modernen TypeScript-Stack, das von frühen Prototypen bis zu produktionsreifen Anwendungen reicht. Wer heute einen Agenten mit Werkzeugaufrufen, Speicher und Auswertung braucht, bekommt hier eine zusammenhängende Struktur statt einer Sammlung einzelner Bibliotheken.

Agenten und Workflows als zwei getrennte Ausführungsmodelle

Die wichtigste Designentscheidung zeigt sich in der Aufteilung zwischen Agenten und Workflows. Ein Agent bekommt ein Ziel, wählt selbst Werkzeuge und iteriert intern, bis das Modell eine endgültige Antwort liefert oder eine optionale Abbruchbedingung greift. Dieses Modell eignet sich für offene Aufgaben, bei denen der Lösungsweg vorab nicht feststeht. Ein Workflow ist das Gegenteil: ein Graph mit expliziter Kontrolle, beschrieben über eine Syntax mit `.then()`, `.branch()` und `.parallel()`. Sobald die Reihenfolge der Schritte fachlich festgelegt ist, etwa bei einer Freigabekette, ist der Graph die passendere Wahl, weil sich jeder Übergang nachvollziehen lässt. Beide Modelle teilen sich darunter dieselbe Speicherschicht. Genau das macht Human-in-the-loop praktikabel: Ein Agent oder Workflow wird suspendiert, wartet auf Eingabe oder Zustimmung und läuft später an derselben Stelle weiter, weil der Ausführungszustand im Storage liegt. Ohne diese persistente Ablage wäre ein Pausieren über Prozessgrenzen hinweg nicht möglich.

Kontext, Speicher und der Modellzugang über einen Router

Für den Kontext nennt das README drei getrennte Quellen. Erstens den Gesprächsverlauf, der als Conversation History geführt wird. Zweitens abgerufene Daten aus eigenen Quellen, also APIs, Datenbanken oder Dateien, was unter dem Stichwort RAG läuft. Drittens Observational Memory, das menschenähnliche Erinnerung ergänzen soll, damit Agenten über längere Interaktionen hinweg kohärent bleiben. Diese Trennung ist sinnvoll, weil die drei Quellen unterschiedlich teuer und unterschiedlich flüchtig sind. Ein Verlauf wächst mit jeder Nachricht, abgerufene Dokumente sind austauschbar, Erinnerungen sollen verdichten statt anzuhäufen. Auf der Modellseite steht ein Router, der über eine einheitliche Schnittstelle mehr als 40 Anbieter anbindet, darunter OpenAI, Anthropic und Gemini. Der Nutzen liegt weniger in der Zahl als in der Austauschbarkeit: Ein Anbieterwechsel ist eine Konfigurationsfrage und keine Umschreibung der Aufrufstellen. Wer ohnehin nur ein Modell eines einzigen Anbieters nutzt, gewinnt dadurch nichts, zahlt aber auch nichts dafür.

Installation über den CLI-Assistenten

Der vom README empfohlene Weg ist ein einzelner Befehl: `npm create mastra@latest`. Wer den Assistenten umgehen will, kann Projektname und Anbieter direkt mitgeben, etwa `npm create mastra@latest <project-name> -- --llm <provider>`. Als Anbieterwerte nennt das Material openai, anthropic, google und xai. Der Befehl legt ein Standardprojekt an, installiert Mastra-Skills für erkannte Coding-Assistenten und initialisiert Git, wenn es die Situation erlaubt. Danach startet der Entwicklungsserver, im README über `npx bgproc start -n <project-name> -w -- npm run dev`. Mastra Studio läuft anschließend unter `http://localhost:4111` und dient laut README dem Bauen, Testen und Verwalten von Agenten, Workflows und Werkzeugen. Eine manuelle Installation ist als Alternative dokumentiert. Wer den Assistenten nicht nutzt, sollte beachten, dass die automatische Skill-Installation für Coding-Assistenten dann entfällt und die Einrichtung selbst nachgezogen werden muss.

Human-in-the-loop und die Kosten der Zustandshaltung

Suspendieren und Fortsetzen klingt nach einem kleinen Feature, ist aber eine Infrastrukturentscheidung. Damit ein Lauf beliebig lange pausieren kann, muss der Zustand außerhalb des Prozesses liegen. Mastra verweist dafür auf seine Storage-Schicht. Daraus folgen zwei Dinge, die in der Dokumentation nicht als Warnung auftauchen, aber aus dem Mechanismus folgen. Erstens ist der Storage kein optionales Add-on, sondern Voraussetzung für diesen Anwendungsfall, und damit Teil der Betriebsfläche. Zweitens braucht ein pausierter Lauf eine Strategie für veraltete Zustände: Wenn ein Vorgang Wochen liegt und das Team zwischenzeitlich die Werkzeugsignatur ändert, muss klar sein, was beim Fortsetzen passiert. Mastra ist hier die falsche Wahl, wenn niemand den zusätzlichen Speicher betreiben will und Freigaben synchron im selben Request erledigt werden können. Für einen Chatbot ohne Freigabeschritt ist der ganze Mechanismus überflüssig.

MCP-Server als Ausgabeseite des Frameworks

Mastra beschränkt sich nicht darauf, Werkzeuge zu konsumieren. Man kann mit dem Framework eigene Model-Context-Protocol-Server schreiben und darin Agenten, Werkzeuge und andere strukturierte Ressourcen über die MCP-Schnittstelle bereitstellen. Diese Server sind dann für jedes System erreichbar, das das Protokoll spricht. Der praktische Effekt ist eine Umkehrung der Richtung: Statt dass die eigene Anwendung fremde Fähigkeiten einbindet, werden die eigenen Fähigkeiten für fremde Agenten sichtbar. Das ist nützlich, wenn ein Werkzeug bereits in einer TypeScript-Anwendung steckt und auch außerhalb davon genutzt werden soll, ohne eine zweite Implementierung zu pflegen. Wer dagegen nur eine einzelne Anwendung mit einem Modell verbindet, für den ist diese Ausgabeseite schlicht zusätzliche Angriffsfläche, die man nicht aufmachen muss.

Duale Lizenzierung: Apache-2.0 plus Enterprise-Verzeichnisse

Das Repository nennt keine Standard-Lizenzkennung, sondern beschreibt ein duales Modell. Der Kern und die große Mehrheit des Codes stehen unter Apache-2.0. Verzeichnisse mit dem Namen `ee/`, im README am Beispiel `packages/core/src/auth/ee/` illustriert, stehen dagegen unter der Mastra Enterprise License. Diese Teile sind source-available, für Entwicklung und Tests frei nutzbar, für den Produktiveinsatz aber an eine gültige Enterprise-Lizenz gebunden. Die vollständige Zuordnung verweist das README auf `LICENSE.md` und `ee/LICENSE`. Für die Bewertung heißt das: Die Frage ist nicht, ob Mastra Open Source ist, sondern welche Pfade im eigenen Abhängigkeitsbaum tatsächlich aus `ee/` stammen. Das lässt sich vor dem Produktivgang prüfen, indem man die installierten Pakete gegen die Zuordnung in `LICENSE.md` hält. Eine rechtliche Bewertung ersetzt das nicht.

Wartung, Release-Takt und Alternativen

Die Release-Liste zeigt drei Versionen des Kernpakets innerhalb von etwa zwei Wochen: 1.63.0 am 26. August 2026, 1.64.0 am 3. September und 1.65.0 am 9. September. Der letzte Push liegt auf demselben Tag. Dieser Takt bedeutet, dass Teams eine Update-Routine brauchen, weil sich Nebenversionen schnell stapeln. Wer Agenten auf Basis eines sich bewegenden Kerns baut, sollte die Version des Kernpakets festnageln und Upgrades gebündelt fahren. Als Alternative bietet sich an, direkt auf einem schlanken SDK aufzusetzen und die Orchestrierung selbst zu schreiben. Der Unterschied liegt nicht im Umfang, sondern in der Zuständigkeit: Ohne Framework gehören Werkzeugschleife, Speicherung des Verlaufs und Persistenz für Pausen dem eigenen Team. Mastra nimmt diese Teile ab und verlangt dafür, dass man sein Ausführungsmodell, seine Storage-Schicht und seine Lizenzaufteilung akzeptiert. Für ein Projekt mit einem einzigen Modellaufruf ist der selbstgeschriebene Weg kürzer; sobald mehrere Werkzeuge, Freigabeschritte und Auswertungen zusammenkommen, kippt das Verhältnis.

Redaktionelles Fazit

Mastra passt zu TypeScript-Teams, die Agenten und mehrstufige Workflows im selben Repo wie ihre Anwendung betreiben und den Kern unter Apache-2.0 weiterverwenden wollen. Wer eine reine Python-Umgebung hat oder ausschließlich einen einzelnen LLM-Aufruf ohne Tools, Speicher und Auswertung braucht, fährt mit einem schlanken SDK direkter. Vor dem Produktivgang sollte man prüfen, welche Verzeichnisse im eigenen Abhängigkeitsbaum unter ee/ fallen und ob die dortigen Funktionen produktiv genutzt werden, denn dafür verlangt die Mastra Enterprise License eine gültige Enterprise-Lizenz.

Offizielle Quellen

1. Issues
2. mastra-ai/mastra on GitHub
3. Project website
4. README
5. Releases