Asana-Browser-Agent-Tests senken Modellkosten mit GPT-6.1 Sol um das 76-Fache

Asana zufolge wurde sein Browser-Agent 76-mal günstiger und fünfmal schneller, nachdem Entwickler verändert hatten, wie er den Browserverlauf speicherte und zwischenspeicherte. Bei den Tests des Asana-Browser-Agents kam GPT-6 Astra in Codex zum Einsatz, um das System zu untersuchen, Experimente durchzuführen und Traces zu analysieren. GPT-6.1 Sol erzielte anschließend im optimierten Workflow die niedrigsten geschätzten Modellkosten.

Das Schlagzeilenergebnis wirkt wie ein Sieg für ein Modell. Die wichtigere Erkenntnis betrifft die Agentenarchitektur. Asana veränderte, wann der Agent Screenshots entfernte, erweiterte dessen Historienlimit und cachete die wachsende Aufzeichnung vorheriger Schritte. Diese Änderungen reduzierten wiederholte Verarbeitung, ohne Informationen zu verlieren, die der Agent zum Abschließen seiner Aufgabe benötigte.

Diese Unterscheidung ist für jedes Unternehmen relevant, das Browser-Agenten evaluiert. Ein Team kann zu einem günstigeren Modell wechseln und durch schlechtes Context-Management trotzdem Tokens verschwenden. Es kann auch ein leistungsfähigeres Modell wählen, die richtige Historie bewahren und die gesamten Betriebskosten senken. Asanas Experiment stellt diese beiden Strategien direkt gegenüber.

Die Studie zum Asana-Browser-Agent veränderte mehr als nur das Modell

Asanas größte Fortschritte resultierten aus einer Neugestaltung des Workflows rund um das Modell und nicht bloß aus dem Austausch eines Modells gegen ein anderes.

Das Unternehmen veröffentlichte die Ergebnisse am 8. Oktober 2026, gefolgt von einer OpenAI-Fallstudie am 9. Oktober. Die Arbeit konzentrierte sich auf einen Browser-Agenten in StackAI, der No-Code-Automatisierungsplattform, die Asana Anfang 2026 übernommen hatte.

Mit StackAI können Kunden Agenten erstellen, die Websites navigieren, Informationen sammeln und Formulare in Geschäftsanwendungen ausfüllen. Diese Workflows ähneln menschlichem Browsing, doch der zugrunde liegende Agent sendet wiederholt Anweisungen, Tools, Seitentext, Screenshots und frühere Aktionen an ein Modell.

Dieser wiederholte Kontext erzeugt ein kostspieliges Muster. Jeder neue Schritt enthält mehr Historie als der vorherige. Wenn sich frühere Inhalte ständig ändern, kann ein Anbieter deren gecachte Repräsentation nicht zuverlässig wiederverwenden.

Asanas ursprünglicher Agent cachete feste Anweisungen und Tool-Definitionen. Den wachsenden Browserverlauf cachete er jedoch nicht effektiv. Der Agent entfernte außerdem alte Screenshots und kürzte Text häufig, wodurch frühere Teile der Anfrage verändert wurden.

Diese Änderungen zerstörten den stabilen Präfix – also den unveränderten Anfang, den aufeinanderfolgende Modellanfragen gemeinsam haben. Sobald sich dieser Präfix änderte, musste ein großer Teil des Browserverlaufs erneut verarbeitet werden.

Frank Hidalgo, Chief Technology Officer von StackAI bei Asana, wies GPT-6 Astra in Codex an, dieses Verhalten zu untersuchen. Das Modell kartierte die Codebasis, prüfte, wie Anfragen zusammengesetzt wurden, und identifizierte Variablen, deren Test sich lohnte.

Asana zufolge umfasste die daraus resultierende Studie 144 primäre Durchläufe über vier Frontier-Modelle hinweg. Getestet wurden sechs Caching- und Screenshot-Richtlinien, zwei Historienlimits sowie drei Durchläufe pro Bedingung. Später führte das Unternehmen einen kleineren Folgeversuch durch.

