KI-Agenten & Automatisierung

In „So baust du ein Multi-Agenten-System" hieß es, jede Übergabe zu instrumentieren, bevor man Agenten hinzufügt; die Technologie, die diese Instrumentierung in der Produktion trägt, ist AI observability. Sie macht sichtbar, was LLMs und Agenten in der Produktion tatsächlich tun (welches Modell mit welchem Prompt, welche Tools und Suchen, was zurückkam und wie lange und wie viel es kostete), damit du bis zur Ursache zurückverfolgen kannst. Der entscheidende Unterschied zum gewöhnlichen App-Monitoring: KI kann 200 OK in 50ms zurückgeben und trotzdem selbstbewusst halluzinieren, sodass die meisten KI-Ausfälle Qualitäts-Ausfälle sind (Halluzination, schwaches Retrieval, unsichere Antworten, unvollständige Aufgaben, schlechte Tool-Nutzung, Regressionen nach Prompt-Änderung) und keine Infrastruktur-Ausfälle. Observability ruht auf drei Säulen: traces (eine Anfrage als Baum aus spans, der LLM-Aufrufe, Tools, Retrieval und Argumentationsketten zeigt; der Star der KI-Beobachtung), metrics (Latenz, Kosten, Tokens, Fehlerrate, Durchsatz) und logs (Detail pro Ereignis). Der Industriestandard OpenTelemetry GenAI-Konventionen erfasst Prompts, Antworten, Token-Verbrauch und Tool-/Agenten-Aufrufe in einem herstellerneutralen Schema, einspeisbar in Datadog/Grafana. Die am häufigsten verwechselte Unterscheidung ist Observability vs. Evaluation (evals): Observability zeigt, was passiert ist (leicht zu messen, kann aber nicht sagen, ob die Antwort korrekt ist), während evals messen, ob die Antwort gut ist (Genauigkeit, groundedness, Sicherheit) und explizite Bewertung erfordern. Da Kosten und Latenz leicht zu messen sind, die Antwortqualität aber nicht, kombinieren Tools von 2026 die trace-Anzeige mit Output-Bewertung und Verschlechterungs-Alarmen. Kennzahlen teilen sich in betriebliche (Kosten, Latenz, Tokens, Fehlerrate) und qualitative (Halluzination, groundedness/faithfulness, am wichtigsten für RAG, Sicherheit, Aufgabenerfüllung), mit Halluzinationserkennung via LLM-as-a-judge, semantischer Ähnlichkeit und groundedness-Scores. Wichtige Tools: LangSmith (LangChain), Langfuse (Open-Source-Self-Host), Arize Phoenix (RAG-Debugging), MLflow (Lebenszyklus), AgentOps (Agenten) und OpenTelemetry (der Standard). Beginne mit dem Erfassen von traces (OpenTelemetry-konform), visualisiere betriebliche Kennzahlen und binde dann evals an, bevor du ausrollst. Für Multi-Agenten-Systeme ist Beobachtung unverzichtbar, da sich Fehler in mehrstufigen Ketten verbergen, die nur in einem vollständigen Session-Trace sichtbar sind. Beobachten plus bewerten macht KI produktionsreif. Abbildungen und Merkmale sind aus öffentlichen Materialien zitiert, als Richtwert.

