Jak zacząć z AAMP — buyer/seller SDK z GitHuba w praktyce

przez Łukasz | cze 7, 2026

Pięć wpisów o tym, jak to działa.

Ten jest o tym, jak to odpalić u siebie.

Cała gałąź Agentic Advertising była opisowa — czym jest AAMP, jak działają filary, jak wygląda transakcja. Ten wpis jest inny: bierzemy referencyjne SDK z GitHuba i patrzymy, co realnie masz w rękach, gdy chcesz z tym pracować. To nie jest zamknięty produkt — to otwarty wzorzec do zbudowania własnej implementacji.

Zastrzeżenie na wejściu: repozytoria AAMP są w aktywnym rozwoju (po I/O ekosystemu wyszło już AAMP 2.0 z „transaction-ready” SDK), więc szczegóły API i struktura zmieniają się między wersjami. Traktuj poniższe jako mapę, nie jako sztywną instrukcję — przy realnej pracy sprawdzaj README w repo, bo ono jest źródłem prawdy.

Co jest na GitHubie

Wszystko żyje pod organizacją IABTechLab. Repo-hub spina resztę:

  • IABTechLab/AAMP — centralny hub frameworku z linkami do pozostałych repozytoriów; każde ma niezależne wersjonowanie semantyczne.
  • IABTechLab/buyer-agent — referencyjny agent kupującego.
  • IABTechLab/seller-agent — referencyjny agent sprzedającego.
  • IABTechLab/agentic-direct — SDK transakcji bezpośrednich (na OpenDirect).
  • IABTechLab/agentic-audiences — schemat sygnałów audytoryjnych (dawniej UCP).

Zaczynasz od huba, żeby zobaczyć aktualne wersje, a potem schodzisz do konkretnego repo — najczęściej buyer-agent, bo to on jest najbliżej „uruchom i zobacz, jak działa”.

Na czym stoi buyer agent

Referencyjny agent kupującego jest zbudowany na CrewAI (framework do orkiestracji agentów) i protokole OpenDirect 2.1. Dostaje brief kampanii i przez pojedyncze API robi całą sekwencję: rozdziela budżet między kanały, bada inventory sprzedawców, buduje rekomendacje i rezerwuje deale.

W środku łączy dwa protokoły agentowe, każdy do czego innego — co opisaliśmy w anatomii transakcji: klient A2A do konwersacyjnego discovery i negocjacji, oraz klient MCP do strukturalnych wywołań narzędzi seller agentów. Do tego dochodzi klient rejestru, który obsługuje odkrywanie sprzedawców, pobieranie ich kart, rejestrację i weryfikację zaufania.

Czyli: jeśli chcesz zobaczyć w kodzie to, o czym pisaliśmy teoretycznie — jak agent znajduje kontrahenta, sprawdza jego status i negocjuje — to siedzi właśnie w tym repo.

Element, na który warto spojrzeć najpierw: klient rejestru

Z perspektywy „chcę zrozumieć, jak to się trzyma kupy”, najciekawszy jest klient rejestru. To on realizuje filar zaufania z wpisu o Agent Registry w praktyce:

Buyer agent rejestruje własną kartę (tożsamość, obsługiwane protokoły, lista capabilities z tagami). Przed transakcją odpytuje rejestr o status kontrahenta — czy jest zarejestrowany, jaki ma poziom zaufania, jaki identyfikator. Jeśli status to BLOCKED, transakcja nie rusza. Całość ma bufor z czasem życia, żeby nie odpytywać rejestru przy każdej operacji.

To dobry punkt startu, bo pokazuje cały cykl zaufania w jednym, zwartym kawałku — od rejestracji siebie, przez odkrycie drugiej strony, po decyzję „transaktuję / nie transaktuję”.

Co można odtworzyć: demo media planu

Najlepszym ćwiczeniem na rozgrzewkę jest powtórzenie demo, które pokazał IAB: agent buduje media plan z briefu, negocjuje ze sprzedawcą, potwierdza transakcję i wypycha ją do systemu zarządzania reklamą (w demie — Google Ad Manager). Repozytoria są pomyślane tak, żeby ten przepływ dało się u siebie odtworzić.

To jest moment, w którym opisowe „agent dogaduje deal” zamienia się w coś namacalnego — widzisz, jak brief wchodzi z jednej strony, a z drugiej wychodzi zarezerwowana transakcja, i co dzieje się pomiędzy.

Czego się spodziewać, a czego nie

Żeby uniknąć rozczarowania, dwie rzeczy warto przyjąć z góry.