Jede Konfiguration erhielt dieselbe Aufgabe. Der Browser-Agent musste für jedes von 32 Büchern aus einem öffentlichen Demonstrationskatalog sechs Felder erfassen. Das bedeutete, 192 Fakten zu finden und zugleich genügend Kontext zu bewahren, um eine korrekte abschließende Antwort zu liefern.

Zu den Modellen gehörten GPT-6.1 Sol und drei anonymisierte Alternativen. Asana bezeichnete diese Systeme als Modelle A, B und C. Modell B betrieb die ursprüngliche Produktionskonfiguration, während Modell C ein neueres Modell desselben Anbieters repräsentierte.

Asana legte diese Anbieter nicht offen, was direkte Wettbewerbsvergleiche einschränkt. Das Unternehmen erklärte jedoch, dass der optimierte GPT-6.1-Sol-Workflow 76-mal weniger kostete als das ursprüngliche Setup mit Modell B. Zudem wurde er etwa fünfmal schneller abgeschlossen.

Das Unternehmen hat die Änderungen für die Browser-Navigation inzwischen in StackAI veröffentlicht. Damit wird aus der Übung ein Produktions-Update, auch wenn Asana noch keine breit angelegten Leistungsdaten auf Kundenebene veröffentlicht hat.

Warum Prompt Caching zum entscheidenden Mechanismus wurde

Die entscheidende Variable war, ob der Agent den Großteil seiner angesammelten Historie zwischen Aufrufen unverändert halten konnte.

Prompt Caching speichert den wiederverwendbaren Rechenzustand, der mit einem unveränderten Prompt-Präfix verbunden ist. Spätere Anfragen können diesen Zustand wiederverwenden, statt dasselbe Material von Beginn an erneut zu verarbeiten.

Der Cache speichert keine fertige Antwort zur erneuten Wiedergabe. Das Modell verarbeitet weiterhin neues Material und generiert eine neue Antwort. Es vermeidet lediglich, Arbeit für berechtigten Kontext zu wiederholen, der identisch bleibt.

OpenAIs Leitfaden zu Prompt Caching empfiehlt, stabile Anweisungen und Referenzmaterial vor veränderlichen Inhalten zu platzieren. Außerdem wird Anwendungen geraten, den Gesprächsverlauf anzuhängen, statt frühere Turns wiederholt umzuschreiben.

Asanas ursprüngliches Design verletzte dieses zweite Prinzip während Browser-Durchläufen. Bei fast jedem Schritt entfernte es einen früheren Screenshot und kürzte manchmal älteren Text. Die nächste Anfrage unterschied sich dadurch in der Mitte ihrer Historie.

Das Caching allein des festen System-Prompts konnte die größte Quelle wiederholter Eingaben nicht erfassen. Der Browser-Agent sammelte während der Aufgabe Seitentext, Screenshots, Beobachtungen und Tool-Ergebnisse an.

Asana testete eine andere Richtlinie namens Batch Pruning. Pruning bedeutet, älteren Kontext zu löschen, bevor die angesammelte Historie zu groß wird. Unter der ausgewählten Richtlinie behielt der Agent bis zu 20 Screenshots, bevor er die Auswahl auf den neuesten reduzierte.

Dieser Ansatz schuf längere Abschnitte einer ausschließlich angehängten Historie. Der Agent konnte neue Beobachtungen am Ende hinzufügen, ohne bei jedem Schritt frühere Inhalte zu verändern. Dadurch blieb ein größerer Teil jeder Anfrage für die Wiederverwendung geeignet.

Der optimierte Workflow erhöhte außerdem das Limit für die Texthistorie von 120.000 auf 480.000 Zeichen. Das gab dem Agenten mehr Raum, bereits gesammelte Fakten zu bewahren, statt sie zu verwerfen.

