O czym jest ten film
- Autor prezentuje Open Engine — własny, otwarty framework, który pozwala agentom Claude Code, Codex, ChatGPT czy OpenClaw współpracować już dziś, bez czekania na integracje od dostawców.
- Diagnoza: używamy wielu narzędzi AI naraz, bo każde ma inne mocne strony (Claude — design interfejsów, OpenAI — inżynieria back-endu), a to człowiek ręcznie przenosi pracę między nimi.
- Punkt wyjścia to historia przyjaciółki: mama prowadząca agencję, pięć systemów AI i ona sama w roli „mostu” między nimi — plus klasyczny scenariusz: telefon z klientem, ustalanie zakresu produktu i nagła wizyta dziecka.
- Wniosek autora: to nie problem modeli ani umiejętności, lecz problem przekazywania pracy — kto dostaje zadanie dalej, z jakim kontekstem i jakim śladem tego, co zrobiono.
- Rozwiązanie: jedna kolejka zadań (Linear, Jira, własna tablica kanban), do której piszą zarówno ludzie, jak i agenci; ticket staje się wspólnym językiem i miejscem „rozmowy” między agentami.
- Kluczowe rozróżnienie: prompt prosi o odpowiedź, ticket zleca rezultat — wraz z tłem, właścicielem, granicami uprawnień agenta i definicją gotowości.
- Mechanika pętli: agent rezerwuje zadanie, przechodzi przez statusy („do zrobienia” → „agent pracuje” → „gotowe”), zostawia paragon wykonania, a przy wątpliwościach zadaje jedno precyzyjne pytanie zamiast zgadywać.
- Na demo widać delegowanie między agentami różnych dostawców: agent May (Codex) zleca przez ticket zadanie agentowi Leo (Claude) — bez żadnej integracji po stronie producentów.
- Open Engine nie konkuruje z OpenClaw ani Hermes i nie zastępuje człowieka — ma tylko sprawić, że to nie człowiek będzie dalej pełnił rolę „korytarza” między narzędziami.
- System działa i w domu (przeprowadzka, odbiór dzieci, kolory farb), i w zespole; autor udostępnia społeczności przewodnik złożony z pięciu elementów.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Wąskim gardłem AI nie są modele, tylko przejścia pracy
Na czym polega: Autor diagnozuje, że prawdziwy ból leży na granicach: czy praca może opuścić Claude i trafić do Codexa, czy agent kolegi podjmie zadanie od mojego agenta, czy eskalacja do człowieka nie zgubi historii. To problem „kto dostaje to dalej i jak przekazujemy”, a nie problem modelu.
Jak stosować: Zanim kupisz kolejne narzędzie albo zaczniesz czekać na nowszy model, policz, ile czasu tracisz na przenoszenie pracy: kopiowanie, streszczanie kontekstu, sprawdzanie, co się stało. Optymalizuj te przejścia, nie pojedyncze sesje z AI.
Na co uważać: Łatwo pomylić problem przejęć z brakiem biegłości. Jeśli ktoś zna narzędzia, a mimo to tonie w koordynacji, winna jest architektura przepływu — dokształcanie się nic tu nie da.
2.Postaw pracę w kolejce, którą czytają ludzie i agenci
Na czym polega: Wspólna kolejka zadań (Linear, Jira, własny kanban) staje się jedynym miejscem, w którym „mieszka” praca. Warunek jest jeden: agent musi umieć do niej pisać, a ty — z niej czytać.
Jak stosować: Wybierz jedno narzędzie i zacznij od małego testu kontrolnego: stwórz prosty ticket, przypisz go człowiekowi lub agentowi i sprawdź, czy da się go domknąć. Dopiero potem włączaj realne obciążenie.
Na co uważać: Kolejka musi być nadrzędnym rejestrem stanu. Jeśli równolegle zostaje Slack albo czat jako miejsce decyzji, stan pracy rozjedzie się w pół dnia.
3.Ticket zamiast promptu
Na czym polega: Prompt prosi o odpowiedź; ticket zleca rezultat do wykonania. Ticket może obsłużyć kilku agentów, którzy się nie znają i nie są zintegrowani — to właśnie zgłoszenie staje się miejscem, w którym „rozmawiają”.
Jak stosować: Za każdym razem, gdy chcesz, żeby coś naprawdę zeszło z twojego biurka, twórz ticket zamiast wiadomości na czacie: dołącz materiały źródłowe, decyzje i ograniczenia.
Na co uważać: Czat nadaje się do myślenia na głos, ale nie do zarządzania stanem. Nie traktuj historii rozmów jak rejestru projektu.
4.Kompletna struktura zlecenia dla agenta
Na czym polega: Dobry ticket zawiera: co ma się wydarzyć, kto jest właścicielem, jakie tło ma znaczenie, co agent może zrobić samodzielnie, gdzie ma się zatrzymać i co ma pokazać po skończeniu (definicja gotowości).
Jak stosować: Traktuj tę listę jak checklistę przy każdym zleceniu. To różnica między „poproszeniem AI o pomoc” a „oddaniem komuś zadania, które kolejna osoba albo agent potrafi podjąć”.
Na co uważać: Przesada w drugą stronę też szkodzi — dołączaj tylko kontekst niezbędny do działania, bo zalewka źródeł spowalnia agenta i zaciemnia, czego po nim chcesz.
5.Rezerwacja zadania, statusy i paragon wykonania
Na czym polega: Przed rozpoczęciem pracy agent rezerwuje i blokuje ticket, przechodzi ze statusu „do zrobienia” do „agent pracuje”, a na końcu zostawia paragon — zapis tego, co dokładnie zrobił, a czego nie.
Jak stosować: Wprowadź stały zestaw statusów i wymagaj paragonu. Dzięki temu nie pytasz „zrobiłeś to?”, tylko czytasz potwierdzenie — i widać, kiedy agent jest online, a kiedy zadanie czeka.
Na co uważać: Paragon to nie formalność. Jeśli agent go nie zostawia, pętla się psuje i wraca ręczne sprawdzanie — dokładnie to, przed czym chcesz uciec.
6.Przy wątpliwościach pytaj, zamiast zgadywać
Na czym polega: Gdy agent trafia na niejednoznaczność, nie zgaduje: przechodzi do statusu „potrzebne informacje” i zadaje jedno dokładne pytanie o to, co blokuje. Cłowiek odpowiada w tym samym zgłoszeniu, agent wznawia pracę, a ślad audytu zostaje w jednym miejscu.
Jak stosować: W instrukcjach dla agentów jednoznacznie zabroń zgadywania i wskaż status eskalacji wraz z wymogiem pojedynczego, konkretnego pytania.
Na co uważać: Pytania muszą być precyzyjne. Seria ogólnych „wyjaśnij więcej” zamienia agenta w kolejne źródło korespondencji do ogarnięcia.
7.Wynik to nie to samo co praca
Na czym polega: Wynik to to, co AI zwraca tu i teraz. Praca to coś, co ktoś może sprawdzić, zaakceptować i na tym budować. Piękna notatka w prywatnym czacie, o której nikt nie wie, to tylko szkic w pustym pokoju.
Jak stosować: Wymagaj, by produkty agentów lądowały w miejscu widocznym dla zespołu — w pliku, tickecie, wspólnym rejestrze — a nie w oknie rozmowy, które zaraz zniknie.
Na co uważać: Jeśli weryfikacja pracy agenta wymaga scrollowania transkryptów, znów to ty pracujesz dla AI, a nie odwrotnie.
8.Samodzielny agent to za mało
Na czym polega: Projekty takie jak OpenClaw dają agenta, który działa, a nie tylko czatu; Hermes — agenta, który uczy się powtarzalnej pracy zamiast zaczynać od zera. To realne potrzeby, ale bardzo zdolny prywatny agent i tak może stać się kolejną skrzynką odbiorczą do pilnowania.
Jak stosować: Nie porzucaj tych narzędzi — podłącz je jako umiejętność do wspólnej kolejki zadań. Autonomiczny agent potrzebuje tego samego co członek zespołu: właściciela, statusów, paragonów i przeglądu.
Na co uważać: Pamięć takiego agenta bywa zawodna przy dłuższym horyzoncie i wielu rolach życiowych — nie opieraj na niej rejestru prawdy o projekcie.
9.Przepisz polecenia z trybu promptu na tryb pracy
Na czym polega: „Napisz mi maila” to tryb promptu. Tryb pracy to pełne zlecenie: transkrypt rozmowy, podjęta decyzja, obietnica (bez przesady), ograniczenia kalendarzowe, zaznaczenie co wymaga mojej oceny, notatki do późniejszego przeglądu. Autor pokazuje trzy wersje: mail follow-up, zgłoszenie supportowe, zmiana harmonogramu.
Jak stosować: Przy każdym zleceniu dołącz źródła, reguły eskalacji i punkt zatrzymania. Model może zostać ten sam — jakość wyniku zmienia jakość zlecenia. Komunikaty wychodzące na zewnątrz mogą jeszcze przejść przegląd przez drugiego agenta, np. pod kątem języka marki.
Na co uważać: Tryb pracy nie wykreśla ludzi z pętli. Wiadomości do szkoły czy klienta czekają na akceptację, zanim cokolwiek opuści system.
10.Nie czekaj na integracje ani na „jedno narzędzie dla wszystkich”
Na czym polega: Dostawcy nie zintegrują się szybko, a dwie osoby w zespole potrafią używać sześciu różnych AI. Nie zmuszaj nikogo do zmiany — daj ludziom kolejkę, w której ich agenci mogą się dogadać.
Jak stosować: Zacznij od jednego przepływu (dom albo jeden proces w pracy) i rozszerzaj. Test użyteczności jest prosty: czy praca wychodzi z czatu, niesie źródła, respektuje limity i wraca z paragonem?
Na co uważać: Nie obiecuj sobie, że kolejka „poprowadzi firmę”. Obietnica jest skromniejsza: praca przepływa między narzędziami, a ty przestajesz być posłańcem.
Redakcyjne tłumaczenie
Obietnica: spraw, żeby twoje AI zaczęły ze sobą współpracować
Po tym materiale będziesz wiedzieć, jak zmusić Claude, Codex, ChatGPT oraz OpenClaw czy Hermes do wspólnej pracy — bez czekania, aż którykolwiek z dostawców zintegruje się z resztą. Pokażę demonstracje, opowiem, co zbudowałem i dlaczego, dorzucę historie z życia i powiem wprost: używam tego w domu i w pracy. Dostaniecie pełną wycieczkę po systemie, a na końcu będziecie mogli zbudować go sami.
Nazwałem to Open Engine i obietnica jest prosta: potrzebujemy otwartego „silnika”, który porządkuje nasze życie, bo mamy za dużo AI, a te AI źle się ze sobą dogadują. Chodzi o to, żeby agenci przestali być osobnymi subskrypcjami i osobnymi produktami, a zaczęli tworzyć system, którym można zarządzać. A jeśli pytasz, czy to coś dla zespołów — tak, używam tego ze swoim zespołem. Działa dla ludzi i ich agentów i pozwala wszystkim współpracować płynnie. Budowałem działającą wersję, która pomaga mi ogarniać publikacje i porządkować życie — niedawno także przeprowadzkę. Wypuszczam to w świat, bo bardzo mi pomogła i zdjęła spory ciężar z mojej żony.
(Informacja dodatkowa: Claude Code i Codex to agenci programistyczni — odpowiednio Anthropic i OpenAI — pracujący z poziomu terminala; OpenClaw i Hermes to niezależne projekty asystentów-agentów działających po stronie użytkownika.)
Historia, która tłumaczy cały problem
Niech będzie konkretnie: moja przyjaciółka. Ma małe dziecko, prowadzi agencję, korzysta z Claude Code, ma zbudowane pętle i automatyzacje, a OpenClaw przyglądała się poważnie, bo chce agentów wykonujących prawdziwą pracę. To nie ktoś, kto dopiero testuje AI — tych narzędzi już używa i rozmawia o nich ze mną. Jej wyzwanie: co najmniej pięć systemów AI, z których każdy pomaga w innym kawałku dnia, a ona sama staje się osobą, która przenosi pracę między nimi. To spory ciężar do dźwigania. Każdy, kto tych systemów używa, wie, że ta robota jest realna, bo narzędzi nie da się po prostu wymieniać jak zamienne. Claude Code i Codex nie robią tych samych rzeczy, choć celują w tę samą grupę użytkowników. Claude po prostu jest lepszy w projektowaniu front-endu — ma intuicję. OpenAI jest w tym słabsze, ale ma bardzo mocną reputację w inżynierii back-endu. Ludzie, którzy to rozumieją, żonglują kilkoma narzędziami naraz; to boli i musimy sami zakładać sobie „uprząż” — czyli koordynować siebie w poprzek wszystkich tych aplikacji.
Pytanie brzmi: jak praca może opuścić jedno narzędzie, trafić do właściwego człowieka albo właściwego agenta, zabrać ze sobą materiały źródłowe i pokazać, co się wydarzyło — tak, żeby nikt nie musiał czytać ogromnego transkryptu rozmowy? Jeśli to twoja sytuacja, mam dobrą wiadomość. Składam właśnie narzędzie, które to rozwiązuje — i tym właśnie jest Open Engine: system pozwalający każdemu AI w twoim otoczeniu koordynować się płynnie i przenosić stan, kontekst i szczegóły w obie strony, bez twojego udziału.
Trzy rzeczy naraz: klient, produkt, dziecko
Teraz konkretny scenariusz. Ona musi pogodzić rozmowę z klientem, ustalanie zakresu produktu i wizytę u lekarza, która właśnie wkradła się do kalendarza dziecka. Za ustalenia produktowe bierze się zwykle Codex; Claude Code przemeblowuje jej kalendarz; sprawę wizyty załatwia mailowo, choć marzy jej się jakaś automatyzacja. Nie ma prostego sposobu, żeby ogarnąć to wszystko w jednym miejscu — chyba że gdzieś po drodze pójść na kompromis w kwestii modeli. A jej pytanie brzmi: czy można żyć bez kompromisów? Czy można brać ulubiony model do konkretnego problemu i nie płacić za to utratą panowania nad całością? I idąc dalej: czy da się przy tym nie polegać na nieprzewidywalnej pamięci agenta?
Bo to jedna z bolączek OpenClaw — instalowałem, używałem: przy kilku różnych rolach życiowych i dłuższym horyzoncie bywa po prostu nieprecyzyjny. Wizyta dziecka wraca po paru miesiącach, w tym samym momencie pojawia się pytanie od zespołu agencji, a twój asystent nie potrafi rozmawiać z zespołem w naturalny sposób, chyba że dasz mu uprawnienia na Slacku. A gdy mu dasz — to i tak nie rozmawia z agentami zespołu. Do tego trzeba sprawę jakoś przemycić do poczty i dochodzi cała warstwa pamięci. Tak wyglądają prawdziwe rozmowy, które słyszę. Słyszycie, ile w tym „jeśli”, „ale” i kopiuj-wklej? To mnóstwo dorywczej pracy wykonywanej obok właściwych zadań. Ludzie produktywni dzięki AI po prostu ją dźwigają, bo zysk jest tak duży.
Rok 2026: brakuje przepływu, nie możliwości
To, co widzimy w 2026 roku, to AI pomagające w poszczególnych kawałkach. Po premierze OpenClaw dochodzi trochę koordynacji, ale najtrudniejsza część wciąż czeka na rozwiązanie: płynne przemieszczanie się pracy między elementami wraz z pełnym stanem i wszystkimi szczegółami.
Agenci to zarządcy pętli — a człowiek robi za korytarz
W środowym odcinku mówiłem, że agenci to w istocie zarządcy pętli. Użyteczny agent to zapamiętany przepływ, który można uruchomić ponownie; który zauważa, co się zmieniło; który zatrzymuje się we właściwym miejscu i wciąga ciebie, gdy naprawdę potrzebna jest decyzja. To absolutnie właściwy punkt wyjścia. Ale jeśli każda pętla siedzi we własnym pokoju, człowiek staje się korytarzem. Pętla badawcza kończy pracę, a pętla pisarska nie wie, co się zmieniło. Support dostrzega wzorzec, ale pętla produktu nie dostaje oryginalnych wiadomości — chyba że sam je tam włożysz. Agent programistyczny naprawia plik, a kolega odpowiedzialny za przegląd widzi tylko mgliste streszczenie — chyba że wyślesz mu stos wiadomości. Plan dnia się zmienia, a pętla pracy nie wie, że popołudnie właśnie się zawaliło.
Wracając do naszej historii — właśnie dlatego zbudowałem Open Engine. To problem, nad którym pracuję od dawna.
Od pamięci do przepływu
Jeśli pamiętasz, Open Brain dotyczyło pamięci. Kilka miesięcy temu argumentowałem, że każde twoje AI zaczyna od zera, dopóki nie dasz mu prawdziwego systemu pamięci — takiego, który kontrolujesz i który żyje między twoimi agentami. Twój kontekst nie powinien być uwięziony w historii czatu jednej firmy. Open Engine to kolejny duży element układanki: skoro AI potrafi już pamiętać, to jak właściwie przemieszcza się twoja praca? Żebyśmy nie tracili czasu na koordynowanie i na tę niewidzialną robotę.
Sama podstawa jest celowo banalnie prosta — chcę, żeby to było łatwe do zrobienia. Wystarczy umieścić pracę w kolejce, którą mogą czytać zarówno ludzie, jak i agenci.
Kolejka i ticket zamiast czatu
Co to jest kolejka? Może to być zwykły Jira. Może to być tablica kanban, którą sam zakodowałeś. Może to być kolejka ticketów w Linear — tego używam i to lubię. Liczy się jedno: skoro agent umie do niej pisać, a ty umiesz z niej czytać, to wystarczy. W takiej kolejce wystarczy zgłoszenie, które mówi: to ma się wydarzyć; to jest właściciel; to jest tło, które ma znaczenie; to agent może zrobić sam, a tu ma się zatrzymać; i to ma pokazać po zakończeniu.
Brzmi bardzo prosto — i ta prostota jest celem. Dobry ticket to różnica między poproszeniem AI o pomoc a przekazaniem mu zadania, które następny człowiek albo następny agent potrafi zrozumieć — tak, żeby praca realnie zeszła z twojego biurka i została zrobiona. W 2025 roku dużo mówiło się o promptowaniu: prompt prosi o jakąś odpowiedź. Ticket zleca rezultat do wykonania — i może obsłużyć wielu agentów, nawet jeśli się nie znają i nie są w żaden sposób zintegrowane. Ticket staje się miejscem, w którym rozmawiają.
To rozróżnienie jest kluczowe, bo im lepsi będą agenci, tym bardziej potrzebujemy lepszego zarządzania stanem ich pracy. Okno czatu to fatalny sposób na pilnowanie stanu — i przykro mi, ale Slack też. Agent musi móc zmieniać pliki, tworzyć zadania, przesuwać statusy, pisać szkice — i to w miejscu, w którym widać, co się stało. Kiedy z żoną wybieraliśmy kolory farb do domu, muszę widzieć, jaką farbę wybraliśmy — inaczej wszystko się pomiesza, decyzja zostaje w czyjejś głowie i znowu wykonujemy tę pracę umysłową. Gdy moja przyjaciółka sprawdza, czy ma w lejku pięć, czy sześć firm, musi móc przejrzeć ten lejek z dowolnego miejsca: co zrobił z nim jej zespół, co zrobiły agenty zespołu, co zrobiły jej własne agenty i jaki jest następny krok. Tego nie da się osiągnąć, odpytując czaty.
(Informacja dodatkowa: Linear to popularne narzędzie do zarządzania projektami oparte na kolejkach zadań i tablicach; ma bezpłatny plan.)
Pięć elementów, które składają się na całość
Przewodnik, który przygotowałem, jest bardzo konkretny. Ma pięć elementów, które razem tworzą kompletny ekosystem — a jeśli któryś pominiesz, całość się nie spina. Pierwszy to kolejka w Linear. To sensowny wybór: Linear ma hojny darmowy plan i dobrze współpracuje ze wszystkimi systemami AI — dlatego na niego się zdecydowałem. Ale nie musisz: Jira albo własny system też się nadają.
Dalej jest kwestia: jak powiedzieć swojemu AI „tak używa się tego narzędzia”. Bo AI trzeba pokazać protokół pracy z systemem zgłoszeń. Dlatego dochodzą cztery kolejne elementy: w praktyce napisałem umiejętności (skills), które tłumaczą AI, jak z tego korzystać. Jest umiejętność konfiguracji, jest umiejętność statusów, jest umiejętność prowadzenia kolejki przez AI i jest test kontrolny. I tak, możesz wycelować swoim OpenClaw albo Hermesem w ten system i używać go jako kolejnej umiejętności.
Nie jestem przeciw OpenClaw. Po prostu autonomia to za mało
To nie jest wystąpek przeciw OpenClaw. Podziwiam to, co zrobił Peter, podziwiam Hermes. Możesz używać tych narzędzi do woli i nic cię tu nie ogranicza. OpenClaw odpowiada na prawdziwą potrzebę: chcemy agentów, którzy działają, a nie kolejnego okna czatu. Hermes i podobne projekty odpowiadają na następną: agenci mają się ulepszać w powtarzalnej pracy i się uczyć, zamiast za każdym razem zaczynać od zera. To realne potrzeby. Ale sama autonomia nie wystarczy. Bardzo zdolny prywatny agent wciąż może stać się kolejną skrzynką odbiorczą albo kolejną listą zadań, którą musisz ogarniać.
Wąskie gardło, na którym mi zależy, to granica między agentami — bo właśnie tam to czuję. Czy praca może opuścić Claude i trafić do Codexa? Czy agent kolegi może podjąć zadanie utworzone przez mojego agenta? Czy pętla supportu może eskalować do osoby z uprawnieniami, nie gubiąc ani wiadomości, ani historii klienta, ani powodu, dla którego agent przerwał pracę? To nie problem modelu. To nie problem agenta. To problem granic: kto dostaje to dalej i jak przekazujemy.
U mojej przyjaciółki ból jest większy niż kwestia narzędzi czy biegłości. Narzędziami włada — to nie problem. Ma ich pod dostatkiem — to też nie problem. Problemem jest przekazywanie: informacje nie płyną między nią, jej agentami, agentami zespołu i samym zespołem gładko i bez kogoś, kto musi tym sterować. Zadziwia mnie, ile obietnic AI utyka właśnie w tych punktach przekazania. Jeśli spojrzeć na AI jak na technologię, która przemieszcza wąskie gardła, to obecnie wlewamy mnóstwo generatywnej energii w maleńkie gardło przekazań. I to właśnie Open Engine ma rozwalić na czynniki pierwsze.
Ten sam kształt problemu w domu i w pracy
Działa to jednocześnie dla gospodarstw domowych i zespołów. Zmiana godziny odbioru dziecka ze szkoły to nie lejek sprzedażowy, ale kształt tego bólu pod spodem jest znajomy: coś się zmieniło; kilka innych rzeczy od tego zależy; część może załatwić agent; część wymaga człowieka. Open Engine nie zastępuje człowieka. Robi tylko jedno: sprawia, że człowiek przestaje być jedynym, który wszystko przekazuje dalej. To ogromna ulga. W naszej rodzinie zdjęło wielki ciężar; w zespole — również, bo nasi agenci potrafią teraz współpracować płynnie. Nie śledzimy wiadomości agentów na Slacku (choć możemy przez Slacka agentów wywoływać) — mamy jasny rejestr stanu pracy i możemy wpinać do zadań także agenty innych osób. To bardzo skuteczny sposób współpracy, w którym nie gubimy żadnego szczegółu.
Wynik to jeszcze nie praca
Pomyśl: jeśli agent napisze piękną notatkę w prywatnym czacie i nikt nie wie, skąd się wzięła, to jest tylko szkic w pustym pokoju. Wynik to to, co AI zwraca tu i teraz. Praca to coś, co ktoś może sprawdzić, zaakceptować i na tym budować. Open Engine służy przejściu od wyniku do pracy — bez robienia z człowieka żywej ścieżki kopiuj-wklej.
Demonstracja: podstawowa pętla
Na ekranie widzicie podstawową pętlę Open Engine. Prośba staje się czytelnym zadaniem w Linear, przypisanym do właściwego operatora. Codex się budzi, sprawdza przypisaną sobie kolejkę i znajduje jedno kwalifikujące się zgłoszenie z instrukcjami dla agenta. Zanim zabierze się do pracy, rezerwuje i blokuje zadanie, przenosi je do statusu „agent pracuje” i zostawia paragon z potwierdzeniem przejęcia. Dopiero potem lokalnie rusza wykonanie. Linear koordynuje zespół, Codex robi robotę. Człowiek może stworzyć zadanie dla agenta, a agent — zadanie dla innego agenta. Zadanie zawiera oczekiwany efekt, źródła i definicję gotowości. Gdy agent startuje, status zmienia się z „do zrobienia przez agenta” na „agent pracuje”; gdy kończy, przesuwa zgłoszenie we właściwe miejsce.
Ten paragon to nie ozdoba. On ci mówi, co zostało zrobione. Nie chcę pytać agenta: „zrobiłeś to?”. Chcę wiedzieć, że to zrobione. Nie chcę kopiować i nie chcę już koordynować swoich modeli — mam tego dość. W ten sposób cały kontekst i wszystkie artefakty trafiają do systemu, w którym agenci mogą przejrzyście brać się do pracy. Ludzie nie gubią się w tym, co jest w toku. Agenci też nie. Robi się po prostu prosto.
Demonstracja: delegowanie, czyli agent zleca agentowi
Spójrzmy na delegowanie — kluczową część tego wzorca. Da się delegować agentom? Jak to wygląda? Załóżmy, że Maya prosi Codexa o przekazanie specyfikacji metryki agentowi Leo. Agentem Leo jest Claude. Codex sprawdza, że agent Leo jest online, i pisze samowystarczalny ticket w Linear z kontekstem potrzebnym do działania. Mamy więc agentów dwóch osób, u dwóch różnych dostawców, koordynujących się w Linear. Zgłoszenie zostaje przypisane do agenta Leo, zostaje w statusie „do zrobienia przez agenta” i dostaje etykietę instrukcji. Agent Leo może je podjąć we własnym rytmie sprawdzania kolejki — a przekazanie jest widoczne i ma wyraźne granice, nie leży zakopane w czacie. Bo nie chodzi o to, że agent „zrobił sztuczkę”. Chodzi o to, że widzisz, jak praca przepływa przez zespół.
Test kontrolny
Test w tej umiejętności jest celowo czysty i szybki. Tworzysz zgłoszenie „przywitaj się z kolejki”, przypisujesz je człowiekowi albo agentowi, nadajesz etykietę instrukcji i upewniasz się, że da się je domknąć. Nie chodzi o wręczenie agentowi stosu pracy — tylko o czysty sprawdzian, że pętla współdziałania działa. A pełna pętla jest naprawdę prosta: prośba, zgłoszenie, rezerwacja, wykonana praca, dowód — paragon — i następna pozycja.
Co agent robi z wątpliwością
Agent Leo przejmuje zadanie i przenosi je do „agent pracuje”, więc wszyscy wiedzą, że ktoś nad tym siedzi. Jeśli trafi na niejednoznaczność, nie zgaduje: przechodzi do statusu „potrzebne informacje” i zadaje dokładnie jedno pytanie o to, co blokuje. Maya — człowiek — może odpowiedzieć w tym samym zgłoszeniu, agent wznawia pracę, a ślad audytu zostaje w jednym miejscu. Po skończeniu agent Leo zostawia status „agent skończył” i przechodzi do następnego zadania.
Tego można użyć do wszystkiego. Do wyboru kolorów farb w domu tak samo łatwo jak do zaplanowania przeglądu lejka sprzedażowego, kiedy w biegu ogarniasz wizytę dziecka u lekarza. Sedno: kolejka sama ogarnia cały stres przekazań, żebyś to nie ty musiał się z nim mierzyć.
Od trybu promptu do trybu pracy
Open Engine wymaga od nas przejścia z trybu promptu do żądania prawdziwej pracy. Tryb promptu: „napisz mi maila z follow-upem”. Tryb pracy: „oto transkrypt rozmowy z klientem; oto decyzja, którą podjęliśmy; oto obietnica — nie przesadzaj; oto ograniczenia kalendarzowe. Napisz szkic follow-upa, zaznacz, co wymaga mojej oceny, i zostaw notatki, do których wrócę”. To jest pełne zlecenie pracy. I możesz je oddać innemu agentowi do przeglądu, jeśli chcesz drugiej opinii — co wielu ludzi robi zwłaszcza przy komunikacji z klientami. Możesz mieć wręcz całego agenta, który pilnuje wyłącznie języka marki.
Kolejne przykłady. Tryb promptu: „podsumuj to zgłoszenie supportowe”. Tryb pracy: „sklasyfikuj zgłoszenie, dołącz historię klienta, sprawdź, czy to znany problem, utwórz zadanie produktowe tylko wtedy, gdy spełniona jest moja reguła eskalacji, i pokaż dokładnie, gdzie przerwałeś i dlaczego”. Albo: tryb promptu — „pomóż mi zmienić plan dnia”. Tryb pracy — „godzina odbioru dzieci się zmieniła. Sprawdź, na co to wpływa, przygotuj dwa szkice wiadomości do szkoły i czekaj na moją akceptację, zanim cokolwiek wyjdzie z systemu”.
Model może być w obu przypadkach ten sam. Ale zlecenie jest dużo wyraźniejsze, a przekazanie dalej — kilku agentom albo człowiekowi, według twojego uznania — staje się banalnie proste.
Przestań być klejem
Musimy przestać zakładać, że to my jesteśmy spoiwem między wszystkimi systemami AI, przy których pracujemy. Inaczej to AI nas promptuje i to my pracujemy dla AI, a nie odwrotnie. Chcemy, żeby praca przepływała przez narzędzia, których już używamy. Bo zespoły nie mieszkają w jednym narzędziu AI. Nie znam nikogo zainteresowanego AI, kto używa wyłącznie jednego. A już na pewno dwie osoby to nie jedno narzędzie — to dwa, trzy, pięć. Często widzę sześć różnych AI na dwie osoby. Nie przekonasz nikogo, żeby to zmienił. Po prostu daj ludziom kolejkę, w której ich AI mogą ze sobą rozmawiać.
Czego Open Engine nie obiecuje
Nie składam wielkiej obietnicy. Nie mówię, że Open Engine poprowadzi twoją firmę — nie chcę tego mówić. Nie powiem też, że poprowadzi twój dom. Powiem co innego: następne użyteczne AI to nie kolejny prywatny asystent. To kolejka, w której twoi agenci mogą razem pracować i posuwać sprawy do przodu. To ma znaczenie w każdym zespole — a wszyscy coraz częściej zarządzamy zespołami agentów, bo zespoły potrzebują właścicieli, statusów, paragonów i przeglądu. Jeśli się tym nie zajmiesz, coś ginie. Coś wypada przez szpary. I są tego konsekwencje — domowe i zawodowe.
Z korytarza robi się software
Na początku mówiłem, że jesteśmy korytarzem między agentami. Open Engine to narzędzie, które zamienia ten korytarz w software — przejrzysty, gładki, prosty — żeby ludzie przestali dźwigać cały ten ładunek. Nie naszym zadaniem jest być niewidzialną siłą roboczą dla naszych AI. To zadanie dobrych frameworków i systemów: pozwolić pracy przejść od miejsca, w którym się zaczęła, do miejsca, w którym jest potrzebna — z kontekstem wystarczającym, by następna pętla mogła zrobić coś użytecznego.
Test dla Open Engine jest prosty. Czy praca umie wyjść z twojego czatu? Czy zabiera ze sobą źródła, których wymaga? Czy respektuje granice? Czy wraca i mówi: to zrobiłem, tego nie zrobiłem, oto paragon? Jeśli odpowiedź brzmi „tak” — choćby w małym zakresie — cała rozmowa o agentach zmienia ci się w głowie. Przestajesz pytać wyłącznie, co potrafi jedno AI w jednej sesji. Zaczynasz pytać, jaką pracę udźwignie cały twój system — bez ciebie w roli posłańca.
Tak brzmi obietnica Open Engine. Nie agenci zastępujący nasz osąd. Nie jeden agent, który rządzi wszystkimi. Po prostu cały nasz AI-owy bałagan zszyty porządnym frameworkiem — tak, by agenci doprowadzali pracę aż do punktu, w którym potrzebny jest osąd człowieka, i nie zawracali nam głowy przekazaniami po drodze. O taką autonomię mi chodzi. Z tym żyję. I to wam dziś pokazuję.
Przewodnik i co dalej
Jeśli chcesz — pełny przewodnik jest już dostępny. Społeczność na Substack dostaje go pierwsza; mamy też aktywny Slack, na którym ludzie nad tym budują. Znajdziesz tam dokładnie tę demonstrację, którą widzieliście, i kompletny przewodnik, który możesz wręczyć swojemu AI i wystartować jeszcze dziś.
Jeśli przekazania pracy boli cię tak jak mnie i jak wielu ludzi, których znam — to jest dla ciebie. Ułatw sobie życie. Pozbądź się bólu głowy. Przestań kopiować i wklejać — po prostu spraw, żeby to zniknęło. Mój osobisty cel to mniej zmarnowanych ludzkich godzin: chcę, żebyśmy spędzali mniej czasu na niepotrzebnej koordynacji agentów. To będzie mój sukces.
A jeśli patrzysz na to i myślisz: „o mój Boże, to jest dla mnie” — napisz w komentarzach, do czego tego użyjesz. Które systemy AI będziesz łączyć. Czy pracujesz z agentami, z zespołem, czy z partnerem lub partnerką. Jedno: z waszych uwag będziemy ulepszać Open Engine. Dwa: chcę wiedzieć, jak wielki ból tu leczymy. Interesuje mnie AI, który zabiera nam ból — a ten ból pojawił się i narasta, odkąd agenci stali się zdolniejsi. W erze OpenClaw, w erze Codexa, w erze Claude — potrzebujemy czegoś takiego jak Open Engine. Mam nadzieję, że obejrzenie tego demo było dla was frajdą.