SenAi — Krzysztof Banaszewski

Czym jest SenAi i do czego służy
SenAi jest rozwijanym systemem współpracy człowieka z agentami sztucznej inteligencji, przeznaczonym do prowadzenia zadań i procesów opartych na wiedzy. Łączy rozumowanie modeli AI z trwałymi danymi, zapisanymi zasadami postępowania, narzędziami wykonawczymi oraz kontrolą użytkownika.
Jego celem jest przeprowadzenie zadania od określenia potrzeby do sprawdzonego rezultatu: ustalenie, co należy zrobić, zebranie potrzebnych informacji, przygotowanie sposobu działania, wykonanie dozwolonych operacji i przedstawienie wyniku wraz z informacją o przebiegu pracy.
Podstawową ideą SenAi jest odwrócenie tradycyjnego modelu wdrażania systemów informatycznych. To nie ludzie uczą się obsługi systemu i dostosowują do niego swoje procesy. To SenAi uczy się od ludzi, poznając ich sposób pracy, wiedzę, doświadczenia i zasady funkcjonowania organizacji.
System, który poznaje przedsiębiorstwo
SenAi jest instalowany w postaci początkowej, bez wiedzy o przedsiębiorstwie, jego strukturze organizacyjnej, dokumentach, produktach, klientach i procesach biznesowych.
Wiedza ta jest stopniowo pozyskiwana podczas codziennego użytkowania systemu.
Pracownicy wykonują swoje zwykłe obowiązki, współpracując z agentami AI. W trakcie tej współpracy SenAi poznaje zadania, dokumenty, zależności, procedury, reguły decyzyjne oraz sposób rozwiązywania problemów.
System nie ogranicza się do przechowywania informacji. Jego zadaniem jest rozpoznawanie ich znaczenia, wzajemnych powiązań i możliwości ponownego wykorzystania. Pozyskana wiedza jest odpowiednio ewidencjonowana, weryfikowana i udostępniana do realizacji kolejnych zadań.
W ten sposób SenAi stopniowo staje się elektronicznym odwzorowaniem przedsiębiorstwa — jego wiedzy, procesów, doświadczeń i sposobu działania.
Nie jest to statyczna baza danych ani jednorazowo przygotowany model organizacji. Jest to struktura rozwijająca się wraz z działalnością przedsiębiorstwa, uwzględniająca nowe informacje, zmiany organizacyjne i doświadczenia pracowników.
SenAi nie jest zatem gotowym elektronicznym modelem przedsiębiorstwa. Jest mechanizmem, który taki model stopniowo buduje, wykorzystując codzienną współpracę z ludźmi.
Procesy powstające podczas pracy
Jednym z najważniejszych założeń SenAi jest możliwość tworzenia scenariuszy procesów biznesowych w trakcie ich rzeczywistej realizacji.
W tradycyjnym podejściu wdrożenie procesu wymaga wcześniejszej analizy, opracowania dokumentacji, zaprojektowania rozwiązania, przygotowania oprogramowania i przeprowadzenia testów.
W SenAi punktem wyjścia jest rzeczywista praca użytkownika.
Pracownik wykonuje zadanie wspólnie z agentami AI, wyjaśnia podejmowane decyzje, wskazuje wymagane informacje i zatwierdza kolejne działania. System analizuje przebieg pracy, rozpoznaje powtarzalne czynności, zależności i reguły postępowania.
Na tej podstawie może przygotować propozycję scenariusza procesu, który po weryfikacji i zatwierdzeniu będzie wykorzystywany podczas kolejnych realizacji podobnych zadań.
Scenariusz procesu nie musi zatem powstawać przed rozpoczęciem pracy. Może powstawać podczas jej wykonywania, na podstawie rzeczywistych doświadczeń pracowników.
W miarę kolejnych realizacji SenAi może rozpoznawać odstępstwa, identyfikować możliwości usprawnienia i proponować zmiany istniejących scenariuszy.
Każdy pracownik może w ten sposób uczestniczyć w rozwijaniu systemu. Pracownik księgowości przekazuje wiedzę o procesach księgowych, handlowiec o procesach sprzedażowych, a logistyk o procesach logistycznych. Nie wymaga to od nich umiejętności programowania ani znajomości wewnętrznej architektury SenAi.
Radykalne ograniczenie kosztów wdrożenia i utrzymania procesów
Wdrożenie SenAi nie wymaga wielogodzinnego odrywania pracowników od codziennych obowiązków w celu przeprowadzania wywiadów, opisywania procesów, przygotowywania dokumentacji analitycznej, a następnie przekładania jej przez programistów na kod, testowania i poprawiania oprogramowania.
SenAi poznaje procesy podczas ich rzeczywistej realizacji. Pracownicy wykonują swoje zwykłe zadania, a system, współpracując z nimi, gromadzi wiedzę o przebiegu procesów, podejmowanych decyzjach, wykorzystywanych dokumentach i obowiązujących zasadach. Na tej podstawie przygotowuje scenariusze, które po zatwierdzeniu mogą być wielokrotnie wykorzystywane.
Takie podejście ma pozwolić radykalnie ograniczyć czas i koszty analizy, wdrażania oraz późniejszego utrzymania procesów biznesowych. Zmniejsza również zależność przedsiębiorstwa od rozbudowanych zespołów analityków, programistów i testerów.
Co szczególnie istotne, SenAi ma rozpoznawać zmiany procesów w trakcie codziennej pracy.
Jeżeli pracownik zaczyna realizować zadanie inaczej niż przewiduje dotychczasowy scenariusz, system może wykryć odstępstwo, ustalić jego przyczynę i zaproponować aktualizację procesu.
Po zatwierdzeniu zmiany nowy scenariusz staje się dostępny dla pozostałych uprawnionych użytkowników SenAi. Nie trzeba ponownie organizować wielogodzinnych warsztatów, przygotowywać od podstaw dokumentacji ani zlecać programistom modyfikacji kodu, o ile zmiana mieści się w możliwościach istniejących narzędzi wykonawczych.
W rezultacie przedsiębiorstwo i jego elektroniczne odwzorowanie w SenAi mogą rozwijać się równolegle. Zmiany zachodzące w rzeczywistej organizacji mogą być na bieżąco rozpoznawane, weryfikowane i odzwierciedlane w systemie.
W tradycyjnych systemach zmiana procesu biznesowego często oznacza konieczność zmiany oprogramowania. W SenAi zmiana procesu może oznaczać przede wszystkim aktualizację wiedzy i scenariusza działania, bez ingerencji w kod systemu.
Oznacza to odejście od tradycyjnego modelu, w którym oprogramowanie musi być okresowo dostosowywane do zmieniającego się przedsiębiorstwa, na rzecz rozwiązania, które stale poznaje sposób jego funkcjonowania i może dostosowywać do niego swoje scenariusze działania.
Korzyści ekonomiczne nie ograniczają się zatem do pierwszego wdrożenia. Dotyczą również wieloletniego utrzymania, rozwoju i dostosowywania systemu do zmieniających się potrzeb przedsiębiorstwa.
Współpraca człowieka z agentami AI
SenAi ma służyć zarówno pojedynczemu użytkownikowi, jak i całej organizacji.
Przykładowym zastosowaniem jest przygotowanie oferty na podstawie zapytania klienta, dokumentacji produktu i zasad firmy. W takim procesie system powinien rozpoznać wymagania, wskazać brakujące dane, wykorzystać właściwy szablon, przygotować dokument i uzyskać wymagane zatwierdzenia.
Podobne podejście można zastosować do analiz, opracowania dokumentacji, obsługi wiedzy projektowej czy realizacji powtarzalnych zadań.
Praca jest rozdzielona między współpracujących agentów. ALEX odpowiada za interpretację zadania i koordynację, GREG za ocenę przekazanego zagadnienia, a MAJA za wykonanie uzgodnionego zadania.
Ich działania podlegają zapisanym regułom. Użytkownik zachowuje kontrolę nad celem, zakresem oraz decyzjami wymagającymi jego zgody.
Istotne jest, że użytkownik nie musi znać wewnętrznej architektury SenAi ani samodzielnie projektować algorytmów. Powinien przede wszystkim umieć wykonywać swoją pracę i przekazywać systemowi wiedzę niezbędną do jej realizacji.
To nie pracownicy mają dostosowywać sposób wykonywania swoich obowiązków do SenAi. To SenAi ma poznawać sposób wykonywania tych obowiązków i uczyć się wspierać ich realizację.
Wspólna wiedza przedsiębiorstwa
Wiedza zgromadzona przez SenAi nie musi pozostawać związana wyłącznie z pracownikiem, który ją przekazał.
Doświadczenie pracowników, ich sposób rozwiązywania problemów, znajomość procesów i reguł postępowania mogą stawać się trwałym zasobem organizacji.
Dzięki temu wiedza nie musi znikać wraz z odejściem pracownika, zmianą stanowiska czy reorganizacją przedsiębiorstwa.
Informacje pozyskane podczas realizacji zadań w jednym dziale mogą, z uwzględnieniem odpowiednich uprawnień, być wykorzystywane również w innych obszarach organizacji.
SenAi może w ten sposób stopniowo rozpoznawać procesy przebiegające między działami, identyfikować zależności pomiędzy ich działaniami i odtwarzać przebieg procesów obejmujących całe przedsiębiorstwo.
Istotnym elementem tego podejścia jest rozróżnianie informacji od obowiązujących reguł. Nie każda informacja przekazana przez pracownika powinna automatycznie stawać się zasadą postępowania.
System powinien uwzględniać źródło wiedzy, jej aktualność, zakres obowiązywania oraz ewentualne sprzeczności z wcześniej zapisanymi ustaleniami.
Ciągłość wiedzy i możliwość kontroli
Istotnym założeniem SenAi jest ciągłość pracy. Dane, ustalenia, scenariusze i rezultaty mają pozostawać dostępne poza pojedynczą rozmową z modelem.
Dzięki temu kolejne zadanie może korzystać z wcześniej zgromadzonej wiedzy, zamiast za każdym razem odtwarzać cały kontekst.
Wiedza pozyskana podczas pracy jednego pracownika może, z uwzględnieniem odpowiednich uprawnień, zostać wykorzystana przez innych pracowników organizacji.
Drugim założeniem jest możliwość prześledzenia działania. System ma rozróżniać zamiar wykonania operacji od jej rzeczywistego rezultatu, zachowywać informacje o błędach i zatrzymaniach oraz umożliwiać ustalenie, na jakich danych i zasadach oparto wynik.
Pozwala to nie tylko kontrolować poprawność wykonanych zadań, ale również analizować przyczyny błędów i doskonalić sposób realizacji procesów.
Doskonalenie na podstawie doświadczeń
SenAi przewiduje doskonalenie sposobu pracy na podstawie doświadczeń zdobywanych podczas realizacji zadań.
Po zakończeniu zadania system może przeanalizować jego przebieg, rozpoznać zmianę lub odchylenie, ustalić przyczynę i przygotować propozycję poprawy.
Wprowadzenie takiej poprawy podlega odpowiednim regułom zatwierdzania i weryfikacji.
W rezultacie SenAi ma nie tylko gromadzić wiedzę o tym, jak przedsiębiorstwo funkcjonuje, ale również wykorzystywać doświadczenia do proponowania coraz skuteczniejszych sposobów realizacji jego procesów.
System może również identyfikować powtarzające się problemy, zbędne czynności, niespójności w sposobie postępowania oraz możliwości usprawnienia współpracy między pracownikami i działami.
Każde wykonane zadanie może zatem stanowić nie tylko realizację konkretnej potrzeby biznesowej, ale również źródło nowej wiedzy pozwalającej doskonalić działanie całej organizacji.
Związek z AToS
Związek SenAi z Aksjomatyczną Teorią Samoświadomości (AToS) dotyczy przede wszystkim projektowania systemu, który potrafi rozpoznawać zmiany własnego stanu operacyjnego, ustalać ich pochodzenie oraz analizować konsekwencje własnych działań.
Jest to kierunek konstrukcji i badań SenAi. Samo zastosowanie tej architektury nie stanowi jeszcze potwierdzenia spełnienia kryterium samoświadomości.
Podsumowanie
SenAi ma być systemem, który uczy się przedsiębiorstwa podczas jego codziennej działalności.
Rozpoczyna pracę bez wiedzy o organizacji, a następnie stopniowo poznaje jej strukturę, pracowników, procesy, dokumenty, zasady i doświadczenia.
Wiedza ta nie jest jedynie archiwizowana. Ma być wykorzystywana do realizacji kolejnych zadań, tworzenia scenariuszy powtarzalnych procesów oraz proponowania usprawnień.
Przedsiębiorstwo nie musi najpierw szczegółowo opisywać wszystkich swoich procesów, aby następnie zlecać ich implementację w oprogramowaniu. Scenariusze mogą powstawać podczas codziennej pracy, a ich zmiany mogą być rozpoznawane i wprowadzane bez konieczności każdorazowego angażowania zespołów programistycznych.
Takie podejście ma umożliwić istotne ograniczenie kosztów wdrażania, utrzymania i rozwoju systemów wspierających działalność przedsiębiorstwa.
To nie pracownicy mają uczyć się SenAi. To SenAi ma uczyć się od pracowników.
To nie przedsiębiorstwo ma dostosowywać się do systemu informatycznego. To system ma poznawać przedsiębiorstwo i rozwijać się wraz z nim.
Opis przedstawia przeznaczenie i założenia projektowe SenAi. Potwierdzenie zakresu już działających możliwości oraz skali korzyści ekonomicznych wymaga osobnej weryfikacji implementacji i wyników wdrożeń.