Das größere Limit hatte einen wichtigen Effekt auf die Abschlussrate. Mit der kleineren Historieneinstellung lieferte GPT-6.1 Sol nur in drei von 18 Durchläufen eine Antwort. Bei der größeren Einstellung antwortete es laut Asana in allen 18 Durchläufen.

Asana zufolge gab jeder dieser Durchläufe mit größerer Historie die korrekte Antwort zurück. Dieses Ergebnis stellt die Annahme infrage, dass aggressives Verkleinern von Kontext die Effizienz von Agenten immer verbessert.

Das Löschen von Kontext reduziert zwar die unmittelbare Größe einer Anfrage. Es kann einen Agenten jedoch dazu zwingen, Seiten erneut aufzurufen, Tool-Aufrufe zu wiederholen oder ohne zuvor gesammelte Belege fortzufahren. Außerdem kann es die Cache-Wiederverwendung unterbrechen, wenn die Löschung den Anfragepräfix verändert.

Die beste Richtlinie hängt daher von der Gesamtökonomie der Aufgabe ab. Teams müssen die Verarbeitung von Eingaben, wiederholte Navigation, Abschlussraten, Antwortqualität und die Wiederherstellung nach fehlgeschlagenen Durchläufen berücksichtigen.

Asana berichtete, dass im optimierten Setup 89 Prozent der Eingaben von GPT-6.1 Sol aus dem Cache stammten. Dieses Verhältnis erklärt, warum ein leistungsfähigeres Modell für die vollständige Aufgabe zur günstigsten getesteten Option werden konnte.

Das ist der zentrale Mechanismus hinter dem Ergebnis des Asana-Browser-Agents. Das Unternehmen bat ein Modell nicht bloß darum, weniger Tokens zu verwenden. Es organisierte den Workflow so um, dass wiederholte Tokens günstiger verarbeitet werden konnten.

Mehr Kontext half dem Agenten, Aufgaben zuverlässig abzuschließen

Das Experiment legt nahe, dass die günstigste Anfrage nicht immer Teil des günstigsten vollständig abgeschlossenen Workflows ist.

Entwickler von Agenten behandeln Kontext häufig als Ressource, die minimiert werden muss. Diese Sichtweise ist nachvollziehbar, weil lange Prompts die Eingabeverarbeitung erhöhen und sich dem Kontextlimit eines Modells nähern können.

Browser-Agenten erschweren diese Rechnung. Ihre früheren Beobachtungen dienen als Arbeitsgedächtnis. Das Entfernen einer Adresse, eines Produktattributs, einer Warnung oder eines Navigationsergebnisses kann dazu führen, dass der Agent seine finale Antwort nicht mehr abschließen kann.

Das kleinere Historienlimit führte bei einigen Modellen zu besonders schwachen Ergebnissen. Asana berichtet, dass Modell C unter dieser Bedingung über 18 Durchläufe hinweg keine Antwort lieferte. GPT-6.1 Sol lieferte nur drei Antworten.

Diese Fehlschläge waren kein Beleg dafür, dass den Modellen allgemeine Browsing-Fähigkeiten fehlten. Das größere Historienlimit veränderte das Ergebnis. Beide Modelle beantworteten jeden Durchlauf, nachdem sie genug Platz erhalten hatten, um die notwendige Aufzeichnung zu behalten.

Das Ergebnis stützt ein umfassenderes Engineering-Prinzip. Die Context-Richtlinie muss zum Modell und zur Aufgabe passen. Ein universelles Token-Limit wird über unterschiedliche Systeme hinweg kein gleichwertiges Verhalten erzeugen.

Modelle können Kontext unterschiedlich schnell verbrauchen, weil sie unterschiedliche Beschreibungen, Tool-Aufrufe und Reasoning-Traces erzeugen. Ein Agent könnte nach wenigen Aktionen einen Pruning-Schwellenwert erreichen. Ein anderer könnte deutlich länger weitermachen.

