Każdemu agentowi trzeba powiedzieć, czego nie robi

Każdemu agentowi trzeba powiedzieć, czego nie robi#

Poradniki o systemach wieloagentowych mówią o nadawaniu ról. Dajesz jednemu agentowi rolę analityka, drugiemu rolę recenzenta, trzeciemu rolę arbitra i liczysz, że podział pracy zrobi się sam.

Nie robi się. Agent z rolą, ale bez granicy, wykona całe zadanie samodzielnie i wypluje wynik, który wygląda na kompletny. Trzej analitycy z rolami napiszą trzy warianty tej samej opinii, a arbiter dopisze czwarty.

Mamy trzy workflow zbudowane na tym wzorcu, każdy o innym kształcie. Kiedy zestawiliśmy ich prompty obok siebie, okazało się, że łączy je nie podział ról, tylko coś innego: w każdym prompcie stoi jawne zdanie o tym, czego ten konkretny agent robić nie ma.

Trzy kształty tego samego pomysłu#

:::

Trzeci kształt to iteracja: jeden agent wywoływany wielokrotnie na kolejnych elementach listy. Tak działa przegląd umowy — ten sam agent ocenia klauzulę po klauzuli, a agregacja i decyzja dzieją się poza nim, w kodzie.

Warto to zauważyć, bo „wieloagentowy" nie musi znaczyć „wielu różnych agentów". Może znaczyć jednego agenta z wąskim zadaniem, wołanego tyle razy, ile jest elementów.

Granica, nie rola#

Zestawmy początki promptów z trzech workflow.

You read ONE ticket and classify it. You do NOT answer it — a later specialist agent does that.

You research a support ticket against the team's own documentation before anyone drafts a reply. You do NOT write the customer-facing answer — that is the next agent's job.

You draft a support reply. Everything factual has already been researched — your job is wording, not investigation.

You are the adjudicator. You did NOT read the company's website and you must not pretend to: your entire input is their three reports.

Każde z tych zdań odbiera agentowi coś, co byłby w stanie zrobić. Triage potrafiłby odpowiedzieć na zgłoszenie. Researcher potrafiłby napisać odpowiedź. Redaktor potrafiłby sam poszukać faktów. Arbiter potrafiłby wejść na stronę firmy i wyrobić sobie własne zdanie.

Arbiter, który nie widział źródła#

Najciekawszy przypadek to workflow równoległy. Trzej recenzenci czytają stronę firmy przez trzy różne soczewki i każdy zwraca raport w tej samej strukturze:

Potem wchodzi arbiter, i tu jest cała sztuczka: jego jedynym wejściem są te trzy raporty. Nie ma dostępu do strony firmy.

To nie jest oszczędność tokenów. Gdyby arbiter mógł doczytać źródło, wyrobiłby sobie własne zdanie i trzy soczewki stałyby się dekoracją. Odcięcie go od źródła sprawia, że jedyne, co może zrobić, to porównać cudze wnioski — a to znaczy, że rozbieżność między recenzentami staje się wykrywalna.

Schemat wyjścia arbitra to potwierdza:

{
  "verdict": "...",
  "verdict_reason": "...",
  "dealbreaker_triggered": "...",
  "disagreements": [],
  "collective_blind_spots": [],
  "top_strengths": [],
  "top_risks": [],
  "open_questions": []
}

disagreements i collective_blind_spots to pola, których nie da się wypełnić, jeśli miało się jedno źródło i jedną opinię. Istnieją wyłącznie dlatego, że wejściem były trzy niezależne raporty.

Bramka człowieka i gdzie ją postawić#

We wszystkich trzech workflow jest moment, w którym wynik czeka na człowieka. Ale stoi w innym miejscu, i to nie przypadek.

Reguła jest prosta: bramka stoi tam, gdzie kończy się odwracalność. Wiadomość wysłana do klienta jest nieodwracalna, więc przed nią stoi człowiek. Raport w arkuszu jest odwracalny, więc nie stoi.

Przegląd umowy pokazuje wariant pośredni. Ma gałąź automatycznego przepuszczania dla klauzul, które nie naruszają twardych limitów i mieszczą się w standardowych pozycjach. Człowiek widzi tylko to, co wymaga decyzji. To jest różnica między bramką a wąskim gardłem: bramka przepuszcza oczywiste, wąskie gardło zatrzymuje wszystko.

Konfiguracja jako parametr, nie jako prompt#

W każdym z trzech workflow to, co czyni go użytecznym dla konkretnej firmy, siedzi w node'cie Set, a nie w treści promptu.

productContext        czym jest produkt i dla kogo
severityDefinitions   definicje priorytetów, dosłownie

ourSide     po czyjej stronie stoisz
playbook    standardowe pozycje negocjacyjne
hardLimits  klauzule, których nie przepuszczamy

reviewPurpose   po co w ogóle na tę firmę patrzymy

Prompt agenta triage'ującego zgłoszenia mówi wprost:

SEVERITY DEFINITIONS (use these exactly, not your own intuition)