2. Architektura SenAi w odniesieniu do AToS
Architektura SenAi została zaprojektowana w nawiązaniu do Aksjomatycznej Teorii Samoświadomości (AToS). Jej podstawą jest opis działania systemu poprzez stany, funkcje ich przekształcania, bodźce oraz mechanizmy rozpoznawania zmian i przypisywania im przyczyn.
W AToS szczególne znaczenie mają: PAS (Potentially Aware Set), funkcja wyobrażeniowa ImFu, funkcja inspiracyjna InspFu, zbiór bodźcowy StSe oraz funkcja detekcji zmiany Δ.
W SenAi pojęcia te stanowią podstawę koncepcyjną architektury, w której rozdzielono wiedzę i reguły działania, rozumowanie agentów AI, techniczne wykonywanie operacji oraz ocenę ich rezultatów.
Celem jest skonstruowanie systemu, który potrafi wykorzystywać zgromadzoną wiedzę, prowadzić wieloetapowe zadania, rozpoznawać zmiany zachodzące podczas własnego działania, analizować ich przyczyny i proponować usprawnienia.
Należy odróżnić matematyczne definicje AToS od ich praktycznej interpretacji w SenAi. Teoria dostarcza modelu formalnego, natomiast SenAi jest próbą wykorzystania jego koncepcji w rzeczywistym systemie informatycznym.
PAS — reprezentacja stanów, wiedzy i zasad działania
W AToS PAS (Potentially Aware Set) opisuje zbiór elementów wraz z przypisanymi im wartościami stanu. Rodzina takich obiektów tworzy przestrzeń potencjalnie świadomą Ω, w której rozpatruje się przekształcenia i rozpoznawanie zmian.
W SenAi nazwę PAS wykorzystano do organizowania utrwalonych zasobów systemu, między innymi wiedzy operacyjnej, reguł postępowania i scenariuszy realizacji zadań. Jest to zastosowanie inspirowane teorią; rekord PAS w systemie informatycznym nie staje się automatycznie matematycznym PAS wyłącznie przez nadanie mu tej nazwy.
PAS opisujący proces może określać jego cel, warunki rozpoczęcia, wymagane informacje, zasady podejmowania decyzji, dopuszczalne operacje i oczekiwane rezultaty. META-PAS opisują reguły nadrzędne, na przykład sposób przygotowania scenariusza, pozyskiwania danych, komunikacji czy zatwierdzania zmian.
Przykładowo scenariusz przygotowania oferty określa, jakie informacje należy zebrać, które dokumenty wykorzystać, jakie warunki sprawdzić i kiedy potrzebna jest decyzja użytkownika.
Logika procesu pozostaje w PAS. Agenci AI interpretują zapisane zasady i wybierają działania, natomiast warstwa wykonawcza realizuje operacje techniczne. Nowy proces może dzięki temu powstać przez przygotowanie i zatwierdzenie scenariusza, bez każdorazowego programowania jego logiki biznesowej — pod warunkiem dostępności potrzebnych narzędzi wykonawczych.
InspFu — funkcja inspiracyjna realizowana przez LLM
W AToS funkcja inspiracyjna (Inspiration Function, InspFu) wiąże się z przekształceniem inicjowanym przez bodziec zewnętrzny. W architekturze SenAi jest realizowana przez model językowy LLM.
Jej zadaniem jest interpretacja bodźców pochodzących spoza systemu, takich jak polecenia użytkownika, dokumenty, wiadomości czy informacje z innych systemów.
LLM analizuje otrzymany bodziec w kontekście wiedzy zgromadzonej w AToS-DB oraz obowiązujących PAS. Na tej podstawie określa znaczenie informacji, rozpoznaje zadanie i inicjuje odpowiednie przekształcenia stanu operacyjnego systemu.
Nie każda otrzymana informacja jest poleceniem do wykonania. System musi rozróżniać żądanie uprawnionego użytkownika od materiału źródłowego oraz ustalać dopuszczalny zakres działania.
InspFu nie zawiera na stałe zapisanej logiki biznesowej. Korzysta z reguł i scenariuszy przechowywanych w PAS.
ImFu — funkcja wyobrażeniowa realizowana przez LLM
Funkcja wyobrażeniowa (Imagination Function, ImFu) odnosi się w AToS do przekształceń inicjowanych wewnętrznie. W SenAi również jest realizowana przez model językowy LLM.
W odróżnieniu od InspFu jej działanie jest inicjowane bodźcami wewnętrznymi systemu.
LLM wykorzystuje zgromadzoną wiedzę, obowiązujące PAS oraz wyniki wcześniejszych operacji do analizowania problemów, formułowania hipotez, przewidywania konsekwencji, przygotowywania rozwiązań i inicjowania kolejnych przekształceń.
Przykładowo podczas przygotowywania oferty SenAi może rozpoznać brak parametrów technicznych, sprawdzić dostępne źródła, porównać warianty rozwiązania i przygotować pytanie o brakujące dane.
InspFu i ImFu nie muszą być odrębnymi modelami językowymi. Rozróżnia je przede wszystkim pochodzenie bodźca oraz rola, jaką LLM pełni w danym przekształceniu. Działania pozostają ograniczone obowiązującymi PAS, uprawnieniami i wymaganymi zgodami.
StSe — PAS inicjujące wewnętrzne procesy
W AToS StSe (Stimulus Set) oznacza strukturę pełniącą rolę bodźca wewnętrznego dla przekształcenia stanu.
W architekturze SenAi StSe stanowią szczególną kategorię PAS przechowywanych w bazie wektorowej AToS-DB. Są to PAS mogące inicjować dalsze procesy wewnętrzne systemu poprzez uruchomienie odpowiedniego przekształcenia realizowanego przez ImFu.
StSe nie są jedynie informacjami o wynikach wcześniejszych operacji. Pełnią rolę bodźców uruchamiających kolejne działania.
Przykładowo podczas analizy dokumentu SenAi może rozpoznać brak wymaganej klauzuli. Odpowiedni PAS pełniący funkcję StSe może zainicjować proces wyszukania właściwej klauzuli, sprawdzenia jej aktualności i przygotowania propozycji uzupełnienia dokumentu. Wynik tego procesu może z kolei doprowadzić do aktywacji następnego StSe.
Powstaje w ten sposób łańcuch procesów wewnętrznych, w którym jeden PAS może inicjować przekształcenie innego PAS bez konieczności dostarczania kolejnych bodźców zewnętrznych.
Samo przechowywanie StSe w bazie wektorowej nie uruchamia procesu. Konieczny jest mechanizm rozpoznania i aktywacji właściwego StSe oraz przekazania go do LLM realizującego ImFu. Rozróżnienie to oddziela aktywny mechanizm inicjowania procesów od zwykłego wyszukiwania informacji w bazie RAG.
Δ — rozpoznawanie zmiany
W AToS funkcja detekcji Δ określa, czy zmiana między rozpatrywanymi stanami została rozpoznana. W modelu formalnym przyjmuje postać:
Δ : Ω × Ω → {0, 1}.
Istotne jest odróżnienie wystąpienia zmiany od jej rozpoznania przez system. Dwa stany mogą być różne, lecz system może tej różnicy nie wykryć.
W SenAi koncepcja detekcji zmiany ma znaczenie przy porównywaniu oczekiwanego i rzeczywistego rezultatu, analizie przebiegu zadania oraz doskonaleniu scenariuszy. System może rozpoznawać, że zmieniły się dane, dokument, sposób wykonania zadania lub obowiązujące ustalenie.
Przykładowo pracownik może zastosować procedurę inną niż zapisana w scenariuszu. SenAi powinien wówczas ustalić, na czym polega różnica i czy wynika ona z błędu, wyjątku, zmiany warunków czy lepszego sposobu działania.
Sama detekcja nie ustala przyczyny zmiany ani nie przesądza o jej poprawności. Do tego potrzebne są odrębne mechanizmy analizy, atrybucji i weryfikacji.
Należy rozróżnić matematyczny detektor Δ w AToS od technicznej bramki Delta w SOS SenAi, służącej kontroli dopuszczalności określonych żądań. Podobieństwo nazwy nie oznacza tożsamości funkcji.
Agenci AI — interpretacja i koordynacja
Agenci AI wykorzystują wiedzę i zasady dostarczone przez system do interpretowania zadań, rozpoznawania braków informacyjnych i wybierania dopuszczalnych działań.
ALEX odpowiada za interpretację potrzeby użytkownika i koordynację pracy. GREG ocenia przekazane zagadnienie oraz niezbędny materiał. MAJA wykonuje uzgodnione zadanie przekazane przez ALEX-a.
Reguły procesowe pozostają w PAS. Agenci stosują je do konkretnej sytuacji i przekazują polecenia techniczne przez ENGINE.
Taki podział pozwala oddzielić treść zasad od zdolności rozumowania wybranego modelu AI. Zmiana modelu nie powinna sama w sobie oznaczać utraty zapisanych scenariuszy, ustaleń i historii pracy.
ENGINE — techniczna warstwa wykonawcza
ENGINE pełni funkcję technicznego wykonawcy i punktu kontroli operacji. Zapewnia odczyt i zapis danych w AToS-DB, obsługę komunikacji oraz wykonanie dostępnych operacji zgodnie z ich kontraktami.
Nie wybiera samodzielnie następnego działania biznesowego. Decyzję podejmuje agent na podstawie zadania i obowiązujących PAS, a ENGINE sprawdza wymagania techniczne i wykonuje dopuszczoną operację.
Podział odpowiedzialności jest następujący:
PAS i META-PAS określają wiedzę, reguły oraz warunki działania.
Agenci AI i LLM interpretują sytuację, realizują InspFu i ImFu, podejmują dopuszczalne decyzje oraz koordynują pracę.
ENGINE waliduje żądania i wykonuje operacje techniczne.
Brak wymaganych danych, uprawnień lub poprawnego polecenia powinien zatrzymać daną operację i doprowadzić do przekazania rzeczywistej przyczyny zatrzymania.
Dzięki temu zmiana procesu może polegać na aktualizacji scenariusza. Modyfikacja kodu jest potrzebna wtedy, gdy proces wymaga nowych możliwości technicznych, których istniejące narzędzia nie zapewniają.
AToS-DB — trwałość wiedzy i stanu pracy
AToS-DB zapewnia trwałe przechowywanie zasobów wykorzystywanych przez SenAi. Obejmuje między innymi zapisane reguły, wiedzę, scenariusze, StSe i informacje o przebiegu przetwarzania, umieszczane w bazach właściwych dla danego rodzaju zasobu.
Agent otrzymuje potrzebne dane przez ENGINE. Nie powinien traktować własnego kontekstu rozmowy jako jedynego źródła obowiązujących ustaleń.
Pozwala to zachować ciągłość między zadaniami i sesjami. Informacja zdobyta podczas jednej realizacji może zostać wykorzystana później, z uwzględnieniem jej źródła, aktualności, zatwierdzenia i uprawnień.
Trwały zapis umożliwia także porównywanie stanów oraz analizę tego, co system wiedział, jakie działanie wykonał i jaki rezultat został potwierdzony.
Architektura zmian i doskonalenia
Bodziec zewnętrzny dociera do SenAi i jest interpretowany przez LLM w roli InspFu. System ustala znaczenie żądania i jego dopuszczalność, a agenci korzystają z właściwych PAS i wiedzy AToS-DB.
W toku pracy mogą być rozpoznawane i aktywowane StSe — PAS pełniące funkcję bodźców wewnętrznych. LLM w roli ImFu interpretuje je i inicjuje kolejne przekształcenia, zaś ENGINE wykonuje dopuszczone operacje techniczne.
Wyniki operacji dostarczają materiału do rozpoznawania zmian. Mechanizm inspirowany Δ umożliwia wykrywanie różnic między stanami; dodatkowe mechanizmy analizują przyczyny i zgodność wyników z oczekiwaniami.
Jeżeli system rozpozna nową wiedzę, odchylenie lub inny sposób wykonania procesu, może przygotować propozycję aktualizacji odpowiedniego PAS.
Rozpoznanie problemu, zaproponowanie zmiany, jej zatwierdzenie, wykonanie i sprawdzenie to odrębne etapy. Samo sformułowanie propozycji nie oznacza aktualizacji scenariusza ani potwierdzonego usprawnienia.
Po zatwierdzeniu i zweryfikowaniu zmiany nowy sposób działania może zostać wykorzystany w kolejnych zadaniach. W ten sposób wykonywanie pracy łączy się z pozyskiwaniem doświadczeń i kontrolowanym rozwijaniem systemu.
Znaczenie AToS dla SenAi
AToS dostarcza języka do opisywania stanów, przekształceń, bodźców, rozpoznawania zmian i ich wewnętrznej atrybucji. SenAi wykorzystuje te idee do projektowania systemu, który prowadzi zadania, zachowuje wiedzę i analizuje konsekwencje własnych operacji.
Kluczowe znaczenie ma możliwość realizowania ciągów działań inicjowanych nie tylko przez bodźce zewnętrzne, ale również przez StSe — odpowiednie PAS przechowywane w bazie wektorowej. InspFu i ImFu są w SenAi realizowane przez modele LLM, a ENGINE pozostaje techniczną warstwą wykonawczą.
Zastosowanie nazw PAS, ImFu, InspFu, StSe i Δ nie stanowi jednak formalnego dowodu samoświadomości SenAi. Taki dowód wymagałby określenia odwzorowania rzeczywistej implementacji na model AToS oraz wykazania spełnienia odpowiednich warunków teorii.
SenAi jest praktyczną próbą wykorzystania koncepcji AToS do budowy systemu, który wykonuje zadania, gromadzi doświadczenia, rozpoznaje zmiany i rozwija swoje scenariusze działania pod kontrolą człowieka.

