Executive Briefing: Der beste Agent ist die falsche Frage

Copilot, Claude Cowork, Codex, Gemini, Salesforce Agentforce und WPP Open sind nicht Varianten derselben Sache. Sie passen zu unterschiedlichen Arbeiten, Datenlagen, Oberflächen und Risiken. Wer sie richtig beurteilen will, muss zuerst das Problem verstehen.

Copilot ist nicht Claude Cowork. Claude Cowork ist nicht Codex. Codex ist nicht Gemini. Gemini ist nicht Salesforce Agentforce. Und WPP Open ist noch einmal etwas anderes.

Trotzdem landen diese Produkte in vielen Unternehmen gerade in derselben gedanklichen Schublade: AI-Agenten.

Klingt praktisch. Ist aber zu grob.

Ein Agent, der einen Text zusammenfasst, ist ein Werkzeug. Ein Agent, der eure Mails liest, CRM-Daten auswertet, Briefings schreibt, Kampagnen plant, Dateien anlegt und vielleicht noch Aktionen ausführt, ist etwas anderes.

Er ist ein Stück Organisationsarchitektur.

Genau deshalb ist die beliebteste Frage meistens falsch. Sie lautet: Welcher Agent ist der beste?

Die bessere Frage lautet: Welcher Agent passt zu welcher Arbeit, zu welchen Daten und zu welchen Grenzen?

Es gibt nicht den einen richtigen Agenten. Es gibt nur bessere Beurteilungsfragen.

Der US-Filter ist gut. Nur nicht ausreichend.

Nate Jones hat kürzlich einen nützlichen Filter für Agentenlaunches formuliert. Er fragt im Kern: Bindet sich das Produkt in vorhandene Tools ein? Können andere Agenten darauf aufbauen? Hat es Zugriff auf relevante Daten? Entsteht ein Ökosystem? Lassen sich Agenten stapeln?

Diese Fragen sind gut, weil sie die Debatte aus dem Modellvergleich holen.

Die Frage ist nicht mehr, ob Claude, GPT, Gemini oder Kimi in einem Benchmark drei Punkte vorn liegen. Die Frage ist, welches Produkt an die Daten, Rechte und Workflows kommt, in denen eure Arbeit wirklich stattfindet.

Ein mittelmäßiger Agent mit Zugriff auf echte Kundendaten kann wertvoller sein als ein sehr gutes Modell, das vor einer leeren Wand sitzt. Organisationen funktionieren selten über reine Modellqualität. Sie funktionieren über Kontext, Rechte, Routinen und Zugriff.

Nates Filter trennt damit Features von Infrastruktur. Ein Agent, der nur in seiner Oberfläche funktioniert, ist ein Produkt. Ein Agent, den andere Systeme nutzen können, der Berechtigungen erbt und Workflows erreicht, wird Infrastruktur.

Soweit, so richtig.

Der europäische Haken ist: Sobald ein Agent Infrastruktur wird, wird er auch Governance. Und viel zu oft: Mitbestimmung.

Sechs Agententypen, sechs verschiedene Fragen

Wenn ein Entscheider jetzt fragt: "Welchen Agenten brauchen wir?", wäre meine Gegenfrage nicht: "Wie groß ist euer Budget?"

Meine Gegenfrage wäre: Welches Problem versucht ihr zu lösen?

Denn Copilot, Claude Cowork, Codex, Gemini, Salesforce Agentforce und WPP Open sitzen an unterschiedlichen Stellen im System.

Wenn die Arbeit im Microsoft-Graph liegt: Copilot prüfen

Wenn eure Arbeit vor allem in Outlook, Teams, SharePoint, Excel, PowerPoint und M365-Dokumenten stattfindet, ist Copilot nicht einfach ein weiterer Chatbot. Dann ist der entscheidende Vorteil der Zugriff auf den organisatorischen Kontext.

Die Prüffrage lautet nicht: Ist Copilot das beste Modell?