Asana stellte fest, dass neuere oder leistungsfähigere Modelle das kleinere Limit nicht automatisch effizienter nutzten. Modell C begann im getesteten Workflow deutlich früher damit, die Historie zu kürzen als Modell A.

Das Experiment ergab außerdem, dass Caching allein nicht ausreichte. Beim größeren Historienlimit kostete Caching ohne Batch Pruning bei drei von vier Modellen mehr als gar kein Caching.

Dieses Ergebnis wirkt widersprüchlich, bis man die Anfragestruktur berücksichtigt. Ein Cache bietet nur begrenzten Nutzen, wenn die Anwendung das Material, das sie wiederverwenden will, ständig umschreibt. Das System zahlt für die Verarbeitung einer sich ändernden Historie, ohne genügend spätere Cache-Treffer zu erhalten.

Asanas ausgewählte Richtlinie brachte drei Entscheidungen in Einklang. Sie cachete die Historie, bewahrte über längere Zeiträume eine ausschließlich angehängte Sequenz und stellte ein größeres Limit bereit, bevor Kürzungen nötig wurden.

Ein Folgeversuch warf eine weitere Frage auf. Asana testete Konfigurationen, die jeden Screenshot behielten, anstatt sie zu kürzen. Einige davon lieferten bei dieser speziellen Aufgabe niedrigere Kosten pro Aufruf als die ausgewählte Richtlinie.

Das Unternehmen wertete dies nicht als Beweis dafür, dass Pruning verschwinden sollte. Längere Workflows können Kontextlimits überschreiten, während einige Anbieter mehr für Cache-Operationen berechnen. Ein Agent, der in unnötiges Browsing abdriftet, benötigt zudem klare Grenzen.

Asana empfiehlt Obergrenzen für Schritte, Tokens und die Gesamtkosten eines Durchlaufs. Diese Limits verhindern, dass ein fehlerhafter oder verwirrter Agent seine Historie unbegrenzt ausweitet. Compaction, bei der ältere Historie durch eine kürzere Zusammenfassung ersetzt wird, bietet eine weitere Option.

Compaction bringt einen eigenen Zielkonflikt mit sich. Sie reduziert die Kontextgröße, verändert jedoch den früheren Prompt und kann damit die Cache-Wiederverwendung stören. Eine Zusammenfassung kann außerdem ein Detail auslassen, das später wichtig wird.

Aus diesem Grund benötigen Teams Aufzeichnungen außerhalb des aktiven Prompts. Asana protokollierte Anfragen, Traces und Ergebnisse in Command, seiner Plattform für Softwarebereitstellung. Entwickler und zusätzliche Agenten konnten das vollständige Experiment anschließend prüfen.

Eine dauerhafte Aufzeichnung unterstützt zudem eine durchsuchbare Wissensdatenbank. Der aktive Agent erhält nur den Kontext, den er für seinen aktuellen Schritt benötigt, während Prüfer Zugriff auf die vollständige Beweiskette behalten.

Diese Trennung hilft Teams, zwischen Modellgedächtnis und organisatorischem Gedächtnis zu unterscheiden. Der Arbeitskontext eines Agenten sollte begrenzt bleiben. Die Aufzeichnung des Experiments sollte detailliert genug bleiben, um Entscheidungen zu reproduzieren und Fehler zu untersuchen.

GPT-6 Astra machte Evaluierungsarbeit zu einer Agentenaufgabe

Asana nutzte ein Modell, um das System zu verbessern, und ein anderes für den optimierten Produktions-Workflow.

GPT-6 Astra arbeitete in Codex als Forschungs- und Engineering-Agent. GPT-6.1 Sol war eines der Runtime-Modelle des Browser-Agents. Diese als getrennte Rollen zu behandeln, verhindert eine irreführende Interpretation der Ergebnisse.