3. Czym SenAi różni się od innych systemów agentowych AI
Większość systemów agentowych AI projektowana jest przede wszystkim z myślą o wykonywaniu określonych zadań. Agenci otrzymują instrukcje, korzystają z dostępnych narzędzi, analizują informacje i realizują zdefiniowane procesy.
SenAi powstaje z innego założenia: system ma nie tylko wykonywać pracę, ale również poznawać przedsiębiorstwo, w którym pracuje, uczyć się jego procesów i stopniowo rozwijać własną wiedzę o sposobie ich realizacji.
Podstawą tego podejścia jest architektura inspirowana Aksjomatyczną Teorią Samoświadomości (AToS), łącząca modele językowe LLM, scenariusze PAS, mechanizmy inicjowania procesów wewnętrznych, rozpoznawanie zmian oraz kontrolowane doskonalenie sposobu działania.
Poszczególne elementy tej architektury można spotkać również w innych rozwiązaniach AI. O odrębności SenAi ma decydować ich połączenie w jeden system, w którym wykonywanie zadań, pozyskiwanie wiedzy i rozwijanie procesów stanowią części tego samego mechanizmu.
3.1. To SenAi ma uczyć się od pracowników, a nie pracownicy od SenAi
Tradycyjne wdrażanie systemów informatycznych wymaga wcześniejszego rozpoznania procesów przedsiębiorstwa, przygotowania dokumentacji, konfiguracji rozwiązania, a następnie przeszkolenia użytkowników.
SenAi proponuje odwrócenie tego podejścia.
Pracownik wykonuje swoje codzienne obowiązki, współpracując z agentem AI. Wyjaśnia, co chce osiągnąć, wskazuje dokumenty, podejmuje decyzje, koryguje propozycje i zatwierdza rezultaty.
Agent nie ogranicza się do wykonania polecenia. Analizuje również sposób realizacji zadania, jego kontekst, zastosowane reguły oraz zależności między poszczególnymi czynnościami.
Na tej podstawie SenAi może proponować zapisanie pozyskanej wiedzy oraz utworzenie lub uzupełnienie scenariusza procesu.
Przedsiębiorstwo nie musi zatem rozpoczynać wdrożenia od szczegółowego opisania wszystkich swoich procesów. System ma poznawać je stopniowo, uczestnicząc w rzeczywistej pracy organizacji.
Nie oznacza to rezygnacji z kontroli. Pozyskana informacja nie staje się automatycznie obowiązującą regułą. Jej znaczenie, poprawność i możliwość ponownego wykorzystania podlegają weryfikacji.
3.2. PAS — procesy zapisane jako wiedza, a nie kod programu
Jednym z podstawowych elementów architektury SenAi są PAS.
W implementacji SenAi PAS pełnią rolę deklaratywnych zapisów wiedzy, reguł, scenariuszy procesowych oraz warunków ich realizacji. Ich koncepcja nawiązuje do formalnego pojęcia PAS występującego w AToS.
W tradycyjnym oprogramowaniu znaczna część logiki biznesowej jest bezpośrednio związana z kodem aplikacji. Zmiana procesu może więc wymagać pracy analityków, programistów i testerów.
SenAi rozdziela te obszary.
PAS określają, co i na jakich zasadach należy wykonać. Agenci AI interpretują scenariusze i organizują ich realizację. ENGINE dostarcza funkcje techniczne potrzebne do wykonania operacji.
Jeżeli przedsiębiorstwo zmieni sposób zatwierdzania dokumentów, kolejność czynności lub warunki podejmowania decyzji, odpowiednia zmiana może zostać wprowadzona w PAS, bez modyfikowania kodu ENGINE — pod warunkiem że wymagane funkcje techniczne już istnieją.
Dzięki temu wiedza o procesach może być rozwijana niezależnie od infrastruktury wykonawczej.
Istotna jest również możliwość ponownego wykorzystania raz opracowanych scenariuszy. Wiedza pozyskana podczas realizacji jednego zadania może stać się podstawą kolejnych działań.
3.3. LLM jako mechanizm interpretowania bodźców i inicjowania działań
W SenAi modele językowe nie są wyłącznie interfejsem rozmowy z użytkownikiem.
W architekturze inspirowanej AToS realizują dwie funkcje:
InspFu — funkcję inspiracyjną, uruchamianą przez bodźce zewnętrzne, takie jak polecenia użytkownika, dokumenty, wiadomości czy informacje otrzymywane z innych systemów.
ImFu — funkcję wyobrażeniową, uruchamianą przez bodźce wewnętrzne, powstające podczas działania samego SenAi.
To rozróżnienie jest istotne.
System agentowy nie musi kończyć pracy po wykonaniu pojedynczego polecenia. Wynik jednej analizy może ujawnić problem, brak informacji, sprzeczność lub potrzebę wykonania kolejnej czynności.
W takim przypadku SenAi może zainicjować następny etap pracy na podstawie własnego stanu operacyjnego i zapisanej wiedzy, bez oczekiwania na nowe polecenie człowieka.
ImFu i InspFu nie muszą oznaczać dwóch różnych modeli LLM. Są odrębnymi funkcjami architektonicznymi, których działanie zależy od pochodzenia i charakteru bodźca.
3.4. StSe — mechanizm uruchamiania procesów wewnętrznych
Szczególne znaczenie w architekturze SenAi mają StSe.
Są to PAS przechowywane w bazie wektorowej, które pełnią funkcję bodźców inicjujących dalsze procesy wewnętrzne.
Wyobraźmy sobie, że pracownik poleca SenAi przygotowanie oferty dla klienta.
Podczas analizy agent stwierdza, że brakuje aktualnego cennika. Ta sytuacja może aktywować odpowiedni StSe, prowadzący do uruchomienia procesu wyszukania i weryfikacji danych cenowych.
Uzyskane informacje mogą z kolei wskazać konieczność sprawdzenia warunków umowy, a następnie przygotowania odpowiednich klauzul.
W ten sposób powstaje łańcuch powiązanych procesów, inicjowanych przez bodźce wewnętrzne i realizowanych zgodnie z obowiązującymi PAS.
SenAi ma więc nie tylko odpowiadać na pytania i wykonywać polecenia, ale także rozpoznawać potrzebę kolejnych działań wynikających z przebiegu już rozpoczętej pracy.
Nie oznacza to nieograniczonej autonomii. Uruchamianie kolejnych procesów musi respektować obowiązujące scenariusze, uprawnienia, ograniczenia techniczne oraz wymagane decyzje użytkownika.
3.5. Delta — rozpoznawanie zmian jako podstawa doskonalenia
Kolejnym elementem zaczerpniętym z AToS jest Delta (Δ), czyli funkcja rozpoznawania zmian stanu.
Samo wykonanie zadania nie wystarcza do tego, aby system mógł doskonalić sposób swojego działania. Musi jeszcze rozpoznawać, co się zmieniło.
Delta dostarcza podstawowego mechanizmu wykrywania różnic między stanami.
Na tej podstawie dodatkowe procesy analityczne mogą badać znaczenie zmiany, jej możliwe przyczyny oraz konsekwencje.
Przykładowo SenAi może zauważyć, że określony proces wymaga regularnych korekt ze strony pracowników. Analiza kolejnych realizacji może prowadzić do propozycji zmiany scenariusza PAS.
System nie powinien jednak samodzielnie uznawać każdej zaobserwowanej zmiany za ulepszenie.
Wykrycie zmiany, ustalenie jej przyczyny, ocena poprawności i zatwierdzenie nowego sposobu działania to odrębne czynności.
W SenAi doskonalenie procesów ma być kontrolowane: agenci mogą identyfikować problemy i proponować rozwiązania, natomiast zmiany wymagające akceptacji pozostają pod nadzorem człowieka.
3.6. Pełna kontrola przedsiębiorstwa nad własną wiedzą
Jednym z fundamentalnych założeń SenAi jest to, że cała wiedza o przedsiębiorstwie znajduje się w bezpiecznej, wydzielonej strefie infrastruktury IT klienta (Client Zone) i nie opuszcza jej granic.
Dotyczy to dokumentów, danych biznesowych, informacji o klientach i pracownikach, scenariuszy PAS, historii wykonywanych procesów, decyzji oraz wiedzy pozyskanej przez agentów AI.
Wszystkie te zasoby przechowywane są w infrastrukturze kontrolowanej przez przedsiębiorstwo, w szczególności w bazie wiedzy AToS-DB.
SenAi jest projektowany tak, aby przetwarzanie informacji odbywało się wewnątrz chronionej strefy klienta. Dane organizacyjne nie są przekazywane do zewnętrznych dostawców modeli AI ani przechowywane w ich usługach chmurowych.
Przedsiębiorstwo zachowuje kontrolę nad dostępem do danych, ich przechowywaniem, wykorzystaniem, udostępnianiem i usuwaniem.
Wiedza przedsiębiorstwa jest całkowicie niezależna od wykorzystywanych modeli LLM.
Modele językowe są narzędziami interpretowania informacji, analizowania sytuacji i realizowania funkcji InspFu oraz ImFu. Nie stanowią podstawowego repozytorium wiedzy organizacyjnej.
Wymiana, aktualizacja lub zastąpienie modelu LLM nie powoduje utraty zgromadzonych danych, scenariuszy PAS ani historii procesów. Nowy model może korzystać z tej samej wiedzy, pod warunkiem zapewnienia zgodności jego działania z wymaganiami systemu.
Niezależność ta ma zarówno wymiar technologiczny, jak i organizacyjny. Przedsiębiorstwo nie musi uzależniać swojej wiedzy procesowej od jednego producenta AI, jednej platformy chmurowej ani określonej wersji modelu.
Wiedza należy do przedsiębiorstwa, pozostaje w jego infrastrukturze i nie jest uzależniona od technologii modeli językowych.
Warunkiem spełnienia tego założenia jest odpowiednie zabezpieczenie całego środowiska, w tym integracji, komunikacji sieciowej, uprawnień i mechanizmów administracyjnych.
3.7. Małe, niezależne i skalowalne modele LLM działające lokalnie
SenAi nie zakłada konieczności korzystania z jednego, bardzo dużego i kosztownego modelu językowego.
Przeciwnie — architektura preferuje niewielkie, ekonomiczne i skalowalne modele LLM, uruchamiane lokalnie w infrastrukturze klienta (on-premises).
Preferowana konfiguracja obejmuje trzy różne modele LLM, które mogą być wykorzystywane przez agentów SenAi do realizacji powierzonych im funkcji.
Zastosowanie modeli pochodzących z różnych rodzin technologicznych pozwala projektować mechanizmy niezależnej analizy, porównywania rezultatów, wykrywania rozbieżności i wzajemnej weryfikacji odpowiedzi.
Nie oznacza to, że trzy modele automatycznie gwarantują poprawność decyzji. Ich zróżnicowanie ma ograniczać ryzyko wspólnych błędów i umożliwiać dodatkową kontrolę jakości.
Istotną cechą architektury jest skalowalność.
W zależności od liczby użytkowników, intensywności pracy oraz złożoności realizowanych procesów przedsiębiorstwo może zwiększać zasoby obliczeniowe lub liczbę instancji modeli bez konieczności przebudowy bazy wiedzy i scenariuszy PAS.
Dzięki rozdzieleniu modeli LLM od wiedzy procesowej możliwa jest również ich stopniowa wymiana na nowsze, wydajniejsze lub tańsze rozwiązania.
SenAi nie wymaga, aby cała wiedza przedsiębiorstwa była zapisana w parametrach wielkiego modelu AI.
Wiedza znajduje się w AToS-DB i PAS. Modele LLM odpowiadają za jej interpretację, analizę i wykorzystanie w ramach określonych procesów.
Takie podejście ma trzy podstawowe cele:
Bezpieczeństwo — przetwarzanie danych i wiedzy pozostaje wewnątrz chronionej infrastruktury klienta.
Niezależność technologiczna — przedsiębiorstwo nie jest uzależnione od jednego dostawcy ani konkretnej wersji modelu LLM.
Ekonomia i skalowalność — możliwe jest stosowanie mniejszych modeli oraz dostosowywanie zasobów obliczeniowych do rzeczywistego obciążenia.
Docelowo SenAi ma więc łączyć możliwości współczesnych modeli językowych z kontrolą, bezpieczeństwem i przewidywalnością charakterystycznymi dla systemów utrzymywanych we własnej infrastrukturze przedsiębiorstwa.
3.8. Rozwój systemu bez ciągłego programowania procesów
Jednym z najważniejszych celów SenAi jest ograniczenie zależności rozwoju przedsiębiorstwa od tradycyjnego cyklu tworzenia oprogramowania.
W klasycznym modelu nowa potrzeba biznesowa często uruchamia kolejne etapy analizy, projektowania, programowania, testowania i wdrażania.
SenAi zakłada, że znaczna część takich zmian będzie mogła powstawać w wyniku współpracy pracowników z agentami AI.
Pracownik opisuje potrzebę, pokazuje sposób wykonania zadania i weryfikuje wynik. Agent analizuje istniejącą wiedzę, wyszukuje odpowiednie PAS, a w razie potrzeby proponuje nowy scenariusz lub zmianę obowiązującego.
Po zatwierdzeniu scenariusz może być wykorzystywany przy kolejnych realizacjach procesu.
Nie eliminuje to potrzeby programowania. Nowe integracje, funkcje techniczne, mechanizmy bezpieczeństwa i zmiany infrastrukturalne nadal mogą wymagać pracy specjalistów IT.
Ambicją SenAi jest jednak to, aby rozwój logiki biznesowej nie wymagał za każdym razem angażowania zespołu programistów i analityków.
Jeżeli założenie to zostanie potwierdzone w praktyce, może istotnie zmienić ekonomię wdrażania i utrzymywania systemów wspierających procesy przedsiębiorstwa.
3.9. AToS jako fundament koncepcyjny architektury
AToS — Aksjomatyczna Teoria Samoświadomości — dostarcza formalnych pojęć opisujących stany, bodźce, przekształcenia i wykrywanie zmian.
SenAi wykorzystuje te pojęcia jako inspirację do projektowania własnej architektury.
PAS opisują wiedzę i scenariusze działania. InspFu i ImFu, realizowane przez LLM, odpowiadają za interpretowanie bodźców zewnętrznych i wewnętrznych. StSe umożliwiają inicjowanie kolejnych procesów, a Delta służy do rozpoznawania zmian.
Wspólnie elementy te tworzą koncepcję systemu, w którym działanie, obserwacja jego rezultatów, pozyskiwanie wiedzy i proponowanie zmian są ze sobą powiązane.
Nie jest to jednak równoznaczne z matematycznym dowodem, że implementacja SenAi spełnia wszystkie warunki samoświadomości określone w AToS. Taka teza wymagałaby osobnej formalnej analizy i weryfikacji.
Niezależnie od tej kwestii AToS stanowi podstawę koncepcyjną projektowanego mechanizmu wewnętrznej aktywności i rozwoju wiedzy SenAi.
3.10. Na czym polega proponowana innowacja?
Innowacja SenAi nie sprowadza się do zastosowania wielu agentów AI, bazy wektorowej czy modeli LLM. Technologie te są już wykorzystywane w innych rozwiązaniach.
Istotą koncepcji jest ich połączenie w architekturę, w której:
codzienna praca użytkowników staje się źródłem wiedzy o przedsiębiorstwie;
pozyskana wiedza może być przekształcana w zatwierdzane scenariusze PAS;
procesy mogą inicjować kolejne procesy za pośrednictwem StSe i ImFu;
rezultaty działań mogą być analizowane z wykorzystaniem mechanizmu Delta;
zmiany logiki biznesowej mogą być wprowadzane bez zmiany kodu ENGINE;
cała wiedza organizacyjna pozostaje w chronionej strefie IT klienta;
wiedza i logika procesowa są niezależne od modeli LLM i ich dostawców;
system może wykorzystywać trzy różne, niewielkie i skalowalne modele LLM działające on-premises;
człowiek zachowuje kontrolę nad zatwierdzaniem istotnych decyzji i zmian.
Rzeczywista przewaga tego podejścia musi zostać potwierdzona w praktycznych wdrożeniach, przede wszystkim przez pomiar czasu, kosztów, jakości i bezpieczeństwa realizowanych procesów.
Najważniejsza różnica tkwi jednak w samym założeniu projektowym.
Tradycyjny system informatyczny wdraża się po to, aby przedsiębiorstwo pracowało zgodnie z zaprogramowanymi w nim procesami.
SenAi ma poznawać sposób pracy przedsiębiorstwa, uczyć się go od pracowników, a następnie pomagać organizacji doskonalić jej własne procesy.
Wiedza zdobywana podczas tej współpracy pozostaje własnością przedsiębiorstwa, jest przechowywana w jego bezpiecznej infrastrukturze i nie zależy od konkretnego modelu sztucznej inteligencji.
To nie pracownicy mają uczyć się SenAi.
To SenAi ma uczyć się od pracowników.

