Eine Anfrage, eine ganze Aufgabe: ein Blick in Mangrove

Am 4. November gaben wir einem unserer Testagenten eine kleine Aufgabe: den KI-Nachrichtenüberblick des Tages schreiben, fünf Meldungen, jede mit Quelle.

Zwei Minuten und zweiundzwanzig Sekunden später hatte er eine Antwort. Er hatte acht Websuchen ausgeführt und eine neunte versucht, die abgelehnt wurde. Er hatte es bei sechs Seiten versucht, und drei dieser Websites blockierten automatisierte Zugriffe. Als er glaubte, fertig zu sein, schickte ihn eine Prüfung zurück an die Arbeit. Und am Ende seiner Antwort stand, welche zwei Meldungen nur auf Suchergebnissen beruhten, weil er die Seiten dahinter nie zu lesen bekam.

Der ganze Lauf verbrauchte 1,96 Wh Energie.

Dieser Lauf erklärt gut, was Mangrove ist, denn fast alles, was daran zählt, geschah dort, wo du es nicht sehen konntest.

Transkript (übersetzt)

Ein Chatmodell gibt dir eine Antwort. Die meiste Arbeit ist mehr als eine Antwort. Sie heißt suchen, lesen, vergleichen, prüfen und oft: noch mal von vorn. Mangrove ist der Orchestrierungs-Endpunkt von GreenPT. Du sendest eine Anfrage. Mangrove ermittelt, was die Aufgabe braucht, nutzt die richtigen Tools, prüft seine eigene Antwort und gibt dir das Ergebnis. Du musst keine Agenten-Schleife bauen und keine Tools anbinden. Wie der Baum arbeitet es unter der Oberfläche.

Ein Chatmodell gibt dir eine Antwort

Eine Chat-Completion ist eine Frage und eine Antwort. Die meiste Arbeit sieht nicht so aus. Sie heißt suchen, lesen, vergleichen, prüfen und ziemlich oft: noch mal von vorn.

Du kannst diese Schleife selbst bauen. Viele Teams tun das. Du bindest Tools an, schreibst eine Schleife um das Modell, ergänzt hier einen Retry und dort ein Limit, und dann merkst du, was wirklich teuer ist: festzulegen, was passiert, wenn eine Seite 1,3 Millionen Zeichen lang ist, wenn das Modell sagt, es sei fertig, und es nicht ist, oder wenn jede Suche scheitert und das Modell eine höfliche Entschuldigung schreibt, die dein System als Erfolg verbucht.

Mangrove ist der Orchestrierungs-Endpunkt von GreenPT. Du sendest eine Anfrage, und Mangrove führt die ganze Aufgabe durch: Es ermittelt, was die Aufgabe braucht, nutzt die richtigen Tools, prüft seine eigene Antwort und gibt dir das Ergebnis.

curl -X POST https://api.greenpt.ai/v1/agents/runs \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{ "question": "Summarise the EU grid carbon intensity news from this week" }'

Du bekommst sofort eine agentId. Dann fragst du den Lauf ab oder streamst seine Schritte, während sie passieren. Du musst keine Agenten-Schleife bauen und keine Tools anbinden.

Der Name ist wörtlich gemeint. Eine Mangrove leistet ihre Arbeit unter der Oberfläche: Was du siehst, ist ein Baum, und was alles trägt, ist ein Netz aus Wurzeln, die in alle Richtungen reichen. So denken wir über Orchestrierung. Über der Oberfläche siehst du eine Aufgabe und ein Ergebnis.

Eine Unterscheidung, bevor es weitergeht, weil sie für alles Folgende zählt. Mangrove ist kein Modell. Es ist das System, das eines betreibt. Das Modell, das die Entscheidungen trifft, hat einen eigenen Namen.

Metis entscheidet. Mangrove erledigt die Arbeit.

Transkript (übersetzt)

Bevor ein Lauf startet, zählen drei Fragen. Wie schwer ist diese Aufgabe? Wie viel Arbeit macht sie? Und wie viele Quellen braucht sie? Ein Modell, das rät, gibt zu viel aus oder zu wenig. Also fragt Mangrove Metis, unser Entscheidungsmodell. Metis schreibt nichts. Es liest die Aufgabe einmal und liefert eine Wahrscheinlichkeit für jede mögliche Antwort. Alle drei Fragen in einem Durchlauf. Etwa 65 Millisekunden Modellzeit und weniger als fünf Tausendstel einer Wattstunde. Metis entscheidet. Mangrove erledigt die Arbeit.

