Kategorie: Erklärer

Stell dir vor, du entwickelst eine Webanwendung. Früher war das überschaubar: Code schreiben, auf einen Server schieben, fertig. Heute siehst du dich einem Dschungel aus Kubernetes-Clustern, CI/CD-Pipelines, Observability-Stacks und Sicherheitsrichtlinien gegenüber. Und jetzt kommen auch KI-Agenten dazu, die selbstständig Ressourcen provisionieren, Incidents untersuchen oder Deployments durchführen. Was bedeutet das für die Plattformen, auf denen deine Software läuft? Der Entwickler Lakmal Warusawithana von WSO2 beschreibt in einem aktuellen Beitrag, wie sich Platform Engineering ändern muss, um sowohl Menschen als auch KI-Agenten als Nutzer zu integrieren.

Platform Engineering hat sich in den letzten Jahren rasant entwickelt. Als Unternehmen auf Kubernetes, Microservices und GitOps setzten, wuchs die Komplexität so stark, dass einzelne Entwicklerteams nicht mehr alle Aspekte beherrschen konnten. Jede Anwendung brauchte Deployment-Pipelines, Infrastruktur, Netzwerk, Sicherheit, Monitoring und Compliance. Statt jedes Team das Rad neu erfinden zu lassen, entstanden Internal Developer Platforms (IDPs). Diese Plattformen kapselten Best Practices hinter standardisierten Workflows, Self-Service-Funktionen und Golden Paths. Entwickler konnten sich auf die Geschäftslogik konzentrieren, während die Plattform zuverlässig Deployment, Sicherheit und Betrieb übernahm. Das Modell war erfolgreich – aber es basierte auf einer Annahme: Der Hauptnutzer der Plattform ist ein menschlicher Entwickler.

Diese Annahme gilt nicht mehr. Im Agentic Enterprise werden KI-Agenten zu Konsumenten der Plattform – Seite an Seite mit Ingenieuren. Sie provisionieren Infrastruktur, deployen Anwendungen, analysieren Telemetriedaten, führen operative Workflows aus und automatisieren Aufgaben, die früher menschliches Eingreifen erforderten. Die Plattform muss jetzt beides bedienen: Menschen und intelligente Software. Jeder Actor interagiert über seine eigene Schnittstelle – ein Entwickler über ein Portal, ein SRE über die Kommandozeile oder GitOps, ein KI-Agent über einen MCP-Server – aber alle Handlungen müssen denselben Sicherheitskontrollen, Richtlinien und Prüfpfaden unterliegen.

Die neue Dreifaltigkeit: Anwendungen, Ressourcen und KI-Agenten

Bisher drehte sich in Internal Developer Platforms alles um die Anwendung. Infrastruktur existierte darunter, CI/CD-Pipelines um sie herum, Observability-Systeme überwachten sie. Alles diente dazu, die Bereitstellung und den Betrieb von Anwendungen zu vereinfachen. Im Agentic Enterprise sind Anwendungen jedoch nicht mehr die einzigen erstklassigen Entitäten. Ja, sie bleiben zentral: Sie implementieren Geschäftslogik, exponieren APIs, verarbeiten Events. Aber daneben treten zwei weitere Kategorien von Software-Assets.

Ressourcen liefern die Fähigkeiten, die Anwendungen erst möglich machen: Datenbanken, Message Queues, Object Storage, KI-Modelle, Identity Provider, Secrets, Kubernetes-Cluster, SaaS-Dienste. Früher galten sie als bloße Infrastruktur oder externe Abhängigkeiten. Heute werden sie zu erstklassigen Software-Assets mit eigenem Lebenszyklus, eigener Governance, Betriebshistorie und Sicherheitsanforderungen. KI-Agenten wiederum sind eine grundlegend andere Art von Software-Akteuren. Statt direkt Geschäftsfunktionen zu implementieren, reasoning sie über Kontext, rufen Werkzeuge auf, arbeiten mit Menschen und anderen Agenten zusammen und automatisieren operative Tätigkeiten. Sie interagieren mit genau denselben Ressourcen wie menschliche Entwickler.

Der entscheidende Punkt: Diese drei Entitäten sind nicht unabhängig. Anwendungen konsumieren Ressourcen, um Geschäftsfunktionen zu liefern. KI-Agenten konsumieren viele derselben Ressourcen, um das System zu verstehen und zu betreiben. Sie interagieren auch mit Anwendungen, während Anwendungen selbst Fähigkeiten exponieren, die KI-Agenten aufrufen können. Ressourcen werden so zur gemeinsamen Grundlage, die Anwendungen und KI-Agenten im Softwarebestand des Unternehmens verbindet. Für Platform Engineering bedeutet das: Statt einzelne Komponenten zu verwalten, geht es jetzt darum, die Beziehungen zwischen ihnen zu managen. Die Plattform muss verstehen, wie Abhängigkeiten aussehen, wie Änderungen durch das System propagieren und wie sowohl Menschen als auch KI-Agenten sicher damit interagieren können.

Kontext wird zur neuen Plattformfähigkeit

Wenn Software zu einem Netzwerk aus Anwendungen, Ressourcen und KI-Agenten wird, reicht es nicht mehr, nur die Assets selbst zu verwalten. Platform Engineering muss auch die Zusammenhänge verstehen. Herkömmliche Observability-Plattformen sammeln bereits Unmengen operativer Daten: Logs, Metriken, Traces, Events. Diese Signale sind essenziell, aber sie sind beschreibend. Sie sagen, was passiert ist, aber selten, warum es passiert ist oder wie ein Ereignis mit einem anderen zusammenhängt. Erfahrene Ingenieure kombinieren bei einer Fehlersuche ganz natürlich Deployment-Historie, Verantwortlichkeiten, Topologie, Abhängigkeiten, Richtlinien, frühere Incidents und organisatorisches Wissen. Sie nutzen Kontext, nicht isolierte Datenpunkte.

KI-Agenten brauchen genau dieselbe Fähigkeit. Ein Agent, der einen fehlgeschlagenen Deployment untersucht, benötigt mehr als Logs. Er muss wissen: Welche Anwendung ist betroffen? Von welchen Ressourcen hängt sie ab? Was hat sich kürzlich geändert? Wer ist verantwortlich? Welche Richtlinien gelten? Gab es ähnliche Vorfälle? Welche Lösungen haben damals funktioniert? Ohne diesen breiteren Kontext bleibt selbst das leistungsfähigste KI-Modell auf das Reasoning über zusammenhanglose Beobachtungen beschränkt.

