Agentenbasierter Media-Einkauf lässt sich ohne das richtige Fundament nicht skalieren. Erfahren Sie, wie Einkäufer und Verkäufer dies auf Databricks umsetzen.

Der Engpass im Mediaeinkauf ist heute nicht das Talent, sondern die Koordination

Jeden Tag wechseln Werbegelder in Milliardenhöhe den Besitzer – durch einen Prozess, der sich seit Jahrzehnten kaum verändert hat: E-Mails, Tabellenkalkulationen, PDFs und Telefonanrufe. Ein Einkäufer legt eine Kampagne fest, dann kontaktieren qualifizierte Teams Publisher, senden RFPs, warten auf Tarife, vergleichen Mediadaten und verhandeln Preise, bevor sie schließlich einen Schaltauftrag erteilen. Talentierte Fachkräfte verbringen die meiste Zeit mit der Koordination der Transaktion, anstatt sich auf die strategische und kreative Arbeit zu konzentrieren.

Die Reibungsverluste entstehen durch Fragmentierung. Es gibt keinen standardisierten Weg, um Inventar zu finden, Zielgruppen zu bewerten oder vertrauensvolle Beziehungen zu Partnern aufzubauen. Daher wird jede Verbindung zwischen Einkäufer und Verkäufer zu einer maßgeschneiderten Integration. Da diese Koordination Tage dauert, werden Entscheidungen oft auf der Grundlage von Informationen getroffen, die bereits Stunden oder Tage alt sind. Inventar, Preise und Zielgruppensignale ändern sich ständig, und bis eine Kampagne genehmigt ist, ist die beste Gelegenheit oft schon vorbei.

Der Aufstieg agentischer Workflows bietet diesen Teams die Möglichkeit, die manuelle, sich wiederholende Koordination aus der Gleichung zu streichen. So können sie ihre Zeit dort investieren, wo es am meisten auf ihr Urteilsvermögen ankommt: präziseres Targeting, bessere Creatives und Kampagnen, die nicht nur schneller starten, sondern auch effektiver sind.

Warum dies endlich lösbar ist und warum Standards wichtig sind

Die letzte KI-Welle hat Software hervorgebracht, die antwortet. Die nächste Welle bringt Software hervor, die handelt – Agenten, die ein Ziel verfolgen, Entscheidungen treffen, Tools aufrufen und in Ihrem Namen Transaktionen durchführen. Das ist genau die Koordinationsarbeit, in der der manuelle Mediaeinkauf ertrinkt: Briefings lesen, Publisher recherchieren, Tarife vergleichen, Preise verhandeln, den Auftrag erteilen. Zum ersten Mal können Multi-Agenten-Systeme mit LLMs und Protokollen wie MCP diesen Ablauf automatisch ausführen.

Aber Automatisierung allein reicht nicht aus. Die AAMP-Standards (Agentic Advertising Management Protocols) des IAB Tech Lab etablieren ein einheitliches Kommunikationsmuster: ein gemeinsames Vokabular für Inventar und Zielgruppen (AdCOM, die Taxonomien), ein gemeinsames Transaktionsprotokoll (OpenDirect, OpenRTB-Deals) und ein Registermodell für Entdeckung und Vertrauen. Sie könnten dies mit KI und ohne Standards zwischen zwei Parteien lösen. Standards sorgen jedoch dafür, dass sich die gesamte Branche gemeinsam weiterentwickelt, sodass jeder konforme Einkäufer-Agent mit jedem konformen Verkäufer-Agenten Transaktionen durchführen kann – so wie jeder Browser jede Website laden kann.

Die offenen Standards definieren, was Agenten einander mitteilen. Die nächste Frage ist, wo diese Agenten tatsächlich ausgeführt werden: ihr Zustand, ihre Modelle, ihre Identität, ihre Governance. Genau hier kommt Databricks ins Spiel.

Wir haben ein Beispiel für den agentischen Mediaeinkauf und -verkauf vollständig auf Databricks entwickelt. Autonome Einkäufer und Verkäufer finden einander, einigen sich auf den Preis und schließen Geschäfte ab. Es basiert auf dem offiziellen Open-Source-SDK des IAB Tech Lab, sodass kein Lock-in auf der Protokollebene stattfindet, und ist jetzt als Accelerator verfügbar, den Sie mit einem einzigen Befehl bereitstellen können. Die Anleitung finden Sie am Ende des Blogs.

Was gehört zu einem agentischen Mediaeinkauf?

