eMarketing AI od środka: nadzorca i zespół wyspecjalizowanych agentów AI

W artykule przeglądowym opisaliśmy już, co potrafi eMarketing AI: pisze posty, artykuły, e-maile i landing pages, prowadzi kampanie, newslettery i analitykę — a wszystko w jednym miejscu. To było spojrzenie od strony użytkownika. Teraz podejdźmy od strony realizacji i zobaczmy, jak zbudowana jest tu sztuczna inteligencja.

Marketing to mnóstwo niepodobnej do siebie pracy: napisać post w social mediach, złożyć listę kontrolną na launch, przeprowadzić audyt SEO, zestawić raport na realnych liczbach. Jeden «inteligentny» przycisk na wszystko naraz zwykle wychodzi przeciętny w każdym z tych zadań. Dlatego wewnątrz eMarketing AI nie ma jednego bota od wszystkiego, lecz zespół wąskich specjalistów pod kierunkiem nadzorcy — a wokół nich ta sama inżynierska dyscyplina, dla której całość powstała: realne dane projektu zamiast zmyśleń, koszt liczony dla każdego uruchomienia i jeden silnik starannie dostrojony pod zadanie.

Przez cały tekst przewija się jedna myśl: wartość nie tkwi w rozmiarze modelu, lecz w tym, jak zorganizowana jest praca wokół niego. Przejdźmy po kolei — od ogólnej mapy systemu po to, który model odpowiada za które zadanie.

Jak zbudowany jest cały system

Zanim zanurzymy się w szczegóły, warto zobaczyć mapę. Cała «inteligentna» część jest wydzielona do osobnej usługi: żyje obok głównej aplikacji, ale uruchamia się niezależnie. Panel marketera nie wywołuje modelu wprost: tworzy wpis o uruchomieniu (co trzeba zrobić i dla którego projektu), wrzuca zadanie do kolejki — i zwalnia użytkownika. Zadanie podejmuje dalej usługa AI.

flowchart TB
  subgraph Client["Jak trafia zadanie"]
    UI["Panel web marketera"]
    CRON["Harmonogram (cron)"]
  end
  subgraph App["Aplikacja główna"]
    API["Serwer (API)<br/>tworzy wpis o uruchomieniu"]
    Q["Kolejka zadań<br/>(na Redis)"]
  end
  subgraph AI["Usługa AI (osobna)"]
    SUP["Nadzorca<br/>(router)"]
    AG["Wyspecjalizowani agenci"]
  end
  LLM["OpenAI GPT-4o"]
  DB[("Baza danych<br/>treści · kampanie · metryki")]
  UI --> API
  CRON --> API
  API --> Q
  Q --> SUP
  SUP --> AG
  AG --> LLM
  AG --> DB
  API --> DB

Dlaczego przez kolejkę, a nie «wprost»? Wygenerowanie artykułu czy raportu zajmuje dziesiątki sekund — trzymanie przez cały ten czas otwartego połączenia jest niewygodne i zawodne. Kolejka daje trzy rzeczy naraz: użytkownik nie czeka z kręcącym się wskaźnikiem, każde uruchomienie jest widoczne i jego status można śledzić, a same zadania łatwo ponawiać i planować. Do harmonogramu jeszcze wrócimy.

Nadzorca i zespół specjalistów

Wewnątrz usługi AI nie ma jednego agenta «do wszystkiego». Zadanie wita nadzorca: patrzy, jakiego rodzaju praca przyszła, i oddaje ją właściwemu specjaliście. Każdy agent jest ekspertem od jednej rzeczy, ze swoim promptem, swoim formatem odpowiedzi i swoją «temperaturą» (miarą twórczej swobody modelu).

flowchart TB
  SUP(["Nadzorca wybiera właściwego specjalistę"])
  subgraph Team["Zespół agentów"]
    direction TB
    C["Treści<br/>posty · artykuły · e-maile · landing pages"]
    CH["Listy kontrolne<br/>launch · kampania · SEO"]
    D["Dokumenty<br/>plan · raport · analiza konkurencji"]
    S["SEO<br/>audyt strony + analiza wyników"]
    ST["Strategia<br/>go-to-market · pozycjonowanie"]
    E["Email<br/>tematy · e-maile · sekwencje"]
    A["Analityka<br/>wglądy na realnych metrykach"]
  end
  CHAT["Asystent czatu"]
  SUP --> Team
  CHAT -. "przekazuje zadanie" .-> SUP

Zespół wygląda tak: treści piszą posty, artykuły, e-maile, newslettery, teksty reklamowe, landing pages i artykuły SEO; listy kontrolne składają szczegółowe listy zadań na launch lub kampanię; dokumenty przygotowują plan marketingowy, raport, analizę konkurencji lub wytyczne marki; SEO audytuje stronę i rozbiera konkurentów w wyszukiwarce; strategia odpowiada za go-to-market i pozycjonowanie; email zajmuje się tematami z wariantami A/B i sekwencjami; analityka zamienia realne metryki projektu we wglądy.

