Brief dla agenta: zbuduj i zweryfikuj pełny AI Travel Scout w n8n
Cel
Zbuduj w n8n pełny system AI Travel Scout na podstawie szkolenia Mateusza Jankowskiego:
- formularz zbiera email, opis podróży i częstotliwość monitorowania,
- AI parsuje opis do ustrukturyzowanych preferencji,
- preferencje trafiają do Data Table,
- scheduler cyklicznie znajduje rekordy do obsłużenia,
- workflow pyta SerpApi Google Hotels o hotele,
- AI rankinguje oferty i wybiera TOP 3 + najlepszy hotel,
- AI generuje przewodnik po miejscu,
- AI tworzy finalną rekomendację podróży,
- Gmail wysyła realny mail testowy,
- Data Table zapisuje rekomendację i
last_sent_at, - weryfikujesz end-to-end, w tym przez MCP/mail, że wiadomość dotarła.
To jest demo szkoleniowe. Priorytet: pokazać zamkniętą pętlę pracy agenta, nie budować produkcyjny SaaS.
Źródła
Przeczytaj przed pracą:
[lokalna ścieżka do materiałów źródłowych][lokalna ścieżka do materiałów źródłowych][lokalna ścieżka do materiałów źródłowych] AI scout - 2.json[lokalna ścieżka do materiałów źródłowych] przesłane od Mateusza w trakcie/Travel AI Scout - 1 (20.15).json[lokalna ścieżka do materiałów źródłowych] przesłane od Mateusza w trakcie/scout-3 (19.32).json
Granice bezpieczeństwa
- Nie proś o klucze API w promptcie.
- Używaj istniejących n8n credentials.
- Nie wysyłaj maili poza testowy adres wskazany przez Tomasza.
- Nie kasuj workflowów, tabel, credentiali ani backupów.
- Nie zapisuj sekretów w workflow JSON ani w raporcie.
- Jeśli czegoś brakuje, zatrzymaj się i wypisz brak, zamiast zgadywać.
- Wszystkie testy wykonuj na danych testowych.
Wymagane dostępy
- n8n MCP albo n8n REST API: create/update workflow, execute workflow, inspect executions.
- Filesystem: czytanie źródeł i zapis artefaktów do
n8n_demo/outputs/. - Gmail/mail MCP read-only: sprawdzenie, czy testowy mail dotarł.
- Opcjonalnie Docker/shell read: status/logi n8n.
- Opcjonalnie browser: awaryjna konfiguracja credentiali.
Tryb pracy agenta i subagentów
Nie wykonuj tego jako jednego monolitycznego zadania.
Podziel pracę na małe, niezależne części i deleguj je do subagentów Sonnet. Każdy subagent ma pracować w pętli:
scout / plan- przeczytaj właściwe źródła, zrozum aktualny stan, zaplanuj minimalny zakres,work- zbuduj lub popraw swoją część,test- uruchom test swojej części i zbierz dowód,work- popraw błędy,test- powtarzaj aż część działa albo masz jasno opisany blocker.
Każdy workflow / moduł musi być niezależnie przetestowany przez subagenta Sonnet, zanim zostanie włączony do testu end-to-end.
Minimalny podział subagentów Sonnet:
Sonnet 1: Intake workflow- formularz, parsing AI, normalizacja, insert do Data Table.Sonnet 2: Monitor + SerpApi + ranking- scheduler, filtr, query params, SerpApi, extract hotels, ranking AI, update tabeli.Sonnet 3: Recommendation + Gmail- recommendation input, Destination Guide, Travel Advisor, final body, Gmail send, final table update.Sonnet 4: n8n integration QA- walidacja node’ów, credentials, connections, execution logs, eksport workflowu.Sonnet 5: Mail/Data verification- weryfikacja przez mail/Gmail MCP, Data Table i raport dowodów.
Na końcu uruchom osobnego agenta Opus jako finalnego rewiewera całego flow. Opus ma sprawdzić:
- czy każdy subagent Sonnet dostarczył dowód testu,
- czy oba workflowy / wszystkie moduły działają razem end-to-end,
- czy realny testowy mail doszedł,
- czy Data Table została zaktualizowana,
- czy raport nie zawiera sekretów,
- czy demo można pokazać na spotkaniu.
Finalne potwierdzenie działania musi pochodzić z testów, nie z deklaracji. Jeśli coś nie działa, raport ma powiedzieć dokładnie gdzie, z jakim błędem i jaki jest następny krok.
Wymagane artefakty końcowe
Zapisz w n8n_demo/outputs/:
travel-scout-final.workflow.json- eksport workflowu/workflowów.travel-scout-test-report.md- raport z testów.travel-scout-known-issues.md- braki, ryzyka i rzeczy do ręcznego ustawienia.travel-scout-demo-summary.md- krótka wersja dla prowadzącego: co pokazać na spotkaniu.subagents/sonnet-intake-report.md- plan, wykonanie, testy i dowody dla intake.subagents/sonnet-monitor-ranking-report.md- plan, wykonanie, testy i dowody dla monitoringu/rankingu.subagents/sonnet-recommendation-gmail-report.md- plan, wykonanie, testy i dowody dla rekomendacji/Gmail.subagents/sonnet-integration-qa-report.md- walidacja n8n, credentials, connections i execution logs.subagents/sonnet-mail-data-verification-report.md- weryfikacja maila i Data Table.opus-final-verification.md- końcowe potwierdzenie Opus, że cały flow działa albo precyzyjny opis blockerów.
Architektura workflowu
Możesz zrobić to jako dwa workflowy albo jeden workflow z dwoma triggerami. Preferowane dla czytelności:
Workflow A: Intake / formularz
Formularz przyjmuje dane użytkownika i zapisuje preferencje do Data Table.
Klocki:
On form submission(formTrigger)AI Agent: Parse travel requestOpenAI Chat ModelCode: Normalize parsed requestData Table: Insert row
Workflow B: Monitor / ranking / rekomendacja / mail
Scheduler bierze rekordy z tabeli, sprawdza hotele, rankinguje, tworzy rekomendację i wysyła maila.
Klocki:
Schedule TriggerData Table: Take all rows from the tableCode: Add should_monitor_nowIF: Check if we should continueSet: Prepare query paramsHTTP Request: SerpApi Google HotelsCode: Extract hotels for AIAI Agent: Rank hotelsOpenAI Chat ModelCode: Parse AI rankingData Table: Update request with rankingCode: Prepare recommendation inputAI Agent: Destination GuideOpenAI Chat ModelCode: Parse Destination GuideAI Agent: Travel AdvisorOpenAI Chat ModelCode: Parse Final RecommendationGmail: Send EmailData Table: Update row with recommendation
Data Table
Użyj jednej tabeli demo, np. travel_scout_demo.
Wymagane pola:
emailoriginal_descriptionmonitor_frequencystatusdestination_countrydestination_regionsuggested_locationstravel_typetravel_styleactivitiespeople_countbudgettrip_durationpreferred_datespreferencesconstraintsinspiration_suggestionsassumptionsmissing_informationcheck_in_datecheck_out_dateadultscurrencylast_checked_attop_hotelsbest_hotelranking_summarybudget_summarydestination_guiderecommendation_subjectrecommendation_bodylast_sent_at
Używaj systemowego id, jeśli istnieje. Jeśli w starym imporcie występuje tylko LEGACY_id, użyj LEGACY_id. Nie aktualizuj id, LEGACY_id, LEGACY_createdAt, LEGACY_updatedAt.
Szczegółowy workflow krok po kroku
1. Formularz
Pola formularza:
email/EmailOpis wycieczkialbotravel_descriptionCzęstotliwość monitorowaniaalbomonitor_frequency
Wymagania:
- waliduj, że email istnieje,
- opis może być naturalnym językiem,
- częstotliwość może mieć wartości np.
once,daily,weekly.
2. AI Agent: Parse travel request
Cel: zamień opis użytkownika na JSON preferencji.
Zasady:
- nie zgaduj faktów,
- jeśli brakuje danych, wpisz je w
missing_information, - odpowiedź wyłącznie JSON,
- po polsku tam, gdzie to naturalne.
Oczekiwany JSON:
{
"destination_country": "",
"destination_region": "",
"suggested_locations": [],
"travel_type": "",
"travel_style": "",
"activities": [],
"people_count": "",
"budget": "",
"trip_duration": "",
"preferred_dates": "",
"preferences": [],
"constraints": [],
"inspiration_suggestions": [],
"assumptions": [],
"missing_information": [],
"check_in_date": "",
"check_out_date": "",
"adults": 2,
"currency": "PLN"
}
3. Code: Normalize parsed request
Cel:
- parsuj odpowiedź AI bezpiecznie,
- zachowaj
email,original_description,monitor_frequency, - ustaw
status = new, - ustaw
created_at, - przygotuj rekord do Data Table.
4. Data Table: Insert row
Wstaw nowy rekord do tabeli demo.
Po teście formularza sprawdź, że w Data Table istnieje rekord z testowym adresem.
5. Schedule Trigger
Do demo ustaw częstotliwość bezpiecznie, np. co minutę, ale aktywuj workflow dopiero do testu. Jeżeli testujesz manualnie w n8n, upewnij się, że ścieżka schedulerowa przechodzi z testowym rekordem.
6. Data Table: Take all rows from the table
Pobierz rekordy z tabeli demo.
7. Code: Add should_monitor_now
Dla każdego rekordu wylicz:
should_monitor_now,- uwzględnij
monitor_frequency, - uwzględnij
last_checked_at, - dla
status = newustawshould_monitor_now = true.
8. IF: Check if we should continue
Przepuść tylko rekordy z should_monitor_now == true.
9. Set: Prepare query params
Przygotuj parametry dla SerpApi Google Hotels:
q/hotel_query,check_in_date,check_out_date,adults,currency,max_price, jeśli da się wyciągnąć z budżetu,gl=pl,hl=pl.
Jeśli brakuje dat, ustaw bezpieczne daty testowe albo wypisz brak w raporcie. Nie wymyślaj dat jako faktu użytkownika; oznacz fallback jako testowy.
10. HTTP Request: SerpApi Google Hotels
Endpoint:
https://serpapi.com/search
Parametry:
engine=google_hotelsq={{ ... }}check_in_date={{ ... }}check_out_date={{ ... }}adults={{ ... }}currency=PLNgl=plhl=plapi_keyz credential/env, nie jawnie w JSON.
Test:
- sprawdź status HTTP,
- sprawdź, czy response zawiera listę hoteli/properties,
- jeśli SerpApi zwraca błąd, zapisz go w raporcie.
11. Code: Extract hotels for AI
Weź maks. 10 hoteli z odpowiedzi SerpApi.
Dla każdego zachowaj tylko potrzebne pola:
- nazwa,
- cena za noc / total,
- rating,
- liczba opinii,
- class / gwiazdki,
- amenities,
- link / source jeśli dostępny,
- lokalizacja jeśli dostępna.
Dołącz user_preferences.
12. AI Agent: Rank hotels
Cel: oceń hotele względem preferencji i wybierz TOP 3 + best hotel.
Zasady:
- nie wymyślaj hoteli,
- używaj tylko hoteli z wejścia,
- score 0-100,
- odpowiedź wyłącznie JSON.
Oczekiwany JSON:
{
"top_hotels": [
{
"rank": 1,
"name": "",
"score": 0,
"price_note": "",
"why_it_fits": "",
"risks": []
}
],
"best_hotel": {
"name": "",
"why_this_one": "",
"price_note": ""
},
"ranking_summary": "",
"budget_summary": ""
}
13. Code: Parse AI ranking
Cel:
- usuń markdown / code blocki,
- znajdź JSON,
- sparsuj,
- ustaw
last_checked_at, - przekaż
top_hotels,best_hotel,ranking_summary,budget_summary.
14. Data Table: Update request with ranking
Aktualizuj ten sam rekord po id albo LEGACY_id.
Zapisz:
top_hotels,best_hotel,ranking_summary,budget_summary,last_checked_at.
Nie aktualizuj pól technicznych ani identyfikatora.
15. Code: Prepare recommendation input
Ten krok jest krytyczny, bo po Data Table Update n8n może nie przekazać pełnego requestu.
Wymagania:
- pobierz dane z wcześniejszych node’ów przez stabilne odwołania typu
.all()[0]/.first(), - nie polegaj wyłącznie na bieżącym
$json, - przygotuj:
request_id,user_email,user_preferences,ranking.
Uwzględnij wskazówki z AI-Travel-Scout-Prompt-4.txt.
16. AI Agent: Destination Guide
Cel: lokalny przewodnik/researcher.
Nie robi:
- nie wybiera hotelu,
- nie rankinguje,
- nie pisze finalnego maila.
Odpowiedź wyłącznie JSON:
{
"destination_intro": "",
"interesting_facts": [
{"title": "", "description": ""}
],
"suggested_activities": [
{"name": "", "why_it_fits": "", "estimated_time": ""}
],
"local_tips": [""],
"activity_plan_notes": ""
}
17. Code: Parse Destination Guide
- obsłuż pola
output,text,response, - usuń markdown,
- sparsuj JSON,
- przekaż dalej
request_id,user_email,user_preferences,ranking,destination_guide.
18. AI Agent: Travel Advisor
Cel: finalna rekomendacja podróży po polsku.
Wykorzystaj:
- preferencje użytkownika,
- ranking hoteli,
- Destination Guide.
Nie rób:
- nie pobieraj hoteli ponownie,
- nie rób nowego rankingu,
- nie zmieniaj best hotel bez powodu,
- nie wymyślaj nazw, cen, ocen.
Odpowiedź wyłącznie JSON:
{
"email_subject": "",
"email_body": "",
"recommended_hotel": {
"name": "",
"why_this_one": "",
"price_note": "",
"pros": [],
"cons": []
},
"alternatives": [
{"name": "", "why_consider": ""}
],
"destination_highlights": {
"intro": "",
"facts": [],
"activities": []
},
"stay_plan": [
{"day": 1, "title": "", "plan": ""}
],
"final_note": ""
}
19. Code: Parse Final Recommendation
Wymagania:
- sparsuj JSON z Travel Advisor,
- zbuduj pełny
recommendation_body, nawet jeśliemail_bodyjest zbyt krótki, - użyj fallbacków z rankingu, guide i preferencji,
- ustaw
recommendation_subject, - ustaw
last_sent_at, - serializuj
destination_guidedo tekstu/JSON stringa.
Treść maila musi mieć konkretne sekcje:
- powitanie,
- podsumowanie podróży,
- rekomendowany hotel,
- dlaczego ten hotel,
- cena/budżet,
- plusy,
- minusy / ryzyka,
- alternatywy TOP 3,
- ciekawostki,
- aktywności,
- praktyczne wskazówki,
- krótki plan pobytu,
- końcowa uwaga.
20. Gmail: Send Email
Konfiguracja:
- Resource:
Message - Operation:
Send - To:
={{ $json.user_email }} - Subject:
={{ $json.recommendation_subject }} - Email Type:
Text - Message:
={{ $json.recommendation_body }} - Append n8n Attribution:
false, jeśli dostępne.
Do testu user_email musi być testowym adresem kontrolowanym przez Tomasza.
21. Data Table: Update row with recommendation
Po Gmail node aktualizuj tabelę danymi z Parse Final Recommendation, nie z bieżącego $json, bo Gmail może nie przekazać wszystkich pól.
Warunek:
id equals {{ $('Parse Final Recommendation').first().json.request_id }}- albo
LEGACY_id equals {{ $('Parse Final Recommendation').first().json.request_id }}
Zapisz:
destination_guiderecommendation_subjectrecommendation_bodylast_sent_at
Plan testów
Test 1: Struktura workflowu
Sprawdź, czy istnieją wszystkie wymagane node’y i połączenia.
Test 2: Credentials
Sprawdź, czy node’y mają podpięte credentials:
- OpenAI,
- Gmail,
- SerpApi/env.
Nie wypisuj sekretów w raporcie.
Test 3: Intake
- wyślij testowy formularz,
- sprawdź Data Table,
- potwierdź
status = new,email,original_descriptioni pola preferencji.
Test 4: SerpApi
- uruchom część monitorującą,
- potwierdź, że query jest sensowne,
- potwierdź, że zwrócono hotele.
Test 5: Ranking
- sprawdź
Parse AI ranking, - potwierdź TOP 3, best hotel, budget summary,
- potwierdź update tabeli.
Test 6: Destination Guide
- potwierdź poprawny JSON,
- potwierdź aktywności i wskazówki.
Test 7: Travel Advisor i final body
- potwierdź poprawny JSON,
- potwierdź, że finalny mail jest pełny i szczegółowy,
- jeśli AI zwróci krótki wstęp, Code node musi zbudować pełny mail z pól strukturalnych.
Test 8: Gmail send
- wyślij realny mail tylko na testowy adres,
- zapisz execution id,
- zapisz subject i timestamp.
Test 9: Mail MCP verification
Przez Gmail/mail MCP:
- wyszukaj mail po subject,
- potwierdź
from,to,date,subject, - opcjonalnie sprawdź, że body zawiera rekomendowany hotel.
Test 10: Final table update
Sprawdź w Data Table:
recommendation_subject,recommendation_body,destination_guide,last_sent_at.
Raport końcowy
travel-scout-test-report.md ma zawierać:
- data i godzina testu,
- URL/nazwa workflowu,
- nazwa tabeli,
- testowy adres odbiorcy zamaskowany częściowo, np.
to***@domain.com, - execution ids,
- wynik każdego testu,
- link/nazwa eksportu workflowu,
- lista braków i ryzyk,
- informacja, czy mail dotarł,
- linki/nazwy raportów subagentów Sonnet,
- wynik finalnej weryfikacji Opus.
Każdy raport subagenta Sonnet ma zawierać:
- zakres odpowiedzialności,
- źródła, które przeczytał,
- plan,
- wykonane zmiany,
- testy uruchomione samodzielnie,
- dowody: execution id, screenshot/log fragment, Data Table row id, subject maila albo inny konkretny ślad,
- wynik:
PASS,PASS_WITH_WARNINGSalboBLOCKED, - jeśli
BLOCKED: dokładny błąd i następny krok.
opus-final-verification.md ma zawierać niezależny werdykt Opus:
- czy raporty Sonnet są wystarczające,
- czy end-to-end przeszedł,
- czy mail dotarł,
- czy Data Table jest poprawnie zaktualizowana,
- czy workflow nadaje się do pokazania na szkoleniu,
- czy istnieją ryzyka, które trzeba powiedzieć publicznie.
Kryteria DONE
Demo jest gotowe, jeśli:
- agent zbudował/importował workflow,
- praca została podzielona na małe części i wykonana przez subagentów Sonnet,
- każdy workflow / moduł ma niezależny raport testowy Sonnet,
- przepływ przeszedł od formularza do Gmaila,
- mail testowy dotarł i zostało to zweryfikowane przez MCP,
- Data Table została zaktualizowana,
- Opus wykonał finalną weryfikację całego flow,
- istnieje eksport workflowu,
- istnieje raport testowy,
- istnieje
opus-final-verification.mdz jednoznacznym werdyktem, - żaden sekret nie trafił do raportu ani prompta.