Agentic workflow w produkcji: kiedy gotowy control plane wystarczy, a kiedy musisz budować własny

PoC działał na laptopie przez trzy tygodnie. Parsował dokumenty, odpytywał RAG, zapisywał wyniki do CRM. Zespół był zadowolony. Potem przyszedł staging — i wszystko się rozsypało.

PoC działa, produkcja nie — dlaczego agentic workflow rozsypuje się poza laptopem

Nie chodzi o model. Model działa tak samo w produkcji jak na laptopie. Problem leży w infrastrukturze wokół modelu — i uderza w trzy konkretne ściany.

Trzy ściany, w które uderza każdy zespół

Stan i pamięć. Multi-agent workflow zakłada, że agenci pamiętają kontekst między krokami. W PoC trzymasz go w pamięci procesu. W produkcji masz wiele instancji, restarty, timeouty. Bez zewnętrznego store'u stanu każdy błąd zaczyna workflow od zera — i nie wiesz, na którym kroku się wysypał [1].

Prywatność danych. W polskich firmach przetwarzających dane klientów (RODO, umowy z kontrahentami, sektory regulowane jak fintech czy medtech) zarząd często stawia twarde wymaganie: dane nie opuszczają VPC. To nie jest negocjowalne. Większość SaaS-owych narzędzi do orkiestracji agentów domyślnie wysyła trace'y i logi do chmury dostawcy — co natychmiast dyskwalifikuje je z rozważań [1].

Halucynacje wywołań funkcji. Agent nie halucynuje tylko tekstu. Halucynuje też nazwy funkcji, parametry, kolejność kroków. W PoC widzisz to jako śmieszny błąd. W produkcji agent zapisuje błędne dane do CRM albo wywołuje endpoint, który nie istnieje — i nie masz żadnego mechanizmu, żeby to wychwycić przed skutkiem [1].

Ile sprintów kosztuje własna warstwa orkiestracji?

Zespół opisany w wątku na Reddit [1] policzył to wprost: zbudowanie własnej warstwy obejmującej logowanie, RBAC, wykonanie w Dockerze i izolację VPC to "massive waste of sprint capacity". Nie podali liczby sprintów, ale struktura problemu jest czytelna — to kilka tygodni pracy inżynierskiej, która nie dostarcza żadnej wartości biznesowej. Budujesz infrastrukturę, żeby móc budować to, co naprawdę miałeś budować.

Jeśli twój zespół liczy trzech inżynierów i macie backlog produktowy, własny control plane to koszt, który musisz świadomie wybrać — nie wpaść w niego przez przypadek.

Control plane dla agentów to nie buzzword — to Kubernetes dla twoich LLM-ów

Activant Capital w raporcie z Q4 2024 zdefiniował agent control plane jako scentralizowany system zarządzający polityką, obserwowalnością, routingiem i lifecycle agentów AI w całym przedsiębiorstwie [2]. Analogia do Kubernetes jest celna: tak jak Kubernetes zarządza kontenerami — planuje, restartuje, monitoruje — control plane robi to samo dla agentów.

Co musi robić control plane w produkcji

Cztery rzeczy są niezbędne:

• Obserwowalność — pełne trace'y każdego wywołania, z czasem, tokenami, wynikiem i błędem. Bez tego debugowanie to wróżenie z fusów.
• Governance — kto może uruchomić jakiego agenta, z jakimi danymi, z jakim budżetem tokenów. RBAC to minimum.
• Routing — który model obsługuje które zadanie, jak wygląda fallback gdy model jest niedostępny.
• Lifecycle — wersjonowanie agentów, rollback, staging vs produkcja.

Gdzie kończy się LangChain, a zaczyna problem

LangChain rozwiązuje orkiestrację — łańcuchy wywołań, narzędzia, pamięć w obrębie jednej sesji. Nie rozwiązuje governance'u, wielotenantowości ani audytu. Kiedy masz jednego agenta i jednego użytkownika, LangChain wystarcza. Kiedy masz dziesięciu agentów, pięć zespołów i wymóg audit logu — potrzebujesz warstwy powyżej [3].

Towards AI ujął to w 2025 roku wprost: przy skalowaniu od kilku do setek agentów control plane staje się koniecznością do egzekwowania guardrails, śledzenia wydajności i zarządzania kosztami [3]. Bez niego każdy zespół buduje własną logikę orkiestracji — i po roku masz pięć niekompatybilnych implementacji w jednej firmie.

