Agent czy proces pracy? Oddzielenie rozumowania od wykonywania zadań w sztucznej inteligencji korporacyjnej

Sztuczna inteligencja agentowa to aktualny hit. Daj modelowi językowemu niektóre narzędzia, dodaj pamięć, połącz go z systemami korporacyjnymi, pozwól mu zdecydować, co robić dalej – wtedy taki wynik nazywany jest agentem sztucznej inteligencji. Istnieje jednak pewien problem: systemy korporacyjne nie mogą funkcjonować wyłącznie na podstawie decyzji probabilistycznych. Gdy sztuczna inteligencja ma dostęp do danych dostawców, procesów finansowych, danych ERP, zatwierdzeń czy innych krytycznych operacji, niektóre wybory mogą pozostać elastyczne, a inne nie.

Projekt zarządzania dostawcami oparty na technologiach RAG, LangGraph, MCP, ludzkim zatwierdzeniu oraz Amazon Bedrock doprowadził do jednej kluczowej koncepcji: agent powinien decydować, co musi się wydarzyć, a aplikacja powinna kontrolować sposób realizacji tego zadania. Wszystko inne w projekcie wynika z tej podziałki.

Dlaczego agent nie powinien robić wszystkiego

Załóżmy prośbę o włączenie dostawcy: należy stworzyć tego dostawcę, zweryfikować jego dane, sprawdzić politykę zakupową i wysłać ją do SAP. Teoretycznie w pełni autonomiczny agent mógłby zinterpretować tę prośbę, przeszukać wewnętrzne dokumenty, zweryfikować dane, zdecydować, czy potrzebna jest zgoda, połączyć się z SAP, utworzyć rekord i spróbować ponownie w przypadku niepowodzenia.

To jest technicznie możliwe, ale architektonicznie niepraktyczne. LLM działają na zasadzie prawdopodobieństwa – ten sam wprowadzony tekst może prowadzić do nieco innych ścieżek rozumowania, a modele, prompty i kontekst stale się zmieniają. Ta elastyczność jest doskonała do interpretacji intencji osoby, ale nie nadaje się do wykonywania krytycznych transakcji biznesowych. Model nie powinien decydować o zatwierdzeniu transakcji w bazie danych, wymyślać własnej strategii ponownych prób, oceniać, czy można pominąć autoryzację, ani przechowywać uprawnień do SAP. Dlatego rozumowanie i wykonywanie operacji są oddzielone.

Przepływy pracy kontra agenci

Często zamienia się te dwa terminy, ale różnica między nimi jest istotna. Przepływ pracy oparty na AI podąża przeważnie za z góry określoną ścieżką:

Request
   ↓
Validate
   ↓
Retrieve Policies
   ↓
Evaluate
   ↓
Approval
   ↓
Create Supplier
   ↓
Publish Integration Event

Aplikacja zna każdy stan oraz każdą transformację. Agent AI ma większą swobodę w wyborze tego, co nastąpi dalej:

User Request
      ↓
     LLM
      ↓
Reason about intent
      ↓
Choose next capability
   ↙    ↓     ↘
Search Validate Request Approval

Ta swoboda ma wartość, ale staje się ryzykowna, gdy agent dostępuje do infrastruktury transakcyjnej. Optymalny projekt łączy oba te modele.

Rozumowanie agentowe u góry, wykonywanie deterministyczne poniżej

USER
                      │
                      ▼
                 FastAPI API
                      │
                      ▼
                 LangGraph
                Agent Workflow
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
        RAG        Reasoning     Tools
          │
          ▼
   Amazon OpenSearch
          │
          ▼
     AWS Bedrock
                      │
                      ▼
                MCP Boundary
                      │
                      ▼
               Application API
                      │
                      ▼
              Domain / Use Cases
                      │
              ┌───────┴───────┐
              ▼               ▼
          PostgreSQL         AWS SQS
                                │
                                ▼
                               SAP

Jedna granica wyróżnia się. LLM znajduje się powyżej warstwy aplikacji. Potrafi interpretować żądania, rozumować, pozyskiwać wiedzę, rekomendować działania i prosić o narzędzia. Nie kontroluje transakcji.

Gdzie agenci zdobywają swoje miejsce

Rozumowanie probabilistyczne przynosi korzyści w kilku konkretnych sytuacjach.

Rozumienie intencji

Ludzie nie tworzą idealnie skonstruowanych wywołań API. Użytkownik może powiedzieć, że musi włączyć ACME do działalności w Brazylii i chce wiedzieć, czy wszystko jest zgodne z regulacjami. To zdanie łączy intencję, kontekst i niejednoznaczność, a LLM doskonale potrafi przekształcić je w coś, co aplikacja może wykorzystać:

{
  "intent": "supplier_onboarding",
  "supplier": "ACME",
  "country": "BR",
  "requires_policy_validation": true
}

Stamtąd przejmuje kontrolę oprogramowanie deterministyczne.

Pobieranie wiedzy przedsiębiorstwa za pomocą RAG

Proces wdrożenia zależy od polityki wewnętrznej: wymaganych dokumentów, zasad podatkowych, specyficznych wymagań dla danego kraju, ograniczeń w zakupach oraz progów zatwierdzenia. Zamiast wkładać te dokumenty do zapytań lub kodować każdą zasadę ręcznie, system może je pobrać:

Question
   ↓
Embedding
   ↓
Amazon OpenSearch
   ↓
Relevant Policy Chunks
   ↓
LLM Context
   ↓
Reasoning

Tutaj obowiązuje kolejna zasada. Pobieranie informacji dostarcza kontekstu i nie powinno wpływać na decyzje biznesowe. Przydatne jest znalezienie zasady stanowiącej, że dostawcy przekraczający określony próg wymagają zatwierdzenia. Egzekwowanie tego zatwierdzenia musi odbywać się w ramach zwykłej logiki aplikacji.

Gdzie procesy pracy radzą sobie lepiej

Gdy prośba zostanie zrozumiana, załóżmy, że konieczne jest utworzenie dostawcy. Proces może obejmować takie kroki jak te:

Validate Supplier
      ↓
Check Duplicate
      ↓
Check Authorization
      ↓
Persist Supplier
      ↓
Publish Integration Event
      ↓
Wait for SAP Result

LLM nie powinno tego improwizować. Proces pracy musi określić gwarancje wykonania: walidację, autoryzację, idempotencję, zapobieganie duplikatom, próby ponowne, logi audytowe, granice transakcji oraz obsługę błędów. To kwestie inżynierii oprogramowania, a projektowanie promptów nie ma z nimi nic wspólnego.

Dlaczego LangGraph

Do orkiestracji wybrano LangGraph, ponieważ oferuje wyraźne przejścia pomiędzy stanami, zamiast pętli otwartej, w której agent ciągle decyduje, który narzędzie wywołać dalej. Koncepcyjnie graf wygląda tak:

START
  │
  ▼
Understand Intent
  │
  ▼
Retrieve Policies
  │
  ▼
Evaluate Request
  │
  ├───────────────┐
  │               │
  ▼               ▼
Approval Needed?  No Approval
  │               │
  ▼               │
Human Approval    │
  │               │
  └───────┬───────┘
          ▼
     Request Action
          │
          ▼
         END

W wybranych węzłach model zachowuje swobodę rozumowania, podczas gdy graf ogranicza, jak daleko jego wnioski mogą wpłynąć na system. Rezultatem jest ograniczona autonomia: swoboda w ramach wyraźnie określonych zasad architektonicznych.

Pojęcie „człowiek w łańcuchu” ma więcej niż jedno znaczenie

Rozmowy na temat sztucznej inteligencji w przedsiębiorstwach często sprowadzają się do stwierdzenia „po prostu włącz człowieka do procesu”. Jednak ludzie mogą interweniować z różnych powodów, a warto odróżnić co najmniej dwa rodzaje zatwierdzeń.

Zatwierdzenie biznesowe

Sam proces biznesowy wymaga zatwierdzenia, niezależnie od tego, czy bierze udział w nim sztuczna inteligencja, czy nie:

Supplier
   ↓
Compliance Check
   ↓
Manager Approval
   ↓
Creation

Zatwierdzenie narzędzia AI

Potrzebne jest drugie zatwierdzenie, ponieważ agent chce wykonać czynność wrażliwą:

Agent
  ↓
"Create supplier"
  ↓
Tool requires confirmation
  ↓
Human approves
  ↓
Application executes

Te dwa zagadnienia się różnią. Jedno należy do dziedziny architektury, a drugie do zarządzania sztuczną inteligencją. Ich łączenie powoduje zamieszanie w kwestiach architektonicznych.

Dlaczego MCP jest ważne

Agent działający z systemami korporacyjnymi potrzebuje narzędzi, ale bezpośrednie udostępnianie infrastruktury modelowi LLM niesie ze sobą niepotrzebne ryzyko. Lepszym rozwiązaniem jest użycie narzędzia MCP:

Agent
  ↓
MCP Tool
  ↓
Application API
  ↓
Use Case
  ↓
Domain
  ↓
Infrastructure

i unika łączenia agenta z bazą danych:

Agent
  ↓
PostgreSQL

lub bezpośrednio do SAP:

Agent
  ↓
SAP