Bevor ein Lauf startet, zählen drei Fragen. Wie schwer ist diese Aufgabe? Wie viel Arbeit macht sie? Wie viele Quellen braucht sie?

Liegst du dabei falsch, zahlst du so oder so drauf. Ein Agent ohne Gefühl für Größenordnungen setzt ein großes Modell und ein langes Budget für eine einzeilige Abfrage ein oder gibt einer echten Rechercheaufgabe zu wenig Raum, um fertig zu werden.

Also fragt Mangrove Metis, unser Entscheidungsmodell. Metis schreibt nicht. Du gibst ihm einen Fall und eine Reihe von Fragen, es liest alles einmal und liefert eine Wahrscheinlichkeit für jede mögliche Antwort. Mangrove stellt alle drei Fragen in einer einzigen Anfrage.

Das kam am 5. November für eine echte Aufgabe zurück: “Summarise this week’s news on EU grid carbon intensity in five bullets, with a source for each.”

Frage	Antwort von Metis	Der Rest
Wie schwer ist sie?	standard, 62 %	complex 27 %, simple 12 %
Wie viel Arbeit macht sie?	medium, 72 %	long 15 %, short 13 %
Wie viele Quellen?	several, 71 %	many 14 %, few 9 %, none 6 %

Diese Entscheidung brauchte 63 ms Modellzeit und 0,0041 Wh und erzeugte null Tokens. Die Zahlen stammen aus dem Impact-Bericht, den die API mit der Antwort zurückgibt.

Warum nicht einfach ein Chatmodell die Aufgabe einstufen lassen? Das haben wir versucht. Im Oktober haben wir beide für das Chat-Routing an 65 von Hand gelabelten Gesprächsrunden getestet. Die Gesamtgenauigkeit lag nah beieinander, 77 % für Metis gegenüber 80 % für ein allgemeines Modell, das in JSON antwortete. Der Unterschied lag in den Fehlern und in der Wartezeit. Das allgemeine Modell brauchte im Median 2,3 Sekunden und unterschätzte in 20 % der Fälle, wie viel Aufwand eine Gesprächsrunde erforderte. Metis beantwortete drei Fragen in etwa 230 ms und unterschätzte in 2 % der Fälle. Ein Orchestrator stellt solche Fragen ständig, und eine Unterschätzung ist der teure Fehler: Die Aufgabe bekommt zu wenig Raum und scheitert. Auch die Wahrscheinlichkeiten helfen, denn sie sind eine Zahl, mit der deine Logik arbeiten kann, ohne dass etwas geparst werden muss.

Das ist also der Platz von Metis. Metis urteilt. Mangrove handelt nach dem Urteil. Innerhalb des Laufs denkt ein Sprachmodell; Metis legt von außen die Bedingungen dafür fest.

Der passende Aufwand

Transkript (übersetzt)

Nicht jede Aufgabe verdient denselben Aufwand. Frag nach der Hauptstadt von Finnland, und Metis sagt simple und short. Frag nach einer Tabelle aller Unternehmen aus drei Aktienindizes, und es sagt complex und long. Diese Einstufungen prägen den Lauf. Die Schwierigkeit wählt das Modell, ein leichter Job weckt also nie ein großes. Die Länge setzt die Limits für Aufrufe, Tokens und Zeit. Die Recherchetiefe bestimmt, wie weit er suchen darf. Ein Nachrichtenüberblick bekommt acht Suchen, nicht siebzehn. Und kommt eine Einstufung nicht zurück, behält der Lauf die Limits, mit denen er gestartet ist. Genug Arbeit, und nicht mehr.

Schwer und lang sind zwei verschiedene Dinge. Die Websites von 250 Unternehmen zu finden, ist pro Eintrag einfach und insgesamt lang. Bei einem subtilen Deadlock ist es umgekehrt. Deshalb hält Mangrove die Achsen auseinander, und jede steuert etwas anderes.