Hidalgo legte die Forschungsrichtung fest und wählte die vorgeschlagenen Änderungen aus, die getestet werden sollten. GPT-6 Astra untersuchte den Code, instrumentierte Anfragen, führte erste Tests durch und identifizierte einflussreiche Variablen.

Der vorhandene Code war nicht für kontrollierte Vergleiche ausgelegt. Asana zufolge gestaltete der Codex-Agent das System so um, dass ein gemeinsames Frontend und Backend mehrere experimentelle Workflows parallel unterstützen konnten.

GPT-6 Astra startete anschließend die Studie, analysierte Nutzungsdaten und verglich die Ergebnisse. Getrennte Modellsitzungen überprüften Teile der Arbeit, während Menschen die Schlussfolgerungen bewerteten und Änderungen für die Produktion freigaben.

Asana schätzt, dass das Projekt ein oder zwei Monate manueller Arbeit erfordert hätte. Mit dem Codex-Workflow dauerte die Untersuchung etwa eine Woche.

Diese Aussage stammt vom Unternehmen selbst und nicht aus einer unabhängigen Bewertung. Sie beschreibt zudem ein einzelnes Engineering-Projekt unter Leitung einer technischen Führungskraft, die mit dem System vertraut ist. Andere Teams sollten nicht von derselben Verkürzung des Zeitplans ausgehen.

Dennoch veranschaulicht der Workflow eine bedeutende Veränderung beim Einsatz von Coding-Agenten. Der Agent implementierte nicht nur ein Feature anhand einer abgeschlossenen Spezifikation. Er half auch dabei, eine empirische Untersuchung zu entwerfen und durchzuführen.

Die Untersuchung erzeugte Traces, Versuchsergebnisse, Tickets und Pull Requests. Diese Artefakte durchliefen Command, bevor die Änderungen in die StackAI-Produktion gelangten.

Dieser Prozess ist wichtiger als die Behauptung, ein KI-Agent habe den Großteil der mechanischen Arbeit erledigt. Ohne stabile Aufzeichnungen können Prüfer nicht zuverlässig feststellen, welche Konfiguration lief, warum sie scheiterte oder ob eine berichtete Verbesserung Änderungen am Code überstanden hat.

Die Asana-Studie besagt, dass Menschen Ziel und Bewertungsstandards festlegten. Sie überprüften auch die Ergebnisse. Der Coding-Agent vergrößerte den Umfang der Experimente, die das Team zwischen diesen Entscheidungen durchführen konnte.

Hidalgo beschrieb eine Routine, bei der er vor dem Schlafengehen ein Ziel festlegte und die Ergebnisse am folgenden Morgen prüfte. Dieses asynchrone Muster macht die Laufzeit von Agenten zu einer Engineering-Ressource.

Es verschiebt jedoch auch den Engpass. Wenn Experimente leicht zu erzeugen sind, müssen Menschen mehr Zeit darauf verwenden, valide Fragen auszuwählen, Messungen zu überprüfen und irreführende Schlussfolgerungen zu verwerfen.

Das Risiko besteht in automatisiertem Experimentierrauschen. Ein Agent kann viele Durchläufe erzeugen, ohne belastbare Evidenz zu liefern. Wiederholte Tests bleiben anfällig für Benchmark-Design, verdeckte Aufgabenvariationen und Bewertungsfehler.

Asana verringerte einen Teil dieses Risikos durch die Verwendung einer festen Aufgabe und einer unabhängig vorbereiteten Referenzantwort. Zudem zeichnete das Unternehmen die eigenen Nutzungszähler des Anbieters auf, statt den Tokenverbrauch anhand der Textlänge zu schätzen.

Das Unternehmen führte für die meisten Konfigurationen nur drei Wiederholungen durch. Asana erklärt ausdrücklich, dass die Studie grobe Muster offenlegt, nicht aber verlässliche Unterschiede von wenigen Prozentpunkten.