Mapa gotowych rozwiązań: co kupujesz, a czego nie musisz budować

Trzy narzędzia, które realnie rozwiązują różne podzbiory problemu.

LangSmith + LangGraph: ekosystem dla zespołów już w LangChain

LangSmith dostarcza trace'y, eval harness i dashboard do monitorowania. LangGraph dodaje stateful workflows — agenci mogą wracać do poprzednich kroków, obsługiwać pętle, zarządzać stanem między wywołaniami. Razem tworzą spójny ekosystem, jeśli już piszesz w LangChain.

Cennik jest transparentny: plan Free obejmuje 2 000 uruchomień miesięcznie, plan Pro zaczyna się od 39 USD miesięcznie [1]. Dla polskiej sp. z o.o. z małym zespołem to około 160 PLN miesięcznie za warstwę obserwowalności — trudno to nazwać barierą wejścia.

Ograniczenie: LangSmith w wersji SaaS wysyła dane do infrastruktury LangChain. Jeśli masz wymóg VPC, musisz sięgnąć po self-hosted deployment — co znowu generuje koszt utrzymania.

Lyzr: lokalny deployment dla zespołów z restrykcjami prywatności

Lyzr wyróżnia się jedną rzeczą: lokalny deployment i VPC hosting działają out-of-the-box, bez konfigurowania własnego pipeline'u [1]. Dla zespołów, którym zarząd zablokował wysyłanie danych poza infrastrukturę firmy, to często jedyna droga do gotowego control plane bez miesięcy pracy inżynierskiej.

Wbudowany control plane Lyzr obejmuje trace logi i podstawowy governance. To nie jest narzędzie dla enterprise z setkami agentów — ale dla zespołu budującego pierwszy produkcyjny workflow z twardymi wymogami prywatności sprawdza się jako punkt startowy [1].

Orkes: gdy potrzebujesz audit logu klasy enterprise

Orkes Conductor to workflow engine pozycjonowany dla środowisk, gdzie audit log nie jest opcją, tylko wymogiem regulacyjnym [6]. Wbudowana obserwowalność i RBAC są częścią platformy, nie dodatkiem.

Kluczowa różnica w stosunku do LangGraph: Orkes traktuje workflow jako pierwszorzędny obiekt systemu — z wersjonowaniem, historią wykonań i możliwością replay'u konkretnego uruchomienia. Jeśli twój workflow dotyka danych finansowych albo medycznych i musisz udowodnić audytorowi, co agent zrobił 6 miesięcy temu, Orkes jest właściwym wyborem [6].

Prywatność danych i RBAC: jak nie wysyłać danych klientów poza VPC

Dla polskich firm działających w sektorach regulowanych (fintech pod nadzorem KNF, medtech z danymi pacjentów, firmy z umowami enterprise zabraniającymi przetwarzania danych przez podmioty trzecie) pytanie nie brzmi "czy self-hosted", tylko "jak szybko".

Self-hosted vs SaaS — matryca decyzyjna

Wybierz SaaS, jeśli: dane agenta nie są danymi osobowymi ani poufnymi, twój zespół nie ma zasobów do utrzymania własnej infrastruktury, i możesz zaakceptować, że dostawca widzi Twoje trace'y.

Wybierz self-hosted, jeśli: dane klientów przechodzą przez agenta, masz wymóg VPC w umowie z klientem lub regulatorem, albo przetwarzasz dane szczególnej kategorii w rozumieniu RODO.

Co sprawdzić w kontrakcie przed podpisaniem

Trzy punkty, które mają znaczenie:

Gdzie fizycznie trafiają trace'y i logi? Czy dostawca ma dostęp do treści wywołań, czy tylko do metadanych? Jaki jest czas retencji danych i czy możesz go skrócić? Brak odpowiedzi na te pytania w dokumentacji technicznej dostawcy to sygnał, że odpowiedź ci się nie spodoba.

Evaluation loop zanim agent dotknie CRM: jak łapać halucynacje funkcji przed produkcją

Halucynacje wywołań funkcji są trudniejsze do wychwycenia niż halucynacje tekstowe, bo nie widać ich w odpowiedzi — widać je w skutkach. Agent wywołuje funkcję update_contact z błędnym ID, CRM zapisuje zmianę, a ty dowiadujesz się o tym z reklamacji klienta.

LLM-as-judge i regression testy w LangSmith — trzy kroki