Sie lautet: Ist unser Problem stark genug im M365-Kontext verankert, dass nativer Datenzugang wichtiger ist als maximale Modellkontrolle?

Wenn ja, ist Copilot oft naheliegender als ein generischer Agent mit nachträglich verbundenen Connectoren.

Wenn die Arbeit modellnah, offen und skill-basiert ist: Claude prüfen

Claude und Claude Cowork sind stärker, wenn die Arbeit weniger an einem einzelnen Enterprise-Graph hängt und stärker an Denk-, Schreib-, Analyse-, Coding- oder Skill-Mustern.

Die Prüffrage lautet: Brauchen wir ein gutes Denk- und Arbeitsmodell, das wir selbst formen, oder einen Agenten, der schon tief in einem bestimmten Unternehmenssystem sitzt?

Wenn ihr eigene Arbeitsmuster bauen, testen und iterieren wollt, ist das eine andere Entscheidung als "wir wollen, dass ein Agent direkt im CRM arbeitet".

Wenn die Arbeit an Oberflächen hängt: Codex und Computer Use prüfen

Viele Unternehmen haben Systeme, die für Menschen gebaut wurden und für Agenten schlecht zugänglich sind.

Kein sauberer API-Zugang. Kein MCP-Server. Nur eine grafische Oberfläche, ein Browserfenster, ein altes Backoffice, ein Portal oder irgendeine Fachanwendung, die seit Jahren funktioniert und deshalb nie ordentlich integriert wurde.

Genau hier werden Codex, Computer Use und Desktop-Agenten spannend. Nicht, weil die Oberfläche der eleganteste Weg wäre. APIs sind stabiler. Aber viele reale Unternehmensprozesse leben nun einmal in Masken, Upload-Feldern, Download-Buttons und Portalen, die ein Mensch bisher abgeklickt hat.

Die Prüffrage lautet: Muss der Agent ein System über eine Oberfläche bedienen, weil es keine bessere Schnittstelle gibt?

Wenn ja, ist er eine Brückentechnologie für die schmutzige Wirklichkeit. Aber genau deshalb braucht er engere Grenzen: Sandbox, Aufzeichnung, Freigaben, Testdaten, kleine Aktionsräume und klare Stopppunkte.

Wenn die Arbeit im Google-Stack liegt: Gemini und Opal prüfen

Nicht jedes Unternehmen lebt in Microsoft.

Wenn eure Arbeit stark in Gmail, Google Drive, Docs, Sheets, Slides, Meet und BigQuery liegt, zählt derselbe Mechanismus wie bei Copilot: nativer Zugriff auf den Arbeitsgraphen kann wichtiger sein als ein marginal besseres Modell anderswo.

Google Opal ist zusätzlich interessant, weil es als prompt-basierter Workflow-Builder eine andere Einstiegshürde hat. Nate beschreibt Opal als freien On-Ramp in Agentenlogik: Workflows, dynamisches Routing, Kontext über Sessions und Speicher in Google Sheets. Das ist nicht perfekt, aber bemerkenswert inspizierbar.

Die Prüffrage lautet: Liegt unser Problem im Google-Arbeitsraum, oder wollen wir schnelle, sichtbare Workflow-Prototypen bauen?

Wenn ja, sollte Google in der Auswahl nicht fehlen. Aber auch Google-native Workflows portieren nicht automatisch.

Wenn die Arbeit im CRM und Revenue-Prozess liegt: Salesforce prüfen

Salesforce Agentforce und Headless-360-Logik sind relevant, wenn der Kern eures Problems in CRM-Daten, Opportunities, Servicefällen, Flows, Kundendaten, Pipeline-Logik oder Revenue Operations liegt.

Dann ist nicht der Chat das Produkt. Das Produkt ist der kontrollierte Zugriff auf Objekte, Workflows, Berechtigungen und Businesslogik im CRM.

Die Prüffrage lautet: Soll ein Agent nur über CRM-Daten reden, oder soll er CRM-Arbeit mit echten Berechtigungen, Logs und Systemlogik ausführen?

Wenn Letzteres der Fall ist, ist ein lose angebundener Generalist oft nicht der richtige Ausgangspunkt.

Wenn die Arbeit Marketingmethode, Brand und Agenturleistung betrifft: Plattformen wie WPP Open prüfen

WPP Open ist wieder eine andere Kategorie. Hier geht es nicht nur um ein Tool für Einzelaufgaben. Es geht um eine Plattform, in der Daten, Agenten, Methoden, Brand-Logik, Agenturwissen und Service-Modelle zusammenlaufen.

Das kann sinnvoll sein, wenn das Problem nicht "einzelne Aufgabe automatisieren" lautet, sondern "Marketingarbeit über Strategie, Kreation, Media, Produktion und Performance hinweg verbinden".

Die Prüffrage lautet: Brauchen wir ein Werkzeug für eine Aufgabe, oder übernehmen wir eine Arbeitsoberfläche, in der Methode und Betrieb gleich mitgeliefert werden?

Wenn Methode und Betrieb mitgeliefert werden, wird die Entscheidung strategischer. Dann geht es nicht nur um Capability, sondern um Abhängigkeit, Ownership und Exit.

Disclaimer: In meinem Tagesjob, der keinen Einfluss auf dekodiert.de hat, arbeite ich für VML, eine Agentur im WPP Netzwerk.

Das ist keine Rangliste

Damit wird die Agentenentscheidung weniger mystisch:

• Office- und Wissensarbeitsgraph: Copilot prüfen.
• Denk-, Schreib-, Coding- oder Skill-Arbeit: Claude und ähnliche Modellagenten prüfen.
• Alte Systeme ohne saubere Schnittstelle, aber mit bedienbarer Oberfläche: Codex, Computer Use und Desktop-Agenten prüfen.
• Google-Arbeitsraum oder schnell prototypisierbare Workflows: Gemini und Opal prüfen.
• CRM oder Revenue Operations: Salesforce-nahe Agenten prüfen.
• Marketingmethode, Brand-Systeme und Agenturleistung: Plattformen wie WPP Open prüfen.

Das ist keine Rangliste. Es ist Werkzeugwahl.

Ein Hammer ist kein schlechter Schraubendreher. Er ist ein Hammer.

Tiefe Integration ist nie nur ein Vorteil

Viele AI-Produkte verkaufen gerade genau diese Tiefe als Versprechen.

Der Agent sieht eure Mails. Eure Meetings. Eure CRM-Historie. Eure Brand Guidelines. Eure Assets. Eure Kampagnen. Eure Performance-Daten. Eure internen Chats. Eure Dokumente. Eure Freigabelogiken.

Aus Produktsicht ist das logisch. Ein Agent ohne Kontext ist ein Praktikant mit verbundenen Augen. Vielleicht motiviert. Selten nützlich.

Aber in Europa ist Datenzugang nicht nur Produktqualität. Er ist Rechtsfrage, Sicherheitsfrage, Mitbestimmungsfrage und Betriebsmodell.

Sobald ein Agent echte Arbeit vorbereitet oder ausführt, stellen sich sehr nüchterne Fragen:

• Welche Daten braucht er wirklich?
• Erbt er bestehende Rechte oder entstehen Schattenrechte?
• Speichert er Prompts, Outputs, Dateien, Embeddings, Feedback oder Memory?
• Welche Aktionen darf er ausführen?
• Wer sieht die Logs?
• Können Führungskräfte individuelle Nutzung, Outputmenge oder Qualität auswerten?
• Was passiert, wenn der Anbieter Modell, Agentenlogik oder Preismodell ändert?

Das sind keine Detailfragen für Legal am Ende des Piloten. Das ist die Kaufentscheidung.

Ein Agent, der tief genug integriert ist, um richtig nützlich zu sein, ist fast immer auch tief genug integriert, um Schaden anzurichten.

WPP Open zeigt das Muster besonders klar