Diese Einschränkung ist wichtig. Die Vergleiche von 76x und 5x sind groß genug, um Aufmerksamkeit zu rechtfertigen, aber sie kombinieren Änderungen an Architektur und Modell. Sie isolieren keinen universellen Vorteil für GPT-6.1 Sol.

Asanas interne Ergebnisse zeigen, dass sich auch Model B nach Erhalt des optimierten Workflows deutlich verbesserte. Die Architektur machte bereits einen großen Teil des Gewinns aus, bevor GPT-6.1 Sol die Kosten weiter senkte.

Was die 76x-Behauptung nicht belegt

Die veröffentlichten Ergebnisse sind überzeugende Engineering-Evidenz, aber kein neutraler Benchmark für den Markt der Browser-Agenten.

Die Studie verwendete eine strukturierte Aufgabe in einem öffentlichen Buchkatalog. Jeder Durchlauf folgte demselben Ziel und sammelte denselben Satz an Feldern. Reales Browsing in Unternehmen umfasst oft Authentifizierung, wechselnde Layouts, mehrdeutige Anweisungen und die Wiederherstellung nach unerwarteten Dialogen.

Ein Workflow, der bei wiederholter Extraktion hervorragend abschneidet, könnte sich bei Beschaffung, Support, Compliance oder internen Abläufen anders verhalten. Solche Aufgaben können Urteilsvermögen über mehrere Systeme hinweg erfordern, statt Daten wiederholt von ähnlichen Seiten zu sammeln.

Der Asana-Test des Browser-Agenten verglich GPT-6.1 Sol zudem mit drei anonymisierten Modellen. Leser können die anbieterspezifischen Einstellungen nicht prüfen oder bestimmen, wie jede Alternative nach unabhängiger Optimierung abschneiden würde.

Asana zufolge hatten Models B, C und GPT-6.1 Sol während der Studie vergleichbare Standardpreise. Model A wurde als günstigere Alternative positioniert. Der öffentliche Artikel nennt ihre Namen nicht.

Diese Anonymität verhindert, dass das Ergebnis zu einer klaren Modellrangliste wird. Sie schützt die Studie auch davor, in Anbieter-Vergleiche abzudriften, die nicht durch genügend Tests gestützt sind.

Die größte Schlagzeile vergleicht den optimierten GPT-6.1-Sol-Workflow mit der ursprünglichen Produktionskonfiguration auf Model B. Zwei Variablen änderten sich zugleich: das Modell und die Agentenarchitektur.

Ein engerer Vergleich ergab eine vierfache Kostensenkung, wenn die neue Richtlinie innerhalb von GPT-6.1 Sol angewendet wurde. Der verbleibende Unterschied entstand durch den Vergleich dieses optimierten Systems mit der älteren Produktionsbasis.

Das schwächt das Ergebnis nicht. Es verändert die Schlussfolgerung. Die Studie spricht dafür, leistungsfähige Modelle mit kontextbewusster Architektur zu kombinieren, statt einen Modellwechsel als vollständige Lösung zu betrachten.

Die fünffache Verbesserung der Laufzeit ist mit ähnlichen Einschränkungen verbunden. Einige ursprüngliche Model-B-Durchläufe erreichten ein Schrittlimit, bevor sie abgeschlossen waren. Ihre gemessene Dauer stellt daher eine Untergrenze für die vollständige Aufgabe dar.

Auch die Abschlussqualität muss fortlaufend beobachtet werden. Asana berichtet, dass alle Durchläufe unter den besten Bedingungen die erforderlichen Fakten fanden und korrekte Antworten lieferten. Das öffentliche Material enthält keine Kunden-Workloads oder langfristigen Fehlerraten.