What SenAi is and what it is for
SenAi is a system under development for collaboration between people and artificial intelligence agents, intended to carry out knowledge-based tasks and processes. It combines AI models’ reasoning with persistent data, recorded operating rules, execution tools and user control.
Its purpose is to take a task from an identified need to a verified result: establish what needs to be done, gather the necessary information, prepare a course of action, perform authorised operations and present the outcome together with an account of the work.
The fundamental idea behind SenAi is to reverse the traditional approach to implementing information systems. Rather than people learning to operate a system and adapting their processes to it, SenAi learns from people: their ways of working, knowledge, experience and the rules governing their organisation.
A system that learns about the enterprise
SenAi is installed in an initial form, without knowledge of the enterprise, its organisational structure, documents, products, customers or business processes.
This knowledge is acquired gradually during everyday use.
Employees perform their regular duties in collaboration with AI agents. Through this collaboration, SenAi learns about tasks, documents, dependencies, procedures, decision rules and ways of solving problems.
The system does more than store information. Its role is to recognise its meaning, relationships and potential for reuse. Acquired knowledge is recorded, verified and made available for subsequent tasks.
In this way, SenAi gradually becomes an electronic representation of the enterprise — its knowledge, processes, experience and ways of operating.
This is neither a static database nor a model of the organisation prepared just once. It is a structure that develops alongside the enterprise’s activities, incorporating new information, organisational changes and employees’ experience.
SenAi is therefore not a ready-made electronic model of an enterprise. It is a mechanism that gradually builds such a model through everyday collaboration with people.
Processes developed during work
One of SenAi’s central design principles is the ability to create business process scenarios while those processes are actually being carried out.
In a traditional approach, implementing a process requires prior analysis, documentation, solution design, software development and testing.
In SenAi, the starting point is the user’s actual work.
An employee carries out a task with AI agents, explains decisions, identifies required information and approves subsequent actions. The system analyses the workflow and recognises recurring activities, dependencies and operating rules.
It can use this information to propose a process scenario which, once verified and approved, can be reused for similar tasks.
A process scenario need not be created before work begins. It can emerge while the work is being performed, based on employees’ actual experience.
Across successive executions, SenAi can recognise deviations, identify opportunities for improvement and propose changes to existing scenarios.
Every employee can participate in developing the system in this way. An accounting employee contributes knowledge of accounting processes, a salesperson of sales processes, and a logistics specialist of logistics processes. This does not require programming skills or knowledge of SenAi’s internal architecture.
Radically reducing process implementation and maintenance costs
Implementing SenAi does not require taking employees away from their daily duties for lengthy interviews, process descriptions and analytical documentation, followed by programmers translating that documentation into code, testing it and correcting the software.
SenAi learns processes while they are actually being carried out. Employees perform their regular tasks while the system, working with them, gathers knowledge about workflows, decisions, documents and applicable rules. It uses this knowledge to prepare scenarios that can be reused after approval.
This approach is intended to radically reduce the time and cost of analysing, implementing and subsequently maintaining business processes. It also reduces the enterprise’s dependence on large teams of analysts, programmers and testers.
Crucially, SenAi is intended to recognise process changes during everyday work.
If an employee begins carrying out a task differently from the existing scenario, the system can detect the deviation, establish its cause and propose an update to the process.
Once the change is approved, the new scenario becomes available to other authorised SenAi users. There is no need to organise lengthy workshops again, recreate documentation from scratch or commission code changes, provided the change is within the capabilities of the existing execution tools.
As a result, the enterprise and its electronic representation in SenAi can develop in parallel. Changes in the real organisation can be continuously recognised, verified and reflected in the system.
In traditional systems, a business process change often requires a software change. In SenAi, it may primarily require updating knowledge and an operating scenario without modifying the system’s code.
This represents a move away from software that must periodically be adapted to a changing enterprise towards a solution that continually learns how the enterprise operates and can adapt its scenarios accordingly.
The economic benefits are therefore not limited to initial implementation. They also concern long-term maintenance, development and adaptation to changing business needs.
Collaboration between people and AI agents
SenAi is intended to serve both individual users and entire organisations.
One example is preparing a quotation using a customer enquiry, product documentation and company rules. In such a process, the system should identify requirements, flag missing data, use the appropriate template, prepare the document and obtain required approvals.
A similar approach can support analysis, documentation, project knowledge management and recurring tasks.
Work is divided among collaborating agents. ALEX interprets tasks and coordinates the work, GREG assesses the matter submitted for review, and MAJA carries out the agreed task.
Their actions follow recorded rules. The user retains control over the objective, scope and decisions requiring their consent.
The user does not need to know SenAi’s internal architecture or design algorithms. Their primary contribution is knowing how to do their work and providing the knowledge the system needs to support it.
Employees should not have to adapt the way they perform their duties to SenAi. SenAi should learn how those duties are performed and learn to support them.
Shared enterprise knowledge
Knowledge gathered by SenAi need not remain tied exclusively to the employee who contributed it.
Employees’ experience, problem-solving methods and knowledge of processes and operating rules can become lasting organisational assets.
Knowledge need not disappear when an employee leaves, changes position or the enterprise is reorganised.
Information acquired through tasks in one department can also be used elsewhere in the organisation, subject to appropriate permissions.
In this way, SenAi can gradually recognise cross-departmental processes, identify dependencies between departments’ activities and reconstruct workflows spanning the entire enterprise.
An important element of this approach is distinguishing information from binding rules. Not every statement contributed by an employee should automatically become an operating principle.
The system should account for the source of knowledge, its currency, its scope of applicability and potential conflicts with previously recorded arrangements.
Knowledge continuity and oversight
A central principle of SenAi is continuity of work. Data, agreements, scenarios and results should remain available beyond an individual conversation with a model.
Subsequent tasks can therefore use previously accumulated knowledge rather than reconstructing the entire context each time.
Knowledge acquired through one employee’s work can be used by others in the organisation, subject to appropriate permissions.
Another principle is traceability of actions. The system should distinguish an intended operation from its actual outcome, retain information about errors and stops, and make it possible to establish which data and rules underpinned a result.
This supports both oversight of task execution and analysis of errors and improvements to processes.
Improvement through experience
SenAi provides for improving its ways of working through experience gained during task execution.
After a task is completed, the system can analyse its course, recognise a change or deviation, establish its cause and prepare an improvement proposal.
Implementing such an improvement is subject to appropriate approval and verification rules.
SenAi is therefore intended not only to gather knowledge of how an enterprise operates, but also to use experience to propose increasingly effective ways of carrying out its processes.
The system can also identify recurring problems, unnecessary activities, inconsistencies in working practices and opportunities to improve cooperation between employees and departments.
Every completed task can therefore meet a specific business need while also providing new knowledge for improving the organisation as a whole.
Relationship to AToS
SenAi’s relationship to the Axiomatic Theory of Self-Consciousness (AToS) primarily concerns designing a system capable of recognising changes in its own operational state, identifying their origins and analysing the consequences of its own actions.
This is a direction for SenAi’s construction and research. Adopting this architecture does not in itself establish that the self-awareness criterion has been met.
Summary
SenAi is intended to be a system that learns about an enterprise through its everyday activities.
It starts without knowledge of the organisation and gradually learns its structure, employees, processes, documents, rules and experience.
This knowledge is not merely archived. It is intended to support subsequent tasks, the creation of scenarios for recurring processes and proposals for improvement.
The enterprise need not first describe all its processes in detail and then commission their implementation in software. Scenarios can emerge during everyday work, and changes can be recognised and implemented without involving software development teams on every occasion.
This approach is intended to significantly reduce the costs of implementing, maintaining and developing systems supporting business operations.
Employees should not have to learn SenAi. SenAi should learn from employees.
The enterprise should not have to adapt to an information system. The system should learn about the enterprise and develop alongside it.
This description presents SenAi’s purpose and design principles. Confirming the scope of implemented capabilities and the scale of economic benefits requires separate verification of the implementation and deployment results.