Die Schwierigkeit wählt das Modell. Bei einem gespeicherten Agenten geht eine als simple eingestufte Aufgabe an ein kleineres Modell und eine als complex eingestufte an ein stärkeres, ein leichter Job weckt also nie ein großes Modell. Legst du für deinen Agenten ein Modell fest, gilt deine Wahl.

Die Länge setzt die Limits. Eine Aufgabe bekommt ein Budget aus Modellaufrufen, Tokens und Sekunden, das zu ihrer Größe passt.

Die Recherchetiefe bestimmt, wie weit ein Lauf suchen darf. Sie entstand aus einer Messung. Bevor es sie gab, brauchte ein Nachrichtenüberblick mit fünf Meldungen zwischen 8 und 17 Websuchen und las bis zu 9 Seiten, alles mit unterschiedlichen Suchanfragen, denn jede Suche, die etwas fand, lud zur nächsten ein. Ein Lauf hatte kein Gefühl dafür, wann es genug war.

Recherchetiefe	Websuchen	Gelesene Seiten
None	1	1
Few	3	3
Several	8	6
Many	keine Obergrenze	keine Obergrenze

Daher kam die Ablehnung der neunten Suche in unserem Nachrichtenüberblick. Der Lauf kennt sein Limit von Anfang an, und wenn er es erreicht, antwortet das Tool, dass das Budget aufgebraucht ist, und bittet ihn, aufzuschreiben, was er hat. Und die Einstufungen von Metis fallen für sehr unterschiedliche Aufgaben tatsächlich sehr unterschiedlich aus: “What is the capital of Finland?” kam als simple (98 %) und short (96 %) zurück. Eine Tabelle aller börsennotierten Unternehmen in AEX, AMX und AScX kam als complex (71 %) und long (93 %) zurück.

Kommt eine Einstufung gar nicht zurück, bricht nichts. Ein Lauf, der nicht eingestuft werden kann, behält die Limits, mit denen er gestartet ist. Ein ausgefallener Klassifikator sagt nichts über die Aufgabe, darum darf er auch nichts einschränken.

Erst planen, dann handeln

Transkript (übersetzt)

Ein Lauf beginnt nicht mit Improvisation. Was feststeht, kommt zuerst. Eine Aufnahme wird transkribiert und ein Bild angesehen, bevor das Modell deine Frage überhaupt sieht. Eine Aufgabe mit mehr als einem Schritt bekommt einen schriftlichen Plan mit höchstens acht Schritten, bevor die Arbeit beginnt. Dieser Plan wird gegen die Tools geprüft, die dieser Lauf nutzen darf. Lässt er sich nicht ausführen, geht die Aufgabe ohne ihn weiter. Dann übernimmt die agentische Schleife: bis zu zwanzig Runden, in denen Tools aufgerufen und Ergebnisse gelesen werden, mit einer To-do-Liste, die du mitverfolgen kannst. Feste Schritte für das, was feststeht. Urteilsvermögen für das, was offen ist.

Ein Lauf beginnt nicht mit Improvisation.

Was feststeht, kommt zuerst. Schickst du eine Aufnahme, wird sie transkribiert, bevor das Modell deine Frage überhaupt sieht. Schickst du ein Bild, wird es zuerst angesehen. Das Modell muss weder das eine noch das andere selbst entscheiden, und es muss nie eine mehrere Megabyte große Datei als Tool-Argument wiederholen. Das wäre langsam und teuer, und ein einziges falsches Zeichen würde sie beschädigen.

Eine Aufgabe, die als mehr als ein einzelner Schritt eingestuft ist, kann dann einen schriftlichen Plan mit höchstens acht Schritten bekommen, der entsteht, bevor die Arbeit beginnt. Das ist mit Absicht ein eigener Aufruf. Ein Plan, der mitten in der Arbeit entsteht, erzählt nur nach, was ohnehin passiert; ein Plan, der zuerst entsteht, ist eine Absichtserklärung, die du prüfen kannst. Er wird gegen die Tools geprüft, die dieser Lauf nutzen darf, und jeder Schritt, dessen Eingabe von einem früheren Ergebnis abhängt, bleibt dem Urteil des Modells überlassen. Scheitert die Planung oder lässt sich die Aufgabe nicht in Schritte zerlegen, die sich vorab festzulegen lohnen, verzichtet der Planer, und der Lauf geht so weiter, wie er es ohne Plan getan hätte.