Eine unabhängige Replikation bleibt begrenzt, weil die vollständige Studie von Asanas Implementierung und Traces abhängt. Das Unternehmen teilte seine Methoden und eine ausführlichere Studie, doch externe Teams benötigen weiterhin eigene Aufgabensuiten.

Die Übernahme von StackAI durch das Unternehmen schafft ebenfalls ein kommerzielles Interesse am Ergebnis. Asana schloss die Übernahme von StackAI im Mai 2026 ab, um systemübergreifende Agenten-Workflows auszubauen.

OpenAI hat ein ähnliches Interesse daran, zu zeigen, wie GPT-6 Astra und GPT-6.1 Sol Unternehmensagenten unterstützen. Beide Primärquellen liefern wertvolle technische Details, doch keine von beiden stellt ein unabhängiges Branchenaudit dar.

Auch betriebliche Bedingungen können das Ergebnis verändern. Die Verfügbarkeit des Caches hat eine begrenzte Lebensdauer. Gleichzeitige Kunden können unterschiedliche Verläufe haben, und personalisierter Kontext kann die Menge gemeinsam nutzbaren Materials verringern.

Datenschutzanforderungen können einschränken, welche Inhalte in den Modellkontext gelangen. Sicherheitsteams benötigen zudem Kontrollen für Screenshots, Zugangsdaten, Kundendaten und sensible Informationen, die beim Browsing erfasst werden.

Caching beseitigt diese Verpflichtungen nicht. Es verändert Rechen- und Abrechnungsverhalten, nicht jedoch den Bedarf an Daten-Governance. Teams benötigen weiterhin Aufbewahrungsrichtlinien, Zugriffskontrollen, Audit-Trails und Fehlerbehandlung.

Die richtige Schlussfolgerung ist daher bedingt. Asana fand für einen spezifischen Browser-Agenten eine wertvolle Optimierung und überführte sie in die Produktion. Andere Teams sollten den Mechanismus als testbare Hypothese behandeln.

Der nächste Test ist die Leistung über reale Kunden-Workflows hinweg

Die nächsten drei Signale werden zeigen, ob Asanas Ergebnis zu einem wiederverwendbaren Betriebsmodell wird oder eine starke interne Fallstudie bleibt.

Das erste Signal ist eine breitere Evaluierungsabdeckung. Asana erklärt, es entwickle Tools, mit denen Kunden und interne Teams Kosten, Laufzeit und Antwortqualität bei der Konfiguration von Agenten vergleichen können.

Diese Bewertungen müssen Aufgaben über die strukturierte Katalogextraktion hinaus umfassen. Nützliche Testsuiten sollten wechselnde Websites, authentifizierte Anwendungen, Teilausfälle, lange Navigationspfade und Anweisungen mit mehrdeutigen Abbruchpunkten enthalten.

Wenn dieselbe Verlaufsrichtlinie diese Workflows verbessert, wird der Fall für architekturgetriebene Optimierung stärker. Schrumpfen die Gewinne, könnte Asanas gewählte Konfiguration eng an repetitive Extraktion gebunden sein.

Das zweite Signal sind Belege aus der Produktionsnutzung. Asana hat die Änderungen an der Browser-Navigation bereits für StackAI ausgeliefert, aber noch keine aggregierten Kundenergebnisse veröffentlicht.

Die Abschlussrate sollte wichtiger sein als die Kosten pro Aufruf. Eine günstigere Anfrage bietet wenig Wert, wenn Kunden Jobs erneut ausführen oder unvollständige Ausgaben manuell reparieren müssen.

Teams sollten außerdem den Anteil der aus dem Cache bedienten Eingaben, die mediane Aufgabendauer, Ausfälle durch Schrittlimits und Raten menschlicher Eingriffe beobachten. Diese Kennzahlen zeigen, ob das optimierte Design variablem Produktionsverkehr standhält.

Das dritte Signal ist die Reaktion konkurrierender Modellanbieter und Agentenplattformen. Prompt-Caching ist zu einer Produktfunktion geworden, doch die Anwendungsarchitektur bestimmt, ob Entwickler davon profitieren können.