W przypadku pierwszej formy aplikacja nadal kontroluje procesy autoryzacji, walidacji, zasad biznesowych, audytu, transakcji oraz właściwości idempotencji. MCP stanowi granicę pomiędzy rozumowaniem AI a możliwościami przedsiębiorstwa. Agent wyraża intencje, natomiast aplikacja odpowiada za ich realizację.

SAP nie powinno polegać na ciągłym działaniu LLM

Zewnętrzne systemy mogą zawieść się. SAP może przestać działać, sieć może zostać przerwana, usługa poniżej w łańcuchu może wygenerować timeout, a dostawca LLM również może zostać offline. Wykonywanie wszystkiego synchronicznie w ramach pętli agenta utrudnia odporność systemu. Dlatego stosuje się asynchroniczną komunikację za pomocą AWS SQS. Zamiast tego:

Agent
  ↓
SAP
  ↓
Wait...
  ↓
Timeout

Przepływ staje się:

Agent
  ↓
Application
  ↓
Persist State
  ↓
AWS SQS
  ↓
Integration Worker
  ↓
SAP

Transakcje biznesowe nie muszą już czekać, aż SAP natychmiast udzieli odpowiedzi. Pracownik zajmuje się ponawianiami prób, mechanizmami opóźnienia, kolejkami wiadomości błędowych, możliwościami obserwacji oraz przetwarzaniem idempotentnym, a te gwarancje pochodzą od oprogramowania deterministycznego, a nie od jakiegoś modelu.

Architektura hybrydowa

Gdy te granice zostaną ustalone, określanie systemu jedynie jako agenta AI już nie jest odpowiednie. Jest to architektura hybrydowa:

┌─────────────────────────────┐
│     PROBABILISTIC LAYER     │
│                             │
│ LLM                         │
│ RAG                         │
│ Intent Understanding        │
│ Reasoning                   │
│ Tool Selection              │
└──────────────┬──────────────┘
               │
        Controlled Boundary
               │
┌──────────────▼──────────────┐
│     DETERMINISTIC LAYER     │
│                             │
│ Application Use Cases       │
│ Domain Rules                │
│ Authorization               │
│ Validation                  │
│ Transactions                │
│ Idempotency                 │
│ Messaging                   │
│ Integrations                │
└─────────────────────────────┘

To rozróżnienie jest kluczowe dla korporacyjnych agentowych systemów AI.

Architektura oprogramowania wciąż ma znaczenie

Powszechnym błędem w przypadku sztucznej inteligencji generatywnej jest założenie, że tradycyjna architektura przestała być istotna. Wręcz przeciwnie – jest jeszcze ważniejsza. System, który potrafi dynamicznie rozumować i wybierać działania, wymaga silniejszych ograniczeń dotyczących tego, co te działania mogą zrobić. DDD, CQRS, architektura sześciokątna, autoryzacja, uwierzytelnianie, komunikacja, obserwowalność, odporność i idempotencja wciąż mają zastosowanie. Sztuczna inteligencja nic z tego nie eliminuje – dodaje jedynie kolejny element probabilistyczny, który musi działać bezpiecznie obok tych rozwiązań.

Agent czy proces pracy?

Odpowiedź brzmi: i jedno, i drugie. Wykorzystuj agenty tam, gdzie niepewność i rozumowanie dodają wartości, a deterministyczne procesy pracy tam, gdzie ważna jest przewidywalność i gwarancje. Praktyczny model myślowy:

AI AGENT
                 │
                 │ decides WHAT
                 ▼
        ┌─────────────────┐
        │ Controlled Tool │
        │    Boundary     │
        └────────┬────────┘
                 │
                 │ requests
                 ▼
          APPLICATION
                 │
                 │ decides HOW
                 ▼
             DOMAIN
                 │
                 ▼
        INFRASTRUCTURE

LLM nie powinno stać się samą architekturą. Powinno w niej brać udział.

Gdzie autonomia przynosi korzyści

Prawidłowe pytanie brzmi nie o to, ile autonomii można dać modelowi, ale o to, gdzie autonomia tworzy wartość. Autonomia sprawdza się przy interpretacji niejasnych żądań, przeszukiwaniu dużych ilości wewnętrznych dokumentów, rozumowaniu na podstawie kontekstu i proponowaniu dalszych działań. Nie nadaje się natomiast do ignorowania zasad biznesowych, zarządzania transakcjami ani przechowywania danych dostępowych do bazy produkcyjnej.

Celem jest kontrolowana autonomia, która w systemach korporacyjnych oznacza połączenie probabilistycznego rozumowania AI z deterministyczną inżynierią. Naturalnie pojawia się następne pytanie: gdy agent musi uzyskać dostęp do SAP lub bazy danych, jak powinna wyglądać ta granica?