Obsługa zgłoszeń z trzema agentami AI: triage, dokumentacja, odpowiedź i bramka człowieka
Jeden agent klasyfikuje zgłoszenie, drugi szuka odpowiedzi we własnej dokumentacji, trzeci pisze odpowiedź. Sama wychodzi tylko odpowiedź, która przeszła trzy warunki naraz. Resztę widzi człowiek, a każde pytanie bez pokrycia w dokumentacji staje się zadaniem do dopisania.
Autor
- Adrian HuniaWspółzałożyciel SEVENEDGE
- Opublikowano:
- Ostatnia weryfikacja:
- Wersja n8n:
- 2.8.4
W skrócie
Co robi
- Przyjmuje zgłoszenie przez webhook
- Klasyfikuje kategorię, wagę i nastrój według Twoich definicji
- Szuka odpowiedzi w Twojej dokumentacji i cytuje tylko pobrane strony
- Pisze szkic odpowiedzi wyłącznie na podstawie znalezionych faktów
- Przepuszcza automatycznie tylko pewne odpowiedzi na proste zgłoszenia, resztę daje człowiekowi
Czego nie robi
- Nie wysyła maila sam, tylko oznacza odpowiedź do wysłania
- Nie obiecuje terminów, zwrotów ani funkcji
- Nie przepuszcza zgłoszeń z hasłem do agenta piszącego
- Nie zastępuje systemu helpdesk
Czego wymaga
- n8n z node'ami LangChain (sprawdzone na 2.8.4)
- Klucz API Anthropic
- Publiczna dokumentacja produktu pod jednym adresem
- Arkusz Google i webhook na powiadomienia
Obsługa zgłoszeń z trzema agentami AI: triage, dokumentacja, odpowiedź i bramka człowieka
Jeden agent, który dostaje zgłoszenie i od razu odpisuje klientowi, robi naraz trzy różne rzeczy: ocenia, jak poważna jest sprawa, szuka odpowiedzi i pisze. Każda z nich psuje się inaczej. Ten workflow n8n rozdziela je na trzech agentów z osobnymi zadaniami i jedną bramką na końcu.

Triage: waga według definicji, nie według tonu
Pierwszy agent niczego nie odpisuje. Klasyfikuje zgłoszenie według definicji wag, które wpisujesz w ustawieniach (od critical do low plus needs_info). Dwie reguły robią tu największą różnicę:
An angry tone does NOT raise severity. A calm report of total data loss is still critical.
Druga: jeśli zgłoszenie jest zbyt ogólne, agent ustawia needs_info i wypisuje, czego brakuje, zamiast zgadywać.
Research: tylko strony, które naprawdę pobrano
Drugi agent dostaje narzędzie HTTP, które pobiera stronę dokumentacji i zwraca jej tekst. Ma próbować kilku sformułowań i przechodzić po linkach, maksymalnie przez 5 stron. Może cytować wyłącznie strony, które pobrał. To, co wywnioskował sam, trafia do osobnego pola inferred_notes.
Jeśli dokumentacja nie odpowiada na pytanie, agent ustawia found_answer na fałsz i opisuje lukę. To nie jest porażka. Każda taka luka idzie osobnym powiadomieniem jako zadanie do dopisania w dokumentacji.
Szkic: tylko słowa, żadnych nowych faktów
Trzeci agent pisze odpowiedź w języku klienta i według przewodnika tonu. Nie może podać faktu, którego nie znalazł research, i nie może obiecać terminu, zwrotu ani funkcji. Zdenerwowany klient dostaje krótszą i spokojniejszą odpowiedź, a nie więcej przeprosin.
Bramka
Odpowiedź przechodzi automatycznie tylko wtedy, gdy trzy warunki są spełnione naraz:
| Warunek | Wartość |
|---|---|
| pewność szkicu | high |
| dokumentacja zawiera odpowiedź | found_answer = prawda |
| waga zgłoszenia | równa autoSendMaxSeverity (domyślnie low) |
Wszystko inne idzie do człowieka z trzema linkami: wyślij, przepiszę sam, eskaluj do zespołu technicznego. Każde zgłoszenie, niezależnie od ścieżki, trafia do arkusza z wagą, decyzją i treścią szkicu.
Ograniczenia
Workflow nie wysyła maila. Ścieżka automatyczna oznacza odpowiedź jako gotową do wysłania i zwraca ją przez webhook. Wysyłkę trzeba podpiąć po stronie helpdesku albo dodać node pocztowy.
Webhook odpowiada dopiero po ostatnim kroku. Na ścieżce z człowiekiem oznacza to, że system, który wysłał zgłoszenie, czeka na kliknięcie albo dostaje timeout. W produkcji lepiej odpowiedzieć od razu i resztę przetwarzać w tle.
Narzędzie research pobiera dowolny adres, który agent wymyśli. Warto ograniczyć je do domeny dokumentacji.
Linki decyzji nie mają logowania, a komunikatory potrafią je otwierać przy budowaniu podglądu. W kanale z takimi wiadomościami warto wyłączyć podgląd linków.
Kiedy to nie ma sensu
Przy kilku zgłoszeniach tygodniowo i małej dokumentacji szybciej odpisać samemu. Workflow ma sens, gdy zgłoszeń są dziesiątki dziennie, część to powtarzalne pytania, a dokumentacja istnieje i jest publiczna. Zasady dzielenia pracy między agentów opisujemy w tekście każdemu agentowi trzeba powiedzieć, czego nie robi. Gdy obsługa zgłoszeń ma działać w Twoim helpdesku albo panelu, to już projekt automatyzacji procesów z AI.
Weź to do siebie
Jak to zacytować
Adrian Hunia (2026). Obsługa zgłoszeń z trzema agentami AI: triage, dokumentacja, odpowiedź i bramka człowieka. SEVENEDGE. https://sevenedge.pl/pl/workflows/obsluga-zgloszen-trzy-agenty-ai (dostęp: 5 listopada 2026)
Źródła
- n8n docs — AI Agentdokumentacja n8n
- n8n docs — Waitdokumentacja n8n
- n8n docs — Structured Output Parserdokumentacja n8n
Kto za tym stoi
Adrian Hunia
Współzałożyciel SEVENEDGE
Współzałożyciel SEVENEDGE. Projektuje i wdraża systemy biznesowe dla małych firm — od zarządzania produkcją po rejestrację czasu pracy. Pracuje na Next.js, FastAPI i PostgreSQL. SEVENEDGE działa bez podwykonawców: kod piszą dwaj właściciele.
Powiązane dokumenty
Inne przepływy, które opisaliśmy tak samo dokładnie.
- Przegląd umowy według Twojego playbooka: klauzula po klauzuli, z bramką dla prawnikaUmowa wpada do folderu, Claude wyciąga z niej klauzule, agent ocenia każdą względem Twoich stanowisk negocjacyjnych, a werdykt liczy kod. Przy pisaniu tego tekstu znaleźliśmy w opublikowanej wersji błąd, który gubił dwie z trzech ocen. Opisujemy go razem z poprawką.
- Agent pisarz i agent krytyk: pętla w n8n, która kończy się na rubryce, a nie na zmęczeniuJeden agent pisze, drugi ocenia według rubryki i reguł domu, a pętla wraca do pisarza, dopóki tekst nie przejdzie progu. Najważniejsze w tym workflow nie są prompty, tylko trzy warunki stopu i to, że krytyk nie ma prawa podbijać oceny, żeby pętla się skończyła.


