Wróć do panelu
Architektura systemu · Plan

Buduj wokół intencji,
nie wokół agentów

Systemowy model łączenia junior agentów w spójne workflow — oparty na jednej kanonicznej sprawie, warstwie intencji i agentach-normalizatorach. Dokument jest żywym planem: agenty oznaczone ⚠ DO ZBUDOWANIA wynikają z analizy use case'ów.

AML / Compliance Architektura pipeline'u Canonical ctx Istniejące agenty Do zbudowania
Problem

Dlaczego intuicyjnie złożony workflow nie działa

Agenty działają poprawnie lokalnie, ale globalnie się rozjeżdżają — bo brakuje wspólnej struktury sprawy i warstwy intencji.

🔴

Każdy agent pyta o inne dane, w innym momencie

System pyta o KRS, potem o nazwę, potem o PESEL — bo każdy junior agent ma własne wejście bez wiedzy o tym, co już zebrały poprzednie. Użytkownik nie rozumie, dlaczego te pytania się pojawiają.

🔴

Brak wspólnego obiektu sprawy (ctx jest chaosem)

Jeden agent produkuje beneficjenci (lista), następny oczekuje płaskiego pesel. Nie ma konwencji kluczy, więc agenty nie widzą nawzajem swoich danych.

🔴

Workflow to narzędzia, nie proces

Zielony przycisk „przekazuje" to akcja techniczna, a nie krok rozumiany przez użytkownika. System nie pyta „co chcesz osiągnąć?" — od razu uruchamia agenty, zanim wiadomo dla kogo i po co.

Rozwiązanie: trzy elementy wystarczą

Canonical Case Model — jeden słownik kluczy ctx dla wszystkich agentów. Intake Agent — jeden agent zbierający dane na starcie. Szablony intencji — gotowe senior agenty dla każdego celu, zamiast ręcznego składania.

Krok 1 — Konwencja (nie kod)

Canonical Context Model — wspólny słownik kluczy

Każdy agent (istniejący i nowy) trzyma się tego zestawu nazw kluczy ctx. To README-owa konwencja — nie nowa baza danych, nie migracje.

canonical-ctx.json — konwencja kluczy
// ── Identyfikacja podmiotu ──────────────────────────────────
"podmiot_typ"      // "osoba" | "spolka" | "nieznany"
"podmiot_nazwa"    // pełna nazwa firmy lub osoby
"podmiot_krs"      // numer KRS (gdy spółka)
"podmiot_pesel"    // PESEL (gdy osoba fizyczna)
"podmiot_nip"      // NIP (opcjonalnie)

// ── Intencja i zakres ───────────────────────────────────────
"intencja"         // "screening" | "due_diligence" | "monitoring" | "onboarding"
"zakres_analizy"   // ["knf", "krz", "policja", "crbr", ...]

// ── Dane beneficjenta (po CRBR + wyodrębnieniu) ─────────────
"podmiot_nazwa_osoby"  // "Kowalski Jan" — dla checków osobowych
"query"            // alias: imię+nazwisko lub nazwa — dla agentów bez canonical klucza

// ── Wyniki checków (produkowane przez istniejące agenty) ─────
"knf_status"       // "brak_ostrzezen" | "ostrzezenie" | "blad"
"poszukiwani_status" // "brak_wynikow" | "znaleziono" | "blad"
"krz_status"       // "brak_wynikow" | "znaleziono" | "blad"
"beneficjenci"     // lista z CRBR: [{imie, nazwisko, pesel, ...}]

// ── Wynik syntetyczny (produkowany przez konsolidację) ───────
"ryzyko_poziom"    // "niskie" | "srednie" | "wysokie" | "krytyczne"
"alerty"           // [{zrodlo, opis, powaga}]
"podsumowanie"     // jeden akapit po polsku

Istniejące agenty już produkują te dane — tylko pod różnymi nazwami. Nowe agenty piszemy pod ten słownik od razu. Pole pipeline_source w manifestach pozwala mapować stary klucz na nowy bez zmiany kodu agenta.

Kroki 2–4 — Nowe junior agenty

Trzy agenty domykające lukę

Każdy rozwiązuje konkretny problem systemowy — nie tylko AML. Działają razem lub osobno.

intake-podmiotu
Intake podmiotu — rozpoznanie i normalizacja
⚠ DO ZBUDOWANIA
Cel
Jedyne miejsce w systemie, które rozmawia z użytkownikiem na początku. Zbiera minimum identyfikacyjne i normalizuje do canonical ctx. Eliminuje chaos „każdy agent pyta o co innego".
Wejście
podmiot_wejscie opis_sprawy (opcjonalne)