Dann übernimmt die agentische Schleife: bis zu zwanzig Runden, in denen Tools aufgerufen, Ergebnisse gelesen und die nächsten Schritte entschieden werden, mit einer To-do-Liste, die du im Stream mitverfolgen kannst.

Feste Schritte für das, was feststeht. Urteilsvermögen für das, was offen ist.

Worauf Mangrove zugreifen kann

Transkript (übersetzt)

Ein Agent ist nur so nützlich wie das, was er erreichen kann. Mangrove sucht im Web und liest die Seiten, die es findet. Es parst Dokumente, sieht sich Bilder an und transkribiert Meetings. Es schreibt und startet Python in einer isolierten Sandbox, für Rechnungen, Diagramme und Word-, Excel- und PowerPoint-Dateien. Es speichert Werte zwischen Läufen, damit der nächste vergleichen kann. Mit deiner Erlaubnis erreicht es deine eigene Arbeit: Outlook, OneDrive, SharePoint und jeden MCP-Server, den du verbindest. Es kann in Outlook einen Antwortentwurf schreiben. Senden kann es ihn nie.

Ein Agent ist nur so nützlich wie das, was er erreichen kann. Von Haus aus kann Mangrove:

• Im Web suchen und Seiten lesen und sich dabei auf die Passagen beschränken, die für die Suche zählen.
• Dokumente parsen, etwa PDFs und Word-Dateien, über einen Link oder einen Upload.
• Bilder direkt ansehen, sodass Diagramme und Layouts als Bilder erfasst und nicht als Text ausgelesen werden.
• Meetings transkribieren und dann mit dem Transkript arbeiten, samt Sprechern, Entscheidungen und Aufgaben.
• Python ausführen, in einer isolierten Sandbox, für Rechnungen, Datenanalysen und Diagramme und um echte Word-, Excel-, PowerPoint- und PDF-Dateien zu erzeugen.
• Einen Wert zwischen Läufen speichern, unter einem Namen, damit der Lauf der nächsten Woche mit dieser Woche vergleichen kann.

Mit deiner Erlaubnis erreicht Mangrove auch deine eigene Arbeit: Suchen und Lesen in Outlook, deine Dateien in OneDrive und SharePoint und jeden MCP-Server, den du verbindest. Es kann Dateien zurück in OneDrive speichern, und es kann in Outlook einen Antwortentwurf schreiben.

Senden kann es ihn nicht. Es gibt kein Sende-Tool, und auch der Endpunkt hinter dem Entwurfs-Tool kann nicht senden. Eine Antwort landet in deinem Ordner Entwürfe und wartet auf dich. Diese Grenze haben wir absichtlich eingebaut, und wir erklären sie lieber, als sie zu entfernen.

Das Modell entscheidet nicht selbst, wann es fertig ist

Transkript (übersetzt)

Die meisten Agenten entscheiden selbst, wann sie fertig sind. Mangrove überlässt das nicht dem Modell. Jeder Plan endet mit einer Prüfung, die kein Plan entfernen kann. Beantwortet das die Frage vollständig? Würde ein Tool, das du noch nicht genutzt hast, eine Lücke schließen? Zurück an die Arbeit zu gehen, zählt. Nur die To-do-Liste abzuhaken, zählt nicht. Und wenn sich eine Aufgabe nicht erledigen lässt, sagt der Lauf das. Er endet als nicht erledigt, mit Begründung, statt mit einer Entschuldigung, die als Erfolg gilt. Ist jedes aufgerufene Tool gescheitert, endet der Lauf als nicht erledigt, so überzeugt die Antwort auch klingt. Ein ehrliches Ende gehört zur Arbeit.

Dieser Teil von Mangrove kommt daher, dass wir Agenten beim Scheitern zugesehen haben.

In einer einfachen Agenten-Schleife entscheidet das Modell, wann es fertig ist: Es ruft keine Tools mehr auf, und was es zuletzt gesagt hat, ist die Antwort. Mangrove überlässt das nicht dem Modell. Jeder Plan endet mit einer Prüfung, und kein Plan kann sie entfernen, weil die Runtime sie erst hinzufügt, nachdem der Plan geschrieben ist.