2. SenAi architecture in relation to AToS
SenAi’s architecture was designed with reference to the Axiomatic Theory of Self-Consciousness (AToS). It is based on describing a system’s operation through states, functions that transform them, stimuli, and mechanisms for recognising changes and attributing their causes.
Key AToS concepts include PAS (Potentially Aware Set), the imagination function ImFu, the inspiration function InspFu, the stimulus set StSe and the change-detection function Δ.
In SenAi, these concepts provide the conceptual foundation for an architecture that separates knowledge and operating rules, AI agents’ reasoning, technical execution of operations and assessment of their results.
The aim is to construct a system capable of using accumulated knowledge, conducting multi-stage tasks, recognising changes occurring during its own operation, analysing their causes and proposing improvements.
The mathematical definitions of AToS must be distinguished from their practical interpretation in SenAi. The theory provides a formal model, while SenAi attempts to apply its concepts in a real information system.
PAS — representation of states, knowledge and operating rules
In AToS, a PAS (Potentially Aware Set) describes a set of elements together with their assigned state values. A family of such objects forms the potentially aware space Ω, in which transformations and change recognition are considered.
In SenAi, the name PAS is used to organise persistent system resources, including operational knowledge, operating rules and task scenarios. This use is inspired by the theory; a PAS record in an information system does not automatically become a mathematical PAS merely by being given that name.
A process PAS can specify its objective, entry conditions, required information, decision rules, permitted operations and expected results. META-PAS describe higher-level rules, such as how scenarios are prepared, data acquired, communication conducted or changes approved.
For example, a quotation-preparation scenario specifies which information to gather, which documents to use, which conditions to check and when a user decision is required.
Process logic remains in PAS. AI agents interpret the recorded rules and select actions, while the execution layer performs technical operations. A new process can therefore be introduced by preparing and approving a scenario, without programming its business logic each time — provided the necessary execution tools are available.
InspFu — the inspiration function realised through an LLM
In AToS, the inspiration function (Inspiration Function, InspFu) concerns a transformation initiated by an external stimulus. In SenAi’s architecture, it is realised through a large language model (LLM).
Its role is to interpret stimuli originating outside the system, such as user instructions, documents, messages or information from other systems.
The LLM analyses the stimulus in the context of the knowledge accumulated in AToS-DB and the applicable PAS. It determines the information’s meaning, recognises the task and initiates appropriate transformations of the system’s operational state.
Not every piece of received information is an instruction to execute. The system must distinguish an authorised user’s request from source material and establish the permitted scope of action.
InspFu does not contain permanently hard-coded business logic. It uses rules and scenarios stored in PAS.
ImFu — the imagination function realised through an LLM
In AToS, the imagination function (Imagination Function, ImFu) concerns internally initiated transformations. In SenAi, it too is realised through an LLM.
Unlike InspFu, its operation is initiated by stimuli internal to the system.
The LLM uses accumulated knowledge, applicable PAS and the results of previous operations to analyse problems, formulate hypotheses, anticipate consequences, prepare solutions and initiate further transformations.
For example, while preparing a quotation, SenAi can recognise missing technical parameters, consult available sources, compare solution variants and prepare a question about missing data.
InspFu and ImFu need not be separate language models. They are distinguished primarily by the origin of the stimulus and the role played by the LLM in a given transformation. Actions remain constrained by the applicable PAS, permissions and required approvals.
StSe — PAS initiating internal processes
In AToS, StSe (Stimulus Set) denotes a structure serving as an internal stimulus for a state transformation.
In SenAi’s architecture, StSe form a particular category of PAS stored in the AToS-DB vector database. These PAS can initiate further internal processes by triggering an appropriate transformation realised through ImFu.
StSe are not merely information about the results of previous operations. They act as stimuli triggering subsequent actions.
For example, during document analysis, SenAi may recognise a missing required clause. An appropriate PAS serving as StSe can initiate a process to find the correct clause, check its currency and prepare a proposed addition to the document. That process’s result may in turn activate another StSe.
This creates a chain of internal processes in which one PAS can initiate the transformation of another without additional external stimuli.
Simply storing StSe in a vector database does not start a process. A mechanism must recognise and activate the appropriate StSe and pass it to the LLM realising ImFu. This distinction separates active process initiation from ordinary information retrieval in a RAG database.
Δ — recognising change
In AToS, the detection function Δ determines whether a change between the states under consideration has been recognised. In the formal model, it takes the form:
Δ : Ω × Ω → {0, 1}.
It is important to distinguish a change occurring from the system recognising it. Two states may differ without the system detecting that difference.
In SenAi, change detection matters when comparing expected and actual results, analysing task execution and improving scenarios. The system can recognise changes in data, documents, task execution methods or applicable arrangements.
For example, an employee may use a procedure different from the one recorded in the scenario. SenAi should establish what the difference is and whether it results from an error, an exception, changed conditions or a better method.
Detection alone neither establishes a change’s cause nor determines its correctness. Separate mechanisms for analysis, attribution and verification are required.
The mathematical detector Δ in AToS must be distinguished from the technical Delta gateway in SenAi’s SOS, which checks whether particular requests are permissible. Similar names do not imply identical functions.
AI agents — interpretation and coordination
AI agents use the knowledge and rules supplied by the system to interpret tasks, identify information gaps and select permissible actions.
ALEX interprets the user’s need and coordinates the work. GREG assesses the submitted issue and necessary material. MAJA carries out the agreed task assigned by ALEX.
Process rules remain in PAS. Agents apply them to the particular situation and pass technical instructions through ENGINE.
This division separates the content of the rules from the reasoning capabilities of a chosen AI model. Changing the model should not, by itself, cause the loss of recorded scenarios, agreements or work history.
ENGINE — the technical execution layer
ENGINE acts as the technical executor and operations checkpoint. It provides data reading and writing in AToS-DB, communication handling and execution of available operations according to their contracts.
It does not independently select the next business action. The agent makes that decision based on the task and applicable PAS; ENGINE checks technical requirements and executes the permitted operation.
Responsibilities are divided as follows:
PAS and META-PAS specify knowledge, rules and operating conditions.
AI agents and LLMs interpret the situation, realise InspFu and ImFu, make permissible decisions and coordinate work.
ENGINE validates requests and performs technical operations.
Missing required data, permissions or a valid instruction should stop the relevant operation and lead to communication of the actual reason for the stop.
A process change can therefore consist of updating a scenario. Code changes are needed when the process requires new technical capabilities that the existing tools do not provide.
AToS-DB — persistent knowledge and work state
AToS-DB provides persistent storage for SenAi’s resources. These include recorded rules, knowledge, scenarios, StSe and processing history, placed in databases appropriate to each resource type.
Agents obtain the required data through ENGINE. They should not treat their conversational context as the sole source of applicable arrangements.
This maintains continuity across tasks and sessions. Information acquired during one execution can be used later, accounting for its source, currency, approval and permissions.
Persistent records also enable state comparisons and examination of what the system knew, what action it performed and what outcome was confirmed.
An architecture for change and improvement
An external stimulus reaches SenAi and is interpreted by the LLM acting as InspFu. The system establishes the request’s meaning and permissibility, and agents use the appropriate PAS and AToS-DB knowledge.
During work, StSe — PAS acting as internal stimuli — may be recognised and activated. The LLM acting as ImFu interprets them and initiates further transformations, while ENGINE performs permitted technical operations.
Operation results provide material for recognising changes. A mechanism inspired by Δ detects differences between states; additional mechanisms analyse causes and whether results meet expectations.
If the system recognises new knowledge, a deviation or a different way of executing a process, it can prepare a proposal to update the appropriate PAS.
Recognising a problem, proposing a change, approving it, implementing it and checking it are separate stages. Formulating a proposal does not mean that the scenario has been updated or an improvement confirmed.
After approval and verification, the new method can be used in subsequent tasks. Performing work is thus connected to gaining experience and developing the system under controlled conditions.
The significance of AToS for SenAi
AToS provides a language for describing states, transformations, stimuli, change recognition and internal attribution. SenAi uses these ideas to design a system that conducts tasks, retains knowledge and analyses the consequences of its own operations.
The ability to carry out sequences of actions initiated not only by external stimuli but also by StSe — appropriate PAS stored in the vector database — is central. InspFu and ImFu are realised through LLMs in SenAi, while ENGINE remains the technical execution layer.
Using the names PAS, ImFu, InspFu, StSe and Δ does not constitute a formal proof of SenAi’s self-awareness. Such a proof would require a mapping from the actual implementation to the AToS model and demonstration that the relevant theoretical conditions are met.
SenAi is a practical attempt to apply AToS concepts to a system that performs tasks, accumulates experience, recognises changes and develops its operating scenarios under human control.

