Interner Recherchebericht vom **12. August 2026** (im Format *What? — So What? — Now What?*, Untersuchung durchgeführt am 11.–12. August) zu einer einfachen Frage: Sind die **Desktop**-Anwendungen von ChatGPT und Claude besser als ihre **Web**-Versionen? Die Antwort kommt in zwei Teilen. **(A) Es existiert ein solider, gut belegter qualitativer Konsens.** Der Ausgangspunkt ist unbestreitbar: Desktop und Web rufen exakt dieselben Cloud-Modelle auf, die Anwendung ist lediglich eine Schnittstelle zum Dienst — der Gewinn liegt somit vollständig in der Application Shell (Zugriffslatenz, Stabilität bei langen Sitzungen, Speicherbedarf, Systemintegrationen, Workflow-Flüssigkeit). Was Desktop tatsächlich unterscheidet, bestätigt: auf OpenAI-Seite ein globaler Shortcut (Option/Alt + Space), ein *companion window*, das immer im Vordergrund bleibt, native Screenshots und seit Juli 2026 die agentische **Codex/Work**-Fähigkeit, die in die App integriert ist; auf Anthropic-Seite **Quick Entry** (macOS), **Desktop Extensions** (die Installation eines lokalen **MCP**-Servers wird *„so einfach wie ein Klick auf einen Button“*), Zugriff auf lokale Dateien, **Cowork** und **Computer Use** (Bedienungshilfen-Berechtigungen und Bildschirmaufzeichnung). Das Web behält zwei bestätigte Stärken: mehrere Tabs/Threads und Universalität ohne zu installierenden Client. **(B) Nahezu alle kursierenden Zahlen zur Stützung dieses Konsenses halten einer Überprüfung nicht stand.** Das kritische Audit des Berichts (§1.5) stuft sieben weitverbreitete numerische Behauptungen als **unbestätigt** ein: der *Kaltstart* „2–3 s vs. 8–12 s“ (die einzige Spur ist ein anekdotisches *„lädt in etwa 3 Sekunden“* auf Substack); RAM-Nutzung „200–700 MB vs. 1,2–2 GB“, zugeschrieben einem „Alibaba Product Insights“, dessen Seiten **404** zurückgeben; eine nicht nachvollziehbare Glitch-Rate und eine ebenso nicht nachvollziehbare Zahl zur Sitzungsbindung; ein Claude „+10–20 %“ End-to-End, zugeschrieben **Skywork**, das in Wahrheit seinen eigenen Windows-Agenten und nicht Claude gegen das Web gebenchmarkt hatte; eine nicht nachvollziehbare Quelle „Cosmo Edge“; unbestätigte Zitate von Zenken AI; sowie zwei nicht authentifizierte X-Posts ohne URL. Das Gegensignal ist mit derselben Sorgfalt dokumentiert: Yuri Dvoinos beschreibt eine Claude-Desktop-App, die *„mich dazu bringt, meinen Laptop aus dem Fenster werfen zu wollen“* — 68 % CPU-Auslastung, Eingabeverzögerung auf einem MacBook Pro — und der Bericht vermerkt, dass beide Apps **Electron**-Builds mit nativen Schichten sind. Daher seine Formulierung: *der Desktop-Vorteil ist ein Implementierungsversprechen, kein Naturgesetz.* **Das „So What“**: Da das Modell zum gemeinsamen Nenner geworden ist, wird die Schnittstelle zum Schlachtfeld — die Fusion **Codex + ChatGPT** vom 9. Juli 2026 und das Tandem Cowork/Computer Use erzählen dieselbe Geschichte: *„die Desktop-App ist kein Chat-Client mehr, sondern eine Agenten-Laufzeitumgebung mit Zugriff auf die Maschine.“* Drei Konsequenzen: Der Gewinn ist ein **Reibungs**-Gewinn, kein Leistungsgewinn; für einen CIO **verschiebt** Desktop die **Vertrauensgrenze** — Computer Use erfordert sensible Systemberechtigungen, und die Codex-Fusion bringt Codeausführung, Browser und Konnektoren in *„eine erweiterte Vertrauensgrenze“*, während der Browser über SSO, DLP und CASB weiterhin steuerbar bleibt; und für jeden, der publiziert, ist die Zerbrechlichkeit der Zahlen selbst die Geschichte. **Das „Now What“** liefert individuelle Umstiegskriterien, eine CIO-Checkliste (Berechtigungen inventarisieren, Computer Use und Cowork standardmäßig deaktivieren, festlegen, welche MCP-Erweiterungen autorisiert sind, Verteilung und Updates organisieren — unter Linux, außerhalb des apt-Repositorys, aktualisiert sich Claude Desktop nicht selbst) sowie eine redaktionelle Vorgabe: nur bestätigte Verbatims und Daten zitieren.
#ChatGPT Desktop#Claude Desktop#Web-Version
**Deep Research Veille Interne** — rapport non signé · produit par une enquête sourcée menée les **11-12 août 2026** et rendu le 12.
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).
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.
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*.
Blogbeitrag von **Pasquale Pillitteri** (Softwareingenieur, Palermo), veröffentlicht am **29. Mai 2026** (FR-Version), 18 Minuten Lesezeit, Rubrik *Claude Code & Anthropic*. **Kernthese**: *« Claude Opus 4.8 ist das leistungsstärkste SEO-Modell des Jahres 2026, aber fast alle nutzen es falsch »* — kein Modellproblem, sondern ein **System**-Problem. Die goldene Regel: ***« Strategie ist ein Whiteboard, Produktion ist ein Fließband »*** — SEO muss **in zwei getrennte Phasen aufgeteilt werden**, und deren Vermischung ist *« der schnellste Weg, ein Modell zu verschwenden, das fünf Dollar pro Million Input-Token und fünfundzwanzig für Output kostet »*. **Modellkontext**: Opus 4.8 veröffentlicht am **28. Mai 2026** (41 Tage nach Opus 4.7), **1-Mio.-Token**-Kontext, **GraphWalks Long-Context F1 bei 1M: 40,3 % → 68,1 %**, **SWE-bench Verified 88,6 %**, **USAMO 2026 96,7 %** (+27,4 Punkte), **HLE with tool 57,9 %**, unveränderter Preis **5 $/25 $** pro Mio. Token, **Fast Mode 2,5× zu 10 $/50 $**, vier **Aufwandsstufen** (Low, High, Extra, Max). **Das zentrale Anti-Pattern** = *« das riesige Gespräch »* / **Context Drift**: die Vermischung von Strategie, Keyword-Recherche, Wettbewerbsanalyse und Texterstellung in einem einzigen Chat erzeugt einen *« Brei widersprüchlicher Absichten »* → das Modell driftet zu **generischen Best Practices** („holistic optimization“, „strategic approach“) statt zu datenverankerten Inhalten. **Phase 1 – Strategie (Whiteboard, visuelle UI, einmalig)**: Dashboard / Google Sheet / Claude.ai-Canvas, um gemeinsam anhand der Daten zu entscheiden. **3 Spielzüge**: (a) **klassifizierte Keyword-Recherche** (Tabelle mit Volumen / Schwierigkeit 0-100 / Intent / Geschäftspotenzial / Priorität = Volumen÷Schwierigkeit×Geschäftsgewichtung); (b) **visuelle Wettbewerbsanalyse** (Themenabdeckungs-Matrix, Lücken); (c) **phasenweise Roadmap** (Quick Wins M1-2 / mittelfristig M3-6 / Pillar-Seiten M7-12). Der **Extra/Max**-Modus ist hier gerechtfertigt (*« eine richtige strategische Entscheidung ist tausend gut geschriebene Seiten zu den falschen Keywords wert »*). 3 abgeschlossene Artefakte, gespeichert in Notion/Drive. **Phase 2 – Produktion (Fließband, Opus 4.8 + MCP)**: Das Modell wandelt sich vom Strategen zur **Ausführungsmaschine**; jede Entscheidung wird über das **Model Context Protocol** in **Live-Daten verankert**. **Minimaler MCP-Stack**: **GSC MCP** (AminForou/mcp-gsc, 500+ Stars), **offizieller Ahrefs MCP** (98 Stars), **GA4 MCP**; das Repo `modelcontextprotocol/servers` = **86.440 Stars**, **10.000+ aktive Server**, 97 Mio. SDK-Downloads/Monat. Setup ~35 Min., monatliches Refresh ~20 Min. **Wöchentliche Schleife**: ein einziger Prompt zieht Live-Daten, erstellt das Brief (Top-10-SERP + GSC + Ahrefs), leitet H2/H3 ab, schreibt, prüft die Dichte, schlägt Titel vor → **+45 % Produktivität**, Entwurf in **6-12 Min.** (expliziter Verweis auf **Ryan Law / Ahrefs Content Engineering**, 23 Skills). Erwähnt Anthropics **Dynamic Workflows** (bis zu 1.000 Subagenten). **4 häufige Fehler**: (1) die Zahlen nicht zu überprüfen (Stichprobenkontrolle verpflichtend, *trust & verify*); (2) Semrush/Ahrefs vollständig zu ersetzen (MCP ist eine **zusätzliche Schicht**, kein Ersatz); (3) die **Paid-Organic-Content-Lücke** zu ignorieren (Kundenfall aus dem Bildungsbereich: **2.742 verschwendete Begriffe / 351 Chancen** in 90 s identifiziert); (4) Opus 4.8 dort einzusetzen, wo **Haiku 4.5** ausreicht (Meta-Beschreibungen, Alt-Texte). **Kosten**: 1-3 $ pro Artikel mit 2.500 Wörtern. **Sonnet 4.6** genügt für die laufende Produktion, Opus 4.8 bleibt der Strategie vorbehalten. SEO-optimierter und selbstreferenzieller Artikel (der Autor schreibt über SEO in einem Inhalt, der selbst darauf ausgelegt ist, für „Opus 4.8 SEO“ zu ranken). Direkte Konvergenz mit **Ryan Law/Ahrefs** (zitiert), **Systemen rund um das Modell** (Dropbox/Okumura), **Skills-over-Prompts** (Lattice), Haiku/Sonnet/Opus-Modell-Routing (Gupta Token-to-Outcome).
#Claude Opus 4.8#KI-SEO#Zweiphasen-Workflow
**Pasquale Pillitteri** — Ingénieur informatique / développeur logiciel basé à **Palerme** (Italie) · certifié Innovation Manager UNI 11814:2021. Auteur d'un blog tech actif (rubrique *Claude Code & Anthropic*) · avec une newsletter hebdomadaire (~3,4k lecteurs). Article publié en version **FR** le **29 mai 2026** (lendemain de la sortie d'Opus 4.8).
Beitrag aus dem **Ahrefs-Blog**, veröffentlicht am **28. April 2026** von **Ryan Law** (Director of Content Marketing, Ahrefs), der ein internes **Content-Engineering**-System rund um **Claude Code** beschreibt: eine redaktionelle Pipeline, die **publikationsreife Entwürfe in 6 bis 12 Minuten** erzeugt. **Kernthese**: ***« AI content is not, by default, good. This process works well because it mirrors our existing human editorial process »*** — Qualität entsteht nicht durch das Modell, sondern durch die **getreue Nachbildung eines menschlichen Redaktionsprozesses**, der sich über Jahrzehnte bewährt hat. Architektur: **~23 skill files**, jede entspricht einem redaktionellen Schritt (Keyword-Recherche, Themenlücken-Analyse, strukturelle Gliederung, Recherche-Zusammenstellung, Entwurfserstellung, Formatierung), **orchestriert von einem übergeordneten Skill `blog-pipeline`**, der sie verkettet, um einen vollständigen Artikel zu erzeugen. **Sieben Gestaltungsprinzipien**: (1) **menschliche Arbeitsabläufe nachahmen**, indem Skills aus vorhandener Ahrefs-Redaktionsdokumentation abgeleitet und verkettet werden; (2) **jeden Schritt einzeln ausgeben** zur Fehlersuche (*« if you get an article at the end of a ten minute run, and it's bad, it's hard to diagnose precisely where and why the process went wrong »* → Zwischenergebnisse speichern); (3) **Testfälle erstellen** über Anthropics Skill `skill-creator`, um Anweisungen zu bewerten und zu verbessern; (4) **hochwertige Datenquellen einbinden** — den **Ahrefs MCP** (Keyword-Metriken, Parent Topic, Long-Tail-Themen, SERP-Übersichten, Wettbewerbsanalyse), Wettbewerbsanalysen und Produktdokumentation; (5) **menschliche Vorgaben vorab einbringen** über Kontextparameter, die redaktionelle Steuerung ermöglichen; (6) **interaktive Vorschauen** im HTML-Format zur Prüfung vor der Veröffentlichung erstellen; (7) **Anpassung erlauben** (jedes Teammitglied kann das System forken und modifizieren). **Umfang**: ~**15 veröffentlichte Artikel** und ~**30 aktualisierte Artikel** über diesen Workflow; die Entwicklung begann im **Februar 2026** (der vorherige Prozess vom **August 2025** benötigte mehrere Tage und manuelle Eingriffe). **Explizite Vorbehalte** (Anti-Übertreibung): *« experience matters »* — der Prozess spiegelt jahrzehntelange redaktionelle Expertise wider; die Themenauswahl konzentriert sich auf **informationelle SEO-Inhalte**, die der Autor gut kennt; Ahrefs **plant kein „Scaling“ der Inhalte im großen Stil**, sondern pflegt eine **evergreen** Bibliothek. Philosophie: *« the formulaic parts of work »* automatisieren, um Routinearbeit zu eliminieren und Zeit für Recherche, Thought Leadership, Webinare und Systemoptimierung freizusetzen — **nicht** menschliche Arbeit ersetzen. Als kanonische Referenz von Pasquale Pillitteri zitiert (*Opus 4.8 SEO workflow*) als Feldbeweis für den Gewinn von „6-12 min/Entwurf“. Direkte Konvergenz mit der Doktrin **skills-over-prompts** (Lattice, PROJ-AI), **Systeme rund um das Modell** (Dropbox/Okumura) und der Verwendung von **HTML als Review-Artefakt** (Shihipar).
**Ryan Law** — Director of Content Marketing chez **Ahrefs**. Praticien senior du content marketing SEO ; le billet est un retour d'expérience personnel (*« How I do… »*) publié sur le **blog Ahrefs** (ahrefs.com/blog) le **28 avril 2026**.
Block/Goose — MCP-UI and the Future of Agentic Interfaces: interaktive Webkomponenten in Konversationen mit KI-Agenten via Model Context Protocol (block.github.io)
Weiterverbreitung der MIT-NANDA-Studie "The GenAI Divide: State of AI in Business 2025" durch Legal.io: 95 % der Unternehmens-KI-Pilotprojekte erzielen trotz Investitionen von 30-40 Mrd. USD keinen messbaren ROI. Konzept der "GenAI Divide", der "Schatten-KI-Ökonomie", vier strukturelle Ausfallfaktoren, Empfehlung für Back-Office und Build-vs-Buy. Empirische Begründung für den personalwirtschaftlich-organisatorischen Wandel.
#MIT NANDA#GenAI Divide#95 % Scheitern der Pilotprojekte
Legal.io (relais et synthèse) — étude MIT NANDA "The GenAI Divide: State of AI in Business 2025"