WPP beschreibt Open als "agentic marketing platform". Die Plattform soll Marketingarbeit über einen gemeinsamen, sicheren Workspace verbinden. WPP-Teams können damit Leistungen erbringen. Kundenteams können Anwendungen selbst nutzen. Oder beide Seiten arbeiten gemeinsam in derselben Umgebung.

Das ist strategisch plausibel. Marketingarbeit ist voller Übergaben, Datenbrüche, Medienlogik, Brand Guidelines, Zielgruppenannahmen, Produktionsschleifen und Freigaben. Wenn Agenten dort sinnvoll arbeiten sollen, brauchen sie mehr als ein Chatfenster.

Der Agent Hub verspricht verifizierte, brand-safe Agents, trainiert auf proprietären Daten, Frameworks und Methoden. WPP spricht von ungefähr 30 Jahren Brand-Asset-Valuator-Daten und von 150 Jahren kreativer WPP-Intelligenz.

Das ist nicht automatisch schlecht. Genau so sieht ein ernst gemeinter Plattformversuch aus: keine Modellhülle, sondern eine Arbeitsschicht aus Daten, Methode, Prozess, Agenten und menschlicher Expertise.

Aber genau deshalb ist WPP Open der richtige Fall für die europäische Frage.

Wenn eine Agenturplattform eure Briefings verbessert, eure Zielgruppenlogik prägt, eure Brand Guidelines operationalisiert, eure Tests ausführt, eure Kampagnen plant und eure Methoden in Agents codiert, dann kauft ihr nicht nur Effizienz.

Ihr kauft ein Stück Betriebssystem für Marketing.

Dann lautet die entscheidende Frage nicht: Ist das Tool gut?

Die Frage lautet: Wird eure Organisation dadurch fähiger, oder wird sie nur tiefer in ein fremdes Betriebssystem eingebaut?

Der neue Lock-in sitzt in der Arbeitsweise

Früher war Vendor-Lock-in relativ leicht zu beschreiben.

Datenexport. Schnittstellen. Vertragslaufzeit. Schulungsaufwand. Migration. Alles nervig, aber immerhin sichtbar.

Bei Agenten wird es unangenehmer.

Der neue Lock-in sitzt nicht nur in Dateien oder APIs. Er sitzt in codierten Workflows, Prompt-Logik, Freigabemustern, Agenten-Memory, Evaluationsdaten, Brand Guidelines als ausführbarer Arbeitslogik, proprietären Methoden und in den Gewohnheiten der Teams.

Das ist schwerer zu exportieren als eine CSV-Datei.

Wenn ein Anbieter nach zwölf Monaten sagt: "Natürlich können Sie Ihre Daten exportieren", ist das nett. Aber es beantwortet nicht die eigentliche Frage.

Könnt ihr auch die Arbeitsweise exportieren?

Könnt ihr Agentendefinitionen, Tests, Freigaben, Logs, Memories, Prompts, Brand-Regeln und Prozessartefakte mitnehmen? In einem Format, das ein anderer Anbieter oder euer internes Team wiederverwenden kann?

Wenn nicht, ist der Exit nur formal vorhanden.

Europa ist hier nicht einfach langsamer

In vielen US-Debatten wirkt Regulierung wie ein Störgeräusch. In Europa ist sie eher eine Erinnerung daran, dass Organisationen aus mehr bestehen als Produktivität.

Der EU AI Act unterscheidet zwischen Providern und Deployern. Er verlangt AI Literacy für Menschen, die mit AI-Systemen umgehen. Er reguliert risikobasiert und zieht besondere Grenzen dort, wo Systeme Menschen, Rechte oder sensible Bereiche betreffen.

Das verändert die Managementfrage.

Wenn ihr einen Agenten einführt, seid ihr nicht einfach Käufer. Ihr werdet Betreiber, Gestalter, Beaufsichtiger und manchmal Mitverantwortliche eines Systems, das Arbeit verändert.

In Deutschland kommt § 87 BetrVG dazu. Der Betriebsrat hat mitzubestimmen bei Einführung und Anwendung technischer Einrichtungen, die dazu bestimmt sind, Verhalten oder Leistung von Arbeitnehmern zu überwachen.