Jedno pole swobodne — może być KRS, PESEL, NIP, nazwa, opis. Agent sam wykrywa typ.

Wyjście
podmiot_typ podmiot_nazwa podmiot_krs podmiot_pesel intencja zakres_analizy
Logika
10 cyfr → KRS (spółka) · 11 cyfr → PESEL (osoba) · inaczej → nazwa, dopytaj o typ. Intencja wykrywana z opisu lub domyślna = pełny check. Python stdlib, brak zależności zewnętrznych.
wyodrebnij-beneficjenta
Wyodrębnienie beneficjenta z listy CRBR
⚠ DO ZBUDOWANIA
Cel
Awansuje pola wybranego elementu z listy beneficjenci do płaskich kluczy ctx. Rozwiązuje systemowo problem lista→skalar dla każdego pipeline'u z listą obiektów.
Wejście
beneficjenci

Z poprzedniego agenta (CRBR). Jeśli beneficjentów > 1, disambiguation pyta użytkownika który wybrać — reużywając istniejący mechanizm pipeline.

Wyjście
podmiot_pesel podmiot_nazwa_osoby query
Settings
source_list (domyślnie: beneficjenci) · source_index (domyślnie: 0) · pola: field_pesel, field_imie, field_nazwisko. Konfigurowalny dla innych typów list.
konsolidacja-wynikow-aml
Syntetyczna ocena ryzyka AML
⚠ DO ZBUDOWANIA
Cel
Zamienia 4 osobne statusy z różnych źródeł w jedną syntetyczną ocenę ryzyka. Użytkownik widzi jeden wynik, nie cztery osobne raporty.
Wejście
knf_status knf_ostrzezenia poszukiwani_status poszukiwani_wyniki krz_status krz_znalezione_wiersze

Zbiera automatycznie co znajdzie w ctx — agnostyczny wobec tego, które checki zostały uruchomione.

Wyjście
ryzyko_poziom alerty podsumowanie sprawdzone_zrodla data_sprawy
Logika
Deterministyczna, bez LLM. Reguły: jeśli cokolwiek status = "znaleziono"ryzyko_poziom = "wysokie". Mnożenie alertów z wielu źródeł → "krytyczne". Python stdlib.
Krok 5 — Senior agenty jako szablony intencji

Każda intencja = jeden gotowy senior agent

Zamiast budować skomplikowany router kodu — każdy cel użytkownika ma swój senior agent z gotowym pipeline'em. Biblioteka rośnie razem z use case'ami.

AML — Spółka (pełny)
·intake-podmiotu
wyszukiwanie-krs-po-fragmencie-nazwy
pobieranie-danych-crbr
wyodrebnij-beneficjenta
sprawdzanie-ostrzezen-knf
sprawdzanie-poszukiwanych-policja
wyszukiwanie-w-krz
konsolidacja-wynikow-aml
AML — Osoba fizyczna
·intake-podmiotu
sprawdzanie-poszukiwanych-policja
wyszukiwanie-w-krz
sprawdzanie-ostrzezen-knf
konsolidacja-wynikow-aml
Screening — Spółka (szybki)
·intake-podmiotu
wyszukiwanie-krs-po-fragmencie-nazwy
sprawdzanie-ostrzezen-knf
konsolidacja-wynikow-aml
Screening sankcyjny (przyszłość)
·intake-podmiotu
ocena-ryzyka-sankcyjnego ⚠
konsolidacja-wynikow-aml

Konwencja: każdy nowy use case = nowy senior agent. Nie zmieniane są istniejące agenty — tylko dodawane nowe szablony. Pole intencje w manifeście każdego junior agenta (np. ["screening", "aml_spolka"]) stanie się podstawą pod przyszły auto-composer pipeline'u.

Krok 4 — Konkretna poprawka

AMLrowiec — poprawiony przepływ ctx

Co wchodzi, co wychodzi, gdzie ctx jest gotowy bez przerywania użytkownika.