Dlaczego nie jeden agent na wszystko? Bo zadania różnią się nie tematem, lecz formą wyniku: post to swobodny tekst, landing page to ustrukturyzowane bloki, raport to Markdown na realnych danych, audyt SEO to priorytezowana lista poprawek. Wąski specjalista ze sfokusowanym promptem robi swoje lepiej niż jeden prompt próbujący dogodzić wszystkim naraz. I taki system łatwiej się debuguje: każdy agent odpowiada za zrozumiały kawałek.

Życie jednego uruchomienia

Każde zadanie w systemie to uruchomienie o zrozumiałym cyklu życia. Wpis powstaje najpierw w stanie «oczekuje», potem trafia do kolejki, stamtąd bierze go agent, a na końcu wynik jest zapisywany i uruchomienie oznaczane jako «gotowe» (albo «błąd», jeśli coś poszło nie tak).

stateDiagram-v2
  state "Oczekuje" as P
  state "W kolejce" as Q
  state "Trwa" as R
  state "Gotowe" as D
  state "Błąd" as F
  [*] --> P: zadanie utworzone
  P --> Q: trafia do kolejki
  Q --> R: agent bierze je do pracy
  R --> D: wynik zapisany
  R --> F: błąd
  D --> [*]
  F --> [*]
  note right of R
    Mierzone są czas,
    zużyte tokeny
    i koszt w dolarach;
    zapisywany jest ślad do debugowania
  end note

Gdy agent pracuje, nadzorca mierzy czas, liczy zużyte tokeny i przelicza je na koszt w dolarach, a do uruchomienia można dołączyć ślad do debugowania. Brzmi zwyczajnie, ale to właśnie czyni wydatki przejrzystymi: zawsze wiesz, ile kosztował konkretny tekst czy raport, i możesz trzymać budżet w ryzach — zwłaszcza gdy generacji jest dużo.

Silnik treści: jedno zapytanie — trzy języki

Najbardziej obciążony specjalista to agent treści. Obsługuje dziewięć formatów (od postu w social mediach po landing page i artykuł SEO), pod wybraną platformę, ton i długość. Ale nie zaczyna od generowania — zaczyna od wczytania kontekstu projektu: głos marki, odbiorcy, branża. Bez tego tekst byłby gładki, ale bez twarzy.

flowchart TB
  IN["Zapytanie: typ · platforma · temat ·<br/>ton · długość · języki"] --> CTX["Wczytaj kontekst projektu<br/>głos marki · odbiorcy · branża"]
  CTX --> GEN["Wygeneruj tekst<br/>(GPT-4o, temperatura 0.8)"]
  GEN --> REV["Kontrola jakości"]
  REV --> SAVE["Zapisz jako osobny wpis<br/>ze wspólnym ID grupy"]
  SAVE --> MORE{"Więcej języków?"}
  MORE -->|tak| NEXT["Następny język"]
  NEXT --> GEN
  MORE -->|nie| DONE["Gotowe: po wpisie na język,<br/>zgrupowane razem"]

Na osobne słowo zasługuje wielojęzyczność. Poproś o tekst w kilku językach naraz (np. en, pl, ru), a agent nie tłumaczy jednej wersji — przechodzi pętlę dla każdego języka: generuje, sprawdza jakość, zapisuje jako osobny wpis — a wszystkie wersje łączy wspólny identyfikator grupy, żeby w panelu leżały razem. «Temperatura» jest tu wysoka (0.8): treść potrzebuje odrobiny kreatywności. Dla artykułu SEO agent dodatkowo analizuje wyniki wyszukiwania i podaje meta-tytuł, opis oraz slug, a landing page wraca już rozłożony na sekcje.

Odpowiedzi na realnych danych, a nie na zmyślonych liczbach

Tu kryje się kluczowa różnica wobec «inteligentnego, ale zmyślającego» pomocnika. Gdy w grę wchodzi raport albo analityka, agent opiera się nie na ogólnych rozważaniach, lecz na realnych danych Twojego projektu.

flowchart LR
  Q["Zapytanie: raport<br/>lub pytanie o analitykę"] --> AGENT["Agent dokumentów / analityki"]
  AGENT --> DATA["Tylko odczyt realnych danych projektu<br/>treści · kampanie · subskrybenci ·<br/>social · metryki · listy kontrolne"]
  DATA --> CHECK{"Czy są dane?"}
  CHECK -->|tak| ANS["Raport i wglądy<br/>na realnych liczbach"]
  CHECK -->|nie| HONEST["«Brak danych» +<br/>co warto podłączyć"]

Do raportu agent dokumentów wczytuje faktyczny stan projektu: ile treści i w jakich statusach, jakie kampanie, ilu subskrybentów, jakie konta społecznościowe podłączone, jak realizowane są listy kontrolne. I ma wprost polecone korzystać tylko z realnych danych: jeśli czegoś brakuje, tak właśnie pisze — «brak danych» — i podpowiada, co warto podłączyć, zamiast dorysować prawdopodobną, ale zmyśloną metrykę. Agent analityki działa tak samo: czyta metryki i zdarzenia (tylko do odczytu) i odpowiada na swobodne pytanie w rodzaju «dlaczego w zeszłym tygodniu spadł ruch» ludzkim językiem.

