**About**-Seite der Website **tokeneconomics.com**, die die **Tokenomics Foundation** vorstellt — ein Projekt der **Linux Foundation**, angekündigt am **3. Juni 2026**, betrieben in **enger Partnerschaft mit der FinOps Foundation**. **Erklärte Mission**: *"establish open industry standards, benchmarks, and best practices for the economics of AI infrastructure"* — sie verknüpft **Produktion, Konsum und Monetarisierung** von Tokens mit dem **Geschäftswert**. **Rahmendefinition von Tokenomics**: *"Tokenomics is not just about the cost of tokens, it's about the entire layer of AI that they drive from production, to consumption to monetization"* — das heißt **die gesamte ökonomische Schicht der KI**, von den Infrastrukturkosten über die Modellwahl bis zur Wertoptimierung. **Phasenthese**: Die frühe KI-Adoption priorisierte **Leistungsfähigkeit**; die aktuelle Phase verschiebt sich hin zu **Effizienz und Wert**, was systematisches Kostenmanagement und **Transparenz** erfordert. **5 Gründungsprinzipien**: (1) ***"Efficiency is a design choice. AI cost is shaped by architecture, not just usage"***; (2) ***"Bigger is not always better. The best AI system is not always the one using the most expensive model"*** (Right-Tool / Routing); (3) ***"Visibility comes before optimisation. Teams cannot manage what they cannot see"***; (4) ***"Value matters more than volume. More tokens, more calls, and more automation do not automatically mean better outcomes"***; (5) ***"Open knowledge benefits everyone"*** (gemeinsame Standards, gemeinschaftliches Lernen, Transparenz). **Governance**: ein **Governing Board** (Branchenausrichtung + Mitteleinsatz) und ein **Technical Committee** (offene Spezifikationen + Benchmarks). **Ergebnisse**: Erweiterung der **FOCUS specification** (FinOps), offene Spezifikationen, Benchmarks, gemeinsame Frameworks und Metriken. **Zielgruppe**: CAIO, CTO, CIO, CFO, Ingenieure, Produktteams, FinOps-Praktiker, Forscher, Start-ups, Unternehmen, öffentlicher Sektor. **Erklärtes Ziel**: Organisationen *"from experimental AI adoption to sustainable AI operations"* zu führen, indem die Disziplin der **variablen Technologieausgaben** auf die Token-Ära ausgeweitet wird. **Relevanz für diese Veille**: Institutionalisierung/Standardisierung von **agentischem FinOps** auf Ebene einer Branchenstiftung — steht in direktem Zusammenhang mit den Fiches [[finops-foundation-finops-for-ai-overview-2026-02-17]], [[finout-finops-ai-agents-four-step-allocation-framework-2026-04-27]], orq-ai-finops-ai-agents-cost-per-outcome-hosseini-2026-04-15, gupta-token-budget-wars-marginal-token-utility-2026-05-28 (Allocation Layer, Token-to-Outcome) sowie mit der Verschiebung **Token → Outcome** (Salesforce/Tallapragada, Sierra/Greenwald). Die 5 Prinzipien decken sich genau mit bereits erfassten Hebeln: Architektur > Nutzung, **Haiku/Sonnet/Opus-Routing**, Beobachtbarkeit vor Optimierung, Wert ≠ Volumen.
#Tokenomics Foundation#Tokenomics#Token-Ökonomie
**Tokenomics Foundation** (entité collective, projet de **The Linux Foundation**, en partenariat avec la **FinOps Foundation**). Page institutionnelle *About* — **aucun auteur individuel nommé**. Annonce datée du **3 juin 2026**.
Beitrag aus dem **Dropbox Tech Blog** (Bereich *culture*), veröffentlicht am **28. Mai 2026** von **Kazuaki Okumura** (Dropbox, Rolle im Artikel nicht näher spezifiziert), als Rückblick auf einen Vortrag auf der Konferenz **DX Annual 2026** (Developer Productivity). **Kernthese**: Engineering-Produktivität muss über die *Code-Generierung* hinausgehen. *« Accelerating code generation simply shifted some bottlenecks downstream »* — KI hat den Code-Durchsatz massiv erhöht, aber *« the faster code moves, the more pressure it puts on review queues, CI systems, validation workflows, release coordination, and production operations »*. Die eigentliche Herausforderung besteht nicht mehr darin, schneller Code zu schreiben, sondern den gesamten SDLC in die Lage zu versetzen, ein deutlich größeres Volumen **sicher aufzunehmen, zu validieren und auszuliefern**. **Vom Copilot zum Agenten**: Die erste Welle (Code-Erklärung, Snippets, Q&A) fungierte *« as copilots alongside the engineer »*; der Agent hingegen *« can take a scoped task, inspect the codebase, edit files, run tests, iterate on failures, and return an artifact for human review »* — wobei der Engineer weiterhin *« accountable for intent, architecture, quality, and release decisions »* bleibt (mehr Parallelarbeit, mehr Optionen, Auslagerung repetitiver Ausführung). **Nova** = Dropboxs **interne** Coding-Agent-Plattform: eine Aufgabe in natürlicher Sprache beschreiben, Ausführung in einer kontrollierten Umgebung mit Codebase-Kontext. Zentraler Datenpunkt: ***« Nova's value comes less from the model itself than the systems surrounding it »*** (Codebase-Kontext, interne Praktiken, sichere Ausführung, Workflow-Integration, menschliche Prüfung); Nova macht heute **rund 1 von 12 PRs bei Dropbox** aus (wachsende Adoption) und erstreckt sich über Features hinaus auf **Migrationen, Behebung flakiger Tests, Bug-Untersuchung, Dependency-Updates** (Arbeit mit hohem Aufwand/geringem Mehrwert). **Produktgeschwindigkeit messen, nicht Code-Output**: *PR-Durchsatz*, ein nützliches Signal, solange die Coding-Geschwindigkeit der limitierende Faktor war, *« was no longer sufficient »*. Ein **vierstufiges** Messmodell: ***Fuel*** (werden KI-Tools genutzt?) → ***Adoption*** (wie verändern sich die Workflows teamübergreifend) → ***Output*** (trägt KI zur Produktionsarbeit bei?) → ***Impact*** (*« improving product velocity and reducing the time it takes to move from idea to customer value »*). Erfasste Qualitätssignale: **Durchlaufzeit des Code-Reviews, Erfolgsquote von Tests im ersten Durchlauf, Fehlerquote, Nacharbeitsquote**. *« Quality and trust matter as much as speed »* — der Kern des Wandels: *« moving from local activity metrics toward broader system outcomes »*. **Auch die Workflows müssen sich weiterentwickeln**: Dies ist *« not just a tooling shift »*, sondern eine Veränderung des **Betriebsmodells** — die Rolle des Engineers verschiebt sich hin zu *« defining intent, mapping problems, reviewing generated changes, and making higher-context architectural and quality decisions »*. **Enablement** ist ebenso entscheidend wie das Tool selbst (praktisches Lernen, Hackathons, Workflow-Spotlights, Bootcamps, von Peers geleitete Beispiele); die Adoption verläuft teamübergreifend unterschiedlich schnell; *« The goal is not to force every workflow through an agent »* — das Ziel ist, es dort *« useful, safe, measurable, and repeatable where it creates meaningful leverage »* zu machen. **Erkenntnisse**: ***« AI doesn't eliminate bottlenecks in software development, but it does move them »*** (stromabwärts: Review, Validierung, Testing, Release, Produktionsbetrieb) → die Optimierung des alten Engpasses erzeugt nicht mehr denselben Hebel. *« The advantage will not come from access to the same foundation models everyone else can use. It will come from the systems built around those models: context, internal tooling, quality controls, and the workflows that connect them together. »* Der Druck baut sich auch **stromaufwärts** auf (Produkt & Design): strukturierte Specs, Design-Klarheit, schärfere Problemformulierung. Schluss: ***« The future of engineering productivity will not be defined solely by who has the best models. It will be defined by who builds the best systems around them »***; *« The real challenge is no longer just generating more code, but building engineering systems that can reliably turn AI-assisted output into valuable experiences for our customers »*. Direkte Konvergenz mit **Salesforce/Tallapragada** (Effective Output: Wert statt Volumen messen; kein Trade-off zwischen Geschwindigkeit und Qualität), **Gupta** (Token-zu-Outcome-Zuordnung, Kosten eines abgeschlossenen Outcomes), **DORA** (jenseits des Durchsatzes) und die Verschiebung des KPI hin zum **System-Outcome** (Idee→Kundennutzen).
**Kazuaki Okumura** — Dropbox (rôle non précisé dans l'article ; le billet reprend une intervention présentée à la conférence **DX Annual 2026** sur la productivité développeur, ce qui suggère un profil engineering leadership / platform, sans confirmation). Publié sur le **Dropbox Tech blog** (dropbox.tech) · rubrique *culture* · le **28 mai 2026**.
Viraler X-Thread (**230,5K Aufrufe**, 28. Mai 2026, 1:51 Uhr) von **Jaya Gupta** (@JayaGup10, Investorin — vermutlich bei Foundation Capital, Autorin des *Context Graphs*-Frameworks) mit dem Titel ***„Token Budget Wars“***. **Kernthese**: ***„Enterprise AI has moved from adoption to allocation“*** — Phase 1 der Unternehmens-KI hat bewiesen, dass Modelle funktionieren; Phase 2 wird entscheiden, **wie viel diese Arbeit wert ist**. Die neue Währung an der Unternehmensspitze ist die **Fähigkeit, den KI-ROI zu quantifizieren**: *„zeig mir den Wert“*. Kernkonzept: ***marginaler Token-Nutzen*** = *„der Geschäftswert, den jeder zusätzliche Dollar an Inferenz schafft“* — die Zahl, die im großen Maßstab zählt und die **die meisten Unternehmen nicht sehen können**. Zeitachse: **Claude wurde im November 2025 ausgeliefert**, nachdem die Jahresbudgets 2026 bereits festgelegt waren → schon im **Q1** lagen Unternehmen *„um ein Vielfaches über Plan“* → Inferenz hört auf, ein Experimentierposten zu sein, und wird zu **wiederkehrenden Betriebskosten**. Verschiebung von **Experimentieren (ein paar 100.000 $) → Infrastruktur (siebenstellig, 1 Mio. $+)**: Im Infrastruktur-Maßstab erzeugt **technische Varianz materielle Schwankungen in der Gewinn- und Verlustrechnung — zwei Durchläufe desselben Workflows mit demselben Input können sich im Token-Kostenaufwand um das 5- bis 10-Fache unterscheiden**, ohne dass sichtbar etwas kaputt ist, *„eine Zahl, die der CFO dem CEO erklären muss“*. **KI konkurriert mit Arbeitskraft**: 3 Arten von Budgetanfragen (ausgelagerte Arbeit ersetzen / interne Arbeit ersetzen / Umsatz generieren) → Verschiebung hin zu den ***Kosten eines abgeschlossenen Ergebnisses*** (Kosten pro gelöstem Ticket, bearbeitetem Schadensfall, geprüftem Vertrag, abgeschlossener Rechnung, vermiedener Neueinstellung, gehaltenem Kunden, bewegtem Umsatzdollar). **BPO = die einfachste Vergleichsbasis** (bereits in abgeschlossenen Einheiten bepreist); interne Arbeit ist deutlich schwieriger (multiskillte Mitarbeitende, diffuse Gewinne, Widerstand der Personalabteilung gegen Stellenabbau). **Warum es sich von SaaS unterscheidet**: SaaS hat gelernt, Nutzung als Proxy für Wert zu behandeln; KI bricht diesen Proxy — *„Signal und Rauschen teilen sich dieselbe Einheit“* (den Token), *„SaaS-Nutzung sagte dir, dass die Software adoptiert wurde. KI-Nutzung sagt dir, dass der Zähler läuft. Sie sagt dir nicht, ob dein Unternehmen brodelt.“* **Drei Ursachen für die Unsichtbarkeit des marginalen Token-Nutzens**: (1) ***Retry-Tails*** — Tokens pro gelöstem Workflow ≈ **T/p**; ein Rückgang der Abschlussquote von 90 % auf 70 % erhöht die effektiven Kosten um ~**28 %**, nicht 20 %, weil sich Fehlschläge kumulieren; (2) ***Kontext-Inflation*** — die Inferenzkosten verhalten sich ≈ **O(n²)** zur Kontextlänge (Attention), eine Verdopplung des Kontexts **vervierfacht** die Kosten des Reasonings (Over-Retrieval: 50 Dokumente, wo 5 genügen würden); (3) ***Routing*** — standardmäßig wird das leistungsstärkste Modell verwendet (einfache Klassifikation läuft auf einem komplexen Reasoning-Modell); über Millionen von Aufrufen hinweg macht der Unterschied zwischen dem Routing einfacher Aufgaben zu einem kleinen Modell und dem Versenden von allem an das Frontier-Modell *„den Unterschied zwischen einer überschaubaren Rechnung und einem Problem auf Vorstandsebene“* aus. **Sektorale Aufteilung**: **Software**-Unternehmen = ein Problem der **Produktivitätsmessung** (bereits instrumentiert: PRs, Commits, Deployments, Incidents, Zykluszeit, MTTR — verfolgt *„KI-Entlassungen“*); **Nicht-Software**-Unternehmen = ein **Transformations**-Problem (operative Arbeit: Schadensfälle, Underwriting, Support, Compliance-Prüfungen, Ausnahmen in der Lieferkette, Zahlungsstreitigkeiten — *im Audit korrekt, nicht nur im Durchschnitt korrekt*). **Die fehlende Schicht = Token-zu-Ergebnis-Attribution**: eine Umwandlungsschicht, die Inferenzausgaben → geleistete Arbeit → Geschäftsergebnis verknüpft und 3 Fragen beantwortet (reale Kosten einschließlich Retries/Korrekturen; welche Teile der Trace zählten vs. Thrashing; hat die Arbeit das Betriebsmodell verändert). ***Messung wird zu Gedächtnis***: Um einen Token mit einem Ergebnis zu verknüpfen, müssen **Entscheidungs-Traces** erfasst werden (was der Agent gesehen, abgerufen, aufgerufen, ignoriert hat, wo er es erneut versucht hat, wann ein Mensch eingegriffen hat) — *„die Entscheidungsbegründung ist eines der am schnellsten verderblichen Vermögenswerte eines Unternehmens“* (lebt in Slack, E-Mails, Eskalationsanrufen, in den Köpfen der Menschen). Agenten **erzeugen** diese Traces; zunächst erfasst, um die Ausgaben zu rechtfertigen, werden sie *„wertvoller als der Kostenbericht“* → ein **Context Graph** (*„auch wenn ich dieses Wort in letzter Zeit schon so leid bin“*). **Die Allokationsschicht ist der Preis**: Wer die Token-zu-Ergebnis-Attribution besitzt, trifft die **Allokationsentscheidungen** (welche Workflows mehr Rechenleistung verdienen, welche gedeckelt werden, welche zu günstigeren Modellen wechseln, welche menschlich bleiben, welche BPO ersetzen). Unternehmen werden das nicht allein tun — sie werden es **als Transformation einkaufen** (Fortune-500-Playbook: McKinsey- und Palantir-Alumni + top-down agierender CEO, nach Art von ERP/BI/digitaler Transformation, ein *„Programm“* mit einem Executive Sponsor und einer Infrastruktur, die zur **neuen Single Source of Truth** wird). Eingerahmt mit **Charlie Munger**: *„zeig mir den Anreiz, und ich zeige dir das Ergebnis.“* Organisatorische Nebenthese: der jahrzehntealte Führungsinstinkt, dass *große Teams = große Aufgaben/Reichweite/Macht* bedeuten → sobald Intelligenz zur **knappen Ressource** wird, ist das neue Statussymbol *„wie viel davon man orchestriert.“* Direkte Relevanz für die **Positionierung Cost Optimization / agentisches FinOps**: bestätigt empirisch die Hebel (Model-Routing, Prompt-Caching, Context-Hygiene, Sub-Agenten) und verschiebt den KPI hin zu **Kosten pro abgeschlossenem Ergebnis**. Starke Konvergenz mit Bains *Cross-System Labor* (Execution-Data-Moat, Cursor), Ngs *No AI Jobpocalypse* (Preisgestaltung verankert am Gehalt der ersetzten Arbeitskraft), DORA ROI (Kosten pro Feature), Mensch/Mistral (Elektron→Token), Ensarguet (Ökonomie der Berechnung), Foundation Capitals *Context Graphs* (Entscheidungs-Traces, gleiche Autorin), Wescales *Token Burning*, BFM/Girard (Token = Wert-Treibstoff).
**Jaya Gupta** (@JayaGup10) — investisseuse / VC. Très probablement **Foundation Capital** (le thread s'auto-réfère au cadre ***Context Graphs*** — *« ahem, context graph, although I am so tired of that word these days »* — concept porté par Foundation Capital, cf. fiche `bain-100b-saas-opportunity` qui cite *Foundation Capital — Context Graphs trillion-dollar opportunity, 2025-12-22*). Thread publié sur X le **28 mai 2026 à 1h51** · **230 · 5K vues** · format essai long en un seul post. Une réponse notable de **@tuning_engines** (*« DevSecFinOps for the Agentic Era »*) : *« Tokens will basically have to be managed like headcount […] model hierarchies too »*.
Offizieller **Salesforce News**-Blogbeitrag (Rubrik *Agentic Enterprise*, Reihe *„Pioneering the Agentic Shift Within Salesforce Engineering“*), veröffentlicht am **27. Mai 2026** (6 Minuten Lesezeit) von **Srinivas „Srini“ Tallapragada**, *President and Chief Engineering and Customer Success Officer* bei Salesforce. Direkte Fortsetzung eines früheren Beitrags (*„How we got our engineers to use AI — without breaking everything“*), der das Überschreiten von **>90 % Adoption** schilderte. **Kernthese**: Salesforce Engineering ist von einer Welt, in der KI ein nützlicher *Copilot* war, zu einer Welt übergegangen, in der **agentische Tools den Software-Entwicklungszyklus (SDLC) selbst steuern** — Code schreiben, PRs reviewen, Tests generieren, Dokumentation aktualisieren, Deployments verwalten, Arbeit koordinieren, die früher über menschliche Übergaben lief. **Kanonische Signalentscheidung**: unternehmensweite Standardisierung auf **Claude Code** + ***„we removed all token limits“*** — *„remove every last piece of friction between our engineers and the tools that make them faster and more effective“*. **Zentrales empirisches Ergebnis** (April 2026 vs. April 2025): abgeschlossene Arbeitspakete pro Entwickler **+50,8 %**, gemergte PRs pro Entwickler **+79 %**, und vor allem der **Effective-Output-Score** (ein ML-Maß für den **realen Wert des gelieferten Codes**, nicht dessen Volumen) **+151,3 % im Jahresvergleich**. **Vorzeige-Anwendungsfall**: Migration von **33 API-Endpunkten** auf eine Cloud-native Architektur, auf dem klassischen Weg geschätzt auf **~231 Personentage** (7 pro API), abgeschlossen in **13 Tagen — 18-mal schneller** — mittels eines **regelbasierten, in Claude gebauten Frameworks** (Markdown-Dateien + Referenzimplementierungen), wobei PR-Feedback laufend in das Regelwerk zurückgespeist wurde, **autonome LLM-Loops (build, fix, validate)** ohne manuellen Eingriff, parallelisiert über isolierte Umgebungen → **5 PRs**, wobei der größte **21 Endpunkte mit 100 % Testabdeckung** lieferte. **Kein Zielkonflikt zwischen Geschwindigkeit und Qualität**: über die Plattform **Engineering 360** (die Engineering-Daten aus Hunderten von Systemen zentralisiert) **sinkt die Gesamtzahl der Incidents um 5 %**, trotz der steigenden Zahl an PRs (*„quality doesn't suffer from speed. It benefits from it“*), dank **strukturell eingebetteter Sicherheits-Leitplanken und Qualitätsstandards** im agentischen Workflow (Trust als Wert Nr. 1). **SDLC-Überholung**: sobald KI eingeführt ist, **reißen die Ingenieure Workflows ein und bauen sie neu auf** (welche Prozesse lassen sich eliminieren? welche Übergaben sind jetzt überflüssig? wo erledigt noch ein Mensch Arbeit, die ein Agent übernehmen könnte?). **Neues Ingenieurshandwerk**: **Claude-Code-Skills** (paketierte, wiederverwendbare Fähigkeiten, die Teamkontext, Namenskonventionen, Muster kodieren) werden zu einem gemeinsamen, komponierbaren **Engineering-Artefakt**; **AI Expert Suite** + **Salesforce Foundation Plugins** = eine institutionalisierte, kuratierte Skill-Bibliothek (interner Benchmark: **höhere Genauigkeit und Zuverlässigkeit, weniger unnötige Kosten**); **Subagents & Agent-Teams** parallelisieren Arbeitsstränge (*„They describe the outcome, and a set of coordinated agents figures out the steps“*). **Was weiterhin schwierig bleibt**: (1) **Kontextmanagement** in langen Sessions — die **Qualität der CLAUDE.md-Datei** schwankt stark und wirkt sich erheblich auf die Output-Qualität aus; (2) **agentische Sicherheit** = ein grundlegend anderes Modell (Agenten, die *handeln*, nicht nur *vorschlagen* → größerer Blast Radius); (3) **sich wandelnde Rollen** (wie werden Junior- zu Senior-Ingenieuren, wenn KI die Einstiegsarbeit übernimmt? Rolle von Designer/PM? die Ausführungseinheit = Scrum-Team → Experimente mit Einheiten aus 1 oder 3 Personen). Fazit: *„It changed what was economically possible“*; die erklärte Ambition lautet **„the most automated, agentic SDLC in the industry“**. Berührt sich direkt mit Gupta (*Kosten eines abgeschlossenen Outcomes*, Grenznutzen des Tokens), Greenwald/Sierra (outcome-basierte Preisgestaltung), DORA (ROI / Kosten pro Feature) und der BFM/Girard-Debatte (Token als Wert-Treibstoff, nicht als zu kürzende Kostenposition).
#Agentischer SDLC#agentischer SDLC#Claude Code
**Srinivas « Srini » Tallapragada** — *President and Chief Engineering and Customer Success Officer* de **Salesforce**. Plus d'une décennie chez Salesforce · dirige l'ingénierie mondiale de la plateforme unifiée. Auteur de la série *Agentic Enterprise* sur le blog Salesforce News ; ce billet (27 mai 2026) est la **suite** d'un premier opus consacré à l'adoption de l'IA par les milliers d'ingénieurs Salesforce (*« How we got our engineers to use AI — without breaking everything »*). Position d'autorité = **dirigeant exécutif** parlant en son nom et au nom d'une organisation d'ingénierie à grande échelle (donnée terrain à l'échelle d'un hyperscaler SaaS) · avec accès aux métriques internes (Engineering 360, Effective Output).
FinOps für KI-Agenten: Ein vierstufiges Allokations-Framework für die Kosten von Coding-Assistenten (Claude Code, Cursor, Copilot) und weshalb klassisches Cloud-Tagging versagt - Finout
FinOps für KI-Agenten mit Fokus auf "Kosten pro Ergebnis": warum klassisches FinOps am Laufzeitverhalten scheitert, Guardrails, verhaltensbasierte Observability und ein vierphasiger Lebenszyklus - Orq.ai
#agentisches FinOps#Kosten pro Ergebnis#Laufzeitverhalten