To zdanie jest tam, bo bez niego model użyje własnego wyczucia, co znaczy „krytyczny". Twoje definicje priorytetów są prawdopodobnie inne niż jego. Wskazanie parametru i dopisanie „użyj tego, nie swojej intuicji" jest tańsze i pewniejsze niż opisywanie priorytetów prozą w prompcie.

Kod robi to, co deterministyczne#

Statystyka, która nas zaskoczyła przy porównywaniu tych trzech plików:

Node'ów z kodem jest wszędzie więcej niż agentów, w przeglądzie umowy dziesięciokrotnie. Agenci robią to, co wymaga rozumienia tekstu. Wszystko pozostałe — normalizacja wejścia, scalanie raportów, liczenie, rozgałęzianie, budowanie rekordów, logowanie — robi kod.

To jest właściwy podział. Model wywołany do policzenia sumy albo sprawdzenia progu jest droższy, wolniejszy i mniej niezawodny niż trzy linijki JavaScriptu. A przy okazji każde takie wywołanie to kolejne miejsce, w którym coś może pójść inaczej niż ostatnim razem.

Pole na niewiedzę#

We wszystkich trzech schematach wyjścia jest pole, w którym agent może przyznać, że czegoś nie wie.

• recenzenci mają could_not_verify
• arbiter ma open_questions
• agent researchujący dokumentację ma docs_gap
• agent redagujący odpowiedź ma confidence_in_draft i confidence_reason

To nie jest kosmetyka. Model, który nie ma gdzie umieścić luki, wypełni ją w polu decyzyjnym — bo schemat wymaga tam wartości, a on nie ma mechanizmu, żeby odmówić. Osobne, wymagane pole na niewiedzę daje mu miejsce, w którym może się przyznać, zamiast zgadywać tam, gdzie to kosztuje.

docs_gap w workflow obsługi zgłoszeń ma jeszcze jedno zastosowanie. Zbierany przez kilka tygodni daje listę pytań, na które dokumentacja nie odpowiada — czyli backlog dla osoby, która ją pisze. Agent przy okazji odpowiadania klientom mierzy jakość Waszych własnych materiałów.

Kiedy to jest wariant, a kiedy duplikat#

Zgłosiliśmy wszystkie trzy do biblioteki template'ów n8n. Dwa zostały przyjęte. Trzeci wrócił z uzasadnieniem:

After reviewing it, we've noticed that it's very similar to some of your other templates, with only small changes (mainly a few nodes swapped out). To keep the directory high-quality and diverse, we try to avoid publishing multiple near-duplicates.

To jest informacja warta zapamiętania, bo nie ma jej w oficjalnej dokumentacji: biblioteka odrzuca nie tylko za wady techniczne, ale i za bliskie podobieństwo do Twoich wcześniejszych, już przyjętych zgłoszeń. Publikując serię workflow z jednego wzorca, sam sobie zajmujesz miejsce.

Recenzent podpowiedział rozwiązanie i jest ono dobre także poza kontekstem biblioteki: zamiast osobnego wpisu, dołóż wariantowość do istniejącego — kroki konfiguracyjne albo opcjonalne node'y do wpięcia zależnie od przypadku użycia.

Ograniczenia#

Brak pomiaru, czy trzy soczewki dają lepszy wynik niż jedna. Nie prowadziliśmy porównania z pojedynczym agentem na tym samym materiale. Wzorzec ma sens teoretycznie i wygląda dobrze w praktyce, ale nie mamy liczb.

Koszt rośnie liniowo z liczbą agentów. Trzej recenzenci to trzy pełne przebiegi po materiale plus czwarty na arbitraż. Przy dużych wolumenach to jest realna pozycja w rachunku.

Bramka człowieka jest tak dobra, jak człowiek za nią. Jeśli zatwierdzający klika bez czytania, cały wzorzec sprowadza się do wolniejszego pojedynczego agenta. Warto mierzyć, ile zatwierdzeń wraca z poprawką — jeśli zero, bramka jest fikcją.

Nie ma obsługi sytuacji, w której agenci się nie zgadzają fundamentalnie. Arbiter zgłosi rozbieżność, ale workflow nie ma ścieżki eskalacji do drugiej rundy z dodatkowym kontekstem.

Prompty są długie i to jest dług. Każdy z nich zawiera kilkaset słów instrukcji. Zmiana definicji priorytetów w jednym miejscu wymaga sprawdzenia, czy nie kłóci się z czymś w drugim.

Do czego to się sprowadza#

Wieloagentowe workflow nie działa dlatego, że ma kilku agentów. Działa dlatego, że każdy z nich ma wąsko zdefiniowane wejście, wymuszony kształt wyjścia, jawnie odebrane kompetencje, których nie ma używać, oraz miejsce, w którym może przyznać się do niewiedzy.

Jeśli któregoś z tych czterech brakuje, dostajesz kilku agentów robiących to samo trochę inaczej — czyli wolniejszy i droższy sposób na jedną opinię.