Nachdem das Konzept in „Was ist ein Multi-Agent-System?“ geklärt wurde, ist dies die praktische Fortsetzung. Anhand des De-facto-Standards von 2026, des supervisor-Musters, führt der Artikel Anfänger durch einen Bau in 5 Schritten. Das Kernprinzip: zuerst Single bauen und Agenten nur minimal hinzufügen, sobald man an eine Grenze stößt (rund 80% der Anwendungsfälle reichen mit einem; Multi für einfache lineare Arbeit treibt die Kosten um das 3-10-Fache hoch und senkt laut Google-Forschung die Genauigkeit bei sequenziellen Aufgaben um -39-70%). Drei Anzeichen für Multi: Aufteilung nach Fachgebieten, Parallelität, Entscheidungstrennung. Das supervisor-Muster (der supervisor empfängt die Gesamtaufgabe, zerlegt sie, delegiert an spezialisierte Worker und fasst die Ergebnisse zusammen) ist die Form, auf die Claude Code subagents, LangGraph Supervisor und OpenAI Agents SDK handoffs konvergiert sind – wegen breitester Framework-Unterstützung, eines bekannten Fehlermodus (Über-Delegation, begrenzt durch eine Iterations-Obergrenze) und leichter Auditierbarkeit. Die 5 Schritte: 1) die Aufgabe vorab klar zerlegen; 2) Worker mit einer Rolle + Tools + Ausgabeformat definieren (höchstens 3-5); 3) den supervisor entwerfen, aufrufbare Worker-Namen explizit auflisten (harte Obergrenze) und hier die meiste Zeit verwenden; 4) Handoff und Kontextteilung festlegen, nur Nötiges weitergeben (Standard ist A2A); 5) jeden Handoff vor dem Hinzufügen von Agenten instrumentieren, Iterationen/Tokens/Kosten begrenzen und evals und Guardrails einrichten. Framework-unabhängiger Pseudocode zeigt Worker-Definitionen, einen hart begrenzten supervisor und eine iterationsbegrenzte Ausführungsschleife. Häufige Fallstricke und Lösungen: Über-Delegation (Obergrenze + aufrufbare Worker begrenzen), Token-Aufblähung (nur Nötiges teilen + Cache), Instabilität (bei 3-5 halten + fixe Ausgabe), Genauigkeitsverlust bei sequenziellen Aufgaben (zurück zu Single) und unklarer Fehlerort (Beobachtbarkeit). Die gemeinsame Lektion: Prompts, Tool-Design und das eval-Harness entscheiden mehr über den Erfolg als das Framework. Klein bauen, messen, nur erweitern, wenn es sich lohnt. Zahlen stammen aus öffentlichen Materialien und Forschung, kontextabhängig.

„Eine komplexe Aufgabe, die ein einzelner KI-Agent nicht bewältigen kann, auf mehrere Agenten aufteilen" – das ist die Idee hinter Multi-Agent-Systemen. Dieser Einsteiger-Guide erklärt die Funktionsweise, die wichtigsten Muster und die führenden Frameworks und vor allem die echte Entscheidungsregel, wann sich mehrere Agenten lohnen und wann einer genügt, ganz ohne Hype. Ein Multi-Agent-System lässt mehrere rollenspezialisierte KIs an einer großen Aufgabe zusammenarbeiten; anders als ein einzelner Agent, der alles erledigt (genügt für ~80 % der Anwendungsfälle, günstig und leicht zu debuggen), teilt es die Arbeit nach Fachgebiet auf, für parallele Ausführung und gegenseitige Kontrolle, zum Preis höherer Koordinationskosten und Tokenmenge. Die vier dominierenden Orchestrierungsmuster sind: Orchestrator-Worker (ein Leiter zerlegt, verteilt Worker parallel und führt zusammen; am weitesten verbreitet, mit Prüfspur), sequenzielle Übergabe (Kontext an den nächsten Agenten weiterreichen), Gruppengespräch (Agenten debattieren in einem Thread, ein Auswähler entscheidet, wer spricht; gut für gegenseitige Überprüfung) und Graph-Zustandsmaschine (Agenten als Knoten, Übergänge als Kanten, expliziter Zustand; stark bei Verzweigungen und Checkpoints). Die Frameworks konsolidierten sich 2026 zu LangGraph (größte Verbreitung im Produktivbetrieb), CrewAI (geringste Lernkurve, Prototyping), AutoGen/AG2 (Debatte und Überprüfung, Forschung) und OpenAI Swarm (leichtgewichtige Übergaben). Doch es ist kein Allheilmittel: komplexe fachübergreifende Aufgaben erreichen bis zu +23 % bei Reasoning-Benchmarks, doch bei linearen sequenziellen Aufgaben fand Google-Forschung −39–70 % gegenüber einem einzelnen Agenten, dieselbe Rechenleistung einem Agenten gegeben gleicht oft auf oder gewinnt, und 7 von 10 Einführungen verursachten Berichten zufolge Kosten ohne ROI bei ~15-fachem Tokenverbrauch (durchschn. ROI 2.5-3.5x, oberes Quartil 4-6x bei gutem Einsatz). Der empfohlene Weg: erst einzeln bauen, eine konkrete Decke identifizieren (verschwommene Rollen, parallelisierbare Arbeit), dann ein minimales Team von 2-3 Agenten im Leiter-Muster mit Kostengrenze und Logging hinzufügen und messen, ob der Genauigkeitsgewinn den Anstieg rechtfertigt. A2A (Kommunikationsprotokoll) und MCP (Werkzeuganbindung) sind Basistechnologien, die Multi-Agent tragen. Einzeln für 80 %, Multi nur für die schwierigen Teile. Die Zahlen stammen aus Umfragen und Forschung und sind bedingungsabhängige Richtwerte.