Asystent czatu jako dyspozytor

Czat w panelu to nie tylko «pogawędka o marketingu». Pod maską to agent, który potrafi wywoływać narzędzia: albo odpowiada tekstem, albo, jeśli poprosisz o wykonanie czegoś, przekazuje zadanie właściwemu specjaliście prosto z rozmowy.

stateDiagram-v2
  state "Czat" as C
  state Decide <<choice>>
  state "Narzędzie" as T
  [*] --> C: wiadomość użytkownika
  C --> Decide: odpowiedź modelu
  Decide --> [*]: odpowiedź tekstem (bez akcji)
  Decide --> T: potrzebne działanie
  T --> C: specjalista skończył, jest link
  note right of T
    Z rozmowy można przekazać
    zadanie dowolnemu specjaliście:
    lista kontrolna, treść, raport, SEO…
  end note

Napisz «złóż listę kontrolną na premierę produktu» — a czat sam zleci zadanie agentowi list kontrolnych i odeśle link do gotowego wyniku. Tak jedno okno spina cały zespół: nie musisz pamiętać, który agent za co odpowiada — wystarczy wyjaśnić, czego potrzebujesz. Czat zna kontekst projektu, pamięta historię rozmowy i odpowiada w trzech językach (angielski, polski, rosyjski). «Temperatura» jest umiarkowana (0.7) — żywo, ale na temat.

Audyt SEO i praca według harmonogramu

Kolejny specjalista to agent SEO, zbudowany jak mały automat z kilku kroków: pobierz stronę, przeprowadź audyt on-page, rozbierz konkurentów w wynikach i podaj priorytezowane rekomendacje.

stateDiagram-v2
  state "Pobranie" as S1
  state "Audyt" as S2
  state "Wyniki" as S3
  state "Rekomendacje" as S4
  [*] --> S1: pobierz stronę
  S1 --> S2: audyt on-page
  S2 --> S3: analiza konkurencji
  S3 --> S4: priorytety poprawek
  S4 --> [*]
  note right of S2
    Nagłówki, meta-tagi,
    gęstość słów kluczowych
  end note
  note right of S4
    Plus meta-tytuł, opis
    i slug dla nowej strony
  end note

Nie ogranicza się do «wiedzy z głowy»: agent naprawdę pobiera stronę i sięga do żywego wyszukiwania w sieci, więc rekomendacje opierają się na aktualnych wynikach, a nie na pamięci modelu.

A skoro każde zadanie to śledzone uruchomienie, łatwo ustawić je według harmonogramu. Przez cron można na przykład raz w tygodniu składać dajdżest analityczny albo regularnie przygotowywać porcję treści — system uruchomi to sam, bez naciskania przycisku.

Jeden model, wielu specjalistów

Ważny szczegół całej architektury: za tym wszystkim stoi jeden model — GPT-4o. Żadnego «zwierzyńca» modeli: jeden dostawca, jeden klucz, jeden silnik do wszystkich zadań. Zmienia się nie model, lecz to, jak dostraja się go do konkretnej pracy.

Głównym «pokrętłem» jest tu temperatura, miara swobody modelu. Dla list kontrolnych jest niska (0.3): tam potrzebna jest dyscyplina i przewidywalność. Dla dokumentów odrobinę wyżej (0.4). Dla czatu — umiarkowana (0.7). Dla treści — wysoka (0.8), bo właśnie tu przydaje się odrobina kreatywności. Do tego każdy agent ma swój limit długości odpowiedzi. Jeden model, starannie dostrojony pod zadanie, jest prostszy w utrzymaniu i tańszy w debugowaniu niż zestaw różnych.

Podsumowanie

Gdy zebrać to wszystko razem, wyłania się znajoma myśl: wartość bierze się nie z «większego modelu», lecz ze starannej inżynierii wokół niego. Zespół wąskich specjalistów zamiast jednego uniwersała. Realne dane projektu zamiast zmyślonych metryk. Kolejka i zrozumiały cykl życia zamiast «naciśnij i czekaj». Każde uruchomienie policzone w tokenach i pieniądzach. I jeden model, dostrojony osobno do każdego zadania.

To właśnie ta dyscyplina zamienia gadatliwy model w działające narzędzie do marketingu, któremu można powierzyć rutynę. eMarketing AI możesz wypróbować na eMarketingAI.pl albo złożyć samodzielnie ze źródeł na GitHubie. A jeśli potrzebujesz podobnego zestawu agentów wbudowanego w Twój produkt i Twoje dane — napisz do nas: [email protected].

Który model za co odpowiada

Na koniec — zestawienie: który model realizuje które zadanie. Tu jest on jeden na wszystkie zadania, więc tabela pokazuje w gruncie rzeczy co innego — pod jaką pracę i z jaką «temperaturą» jest dostrojony.