Krok 1: Zbierz złe przypadki z PoC. Każde wywołanie funkcji, które agent wykonał niepoprawnie podczas testów, staje się przypadkiem testowym. Nie potrzebujesz ich setek — 20–30 dobrze dobranych przypadków brzegowych daje więcej sygnału niż 200 losowych.

Krok 2: Skonfiguruj LLM-as-judge dla wywołań funkcji. W LangSmith definiujesz evaluator, który dla każdego uruchomienia sprawdza: czy agent wywołał właściwą funkcję, czy parametry są poprawne, czy kolejność kroków jest zgodna z oczekiwaną. Judge to osobny model — tańszy, szybszy — który ocenia output agenta według zdefiniowanych kryteriów.

Krok 3: Uruchom regression suite przed każdym deploymentem. Każda zmiana promptu, modelu lub narzędzia przechodzi przez ten sam zestaw przypadków testowych. Jeśli wynik spada poniżej progu akceptowalności, deployment się nie odbywa.

Kiedy manual review jest tańszy niż automatyczny eval

Automatyczny eval ma sens przy dużej liczbie uruchomień i powtarzalnych zadaniach. Jeśli twój agent wykonuje 50 unikalnych typów zadań dziennie i każde wymaga innego kryterium oceny — koszt konfiguracji evaluatorów może przekroczyć koszt tygodniowego manual review przez jedną osobę. Policz to zanim zainwestujesz w infrastrukturę ewaluacji.

Werdykt: kiedy gotowy control plane wystarczy, a kiedy własna orkiestracja jest nieunikniona

Pięć pytań, które rozstrzygają decyzję:

1. Czy dane klientów przechodzą przez agenta? Jeśli tak — potrzebujesz self-hosted control plane lub narzędzia z VPC out-of-the-box (Lyzr, self-hosted LangSmith).

1. Czy masz wymóg audit logu dla regulatora lub klienta enterprise? Jeśli tak — Orkes Conductor albo własna implementacja z pełnym logowaniem.

1. Czy twój zespół jest już w ekosystemie LangChain? Jeśli tak — LangSmith + LangGraph to najkrótszy krok do produkcji.

1. Czy planujesz więcej niż 10 agentów w ciągu 12 miesięcy? Jeśli tak — gotowy control plane z governance'em od początku jest tańszy niż refaktoryzacja za rok [3].

1. Czy masz zasoby inżynierskie do utrzymania własnej infrastruktury? Jeśli nie — każda godzina spędzona na budowaniu własnego control plane to godzina nie spędzona na produkcie.

Jeśli odpowiedziałeś "nie" na wszystkie pięć — gotowy SaaS (LangSmith Pro, 39 USD miesięcznie) wystarczy na start i przez większość drogi do skali. Jeśli choć jedno "tak" dotyczy prywatności lub audytu — self-hosted jest nieunikniony, i lepiej zaplanować ten koszt teraz niż migrować pod presją.

Następny krok jest konkretny: weź trzy najgorsze przypadki z PoC, skonfiguruj dla nich eval harness w LangSmith i uruchom je na staging przed kolejnym deploymentem. Dwa tygodnie, nie dwa miesiące.

Źródła

[1] Moving an agentic workflow to production without building a custom control plane from scratch — https://www.reddit.com/r/LangChain/comments/1tizdh4/moving_an_agentic_workflow_to_production_without/

[2] The Agent Control Plane — Activant Capital — https://activantcapital.com/research/the-agent-control-plane

[3] From Workflows to Governance: Why AI Agents Need a Control Plane and What It Means for Everyone — Towards AI — https://pub.towardsai.net/from-workflows-to-governance-why-ai-agents-need-a-control-plane-and-what-it-means-for-everyone-d9807052f11d

[4] From Prompts to Production: What Is an Agentic Workflow? — ML6 — https://www.ml6.eu/en/blog/from-prompts-to-production-what-is-an-agentic-workflow

[5] What Are Agentic Workflows? Design Patterns & When to Use Them — Neo4j — https://neo4j.com/blog/agentic-ai/what-are-agentic-workflows/

[6] Agentic AI Explained: Workflows vs Agents — Orkes — https://orkes.io/blog/agentic-ai-explained-agents-vs-workflows/

[7] A Practical Guide for Designing, Developing, and Deploying Agentic AI Systems — arXiv — https://arxiv.org/html/2512.08769v1