Die Prüfung fragt, ob die Antwort die Frage vollständig abdeckt und ob ein Tool, das das Modell noch nicht genutzt hat, eine Lücke schließen könnte. Das Ergebnis beruht nicht auf Selbstauskunft. Geht das Modell zurück und ruft ein Tool auf, zählt das als Arbeit. Hakt es nur seine To-do-Liste ab, zählt das nicht, denn als wir es gemessen haben, taten einige Modelle genau das: Sie markierten jeden Punkt als erledigt und hörten auf.

In unserem Nachrichtenüberblick schickte die Prüfung den Agenten zurück, um zwei weitere Seiten zu lesen. Eine war blockiert. Die andere stieß an das Seitenbudget. Die Antwort, die er danach schrieb, sagte das auch.

Dann gibt es den Fehlerfall, über den niemand gern spricht. Ohne eine Möglichkeit, ein Scheitern zu melden, kann ein Lauf nur mit einer Antwort enden. Ein Lauf, der nichts gefunden hat, würde also als succeeded enden, mit einer Entschuldigung, und sein Besitzer bekäme gesagt, dass es geklappt hat. Wir haben das an einem echten Agenten gemessen, dem alle Tools zur Verfügung standen: Die meisten Läufe, bei denen jede Suche scheiterte, schrieben trotzdem eine Entschuldigung in der Form eines Nachrichtenüberblicks.

Mangrove gibt dem Modell einen Ausweg. Es kann einen Lauf als nicht erledigt beenden, mit einer Begründung für die Person, für die er bestimmt ist. Und für Modelle, die diesen Ausweg nicht nehmen, gibt es eine Absicherung: Hat ein Lauf Tools aufgerufen und ist jeder dieser Aufrufe gescheitert, endet er als task_not_done, so überzeugt die Antwort auch klingt.

Ein ehrliches Ende gehört zur Arbeit.

Limits, die nicht vom guten Benehmen abhängen

Transkript (übersetzt)

Die Limits eines Agenten sollten nicht von seinem guten Benehmen abhängen. Deshalb hält Mangrove sie in der Runtime, nicht im Prompt. Ein Tool, das dieser Lauf nicht nutzen darf, wird dem Modell nie gezeigt. Ruft das Modell es trotzdem auf, wird der Aufruf abgelehnt. Aufrufe, Tokens und Zeit werden über den gesamten Lauf gezählt. Und Limits werden nur enger. Eine Anfrage kann weniger verlangen, als die Plattform erlaubt, aber nie mehr. Wenn das Token-Budget aufgebraucht ist, wird die Arbeit nicht weggeworfen. Der Lauf schreibt eine abschließende Antwort und nennt, was er nicht erreicht hat. Du hast für die Arbeit bezahlt, also behältst du, was er gefunden hat.

Du kannst ein Modell höflich bitten, Limits einzuhalten. Für alles, was unbeaufsichtigt läuft, ist das eine schlechte Methode, deshalb hält Mangrove seine Limits in der Runtime.

Ein Tool, das ein Lauf nicht nutzen darf, wird dem Modell nie gezeigt. Ruft das Modell es trotzdem auf, wird der Aufruf so abgelehnt wie bei einem unbekannten Tool. Modellaufrufe, Tokens und Zeit werden über den gesamten Lauf gezählt, einschließlich der abschließenden Prüfung, sodass nichts kostenlos in einer Schleife laufen kann. Standardmäßig bekommt ein Lauf 100 Modellaufrufe, 1.000.000 Tokens und 900 Sekunden, und die eigenen Limits einer Aufgabe können darunter liegen: Unser Nachrichtenüberblick lief mit 60 Aufrufen, 600.000 Tokens und 600 Sekunden.

Limits werden nur enger. Eine Anfrage kann weniger verlangen, als die Plattform erlaubt, aber nie mehr.

Manche Details haben wir erst durch echte Vorfälle gelernt. Eine einzige gescrapte Seite mit 1,3 Millionen Zeichen machte aus einem Gespräch mit 5.000 Tokens eine Anfrage mit 347.000 Tokens. Deshalb ist jedes Tool-Ergebnis auf 50.000 Zeichen begrenzt, und das Modell erfährt, wenn eines gekürzt wurde. Auch das Token-Budget ist keine feste Schwelle: Es hält Platz für einen Schritt frei, der so groß ist wie der größte, den der Lauf schon bezahlt hat, weil der Prompt mit jedem Ergebnis wächst.

