Tutorial: Loops zamiast Prompts

Dlaczego Loops?

Prompt = one-shot. Mówisz coś -> dostajesz odpowiedź -> koniec.

Loop = continuous. Agent: obserwuje -> myśli -> działa -> powtarza, aż warunek STOP.

Loops zamieniają agenta z narzędzia "na zawołanie" w autonomicznego pracownika.

Część 1: Rodzaje Loops w Hermes

Loop #1: Cron — Najprostszy, harmonogramowy

Scheduler budzi agenta, agent dostaje prompt, wykonuje, kończy. Następny tick = nowa sesja.

hermes cron create "every 30m" \
  --prompt "Sprawdź czy mam nowe wiadomości email i sklasyfikuj je" \
  --name "email-watchdog"

Idealny do:

• Regularnych checków (co 15 min, godzinnie, codziennie)
• Raportów okresowych ("przygotuj summary dnia o 8 rano")
• Monitoringu zmian (ceny, kursy, statusy)

Wady: Za każdym razem nowa sesja (brak ciągłości kontekstu), limit 3 minuty.

Loop #2: Watchdog Script (no_agent=True) — Cichy, zero tokenów

Skrypt bash/python działa na schedulerze, nie zużywa tokenów LLM. Mówi tylko gdy ma coś do powiedzenia.

hermes cron create "every 5m" \
  --name "comments-watchdog" \
  --script /root/.hermes/profiles/ceo/scripts/check-comments.sh \
  --no-agent

Kluczowa zasada: empty stdout = cisza. Skrypt milczy gdy nic się nie zmieniło. Mówi tylko gdy wykryje zdarzenie.

Idealny do:

• Monitorowania plików/katalogów (czy pojawił się nowy plik?)
• Sprawdzania API (czy zmienił się kurs?)
• Watchdogów systemowych (czy proces żyje?)
• Skanowania kanban komentarzy

Wady: Tylko skrypt — nie ma LLM, nie podejmuje decyzji.

Loop #3: Background Process (notify_on_complete) — Długi, ciągły

Proces w tle z pełnym dostępem do narzędzi. Działa w jednej sesji — ma ciągłość kontekstu. Może trwać godzinami.

terminal(command="python /root/convertere/agents/monitor-prices.py", background=true, notify_on_complete=true)

Różnica od cron: cron to seria osobnych ticków, background to jedna ciągła sesja.

Idealny do:

• Długich procesów (migracja danych, scraping)
• Serwerów i listenerów (nasłuchiwanie na webhook)
• Monitorów z kontekstem (widzi całą historię sesji)

Wady: Nie przetrwa restartu agenta. Jeśli wyłączysz Hermes, proces ginie.

Loop #4: Delegate_task Background — Równoległe subprocesy

To samo co #3, ale subagent dostaje czysty kontekst i działa niezależnie. Możesz odpaślić 3 naraz.

delegate_task(goal="Monitoruj ten katalog i raportuj zmiany", context="...", background=True)

Idealny do:

• Równoległych zadań (agent A bada X, agent B bada Y)
• Zadań, które nie potrzebują twojego kontekstu
• Izolowanych workerów

Wady: Nie przetrwa restartu rodzica. Jeśli główny Hermes padnie, dzieci giną.

Loop #5: Kanban + Dispatcher — Pętla zadań

Najbardziej zaawansowany. Kanban board = kolejka zadań. Dispatcher (gateway lub cron) bierze gotowe zadania z boarda i przydziela workerom. Worker robi, oznacza done, bierze następne.

# Krok 1: Init board
hermes kanban init

# Krok 2: Dodaj zadania
hermes kanban create --title "Zrób A" --assignee developer
hermes kanban create --title "Zrób B" --assignee researcher

# Krok 3: Watchdog lub dispatcher ciągnie zadania
# (automat - dispatcher w gateway robi to sam)

Idealny do:

• Produkcyjnych workflowów z wieloma agentami
• Systemów, gdzie kolejność zadań wynika z priorytetu, nie harmonogramu
• Pracy zespołowej agentów (CEO tworzy, developer robi, CEO weryfikuje)

Loop #6: Hermes Spawning (tmux) — Pełny, interaktywny agent

Odpalasz drugą instancję Hermes w tmuxie. Działa jak osobny, pełnoprawny agent.

terminal(command="tmux new-session -d -s agent-x 'hermes'", timeout=10)
terminal(command="sleep 8 && tmux send-keys -t agent-x 'Monitoruj stronę i raportuj co 5 min' Enter")

Idealny do:

• Bardzo długich zadań (dni)
• Agentów, które muszą odpowiadać interaktywnie
• Prawdziwie niezależnych procesów

Wady: Duży narzut (pełna sesja Hermes), trzeba zarządzać tmuxem.

Loop #7: /goal — Wbudowana pętla Hermes Agent (najważniejszy mechanizm)

/goal to wbudowany w Hermes mechanizm pętli wewnątrzsesyjnej. Nie wymaga cronów, skryptów, tmuxów ani żadnej zewnętrznej infrastruktury. Działa wprost w rozmowie.

Jak to działa od środka

Hermes Agent ma w swojej logice coś takiego:

RUN_LOOP:
  1. Użytkownik mówi /goal "ZRÓB X"
  2. Agent zapisuje cel do kontekstu
  3. Agent myśli: "Jaki mam cel? ZRÓB X. Czy już zrobione? Nie."
  4. Agent wykonuje JEDNĄ akcję (tool call: web_search, terminal, write_file...)
  5. Agent dostaje wynik
  6. Agent myśli: "Czy cel ZRÓB X jest już osiągnięty?"
     - NIE → skok do kroku 4 (kontynuuje, wybiera następną akcję)
     - TAK → skok do kroku 8 (cel osiągnięty)
     - NIE PEWIEN → pyta użytkownika: "Czy to wystarczy?"
  7. Jeśli pyta i user mówi "tak" → cel osiągnięty
  8. Jeśli user mówi "nie"/"jeszcze X" → agent kontynuuje z doprecyzowaniem

To jest prawdziwa pętla — agent sam decyduje o kolejnych krokach, dopóki nie uzna zadania za wykonane. Nie musisz mu mówić "zrób krok 1, teraz krok 2, teraz krok 3" — mówisz cel, a on planuje i wykonuje.

Kluczowe cechy

Komendy zarządzania goal

Porównanie: /goal vs inne pętle

Kiedy używać /goal zamiast cron/background

Użyj /goal gdy:

• Chcesz, żeby agent sam zaplanował i wykonał złożone zadanie (np. "zbadaj rynek, przygotuj raport, zapisz plik")
• Zadanie wymaga wielokrotnego sięgania po różne narzędzia (najpierw web_search, potem write_file, potem terminal)
• Chcesz mieć kontrolę na bieżąco — możesz przerwać w każdej chwili
• Nie chcesz konfigurować cronów, skryptów, boardów

Użyj cron/background zamiast /goal gdy:

• Zadanie ma działać regularnie (co godzinę, codziennie)
• Zadanie ma działać poza twoją sesją (gdy śpisz lub nie ma cię przy komputerze)
• Zadanie ma być częścią większego workflow (kanban multi-agent)

Przykład: /goal w akcji

Ustawiasz cel w rozmowie:

/goal "Zbadaj rynek biohackingu w Polsce 2026.
Przygotuj raport w /root/convertere/reports/biohacking.md.
Uwzględnij: top 5 produktów, trendy, regulacje prawne,
głównych graczy. Jak skończysz, zapytaj czy publikować na 10s.pl."

Co się dzieje potem (automatycznie, bez twojego udziału):

Tura 1: Agent web_search("biohacking rynek Polska 2026")
        → Wyniki: 3 artykuły

Tura 2: Agent web_search("regulacje prawna suplementy Polska 2026")
        → Wyniki: 2 artykuły + 1 strona gov.pl

Tura 3: Agent web_search("top supplementy biohacking Polska ranking")
        → Wyniki: rankingi, opinie

Tura 4: Agent write_file(/root/convertere/reports/biohacking.md, ...)
        → Plik zapisany

Tura 5: Agent myśli: "Raport gotowy. Cel: zrobić raport i zapytać"
        → Mówi: "Raport gotowy. Publikować na 10s.pl?"

Zero promptów z twojej strony między krokiem 1 a końcem. Agent sam decyduje co robić dalej, w jakiej kolejności, i kiedy uznać że skończył.

/goal to nie to samo co długi prompt

Zwykły prompt:

"Zrób raport o biohackingu — najpierw poszukaj w sieci,
potem napisz plik, potem mi powiedz. Zrób research, potem...
a nie, zacznij od regulacji prawnych..."

→ Agent dostaje wszystko naraz, może zapomnieć część instrukcji,

albo zrobić tylko pierwszy krok czekając na kolejny prompt.

/goal:

/goal "Przygotuj raport o biohackingu i zapisz go."

→ Agent sam decyduje o kolejności kroków, dopasowuje narzędzia,

iteruje aż uzna że gotowe. Jeśli czegoś brakuje, sam sięga po więcej informacji.

To jest właśnie "loop zamiast prompt" — mówisz CO (cel),

nie JAK (instrukcja krok po kroku). Agent sam znajduje drogę.

Część 2: Praktyczne Wzorce

Wzorzec A: Watchdog-cichy (monitor zmian)

Cron z no_agent=True. Skrypt sprawdza stan, mówi tylko gdy zmiana.

Skrypt:
  1. curl API
  2. Porównaj z ostatnim stanem (z pliku)
  3. Jeśli zmiana → echo "Zmiana: ..."
  4. Zapisz nowy stan do pliku

Twój setup: używasz tego z check-comments.sh dla kanbana. Działa już — co 5 minut sprawdza czy są nowe komentarze na boardzie i milczy gdy pusto.

Wzorzec B: Agent-watchdog (z LLM)

Cron z promptem i skills. Agent myśli, decyduje, raportuje.

cronjob(
  schedule="every 1h",
  prompt="Sprawdź czy mam nowe maile na my.convertere.pl. 
          Sklasyfikuj je: faktura / zapytanie / spam. 
          Jeśli faktura → zapisz do /root/convertere/invoices/.
          Jeśli zapytanie → przygotuj odpowiedź.",
  skills=["web-research-techniques"],
  enabled_toolsets=["web", "file", "terminal"]
)

Wzorzec C: Ping-pong (background + notify)

Długie zadanie w tle z notyfikacją na koniec.

terminal(
  command="hermes chat -q 'Przetwórz wszystkie faktury z
           /root/convertere/invoices/ incoming/ i zapisz wynik
           do /root/convertere/reports/ -q'",
  background=true,
  notify_on_complete=true
)

Wzorzec D: Kanban-loop (ciągła praca z boarda)

CEO tworzy zadania na kanban. Watchdog lub dispatcher przydziela workerom. Worker robi, oznacza done. CEO weryfikuje i zamyka.

Cykl:
  1. [User] → "Zrób X"
  2. [CEO] → kanban create title="Zrób X" assignee=developer
  3. [Dispatcher/gateway] → kanban claim → spawn developer
  4. [Developer] → robi → kanban comment "[developer] ✅ Gotowe" → kanban complete
  5. [Watchdog CEO] → wykrywa nowy komentarz w done
  6. [CEO] → weryfikuje → kanban comment "[CEO] ✅ OK" → kanban archive/close

Wzorzec E: Goal-loop (wewnętrzna pętla sesji)

W trakcie rozmowy ustawiasz cel i pracujesz nad nim wiele tur.

Ty: /goal "Zrób research rynku supplementów w Polsce 2026
     i przygotuj raport w /root/convertere/reports/supplements.md.
     Jak skończysz, zapytaj czy publikować na 10s.pl."

Agent: (pracuje przez kilka tur - szuka, pisze, weryfikuje)
Agent: "Raport gotowy. Publikować na 10s.pl?"

Wzorzec F: Łańcuch cronów (chain)

Jeden cron zbiera dane, drugi przetwarza.

# Kolektor (np. co 6h)
cronjob(create, schedule="0 */6 * * *",
  name="collect-invoices",
  script="/root/convertere/scripts/fetch-invoices.sh",
  no_agent=true)

# Procesor (po kolektorze)
cronjob(create, schedule="0 7,13,19 * * *",
  name="process-invoices",
  prompt="Przetwórz faktury zebrane przez kolektora...",
  context_from=["collect-invoices-job-id"])

Część 3: Jak zintegrować z Hermes Agent — krok po kroku

Krok 1: Wybierz typ pętli

Krok 2: Stwórz pętlę

Przykład: loop co 15 minut sprawdzający kurs BTC i alertujący przy zmianie >5%.

Opcja A — Watchdog (cichy, 0 tokenów):

#!/bin/bash
# /root/.hermes/profiles/ceo/scripts/btc-watchdog.sh
STATE_FILE="/tmp/btc-price-last.txt"
PRICE=$(curl -s https://api.coingecko.com/api/v3/simple/price?ids=bitcoin\&vs_currencies=usd | python3 -c "import sys,json; print(json.load(sys.stdin)['bitcoin']['usd'])")

if [ -f "$STATE_FILE" ]; then
    LAST=$(cat "$STATE_FILE")
    CHANGE=$(echo "scale=2; ($PRICE - $LAST) / $LAST * 100" | bc)
    if [ "$(echo "$CHANGE > 5 || $CHANGE < -5" | bc)" -eq 1 ]; then
        echo "⚠️ BTC zmiana o ${CHANGE}% — obecnie \$${PRICE}"
    fi
fi
echo "$PRICE" > "$STATE_FILE"

cronjob(action="create", schedule="every 15m", name="btc-watchdog",
  script="/root/.hermes/profiles/ceo/scripts/btc-watchdog.sh",
  no_agent=true, deliver="telegram")

Opcja B — Agent z LLM (inteligentny monitor):

cronjob(action="create", schedule="every 1h", name="btc-monitor",
  prompt="Sprawdź cenę BTC (coingecko API).
    Porównaj z ceną sprzed godziny (zapisaną w /tmp/btc-history.txt).
    Jeśli zmiana >5% → napisz analizę: przyczyny, trend, rekomendacja.
    Jeśli zmiana <5% → milcz.
    Zapisz obecną cenę do /tmp/btc-history.txt.",
  enabled_toolsets=["web", "file"])

Krok 3: Połącz z resztą systemu

Z kanbanem: watchdog no_agent sprawdza nowe komentarze -> jeśli są, budzi CEO ->

CEO czyta -> tworzy zadania lub odpowiada.

Z Telegramem/Discordem: deliver="telegram" wysyła alerty na Twój czat.

deliver="all" wysyła na wszystkie podłączone platformy.

Z plikami: cron z workdir="/root/convertere" ładuje AGENTS.md z projektu

do kontekstu, więc agent zna reguły projektu.

Krok 4: Monitoruj i debuguj

hermes cron list              # Lista wszystkich cronów
hermes cron run <job_id>      # Ręczne uruchomienie
hermes cron pause <job_id>    # Pauza
hermes cron remove <job_id>   # Usuń

Dla background terminal:

process(action="list")        # Lista procesów
process(action="log", session_id="xxx")  # Logi
process(action="kill", session_id="xxx") # Ubij

Część 4: Twój konkretny setup (Convertere / 10s.pl)

Już masz:

• Watchdog co 5 min (comments-dense) — sprawdza kanban komentarze
• Watchdog co 1h (comments-sparse) — rzadszy przegląd
• Triage script (no_agent) — cichy gdy pusto

Możesz dodać:

1. Loop raportów finansowych — cron co tydzień (np. w niedzielę 20:00):

"Podsumuj faktury z convertere/invoices/ z tego tygodnia. przygotuj raport."

1. Loop monitoringu strony — cron co 1h:

"Sprawdź czy 10s.pl i convertere.pl odpowiadają HTTP 200. Jeśli nie → alert"

1. Loop cen energii — watchdog no_agent co dzień:

"Sprawdź prognozę ceny energii na TGE. Jeśli zmiana >10% → alert"

1. Loop klientów — kanban + dispatcher:

"Gdy na kanban pojawi się zadanie od klienta → automatycznie przypisz do sales/researcher"

Część 5: Zasady Dobrego Projektowania Loops

Zasada 1: Milcz gdy pusto (empty stdout = cisza)

Watchdog no_agent: jeśli nie ma zmiany, skrypt nic nie wypisuje.

Cron z LLM: jeśli nie ma zmiany, prompt każe milczeć.

Zasada 2: Jeden loop = jedna odpowiedzialność

Nie mieszaj monitorowania cen z wysyłaniem faktur. Dwa osobne crony.

Zasada 3: Stan w pliku, nie w pamięci

Crony nie mają pamięci między tickami. Zapisz stan (ostatnia cena, hash pliku, data) do /tmp/ lub pliku.

Zasada 4: Deliver z głową

• Watchdog no_agent: deliver="telegram" (krótki alert)
• Cron z LLM: deliver="origin" (wraca do sesji)
• Raport dzienny: deliver="all" (wszędzie)

Zasada 5: Testuj ręcznie przed automatem

hermes cron run <job_id>     # Odpala raz, widzisz output
hermes cron pause <job_id>   # Pauzuje

Nigdy nie ustawiaj produkcyjnego loopa bez ręcznego testu.

Zasada 6: Workdir = kontekst projektu

cronjob(create, schedule="...", workdir="/root/convertere", ...)

Ładuje AGENTS.md z projektu. Agent zna konwencje, ścieżki, reguły.

Podsumowanie

┌─────────────────────────────────────────────┐
│         Od Prompt do Loop                   │
├─────────────────────────────────────────────┤
│                                            │
│  jeden prompt ──────► jeden answer         │
│  jeden cron ─────────► cykl odpowiedzi     │
│  watchdog skrypt ────► cisza lub alert     │
│  background terminal ─► ciągła praca       │
│  kanban board ───────► workflow agentów    │
│  /goal ──────────────► cel osiągnięty      │
│                                            │
└─────────────────────────────────────────────┘

Klucz: wybierz narzędzie do zadania.

• Chcesz regularnie sprawdzać coś? → cron
• Chcesz monitorować cicho? → watchdog no_agent
• Chcesz długi proces? → background terminal
• Chcesz workflow zespołowy? → kanban
• Chcesz agenta który nie przestanie dopóki nie zrobi? → /goal