Ein agentischer Mediaeinkauf ist eine einfache Transaktion mit drei Akteuren:

• Ein Einkäufer: ein Werbetreibender (oder seine Agentur) mit einer Kampagne: ein Budget, die zu erreichenden Zielgruppen und ein Preis, der nicht überschritten werden darf.
• Verkäufer: Publisher mit Werbeinventar, jeweils mit einem Katalog (einem Media-Kit mit Paketen und Produkten) und eigener Preisgestaltung.
• Ein Register: ein Verzeichnis, über das Einkäufer Verkäufer finden und Vertrauen aufbauen können, indem der Einkäufer identifiziert wird und festgelegt wird, welchen Zugang und welche Preise er erhält.

Der Kauf selbst ist ein kurzer Kreislauf: herausfinden, welche Verkäufer das richtige Inventar haben, den Preis bestimmen und das Geschäft abschließen (oder abbrechen). Heute erfolgt dieser Ablauf weitgehend manuell. Die von uns demonstrierte Umstellung besteht darin, ihn mit KI-Agenten auf beiden Seiten auszuführen.

Agenten verschiedener Unternehmen benötigen eine gemeinsame Sprache für Transaktionen, und genau hier können die offenen Standards des IAB Tech Lab einen Mehrwert bieten. Wir werden hier nicht auf die Details ihres SDKs eingehen, sondern uns stattdessen darauf konzentrieren, was erforderlich ist, um Einkäufer- und Verkäufer-Agenten auf Databricks auszuführen.

Ein vollständiges Ökosystem für Einkäufer- und Verkäufer-Agenten

Komplexe Agenten gehen weit über einfache Anfragen an ein Large Language Model hinaus. Damit diese Agenten eine Mediatransaktion durchführen können – was eine Vielzahl von Aufgaben wie die Planung einer Zielgruppe, die Aufteilung eines Budgets, das Finden von Publishern, das Einhalten einer Preisobergrenze und das Buchen des Deals umfassen kann –, benötigen Sie ein System zur Verwaltung von:

• Zustand: Briefings, Identitäten, Kataloge, Angebote und Aufträge, die dauerhaft gespeichert und transaktional korrekt sein müssen.
• Bereitgestellte Modelle: Governed Foundation Models, die die Agenten aufrufen können, mit dem jeweils passenden Modell für jede Aufgabe.
• Governed Data: die Katalog- und Zielgruppendaten, auf deren Basis die Agenten Entscheidungen treffen, inklusive Zugriffskontrollen.
• Identität und Vertrauen: Wer ist dieser Agent und was darf er sehen und tun?
• Observability: ein Trace jeder Entscheidung und jedes Tool-Aufrufs zur Fehlerbehebung und Überprüfung.

Dieses System kann aus den Komponenten eines Datenbankanbieters, eines Modell-Hosts, eines Governance-Tools, einer App-Plattform und eines Tracing-Dienstes zusammengestellt werden. Auf Databricks ist es eine einzige Plattform.

Wie sieht die richtige Architektur aus?

Beginnen wir mit einer Tatsache über diesen Markt: Die Einkäufer, die Verkäufer und das Register sind separate Einheiten. Das teilt das Problem in zwei Hälften: wie die Parteien miteinander kommunizieren und wo jede Partei tatsächlich ihre Seite der Transaktion ausführt. Die offenen Protokolle beantworten die erste Frage. Sie sind die Verbindung zwischen den Parteien, die für Entdeckung, Verhandlung und Abwicklung sorgt – und dort enden sie auch. Wo ein Agent ausgeführt wird, seinen Zustand speichert, seine Identität nachweist und verwaltet wird, ist Aufgabe der Plattform. Jede Partei verfügt also über eine in sich geschlossene Anwendung, die auf Databricks Apps basiert, ihren Zustand, ihre Identität und die von ihr ausgeführten Modelle besitzt und den anderen Parteien nur über die Protokolle begegnet. In den folgenden Abschnitten werden diese Teile nacheinander behandelt und es wird gezeigt, warum jeder einzelne dorthin gehört.

Databricks Model Serving: die Agenten-Crew