Typische Agentenprodukte zeigen Nutzung pro Person, speichern Prompts, loggen Outputs, messen Qualität, zeigen delegierte Aufgaben und erzeugen Admin-Dashboards.

Man kann das "Adoption Analytics" nennen.

In Deutschland reicht der hübsche Name nicht.

Wenn ein System geeignet ist, Verhalten oder Leistung auszuwerten, ist es keine reine IT-Entscheidung mehr. Das ist keine deutsche Schrulle. Das ist eine Machtfrage mit Gesetzestext.

Und ehrlich gesagt: Das ist nicht nur hinderlich. Es zwingt Unternehmen, Fragen zu stellen, die sie auch ohne Betriebsrat stellen sollten.

Sicherheit heißt bei Agenten nicht nur Zugriffsschutz

Bei klassischer SaaS konnte man Security oft noch grob entlang von Login, Rollen, Berechtigungen und Datenhaltung denken.

Bei Agenten reicht das nicht.

Ein Agent liest nicht nur Daten. Er interpretiert Kontext, plant Zwischenschritte, ruft Tools auf und kann Aktionen auslösen: Mails schreiben, Tickets verändern, Dateien anlegen, CRM-Felder aktualisieren, Kampagnen vorbereiten oder Reports verschicken.

Damit verschiebt sich die Sicherheitsfrage: Was darf der Agent im Namen des Nutzers tun? Welche Aktionen sind read-only? Wo braucht es Freigabe? Welche Toolaufrufe werden geloggt? Wie wird indirekte Prompt Injection verhindert? Was passiert bei Memory Poisoning? Gibt es einen Kill Switch? Kann ein Lauf forensisch nachvollzogen werden?

OWASP behandelt Agentic AI deshalb zurecht als eigenes Bedrohungsfeld. Die Cloud Security Alliance schreibt inzwischen eigene Guides für Agentic AI Red Teaming. Das ist kein akademischer Luxus. Es ist die Folge davon, dass Kontext und Handlungsmacht zusammenfallen.

Ein Agent mit Leserechten ist ein Recherchewerkzeug. Ein Agent mit Schreibrechten ist ein Akteur. Ein Agent mit Memory, Tools und schwachen Freigaben ist ein Akteur, der lernt, handelt und später schwer erklärt werden kann.

Der europäische Agentenfilter

Für Entscheider heißt das: Der Filter muss kürzer sein als die Anbieterbroschüre und härter als die Demo.

Ich würde vor jeder größeren Agentenentscheidung fünf Fragen stellen.

1. Welche konkrete Arbeit delegieren wir?

Nicht: Welche AI-Fähigkeit wirkt am beeindruckendsten?

Sondern: Welche wiederkehrende Arbeit soll besser werden?

Recherche. Briefing. Kampagnenplanung. CRM-Pflege. Reporting. Angebotsvorbereitung. Kundensupport. Interne Wissenssuche. Freigaben.

Wenn der Workflow nicht benannt ist, wird der Agent zur Projektionsfläche.

2. Welche Daten und Rechte bekommt der Agent wirklich?

Ein Agent braucht Kontext. Aber er braucht nicht automatisch alles.

Die Prüffrage lautet: Welche Daten sind pro Use Case notwendig, welche Rechte werden geerbt, welche Logs entstehen, und wo werden Prompts, Outputs, Dateien, Embeddings und Memories gespeichert?

"Der Agent sieht alles, was Ihre Mitarbeitenden sehen" klingt im Sales-Call wie ein Vorteil. Im Sicherheitskonzept klingt es anders.

3. Wer trägt Verantwortung?

Bei Agenten verschwimmen Rollen. Der Modellanbieter liefert ein Basismodell. Der Plattformanbieter baut Agentenlogik. Die Agentur codiert Methode. Der Kunde bringt Daten, Zweck und Freigaben. Fachbereiche verändern Workflows.