Was am Limit passiert, ist für alle, die Agenten bauen, vielleicht der nützlichste Teil. Wenn das Token-Budget aufgebraucht ist, stirbt der Lauf nicht. Ihn zu verwerfen, wäre das teuerste Ergebnis überhaupt, denn du würdest jeden Aufruf bezahlen und eine Fehlermeldung bekommen. Stattdessen hört er auf zu arbeiten und macht einen abschließenden Aufruf ohne verfügbare Tools, sodass er nichts Neues beginnen kann. Dabei schreibt er auf, was er hat, und nennt, was er nicht erreicht hat.

Du hast für die Arbeit bezahlt, also behältst du, was er gefunden hat.

Ein Lauf handelt für dich und nur unter deiner Identität

Transkript (übersetzt)

Ein Lauf handelt für dich. Deshalb darf er immer nur unter deiner Identität handeln. Bevor er startet, nimmt ein Lauf die Identität seines Besitzers an und prüft, ob es die richtige ist. Scheitert diese Prüfung, startet der Lauf nicht. Gespeicherte Werte sind an diesen Besitzer gebunden. E-Mails und Dateien werden über Referenzen erreicht, die nur für diesen einen Lauf erstellt werden. Tools von deinen verbundenen Servern sind abgeschirmt, und dem Lauf wird gesagt, dass ihre Rückgaben Daten sind und keine Anweisungen. Python läuft in einer eigenen isolierten Sandbox. Outlook kann einen Entwurf speichern, ohne jede Möglichkeit, ihn zu senden. Und jede Verbindung wartet auf deinen eigenen Schalter. Er kann viel. Aber nur unter deiner Identität.

Ein Lauf, der deine E-Mails lesen kann, braucht eine klare Antwort auf die Frage, wessen E-Mails er liest.

Bevor ein Lauf startet, nimmt er die Identität seines Besitzers an und prüft, ob die erhaltene Identität zum Besitzer des Laufs passt. Passt sie nicht, startet der Lauf nicht. Es gibt kein Ersatzkonto. Der Speicher für gespeicherte Werte hat kein Feld dafür, wessen Daten gemeint sind, ein Tool-Aufruf kann also die Daten einer anderen Person gar nicht adressieren. E-Mails und Dateien werden über Referenzen erreicht, die nur für diesen einen Lauf erstellt werden, sodass das Modell mit einer Referenz arbeitet, nicht mit einem Postfach.

Server, die du über MCP verbindest, werden auf Abstand gehalten. Ihre Tool-Beschreibungen sind abgeschirmt, und dem Lauf wird gesagt, dass das, was sie zurückgeben, Daten sind und keine Anweisungen. Der Worker, der deinen Agenten ausführt, sieht ihre Adressen nie. Jede Verbindung und jede Schreibberechtigung, etwa zum Speichern von Entwürfen oder Dateien, wartet auf deinen eigenen Schalter.

Wir behaupten nicht, dass sich ein Lauf dadurch unmöglich in die Irre führen lässt. Ein Agent liest Dinge, die Fremde geschrieben haben, und dieses Risiko verschwindet nicht, nur weil du einen sorgfältigen Prompt geschrieben hast. Deshalb begrenzen wir auch, was ein fehlgeleiteter Lauf anrichten kann: Er kann deine E-Mails nicht senden, sein Code läuft isoliert, und er kann nur nutzen, was du verbunden hast.

Ein Lauf, der auf saubereren Strom warten kann

Transkript (übersetzt)

Manche Arbeit muss nicht sofort passieren. Mit einem zusätzlichen Feld darf ein Lauf bis zu 24 Stunden später starten. Mangrove liest die Netzprognose und findet den saubersten Start in diesem Zeitfenster. Würde Warten weniger als 5 % sparen, startet der Lauf sofort. Lässt sich keine Prognose lesen, startet er ebenfalls sofort. Eine CO₂-Prüfung verzögert einen Lauf nie und lässt ihn nie scheitern. So oder so sagt dir die API-Antwort, was entschieden wurde und um wie viel. Dieselbe Arbeit, zu einer saubereren Stunde.