Unter der Haube ist der Einkäufer-Agent eine „Crew“ oder Gruppe von Spezialisten-Agenten, die mit CrewAI erstellt wurden. Die Crew arbeitet hierarchisch über drei Ebenen hinweg, wobei der Level-1-Agent Aufgaben an Level-2-Agenten delegieren kann und so weiter. Zu diesen Agenten gehören ein Level-1-Portfolio-Manager, der die Strategie festlegt und das Budget aufteilt, Level-2-Channel-Spezialisten, die sich auf den Einkauf eines bestimmten Mediums spezialisiert haben, und taktische Level-3-Mitarbeiter, die Zielgruppen planen und den Kauf ausführen. Sie werden auf Databricks Foundation Model APIs ausgeführt und sind je nach Komplexität der Aufgabe für die Verwendung von Claude-Modellen konfiguriert. Die Verwendung von Databricks Unity AI Gateway zur Ausführung dieser Agenten macht es einfach, das LLM, das jeden Agenten antreibt, zu ändern, ohne etwas anderes anpassen zu müssen.

Lakebase: Transaktionszustand für Agenten

Agenten benötigen zwei Dinge von ihren Daten: Kontext, auf dessen Basis sie handeln können, und einen Ort, an dem sie ihre Aktivitäten aufzeichnen können. Unser Einkäufer liest seine Briefings, jeder Verkäufer liest seinen Inventarkatalog und seine Preisregeln, und sie schreiben jeden gebuchten Auftrag zurück. Das ist klassisches OLTP, also haben wir es auf Lakebase verlagert, das serverlose Postgres von Databricks, das direkt neben dem Lakehouse läuft. Die Agenten lesen und schreiben den Zustand schnell mit Transaktionsgarantien, und da es sich um Postgres handelt, lassen sich die Verkäuferkomponenten ohne maßgeschneiderte Datenebene direkt integrieren. Und da Lakebase serverlos ist, skaliert es in Millisekunden automatisch, um Lastspitzen abzufangen. Agenten treffen nicht in gleichmäßigen Abständen ein, und Einkäufer können sich gleichzeitig an viele Verkäufer wenden, ohne dass vorab Kapazitäten bereitgestellt werden müssen.

Governance: Heute Lakebase, als Nächstes Unity Catalog

Derzeit nutzt diese Demo ausschließlich Lakebase. In der Praxis befindet sich Lakebase zwischen zwei verwalteten Unity Catalog-Grenzen. Beim Import werden Daten aus Unity Catalog-Tabellen in Lakebase geladen (Hydrierung) – das Inventar eines Verkäufers und seine durch ML-Modelle gesteuerte Preisgestaltung, die Kampagnenbriefings und Zielgruppendefinitionen eines Einkäufers. Beim Export wird der von den Agenten erzeugte Transaktionszustand – wer was zu welchem Preis gekauft hat – wieder mit Ihrer Reporting-Umgebung synchronisiert. Beide Richtungen laufen über von Databricks verwaltete Pipelines anstelle von fehleranfälligen, manuell geschriebenen ETL-Prozessen. Das macht es zu einem kontrollierten Kreislauf: Unity Catalog verfolgt automatisch die Lineage jeder Hydrierung und Synchronisierung, sodass Sie immer nachvollziehen können, welche Daten wohin verschoben wurden. Das Lakehouse bleibt an beiden Enden die Source of Truth, und Lakebase ist die operative, schnelle Bereitstellungsebene, auf der die Agenten ihre Transaktionen durchführen.

Identität und Vertrauen

Die Apps authentifizieren sich untereinander über OAuth – dem Mechanismus, der die Identität der jeweiligen App feststellt und überprüft – und ein Register weist jedem Käufer eine Vertrauensstufe zu. Diese Stufe entscheidet darüber, was ein Käufer überhaupt sehen kann: Ein unbekannter, öffentlicher Käufer erhält nur Preisspannen und kann keine Transaktionen durchführen; ein vertrauenswürdiger, verifizierter Käufer erhält exakte Preise und kann buchen. Ändert man den Vertrauensstatus des Käufers, kann dieselbe Kampagne, die zuvor auf Preisspannen beschränkt war, nun gebucht werden. Auf Databricks ist dieses Identitätskonzept nativ in die Funktionsweise von Apps und Datenzugriffen integriert. Wo das IAB-Referenz-SDK nach API-Schlüsseln verlangt, nutzen wir einfach die plattforminternen Service-Principals und OAuth, um uns nach aktuellen Best Practices zu authentifizieren – ohne zusätzlichen Entwicklungsaufwand.

Observability

Die Agenten-Crews sind für das MLflow-Tracing konfiguriert, was sich ganz einfach über einen einzeiligen CrewAI-Autolog-Hook implementieren lässt. Dadurch können wir die logischen Schritte, die Tool-Aufrufe, die gelesenen Preise und die Entscheidung über Kauf oder Nichtkauf bei jedem Agentendurchlauf erfassen. Für die Demo haben wir dies optional gehalten, aber genau so würden Sie ein autonomes System in die Produktion überführen, debuggen, optimieren und absichern wollen, wenn es um Budgetkontrollen geht.