Jetzt, da KI-Agenten alltäglich sind, lautet die nächste Herausforderung, wie man Agenten miteinander kooperieren lässt. Wenn MCP einen Agenten mit seinen Werkzeugen verbindet, verbindet A2A (Agent2Agent) einen Agenten mit einem anderen Agenten — ein offener Standard, mit dem sich KIs auf unterschiedlichen Anbietern und Frameworks finden, kommunizieren und über eine gemeinsame Konvention kooperieren. Google veröffentlichte ihn im April 2025, übergab ihn im Juni an die Linux Foundation, und 2026 erreichte er v1.0. Dieser Einsteiger-Leitfaden erklärt, was A2A ist (mit der Analogie der Umgangsformen einer Geschäftspartnerschaft), warum es nötig ist (spezialisierte Agenten reichen Arbeit weiter — ein Planungs-Agent zu einem Hotelbuchungs-Agent zu einem Bezahl-Agent), wie es sich von MCP unterscheidet (MCP ist vertikal, Agent ↔ Werkzeuge; A2A ist horizontal, Agent ↔ Agent; beide übereinanderzulegen ist das zweischichtige Standard-Setup), wie es funktioniert (eine Agent Card — ein JSON als „Visitenkarte" unter /.well-known/agent-card.json — dient zum Entdecken der Fähigkeiten, dann trägt ein Task die Anfrage durch Zustände wie working, input-required und completed, und ein Artifact liefert das Ergebnis, alles über HTTP, Server-Sent Events und JSON-RPC 2.0, wobei die Agenten ihre Interna verborgen halten) sowie aktueller Stand und Umsetzung (Stand April 2026: 150+ Organisationen im Produktivbetrieb, 22.000+ GitHub-Sterne, SDKs in fünf Sprachen — Python, JavaScript, Java, Go, .NET — mit Microsoft, Salesforce, SAP und ServiceNow beteiligt). Die Eselsbrücke: mit Werkzeugen verbinden = MCP, mit Partnern verbinden = A2A.

Sie haben RAG aufgebaut, aber die Suchqualität ist mittelmäßig – genau dann hilft Reranking. Reranking bewertet die grob von der Embedding-Suche (Vektorsuche) gesammelten Kandidaten nach ihrer Relevanz zur Anfrage neu und ordnet sie um, behält nur die besten; dieser eine Schritt kann die Antwortqualität eines RAG-Systems dramatisch verändern. Dieser Einsteigerleitfaden behandelt, was Reranking ist (ein Vergleich von Vorauswahl und finalem Vorstellungsgespräch), warum es nötig ist (die Embedding-Suche vektorisiert Anfrage und Dokumente getrennt und beurteilt die Relevanz daher nur grob, und eine schlechte Reihenfolge senkt die Antwortqualität unmittelbar – Studien berichten von etwa 40 % RAG-Genauigkeitszugewinn durch Reranking, und das Aufsetzen auf eine hybride Suche ist der Standard 2026), wie zweistufiges Retrieval funktioniert („breit sammeln" mit schneller Embedding-Suche für Recall, dann „klug eingrenzen" mit dem Reranker für Precision, dann die besten an das LLM übergeben), warum ein Reranker genauer ist (ein Bi-Encoder vektorisiert Anfrage und Dokument einzeln, ist schnell, aber näherungsweise; ein Cross-Encoder gibt beide gemeinsam ein und liefert einen Relevanzwert von 0–1, genau, aber schwergewichtig – daher sammeln Sie mit dem schnellen Bi-Encoder und grenzen mit dem genauen Cross-Encoder ein) sowie die Modelle und Umsetzung (API-Typ wie Cohere Rerank, Voyage und Jina; Open Source wie BGE reranker, mixedbread und FlashRank; und LLM-basiertes Scoring wie RankLLM – einfach 50–100 abrufen und auf die Top 5 eingrenzen). Das Prinzip: breit sammeln, klug eingrenzen und die Anzahlen mit KI-Evaluierungen abstimmen.

Wenn man KI-Apps bauen kann, ist die nächste Stufe, sie sicher zu betreiben. LLMs lassen sich durch bösartige Eingaben täuschen, geben vertrauliche Daten preis oder behaupten Unsinn mit Überzeugung; der Sicherheitsmechanismus, der das verhindert, sind KI-Guardrails — im Jahr 2026 ein unverzichtbarer Bestandteil des Produktivbetriebs, da Vorfälle mit KI-Agenten tatsächlich passieren. Guardrails sind Regeln und Filter, die gefährliche Eingaben und unerwünschte Ausgaben zurückhalten, indem sie die Nutzereingabe prüfen, bevor sie das LLM erreicht, und die Antwort, bevor sie zurückkehrt — eine unabhängige Sicherheitsebene, getrennt vom Modell selbst. Die Hauptbedrohungen sind Prompt Injection (die größte), Jailbreaks, Datenlecks (vertrauliche Daten, PII, der System-Prompt) sowie Halluzination oder schädliche Ausgabe. Der Schutz wirkt auf zwei Ebenen: Eingabe-Guardrails (Injection und Jailbreaks erkennen, PII erkennen/maskieren, Themen einschränken, bereinigen) und Ausgabe-Guardrails (schädliche Inhalte filtern, Lecks verhindern, Halluzinationen prüfen, Format validieren). Prompt Injection — auf den OWASP LLM Top 10 als kritischste eingestuft — tritt in direkter (ein Nutzer tippt „ignoriere alle vorherigen Anweisungen") und indirekter Form (in einer Webseite oder einem RAG-Dokument versteckte Befehle) auf, und indirekte Injection wird durch RAG allein nicht blockiert, sodass abgerufene Dokumente eine eigene Prüfung brauchen. Dieser Einsteigerleitfaden behandelt auch Werkzeuge (LLM Guard, Guardrails AI, NeMo Guardrails, Llama Guard sowie Cloud-Sicherheitsfunktionen von Azure, AWS und OpenAI) und die praktischen Prinzipien der mehrschichtigen Verteidigung, der geringsten Rechte, der menschlichen Freigabe und der kontinuierlichen Überwachung.

RAG, semantische Suche und Empfehlungen beruhen alle auf einem unbesungenen Arbeitspferd: dem Embedding (Vektor). Ein Embedding ist die in eine Zahlenfolge — einen Vektor — umgewandelte Bedeutung von Text (oder eines Bildes). Das Wort „Hund" wird zu einer Liste aus Hunderten bis Tausenden von Zahlen, die als „Koordinaten der Bedeutung" wirken, sodass Wörter mit naher Bedeutung nah beieinander liegen („Hund" und „Welpe" sind nah; „Hund" und „Auto" sind fern), und die Nähe wird mit Maßen wie der Kosinus-Ähnlichkeit quantifiziert. Berühmtes Beispiel: „König − Mann + Frau ≈ Königin." Dadurch kann eine Maschine beurteilen, ob die Bedeutung nah ist, selbst wenn die Zeichen nicht übereinstimmen. Dieser Einsteiger-Leitfaden behandelt, was ein Embedding ist (eine „Landkarte der Bedeutung"), warum Nähe Bedeutung misst (Dimensionen und Kosinus-Ähnlichkeit), wofür es verwendet wird (RAG, semantische Suche, Klassifikation und Deduplizierung, Empfehlungen sowie multimodal), wie man ein Embedding-Modell auswählt (API-Typ wie OpenAI text-embedding-3, Cohere, Gemini, Voyage; Open-Source wie BGE-M3, Nomic, Qwen3; plus Matryoshka, das 3.072 Dimensionen auf 1.024 senken kann und dabei etwa 95 % der Qualität bei rund einem Drittel der Kosten erhält) sowie Vektordatenbanken (Pinecone, Weaviate, Qdrant, Chroma, pgvector) mit einem Drei-Schritte-Start (ein Modell wählen, Dokumente vektorisieren und speichern, die Frage vektorisieren und suchen). Embeddings sind das Fundament der RAG-Implementierung.

Sie haben Ihre Prompts verfeinert, mit RAG Wissen ergänzt und vielleicht Fine-Tuning betrieben – aber wie bestätigen Sie, dass es wirklich besser geworden ist? Hier rücken AI Evals in den Mittelpunkt, und bis 2026 ist Evaluierung so unverzichtbar, dass man sie als „Infrastruktur" bezeichnet. AI Evals bedeuten, die Qualität der Ausgaben eines LLM systematisch zu messen (Korrektheit, Halluzinationen, Formattreue, Ton) anhand eines festen Maßstabs statt nach Bauchgefühl; ohne sie ist Verbesserung nur eine Vermutung. Es gibt zwei Methoden: code-basierte Evaluierung für mechanisch messbare Punkte (exakte Übereinstimmung, Format, geforderte/verbotene Wörter – schnell, günstig, stabil) und LLM-as-Judge für subjektive (ein leistungsstarkes LLM als Schiedsrichter, der Ausgaben über Pairwise-Vergleich oder Einzelausgabe-Bewertung benotet). Das Prinzip: Messen Sie mit Code alles, was Code messen kann. LLM-as-Judge hat Wortfülle-, Positions- und Selbstbevorzugungs-Verzerrungen; die Lösungen sind ein anderes Bewerter-Modell, Reihenfolge tauschen und zweimal benoten, Prägnanz ins Raster aufnehmen und an menschlichem Urteil kalibrieren. Grobe Skalen (pass/fail oder 1–3) schlagen feinkörnige 1–10. In der Praxis laufen drei Stufen – sofortige Code-Checks bei jeder Änderung, nächtliche LLM-as-Judge-Regressionstests und kontinuierliche Produktionsüberwachung – mit Tools wie DeepEval, Promptfoo und RAGAS für CI sowie Braintrust, LangSmith und Arize für die Überwachung. Beginnen Sie damit, 10 gute und 10 schlechte Ausgaben zu sammeln und zu bewerten.

In einer Zeit, in der die KI den Code schreibt, verschiebt sich die wertvollere Fähigkeit vom „Code schreiben" zum „die Spezifikation schreiben" — und die Praxis, die das auf den Punkt bringt, ist Spec-Driven Development (SDD). SDD stellt die Spezifikation als maßgebliche Quelle in den Mittelpunkt des Projekts, und ein KI-Agent leitet daraus Design, Aufteilung und Implementierung ab, statt sofort zu programmieren. Entscheidend ist, dass jeder Schritt ein Dokument (oft Markdown) hinterlässt, das der nächste Schritt liest. Dieser einsteigerfreundliche Leitfaden erklärt, was SDD ist (die Spezifikation ist maßgeblich, der Code ein Derivat), warum es jetzt zählt (es verhindert die „Drei-Monats-Mauer" aus technischen Schulden und Anforderungsdrift des Vibe Coding schon in der Entwurfsphase — GitHub berichtet von rund einer Größenordnung weniger „von Grund auf neu generieren"-Zyklen), die grundlegenden vier Schritte (Specify → Plan → Tasks → Implement), die wichtigsten Tools (GitHub Spec Kit mit über 90.000 Sternen und mehr als 30 unterstützten Agenten, AWS Kiro mit seinem Requirements → Design → Tasks-Ablauf und Auto-Router sowie BMAD, OpenSpec, Tessl, Google Antigravity und Cursor), wann man es im Vergleich zum Vibe Coding einsetzt (ein Hybrid: Vibe zum Erkunden, spezifikationsgetrieben zum Ausliefern, mit verpflichtendem menschlichem Review) und wie Sie es noch heute ausprobieren. Im KI-Zeitalter steigen jene auf, die präzise definieren können, was gebaut werden soll — nicht jene, die am schnellsten Code schreiben.

Der Schwerpunkt der Arbeit mit KI verschiebt sich vom Prompt Engineering zum Context Engineering. In Anthropics Worten ist Context Engineering „die Gesamtheit der Strategien, um den optimalen Satz an Tokens (Informationen) zu kuratieren und zu pflegen, den man dem Modell während der Inferenz übergibt" — und umfasst nicht nur den Prompt, sondern alles im Kontextfenster: den System-Prompt, Tools, den Gesprächsverlauf und externe Daten. Es zählt wegen „Context Rot": Je mehr Tokens Sie hinzufügen, desto stärker sinkt tatsächlich die Genauigkeit. Chromas Studie von 2025 testete 18 führende Modelle (GPT, Claude, Gemini und weitere), und jedes verschlechterte sich, je länger die Eingabe wurde, wobei Informationen in der Mitte langer Kontexte besonders leicht übersehen werden („lost in the middle"). Dieser einsteigerfreundliche Leitfaden erklärt, was Context Engineering ist und wie es zum Prompt Engineering steht, warum Context Rot entsteht (Aufmerksamkeit ist ein begrenztes Budget), was tatsächlich im Kontext steckt, sechs zentrale Techniken (Anweisungen auf der richtigen Flughöhe, Tool-Kuratierung, Just-in-time-Abruf, Compaction/Verdichtung durch Zusammenfassung, Notizen als externes Gedächtnis und Isolation per Sub-Agent), das Verhältnis zu RAG und Claude Skills sowie Gewohnheiten für heute, etwa eine neue Sitzung zu starten, wenn das Thema wechselt, und nur die Kernpunkte einzufügen. Der Kerngedanke: nur die kleinste, signalstärkste Menge an Tokens behalten.

Ein anfängerfreundlicher Leitfaden zu Claude Skills (Agent Skills) – dem Mechanismus, der Schluss macht mit dem mühsamen Wiedererklären desselben Ablaufs an Claude. Ein Skill verpackt Anweisungen, Skripte und Referenzen in einen einzigen Ordner, rund um eine SKILL.md-Datei mit name, description und den Schritten. Meist liest Claude nur die kurze Beschreibung jedes Skills und entfaltet den Inhalt erst, wenn deine Anfrage passt – ein Design namens progressive Offenlegung, das deinen Kontext selbst bei Dutzenden installierter Skills leicht hält. Der Artikel erklärt, was Skills sind, warum sie wichtig sind (Schluss mit dem ewigen Prompt-Einfügen), wie man SKILL.md und eine minimale Ordnerstruktur schreibt, wie man einen baut (offizieller skill-creator oder von Hand, abgelegt in .claude/skills, mit Sofort-Reload ab Januar 2026), wie sich Skills von MCP (Konnektivität) und Subagenten (Kontextisolation) unterscheiden, den offenen Standard, den neben den Claude-Apps, Claude Code, der API und dem Agent SDK auch Codex CLI, Cursor, Gemini CLI und GitHub Copilot übernommen haben, plus konkrete Anwendungen wie Dokumentenerstellung und das Durchsetzen interner Regeln. Von Anthropic am 16. Oktober 2025 vorgestellt und von Simon Willison als „vielleicht eine größere Sache als MCP" bezeichnet.

"Ich habe eine KI gefragt, und sie hat den Browser geöffnet, Dinge nachgeschlagen und sogar ein Formular ausgefüllt." 2026 ist das keine inszenierte Demo mehr: Agentische Browser (ChatGPT Atlas, Claude for Chrome, Gemini/Chrome, Perplexity Comet) kamen auf einen Schlag. Doch wie weit reicht die Automatisierung wirklich? Die Realität teilt sich sauber in drei Stufen. (1) Recherche = praxisreif: Auf WebVoyager (echte Sites) erreichen Spitzen-Agenten 89-98%, nahe der Sättigung, und da ein Fehler kaum etwas kostet, sollten Sie hier mit dem Delegieren beginnen. (2) Formulare = machbar, aber prüfen: Die Eingabe selbst wird unterstützt, doch Agenten können Felder falsch zuordnen oder den falschen Absenden-Button treffen, daher ist "die KI entwirft, ein Mensch sendet ab" sicher, und viele Produkte wie Atlas bitten vor wichtigen Aktionen um Bestätigung. (3) Buchen/Bezahlen = selbst erledigen: Agenten stolpern über CAPTCHAs, komplexe JavaScript-Checkouts, Zwei-Faktor-Auth und Sitzungsverwaltung, und auf WebArena (komplexe mehrstufige Aufgaben) erreichen selbst die Besten nur ~47-68% gegenüber einer menschlichen Basislinie von ~78%; der eigentliche Grund, warum OpenAI das eigenständige Operator einstellte (2025/8/31), war die Unzuverlässigkeit des Checkouts. Der Artikel rahmt zunächst die zwei Ansätze (Verbraucher-Browser/Erweiterung vs. Entwickler-API/OSS), kartiert dann die Anbieter 2026 (Atlas als eigenständiger Browser, der per Design keinen Code ausführt und keine Passwörter liest; Claude for Chrome als Erweiterungs-Seitenleiste; Googles Project Mariner endete 2026/5/4 und ging in Gemini/Chrome auf; Operator wanderte in ChatGPT Agent und das Agents SDK; OSS browser-use mit über 78k Sternen). Er erklärt die vier Hürden, an denen Buchungen scheitern (Bot-Abwehr, komplexer Checkout, 2FA, die Kosten des Rückgängigmachens), und vertieft dann die größte Falle: die indirekte Prompt Injection (Perplexity Comet erwies sich als anfällig für Zero-Click-Diebstahl von Zugangsdaten und behob dies im Februar 2026; ein Angriffserfolg von 23.6% vor Abwehr sinkt auf ~11% mit grundlegender und ~1% mit der stärksten, bleibt aber nicht null). Er schließt mit fünf Sicherheitsgrundsätzen (mit Nur-Lesen beginnen, ein Mensch gibt Sendungen/Zahlungen frei, niemals Passwörter übergeben, nicht auf nicht vertrauenswürdigen Sites laufen lassen, geringste Rechte in einem dedizierten Profil). Ein hervorragender Recherchepartner; die geldbewegenden Aktionen erledigen Sie selbst. Die Zahlen stammen als Richtwerte aus öffentlichen Materialien und Ankündigungen.