Deshalb wird Kontext zu einer erstklassigen Plattformfähigkeit. Moderne Plattformen müssen ein gemeinsames Verständnis des gesamten Softwarebestands aufbauen und pflegen. Dieses Verständnis verbindet Anwendungen, Ressourcen, KI-Agenten, Deployments, Eigentümer, Richtlinien, Topologie, Betriebshistorie und organisatorisches Wissen in einem kohärenten Modell – über das sowohl Menschen als auch KI-Agenten reasoning können. Statt durch getrennte Dashboards und APIs zu navigieren, arbeiten alle Plattformkonsumenten mit derselben kontextuellen Repräsentation des Systems.

Ist die Plattform erst einmal kontextbewusst, kann sie dieses Wissen über die jeweils passenden Schnittstellen exponieren. Menschen greifen über Portale, CLIs oder Dashboards darauf zu, KI-Agenten konsumieren denselben Kontext über Protokolle wie das Model Context Protocol (MCP). Die Interfaces unterscheiden sich, aber sie bilden dasselbe zugrundeliegende Verständnis der Plattform ab. Diese kontextuelle Grundlage ermöglicht auch reichhaltigere Fähigkeiten: Wiederverwendbare Skills kapseln typische Ingenieuraufgaben, die sowohl von Menschen als auch von KI-Agenten aufgerufen werden können. Spezialisierte Built-in Agents übernehmen Aufgaben wie Site Reliability Engineering, Sicherheitsüberwachung oder Compliance-Prüfung.

Was das konkret bedeutet

Die Entwicklung ist kein Hype, sondern eine logische Konsequenz. Wenn KI-Agenten produktiv in Unternehmen eingesetzt werden sollen, müssen sie dieselbe operative Intelligenz besitzen wie ein erfahrener Ingenieur. Dafür brauchen sie nicht nur Zugang zu APIs, sondern ein gemeinsames kontextuelles Fundament. Platform Engineering entwickelt sich weiter: von einer Plattform, die nur für Menschen gemacht ist, zu einer Plattform, die Menschen und KI gleichermaßen als erstklassige Konsumenten behandelt. Unternehmen, die diesen Wandel frühzeitig gestalten, werden ihre Softwarebestände effizienter, sicherer und zukunftsfähiger betreiben können. Entwickler und Plattformingenieure sollten ihre Plattformen als Ökosysteme betrachten, in denen menschliche und maschinelle Akteure zusammenarbeiten – nicht als Werkzeug, das nur einem von beiden dient.

Quelle: cncf.io

Du unterhältst dich mit einem Experten zu einem Thema. Du stellst eine Frage und bekommst eine gute Antwort. Dann stellst du eine verwandte Frage, und plötzlich taucht ein anderer Name auf. Der Experte wechselt seine Meinung von Prompt zu Prompt. Genau das passiert mit Marken in ChatGPT. Semrush und Kevin Indig haben 1.094 Themengebiete in ChatGPT analysiert – über 50.000 Marken, 220.000 Domains und 600.000 Zitate. Ergebnis: Sichtbarkeit in KI-Suchen ist kein Keyword-Spiel mehr. Es ist ein Thema-Spiel. Und die meisten Felder sind noch offen.

Die Studie definiert ein Thema als Cluster aus fünf repräsentativen Prompts, die einen typischen Kaufentscheidungsprozess abbilden: Definition, Vergleich, Alternativen, Anwendungsfall und Kaufentscheidung. Wer in mindestens vier dieser fünf Prompts genannt wird und dabei einen Vorsprung von fünf Prozentpunkten gegenüber dem Zweitplatzierten hat, gilt als „Category Owner“. Ein „Emerging Leader“ wird in drei Prompts genannt, aber ohne den nötigen Abstand. Bei über der Hälfte der Themen ist nicht einmal das der Fall – kein Name taucht in drei der fünf Prompts auf.

Das hat handfeste Konsequenzen für jedes Unternehmen, das darauf angewiesen ist, dass Kunden es in KI-Suchumgebungen finden. Wer nur auf einzelne Prompts optimiert, verpasst die eigentliche Dynamik. Wer ein Thema besetzt, kann eine stabile Position aufbauen, die sich nur schwer wieder verlieren lässt – aber nur, wenn der Vorsprung groß genug ist. Die drei wichtigsten Erkenntnisse aus der Studie:

1. Die meisten Themen sind noch zu haben

Nur 15,2 Prozent der analysierten 1.094 Kategorien haben einen klaren Gewinner. In den restlichen fast 85 Prozent ist das Rennen offen. 31,2 Prozent haben einen aufstrebenden Anführer, der aber noch nicht dominant genug ist. 53,7 Prozent sind völlig unentschieden – kein Unternehmen schafft es, in drei der fünf Prompts genannt zu werden. Anders als bei Google, wo große Suchvolumina meist von starken Marken dominiert werden, zeigt sich in ChatGPT ein umgekehrter Effekt: Die populärsten Themen – die, nach denen am häufigsten gefragt wird – sind am wenigsten von einer einzelnen Marke besetzt. Nur 11,3 Prozent der meistgefragten Themen haben einen klaren Eigentümer, während es bei den weniger gefragten 19 Prozent sind. Die meistgefragten Themen machen 98 Prozent des gesamten KI-Suchvolumens in der Studie aus. Fast jede Frage, die ein Nutzer in ChatGPT stellt, landet in einem Themengebiet ohne dominierenden Anbieter.

KI-Modelle entscheiden anders als klassische Suchmaschinen. Sie gewichten nicht nur Backlinks und Domain-Autorität, sondern auch semantische Passgenauigkeit und Quellenvielfalt. Wer in einem Themenbereich breit aufgestellt ist, hat bessere Chancen, auch bei verwandten Fragen genannt zu werden – und genau das tun die meisten Marken noch nicht. Sie konzentrieren sich auf ein oder zwei starke Prompts und vernachlässigen die anderen drei. Das reicht nicht, um als „die“ Antwort für ein Thema zu gelten.

Du kannst jetzt noch einsteigen. Warte nicht, bis die großen Player die Themen besetzt haben. Die meisten Kategorien sind noch kein befestigtes Feld. Wer früh systematisch in ein Thema investiert, kann sich einen schwer einholbaren Vorsprung erarbeiten.