Diese Fähigkeit sagt am meisten darüber, wer Mangrove gebaut hat.

Manche Arbeit muss nicht sofort passieren. Ein Wochenbericht kann ein paar Stunden warten. Mit einem zusätzlichen Feld darf ein Lauf bis zu 24 Stunden später starten:

{
  "question": "Summarise the EU grid carbon intensity news from this week",
  "greenShiftWindowHours": 8
}

Mangrove liest die Prognose der CO₂-Intensität für das Netz, auf dem seine Modelle laufen, und hält den Lauf für den saubersten Start in diesem Zeitfenster zurück. Dabei achtet es darauf, ob sich das lohnt. Würde Warten weniger als 5 % sparen, startet der Lauf sofort, denn darunter kostet eine Verzögerung dich mehr, als sie dem Netz bringt. Lässt sich keine Prognose lesen, startet er ebenfalls sofort. Eine CO₂-Prüfung verzögert einen Lauf nie und lässt ihn nie scheitern.

Die API-Antwort sagt dir, was entschieden wurde: held, run_now oder unavailable, den geplanten Start, die CO₂-Intensität in gCO₂e/kWh mit und ohne Warten und die Einsparung. In einem Netz, das bereits sauber und stabil ist, werden die meisten Läufe einfach pünktlich starten. Dann greift die Regel genau wie vorgesehen, und du kannst es in der API-Antwort nachlesen.

Agenten, die bleiben

Transkript (übersetzt)

Ein Lauf ist eine Aufgabe. Ein Agent ist ein Job, den du behältst. Beschreibe die Arbeit im Chat. GreenPT fragt die wenigen Dinge, die es braucht, und entwirft dann den Agenten: seine Anweisungen, seinen Zeitplan und eine Aufgabe, um ihn zu testen. Behältst du ihn, bekommt er eine eigene Seite, mit jedem Lauf und jedem Ergebnis. Nach Zeitplan ist niemand da, um zu antworten. Deshalb bekommt der Lauf keine Möglichkeit zu fragen. Per API ist es ein Aufruf zum Erstellen und eine Adresse zum Ausführen. Arbeit, die du einmal beschreibst und die immer wieder erledigt wird.

Ein Lauf ist eine Aufgabe. Ein Agent ist ein Job, den du behältst.

Beschreibe die Arbeit im Chat von GreenPT, und er fragt die wenigen Dinge, die er wissen muss: wann die Arbeit laufen soll, wie das Ergebnis zu dir kommen soll und ob der Job auf saubereren Strom warten darf. Dann entwirft er den Agenten, mit seinen Anweisungen, seinem Zeitplan und einer Aufgabe, um ihn zu testen. Nichts wird gespeichert, bevor du zustimmst. Behältst du ihn, bekommt er eine eigene Seite, mit jedem Lauf und jedem Ergebnis.

Ein geplanter Lauf ist anders als einer, den du beobachtest, denn niemand ist da, um zu antworten. Deshalb bekommt ein geplanter Lauf keine Möglichkeit zu fragen. Er arbeitet den Auftrag mit dem ab, was er hat, und meldet, was er nicht tun konnte.

Entwickler bekommen dasselbe in zwei Aufrufen: einem, um einen Agenten zu erstellen, und einem, um ihn unter seiner eigenen Adresse auszuführen.

POST /v1/agent-profiles
POST /v1/agent-profiles/weekly-report/runs

Jeder Schritt ist dokumentiert

Transkript (übersetzt)

Du solltest einem Agenten nicht einfach glauben müssen. Jeder Lauf streamt, was er tut: jeden Schritt, jeden Tool-Aufruf und jedes Ergebnis. Außerdem hält er fest, was er über sich selbst entschieden hat: wie die Aufgabe eingestuft wurde, welchen Plan er genommen hat und welches Budget er bekam. Vierzehn Regeln gelten für jeden Verlauf, egal was das Modell wählt, und Tests sorgen dafür. Seine Modellaufrufe melden ihre Energie und ihre Emissionen, sodass ein Lauf am Ende eine Zahl ergibt, in Wattstunden. Jeder Schritt, dokumentiert.