Anbieter können über längere Cache-Aufbewahrung, bessere Diagnostik, niedrigere Preise für Cache-Eingaben und klarere Nutzungsdaten konkurrieren. Agenten-Frameworks können Verlaufsrichtlinien verfügbar machen, ohne jeden Kunden zu zwingen, eigene Instrumentierung zu bauen.

OpenAI positioniert GPT-6.1 Sol als Modell für leistungsfähige agentische Arbeit zu niedrigeren Betriebskosten als GPT-6 Astra. Asanas Studie liefert dieser Positionierung ein konkretes Anwendungsbeispiel.

Der stärkste Wettbewerbsdruck trifft jedoch Teams für Agentensoftware. Kunden werden zunehmend erwarten, dass Plattformen die Gesamtkosten einer Aufgabe automatisch optimieren, statt nur eine Modellauswahl anzubieten.

Eine ausgereifte Plattform sollte Kontextgrenzen auf Grundlage beobachteten Verhaltens empfehlen. Sie sollte Änderungen erkennen, die den Cache unterbrechen, Richtlinien vergleichen und warnen, wenn das Kürzen den Agenten dazu bringt, frühere Seiten erneut zu besuchen.

Sie sollte außerdem genügend externe Evidenz aufbewahren, damit Menschen das Ergebnis prüfen können. Ein Browser-Agent benötigt einen begrenzten Arbeitsspeicher, während die Organisation eine vollständige Betriebsaufzeichnung braucht.

Asana plant, ähnliche Tests in sein Evaluierungssystem zu integrieren. Außerdem nutzt das Unternehmen GPT-6 Astra in Codex, um Produktfunktionen zu navigieren, unterschiedliche Eingaben auszuprobieren und Fehler für menschliche Prüfer zu melden.

Diese Erweiterung geht über einen einzelnen Browser-Agenten hinaus. Asana testet, ob Engineering-Agenten andere Agenten und Produktfunktionen kontinuierlich bewerten können.

Die Chance ist klar. Automatisierte Experimente können mehr Konfigurationen bewerten, als ein kleines Engineering-Team manuell testen könnte. Sie können außerdem den Weg von der Trace-Analyse zu überprüften Codeänderungen verkürzen.

Die Einschränkung ist ebenso klar. Menschliche Aufmerksamkeit wird zur knappen Ressource, wenn Agenten kontinuierlich Experimente, Erkenntnisse und Patches erzeugen können. Teams müssen entscheiden, welchen Ergebnissen sie vertrauen und welche sie der Produktion aussetzen.

Für Entwickler besteht die unmittelbare Maßnahme darin, vollständige Aufgaben statt isolierter Aufrufe zu messen. Erfassen Sie unter realistischen Bedingungen Cache-Trefferquoten, Abschlussqualität, Laufzeit, Wiederholungen und menschliche Nacharbeit.

Für Unternehmenskäufer gilt: Fragen Sie Anbieter, wie ihre Agenten mit wachsenden Verläufen umgehen. Ein Modellname allein zeigt nicht, ob das umgebende System nützlichen Kontext bewahrt oder wiederholt dafür bezahlt, ihn zu verarbeiten.

Für Wissensarbeiter verspricht die Veränderung schnellere und leistungsfähigere Browser-Automatisierung. Ihr Wert hängt davon ab, ob Agenten notwendige Fakten behalten können, ohne sensible Daten offenzulegen oder durch unnötige Schritte abzudriften.

Das Ergebnis des Asana-Browser-Agenten spricht überzeugend dafür, dass Kontextdesign nun neben der Modellauswahl in jede Agentenbewertung gehört. Die nächste Frage ist, ob diese Erkenntnis über die unübersichtlichen Workflows hinweg Bestand hat, die Kunden tatsächlich automatisieren möchten.