2. Klassische SEO-Kennzahlen sagen wenig über den Gewinner aus

Man könnte meinen, dass Marken mit starker Suchmaschinenoptimierung auch in KI-Suchen dominieren. Schließlich haben sie hohe organische Besucherzahlen, eine starke Markensuche und eine gute Domain-Autorität. Die Studie hat die Werte der Category Owner mit denen der Zweitplatzierten auf drei Metriken verglichen – Markensuchvolumen, organischer Traffic und Authority Score. Ergebnis: Nur die Markensuche war ein statistisch signifikanter Unterschied, und selbst dieser Vorsprung war bescheiden. Die Eigentümer hatten in 55,7 Prozent der Fälle ein höheres Markensuchvolumen als der Zweitplatzierte. Beim organischen Traffic lag der Wert bei 48,4 Prozent – die Zweitplatzierten hatten also häufiger mehr Traffic. Beim Authority Score waren es 52,5 Prozent – quasi Münzwurf. Starke SEO-Signale allein reichen nicht, um in einem KI-Thema zu gewinnen.

Kevin Indig, der die Studie mitentwickelt hat, sagt: „Behandle das als Hypothese, nicht als Ergebnis. Die Daten zeigen, dass traditionelle SEO-Metriken nicht ausreichen, um zu erklären, wer ein Thema besitzt. Sie spielen eine Rolle, aber es steckt mehr dahinter.“ Offenbar entscheiden andere Faktoren – die Tiefe der Inhalte, die Anzahl relevanter Erwähnungen in Quellen wie Reddit, Fachpublikationen oder Bewertungsportalen – und die Verknüpfung der Marke mit dem Thema durch strukturierte Daten und konsistente Nennungen. Es geht nicht um viele generische Backlinks, sondern um Sichtbarkeit im Kontext des Themas.

Höre auf, deine SEO-Erfolge blind auf KI-Suchen zu übertragen. Eine gute Position in Google ist kein Freifahrtschein für ChatGPT. Du musst zusätzlich in themenspezifische Signale investieren: Erstelle Inhalte, die alle Facetten eines Themas abdecken, nicht nur die eine Frage, bei der du schon rankst. Sammle Erwähnungen auf Plattformen, die ChatGPT als Quellen nutzt. Sorge dafür, dass deine Marke in strukturierten Daten und der Berichterstattung konsistent mit dem Thema verknüpft wird.

3. Wer ein Thema besitzt, hält es – wenn der Vorsprung groß genug ist

Die Studie hat die Entwicklung der Category Owner über sechs Monate verfolgt (Januar bis Juni 2026). Klare Eigentümer mit einem Vorsprung von mindestens fünf Prozentpunkten blieben in 90,4 Prozent der Monatsvergleiche an der Spitze. Bei den aufstrebenden Anführern und unentschiedenen Kategorien wechselte die Spitzenposition deutlich häufiger – in 1.950 von 5.470 Vergleichen. Der Unterschied im Median-Vorsprung: In Kategorien, in denen der Leader abgelöst wurde, betrug der Vorsprung im Vormonat im Median nur 1,3 Prozentpunkte. In Kategorien, in denen er sich hielt, waren es 2,9 Prozentpunkte. Die Schwelle, ab der ein Vorsprung stabil wird, scheint zwischen drei und fünf Prozentpunkten zu liegen.

Warum kommt es zu Wechseln? Die Studie kann keine kausalen Gründe nennen – vielleicht ändert ChatGPT seine Quellen, vielleicht verschiebt sich die Relevanz einer Marke durch neue Produkte oder Krisen, vielleicht passt das Modell seine Gewichtung an. Das Muster ist klar: Ein knapper Vorsprung ist keine Sicherheit. Wer nur hauchdünn führt, muss weiter in das Thema investieren, sonst wird er schnell überholt. Wenn du als Herausforderer in einem Thema unterwegs bist, in dem der aktuelle Leader nur einen schmalen Vorsprung hat, ist jetzt der beste Zeitpunkt zum Angriff. Sobald er sich einen komfortablen Abstand erarbeitet hat, wird es deutlich schwerer, ihn zu verdrängen.

Wachstum allein ist nicht gleich Sicherheit. Wenn du in einem Thema führst, höre nicht auf, Inhalte und Signale aufzubauen. Wenn du aufholen willst, konzentriere dich auf Themen, in denen der Vorsprung des Leaders klein ist, und versuche, dich in allen fünf Prompts breit zu positionieren. Am Ende zählt nicht eine einzelne Nennung, sondern die konsistente Präsenz über das gesamte Themenfeld hinweg.

So beginnst du, auf Themenebene zu gewinnen

Die Studie liefert einen praktischen Fahrplan mit vier Schritten. Erstens: Identifiziere die thematischen Bereiche, die für dein Geschäft relevant sind. Frage dich nicht, welche Keywords wichtig sind, sondern welche Fragen deine Kunden in der Kaufentscheidung stellen. Die Antworten auf diese Fragen sind deine Themen. Zweitens: Analysiere deine aktuelle thematische Autorität. Tools wie der Semrush AI Visibility Toolkit zeigen dir, in welchen Themen du bereits genannt wirst, wo deine Autorität dünn ist und wo Konkurrenten vorne liegen. Drittens: Fokussiere dich. Versuche nicht, gleichzeitig in fünfzehn Themen stark zu sein. Wähle zwei oder drei aus, bei denen du bereits eine gewisse Basis hast – bestehende Inhalte, echte Produktrelevanz, erste Erwähnungen. Dort investierst du systematisch. Viertens: Baue deine thematische Autorität auf. Drei Hebel wirken zusammen: umfassende Inhalte, die alle relevanten Fragen abdecken; Erwähnungen in Quellen, die ChatGPT nutzt (Foren, Fachmedien, Bewertungsseiten); und starke Entity-Signale wie strukturierte Daten, konsistente Markennennungen und Verlinkungen, die deine Marke mit dem Thema verbinden.