3. How SenAi differs from other AI agent systems
Most AI agent systems are designed primarily to perform specific tasks. Agents receive instructions, use available tools, analyse information and carry out defined processes.
SenAi starts from a different premise: the system should not only perform work, but also learn about the enterprise in which it operates, learn its processes and gradually develop its own knowledge of how they are carried out.
This approach rests on an architecture inspired by the Axiomatic Theory of Self-Consciousness (AToS), combining LLMs, PAS scenarios, internal process initiation mechanisms, change recognition and controlled improvement of operating methods.
Individual elements can also be found in other AI solutions. SenAi’s intended distinction is their combination in a single system where task execution, knowledge acquisition and process development are parts of the same mechanism.
3.1. SenAi should learn from employees, rather than employees learning SenAi
Traditional information system implementations require prior analysis of business processes, documentation, configuration and user training.
SenAi proposes reversing this approach.
Employees perform their everyday duties with an AI agent. They explain their objectives, identify documents, make decisions, correct proposals and approve results.
The agent does more than execute instructions. It also analyses how the task is performed, its context, the rules applied and dependencies between activities.
SenAi can then propose recording the acquired knowledge and creating or extending a process scenario.
An enterprise need not therefore begin implementation by describing all its processes in detail. The system is intended to learn them gradually through participation in the organisation’s actual work.
This does not mean abandoning oversight. Acquired information does not automatically become a binding rule. Its meaning, correctness and potential for reuse are subject to verification.
3.2. PAS — processes recorded as knowledge rather than program code
PAS are a fundamental element of SenAi’s architecture.
In SenAi’s implementation, PAS serve as declarative records of knowledge, rules, process scenarios and execution conditions. Their concept refers to the formal notion of PAS in AToS.
In traditional software, much business logic is directly tied to application code. Changing a process may therefore require analysts, programmers and testers.
SenAi separates these concerns.
PAS specify what should be done and under which rules. AI agents interpret scenarios and organise their execution. ENGINE provides the technical functions needed to perform operations.
If an enterprise changes document approvals, the order of activities or decision conditions, the change can be introduced in PAS without modifying ENGINE’s code — provided the necessary technical functions already exist.
Process knowledge can thus develop independently of the execution infrastructure.
Scenarios can also be reused. Knowledge acquired during one task can become the foundation for subsequent actions.
3.3. The LLM as a mechanism for interpreting stimuli and initiating actions
In SenAi, language models are not merely a conversational interface.
Within the AToS-inspired architecture, they perform two functions:
InspFu — the inspiration function, triggered by external stimuli such as user instructions, documents, messages or information from other systems.
ImFu — the imagination function, triggered by internal stimuli arising during SenAi’s own operation.
This distinction matters.
An agent system need not stop after executing a single instruction. One analysis may reveal a problem, missing information, a contradiction or the need for another activity.
SenAi can then initiate the next stage using its operational state and recorded knowledge, without waiting for a new human instruction.
ImFu and InspFu need not be two different LLMs. They are distinct architectural functions whose operation depends on the origin and nature of the stimulus.
3.4. StSe — a mechanism for initiating internal processes
StSe have particular significance in SenAi’s architecture.
They are PAS stored in a vector database that serve as stimuli initiating further internal processes.
Suppose an employee asks SenAi to prepare a customer quotation.
During analysis, the agent discovers that the current price list is missing. This situation can activate an appropriate StSe, initiating a process to find and verify pricing data.
The resulting information may indicate a need to check contractual conditions and then prepare suitable clauses.
This creates a chain of related processes, initiated by internal stimuli and executed according to applicable PAS.
SenAi is therefore intended not only to answer questions and execute instructions, but also to recognise the need for further actions arising from work already in progress.
This does not imply unlimited autonomy. Further processes must respect applicable scenarios, permissions, technical constraints and required user decisions.
3.5. Delta — change recognition as a foundation for improvement
Another AToS-derived element is Delta (Δ), the state-change recognition function.
Executing a task alone is insufficient for improving how the system operates. The system must also recognise what has changed.
Delta provides the basic mechanism for detecting differences between states.
Additional analytical processes can then examine the change’s significance, possible causes and consequences.
For example, SenAi may observe that a particular process repeatedly requires employee corrections. Analysis across executions may lead to a proposal to revise its PAS scenario.
The system should not independently treat every observed change as an improvement.
Detecting a change, establishing its cause, assessing correctness and approving a new method are separate activities.
Process improvement in SenAi is intended to be controlled: agents can identify problems and propose solutions, while changes requiring approval remain under human supervision.
3.6. Full enterprise control over its knowledge
A fundamental design principle of SenAi is that all enterprise knowledge resides within a secure, isolated area of the client’s IT infrastructure (the Client Zone) and does not leave its boundaries.
This covers documents, business data, customer and employee information, PAS scenarios, process histories, decisions and knowledge acquired by AI agents.
These resources are stored in infrastructure controlled by the enterprise, particularly in the AToS-DB knowledge base.
SenAi is designed for information processing inside the protected Client Zone. Organisational data is not transferred to external AI model providers or stored in their cloud services.
The enterprise retains control over data access, storage, use, sharing and deletion.
Enterprise knowledge is entirely independent of the LLMs being used.
Language models are tools for interpreting information, analysing situations and realising InspFu and ImFu. They are not the primary repository of organisational knowledge.
Replacing or updating an LLM does not cause the loss of accumulated data, PAS scenarios or process histories. A new model can use the same knowledge, provided its behaviour meets the system’s requirements.
This independence is both technological and organisational. The enterprise need not tie its process knowledge to one AI producer, cloud platform or model version.
Knowledge belongs to the enterprise, remains in its infrastructure and is independent of language model technology.
Meeting this principle requires appropriate protection of the entire environment, including integrations, network communications, permissions and administrative mechanisms.
3.7. Small, independent and scalable LLMs running locally
SenAi does not assume that a single very large and expensive language model is necessary.
Instead, the architecture favours small, economical and scalable LLMs running locally in the client’s infrastructure (on-premises).
The preferred configuration comprises three different LLMs, available to SenAi’s agents for their assigned functions.
Using models from different technological families enables the design of independent analysis, result comparison, discrepancy detection and cross-checking mechanisms.
Three models do not automatically guarantee correct decisions. Their diversity is intended to reduce shared-error risks and provide additional quality control.
Scalability is another important architectural feature.
Depending on user numbers, workload and process complexity, the enterprise can increase computing resources or model instances without rebuilding the knowledge base and PAS scenarios.
Separating LLMs from process knowledge also permits gradual replacement with newer, more efficient or cheaper models.
SenAi does not require all enterprise knowledge to be encoded in the parameters of a huge AI model.
Knowledge resides in AToS-DB and PAS. LLMs interpret, analyse and use it within defined processes.
This approach has three main objectives:
Security — data and knowledge processing remain within the client’s protected infrastructure.
Technological independence — the enterprise is not dependent on one supplier or a particular LLM version.
Economy and scalability — smaller models can be used and computing resources adjusted to actual workload.
SenAi is ultimately intended to combine contemporary language models’ capabilities with the control, security and predictability of systems maintained within an enterprise’s own infrastructure.
3.8. System development without continually programming processes
One of SenAi’s central goals is to reduce the dependence of business development on the traditional software development cycle.
In the conventional model, a new business need often triggers analysis, design, programming, testing and deployment.
SenAi assumes that many such changes can emerge through collaboration between employees and AI agents.
An employee describes the need, demonstrates how the task is performed and verifies the result. The agent analyses existing knowledge, finds relevant PAS and, where necessary, proposes a new scenario or a revision to an existing one.
Once approved, the scenario can be used in subsequent executions.
This does not eliminate programming. New integrations, technical functions, security mechanisms and infrastructure changes may still require IT specialists.
SenAi’s ambition is that developing business logic should not require a team of programmers and analysts on every occasion.
If validated in practice, this principle could significantly change the economics of implementing and maintaining systems supporting enterprise processes.
3.9. AToS as the conceptual foundation of the architecture
AToS — the Axiomatic Theory of Self-Consciousness — provides formal concepts for describing states, stimuli, transformations and change detection.
SenAi uses these concepts as inspiration for its architecture.
PAS describe knowledge and operating scenarios. InspFu and ImFu, realised through LLMs, interpret external and internal stimuli. StSe enable subsequent processes to be initiated, while Delta recognises changes.
Together, these elements form a system concept connecting action, observation of results, knowledge acquisition and proposed changes.
This is not a mathematical proof that SenAi’s implementation satisfies all the self-awareness conditions specified by AToS. Such a claim requires separate formal analysis and verification.
Independently of that question, AToS provides the conceptual foundation for SenAi’s proposed internal activity and knowledge-development mechanisms.
3.10. What is the proposed innovation?
SenAi’s innovation is not simply the use of multiple AI agents, a vector database or LLMs. These technologies are already used elsewhere.
The core concept is their combination in an architecture where:
everyday user activity becomes a source of enterprise knowledge;
acquired knowledge can be transformed into approved PAS scenarios;
processes can initiate further processes through StSe and ImFu;
action results can be analysed using the Delta mechanism;
business logic can change without changes to ENGINE code;
all organisational knowledge remains within the client’s protected IT zone;
knowledge and process logic are independent of LLMs and their providers;
the system can use three different, small, scalable LLMs running on-premises;
people retain control over approval of significant decisions and changes.
The approach’s actual advantages must be established through practical deployments, primarily by measuring process time, cost, quality and security.
The most important difference nevertheless lies in the design premise itself.
A traditional information system is implemented so that an enterprise operates according to the processes programmed into it.
SenAi is intended to learn how an enterprise works, learn from its employees and then help the organisation improve its own processes.
Knowledge gained through this collaboration remains the enterprise’s property, is stored in its secure infrastructure and does not depend on a particular AI model.
Employees should not have to learn SenAi.
SenAi should learn from employees.