To są implementacje referencyjne, nie gotowe systemy produkcyjne. Ich rolą jest pokazać, jak standardy AAMP składają się w działający przepływ — punkt wyjścia do własnej integracji, a nie produkt do wdrożenia bez zmian. Demo media planu działa, ale od dema do produkcji droga jest Twoja.

I druga: to żywy projekt. Wersje SDK się zmieniają, AAMP 2.0 dołożył transaction-ready agentów, kolejne wydania dołożą więcej. Cokolwiek tu opisałem, weryfikuj z aktualnym README — bo w repozytorium pod aktywnym rozwojem to ono, a nie żaden artykuł, jest źródłem prawdy.

Co z tego wynika

Agentowa reklama przestała być wyłącznie tematem do czytania — jest kod, który można pobrać, odpalić i prześledzić. Dla zespołu technicznego to najszybsza droga, żeby zrozumieć AAMP nie z opisu, lecz z działania: zacznij od IABTechLab/AAMP, zejdź do buyer-agent, obejrzyj klienta rejestru, odtwórz demo media planu.


Pojęcia ze słownika: AAMP · Buyer agent · Seller agent · Agent Registry · Agentic Direct · A2A · MCP

Agent kończy, ale zadania nie wykonał

Agent kończy, ale zadania nie wykonał

Objawy Agent odpowiada: „Przygotowałem i wysłałem potwierdzenie do klienta." Potwierdzenie nie zostało wysłane. Albo: „Zaktualizowałem wszystkie rekordy" — zaktualizował trzy z dwunastu. Albo: „Nie znalazłem żadnych zamówień" — bo narzędzie zwróciło błąd, którego nikt...

Agent zrobił coś, o co nikt nie prosił

Agent zrobił coś, o co nikt nie prosił

Objawy Operacja, której nikt nie zlecił. Dane wysłane pod adres, którego nie ma w żadnej konfiguracji. Rekord zmieniony poza zakresem zadania. Odpowiedź, z której wynika, że agent dostał instrukcje od kogoś innego niż ty. Cecha wspólna: technicznie wszystko zadziałało...

Agent zrobił to samo dwa razy

Agent zrobił to samo dwa razy

Objawy Ten syndrom różni się od pozostałych jedną rzeczą: objaw widzi klient, nie ty. Trzy identyczne wiadomości w skrzynce. Dwa zamówienia zamiast jednego. Podwójne obciążenie. Duplikaty rekordów, które ktoś zauważa tydzień później. W twoim dzienniku wszystko wygląda...

Agent gubi wątek w długim zadaniu

Agent gubi wątek w długim zadaniu

Objawy Pierwsze kroki idą wzorowo. Po kilkunastu agent zaczyna się rozjeżdżać. Przestaje przestrzegać reguły z promptu systemowego, której trzymał się na początku. Zmienia format odpowiedzi w połowie zadania. Wraca do czegoś, co już ustalił, i ustala to inaczej....

Agent podaje dane, których nie ma

Agent podaje dane, których nie ma

Objawy Numer zamówienia w idealnym formacie, którego nie ma w bazie. Kwota, której w dokumencie nie ma. Nazwa pola API, które nigdy nie istniało. Cytat z regulaminu, brzmiący dokładnie jak reszta regulaminu i w nim nieobecny. Cecha wspólna wszystkich tych przypadków:...

Działał wczoraj, dziś nie działa

Działał wczoraj, dziś nie działa

Objawy Nic się nie wywala. Nie ma wyjątków, nie ma timeoutów, dziennik wygląda tak samo jak zawsze. Po prostu odpowiedzi są gorsze. Postacie, w jakich to się objawia: Jakość. Agent zaczyna pomijać kroki, które wcześniej wykonywał, albo odpowiada ogólniej. Format....

Agent wybiera złe narzędzie

Agent wybiera złe narzędzie

Objawy Agent odpowiada nie na to pytanie. Pobiera listę zamówień, gdy pytano o jedno konkretne. Odpowiada z pamięci, choć miał sprawdzić w bazie. Albo sięga po właściwe narzędzie i wpisuje w argumenty coś, czego nie da się użyć. Sygnał, który odróżnia ten syndrom od...

Agent kręci się w kółko

Agent kręci się w kółko

Objawy Agent wykonuje kolejne obroty pętli, nie zbliżając się do zakończenia zadania. W dzienniku widać jedną z trzech postaci. Powtórzenie. To samo narzędzie, te same argumenty, raz za razem — czasem dziesiątki razy pod rząd. Oscylacja. Agent wywołuje na przemian dwa...