Das ist viel Arbeit. Aber die Daten zeigen: Wer früh anfängt und kontinuierlich arbeitet, kann sich eine Position aufbauen, die Bestand hat. In einer Welt, in der KI-Suchen immer wichtiger werden und 85 Prozent der Themen noch kein klares Gesicht haben, ist das eine lohnende Investition. Es geht nicht mehr darum, auf eine einzelne Frage die beste Antwort zu geben. Es geht darum, dass Kunden dich wiedererkennen, egal welche verwandte Frage sie als Nächstes stellen. Das ist der Unterschied zwischen einem einmaligen Treffer und einer echten Markenpräsenz im KI-Zeitalter.

Quelle: semrush.com

Du willst die aktuellen Preise einer Bohrmaschine vergleichen. Du öffnest die Website, aber statt der Produktdaten erscheinen CAPTCHAs, Proxy-Fehler und 403-Antworten. Für Unternehmen, Hedgefonds oder KI-Agenten ist das Alltag: Das öffentliche Web steckt voller Daten, aber Anti-Bot-Systeme versperren den Zugang. String bietet eine Infrastruktur, die das Web für Maschinen zugänglich macht – ohne dass jemand Proxy-Listen verwalten oder Browser-Fingerprints fälschen muss.

Stell dir das Web als eine riesige, schlecht sortierte Bibliothek vor. Jedes Buch (jede Webseite) ist vorhanden, aber viele stehen hinter verschlossenen Glastüren – die Betreiber blockieren automatisierte Zugriffe. Bisherige Lösungen erforderten Eigenbau: rotierende Proxys, wechselnde User-Agents, Headless-Browser, Retry-Logik. Trotzdem scheiterte es an dynamischem JavaScript oder Cloudflare-Challenges. String übernimmt diesen Kampf. Das Unternehmen öffnet die Tür – schnell und sauber, ohne dass der Nutzer den Schlüssel selbst schmieden muss.

Im Kern bietet String eine schlanke REST-API: Du sendest eine URL, bekommst den Inhalt als Markdown oder strukturierte Daten zurück. Simpel, aber die Magie liegt im Unsichtbaren. Die API rendert JavaScript-Seiten, umgeht Anti-Bot-Systeme, optimiert Netzwerkpfade und liefert Ergebnisse in unter zwei Sekunden – selbst auf hart verteidigten Seiten wie lowes.com oder lululemon.com. In einem öffentlichen Benchmark gegen 13 Anbieter erzielte String eine Erfolgsquote von 97,4 Prozent, weit vor dem Zweitplatzierten mit 79 Prozent. Das ist kein Marketing-Hype, sondern ein messbarer Vorsprung.

Wie String funktioniert – und warum es anders ist

Die Architektur von String lässt sich als Web Data Infrastructure beschreiben. Anders als einfache Scraper, die nur eine Seite holen, versteht String das gesamte Ökosystem einer Website. Die drei Hauptmodule heißen Fetch, Search und Map.

• Fetch: Du gibst eine URL an, String lädt die Seite, führt JavaScript aus, extrahiert den relevanten Inhalt und gibt ihn als strukturiertes Markdown zurück. Das ist der Kern – ein Ersatz für den eigenen, mühsamen Scraping-Code.
• Search: Statt nur eine Seite zu holen, kannst du eine Suchanfrage über das Web stellen. String durchsucht das Internet in Echtzeit und liefert dir saubere, token-effiziente Ergebnisse. Nützlich für Anwendungen, die aktuelle Informationen brauchen – etwa Preisvergleiche oder News-Monitoring.
• Map: Hier wird es interessant für die Tiefenanalyse. Du reichst eine Start-URL ein, und String crawlt die gesamte Site, erstellt eine vollständige URL-Graph-Liste, inklusive Sitemaps, interner Links und Seitenstruktur. Das ist die Basis für umfassende Datensammlungen – etwa alle Produkte eines Shops mit Kategorien und Preisen.

Ein besonderes Feature ist der Composer, der sich noch in der Beta-Phase befindet. Stell dir vor, du sagst einfach: „Gib mir alle Laufschuhe von Nike mit Preisen, die täglich aktualisiert werden.“ String baut daraus eine vollautomatische Pipeline – von der Datenquelle bis zum Warehouse. Das ist der nächste Schritt: Web Scraping per Prompt, ohne eine Zeile Code schreiben zu müssen.

Benchmark: Warum 97,4 Prozent Erfolgsquote ein Gamechanger sind

Im Web Data Frontier Benchmark, einem offenen Vergleichstest, schickte String 265 Anfragen an 53 schwierige Zielseiten – darunter stark geschützte E-Commerce-Seiten, dynamische Social-Media-Feeds und staatliche Portale. Das Ergebnis: String holte in 97,4 Prozent der Fälle die erwarteten Daten. Der nächste Konkurrent schaffte lediglich 79 Prozent. Fehlschläge waren meist schnelle Fehlermeldungen (z.B. 403), aber String lieferte, wo andere aufgaben. Die durchschnittliche Latenz lag bei unter 1,2 Sekunden für die schwierigsten Ziele. Bedenke: Ein schneller Fehlschlag nützt nichts – Erfolg zählt.

Diese Zuverlässigkeit ist kein Zufall, sondern das Ergebnis gezielter Investitionen in Anti-Bot-Umgehung. String setzt auf eine Kombination aus Proxy-Pools, nativen Browser-Fingerprints und maschinellem Lernen, um das Verhalten eines echten Users zu imitieren, ohne die Latenz zu opfern. Für Unternehmen, die täglich Millionen von Datenpunkten sammeln, bedeutet das: Weniger Ausfälle, weniger manuelles Debugging und höhere Datenqualität.

Integration für Entwickler und Vibe-Coder

String macht keine halbe Sachen bei der Bedienbarkeit. Entwickler können die API in jeder Sprache nutzen – ein simpler POST-Request mit einem JSON-Body reicht. Für Agenten wie Claude oder ChatGPT gibt es einen MCP-Server (Model Context Protocol). Du fügst einen Eintrag in deine claude_desktop_config.json ein, und schon kann der KI-Assistent live auf jede Webseite zugreifen, ohne sich mit Blockaden herumzuschlagen.

Das Unternehmen nennt das Built for coders and vibe coders. Damit ist gemeint: Ob du komplexe Pipelines in Python schreibst oder deinem KI-Agenten einfach per Prompt den Befehl gibst – String liefert die Daten. Wer das klassische Scraping kennt, weiß, wie erfrischend das ist. Statt eines 50-zeiligen Scripts mit Retry-Logik, Proxy-Rotation und Exception-Handling reichen vier Zeilen Code:

import requests
r = requests.post("https://request.usestring.ai/v1/fetch",
    headers={"Authorization": "Bearer sk_live_…"},
    json={"url": "https://lowes.com/c/drills", "format": "markdown"})
print(r.text)

Das war’s. Kein manuelles Laden von Proxys, kein Headless-Browser, kein Warten auf Timeouts.

Anwendungen in der Praxis: Hedgefonds und Marktdaten

String zählt zu seinen Kunden sechs der zehn größten Hedgefonds, mehrere Unicorn-Startups und zwei der fünf größten Asset Manager. Was machen die damit? Ein Beispiel: Ein Hedgefonds beobachtet täglich die Preise von Gebrauchtwagen auf einer großen Plattform, um Inflationstrends zu prognostizieren. Vor String musste ein Team von drei Ingenieuren die Scraper warten – jetzt reicht eine API-Integration. Die Datenqualität ist so hoch, dass laut einem Kunden die täglichen Preisänderungen von Aktien wie $CVNA beeinflusst werden.

Andere nutzen String für SEC-Filings, Immobiliendaten, Telekommunikations-Verfügbarkeiten oder Einzelhandels-Promotions. In jedem Fall geht es darum, das öffentliche Web systematisch und zuverlässig in eine strukturierte Datenquelle zu verwandeln – ohne sich mit den Launen von Anti-Bot-Systemen herumzuärgern.

Einordnung: Was String für die KI-Zukunft bedeutet

Wenn KI-Agenten wie Claude, ChatGPT oder Cursor in Zukunft eigenständig das Web durchsuchen sollen, um Fragen zu beantworten oder Aufgaben zu erledigen, brauchen sie einen zuverlässigen Zugang. Die aktuellen Modelle stoßen schnell an Grenzen, wenn sie auf CAPTCHAs, dynamisches JavaScript oder IP-Blacklists treffen. String fungiert hier als Brücke: Das Unternehmen stellt die Infrastruktur bereit, die den Agenten den Zugriff auf das öffentliche Web ermöglicht, ohne dass sie selbst die Hürden überwinden müssen. Das ist ein zentraler Baustein für das Versprechen von Agentic AI – also KI, die selbstständig im Web handeln kann.

Gleichzeitig zeigt der Erfolg von String, wie sehr der Markt nach einer professionellen Lösung lechzt. Web Scraping war lange eine Bastelei: Ein Mix aus Open-Source-Bibliotheken, Cloud-Diensten und manuellen Workarounds. String professionalisiert diesen Bereich durch eine API, die sowohl für Entwickler als auch für Entscheider einfach verständlich ist. Das Unternehmen wird von renommierten Investoren wie Flex Capital, Zapier und Auren Hoffman unterstützt – ein Zeichen dafür, dass die Idee nicht nur technisch überzeugt, sondern auch geschäftlich.

Bleibt die Frage: Ist das der heilige Gral des Web Scrapings? Nein, es gibt immer noch Seiten mit extrem aggressivem Schutz oder solche, die dynamische Captchas pro Session einsetzen. String selbst gibt zu, dass 2,6 Prozent der Anfragen scheitern. Aber für den Rest des Webs – und das ist der überwältigende Teil – bietet String eine solide, messbar bessere Lösung. Für jeden, der regelmäßig Daten aus dem Web braucht, ob für Analysen, KI-Training oder Preisüberwachung, ist das ein Sprung nach vorn. Die Ära des selbst gebastelten Proxy-Bingo geht langsam zu Ende. String macht das Web für Maschinen zugänglich – und das ist genau die Infrastruktur, die wir für die vernetzte KI-Welt brauchen.

Quelle: usestring.ai

Drei Kollegen fragst du nach dem Umsatz des letzten Quartals. Einer schaut in eine Excel-Tabelle, ein anderer öffnet ein Dashboard, der dritte nutzt einen Chat-Bot. Du bekommst drei verschiedene Zahlen. Jeder hat eine andere Definition verwendet – vielleicht hat einer die Rabatte abgezogen, ein anderer nicht, einer hat nur bestimmte Regionen einbezogen. Dieses Szenario ist kein Einzelfall, es ist Alltag in vielen datengetriebenen Unternehmen. Sobald Menschen oder Tools unterschiedliche Verständnisse von „Umsatz“ haben, entsteht Chaos. Cube packt das Problem an der Wurzel: mit einer semantischen Schicht, die als gemeinsame Sprachbasis für alle Datenabfragen dient.

Die Grundidee ist einfach: Bevor du eine Frage an deine Daten stellst, legst du fest, was die Begriffe bedeuten. Cube nennt das ein semantisches Modell. Es funktioniert wie ein gemeinsames Wörterbuch: „Umsatz“ ist definiert als Nettoumsatz ohne Steuern und Rabatte, berechnet aus der Tabelle „orders“. Sobald dieses Modell steht, kann jedes Tool – Dashboard, Chat-Bot, Workbook oder eine externe KI wie ChatGPT – darauf zugreifen. Die Antworten sind identisch, weil sie auf derselben Definition beruhen. Das ist der Kern von Cube: eine einzige semantische Grundlage für jede Analyseoberfläche.

Warum eine semantische Schicht heute unverzichtbar ist

Wir leben in einer Welt, in der große Sprachmodelle wie ChatGPT oder Claude verbreitet sind. Sie verstehen Fragen in natürlicher Sprache und generieren daraus komplexe Datenabfragen. Aber sie kennen die firmenspezifischen Definitionen nicht. Sagst du einem LLM „Zeig mir den Umsatz der letzten Woche“, schätzt es, welche Spalten und Tabellen gemeint sind. Das Ergebnis ist oft ungenau oder falsch. Cube löst das, indem es dem LLM die semantische Schicht als Karte mitgibt. Der Chat-Bot bekommt nicht die rohen Datenbanken, sondern das bereinigte Modell. So wird aus einem Ratespiel eine präzise Abfrage. Das ist der Unterschied zwischen „Ich verstehe die Frage nicht“ und „Hier ist die korrekte Antwort mit Chart und Erklärung“.

Der Nutzen ist Konsistenz. Wenn dein Dashboard, dein Analyst und dein KI-Assistent dieselbe Frage stellen, bekommen sie dieselbe Antwort. Das schafft Vertrauen in die Daten. Und es reduziert den Aufwand. Statt für jede Abfrage eine eigene SQL-Query zu schreiben oder Definitionen in verschiedenen Tools zu pflegen, definierst du alles einmal im semantischen Modell. Cube nennt das „Governance flows from your model through to your customers‘ permissions“. Die Zugriffsrechte und Berechnungslogiken werden aus dem Modell direkt in die Analyseoberfläche durchgereicht – egal ob der Kunde ein internes Dashboard oder eine eingebettete Analytics-Funktion in einer SaaS-Anwendung nutzt.

Cube in der Praxis: Embedded Analytics und Multi-Tenancy

Ein Einsatzgebiet ist die eingebettete Analytik. Unternehmen wie Brex, Webflow oder Intuit binden Cube in ihre eigenen Produkte ein, sodass deren Kunden Analysen sehen können. Cube ist von Grund auf multi-tenant-fähig: Jeder Kunde bekommt nur die Daten und Definitionen, die für ihn freigegeben sind. Die semantische Schicht stellt sicher, dass die Berechnungen für alle Mieter korrekt sind, aber die Ergebnisse getrennt bleiben. Das ist für SaaS-Anbieter wertvoll – sie müssen sich nicht um die Governance jedes einzelnen Kunden kümmern, Cube erledigt das automatisch.

Brex hat sich bewusst für Cube entschieden – und gegen Alternativen wie dbt Semantic Layer oder LookML. Der Grund: Cube bietet eine native KI-Schnittstelle, die direkt auf dem semantischen Modell aufsetzt. Die LLMs werden so zu zuverlässigen Assistenten, die nicht nur Daten abrufen, sondern auch Zusammenhänge erklären können. Drata, ein Compliance-Unternehmen, berichtet, dass Cube zur „Single Source of Truth“ für Metrikdefinitionen geworden ist – CSMs sparen dadurch Dutzende von Stunden pro Quartal, die sie sonst für manuelle Datenaufbereitung aufgewendet hätten. Webflow lobt die Integration mit ClickHouse als Datenbank: Cube abstrahiert die Datenbankkomplexität, sodass Teams auf die Daten zugreifen können, ohne SQL-Schreibkenntnisse zu besitzen. Alcon hebt hervor, dass Cube die Anzahl der benötigten Queries deutlich reduziert – eine einzige Definition ersetzt 20 verschiedene Abfragen für dieselbe Metrik.

Die Analogie: Cube wie eine Stadtkarte für deine Daten

Denken Sie sich Ihr Unternehmen als eine große Stadt. Es gibt viele Stadtteile (Teams, Abteilungen), jeder mit eigenen Straßennamen und Adressen (Datenquellen und Tabellen). Fragt jemand nach dem Weg zum Hauptbahnhof („Wie hoch ist der Nettogewinn?“), bekommt er je nach Stadtteil eine andere Route. Cube ist die zentrale Karte, die eindeutige Straßennamen definiert. Egal, ob du im Norden oder Süden bist – du weißt, wo der Hauptbahnhof liegt. Du erhältst dieselbe Beschreibung. So wird aus einer chaotischen Ansammlung von Daten eine geordnete, verständliche Landschaft, in der sich jeder zurechtfindet – Mensch und Maschine gleichermaßen.

Cube bietet verschiedene Oberflächen, um auf diese Karte zuzugreifen. Der Analytics Chat arbeitet mit natürlicher Sprache: Du tippst eine Frage auf Deutsch, Cube übersetzt sie über die semantische Schicht in eine präzise Abfrage und zeigt das Ergebnis. Es gibt vorgefertigte iframes für Dashboards und Chats, die du schnell in deine App einbetten kannst. Der Creator Mode erlaubt es Nutzern, eigene Workbooks und Dashboards zu bauen – immer basierend auf dem zentralen Modell. Für Entwickler gibt es die Core Data APIs, die umfassende Kontrolle auf Datenebene bieten. Cube passt sich an deine Branding-Vorgaben an – deine Farben, dein Logo, dein Agentenname –, sodass die Analyseoberfläche als nahtloser Teil deiner Anwendung wirkt.

Warum Cube für die Zukunft der Datenanalyse relevant ist

Der Trend geht zu mehr KI in der Datenanalyse. KI ist nur so gut wie die Daten, die sie bekommt. Cube liefert die notwendige Struktur, damit LLMs nicht nur raten, sondern fundierte Antworten geben. Die semantische Schicht wird zum wichtigen Differenzierungsmerkmal: Wer sie hat, kann KI vertrauen; wer sie nicht hat, hat es mit inkonsistenten Ergebnissen und aufwändigen manuellen Korrekturen zu tun. Cube ist die Plattform, die diesen Schritt ermöglicht – nicht nur für große Konzerne, sondern auch für wachsende SaaS-Unternehmen, die ihren Kunden professionelle Analysefunktionen anbieten wollen.

Was bedeutet das konkret für dich? Wenn du Datenanalyse betreibst oder eine Anwendung entwickelst, die Daten auswertet, solltest du über eine semantische Schicht nachdenken. Cube zeigt, dass es möglich ist, eine einheitliche Definitionsbasis zu schaffen, die klassische BI-Tools und moderne KI-Assistenten bedient. Die Zukunft der Berichterstattung liegt nicht in statischen Charts, sondern in dynamischen, kontextbezogenen Einsichten – Cube liefert das Fundament dafür. Ob du intern deine Teams mit konsistenten Dashboards versorgst oder extern deinen Kunden eine vertrauenswürdige analytische Erfahrung bieten möchtest: Die semantische Schicht ist entscheidend. Cube hat das verstanden und setzt es um – ohne Hype, mit solidem Engineering und einem klaren Fokus auf Governance und Skalierbarkeit.

Quelle: cube.dev

Sie arbeiten in einem Unternehmen und nutzen einen KI-Assistenten mit Zugriff auf alle internen Dokumente. Sie fragen nach Kundenabwanderung. Der Assistent gibt eine kluge Antwort – Zahlen, Zusammenhänge, eine flüssige Erklärung. Doch wenn Sie nach der Quelle fragen, wird es vage. Der Assistent zitiert Passagen, aber gehören sie wirklich zusammen? Stammen sie aus demselben Bericht oder aus verschiedenen Kontexten? Dieses Gefühl der Unsicherheit ist kein Zufall. Viele Unternehmen erleben das mit KI-Agenten: plausible Antworten, aber keinen verlässlichen, nachvollziehbaren Kontext. Genau hier setzt eine Überlegung an, die über typische RAG-Ansätze hinausgeht.

Wenn der Agent Fakten vermischt

Amarnath Byakod beschreibt in seinem Artikel „Context Engineering and Knowledge Cataloging for AI Agents“ ein Experiment. Sein Team ließ einen Agenten aus klinischen Dokumenten Informationen abrufen. Das System fand semantisch ähnliche Textstellen und setzte sie zu einer Antwort zusammen. Auf den ersten Blick sah alles gut aus. Bei genauerer Prüfung zeigte sich: Der Agent hatte Daten von verschiedenen Patienten zu einem einzigen, erfundenen klinischen Profil vermischt. Die Antwort war sprachlich korrekt, aber fachlich falsch. Byakod zieht eine klare Schlussfolgerung: „Das ist kein Retrieval-Problem. Es ist ein Knowledge-Catalog-Problem.“ Es bringt wenig, wenn ein Agent beliebige Textfragmente findet, solange er nicht versteht, was sie bedeuten, wie sie zusammenhängen und ob sie gemeinsam verwendet werden dürfen.

Dieses Problem betrifft nicht nur die Medizin. Es ist relevant, wo immer Unternehmen KI-Agenten zur Entscheidungsunterstützung einsetzen: Finanzanalyse, Kundenbetreuung, Supply-Chain-Planung. Die meisten Initiativen beginnen mit dem Zugang. Teams verbinden den Agenten mit SharePoint, Confluence, Datenbanken oder APIs. Sie fügen Embeddings und Retrieval hinzu und testen, ob der Agent Fragen beantworten kann. Oft entsteht der Eindruck, der Agent verstehe das Unternehmen. In Wirklichkeit sind Zugang und Verständnis zwei verschiedene Dinge. Ein Agent muss wissen, welche Informationen zusammengehören, welche Quelle eine Tatsache belegt, welches Datenprodukt einen Geschäftsfall unterstützt und welche Begriffe eine vereinbarte Bedeutung haben. Auch Qualitätserwartungen, Service-Level, Zugriffsmethoden und Governance-Einschränkungen sind nötig. Das geht über reines Retrieval hinaus. Es betrifft die Struktur und den Kontext von Datenprodukten.

Stellen Sie sich vor, Sie suchen in einer Bibliothek nach Informationen zum Thema „Kundenbindung“. Ein klassischer Retrieval-Ansatz wäre ein Bibliothekar, der Ihnen die relevantesten Seiten aus verschiedenen Büchern bringt – ohne zu sagen, ob sie aus demselben Buch stammen, ob sie aktuell sind oder wer sie geschrieben hat. Sie erhalten viele Fragmente, aber keinen roten Faden. Was Sie brauchen, ist ein kuratiertes Dossier: genau die Informationen, die für Ihre Fragestellung relevant sind, mit klarer Herkunft, Zusammenhängen zwischen den Fakten und Hinweisen, unter welchen Bedingungen Sie sie verwenden dürfen. Genau das meint Byakod mit „Knowledge Cataloging“. Es geht nicht darum, mehr Daten abzurufen, sondern den richtigen Kontext zu kompilieren.

Ein Wissensmodell, viele Repräsentationen

Byakod schlägt eine Architektur vor, in der ein einziger Extraktionsprozess mehrere parallele Repräsentationen desselben Wissens erzeugt. Ein Graph unterstützt die Navigation über Beziehungen. Ein kompilierter Markdown-Wiki gibt dem Sprachmodell dichten, verbundenen Kontext. Ein portables Open-Knowledge-Format-Bündel ermöglicht lokale oder Offline-Nutzung. Eine Query-Engine wählt dann die Repräsentation aus, die am besten zur Frage passt. Dieses Prinzip lässt sich direkt auf Datenprodukte übertragen. Ein Datenprodukt – eine bereitgestellte, qualitätsgesicherte Dateneinheit für einen bestimmten Zweck – kann verschiedene Ansichten haben: eine grafische für das Portfoliomanagement, eine maschinenlesbare für die Plattform, eine vertragliche für die Governance und eine komprimierte für den Agenten. Wichtig ist nicht, alle Konsumenten in ein Format zu zwingen. Wichtig ist, ein einziges, gemanagtes Modell zu pflegen und dann die Repräsentation zu kompilieren, die jeder Anwendungsfall benötigt.

Eine der stärksten Empfehlungen in Byakods Artikel lautet: „Kompiliere Kontext, retriev ihn nicht nur.“ Dieses Prinzip sollte direkten Einfluss darauf haben, wie Agenten Datenprodukte konsumieren. Ein Agent, der das Kundenbindungsrisiko bewerten soll, sollte nicht den gesamten Unternehmenskatalog oder fünfzig Fragmente erhalten, die zufällig „Kundenabwanderung“ erwähnen. Er sollte ein vorbereitetes Kontextpaket bekommen: genau die Produkte, Definitionen, Beziehungen und Betriebsbedingungen, die für diese Aufgabe relevant sind. Dieses Paket könnte das Geschäftsziel, die Kennzahl, den genehmigten Anwendungsfall, die unterstützenden Produkte, die erforderlichen Qualitätsbedingungen, die verfügbaren Zugangsdienste und das im Unternehmen verwendete Vokabular umfassen. Auch Produktabhängigkeiten, Quellennachweise, erlaubte Zwecke und die aktuelle Produktversion sollten enthalten sein.

Maysano Studio als Kontext-Compiler

In der Praxis setzt Maysano Portfolio Studio dieses Modell bereits um. Das Studio beginnt mit Quelldokumenten – Strategieberichten, Präsentationen oder Tabellen – und extrahiert daraus Geschäftsziele, Signale, Anwendungsfälle und Datenproduktbedarfe. Diese werden in einem verbundenen Portfoliomodell organisiert. Die Quelldokumente bleiben am Portfolio haften, sodass der ursprüngliche Beleg stets in der Nähe des daraus erstellten Kontexts liegt. Das ist ein entscheidender Unterschied zu einem typischen Retrieval-Setup. Das System behandelt Quelldateien nicht als lose Sammlung von Textfragmenten, sondern wandelt sie in explizite Geschäftsobjekte um. Ein Ziel wird zu einem definierten Knoten. Ein Signal wird zu einem definierten Knoten. Ein Anwendungsfall wird zu einem definierten Knoten. Ein Datenprodukt wird zu einem definierten Knoten. Diese Objekte sind nicht isoliert gespeichert. Ihre Beziehungen erscheinen in einem Graphen, der zeigt, wie Geschäftsabsicht, Belege, Anwendungsfälle und Produktbedarfe miteinander verbunden sind. Jeder Knoten hat auch eine strukturierte YAML-Repräsentation. Dadurch hat dasselbe Portfolio mehrere nützliche Formen gleichzeitig. Geschäftsanwender sehen ein reichhaltiges, verständliches Portfolio. Der Graph offenbart die Beziehungen. Das YAML gibt Plattformen, Entwicklern und Agenten eine maschinenlesbare Definition. Das Quelldokument, das Geschäftsobjekt, die Graphbeziehung und der YAML-Knoten – sie alle beschreiben denselben zugrunde liegenden Kontext aus unterschiedlichen Perspektiven.

Das Studio fungiert als Business-Context-Compiler für Datenprodukte. Es bereitet den Kontext vor, bevor ein Agent ihn benötigt. Die Quelldokumente erklären, woher das Wissen stammt. Die Portfolio-Objekte erklären, was dieses Wissen bedeutet. Der Graph erklärt, wie die Objekte zusammenhängen. Das YAML bietet die Struktur, die Software und KI-Agenten benötigen. Das Data Product SDK kann diesen Kontext dann validieren, verpacken, traversieren, transformieren und über Schnittstellen wie ODPC, ODPG, ODPS, Sidecars, Workflows und Agenten-Interfaces verfügbar machen. Zusammen bilden Studio und SDK zwei Schichten desselben Systems: Das Studio ist die Business-Entwicklungs- und Portfolio-Bildungsschicht; das SDK ist die technische und operative Schicht, die dieses Modell in spezifikationskonforme, portierbare Kontextpakete für Agenten verwandelt.

Herkunft und drei Wissensebenen

Ein weiterer wichtiger Punkt ist die Herkunft der Informationen. Byakod stellt die Provenienz ins Zentrum der Architektur. Extrahierte Entitäten verweisen auf exakte Stellen im Quellmaterial. Das System überprüft diese Verweise unabhängig, anstatt der Ausgabe des Sprachmodells zu vertrauen. Dieses Prinzip ist auch für die Generierung von Datenproduktdefinitionen aus Geschäftsdokumenten entscheidend. Wenn das System ein Geschäftsziel, einen Produktbedarf, eine Kennzahl, einen Konsumenten, eine Einschränkung oder eine Beziehung extrahiert, sollte es den Beleg hinter dieser Extraktion bewahren. Eine Aussage wie „Das Kundenrisikoprodukt unterstützt das Ziel der Abwanderungsreduzierung“ sollte auf die Seite, die Folie, die Tabellenzelle oder den Textabschnitt verweisen, der diese Aussage stützt. Maysano Portfolio Studio hält die Quelldokumente bereits am Portfolio fest. Der nächste Schritt ist, diese Beziehung auf Knotenebene zu vertiefen: Jedes Ziel, jedes Signal, jeder Anwendungsfall und jedes Produkt sollte direkte Verweise auf den exakten Quellennachweis enthalten, aus dem es erstellt wurde.

Das System sollte außerdem drei Informationsebenen trennen. Die erste Ebene ist der Quellennachweis – also das, was das Originaldokument aussagt. Die zweite Ebene ist die maschinelle Interpretation – also das, was der Extraktionsprozess aus diesem Nachweis abgeleitet hat. Die dritte Ebene ist das genehmigte Portfoliowissen – also das, was ein Mensch in das aktive Modell übernommen hat. Diese Trennung verhindert, dass generierte Spezifikationen von ihrem Quellmaterial losgelöst werden. Ohne sie sehen Prüfer eine polierte Produktbeschreibung, können aber nicht feststellen, welche Teile direkt aus Belegen stammen, welche aus Interpretationen und welche während der Prüfung hinzugefügt wurden. Quellengestützte Generierung würde Portfolioentscheidungen leichter erklärbar, anfechtbar und prüfbar machen.

Schema-Validierung allein reicht nicht. Das Data Product SDK validiert bereits die Struktur von Spezifikationen, aber strukturelle Gültigkeit beweist nicht, dass der generierte Inhalt korrekt ist. Eine Produktdefinition kann perfekt dem ODPS-Schema entsprechen und trotzdem ein nicht unterstütztes Ziel, einen erfundenen Konsumenten oder eine falsche Beziehung enthalten. Die Datei ist technisch valide, aber das Produktwissen darin ist unzuverlässig. Byakod bietet hier einen wichtigen Hinweis: Das Sprachmodell schlägt Entitäten und Beziehungen vor, aber deterministischer Code überprüft, ob der Quellennachweis existiert. Das Modell assistiert bei der Interpretation, es fungiert nicht als letzte Autorität. Dasselbe Prinzip sollte auch für die Arbeit mit Maysano Portfolio Studio und dem Data Product SDK gelten. Das Sprachmodell kann bei der Extraktion und Zusammenfassung helfen, aber die finale Verantwortung für die Korrektheit liegt beim Menschen und bei nachvollziehbaren Belegen.

Was bedeutet das konkret für Unternehmen, die KI-Agenten einführen wollen? Der Fokus sollte nicht auf besseren Retrieval-Methoden liegen – nicht auf größeren Vektordatenbanken oder ausgefeilteren Embeddings. Der Fokus sollte auf der Strukturierung und Katalogisierung des Wissens liegen – auf der Schaffung von Datenprodukten mit klarem Kontext, klaren Beziehungen und klarer Herkunft. Ein KI-Agent, der auf solche Datenprodukte zugreift, kann nicht nur Texte abrufen, sondern auch verstehen, was sie bedeuten, wofür sie gelten und woher sie kommen. Er wird zu einem verlässlichen Werkzeug, statt zu einer Blackbox, die eloquent, aber unzuverlässig antwortet. Die Zukunft der Unternehmens-KI liegt nicht im Retrieval, sondern im Context Engineering. Dieser Kontext muss aus Datenprodukten kommen – nicht aus loser Textsammlung. Das ist der Schritt, um KI-Agenten von Demonstrationsobjekten zu ernsthaften Arbeitshilfen zu machen.

Quelle: blog.opendataproducts.org