Das kann funktionieren. Aber nur, wenn klar ist, wer Provider, Deployer, Integrator, Betreiber und fachlich Verantwortlicher ist.

"Wir nutzen nur GPT darunter" ist keine Compliance-Antwort. Es ist ein Hinweis darauf, dass jemand die Frage nicht verstanden hat.

4. Welche Aktionen sind technisch begrenzt und auditierbar?

Marketingversprechen über "humans at the helm" reichen nicht.

Darf der Agent nur lesen oder auch schreiben? Darf er veröffentlichen? Darf er Kunden kontaktieren? Darf er Budgets verändern? Darf er Daten exportieren? Gibt es Freigaben? Gibt es Logs für Plan, Toolaufrufe, Datenzugriffe, Entscheidungen und Outputs?

Wenn ein Agent handeln kann, aber keine brauchbare Aktionshistorie liefert, ist er kein Produktivsystem. Er ist ein sehr gut verpacktes Risiko.

5. Wie kommen wir wieder heraus?

Exit ist bei Agenten mehr als Datenexport.

Ihr müsst wissen, ob ihr Agentendefinitionen, Workflows, Prompts, Skills, Tests, Evaluationsdaten, Logs, Memories und erzeugte Assets mitnehmen könnt. Vor allem müsst ihr wissen, ob eure Teams nach zwölf Monaten noch erklären können, wie die Arbeit funktioniert, oder ob dieses Wissen still in der Plattform wohnt.

Bei Agenten ist der Lock-in nicht die Datei. Der Lock-in ist die gelernte Arbeitsweise.

Was das für den nächsten Anbietertermin heißt

Wenn ihr in den nächsten Wochen eine Agentenplattform bewertet, würde ich die Demo nicht mit "Zeigen Sie uns mal die Features" beginnen.

Ich würde mit fünf Sätzen anfangen:

1. Beschreiben Sie den konkreten Workflow, den Ihr Agent bei uns übernimmt.
2. Zeigen Sie, welche Daten er dafür wirklich braucht und welche er nicht sehen darf.
3. Legen Sie offen, wer für Systemlogik, Datenverarbeitung, Customizing und Betrieb verantwortlich ist.
4. Zeigen Sie die technischen Grenzen, Freigaben und Audit-Logs für jede relevante Aktion.
5. Erklären Sie, was wir nach zwölf Monaten exportieren können, wenn wir wechseln.

Wenn ein Anbieter darauf sauber antwortet, lohnt sich die nächste Stunde.

Wenn nicht, ist das auch eine Antwort.

Der eigentliche Punkt

Agentenprodukte werden gerade so verkauft, als ginge es um Produktivität.

Das stimmt. Aber nur zur Hälfte.

Ein guter Agent spart Zeit, verbindet Systeme und macht Arbeit flüssiger. Aber er berührt auch Daten, Rechte, Gewohnheiten, Verantwortlichkeiten und Macht. Er verändert, wer Arbeit sieht, wer Arbeit bewertet, wer Arbeit ausführt und wer Arbeit erklären kann.

Darum reicht der US-Filter nicht aus.

In Europa muss die Frage lauten:

Nicht nur: Ist das Infrastruktur?

Sondern: Ist diese Infrastruktur prüfbar, mitbestimmbar, begrenzbar und kündbar?

Wer darauf keine Antwort hat, kauft keinen Agenten. Er kauft Kontrollverlust mit schöner Oberfläche.

Quellenanker

• Nate Jones: "The 5-question filter I run every agent launch through", 29.04.2026.
• Nate Jones: "Every AI agent you use has the same hidden weakness", 04.04.2026.
• WPP: "WPP Open: the AI platform for marketing" und "WPP launches Agent Hub on WPP Open", 05.01.2026.
• Europäische Kommission: "AI Literacy - Questions & Answers" und "Navigating the AI Act".
• § 87 BetrVG, Mitbestimmungsrechte.
• OWASP GenAI Security Project: "Agentic AI - Threats and Mitigations".
• Cloud Security Alliance: "Agentic AI Red Teaming Guide".