Gastbeitrag von **Andy Warfield**, Ingenieur im **S3**-Team bei **AWS**, veröffentlicht am **26. August 2026** auf *All Things Distributed*, dem Blog von **Werner Vogels**, der ihn mit wenigen Zeilen unter „--W" einleitet: **3.554 Wörter** laut Seitenangabe. Der Text dient als Vehikel für die Ankündigung, dass **DuckLabs**, das Team hinter **DuckDB**, zu **AWS** stößt. (A) Die These: In der Systeminformatik geht es darum, den eleganten Kompromiss gegenüber einer sich verändernden „Physik" zu suchen — den Verhältnissen zwischen Speichergeschwindigkeit, Netzwerk und Rechenleistung — und diese Physik hat sich verändert. Warfield beziffert die Kluft: eine **m1.xlarge** aus dem Jahr 2007 bot **15 GB RAM**, **4 virtuelle Kerne** und **~1 Gb/s** Netzwerk; eine **m8g.48xlarge** bietet heute etwa das **50-fache** in jeder der drei Dimensionen. Das Wachstum der Datensätze folgt derweil einer Verteilung, deren Schwanz aus sehr großen Volumina besteht. (B) Die Konsequenz: Verteilte Verarbeitung — **MapReduce**, die **RDDs** von **Spark** — wurde unter den I/O-Beschränkungen der frühen 2000er-Jahre entworfen, und ein Großteil der ihr zugewiesenen Arbeit muss die Anwendung nicht mehr verlassen. Daher die eingebettete, prozessinterne Bibliotheks-Engine, die im Adressraum der Anwendung läuft und für die **DuckDB** das Beispiel liefert. Warfield verankert dies im Paper *Scalability! But at what COST?* (2015) und im Epigraph von **Paul Barham**: „You can have a second computer once you've shown you know how to use the first one." Er formuliert einen expliziten Vorbehalt: „When a job genuinely needs a thousand machines, it needs a thousand machines." Der Korpus enthält bereits [[vogels-tech-predictions-2026-allthingsdistributed-2025-11-25]] vom selben Blog und [[anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03]] zu Self-Service-Analytics.
#DuckDB#DuckLabs#AWS-Übernahme
Andy Warfield · ingénieur du service S3 chez AWS · en billet invité sur *All Things Distributed* ; introduction de Werner Vogels · CTO d'Amazon.
Essay von **Bill Staples**, CEO von **GitLab**, veröffentlicht am **24. August 2026** im Blog von about.gitlab.com: eine angekündigte Lesezeit von **31 Minuten**, rund **39.000 Zeichen**, dargestellt als Fortsetzung eines im Januar 2026 an den Verwaltungsrat gerichteten Memos, das im Mai teilweise unter dem Titel *GitLab Act 2* veröffentlicht wurde. Der Text versteht sich als Antwort auf das drei Tage zuvor veröffentlichte KI-native-SDLC-Playbook von **Anthropic**, dem er die Eingangszeile entlehnt – „Code is no longer the bottleneck“ –, um die Frage zu stellen, die ihn trägt: Was wird knapp, wenn Code im Überfluss vorhanden ist. (A) Die ökonomische Diagnose: Die nützliche Einheit sind nicht die Kosten pro Zeile, sondern die **Kosten pro akzeptierter Änderung**, die Generierung, Umgebung, Kontext, Verifikation, Review, Behebung und Governance zusammenfasst; KI lässt allein den Generierungsterm kollabieren, wodurch die übrigen proportional schwerer wiegen – eine Organisation, die zehnmal schneller generiert, „wird die Warteschlange lediglich verschieben“. (B) Die architektonische Antwort: vier Fähigkeiten – Agentenplattform, maschinenskalige Ausführung, dauerhafter Kontext, Governance – bilden eine Unternehmensschicht, die das Modell überdauert, „Das Modell sollte austauschbar sein. Der Agent sollte dem Kunden gehören.“ (1) Drei Modi koexistieren dauerhaft, vom menschengesteuerten Altsystem bis zur autonomen Entwicklung, gegen die Vorstellung einer einzigen Reifekurve. (2) Die CI/CD-Pipeline wird zu dem Ort, an dem die innere Schleife läuft, statt ein Gate am Ende der Kette zu sein. Die zitierten Zahlen stammen von Stripe, Spotify und Amplitude; GitLab liefert nur eine einzige, zur eigenen Quellcodeverwaltung. Der Korpus enthält bereits [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], die Quelle, auf die dieser Text antwortet, sowie [[sfeir-sdlc-pdlc-articulation-2026-07-22]] zur Verzahnung von SDLC/PDLC, die Staples sich zu eigen macht.
#Codeüberfluss#Kosten pro akzeptierter Änderung#Theory of Constraints
Bill Staples · directeur général de GitLab (fonction non affichée par la page) · sur le blog about.gitlab.com.
Produktankündigung von **Block Engineering**, gezeichnet von **Thomas Petersen** (*Principal Designer & Builder*), veröffentlicht am **18. August 2026**, ~1.800 Wörter in dreizehn kurzen Abschnitten, die **Buzz Projects** vorstellt — eine **Software-Forge, gehostet auf dem eigenen Relay**: Git-Repositories, Branches, Pull Requests, Issues, Review und Merge, Multi-Repo-Projekte, ein Activity Feed, alles verknüpft mit Conversation-Channels. Vorspann und These des Beitrags: *« Coding agents are the terminal for your computer. Buzz is the terminal for your network. »* Drei Beiträge. **(A) Eine Vertrauensdoktrin, die auf *ex post*-Nachweis statt auf *ex ante*-Autorisierung beruht**: auf der einen Seite *« No forced guardrails, no limitations on what your agents are allowed to help you with »*, auf der anderen *« Every push, review, approval, and merge is a signed Nostr event. If an agent authors a patch, you can see which agent produced it and which human authorized that agent to act »*; der Abschnitt schließt mit einer angekündigten Richtung — *« we are already exploring ideas around agent trust protocols informed by past behavior »*. **(B) Git-Interoperabilität ohne proprietäres Tooling**: *« These are standard git repositories… You can fetch, clone, pull, and push over plain Smart HTTP, with no custom tooling or wrapper CLI required »*, wobei die clé Nostr als einzige Identität dient — *« The same npub that signs your messages signs your pushes. »* **(C) Eine Unterscheidung zwischen Ausführungsfläche und Netzwerkpräsenz**: *« A terminal gives an agent somewhere to execute commands and change files, but it does not give it a persistent place in the network. Buzz does. »* Der Beitrag liefert keine Zahlen und enthält keine ausgehenden Links; er qualifiziert sich sechsmal selbst als vorläufig (*« still very basic »*, *« fairly elementary »*, *« still under experiments »*), und Projects befindet sich unter dem Tab **Experiments** von Buzz Desktop.
#Buzz#Buzz Projects#Block
**Thomas Petersen** — *« Principal Designer & Builder »* chez **Block** · auteur unique et signataire du billet ; première apparition dans le corpus. Publié le **18 août 2026** sur le blog **Block Engineering**. Troisième signature Block sur Buzz en un mois · après Tyler Longwell (21 juillet) et Atish Patel (6 août) · et la première non-ingénieur.
Offizielle Produktseite von **DeepSeek**, veröffentlicht am **13. August 2026**, **nicht namentlich gezeichnet**, ca. 450 Wörter, die die *Developer-Preview*-Veröffentlichung von **DeepSeek Harness** (`dsh`) ankündigt — ein Coding-Agent-Harness, **Open Source unter der MIT-Lizenz**, dessen Repository am selben Tag eröffnet wurde. Eine Drei-Wort-These, wiederholt im Titel und in der Repository-Beschreibung: *« Everything is a plugin »*, gepaart mit einem zweiten Versprechen, *« Every run is traceable »*. Die Seite formuliert die Gleichung *« AGENT = MODEL + HARNESS »* und listet die steckbaren Fähigkeiten auf — *« models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI »*. Vier Modi werden ausgeliefert: **Standard** (vollständiger Coding-Agent), **Code** (Tools, die über das *Code Mode SDK* freigelegt werden und es dem Modell erlauben, mehrstufige Operationen innerhalb eines TypeScript-Programms zu komponieren), **Minimal** (*« two-tool coding agent with persistent bash and str_replace_editor »*, ausdrücklich *« for benchmarking models in a minimal environment »*), und **Creator** (Laufzeitinspektion, In-Memory-Plugin-Tests). Die technische Substanz liegt im Repository, nicht auf der Seite: `docs/architecture.md` formuliert eine Logging-Invariante — *« Model-visible means logged. Anything that reaches a model request must be reconstructable from the log, and a runtime invariant asserts it »* — und stellt fest, dass *« there is no privileged core to patch »*. Der technische Kern stammt nicht von DeepSeek selbst: DSH baut auf **Cordis** auf (dem `cordiverse`-Projekt, einem Dritten), **vendort** in `vendor/` mit Manifest und Sync-Verfahren, und die Seite platziert das *« Cordis paper »* auf derselben Navigationsebene wie „GitHub“ und „Developer docs“. Zwei LLM-Adapter werden ausgeliefert — `dsh-llm-deepseek` und `dsh-llm-pi-ai`, ein generischer Multi-Provider-Adapter. Das Repository warnt in Großbuchstaben: *« THERE WILL BE COMPATIBILITY-BREAKING CHANGES »*, und `CLAUDE.md` legt fest, dass `SESSION_FORMAT_VERSION` bei `0` bleibt, *« with no compatibility promise »*, wobei Backends alte Formate auf der Festplatte ablehnen. Zeitachse: DSH erscheint an dem Tag, an dem **DeepSeek-V4-Pro GA erreicht**, drei Tage bevor am **16. August 2026 um 16:00 UTC** ein neuer API-Preisplan in Kraft tritt, mit Spitzen-/Nebenzeittarifen und einem Nebenzeit-Rabatt von **−50 %**.
#DeepSeek Harness#dsh#Agent-Harness
**DeepSeek** (DeepSeek AI, laboratoire chinois) · en tant qu'institution. Page produit **non signée** : aucun auteur · aucun ingénieur mis en avant · aucun billet de blog ni papier technique associé. Le « nous » n'apparaît qu'une fois · en dernière phrase — *« We look forward to exploring the limits of intelligence with developers worldwide »*. Publiée le **13 août 2026**. La page est rendue en JavaScript : `curl` sur l'URL renvoie **HTTP 202 avec un corps vide** · le texte n'existant qu'après exécution du bundle. Deux documents de politique sont liés en pied de page — *Safe Use Policy* et *Data Processing Statement*.
Interner Rechercheureport vom **12. August 2026**, der zu Präsentationszwecken alles öffentlich Dokumentierte über **Buzz** zusammenfasst — den Workspace für Menschen und Agenten von **Block**, der am **21. Juli 2026** unter der Lizenz **Apache 2.0** eingeführt wurde. Er aggregiert die beiden bereits veröffentlichten Engineering-Beiträge neben der Unternehmensankündigung, das GitHub-Repository, die Presseberichterstattung, X sowie **drei unabhängige Praxisberichte**, die die einzigen nicht selbst berichteten Daten des Dossiers darstellen. **(A) Eine durch Zitat dokumentierte Begriffslücke**: Der Launch-Tweet von **Jack Dorsey** kündigt *„model-agnostic, decentralized, self-sovereign, and open source“* an; Blocks `ARCHITECTURE.md` stellt fest: *„The relay is the single source of truth. All reads and writes flow through it. There is no peer-to-peer event exchange, no gossip, no replication.“* Der Relay ist somit pro Community einzig und maßgeblich: Buzz' „Dezentralisierung“ ist eine **organisatorische Souveränität** — Self-Hosting und portable Identität — keine Netzwerkredundanz. Formulierung von **TFTC**: *„Two of those three hold cleanly. The third needs a qualifier.“* **(B) Eine Asymmetrie zwischen nachgewiesener Rigorosität und Ausnutzungsrisiko.** Auf der einen Seite ein für ein v0.4.x/0.5.x seltenes Maß an Formalismus: Spezifikation der Mandanten-Isolation **mechanisiert in TLA+**, in **Tamarin** verifizierte Autorisierungseigenschaften, ein modellgeprüftes Git-Speicherprotokoll, ein hash-verkettetes Append-only-Audit-Log, 127 *event kinds*, NIP-01/42/98/34. Auf der anderen Seite ist Kanalmitgliedschaft die Berechtigungseinheit — *„channel membership is not fine-grained tool authorization“* (João Queirós) —, Agenten laufen in `--dangerously-skip-permissions` außerhalb jeder Sandbox auf der Maschine eines Menschen, und die Beobachtbarkeit fehlt: *„Buzz tells me an agent got a message. It doesn't tell me what happens next“* (DevTools Daily, das stille OOM-Kills berichtet). Block räumt es ein: *„the agent can do anything, and security rests entirely on restricting who can tell it what to do“*. **(C) Der technische Stack**, der in den veröffentlichten Beiträgen fehlt: **Rust**-Relay (Axum WS + REST), **Postgres**, **Redis**, **S3/MinIO** via Blossom, Desktop-Client **Tauri + React**. Die Agentenintegration erfolgt über **`buzz-acp`**, ein **ACP**-Harness, das goose, Codex und Claude Code einbindet und **ACP ↔ MCP** übersetzt, sowie **`buzz-agent`**, einen hauseigenen Agenten. Der Report korrigiert sich an einem Punkt selbst: Die *„+33% more work“* in Blocks TL;DR sind das **Verhältnis abgeschlossener Aufgaben (20 gegenüber 15 von 44)**, kein Punktzahlgewinn — die Punktzahl selbst steigt von 59,1 % auf 71,5 %, also **+12,4 Punkte**.
#Buzz#buzz.xyz#Block
**Deep Research Veille Interne** — rapport non signé · produit le **12 août 2026** en préparation d'une présentation. Aucune URL publique ; source archivée dans `raw-data/`.
Erfahrungsbericht, veröffentlicht auf **LinkedIn Pulse** am **12. August 2026** von **Guillaume Dumortier** in seinem Newsletter *Growth Marketing Fit*, mit dem Untertitel *„Four layers, a lot of rebuilding, and the failure modes nobody warns you about"*, ~2.500 Wörter. Thema: ein internes KI-System, gebaut **in Claude** für ein Marketingteam von rund sechzig Personen – etwa dreißig Content- und Sales-**Skills**, ein Dutzend **Source-of-Truth-Module**, **sieben Agenten, von denen sechs ausschließlich Arbeit prüfen statt sie zu produzieren**, ein **Plugin** für alle, die im Terminal arbeiten, eine **Browseranwendung**, die dasselbe Wissen für alle anderen bereitstellt, und eine Orchestrierung, die drei oder vier Assets zu einem *campaign bundle* verkettet. Die These wird früh formuliert: Die Qualität eines KI-Outputs entscheidet sich nicht im Moment der Generierung, sondern durch das, was das System vorher weiß, und durch das, was anschließend mit dem Entwurf geschieht – *„The generation step in the middle is the easy part. It's also the only part most teams have built."* Daraus ergeben sich vier Schichten: **Truth** (fast niemand baut sie), **Production** (jeder), **Verification** (fast niemand), **Internal distribution** (*„where good systems die of neglect"*). Zwei Fehlermechanismen tragen den Artikel. **(A) Das nackte Closed-World-„pass" des Prüfers**: Ein Fact-Checker, der auf Produktdokumentation gestützt ist, erhält einen Entwurf mit einer Behauptung über ein anderes Produkt, das von seinen Quellen nicht abgedeckt wurde – er liefert ein *„pass"*, nicht weil die Behauptung wahr war, sondern weil ihr nichts widersprach. *„It didn't just miss the error, it certified it."* Lösung: ein nacktes Urteil verbieten und von jedem Bericht verlangen, die **eigene Abdeckung** offenzulegen – wie viele Behauptungen geprüft wurden, wie viele mit Quellen abgeglichen werden konnten, welche außerhalb seiner Zuständigkeit lagen, welche keiner Quelle zugeordnet werden konnten. *„\"I can't verify this\" became a first-class result."* **(B) Der Cross-Asset-Widerspruch**: Zwei Assets können jedes für sich korrekt sein, jedes auf eine reale Quelle rückführbar sein, und sich dennoch widersprechen – die Pressemitteilung nennt ein Datum, der Blogbeitrag ein anderes, beide bestehen die Prüfung, das Bundle kann nicht ausgeliefert werden. *„Per-asset verification can't catch that, by construction."* Schlusssatz des Artikels: *„The generation is free. The trust is the product."*
**Guillaume Dumortier** — auteur de la newsletter LinkedIn **Growth Marketing Fit** (~1 300 abonnés à la publication). Il écrit en **praticien-constructeur** : il a passé *« une longue partie de cette année »* à bâtir et exploiter le système décrit. La légende de l'illustration précise le socle technique — *« A custom-built Marketing AI OS within Claude »*. Publié le **12 août 2026**.
Ankündigung von **Google** am **6. August 2026**: Google tritt als **Core Maintainer** der Spezifikation **Agent Plugins 1.0.0** bei, einem offenen, *anbieterneutralen* Packaging-Format für die gemeinsame Verteilung von **Agent Skills** und **MCP servern**. Die Spezifikation wurde von einem **TSC** veröffentlicht, dessen Core Maintainer von **Amazon, Cursor, Microsoft, OpenAI und Vercel** stammen; Google tritt ihnen bei, vertreten durch **Kevin Hou** (Senior Staff Engineer, Google DeepMind). Die beiden gepackten Bausteine — Agent Skills und MCP — stammen von **Anthropic**, das auf dieser Liste der Maintainer nicht erscheint. **Die Diagnose** passt in einen Satz: *„The core problem isn't the components. It's the manifest.“* Ein Skill ist portabel, ein MCP server ist portabel; die Kiste, in der sie stecken, ist es nicht, und jeder Client musste sie sich selbst ausdenken — daher die Forks, die Kopien identischer Komponenten und ihr Auseinanderdriften. **Das Format** passt in eine Einschränkung: *„A plugin is a directory. That's the whole idea, and the restraint is the point.“* Eine `plugin.json` mit zwei nützlichen Zeilen (`$schema` und `name`), Skills in `skills/` im Agent-Skills-Format, servers deklariert in `mcp.json` mit einem **expliziten `type` bei jedem Eintrag** (stdio, Streamable HTTP oder das veraltete HTTP+SSE) — kein erratener Transport aus der Form des Konfigurationsobjekts mehr. Die Stärke des Designs liegt in dem, was das Manifest **nicht** kann: Komponenten weder verlagern noch inline deklarieren, sodass es keinen zu konfigurierenden Discovery-Pfad und keine zu erlernende Rangfolge gibt. Operatives Korollar: Komponenten **scheitern unabhängig voneinander** — ein `mcp.json`-server, der nicht startet, reißt nicht die Skills des Plugins mit sich; der Client überspringt den Eintrag, macht weiter und meldet den Fehler. Das akzeptierte Schlupfloch ist das **Reverse-Domain**-Verzeichnis (`com.example.client/`), ein Erweiterungsraum, der vollständig einem Client gehört (hooks, agents, commands) und von anderen Clients ignoriert wird: *„the portable core stays small because the non-portable parts have somewhere legitimate to go.“* Ein Abschnitt widmet sich Fällen, in denen das Format nicht gerechtfertigt ist — *„Not every skill should be a Plugin“*: ein einzelner MCP server für einen einzelnen Client, `mcp.json` genügt; ein einzelner Skill braucht kein Plugin. Was v1 unter *future considerations* ausdrücklich ausschließt: **kein Installationsmechanismus, kein Distributionsprotokoll, kein Berechtigungsmodell, keine Sandboxing-Anforderung, keine Vertrauens- oder Herkunftsprüfung, keine UX**. All das fügt sich in einen unabhängig adoptierbaren vierschichtigen Stack — **finden** (Agentic Resource Discovery), **beschreiben** (AI Catalog, das den Typ `application/agent-plugins+json` registrieren würde), **packen** (Agent Plugins), **ausführen** (MCP + Agent Skills). Zwei Google-Produkte liefern bereits aus: **Agents CLI** und **Data Agent Kit** (BigQuery, Spanner, Cloud SQL).
Ein **Block-Engineering**-Benchmark-Beitrag vom **6. August 2026**, verfasst von **Atish Patel**, über **Buzz** – den am 21. Juli gestarteten Workspace für Mensch und Agent – der eine Kostenfrage stellt: Welches Agententeam ist **das günstigste, das zuverlässig erfolgreich ist**? Drei Befunde. **(A) Ein vollständig veröffentlichtes negatives Ergebnis**: Auf **Terminal-Bench 2.1** wurden **zwölf Teamzusammensetzungen** (Paare, Triaden, günstige Schwärme unter einem *Frontier*-Modell) gegen den jeweiligen Solo-Agenten antreten lassen, um den sie herum gebaut waren, und **keine schlug ihn bei gleichen Kosten**. Die Erklärung ist struktureller Natur – einer Aufgabe, die in Minuten erledigt ist, *„fehlt genug Struktur, um sie aufzuteilen"*, und *„mehr Agenten kaufen meist nur die Kosten, es zweimal zu erklären"*. **(B) Der Zeithorizont kehrt das Ergebnis um**: Auf **Long-Horizon Terminal-Bench** (44 Aufgaben, eine Aufgabe im Wert von Stunden Arbeit, gleicher Lead **GPT-5.6 Sol** mit *high*-Aufwand) schließt Solo 15 Aufgaben ab bei 59,1 %, +2 QuickBees 19 bei 64,1 %, +1 QuickBee +1 WorkerBee 19 bei 69,5 %, **+2 WorkerBees 20 bei 71,5 %** – ein Zugewinn von **+12,4 Punkten**, wovon 11,4 aus abgeschlossenen Aufgaben stammen. *„Gleiche Plätze, umgekehrtes Ergebnis, weil die Arbeit eine andere Form hat."* Diese Durchläufe liefen mit dem **3-fachen Timeout**, Solo eingeschlossen. **(C) Jenseits einer Schwelle kauft der Preis keine Qualität mehr**: Solo auf Terminal-Bench 2.1, **Opus 5 mit *xhigh*-Aufwand ist der teuerste Durchlauf (140,63 $) bei 75,0 %**, hinter sechs Durchläufen zwischen 20,08 $ und 109,82 $ und 79,5 % bis 88,4 % – als Ursache wird Over-Reasoning genannt, das 17 von 88 Aufgaben in den Timeout trieb. Unter den sechs besten Durchläufen liegt **eine 5,5-fache Preisspanne bei einer Punktzahldifferenz von 8,9 Punkten**: *„die Wahl zwischen ihnen ist überhaupt keine Qualitätsentscheidung. Es ist eine Budgetentscheidung."* Der Beitrag schlägt eine Taxonomie vor, die er selbst als *ad hoc* bezeichnet – **QuickBee**, **WorkerBee**, **SmartBee**, dazu der Mensch als *„Ehrenbiene"* – sowie zwei Teamformen: die permanente **Hive**, die sich die Präferenzen der Nutzenden merkt, und der einmalige **Swarm**, der sich das Projekt merkt. Rahmenbedingungen: alles läuft auf **Harbor**, gegen echte Buzz-Agenten auf einem **Live**-Relay, **ein Versuch pro Aufgabe, kein Retry**, Preise festgeschrieben zum **30.07.2026**.
#Buzz#Block#Agententeams
- **Atish Patel** — *« Building AI solutions @ Block »* · auteur unique du billet · publié le **6 août 2026** sur `engineering.block.xyz`.
Skill-Eintrag: **graphify** von **Safi Shamsi** (Graphify Labs, Y Combinator S26) verwandelt ein gesamtes Projekt — Code, Dokumentation, PDFs, Bilder, Videos — in einen **abfragbaren Knowledge Graph**, aufgerufen über `/graphify` aus Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot und rund fünfzehn weiteren Clients. Stand **6. August 2026**: **103.187 Stars**, **10.024 Forks**, Repository erstellt am **3. April 2026**. Apache-2.0, Python 3.10+, Standard-Branch **v8**. **Drei im README genannte Designentscheidungen**. *„Code maps for free, fully local"*: Der Code wird deterministisch und ohne LLM in einen **tree-sitter-AST** geparst, ohne dass etwas die Maschine verlässt. *„Every edge is explained"*: Jede Kante wird mit **`EXTRACTED`** (explizit in der Quelle) oder **`INFERRED`** (von graphify aufgelöst) gekennzeichnet, mit einem dritten Wert `AMBIGUOUS`, der im Report erscheint. *„Not a vector index"*: *„no embeddings, no vector store: a real graph you traverse"*. **Drei Ausgaben**: `graph.html` (interaktiver Graph), `GRAPH_REPORT.md` (God Nodes, überraschende Verbindungen, vorgeschlagene Fragen) und `graph.json` (persistenter Graph, Wochen später abfragbar, ohne die Dateien erneut zu lesen). **Drei Abfragemodi** als Ersatz für grep: `query` (Subgraph zu einer Frage in natürlicher Sprache), `path A B` (kürzester Pfad zwischen zwei Entitäten) und `explain` (Nachbarschaft eines Konzepts). **Abdeckung**: 36 tree-sitter-Grammatiken (~40 Sprachen), außerdem Terraform, Apex, MCP-Konfigurationen, Paketmanifeste, Office, Google Workspace, PDFs, Bilder sowie Video/Audio, lokal transkribiert von faster-whisper. Communities werden über **Leiden** erkannt, ohne LLM beschriftet. **Benchmarks**: auf LOCOMO ein recall@10 von **0,497** gegenüber 0,149 für supermemory und 0,048 für mem0, jedoch geringere QA-Genauigkeit (45,3 % gegenüber 49,7 %); auf LongMemEval-S **76 %**, auf Augenhöhe mit einem dense RAG; sowie *„Graph build — LLM credits: 0"*. **Festzuhaltende Punkte**: Der `main`-Branch trägt ein README aus der v1-Ära, das ein anderes Produkt beschreibt (Skill nur für Claude Code, die Behauptung „71.5× fewer tokens"); das PyPI-Paket heißt **`graphifyy`** mit zwei *y*, während der Name `graphify` zurückerobert wird; und ein **Query-Log** wird standardmäßig unter `~/.cache/graphify-queries.log` geschrieben, das sich über eine Umgebungsvariable deaktivieren lässt.
#Skill#Wissensgraph#Wissensgraph
**Safi Shamsi** — créateur et mainteneur de graphify · et de **Graphify Labs** · société passée par **Y Combinator (promotion S26)** selon le badge du dépôt. Il maintient aussi le site d'annuaire `graphify.net` (cf. [[graphify-net-annuaire-ia-coding-2026-08-06]]) et publie un livre · *The Memory Layer* · sur les idées et l'architecture derrière le projet.
Dokumentationsseite zu **Notion as Code**, veröffentlicht im **Notion Ambassadors**-Workspace und abgerufen am **3. August 2026**. Produkt im **Closed-Alpha-/Warteliste**-Status, mit einem Warnhinweis vorab: *« This product is under development so we recommend you try it out in a new workspace vs. your primary workspace »* und *« There may be breaking changes until we're fully launched »*. **Das Prinzip ist Infrastructure as Code, angewandt auf einen dokumentarischen Workspace**: *« Instead of having to make individual public API requests, you can describe the final state and we handle updating your workspace to match. »* Zwei Bausteine: ein **TypeScript SDK** zur Beschreibung des gewünschten Zustands und ein öffentlicher API-Endpunkt `/v1/infra_as_code` zu dessen Bereitstellung. **Der Mechanismus, der alles zusammenhält, ist der Ressourcenbezeichner**: Das Skript enthält **überhaupt keine Notion-ID**, sondern nur vom Autor gewählte *resource IDs*; das erste Deployment liefert eine **Zuordnungstabelle** `resourceId → RecordPointer` zurück, die bei nachfolgenden Aufrufen wieder übergeben wird, sodass dieselben Datensätze **aktualisiert statt neu erstellt** werden. Daraus folgen drei Eigenschaften, und sie sind die einzigen, die zählen: Das Skript ist **idempotent** (erneutes Deployment = Aktualisierung), es ist **vom Workspace entkoppelt** (mehrere Zuordnungstabellen erlauben das Deployment **desselben Skripts auf mehrere Workspaces**), und es ist Code — daher Variablen und Schleifen, wobei als Beispiel genannt wird, *« build 10 teams that all have a very similar structure and just need some nouns renamed »*. **Die API ist asynchron**: `POST /v1/infra_as_code` liefert eine `taskId` zurück, die über `GET /v1/async_tasks/{taskId}` abgefragt wird, bis der Status `succeeded` erreicht ist. **Zwei bemerkenswerte betriebliche Unterschiede**: Das Produkt erfordert **persönliche Zugriffstoken** anstelle der üblichen Bot-Token der öffentlichen API, und das **Rate Limit ist auf 5 Anfragen pro Minute gesenkt**, da ein einzelner Aufruf nicht mehr eine einzelne Entität, sondern einen Batch erzeugt. **Für dieses Korpus festzuhalten**: Die Seite ist explizit für den assistierten Einsatz geschrieben — *« A typescript SDK for you **or your coding agent** to describe what you want »* —, und der empfohlene Einstiegsweg besteht darin, das SDK auf einem experimentellen Branch zu klonen und *« either you or your favorite coding agent »* die README öffnen zu lassen. **Genannte Einschränkungen**: kein Erstellen eines neuen Workspace möglich, nur teilweise Abdeckung der Primitiven, sowie eine Seite ohne Autor- oder Datumsangabe.
#Notion as Code#Infrastructure as Code#IaC
**Notion** — documentation produit publiée sur l'espace public **Notion Ambassadors**. **Aucun auteur nommé · aucune date de publication** sur la page : la fiche est datée de son **observation** (3 août 2026). Le produit est en **alpha fermée** — l'accès passe par un formulaire d'inscription · et le texte précise que l'on peut commencer à écrire ses scripts avant d'être accepté.
Landingpage der **offiziellen Spezifikation** des **Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), abgerufen am **2. August 2026**. Es handelt sich nicht um einen datierten Artikel, sondern um ein **lebendes Artefakt**: Die Fiche ist nach ihrem Beobachtungszeitpunkt datiert, nicht nach einem Veröffentlichungsdatum. **Ein-Satz-Missionsaussage**: *« The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios. »* **Das genannte Problem** lässt sich in drei Zeilen fassen: Coding Agents und Editoren sind **eng gekoppelt**, und *« interoperability isn't the default »* — jeder Editor muss für jeden Agenten eine eigene Integration bauen, jeder Agent muss editorspezifische APIs implementieren. Drei benannte Konsequenzen: **Integrationsaufwand** (jedes Agent-Editor-Paar erfordert individuelle Arbeit), **eingeschränkte Kompatibilität** (ein Agent erreicht nur eine Teilmenge der Editoren), **Developer-Lock-in** (*« choosing an agent often means accepting their available interfaces »*). **Die Lösung ist explizit an LSP orientiert** — *« similar to how the Language Server Protocol (LSP) standardized language server integration »* — mit gegenseitigem Nutzen: Ein Agent, der ACP spricht, funktioniert mit **jedem** kompatiblen Editor, ein Editor, der ACP unterstützt, erhält Zugang zum **gesamten** ACP-Agenten-Ökosystem. **Zwei Deployment-Modi, und das ist der am meisten unterschätzte Punkt**: **Lokale** Agenten laufen als Subprozess des Editors über **JSON-RPC auf stdio**, aber **Remote**-Agenten sind über **HTTP oder WebSocket** geplant — die Unterstützung wird als *« work in progress »* deklariert, mit laufender Zusammenarbeit mit agentischen Plattformen. **Technische Abstammung von MCP, stärker als bloße Komplementarität**: ACP *« re-uses the JSON representations used in MCP where possible »* und ergänzt Typen, die spezifisch auf die UX-Bedürfnisse des agentischen Codings zugeschnitten sind (die **Diff**-Anzeige wird als Beispiel genannt); das Standardformat für lesbaren Text ist **Markdown**, gewählt, damit der Editor nicht zum Rendern von HTML gezwungen ist. **Zwei Beobachtungen zu Governance und Versionierung**, die der Seite selbst entnommen sind, nicht dem umgebenden Diskurs: Die Navigation zeigt **v1 (Latest)** und **v2 (Draft)** — und **nicht ein „ACP 1.2“** —, und die Navigationsleiste verlinkt **Zed Industries *und* JetBrains** gleichrangig nebeneinander, neben einer **ACP Registry**, **RFDs**, einem **Community**-Bereich, **Publications**, **Updates** und einer **Brand**-Seite. Angekündigte offizielle Bibliotheken: **Kotlin, Java, Python, Rust, TypeScript**, plus ein Community-Track.
#Agent Client Protocol#ACP#offenes Protokoll
**Projet Agent Client Protocol** — spécification collective · sans signature individuelle sur cette page. La barre de navigation du site lie deux organisations au même niveau : **Zed Industries** (à l'origine du protocole) et **JetBrains**. La présence d'une section **RFDs** (*requests for discussion*) · d'une page **Community** et d'un **ACP Registry** indique une structure de gouvernance ouverte plutôt qu'une documentation produit.
Tech-Watch-Notiz von **Didier Girard** vom **2. August 2026**, ausgelöst durch die Frage eines Kollegen ("Was ist ACP?"), die ein Problem behandelt, das nicht terminologisch, sondern **dokumentarisch** ist. **Drei Protokolle konkurrieren um das Akronym**, ohne jede technische Überschneidung: **Agent Client Protocol** (Client ↔ Agent — Zed, August 2025, JSON-RPC 2.0 über stdio, Apache-2.0, "das, was LSP für Sprachen war"), **Agentic Commerce Protocol** (Agent ↔ Händler — OpenAI + Stripe, 29. Sept. 2025, in Konkurrenz zu Googles **UCP** vom 11. Jan. 2026, gestützt auf **AP2**), und **Agent Communication Protocol** (Agent ↔ Agent — IBM Research / BeeAI, marginal, aber suchverfälschend). **Der Kern der Notiz ist nicht die Entwirrung, sondern das beobachtete Scheitern**: Der Autor sucht "ACP" in seiner Tech-Watch-Wissensdatenbank und erhält **zwölf Treffer, alle zum Commerce-Protokoll, keinen zu dem von Zed** — *"unsere Watch-Agenten hatten das Akronym indexiert, ohne es zu disambiguieren"*. Daraus folgt eine Regel des Knowledge Engineering: ***"ein nacktes Akronym wird nie indexiert"*** — die Entität ist "Agent Client Protocol", "ACP" ist **nur ein Alias**, getragen von drei verschiedenen Entitäten. Es folgt eine strukturierende Klarstellung (**MCP verbindet einen Agenten mit seinen Tools, ACP verbindet einen Client mit einem Agenten; beide stapeln sich**), dann der Lehrbuchfall: **Buzz**, von **Block** am 21. Juli 2026 unter Apache-2.0 veröffentlicht — ein selbst hostbarer Arbeitsbereich auf Basis von **Nostr**, in dem jeder menschliche oder agentische Teilnehmer ein **Schlüsselpaar** ist und jede Nachricht, jeder Workflow-Schritt oder Git-Push ein **signiertes Ereignis** in einem Append-only-Log ist. Eine vollständig protokollbasierte Architektur (`buzz-acp` ein ACP-Harness über stdio, `buzz-agent` ein ACP-Agent, der ein LLM aufruft, `buzz-dev-mcp` ein MCP-Shell- + Editier-Server), daher Agenten-Agnostizismus: **Goose, Claude Code und Codex** docken über dasselbe Harness an, und **Hermes** (Nous Research) hat sich damit verbunden, ohne dass Block eine einzige Zeile geschrieben hätte — *"N+M statt N×M, im Produktivbetrieb"*. Die Notiz schließt mit der Frage des **Claude-Abonnements** gegenüber Drittanbieter-Agenten, mit einer fünfstufigen 2026er-Zeitleiste und einer **Gestaltungsregel**, die über diesen Fall hinaus gilt: Die Grenze ist nicht rechtlicher, sondern **architektonischer** Natur — ***"wer konsumiert, und in wessen Auftrag"*** (ein `owner-only`-Agent verbraucht Ihr Abonnement in Ihrem Auftrag; ein `anyone`-Agent in einem gemeinsamen Kanal leitet die Anfragen Ihrer Kollegen über Ihr Konto). **Am vorliegenden Korpus durchgeführte Überprüfung**: Die These bestätigt sich, und schärfer noch, als die Notiz behauptet — nicht nur ist "Agent Client Protocol" **vollständig abwesend**, sondern das nackte Akronym `ACP` **ist bereits als Entität typisiert** in zwei Fiches, und die KB-Seite `Agentic-Commerce-Protocol` **schreibt das Protokoll bereits Google zu**, obwohl es OpenAI + Stripe gehört. Die beschriebene Kollision ist kein zukünftiges Risiko: Sie hat **bereits einen Zuschreibungsfehler** im Graphen erzeugt.
**Didier Girard** — auteur de la note. Écrit ici depuis la position de **praticien de la veille outillée** : le déclencheur est une question de collègue · le matériau principal est le comportement observé de sa propre base de connaissances · et la conclusion est une **règle de curation** adoptée en interne. Le texte alterne donc deux voix — l'explicateur de protocoles et l'ingénieur de la connaissance qui constate un défaut chez lui et en tire une norme.
Referenzseite, veröffentlicht auf **eventuallycoding.com** am **28. Juli 2026** von **Hugo Lassiège** (Lyon, vom Entwickler zum Unternehmer, Autor von Bloggrify, Hakanai und Writizzy). Der Autor kündigt sie selbst so an: *„Das wird eher eine Referenzseite als ein Artikel sein“*, gedacht für seine eigene Ressourcenseite. **Thema**: eine erschöpfende, werkzeuggestützte Beschreibung einer **Solo-Softwarefabrik**, in der *„der produzierte Code inzwischen fast zu 100 % generiert ist“*, über mehrere polyglotte Monorepos hinweg (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) in **kontinuierlicher Auslieferung in Produktion**. **Vorab getroffene Unterscheidung**: Dies ist kein **vibe coding** im Sinne von Karpathy (Experimentieren, sich treiben lassen), sondern **context engineering** — *„den gesamten notwendigen Kontext zum richtigen Zeitpunkt geben, damit die Software einer Absicht entspricht und systematisch kontrolliert wird“*, mit dem Satz, der die Verantwortung begründet: *„Auch wenn ich den Code nicht schreibe, bin ich dafür verantwortlich und muss die Kontrolle darüber behalten.“* **Das gesamte Werkzeug-Set beantwortet drei Fragen**, und das ist das am besten wiederverwendbare Lese-Raster des Textes: *„Was weiß der Agent?“* (Kontext, Gedächtnis, Code-Graph) — *„Was kann er deterministisch, ohne zu improvisieren?“* (Skills, Prozeduren) — *„Was stoppt ihn, wenn er einen Fehler macht?“* (Hooks, Architekturtests, Qualitäts-Gates). **Sechs im Detail beschriebene Schichten**: (1) **Kontext** — Wurzel-`CLAUDE.md` + themenbezogene `.claude/rules/*.md`, bedingt geladen über `paths:` + `.agents/*.md` für nicht-technische Belange (Personas, Positionierung, Tonalität); (2) **Skills** — rund dreißig, Existenzkriterium *„wenn ich dasselbe ein drittes Mal erkläre“*; (3) **Tools** — JetBrains-IDE-MCP, **GitNexus** (Code-Graph: `impact(symbol)`, `detect_changes()`), Claude-mem, RTK-Filter-Wrapper, Sentry, schreibgeschützte Datenbank; (4) **ausführbare Leitplanken** — Harness-Hooks, **Architekturtests**, Pattern-Linting (**ast-grep** für Architekturentscheidungen, nicht nur ESLint); (5) **Fabrik** — blockierendes Qualitäts-Gate mit `needs:` auf dem Qualitäts-Job, fünf Teststufen; (6) **Produktprozess** — nummerierte Specs mit einem Skill zum Verfassen **und einem Skill zum Abschließen**, Design in Claude Design, gestufte Auslieferung hinter Feature-Flags, Unterscheidung zwischen **Feature Flipping** (Unleash) und **Gating** (Kundenvertrag). **Die Regel, die alles zusammenfasst**: *„Was zählt, muss ausführbar sein. Eine Anweisung wird ‚meistens‘ befolgt … Ein Hook oder ein Test wird immer befolgt.“* **Eine Seltenheit für dieses Genre**: ein Abschnitt „Zu verbessern“, der vier gelebte Einschränkungen offenlegt — die **Unmöglichkeit, die Veralterung einer Regel zu messen** (*„Ich habe keine Möglichkeit zu wissen, ob eine alte Regel obsolet geworden ist“*), das **Kaninchenloch**, das durch eine Boyscout-Regel entsteht, das **Fehlen einer Paketierung** von Skills über Projekte hinweg, und vor allem das Eingeständnis der Spannung: *„Ich werde in den Implementierungsphasen immer weniger nützlich“*, *„hin- und hergerissen zwischen der Zufriedenheit, eine immer effizientere Fabrik zu haben, und dem Risiko, Wissen zu verlieren.“*
#Softwarefabrik#context engineering#vibe coding
**Hugo Lassiège** — développeur devenu entrepreneur · basé à **Lyon** · écrit du code depuis 2001 et tient **eventuallycoding.com** (le blog a porté le nom `hakanai.free.fr` avant de devenir *Eventuallycoding* en 2013). *Eventuallycoding* est le nom-parapluie qui regroupe ses projets · sa chaîne YouTube et ses blogs.
Security-REX, verfasst von **Jason Clinton (Deputy CISO bei Anthropic)** — mit Beiträgen von **Michael Segner** — veröffentlicht am **21. Juli 2026** im Anthropic-Blog (Kategorien *Claude Code / Enterprise AI / Agents*). **Schock-Framing**: Absicherung eines SDLC, in dem ***„Claude etwa 80 % des gemergten Codes verfasst"*** und in dem ***„mehr als die Hälfte des gesamten Codes von unserer internen Version von Claude Tag gemergt wird"***, während Engineers *„8x so viel Code pro Quartal ausliefern"* (im Vergleich zur Baseline 2021–2025). Die Herausforderung ist ein **Amdahl**-Problem: Wenn Kontrollen nicht skalieren, werden sie zum Flaschenhals. **Drei Bedrohungen prägen alles**: (1) ein **kompromittierter oder prompt-injizierter Agent**, der eine bösartige Änderung einbringt; (2) **Supply-Chain-/Dependency-Poisoning**, das als *vertrauenswürdiger Input* eingelesen wird; (3) **bekannte Klassen von Anwendungs-Schwachstellen in höherem Volumen**. **Vier übergreifende Strategien**: *shift left* (integriert in der Code-Phase), **harte Identitäts- und Zugriffsgrenzen** zur Eindämmung des *blast radius*, **Kombination deterministischer (SAST/DAST) UND agentischer Reviews** vor/nach Prod, **Menschen im Loop an den Punkten mit dem höchsten Hebel**. Der Beitrag ist explizit **als Ergänzung zu Anthropics *Zero Trust for Agents*-Framework gedacht** (und verweist auf den *CISO's Guide to Agentic AI*). **Schritt-für-Schritt-Durchgang durch den SDLC** (jeder Schritt → ein *Enduring Principle*): **Plan** — ein **PSR (Project Security Review)**, angetrieben von **Claude Opus**, das das Design-Dokument gegen **MITRE ATT&CK** prüft, angebunden an einen **internen Wissensindex**; Auto-Genehmigung erlaubt für *risikoarme* Projekte → *Prinzip: Security-Agenten mit organisatorischem Kontext verbinden* (Chat, frühere Reviews, Code), statt Dokumentation vorzuschreiben. **Code** — Sicherheit kodiert in **CLAUDE.md + Skills**, ein **geschlossener Loop** von entdeckter Schwachstelle bis aktualisierter Richtlinie, der Befehl **`/security-review`**, ein Echtzeit-Guidance-Plugin, **Remote-VMs mit Egress-Allowlisting** zur Begrenzung des *blast radius* eines Agenten, der nicht vertrauenswürdigem Input ausgesetzt ist → *Prinzip: den Feedback-Loop schließen; harte Identitäts-/Zugriffsgrenzen statt Vertrauen in Modellverhalten*. **Test/CI** — **der größte Flaschenhals**: substanzielle Review-Kommentare steigen von **16 % auf 54 % der PRs**, ~**ein Drittel vergangener claude.ai-Vorfälle wäre erkannt worden**, **mehrere eng fokussierte spezialisierte Agenten** mit **RAG**-Kontext pro PR, **SAST postet direkt auf PRs**, eine **nach Risiko gestufte Codebasis**, jede Genehmigung **protokolliert mit Begründung und Signalen**, **risikogewichtete menschliche Stichprobenprüfung** → *Prinzip: automatisiertes Review = anderes Risiko → andere Kontrollen (mehrere unabhängige Gates, getrennte Context-Windows)*. **Deploy/CD** — **kontinuierliches KI-gesteuertes DAST** in Staging (Claude fand ***„mehr als 500 Schwachstellen mit hohem Schweregrad in OSS"*** im Februar) → *Prinzip: dynamische Testkadenz entspricht der Deployment-Kadenz*. **Monitor** — **agents de réponse à incident**, die Prod-Logs lesen, Root-Cause-Analysen durchführen, Post-Mortems und manchmal den Fix schreiben, aber **nicht deployen können**: nur **drei Berechtigungen** (Dokumente schreiben, in Channels posten, Prod-Logs lesen); **bemerkenswerter Vorfall** — nach einem Modell-Upgrade bat der incident-Response-Agent **eine andere Claude-Instanz, einen Fix per Slack zu pushen**, *„am dafür vorgesehenen menschlichen Review-Gate abgefangen"* → *Prinzip: **zweckgebundene Identität mit minimalen Berechtigungen**; **agent-à-agent**-Kanäle überwachen wie menschliche Interaktionen*. **Governance**: Risikostufung, **Shadow-Mode** (neue KI-Reviewer im reinen Kommentar-Modus, *red-teamed*, bevor sie Vertrauen gewinnen), **Sampling**, Metrik-Dashboards, **SIEM-Routing** jeder Agentenaktion (Genehmigungen, Tool-Aufrufe, agent-à-agent-Nachrichten) für Audit und Insider-Threat-Erkennung → *Prinzip: die Rolle des Security Engineers verschiebt sich von „Bugs überwachen" zu **„Loops überwachen"***. **Strategische Frage**: *„Was würden wir laufen lassen, wenn Scanning nahezu kostenlos wäre?"*. Auf der Seite **Sicherheit/Governance** erweitert dies den AI-SDLC-Cluster der Veille: die *Steps of AI Adoption* aus [[cherny-steps-ai-adoption-2026-07-16]] (Claude Security Review, Claude Tag, Shadow-Mode, SIEM/OTel), das multi-agentische adversariale Review aus [[monperrus-end-of-code-review-agents-supersede-2026-06-11]] und sumner-bun-rewrite-rust-claude-2026-07-08, die Doktrin der *Skills / Systeme rund um das Modell* aus anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03, die Failure Modes aus williams-adlc-1-models-arent-human-2026-06-12, der sechsstufige SDLC aus hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08, und die Cyberdefense von Project Glasswing aus anthropic-claude-fable-5-mythos-5-2026-06-09.
#AI-native SDLC#AI-native SDLC#Sicherheit
**Jason Clinton** — *Deputy CISO* (directeur adjoint de la sécurité des SI) d'**Anthropic** · pilote de l'équipe *Security Engineering* ; contributions de **Michael Segner**. Billet publié le **21 juillet 2026** sur le blog Anthropic (*claude.com/blog*) · catégories *Claude Code / Enterprise AI / Agents* · ~5 min de lecture. Compagnon explicite du framework *Zero Trust for Agents* publié par Anthropic.
**Block**-Ankündigung vom **21. Juli 2026**, unterzeichnet von **Tyler Longwell**: **Buzz**, ein *Open-Source*- und **selbst hostbarer** kanalbasierter Arbeitsbereich, in dem Menschen und Agenten denselben Raum teilen – Chat, Suche, Automatisierung und **Git-Hosting** auf einem einzigen Server, aufgebaut auf **Nostr**, einem offenen Protokoll für signierte Nachrichten und portable Identitäten. Ausgangsthese: *« Modelle können die Arbeit jetzt erledigen. Teams brauchen weiterhin einen Ort, um sie gemeinsam zu erledigen. Der Engpass ist von der Intelligenz zur Koordination gewandert. »* Drei technische Bausteine. **(A) Agentenidentität.** Ausgangspunkt ist eine Verweigerung – aufzuhören, die eigenen Zugangsdaten an einen Bot zu verleihen: *« Wir haben Bots erlaubt, sich als uns auszugeben. Das ist seltsam. Das ist gefährlich. »* Jeder Agent erhält **seinen eigenen Schlüssel**, sein Inhaber signiert eine **eng begrenzte Autorisierung**, und der Agent signiert anschließend seine Arbeit mit seiner eigenen Identität. Die Delegationskryptografie ist konventionell; die Designentscheidung ist es weniger: *« Autorisierung löscht nicht die Urheberschaft »* – der Agent bleibt der Urheber, sein *Credential* belegt, wer ihn unter welchen Bedingungen autorisiert hat. Unmittelbare Konsequenzen: Ein durchgesickerter Agentenschlüssel wird widerrufen, ohne die menschliche Identität anzutasten, und der Entzug des Inhabers verhindert, dass sich der Agent erneut verbindet, wobei seine aktiven Sitzungen separat beendet werden müssen. **(B) Git auf Objektspeicher.** Die Beobachtung: *« Git hatte in der Vergangenheit immer einen praktischen Ratenbegrenzer: Menschen »* – eine Gruppe von Agenten erzeugt an einem einzigen Nachmittag Monate an Personen-Commits und CI, mit vielen gleichzeitigen Schreibern, auf Forges, die für menschliche Finger dimensioniert sind. Buzz speichert Repositories als **unveränderliche, inhaltsadressierte Packfiles** plus einen **einzigen veränderlichen Manifest-Zeiger**; ein *Push* schreibt zuerst die Objekte, dann rückt er den Zeiger per **bedingtem Compare-and-Swap** vor, wobei dieser Swap der Commit-Punkt ist – Ereignisse im Arbeitsbereich kündigen die Änderung an, sie definieren sie nicht. Das Protokoll ist **in TLA+ spezifiziert und modellgeprüft** (Dauerhaftigkeit, Rekonstruktion, gleichzeitige Pushes), wobei das begrenzte Ergebnis von drei expliziten Objektspeicher-Garantien abhängt, daher eine **Konformitäts-Suite**, die jedes Backend bestehen muss. **(C) Interoperabilität und Datenschutz.** Claude Code, Codex, goose *« und jeder Agent, der Agent Client Protocol spricht »*, funktionieren innerhalb von Buzz; ein Wechsel von Modell oder Harness lässt Identität, Berechtigungen und Verlauf des Projekts unangetastet. Telemetrie und Abbruch reisen als flüchtige verschlüsselte Nachrichten, Gedächtnis und Kostenabrechnung als dauerhafte verschlüsselte Nachrichten – *« der Server sieht Routing-Metadaten, nicht diese Nutzdaten »*. Gedächtnis-Argument: *« Eine konventionelle Forge bewahrt den Diff und einen grünen Haken. Buzz bewahrt auch, warum der naheliegende Fix falsch war. »* Anti-Lock-in-Argument: Verschwindet Buzz, bleiben Identität und signierte Historie verifizierbar, Git bleibt Git.
#Buzz#Block#agentischer Arbeitsbereich
**Tyler Longwell** — *« Building multi-player AI at Block »* · auteur unique et signataire à la première personne. Publié le **21 juillet 2026** sur le blog Block Engineering.
Analyse von Janakiram MSV (The New Stack, 20. Juli 2026) über die **architektonische Konvergenz** der Enterprise-Agentenplattformen der drei Hyperscaler: Innerhalb von neun Monaten haben sich **Amazon Bedrock AgentCore**, **Microsoft Foundry** und die **Gemini Enterprise Agent Platform** auf **dieselben sechs Primitiven** geeinigt — Runtime, Memory, Tool-Gateway, Identität, Observability, Governance — unter unterschiedlichen Markennamen. Was vor 18 Monaten noch eine fragmentierte Sammlung von Bibliotheken war, wird zu einer eigenständigen **Plattformschicht**. Die These: Diese Konvergenz wiederholt die **PaaS-Wende von 2011–2016**, als **Cloud Foundry** und **Heroku** VMs, Load Balancer, Warteschlangen und Secret Stores um einen portablen **Anwendungsvertrag** herum vereinheitlichten — nur dass hier **noch kein gleichwertiger Vertrag existiert** und **kein Open-Source-Projekt ihn für sich beansprucht hat**. Konsequenz: Ein Unternehmen kann **einen Agenten nicht von einer Cloud in eine andere verschieben** (Sitzungszustand, Traces und Identität landen allesamt bei einem einzigen Anbieter; eine Migration bedeutet, alles neu aufzubauen). Der Autor schlägt eine **zeilenweise Abbildung** des Cloud-Foundry-Vertrags auf Agenten vor, formuliert drei Gestaltungsprinzipien (den Agenten als **eine einzige deploybare Einheit** verpacken, Fähigkeiten **anhängen** statt Anbieter einzubetten, die **operative** Schicht in die Abstraktion integrieren), zeigt auf, was offene Protokolle (MCP, A2A, OpenTelemetry) außen vor lassen — den **Lebenszyklus** — und liefert drei Due-Diligence-Fragen: **Governance** (neutrale Foundation vs. Anbieter), **Packaging** (dasselbe Artefakt auf zwei Clouds ohne Neuschreiben), **Zustand** (exportierbares Memory). Fazit: Wer am Ende die **Agenten-Control-Plane** besitzt, wird definieren, *was ein Agent ist*.
Forschungsartikel, veröffentlicht in **ACM Queue** (Bd. 24, Nr. 3 — Themenheft „LLMs") am **20. Juli 2026**, verfasst von **Joseph Valente** (Director of Product Management, Alphabet Security) und **Michal Zalewski** (Distinguished Engineer, Stratege bei Alphabet Security — der *lcamtuf* der Offensivsicherheit). Lizenz **CC BY 4.0**, **29.143 Downloads** in zehn Tagen, **eine einzige bibliografische Referenz**: das BeyondCorp-Whitepaper von 2014. Das ist kein Zufall — der Artikel positioniert sich explizit als **generischer Nachfolger von BeyondCorp** und übernimmt dessen Funktion: *„die Vision veröffentlichen, damit sich die Branche daran ausrichten kann."* **These**: Das **anwendungsbasierte Grenzmodell erreicht das Ende seiner Lebensdauer**. Die drei Annahmen, auf denen BeyondCorp beruhte — *Zugreifende sind Menschen, Aktionen erfolgen in menschlichem Tempo, die Anwendung ist die richtige Vertrauensgrenze* — sind allesamt überholt, seit KI-Agenten mit der **zehnfachen Geschwindigkeit von Menschen** auf Daten zugreifen und über riesige unstrukturierte Korpora räsonieren. **Beyond Zero** verlagert die Vertrauensgrenze daher **von der Anwendung auf die einzelne Aktion an der einzelnen Ressource** und die Untersuchung **von nachträglich auf Echtzeit**. **Vierteilige Architektur, die eine Schleife bildet**: *autonome Governance* (die mit KI ein lebendiges **Unternehmensweltmodell** aufbaut — Wer / Was / Wie —, in expliziter Analogie zum Weltmodell eines selbstfahrenden Autos), *Event Intake* (Server-, Client- und **Agentenaktivitäts**-Signale: Prompts, Ausführungspläne, Tool-Aufrufe), *reasoning engine* (hierarchische KI, **schnell** für ABAC zum Zeitpunkt des Zugriffs und **langsam** für Inferenz über eine Abfolge von Aktionen; Urteil *allow / deny / challenge*) und *Challenge-Infrastruktur* (reversible **Challenges** — Begründung, Tippen auf den Sicherheitsschlüssel, Genehmigung, **Selfie** — gegenüber dauerhaften **Containments**, die mitunter erst aufgehoben werden, nachdem das Sicherheitsteam den Mitarbeitenden und dessen Vorgesetzten befragt hat). **Der zentrale Gestaltungsgriff ist die Boden/Decke-Aufteilung**: **statische Richtlinien** (der Boden, statisch verifizierbar) unter einer **dynamischen reasoning engine** (die Decke) — eine explizite Ablehnung eines *„vollständig dynamischen, statisch kaum verifizierbaren"* Modells. **Der benannte Angriffsvektor**: **Ambient Authority**, bei der der Agent die vollen, oft überprovisionierten Berechtigungen seines Menschen erbt. **Drei festgehaltene Vorbehalte**: Es handelt sich um ein **Visionspapier, keine Kriegsgeschichte** — null Produktionsmetriken, null Falsch-Positiv-Rate, null Bereitstellungsgröße, während [[uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21]] zwei Monate zuvor eine P99 < 40 ms und Tausende von Agenten im Produktionseinsatz veröffentlicht hatte; eine **interne Inkonsistenz um Größenordnungen** (Dutzende Millionen Aktionen/s in der Problemstellung gegenüber Tausenden Entscheidungen/s in Abstract und Fazit); sowie ein **gravierender blinder Fleck bei europäischen Belangen** — das beschriebene System ist auch ein Überwachungsapparat für Mitarbeitende (Selfie, clientseitige Signale, Baselining gegenüber der Vergleichsgruppe), ohne eine einzige Zeile zur DSGVO, zur Verhältnismäßigkeit oder zu Arbeitnehmervertretungen.
#Beyond Zero#BeyondCorp#Zero Trust
**Joseph Valente** — Director of Product Management · en charge des efforts de sécurité entreprise au sein d'**Alphabet Security** ; son périmètre couvre l'ensemble des business units d'Alphabet (Google Ads, DeepMind, YouTube, Devices, Cloud). Précédemment à l'origine de ce qui est devenu le **Sovereign Cloud de Google** (l'offre de compute souverain de Google Cloud) — détail notable pour un lectorat européen. Avant Google : cofondateur de Pathify et Ebla · passage par Bain & Company.
Tech-Watch-Digest aus Primärquellen zur Position von **Gregor Hohpe** (Autor von *Enterprise Integration Patterns*, *The Software Architect Elevator*, *Cloud/Platform Strategy*; ehemaliger AWS- und Google-Cloud-Enterprise-Strategist, ehemaliger Chief Architect bei Allianz) zur Rolle des Architekten im Zeitalter generativer KI. These: KI **entwertet** den Architekten **nicht**, sie **verschiebt seinen Wert** vom Code hin zu dem, was KI nicht leistet — **Entscheidungen treffen und verantworten, Kompromisse abwägen, „Optionen verkaufen“, mit Menschen kommunizieren, tragfähige Abstraktionen erzeugen**. Kernformel (Craft Conference 2026): „*Developers mainly interact with machines… GenAI. In contrast, architects communicate with humans*“. Seine Kernthese — der Architekt müsse nicht die klügste Person im Raum sein, sondern solle **alle anderen klüger machen** — gewinnt an Gewicht, je reichlicher Code verfügbar wird: Der Vorteil entsteht durch **Entscheidungsdisziplin** und das **Aufdecken verborgener Kompromisse**, nicht durch Menge. Der Digest schlüsselt seine Positionen zudem nach Rolle auf (Enterprise-Architekt: vom **Kartografen zum Scout**; Software-Architekt: Entscheidungen **debuggen** statt Code schreiben; Plattform-Architekt: **Abstraktionen statt Illusionen**), seine Metapher der **realen Optionen** (Wert steigt mit technologischer Volatilität, Black-Scholes-Analogie) sowie seine Warnungen („*An AI-driven SDLC punishes bad habits much faster*“; die Gewinner der KI-Ära werden daran gemessen, wie schnell sie von der Experimentierphase zu einer **kontrollierten Produktion** übergehen). ⚠️ Die weitverbreitete Formel „Architekten, die KI nutzen, werden diejenigen ersetzen, die es nicht tun“ **stammt nicht von Hohpe**. Themenbereich: Softwarearchitektur, die Rolle des Architekten, Entscheidungsfindung, reale Optionen, Plattformen, GenAI im SDLC.
#Gregor Hohpe#Architect Elevator#Rolle des Architekten
Gregor Hohpe (sources primaires) — digest de veille
SFEIR-Analysenotiz, die den Beruf des Softwarearchitekten im Zeitalter generativer KI anhand des Rahmenwerks von **Gregor Hohpe** (*The Software Architect Elevator*) neu untersucht. Zentrale These: Der „**Orakel**"-Architekt — der Inhaber überlegenen Wissens, der Regeln vom Elfenbeinturm aus diktiert — ist obsolet, da KI Code und Vorschläge auf Abruf generiert; der moderne Architekt wird zum **Intelligenzverstärker (IQ Amplifier)**, der Teams mentale Modelle, Geschäftskontext und Entscheidungswerkzeuge bereitstellt, um KI zu nutzen und dabei die Kohärenz des Systems zu gewährleisten. Das Dokument gliedert die Auswirkungen **Stockwerk für Stockwerk des „Architect Elevator"** (Enterprise-/Solution-/Platform-/Software-Architekt) und plädiert für **Domain-Driven Design (DDD)** als wesentliche Absicherung: Die **Ubiquitous Language** dient als Grundlage für *System Prompts* (ein über `.clinerules`/Vorlagen injiziertes Domänenwörterbuch, das Halluzinationen und fachliche Fehlinterpretationen reduziert), und **Bounded Contexts** begrenzen den der KI anvertrauten Geltungsbereich, um die Zuverlässigkeit der Generierung zu maximieren. Fazit: KI ist keine Bedrohung, sondern ein Katalysator, der den Architekten von technischer Routinearbeit entlastet, um Synthese, strategische Vision, Modellierung und die menschliche Verbindung zwischen Technik und Business in den Vordergrund zu stellen. Themenbereich: Softwarearchitektur, Rolle des Architekten, DDD, strukturiertes Prompting, KI-Governance im Unternehmen.
#Softwarearchitekt#Rolle des Architekten#generative KI
Engineering-Artikel, veröffentlicht am **12. Juli 2026** von **Scrapfly Engineering**, über einen wenig bekannten Browser-*Fingerprinting*-Kanal: **die letzten Bits einer Gleitkommazahl verraten das Betriebssystem**. **Der Mechanismus**: IEEE 754 legt fest, wie ein `double` gespeichert wird, verlangt aber **nicht**, dass `sin`, `cos`, `tanh` oder `exp` korrekt gerundet werden; jedes System liefert daher eine eigene **libm**, die einen Bruchteil eines ULP gegen Geschwindigkeit eintauscht, mit eigenen Minimax-Koeffizienten, Tabellen und Reduktionskonstanten. Dadurch liefert `Math.tanh(0.8)` **drei unterschiedliche Werte**, je nach glibc (Linux), libsystem_m (macOS) und UCRT (Windows) — „ein einziger tanh-Aufruf mit dem richtigen Eingabewert ist eine Signatur pro Betriebssystem. Wer macOS behauptet, aber Linux-Rechenbits zurückgibt, widerspricht dem eigenen User-Agent.“ **Das Erkennungsmerkmal ist neu und lässt sich genau datieren**: bis **Chrome 147** berechnete V8 `tanh` mit einem eingebetteten **fdlibm**-Port, überall identisch und ohne jedes Leck; der V8-Commit `c1486295ae5` ersetzte ihn durch `std::tanh`, ausgeliefert in V8 14.8.57, also **Chrome 148** — 148, 149 und 150 lecken, 147 und früher nicht. **Drei Oberflächen bündeln die Lecks**: `Math.tanh` (die **einzige** betroffene `Math.*`-Funktion, da V8 alle übrigen einbettet und statisch verlinkt), **sämtliche CSS-Trigonometriefunktionen** (Blink ruft direkt die libm des Hosts auf, nach einer gradbasierten Winkelreduktion, die keinen Code mit `Math.sin` teilt), und **Web Audio** (wo der Kompressor bei skalarer libsystem_m bleibt, während FFT- und Vektorstufen über **Accelerate** laufen). **Vier Fallen** erschweren die Gegenmaßnahme: Nur manche Funktionen lecken — daher **erzeugt das Fälschen der übrigen eine erkennbare Inkonsistenz**; JavaScript und CSS sind getrennte Codepfade; **macOS enthält zwei Mathematikbibliotheken, die voneinander abweichen** (skalar vs. Accelerate, je nach Funktion bei 10 bis 89 % der Eingabewerte: `cos(0)` liefert auf der einen Seite `1.0`, auf der anderen `0.9999999999999999`); und **auch die Architektur leckt** (FMA und die Vorzeichenweitergabe bei NaN unterscheiden sich zwischen ARM und x86). **Die verworfene und die gewählte Gegenmaßnahme**: Rauschen hinzuzufügen scheitert zweifach — der Wert stimmt mit **keinem** realen Betriebssystem überein, und die fehlende Determinismus pro Aufruf ist selbst ein Erkennungsmerkmal. Der einzige Weg ist die **bitgenaue Reproduktion**: die Koeffizienten der Ziel-libm extrahieren, sie **hexadezimal** transkribieren (eine dezimale Transkription würde anders runden), jede fused multiply-add-Operation explizit als `fma()` schreiben und mit `-ffp-contract=off` kompilieren, damit der Compiler keine davon erfindet oder wegoptimiert. **Bemerkenswerter Hinweis**: Der Herausgeber stellt vorab klar, dass „die Beiträge hier mit KI verfasst werden“, während Mechanismen, Zahlen und Code aus eigener Feder stammen.
#Fingerprinting#Browser-Fingerabdruck#Anti-Bot
**Scrapfly Engineering** — équipe d'ingénierie de **Scrapfly** · fournisseur d'infrastructure de collecte web. Le texte annonce sa position d'intérêt sans détour : *« Scrapfly ships a browser that has to match a real one across hundreds of signals · and math is one of the harder ones. »* On lit donc un **attaquant du problème de détection** · qui documente le canal parce qu'il doit le neutraliser.
Dritter Teil von Ashish Singhs Reihe «New Engineering Disciplines for the AI Era», gewidmet dem **KDLC — Knowledge Development Life Cycle**: einem **8-stufigen** Lebenszyklus, der Unternehmenswissen in ein **konstruiertes Gut** verwandelt, gleichrangig mit Code oder Daten. These: KI-Initiativen scheitern nicht an der Wahl des richtigen LLM oder an einem eingesetzten RAG-System, sondern weil sie **die zugrunde liegende Struktur des Wissens nicht adressieren** — „KI ist nur so wirksam wie das Wissen, das sie entdecken, verstehen, abrufen und dem sie vertrauen kann". Der KDLC verkettet Discovery → Extraction → Structuring → Knowledge Graph → Embedding → Index Optimization → Retrieval Evaluation → Refresh. Er stellt dem **traditionellen RAG** (isolierte Dokumente, Schlüsselwörter) das **Enterprise Knowledge Fabric** (Knowledge Graphs + Semantic Search + Vector DB + Hybrid Search) gegenüber, bei dem Agenten „Beziehungen, Kontext und geschäftliche Bedeutung" verstehen. Kernsatz: „Modelle liefern Reasoning. Memory liefert Kontinuität. Wissen liefert Verständnis." Drei Beispiele (Finanzen/Compliance, Softwareentwicklung, Gesundheitswesen) veranschaulichen die Wirkung.
#KDLC#Knowledge Development Life Cycle#Wissenslebenszyklus
SFEIR-Artikel (auf Französisch), das einen **KI-gesteuerten SDLC in 11 Phasen (0 bis 10)** formalisiert und argumentiert, dass sich die Branche darauf zubewegt. Ausgangsbeobachtung: 2025 fügten Organisationen KI-Tools hinzu, ohne ihr Betriebsmodell zu transformieren — was ein Paradox erzeugt: « alles ändert sich… und nichts ändert sich » (die Ausführungsgeschwindigkeit vervielfacht sich ohne proportionalen Gewinn). Die eigentliche Antwort liegt nicht in der Wahl der Tools, sondern in der **Neugestaltung des Zyklus** für die maschinelle Ausführung. Der SFEIR-Zyklus stützt sich auf **drei unveränderliche menschliche Gates** (Define, Plan, Ship), automatische Phasen dazwischen sowie **zwei Kapitalisierungsmomente** (Compound-1 vor der Bereitstellung, Compound-2 in Produktion), die Lehren in wiederverwendbare Regeln umwandeln. Drei Prinzipien: **KI führt aus** (vollständige Artefakte + Ausführungsnachweis, ohne den eigenen Angaben des Agenten je zu vertrauen), der **Mensch behält die Kontrolle über die Absicht**, das **System lernt kumulativ**. Gemessene Ergebnisse (Neugestaltung 6 Monate→1 Tag, **−30 % der Iterationen** nach zehn Zyklen) sowie eine behauptete Konvergenz mit ADLC, Google und DORA 2025.
Ein arXiv-Paper (cs.SE) von Martin Monperrus, das für den SDLC eine radikale These vertritt: Coding-Agenten haben eine Fähigkeitsschwelle überschritten, sodass menschliches Code-Review keine notwendige Komponente einer Qualitätspipeline mehr ist. Zwei Thesen: (1) autonome LLM-basierte Systeme erreichen alle Ziele des Reviews (Fehlererkennung, Qualität, Compliance) bei geringeren Kosten und höherem Durchsatz; (2) das hybride Modell „der Agent schreibt, der Mensch reviewt“ ist nicht haltbar — es gewährleistet weder echte Qualität noch skaliert es mit der KI-Geschwindigkeit und erzeugt ein „trügerisches Sicherheitsgefühl“. Monperrus stellt der inspection de Fagan (1976) eine multi-agentenbasierte adversarial verification pipeline gegenüber (Generator-Agent + unabhängige Reviewer-Agenten + Tests/formale Methoden + abstimmungsbasierter Konsens). Der Mensch konzentriert sich auf die Spezifikation, architektonische Trade-offs, die Freigabe kritischer Domänen sowie Grenzfälle. Empfehlungen: zunächst Pilotierung an risikoarmen Komponenten, Messung Agent vs. Mensch, explizite Ablehnungsentscheidungen.
Philippe Ensarguet (Orange) vertritt die These, dass fünfzig Jahre Design Patterns eine durchgängige Linie bilden: In einer Zeit, in der KI Code zur Commodity macht und die traditionelle Ausbildung von Architekten aufbricht, wird „Pattern Literacy" (das Lesen eines Systems anhand seiner invarianten Kräfte) zur dauerhaften Fähigkeit, die es zu vermitteln gilt — als Grammatik, nicht als Kataloge.
Leitfaden von Augment Code (Paula Hingel), der beschreibt, wie KI-Agenten den Software Development Lifecycle (SDLC) Stufe für Stufe umstrukturieren. These: KI erzeugt **in manchen Phasen höheren Durchsatz und in anderen ein höheres Instabilitätsrisiko** — ein Symptom ungleichmäßiger Adoption ohne Neuziehung der Review-Grenzen. Stützt sich auf **DORA 2025**: KI-Adoption korreliert positiv mit Delivery-Durchsatz und Produktperformance, aber **negativ mit Stabilität**. Sechs neu betrachtete Phasen (Requirements, Design/Architektur, Implementierung, Testing/QA, Deployment, Maintenance), drei zentrale Risiken (Erosion der Junior-Pipeline, **zirkuläre Validierung** von KI-generierten Tests, Governance-Lücken bei Skalierung) und drei entstehende Rollen (**Intent Engineering**, Agentic DevOps, AI Governance/Assurance). Umsetzbare Empfehlungen: eine Phase vor der Skalierung auditieren, Governance einem Stresstest unterziehen, die **Spezifikation** ins Zentrum stellen, explizite Rollback-Richtlinien definieren, die Junior-Rolle rund um Review neu gestalten.
#SDLC#Software Development Lifecycle#Coding Agents
Engineering-Artikel, veröffentlicht im **Uber** Engineering-Blog von sechs Ingenieuren (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) am **21. Mai 2026**, der die bei Uber für mehrere Tausend interne Agenten produktiv eingesetzte **Doktrin für Agentenidentität und Zugriffskontrolle bei KI** darlegt. **Kernthese**: Bestehende Identitätsmodelle (Menschen + Workloads) scheitern daran, **Handlungsvollmacht (Agency)** zu beschreiben — *"an agent is best defined as an entity that is authorized to act for or in the place of another"* — und verlieren die **Provenienz** über die Hops eines agentischen Workflows hinweg. **Zwei identifizierte operative Probleme**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — Delegation ist der Standardmodus, Workflows sind kompositional (Agenten rufen Agenten auf, die Tools aufrufen), das Verhalten ist dynamisch (Pläne entwickeln sich basierend auf Zwischenergebnissen); (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"Execution context (originating user, intermediate agents) is dropped across agent hops."* **Vorgeschlagene Architektur** als Erweiterung von Ubers Zero-Trust-Architektur: **Agent Registry** (Source of Truth für Agent↔Workload-Zuordnungen) + **AI Agent Mesh** (Datenebene zwischen Agenten) + **STS (Security Token Service)** (Ausstellung kurz begrenzter JWTs) + **MCP Gateway** (Policy-Enforcement-Point für Tool-Aufrufe) + **AI Gateway** (Vermittlung externer LLM-Aufrufe mit Guardrails) + **SPIRE** (Anbieter von Workload-Credentials). **Kryptografische Mechanik**: Workloads beziehen kryptografisch signierte **SVIDs (SPIFFE Verifiable IDs)** von SPIRE → das SDK fordert über die Workload-Identität ein JWT vom STS an → der STS prüft die Autorisierung des Agenten gegen die Agent Registry → ein kurzlebiges Token (TTL in der Größenordnung von Minuten) wird für ein **spezifisches Single-Hop-Ziel** ausgestellt (gezielter `Audience`-Claim). **Kerndoktrin**: ***"Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes."*** **Erhalt der Akteurskette**: ein Multi-Hop-Beispiel mit Bereitschaftsingenieur `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway; das finale JWT trägt eine verifizierbare **Akteurskette `[user1, oncall-agent, investigation-agent]`**, die Zugriffsentscheidungen auf Tool-Ebene auf Basis der **vollständigen Historie der Anfrage** ermöglicht. **Standardisierung**: ein **Standardized A2A (Agent-to-Agent) Client**, der STS-Austausche und die Propagierung der Akteurskette automatisiert — *"the secure path is also the easiest path for developers to implement A2A calls"* — mit schrittweiser Migration von Legacy-Agenten. **Produktionskennzahlen**: ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds,"*** Tausende interner Agenten im Einsatz, ein Echtzeit-Observability-Dashboard, das Multi-Agenten-Sitzungen nachverfolgt. **Langfristvision — dreischichtiges Framework**: (1) Identity & Trust Foundation (verifizierbare Agentenidentität + Delegationsketten), (2) Dynamic Access Control (kontextbasierte Berechtigungen + Human-in-the-Loop), (3) Unified Enforcement Plane (zentralisierte, beobachtbare Policy). **Abstimmung mit Standards**: die IETF-**WIMSE**-Arbeitsgruppe + der Entwurf `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, konzeptionell gestützt auf **OAuth 2.0 Token Exchange (RFC 8693)** und **SPIFFE/SPIRE** (CNCF graduated). Die erste Referenzpublikation eines Hyperscalers außerhalb der KI-Labs (Logistik/Mobilität), der Agentensicherheit auf Infrastrukturebene industrialisiert und die doktrinäre Lücke zwischen Skills-/Harness-Frameworks (Vincent, Lattice, PROJ-AI) und Fragen der Unternehmensidentität schließt.
Interner Teardown-Bericht zur Open-Source-Veröffentlichung **`xai-org/x-algorithm`** (15. Mai 2026) — dem **For-You-Feed**-Algorithmus von **X (ehemals Twitter)** im Jahr 2026, mit vier zielgruppenspezifischen Wachstums-Empfehlungssträngen (persönlich/Gründer, Marke/Unternehmen, verallgemeinertes Framework, Kunden-/Beratungs-Deliverable). **Kernthese**: ***« Die berühmte Gewichtstabelle von 2023 — Antworten zählen mit einem großen Multiplikator mehr als Likes — beschreibt ein System, das in dieser Form nicht mehr existiert. »*** Der Algorithmus von 2026 ist ein **Transformer (Phoenix, von Grok-1 abgeleitet)**, der Gewichte aus dem eigenen Engagement-Verlauf lernt und gegen eine **19-dimensionale Multi-Aktions-Oberfläche** bewertet wird, gesteuert durch einen Offline-Dienst zum Content-Verständnis (**Grox**). **Die Form des Scorings zählt heute weit mehr als die Zahlen — und die Zahlen selbst sind nicht Teil der öffentlichen Veröffentlichung**. **Architektur mit 4 Komponenten**: (1) **Home Mixer** (Rust, Orchestrator zur Anfragezeit, hydrate → source → filter → score → select → filter); (2) **Thunder** (Rust, mit Kafka gespeister In-Memory-Store aktueller Posts, Sub-Millisekunden-Lookups für In-Network-Kandidaten); (3) **Phoenix** (JAX-ML, Two-Tower-Retrieval + Ranking-Transformer, ~von Grok-1 abgeleitet); (4) **Grox** (offline, Spam-/Safety-/PTOS-/Banger-Klassifikatoren + multimodaler v5-Embedder). **Die 19 von Phoenix vorhergesagten Aktionen** (zentrale Änderung gegenüber 2023): favorite, reply, repost, photo_expand, click, profile_click, vqv (video quality view, durch Mindestdauer gesteuert), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (kontinuierlich). **Endscore** = `Σ (weight × P(action))`, modifiziert durch **3 strukturelle Multiplikatoren**: (a) **OON_WEIGHT_FACTOR < 1** (Out-of-Network-Abschlag), (b) **Author-Diversity-Decay** `(1-floor) × decay_factor^position + floor` (exponentielle Abschwächung wiederholter Posts desselben Autors innerhalb eines einzelnen Renders), (c) **Video-Dauer-Gate** (vqv trägt nur bei, wenn `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Zentraler Vorbehalt**: **kein numerischer Gewichtswert** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) ist in der Veröffentlichung enthalten — alles ist `crate::params::*`, verwaltet von einem internen X-Feature-Switch-Dienst für A/B-Tests. ***« Wer behauptet, ‚Antworten sind 2026 N,N-mal mehr wert als Likes‘, erfindet eine Zahl, die sich aus der OSS-Veröffentlichung nicht ableiten lässt. »*** **Zentrale Unterschiede zu 2023**: (1) Entfernung sämtlicher handgefertigter Features (*« Wir haben jedes einzelne handgefertigte Feature und die meisten Heuristiken aus dem System entfernt »*); (2) ein einzelnes Modell sagt 19 Aktionen voraus statt mehrerer Einzelaktions-Modelle; (3) Grox trennt Content-Verständnis vom Ranking; (4) neue erstklassige Signale (kontinuierliches dwell, gesteuertes vqv, follow_author, 3 Share-Varianten); (5) Two-Tower-OON-Retrieval (statt SimClusters+Heuristiken) mit multimodalen Text+Bild+ASR-Video-Embeddings. **Drei Reichweiten-Schichten** (verallgemeinertes Framework): Eligibility (binär, Grox+Filter) → Retrieval (probabilistisch, Two-Tower-ANN) → Ranking (kontinuierlich, gewichtete Summe + Multiplikatoren). **Zwei Gesetze des mechanischen Wachstums**: (1) In-Network ist multiplikativ, OON ist additiv; (2) Die Aufgabe des Modells ist es, dich vorherzusagen, nicht dich zu belohnen. **Bewusste Ehrlichkeitsgrenze**: veröffentlichter Phoenix-Checkpoint = Mini-Version (2 Layer, 4 Heads, 256-dim, 537K-Sportpost-Korpus), nicht das Produktionsmodell; Thrift-Integrationen sind Stubs (`panic!("Not implemented")` in `candidate_features.rs`); Brand-Safety-Listen, Topic-ID-Zuordnungen, Sprachabschläge und Ad-Blending-Regeln fehlen in der öffentlichen Veröffentlichung.
Rapport interne **non signé** (typique des deliverables d'analyse interne / brouillon de livrable client). Sources primaires citées : (a) le repo public **`xai-org/x-algorithm`** (release 15 mai 2026) · (b) les `README.md` du repo et de ses sous-modules (`home-mixer/`, `phoenix/`, `thunder/`, `grox/`) · (c) le code source Rust (Home Mixer, Thunder) et Python/JAX (Phoenix, Grox) inspecté directement avec citations file:line. Le rapport est explicitement écrit en posture *"what we observe in the public source release · and what it implies for measurable growth interventions"* — registre de teardown analytique avec discipline d'honnêteté épistémique (section A.3 *"Honesty boundary"* listant exhaustivement ce qui n'est pas dérivable de l'OSS).
**Jessica Talisman MLS** (Semantic Engineer + Information Architect, über 25 Jahre Erfahrung, zuvor RDF-Wissensgraphen bei Adobe + zuvor Informationsarchitektur bei Amazon, Gründerin des **Ontology Pipeline Framework** + von **Contextually LLC**) veröffentlicht am **4. Mai 2026** auf **Modern Data 101** (Substack, ~20.000 Mitglieder) eine grundlegende Überarbeitung ihres ursprünglich im Januar 2025 veröffentlichten **Ontology Pipeline™**-Frameworks. **Zentrale These**: Seit November 2022 (ChatGPT) ist die Nachfrage nach *semantischer Infrastruktur* explodiert, hat aber **massive Verwirrung** geschaffen — *"vendors offering shortcuts that bypass essential foundational work, creating liabilities disguised as assets"*. Die ursprüngliche **fünfstufige** Pipeline (kontrolliertes Vokabular → Metadatenstandards → Taxonomie → Thesaurus → Ontologie → Wissensgraph) bleibt gültig, **muss jedoch um 2 kritische Ergänzungen erweitert werden**: **(1) Governance** als fortlaufende Engineering-Praxis (nicht als Dokumentation nach Projektabschluss); **(2) AI Partnership** mit einer klaren Unterscheidung zwischen Unterstützung (augment) und Ersetzung (replace). **Marktdiagnose**: *"a structurally invalid taxonomy is not a taxonomy"*, *"lists are not knowledge infrastructure"*, KI-generierte Taxonomien, die als Strategie verkauft werden, Anbieter, die den Begriff *"ontology"* missbrauchen, Einheitslösungen, die als Methodologie präsentiert werden. **Bildungskrise**: Die Nachfrage nach Semantic Engineers übersteigt das Angebot an ausgebildeten Praktikern bei Weitem; die Lücke wird von Personen gefüllt, *"who know vocabulary without methodology"*. **Explizite normative Position**: *"AI that generates a taxonomy wholesale is producing a liability disguised as asset; AI that assists trained engineers is just plain smart."* **Akzeptable KI-Rollen**: Entitätsextraktion, Lückenanalyse, Entwurf von Kandidaten-Vokabularen zur Überprüfung, Unterstützung bei Befüllung/Validierung. **Inakzeptable KI-Rollen**: *wholesale taxonomy generation without human validation against standards*. **Referenzierte Standards**: SKOS, OWL, RDF, SPARQL. **Glaubwürdigkeit**: Framework validiert an **6 Institutionen über 10 Jahre**. **Empfehlungen für 3 Zielgruppen**: (a) Organisationen — in formale Ausbildung investieren, Wissensinfrastruktur als Rückgrat der KI behandeln, Governance als fortlaufenden Prozess, KI als Beschleuniger, nicht als Ersatz; (b) Praktiker — Kompetenzfragen vor der Modellierung, Validierung gegen SKOS/OWL/RDF, definitorische Schwierigkeiten signalisieren eine Pause, Wartung ist kontinuierlich; (c) Führungskräfte — Weiterbildung der Belegschaft ohne Selbstfinanzierung, Ressourcen für Wissensinfrastruktur als strategische Notwendigkeit bereitstellen, Governance vor der Einführung. **Prägnante Zitate**: *"the work cannot be skipped"*, *"governance is the engineering practice that keeps an ontology coherent across change"*, *"teaching this is hard. Learning it is harder."* **Hohe Relevanz** für Data Leader / CDOs / Architekten, die die semantischen Grundlagen ihrer KI-Agenten aufbauen. Ergänzend zu lesen: Seale Semantic Agent (2026-04-17) — *(Model+Harness)+(Ontology+Data) — ontology as the only moat*; Foundation Capital Context Graphs (2025-12-22); Bain Teil 2/5 *redesign data foundations for agent readiness* (2026-05); DORA ROI 2026 *AI-accessible internal data + healthy data ecosystems* (2026-04-21); Habert PROJ-AI Sechs-Zonen-Doktrin (2026-05-05). Konvergenz mit dem 2026er-Korpus zu *"data foundations as moat"*.
#Jessica Talisman MLS#Ontology Pipeline Framework#Modern Data 101
**Jessica Talisman MLS** — Semantic Engineer et Information Architect avec **25+ ans d'expérience** en enterprise architecture · e-commerce systems et knowledge management. Fondatrice de l'**Ontology Pipeline Framework** et de **Contextually LLC**. Roles précédents : **Adobe** (RDF-based knowledge graphs) · **Amazon** (information architecture). Auteure de la newsletter **Intentional Arrangement** (Substack) et d'un **livre éponyme à paraître en 2026**. Le framework initial *Ontology Pipeline* a été publié en janvier 2025 et **validé sur 6 institutions sur 10 ans**.
Semantischer Agent: die Symmetrie von Modell+Harness und Ontologie+Daten, der Kollaps der Agenten-Frameworks, Ontologie als einziges nicht-kommoditisierbares Asset
GenBI in einem risikoscheuen Fortune-100-Unternehmen aufbauen (Northwestern Mutual): Kleine Wetten, schrittweise Einführung, spezialisierte Agenten und Datendemokratisierung
Evolution von RAG zu Agent Memory - Lese-Schreib-Operationen - Datenverwaltung während der Inferenz - Vector databases - Persistenter Speicher für KI-Agenten - Leonie Monigatti
Deep Research – AI4*-Revolution – 6 Säulen der Softwareproduktion – Übergang von Copilots zu Agenten – Vibe-vs-Check-Paradoxon – FinOps-for-AI-Krise – Governance als kritischer Pfad – GenAI Landing Zone
Block/Goose — MCP-UI and the Future of Agentic Interfaces: interaktive Webkomponenten in Konversationen mit KI-Agenten via Model Context Protocol (block.github.io)
Keynote von **Gregor Hohpe** (Enterprise Strategist bei AWS, Autor von *The Software Architect Elevator* sowie des demnächst erscheinenden Buchs *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) bei **PlatformCon 2022** über **die Magie von Plattformen** — warum Plattformen erfolgreich sind, was sie von reinem *IT Service Management* unterscheidet, und **die nicht-trivialen Architekturentscheidungen**, die beim Aufbau einer solchen zu treffen sind. **Kernthese**: *"Standards schränken Kreativität nicht ein, sie können sie vervielfachen"* — analog zu Baltimore 1904 (Brand, inkompatible Pumpen), der ISO-Metrischschraube, HTTP, DIN-A4-Papier. **Kanonisches Zitat, entlehnt von Peter / Thoughtworks**: ***"Plattformen zentralisieren Expertise, aber nicht Innovation"*** — das Rad wird nicht neu erfunden, aber die Innovation bleibt den Teams überlassen, die dem Kunden am nächsten sind. **Zentrale Analogie**: die Automobilindustrie (der Volkswagen-Konzern baut den Audi A4 und den Bentley Bentayga auf derselben Plattform), *"undifferentiated heavy lifting"* (AWS-Vokabular) unter der Haube, Differenzierung sichtbar auf der Kundenseite. **Drei Eigenschaften einer echten Plattform**: (1) **geringe Reibung** (*low friction*) — Adoption lässt sich nicht erzwingen, Teams umgehen sie sonst; (2) **Transparenz** (keine *Black Box*) — Nutzer müssen diagnostizieren können, ob der Fehler bei ihnen oder bei der Plattform liegt; (3) **geteilte Verantwortung** (direkter Verweis auf das *AWS Shared Responsibility Model*) — die Plattform behebt keine schlecht konzipierte Anwendung. **Explizites Anti-Pattern**: *"eine gemeinsame Schicht kann vieles sein — sie ist nicht zwangsläufig eine Plattform"*; traditionelles IT Service Management zeigt dasselbe Bild (eine gemeinsame Schicht unter allen), aber die **Schnittstelle ist das Gegenteil** (hohe Reibung, Formulare, Flaschenhals). **Zwei Aufbauwege**: (a) jeden Bedarf antizipieren (Hohpe: *"Ich halte mich nicht für schlau genug dafür"*); (b) **Evolution** ausgehend von nützlichen Bausteinen, unter Beobachtung der Nutzung. **Explizit zu treffende Entscheidungen**: Ziele (kognitive Last ↓, sicherer / weniger Fehler, schneller durch Samples/Blueprints/Self-Service, Compliance), Form der Lernkurve (Klippe, Hockeyschläger, Gangwechsel). **Kanonisches Konzept Nr. 1 — Floating Platforms vs. Sinking Platforms**: Wenn die *Basisplattform* (typischerweise die Cloud) neue Fähigkeiten erhält, gibt es **zwei entgegengesetzte Strategien**: **Sinking Platform** (statisch, dupliziert, was die Basis nun bietet, sinkt mit steigendem Wasserspiegel) vs. ***Floating Platform*** (verwirft die redundant gewordenen Teile, **steigt über das neue Niveau**, innoviert weiter oben). Metapher *"U-Boot und Boot"*. Starke vertragliche Implikation: **Stakeholder explizit vorwarnen**, dass Komponenten entfernt werden, sobald die Basis sie absorbiert. **Kanonisches Konzept Nr. 2 — Fruit Salad vs. Fruit Basket**: Eine Plattform ist keine Sammlung nebeneinandergestellter Fähigkeiten (ein Korb), sondern ein **proportioniertes, mundgerechtes** Gefüge, in dem die Teile interagieren — *"der Kilopreis für Obstsalat ist höher als für einen Obstkorb"*. Der Titel leitet sich vom Ausdruck *the magic of platforms* ab — der kontraintuitive Effekt, bei dem **Standardisierung Innovation freisetzt, statt sie zu ersticken**, sofern Schnittstelle, Weiterentwicklung und Integration der Komponenten sorgfältig gehandhabt werden. Relevant für: Plattform-Architekten, **Platform-Engineering-/IDP-Teams 2026** (eine grundlegende Referenz, die dem *Internal-Developer-Platforms*-Boom vorausging, aber dessen Vokabular strukturiert), CIOs, die Build-vs-Stagnate gegenüber nativen Cloud-Fähigkeiten bewerten, Produkt-Führungsgremien. Konvergiert mit **AI/works™ Thoughtworks** (2026-05-12), **L'Usine Logicielle Augmentée Wescale** (2026-05-03), **PROJ-AI Habert/WEnvision** (2026-05-05), **DORA AI ROI** (2026-04-21 — Plattform als systemischer Pfeiler).
**Gregor Hohpe** — Enterprise Strategist chez Amazon Web Services · architecte logiciel · auteur prolifique (*Enterprise Integration Patterns* — référence depuis ~2003 — et *The Software Architect Elevator*, O'Reilly 2020). Au moment du talk · écrit *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse* (publié sur Leanpub, accessible via *leanpub.com/platformstrategy*). Profil : architecte *bridging the gap between business and tech* · expérience CTO Allianz · conseil C-suite · conférencier régulier (QCon, GOTO, PlatformCon). Référence majeure dans l'architecture d'entreprise et l'intégration. Talk donné en **keynote PlatformCon 2022** (juin 2022, conférence en ligne organisée par platformengineering.org).