Die agentenbasierte Einkaufs-App in Aktion

Verfolgen wir einen vollständigen Durchlauf für eine Kampagne. Wir beginnen mit der Übermittlung des Briefings des Werbetreibenden. In diesem Szenario handelt es sich um einen Q3 Brand Launch mit einem Budget von 200.000 $ für die Medientypen CTV und Linear TV sowie einer CPM-Obergrenze (Cost-per-Mille) von 38 $. Dieses Briefing wird an die Einkaufs-App gesendet, und die Agenten-Crew startet den Kaufprozess.

1. Budget planen: Der Portfolio Manager liest das Briefing und teilt die Ausgaben auf die Kanäle auf, wobei 120.000 $ für CTV und 80.000 $ für Linear TV bereitgestellt werden.

2. Zielgruppe übersetzen: Ein Spezialist ordnet die im Briefing in natürlicher Sprache beschriebenen Zielgruppen Standardsegmenten zu, die mit der IAB Tech Lab Audience Taxonomy abgeglichen werden: „Sportfans“ wird „Sports Enthusiasts“ zugeordnet und „Kaufinteressenten für Autos“ wird „Auto Intenders“ zugeordnet.

3. Verkäufer finden: Der Käufer sucht im Register nach Publishern: Verkäufer A (CTV) und Verkäufer B (Linear TV). Dies bestätigt die Identität des Käufers und legt seine Zugriffsebene fest.

4. Preis ermitteln: Ein Kanalspezialist fragt für jeden Kanal den jeweiligen Verkäufer über MCP an, gleicht das Zielgruppensegment mit einem verfügbaren Produkt ab und liest den verbindlichen Preis aus.

5. Buchen oder ablehnen: Es gilt eine einfache Regel: Buchen, wenn der Preis bei oder unter der Obergrenze von 38 $ liegt und die Produktzielgruppe übereinstimmt; andernfalls ablehnen.

Wie geht es weiter?

Was wir hier gezeigt haben, ist der Kern des Handels: die Agenten, die die Transaktionen abwickeln. Dieselbe Plattform ist jedoch auch der beste Ort, um die vor- und nachgelagerten Schritte aufzubauen: die Erstellung des Käufer-Briefings, die ML-Modelle zur Festlegung der Paketpreise des Verkäufers sowie die Modelle und Dashboards zur Schätzung von Einnahmen und Ausgaben. Die Lösung dieser Probleme hängt von kontrollierten Daten (governed data) und ML ab, die beide nativ in Databricks integriert sind. Unser Team wird das Repository kontinuierlich aktualisieren, um sicherzustellen, dass es sich parallel zum IAB Tech Lab weiterentwickelt, sobald neue AAMP-Funktionen veröffentlicht werden.

Selbst bereitstellen

Dieses System wird als Databricks Automation Bundle Accelerator bereitgestellt. Klonen Sie das Repository, richten Sie das Databricks CLI auf Ihren Workspace aus und führen Sie einen einzigen Befehl aus:

Verwenden Sie diesen Befehl, um die Apps und die Lakebase-Instanzen zu erstellen und bereitzustellen, die Daten einzuspielen und den Käufer über das Register mit den Verkäufern zu verbinden. Wenige Minuten später verfügen Sie über zwei aktive Verkäufer-Agenten, ein Register und eine Käufer-Konsole, die alle in Ihrem eigenen Workspace Transaktionen abwickeln.

Passen Sie das System von dort aus an Ihre Bedürfnisse an. Tauschen Sie Ihr eigenes Inventar, Ihre Preisregeln und Zielgruppen aus oder verbinden Sie die Lakebase-Ebene mit Ihrem echten Katalog und Ihren Modellen. Werden Sie selbst als Käufer oder Verkäufer aktiv und beobachten Sie, wie die Agenten reagieren: Ändern Sie einen Preis, passen Sie die Vertrauensstufe eines Käufers an, fügen Sie einen Verkäufer hinzu und verfolgen Sie die Verhandlung. Es ist eine funktionierende Vorlage, die speziell auf den agentenbasierten Medieneinkauf und -verkauf zugeschnitten ist.

Sehen Sie sich die 5-minütige Demo an und stellen Sie den Accelerator anschließend in Ihrem eigenen Workspace bereit.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag