Konfiguracja to część, której nikt nie chce przeklikiwać
Nowy workspace oznacza tworzenie agentów, pisanie ich instrukcji, podłączanie narzędzi i ustawianie harmonogramów. Raz to nie problem. Przy dziesięciu projektach albo przy każdym kliencie agencji to popołudnie spędzone nad formularzami.
Dlatego Waggle można obsługiwać przez asystenta, którego już masz. Są dwa wejścia. hachi to CLI zaprojektowane dla agentów: za każdym razem JSON na stdout, typowane błędy, stabilne kody wyjścia, --dry-run i bramka --yes przy wszystkim, co destrukcyjne. Drugie wejście to endpoint MCP, który udostępnia te same narzędzia dowolnemu klientowi MCP.
Oba działają dziś. CLI instaluje się poleceniem brew install hachiflow/tap/hachi, a potem hachi mcp serve uruchamia lokalny serwer stdio. Można też pominąć instalację i użyć hostowanego endpointu https://api.hachiflow.com/mcp. Narzędzia są w obu przypadkach te same.
Jak sami tego użyliśmy
Podłączyliśmy asystenta AI do kodowania do hostowanego endpointu i opisaliśmy około dziesięciu projektów w jednym pliku: dla każdego workspace z agentami, konektorami i harmonogramami. Poprosiliśmy go o uruchomienie hachi_plan, przeczytanie różnic, a potem o uruchomienie hachi_apply.
Po jednym wywołaniu było gotowych dziesięć workspace'ów z agentami, konektorami i harmonogramami. Nikt nie przeklikiwał dziesięciu kreatorów.
Zostały dane uwierzytelniające dla każdego workspace'a, czyli to, co powinno zostać po stronie człowieka. Więcej o tym niżej.
Agencja, dwóch klientów, jeden plik
Załóżmy, że agencja przyjmuje dwóch klientów i chce dla każdego agenta skrzynki odbiorczej i agenta raportującego. Najpierw dodaje się hostowany endpoint do Claude Code, potem loguje w przeglądarce zwykłym loginem hachiflow. To OAuth przez WorkOS AuthKit, więc nie trzeba wklejać żadnego klucza API.
Następnie opisuje się pracę. Poniższa specyfikacja pokazuje cały kształt: dwa workspace'y, po dwóch agentów w każdym i harmonogram w dni robocze dla każdego agenta skrzynki. Każdy agent ma nazwę od swojego klienta, dzięki czemu łatwo je odróżnić na liście.
Najpierw uruchamia się plan. Niczego nie zmienia i wypisuje, co zrobiłby apply. Potem apply. Apply jest deklaratywne i zbieżne: uruchomione ponownie zgłasza, że nie ma nic do zrobienia, a zmiana jednej instrukcji daje jedną aktualizację.
Cały przykład. W pliku nie ma żadnych sekretów: logowania do konektorów i dane modelu dla każdego workspace'a wracają jako kroki dla człowieka do dokończenia.
Asystent dostaje konfigurację, człowiek sekrety
Apply nie udaje, że potrafi wszystko. Zwraca listę kroków dla człowieka, czyli rzeczy, które może zrobić tylko osoba: dane uwierzytelniające konektorów, dane modelu dla każdego workspace'a i zaproszenia. Po ich wykonaniu kolejny plan powinien zawierać już tylko operacje bez zmian.
Sekrety nigdy nie trafiają do pliku specyfikacji i nigdy nie przechodzą przez model. Dane uwierzytelniające leżą w escrow, a agenci dostają dzierżawy, nigdy same wartości. Z założenia są też przechowywane osobno dla każdego workspace'a. Klienci agencji mają własne klucze i własny dostęp, a jeden klucz na całe konto zatarłby właśnie tę granicę.
Asystent może więc pisać, a człowiek robi to, co wymaga zaufania: raz logować się do narzędzi każdego klienta.
Dlaczego to pasuje do agencji
Konfiguracja w agencji jest z natury powtarzalna. Każdy klient dostaje workspace, kilku agentów nazwanych od klienta, ten sam zestaw konektorów i poranny harmonogram. To szablon z podmienioną nazwą, a w tym agent jest dobry.
Gdy plik leży w repozytorium, dodanie klienta to kilka nowych linii i plan, który je sprawdza. Asystent agencji robi konfigurację, a ludzie z agencji wykonują kroki dla człowieka. Samo działanie agentów się nie zmienia: nadal działają na maszynie, która należy do tej samej osoby co agent.
Konfiguracja jest darmowa, uruchamianie agentów nie
Konto może tworzyć workspace'y i konfigurować agentów bez planu i bez maszyny. Tak utworzony agent czeka, aż będzie miejsce, w którym można go uruchomić. Kosztuje tylko uruchamianie agentów, bo wymaga mocy obliczeniowej.
Zrobiliśmy to celowo. Asystent powinien móc zbudować całość i pokazać ją, zanim ktokolwiek zostanie poproszony o kartę. Płaci się, gdy praca się zaczyna, a nie za planowanie.
Dalej: agenci, którzy sami kupują usługę
Ta część jest planowana, nie zbudowana. Dążymy do agenta, który sam zapłaci za usługę przez HTTP 402, używając płatności maszynowych Stripe: Machine Payments Protocol z Shared Payment Tokens. Złożyliśmy wniosek, by zostać dostawcą Stripe Projects, oraz o wpis w Stripe Directory. Żaden z nich nie został jeszcze zatwierdzony, więc nic z tego dziś nie działa.
Druga połowa to przejęcie przez człowieka, także planowane. Agent wszystko konfiguruje, wysyła link do przejęcia, a osoba wchodzi do workspace'a dokładnie takiego, o jaki prosiła. Zostają jej tylko sekrety.
Dziś agent może wykonać konfigurację, ale człowiek nadal musi założyć konto i, żeby uruchamiać agentów, wybrać plan. Chcemy zamknąć tę lukę, nie odsuwając człowieka od decyzji, które mają znaczenie.
Co działa dziś i co dalej
Działa: CLI hachi, lokalny i hostowany MCP, plan i apply z jednego pliku, kroki dla człowieka przy danych uwierzytelniających oraz darmowa konfiguracja. Planowane: agenci płacący przez HTTP 402 i przejęcie przez człowieka. Jeśli prowadzi się agencję i chce wypróbować działającą połowę, endpoint i powyższy przykład wystarczą na start.