Du solltest einem Agenten nicht einfach glauben müssen.

Jeder Lauf streamt, was er tut: jeden Schritt, jeden Tool-Aufruf und jedes Ergebnis. Außerdem hält er als decision-Ereignisse fest, was er über sich selbst entschieden hat: wie die Aufgabe eingestuft wurde und wie sicher die Einstufung war, welchen Plan er genommen hat, welches Budget er bekam, warum er gestoppt hat. Ist ein Klassifikator in einen Timeout gelaufen, steht das im Verlauf, denn “nie eingestuft” und “als allgemein eingestuft” sind verschiedene Tatsachen.

Vierzehn Regeln gelten für jeden Verlauf, egal was das Modell wählt: Ein Tool-Aufruf wird immer beantwortet, Schritte überlappen sich nie, ein Plan kommt immer vor der Ausführung, ein Lauf endet nie zweimal. Tests halten die Runtime daran, sodass ein Rückschritt als verletzte Regel sichtbar wird und sich nicht in der normalen Streuung eines Modells verstecken kann.

Und am Ende ergibt ein Lauf eine Zahl. Die Modellaufrufe eines Laufs melden ihre Energie und ihre Emissionen über denselben Impact-Bericht wie jede Antwort der GreenPT-API, und der Lauf behält die Summe. Unser Nachrichtenüberblick verbrauchte 1,96 Wh und 0,14 g CO₂e. Über 21 abgeschlossene Läufe in einem Benchmark auf unserem Test-Stack lag die Spanne bei 0,49 Wh bis 13,61 Wh, mit einem Median von 4,7 Wh. Diese Summen decken die Modellaufrufe in der eigenen Schleife des Laufs ab. Die Einstufung durch Metis und Tools ohne Modell, etwa die Suche, sind nicht enthalten.

Warum das aus unserer Sicht anders ist

Die meisten Agenten-Frameworks geben dir Einzelteile. Mangrove ist ein fertiger Lauf, mit klaren Ansichten:

• Es urteilt, bevor es Ressourcen ausgibt. Ein Entscheidungsmodell schätzt jede Aufgabe in Millisekunden ein, ohne ein Wort zu schreiben.
• Es hat ein Gefühl für genug. Budgets ergeben sich aus der Aufgabe, und sie werden außerhalb des Modells durchgesetzt.
• Es kann nicht stillschweigend Erfolg melden. Ein gescheiterter Lauf sagt, dass er gescheitert ist, mit Begründung.
• Es bewahrt, was du bezahlt hast. Ein aufgebrauchtes Budget endet in einer Antwort, die ihre Lücken nennt.
• Es weiß, was es verbraucht hat. Energie und Emissionen kommen mit dem Lauf, in Wh und Gramm.
• Es kann warten. Ein Lauf kann auf eine sauberere Stunde warten und dir sagen, was das gespart hat.

Was Mangrove nicht tut

Ein Lauf ist ein einziger Austausch. Er beginnt bei null, lässt sich nicht fortsetzen, und eine Nachfrage ist ein neuer Lauf. Zitiere also den Teil der letzten Antwort, auf dem du aufbauen willst.

Die Kosten eines Laufs stehen beim Start nicht fest, weil Mangrove entscheidet, wie viele Schritte eine Aufgabe braucht. Zwei Läufe mit derselben Frage können unterschiedlich viel kosten.

Eine Aufgabe, die mehr als zwanzig Runden braucht, kommt dünner zurück, statt zu scheitern. Es hilft, sie in engere Fragen aufzuteilen.

Wo Mangrove heute steht

Mangrove ist in der privaten Beta, in den Tarifen Pro, Pro Max, Teams und Enterprise, und Läufe werden aus deinem API-Guthaben bezahlt. Während der Beta ist nicht jede Fähigkeit aus diesem Artikel für jedes Konto eingeschaltet. Der Lauf vom Anfang dieses Artikels stammt von unserem Test-Stack, auf dem alle eingeschaltet waren.

Wenn du es ausprobieren möchtest: Die Mangrove-Dokumentation enthält einen Schnellstart und ausgearbeitete Beispiele, und Zugang kannst du auf unserem Discord anfragen.

Sag uns, was du Mangrove als Erstes anvertrauen würdest.