1
intake-podmiotu
Zbiera nazwę/KRS/PESEL. Wykrywa typ. Ustawia intencję i zakres analizy.
⚠ do zbudowania
↓ ctx: podmiot_typ · podmiot_nazwa · intencja
2
wyszukiwanie-krs-po-fragmencie-nazwy
Używa podmiot_nazwa jako query. Daje pelna_nazwa i wybrany_krs.
istnieje
↓ ctx: pelna_nazwa · wybrany_krs
3
pobieranie-danych-crbr
Używa wybrany_krs jako numer_krs (pipeline_source — bez pytania człowieka).
istnieje · manifest fix
↓ ctx: beneficjenci[]
4
wyodrebnij-beneficjenta
Lista → skalar. Daje podmiot_pesel i query (Nazwisko Imię). Disambiguation jeśli >1.
⚠ do zbudowania
↓ ctx: podmiot_pesel · query (imię+nazwisko)
5
sprawdzanie-ostrzezen-knf
Używa pelna_nazwa z ctx — bez pytania człowieka.
istnieje
↓ ctx: knf_status · knf_ostrzezenia
6
sprawdzanie-poszukiwanych-policja
Używa query (Nazwisko Imię) z ctx — bez pytania człowieka.
istnieje
↓ ctx: poszukiwani_status · poszukiwani_wyniki
7
wyszukiwanie-w-krz
Używa podmiot_pesel (alias: pesel) z ctx — bez pytania człowieka.
istnieje
↓ ctx: krz_status · krz_znalezione_wiersze
8
konsolidacja-wynikow-aml
Czyta wszystkie *_status. Produkuje jedno ryzyko, listę alertów i podsumowanie po polsku.
⚠ do zbudowania

Efekt: zero przerwań w trakcie

Po wdrożeniu kroków 1–4 użytkownik jest pytany raz na starcie (przez intake) — a następnie pipeline przechodzi wszystkie 8 kroków bez dodatkowych pytań.

Mapa przyszłości

Agenty do zbudowania — pełna lista

Use case'y AML wskazują co dalej. Każdy brakujący agent to sygnał do rozbudowy bazy junior agentów.

Priorytet wysoki
intake-podmiotu
Wejście: jedno pole swobodne. Wyjście: podmiot_typ, podmiot_krs lub podmiot_pesel, intencja, zakres_analizy. Python stdlib.
Priorytet wysoki
wyodrebnij-beneficjenta
Wejście: lista (dowolna, konfigurowalny klucz). Wyjście: płaskie klucze z wybranego elementu. Disambiguation dla >1 elementów. Python stdlib.
Priorytet wysoki
konsolidacja-wynikow-aml
Wejście: *_status z ctx (cokolwiek znajdzie). Wyjście: ryzyko_poziom, alerty[], podsumowanie. Deterministyczna logika reguł, bez LLM.
Przyszłość
ocena-ryzyka-sankcyjnego
Wejście: podmiot_nazwa lub podmiot_pesel. Sprawdzenie list sankcyjnych UE (EUR-Lex) i OFAC. Wyjście: sankcje_status, sankcje_lista[].
Przyszłość
wyszukiwanie-osoby-po-pesel
Wejście: podmiot_pesel. Identyfikacja osoby (imię, nazwisko, NIP) przez CRBR lub inne rejestry publiczne. Brak łatwego publicznego API.
Przyszłość
auto-composer-pipeline
Wejście: intencja + podmiot_typ. Na podstawie pola "intencje" w manifestach agentów składa pipeline automatycznie. Podstawa: pole intencje w każdym manifeście.
Plan wdrożenia

Kolejność — od najniższego nakładu

1
Manifest CRBR — pipeline_source
Dodaj pipeline_source: "wybrany_krs" do pola numer_krs. Infrastruktura już to obsługuje.
mały
fundament
2
wyodrebnij-beneficjenta
Nowy junior agent Python. Brak zależności. Odblokowuje AML Spółka end-to-end.
mały
wysoka
3
Konwencja canonical ctx
Dokument README.md z tabelą kluczy. Nowe agenty piszemy pod tę konwencję.
mały
długoterminowa
4
intake-podmiotu
Nowy junior agent zbierający i normalizujący dane wejściowe. Eliminuje pytania w środku pipeline'u.
średni
wysoka
5
konsolidacja-wynikow-aml
Nowy junior agent — syntetyczny wynik zamiast 4 osobnych statusów.
mały
wysoka
6
Szablony intencji (senior agenty)
AML Spółka, AML Osoba, Screening szybki — gotowe do użycia senior agenty z poprawnymi pipeline'ami.
mały
wysoka
7
Pole intencje w manifestach
Dodaj intencje: [...] do każdego manifest.json. Podstawa pod przyszły auto-composer.
mały
długoterminowa