Saphan Studio to płaszczyzna sterowania, która zapisuje odpowiedź na to pytanie dla każdej zmiany.
Twoja flota pracuje w języku zespołu. Rejestr audytowy odpowiada po angielsku. EN ไทย العربية
Zbudowane na Saphan Protocol →
Solo preview — w przyszłym tygodniu
Saphan Studio dla jednego developera, na jednej stacji roboczej, bezpłatnie. Zostaw e-mail, a w dniu premiery dostaniesz link do pobrania — i nic poza tym.
Wyślij mi link →Wersje Team i Enterprise do końca września. Self-hosted: kod i rekord nie opuszczają Twojej maszyny.
Co Saphan Studio daje organizacji
Nadzór → Każda istotna decyzja należy do człowieka i trafia do rejestru. Milczenie nigdy nie oznacza zgody, a odmowy pozostają danymi.
Bezpieczeństwo → Agenci są traktowani jako niezaufani, nawet gdy nie mają złych intencji: każde wykonanie jest izolowane, a ruch wychodzący wymaga jawnie wskazanej polityki.
Koszty → Każde wykonanie jest wyceniane przed uruchomieniem, a koszt trafia obok decyzji, która je zatwierdziła.
Enterprise → Control plane, rekord i tożsamość pozostają w Twojej infrastrukturze, z eksportem audytowym od pierwszego dnia.
Kontrole → Co już działa, kontrola po kontroli — jeden wiersz na każdą: co robi, co odrzuca, co zostaje w rekordzie.
Zgodność → Dowody potrzebne w istniejącym systemie zarządzania bezpieczeństwem informacji (ISMS), powiązane z wymaganiami ISO 27001, ISO/IEC 42001, SOC 2, NIST AI RMF i EU AI Act.
Funkcje produktu
Bench → Jakie obciążenie naprawdę obsłuży Twój sprzęt — zmierzone na Twojej maszynie, a nie wywnioskowane z karty modelu.
Serwer MCP → Zadawaj pytania rejestrowi w narzędziu, którego już używasz: sprawdzaj stan floty, bramki oczekujące na decyzję i koszty w dowolnym przekroju. Interfejs działa tylko do odczytu, za standardowym OAuth, a każdy dostęp jest rejestrowany.
Discovery → Kontrolowana analiza systemu legacy, którego nikt nie rozumie już w całości. Zwraca zatwierdzony obraz systemu, w którym każdy wniosek wskazuje źródło — poznawanie, nie zmienianie. Metoda została sprawdzona w realnych projektach i jest przenoszona na Saphan Protocol.
Nadzorowane runtime’y · działają dzisiaj
Saphan obejmuje governance i security pracy wokół runtime’u: dopuszczenie, izolowaną tożsamość, dispatch, confinement, koszt, dowody, review i akt człowieka. Zmiana modelu albo CLI nie tworzy drugiego systemu operacyjnego.
Claude Code, OpenAI Codex, Qwen Code i Factory Droid działają jako nazwane, izolowane per seat backendy pod tymi samymi strumieniami, bramkami i ledgerem.
Wbudowana pętla narzędziowa prowadzi modele lokalne za endpointami zgodnymi z OpenAI, w tym Ollama i vLLM, bez uzależniania krytycznej ścieżki od CLI vendora.
Kompilatory, test runnery, lintery i formatery są pełnoprawnymi aktorami w rekordzie, bez kosztu modelu — jako nadzorowana praca, nie niewidoczna ucieczka do shella.
Agenci i toolchainy mogą działać w obrazach OCI przypiętych digestem, z read-only rootem, użytkownikiem non-root, ograniczonymi mountami i limitami runtime’u. Dokładny obraz jest mierzony na dokładnej maszynie przed dispatchem; brak wymaganego confinement odmawia przed spawnem.
Akceptacja człowieka dociera do Git forge
Saphan wiąże decyzję człowieka o merge z dokładnym headem pull requestu, przenosi to uprawnienie do forge i dowiaduje się o merge przez obserwację repozytorium — nigdy przez zaufanie udanej odpowiedzi API.
Bramka zapisuje aktora, decyzję i SHA heada PR. Nowy push unieważnia tę zgodę, zamiast po cichu rozciągać ją na inny kod.
Wymagany status saphan/gate i ochrona gałęzi zatrzymują niezatwierdzony merge w samym forge. Saphan nie polega na tym, że UI zachowa się poprawnie.
Forge tworzy merge commit z trailerami atrybucyjnymi Saphan. Rekord przechodzi do stanu merged dopiero po pobraniu i zweryfikowaniu tego commita.
Kontrakt API i jego negatywne kontrole zostały wykonane na rzeczywistych repozytoriach GitHub i Gitea 1.26.4. Pełna ścieżka produktowa saphan merge --via pr jest w aktywnej implementacji; kolejnych adapterów forge nie pokazujemy jako dostarczonych.
Zacznij sam. Zachowaj ten sam control plane, gdy flota rośnie.
Solo
Lokalny silnik, konsola webowa, CLI i praca w edytorze bez centralnego serwera. Otwarte wejście do zdyscyplinowanej pracy agentów, nie wygasający trial.
Team
Tożsamość zarządzana przez Saphan jako SaaS i bezdana sygnalizacja mobilna; flota, kod i rekord operacyjny pozostają na Twojej infrastrukturze.
saphan-oauth utrzymywany przez Saphan i pełny cykl życia tożsamościEnterprise
Samodzielnie hostowana kontrola organizacyjna, tożsamość maszyn, polityka, izolacja i eksport dowodów dla regulowanego delivery.
saphan-oauth albo dowolny dopuszczony IdP klientaSaphan Studio to środowisko, w którym prowadzisz floty agentów AI: zlecenia trafiają do wykonawców, wracają raporty z dowodami, a decyzje na bramkach podejmujesz w edytorze. Czytasz rezultaty, nie transkrypty.
Praca przechodzi dalej dopiero po dołączeniu dowodów i zapisaniu decyzji człowieka. System nie pozwala zarejestrować zatwierdzenia bez dowodów.
Wszystko trafia do zwykłych plików w Twoim repozytorium Git. Powstaje trwała pamięć operacyjna pracy, gotowa do wykorzystania przez narzędzia audytowe, które organizacja już posiada.
To nie lista funkcji. To fundament, który organizacja dostaje dziś — jeden wiersz na jedną kontrolę: co robi i co zostawia w rekordzie dla osoby, której przy tym nie było.
| Kontrola | Co działa | Co zostaje w rekordzie |
|---|---|---|
| Podpisany rekord zarządczy | Aktorzy, delegacje, maszyny, seaty i uprawnienia w jednym dzienniku append-only podpisanym Ed25519. Każdy rejestr czytelny dla człowieka jest jego projekcją — odtwarzalną, nigdy źródłem. | Cała historia zarządcza, weryfikowalna przez stronę trzecią mającą tylko główny klucz publiczny — bez zaufania do maszyny, która ją wytworzyła. |
| Bramki ludzkie, bez wyjątków | Żadnego auto-accept, auto-merge ani „brak odpowiedzi = zgoda" w całym produkcie. Decyzja na bramce nie ma wartości domyślnej i jest odrzucana, gdy przychodzi nie po kolei. Silnik przenosi; nigdy nie osądza. | Jeden wiersz na decyzję: aktor, decyzja z zamkniętego słownika, czas. „Merged" nigdy nie jest deklarowane — jest tylko obserwowane z prawdziwego merge commita. |
| Decyzje odporne na manipulację | Każda akceptacja to kluczowana, zweryfikowana krotka, sprawdzana ponownie przy merge. Zmień później dowolne pole i weryfikacja pada. | Krotka i wynik jej sprawdzenia przy merge. |
| Sugestia ≠ decyzja | Konsultacja — AI albo człowieka — jest zapisywana jako opinia; decyzja jest własnym aktem człowieka; odejście od sugestii samo jest zapisane. | Osobne wiersze rekomendacji i decyzji na każdej bramce — nie tylko co postanowiono, ale co i kto rekomendował. |
| Tożsamość maszyny z certyfikatu | Bez endpointu rejestracji, bez join tokena. Maszynę przyjmuje jawny akt właściciela z powiązaniem certyfikatu; płaszczyzna sterowania łączy się tylko na zewnątrz, a runnery nie trzymają do niej żadnych poświadczeń. | Akt przyjęcia w podpisanym dzienniku; łańcuch certyfikatów. |
| Delegowane, ograniczone uprawnienia | Delegacje podpisane kluczem głównym, z zakresem, strumieniami pracy i oknem ważności. Wygaśnięcie to sufit, nigdy wyzwalacz; wycofanie aktora działa natychmiast, niezależnie od niewygasłych delegacji. | Delegacja z podpisem nad każdym polem — kto komu co nadał i do kiedy. |
| Ratyfikowane prawo stałe | Dokumenty rządzące tym, jak wykonuje się pracę, są podpisane kluczem głównym w numerowany seryjnie manifest. Każdy dokument weryfikuje się z powrotem do korzenia; agent pracuje pod prawem, którego otrzymanie da się wykazać. | Manifest oraz zapis każdego uruchomienia, jakie prawo zostało wstrzyknięte — z jego hashem. |
| Izolacja uruchomień na poziomie OS — lokalnie | Polityka zapisu deny-by-default z sandboksa samego systemu operacyjnego — Seatbelt na macOS, Bubblewrap na Linuksie — składana dla każdego uruchomienia, zanim agent wystartuje. Brak sandboksa odrzuca uruchomienie, zamiast je osłabiać. | Rekord uruchomienia nazywa narzędzie, które je izolowało, i katalogi, które pozostały zapisywalne — twierdzenie, które Twój zespół może odtworzyć. |
| Izolacja uruchomień na poziomie OS — zdalnie | Izolacja wymuszana przez jądro (Landlock) dla uruchomień wysyłanych przez SSH. Zdolność maszyny do izolacji jest mierzona, zanim trafi tam praca; maszyna niezmierzona albo zmierzona jako niezdolna odrzuca uruchomienie. | Zmierzona zdolność na podpisanym wierszu maszyny; rekord uruchomienia nazywający, co wymusiło. |
| Ruch wychodzący to lista | Uruchomienie, które deklaruje politykę egress, dociera do sieci wyłącznie przez drzwi, którymi ta polityka rządzi: cel jest dopuszczony tylko wtedy, gdy polityka dopuszcza i hosta, i port, a domyślnie nie dopuszcza nic. Host, którego nie da się odciąć, odrzuca uruchomienie, zamiast startować otwarty. W tym wydaniu opt-in per dispatch — nie ma jeszcze domyślnego ustawienia dla całej floty i mówimy to wprost. | Digest skompilowanej polityki na wierszu uruchomienia — która lista rządziła tym uruchomieniem. Osądy per połączenie nie są jeszcze zapisywane; to zadeklarowany limit tego wydania, nie projektu. |
| Żadnych bocznych kanałów między agentami | Agenci koordynują się wyłącznie przez zapisywane powierzchnie — ordery, pliki kanałów w worktree strumienia wciągane do rekordu, bramki, skrzynkę insert-only na dyrektywy właściciela. W produkcie nie istnieje komunikacja agent–agent. | „Kto komu co powiedział i kiedy" to zapytanie, nie przesłuchanie — historia koordynacji strumienia odtwarzalna z rekordu. |
| Odmowy jako dane | Każda odmowa — silnika, autoryzacji, schematu, polityki — to zapisany, bezkosztowy wiersz z nazwaną klasą. Przyczyny odmów są logowane, nigdy zwracane po kablu. | Księga odmów: kontrole, które zadziałały, a nie tylko istnieją. |
| Monitorowanie — cel dla Prometheusa | Demon serwujący wystawia GET /metrics w standardowym formacie tekstowym Prometheusa: uruchomienia po statusie i backendzie, odmowy po klasie, decyzje bramek po bramce i decyzji, wersja schematu magazynu. Wartości etykiet to wyłącznie nazwy klas — nigdy nazwy strumieni, ścieżki ani nazwy aktorów. |
Odmowy jako metryka pierwszej klasy — w tej architekturze odmowa to sygnał bezpieczeństwa, nie szum. Zbierane przez Prometheusa, którego już masz; nic do instalowania. |
| Sekrety się nie rozchodzą | Żaden podsystem nie przechowuje ani nie przesyła wartości sekretu — tylko nazwy zmiennych i ścieżki, wymuszone w systemie typów. Pliki kluczy są sprawdzane pod kątem uprawnień, zanim ich treść zostanie odczytana. | Konfiguracja po nazwie. Żadnej wartości w rekordzie, logu ani eksporcie. |
| OAuth 2.1 na powierzchni zarządczej | Dostęp tylko z bearerem. Team uwierzytelnia przez utrzymywany przez Saphan SaaS saphan-oauth. Enterprise uruchamia saphan-oauth lokalnie albo dopuszcza dowolny IdP klienta przez zatwierdzaną przez człowieka listę issuerów. Klasy zakresów, wycinki na poziomie wierszy per tenant, domyślnie fail-closed. |
Log dostępu klasy audytowej na każdym transporcie — uczciwe kody statusu, nigdy wartości ani query stringi. |
| Kontrola kosztów | Wycena i twardy limit na uruchomienie ustalone przed wysłaniem; pojemność sprawdzona przed startem; klasy rozliczeniowe na seatach. Koszty rzeczywiste i odchylenie lądują obok dowodów, nie na osobnej fakturze. | Księga kosztów, per strumień i per bramka — „ile kosztowała ta zmiana" ma tę samą jednolinijkową odpowiedź co „kto ją zatwierdził". |
| Przypięty łańcuch dostaw | Binaria agentów dostarczane z digestem liczonym na maszynie odbierającej, a tożsamość rozwiązywana ponownie tam, gdzie się wykonują. | Na uruchomienie: digest binarium, wersja, hash konfiguracji, wstrzyknięte prawo stałe i jego hash. |
| Twój magazyn rekordu | Magazyn rekordu PostgreSQL na infrastrukturze, którą kontrolujesz, konfigurowany po nazwie, poświadczenia tylko przez nazwę zmiennej. Kod, dowody uruchomień i rekord operacyjny nie przechodzą przez infrastrukturę Saphan. Team przekazuje tożsamość do OAuth Saphan; Enterprise pozostawia ją lokalnie. Oba warianty mogą używać sygnalizacji mobilnej niosącej tylko nieprzejrzysty identyfikator bramki i licznik badge’a. | Twoja baza plus zwykłe pliki w Twoim gicie. Czytelne bez naszych narzędzi. |
| Zgodność mierzona, nie deklarowana | Scenariusze end-to-end uruchamiane na prawdziwym binarium: dyscyplina bramek, blokowanie dispatchu, odporność na injection, źle zaadresowane instrukcje, przepływ OAuth, kontrola bearera, parytet projekcji. | Wyniki testów zgodności, odtwarzalne na Twojej instalacji. |
Fail-closed to styl domu: nierozpoznana wartość konfiguracji, brak sandboksa, niejednoznaczny adres bind — każde odrzucane z nazwaną klasą, zamiast cofać się do słabszej postawy. Tam, gdzie kontrola jeszcze nie wymusza, dokumentacja mówi to wprost, a roadmapa ją nazywa.
Jak te wiersze mapują się na ISO 27001, ISO/IEC 42001, SOC 2, NIST AI RMF i EU AI Act →
Dokumentacja · tylko stan zaimplementowany
Saphan Docs powstaje na podstawie istniejącego kodu i zweryfikowanego zachowania produktu. Obejmuje wdrożenie, konfigurację, bezpieczeństwo, governance, audyt i operacje. Bez roadmapy. Bez obietnic.
Otwórz Saphan Docs ↗Nadzór jest gwarancją. Tak wygląda codzienna praca.
Praca zaczyna się od zlecenia: kompletnego briefu określającego zakres, ograniczenia i wymagane dowody. Silnik przekazuje go agentowi bez utraty kontekstu w historii czatu.
Agent zwraca raport, w którym każdemu twierdzeniu towarzyszy dowód. Czytasz wynik i analizujesz zmiany w kodzie, zamiast przeglądać pełny transkrypt rozmowy. To różnica liczona w godzinach.
Widok floty jest dostępny w VS Code: pokazuje aktywne zadania, elementy czekające na decyzję i komendę potrzebną do jej zapisania. Możesz zatwierdzić przejście przez bramkę bez opuszczania przeglądanego pliku.
Każdy projekt otrzymuje własny „most”: zlecenia, decyzje i wnioski zapisane jako zwykłe pliki w repozytorium Git. Studio dostarcza szablon, a baza kodu otrzymuje swoją strukturę pierwszego dnia. Zasady mają stałe miejsce, zanim ruszy pierwszy agent.
Tak wyglądają rzeczywiste pliki tworzące proces — nie makiety ani zrzuty ekranu z obietnicy:
# ORDER — payments-refactor · wave 1 From: master · To: one executor · Stream: payments-refactor Worktree: worktrees/payments-refactor · Base: main @ 4f21c09 Protocol: saphan-protocol v1.0 · pinned in PROTOCOL_BASELINE.md ## Context — read first The payments module calls three providers (stripe, adyen, in-house ledger) directly from checkout code. Retries are ad hoc; a network blip on 06-24 double-charged three orders (postmortem PM-12). ADR-0007 (attached below) ratified one provider interface at STOP-1. This stream implements it. Nothing here asks you to design — the design decisions are made and recorded; your job is the build. ## Scope IN: a. PaymentProvider interface exactly per ADR-0007 §Decision — the Charge/Refund signatures are frozen there; do not redesign them. b. Three adapters: stripe, adyen, ledger. Existing behavior is preserved; parity proven call-for-call against recorded fixtures in tests/fixtures/providers/. c. Retries with idempotency keys (key = order_id + attempt window), stored in pending_payments — migration 0042, up AND down. d. Wire pin W-2: the public /payments API is FROZEN. Golden tests in tests/golden/payments_test.go must pass untouched — if a golden blocks you, STOP and report; never edit a golden. OUT (recorded — do not touch): checkout UI · refund flows (wave 2) · provider timeout policy (carry-forward on ADR-0007). ## Proof standard build green · full suite, counts as passed-of-total with skipped named · migration 0042 proven up+down on a schema copy, row counts pre/post · adapter parity: fixture diff empty · goldens untouched (git diff --stat on tests/golden = empty) · diff summary per file ## Stops STOP-1 already passed (ADR-0007). STOP-2: full return per template before merge. Merge is human-only, from the gate. ## If blocked Write the blocker under "Open questions" in the return, flag the stream, stop. Guessing past ambiguity is a protocol violation, not initiative.
Brief jest kompletny aż do zamrożonych sygnatur: zawiera kontekst, kontrakty, wiążące decyzje interfejsowe i instrukcję na wypadek blokady. Jeżeli agent musi zgadywać, problem leży w zleceniu — dlatego nie pozostawiamy miejsca na domysły.
# RETURN — payments-refactor · STOP-2 Executor: agent-7 · Commits: 6 (head a3f9e12) · Base: main @ 4f21c09 ## Claims, with evidence 1. PaymentProvider extracted; 3 providers behind one interface. → diff: 14 files (+612 −208) · golden tests untouched, green 2. Retries are idempotent under duplicate delivery. → TestRetryIdempotency: 200 duplicate deliveries, 1 charge 3. Migration proven both ways on a copy of the production schema. → up 1.2s / down 0.9s · row counts identical pre and post ## Open questions for the gate Provider timeout is 30s, inherited. Keep or tighten? Out of scope — flagged, untouched. ## Not done Refund flows: out of scope per order (recorded — wave 2).
Każde twierdzenie wraca razem z dowodem. Raport można przeczytać w kilka minut zamiast analizować dwugodzinny transkrypt.
# ADR-0007 — one PaymentProvider interface; providers are adapters Status: accepted · Date: 2026-06-30 · Actor: marcin · Gate: STOP-1 ## Context Three providers are called directly from checkout code. Each has its own retry style and error mapping; the test surface triples; adding or swapping a provider means surgery on callers. Incident 06-24: a timeout retry double-charged three orders (postmortem PM-12). ## Decision One interface, signatures frozen: Charge(ctx, Order, IdempotencyKey) → (Receipt, error) Refund(ctx, ReceiptRef, Amount) → (Refund, error) Providers become adapters behind it. Error taxonomy unified as retryable / terminal / unknown — the mapping is owned by each adapter and may not leak provider-specific errors upward. ## Consequences + one contract to test; parity provable against recorded fixtures + retries live in one place, above the adapters — idempotency enforced at a single seam, not three − adapters gain a lint rule: no provider error types cross the seam − migration 0042 required for idempotency-key storage ## Considered and passed Per-provider services — triples the test surface, scatters retry logic. Feature flags per provider — hides the seam from the record. ## Carry-forward Timeout inherited at 30s. Decide at wave 2 — trigger: refund flows.
Dokument zawiera kontekst incydentu, który wymusił decyzję, zamrożone sygnatury, konsekwencje — także negatywne — oraz odrzucone warianty z uzasadnieniem. Zlecenie odwołuje się do ADR-u, więc decyzja faktycznie steruje pracą, a nie pełni roli dekoracji.
# Finding 4.2 — a number without a definition is not evidence Seen: a return claimed "tests: 124 passed" while 9 were skipped. The count was true and the claim was false. Rule: every number in a return carries its definition — passed of total, skipped named and justified. Applied: same cycle. All return templates updated; the gate now asks for the definition when a bare number appears.
Niepowodzenie staje się nową regułą w tym samym cyklu, w którym je wykryto. Protokół jest zbiorem sprawdzonych precedensów, nie jednorazowym manifestem.
# The sandbox — how the pieces talk you — the operator │ briefs out · gates · reads returns ▼ editor / CLI (VS Code panel · saphan) │ ▼ saphan engine — self-hosted │ dispatch · fleet projection · refusals ▼ worktrees — one isolated sandbox per stream ├─ agent-3 payments-refactor running, wave 1 ├─ agent-7 atrisk-push stop-2 — awaiting you └─ agent-12 notification-svc merged, observed │ ▼ the bridge — plain files in your git orders · returns · ADRs · findings · gate log │ ▼ main — merge is human-only The protocol is the language every arrow speaks. The record is what every arrow leaves behind.
Agenci działają w izolacji, każdy w osobnym worktree. Silnik komunikuje się w obu kierunkach za pomocą protokołu, a każdy etap pozostawia ślad w pliku. Nic istotnego nie dzieje się poza rejestrem.
Z poziomu edytora wybierasz strumień prac, sprawdzasz dowody i podejmujesz decyzję na bramce — bez opuszczania aktualnego pliku.
$ saphan fleet show [awaiting-human] payments-refactor · stop-2 — evidence attached → run: saphan gate payments-refactor --gate stop2 --actor you
Agent zakończył pracę i dołączył dowody. Nic nie zostaje scalone automatycznie: silnik wskazuje dokładnie, jaka decyzja należy do Ciebie, i zapisuje tożsamość decydenta.
$ saphan gate payments-refactor --gate stop2 --actor marcin [refused] evidence incomplete — claims without proof cannot pass nothing advanced · the gate holds · nothing was merged
Systemowa odmowa jest pełnoprawnym rezultatem. Bramka, która nie potrafi zatrzymać pracy, jest tylko pieczątką.
$ saphan gate payments-refactor --gate stop2 --actor marcin [recorded] stop-2 approved · actor: marcin · 2026-07-14 09:12 +07 evidence: build green · 124 tests passed · diff 6 files · bundle sha256:9f2c…
Kto zezwolił na zmianę i na podstawie jakich dowodów? Odpowiedź pozostaje w jednej linii rejestru.
$ saphan fleet show [running] atrisk-push · wave B in progress [awaiting-human] payments-refactor · stop-2 — evidence attached [merged] notification-service · observed on main
Wielu agentów, jeden spójny widok — każdy stan jednoznacznie wskazuje, kto powinien wykonać następny ruch.
Silnik nigdy nie scala zmian. Umożliwia jedynie zapisanie decyzji — albo odmowę jej przyjęcia, gdy brakuje wymaganych warunków.
Bramka jest kierownicą, nie hamulcem. Zatrzymanie pracy nie ma spowalniać floty, lecz tworzyć najtańszy punkt, w którym można jeszcze zmienić jej kierunek. Poniżej trzy korzyści z pętli decyzyjnej oraz uczciwe wyjaśnienie, co dzieje się po jej wyłączeniu.
Wymagania zmieniają się w trakcie projektu. Zmiana wykryta na bramce oznacza korektę jednego strumienia, a nie wyrzucenie tygodnia pracy całej floty. To najtańszy moment na zmianę kierunku, zanim błąd rozprzestrzeni się na kolejne zadania.
„Wyjaśnij mi to, zanim zatwierdzę.” Operator nadąża za systemem, zamiast podpisywać decyzję w ciemno. Raport z wykonania ma skrócić ten proces do kilku minut, a nie całego popołudnia. Zatwierdzasz świadomie albo nie zatwierdzasz wcale.
Na pytanie „dlaczego tak, a nie inaczej?” odpowiadają dokumenty: ADR-y oraz warianty rozważone i odrzucone. Nie trzeba polegać na czyjejś pamięci decyzji sprzed tygodni. Uzasadnienie trafia do rejestru, zanim ktokolwiek o nie zapyta.
Tryb bez człowieka — bez ukrywania konsekwencji
$ saphan gate payments-refactor --gate stop2 --actor auto-approver [recorded] stop-2 approved · actor: auto-approver · 2026-07-14 09:12 +07
Chcesz uruchomić flotę bez człowieka? Podaj model w parametrze --actor i pozwól mu zatwierdzać kolejne decyzje. System nadal działa, ale rejestr przy każdym „tak” pokazuje, że decyzję podpisała maszyna. Różnica między realnym nadzorem a automatycznym przybijaniem pieczątek staje się mierzalnym faktem, a nie przedmiotem sporu. Nie blokujemy automatycznego zatwierdzania — sprawiamy, że zawsze jest jawne i podpisane.
Człowiek w pętli jest ustawieniem domyślnym, nie bezwzględnym wymogiem. System nie gwarantuje, że decyzję podjął człowiek; gwarantuje, że rejestr zawsze wskaże, kto ją podjął.
Organizacja zatrudniająca pięćdziesięciu inżynierów nie powinna płacić za najbardziej zaawansowany model, gdy zadanie lepiej wykona skrypt. Reguła routingu jest prosta: wybierz najtańszego wykonawcę, który nadal spełnia wymagany standard dowodowy.
Budowanie aplikacji iOS, uruchomienie testów czy pakowanie rezultatów to zadania dla narzędzi, nie rozmowy z modelem. W protokole są wykonawcami tak samo jak agenci: otrzymują zlecenie, zwracają dowody i pozostawiają ten sam ślad w rejestrze. Nie zużywasz tokenów na pracę, którą toolchain wykona lepiej.
Modele uruchamiane we własnej infrastrukturze, dostępne przez ten sam interfejs wykonawcy, obsługują powtarzalne prace: migracje według wzorca, streszczenia i generowanie szkieletu kodu. Twój sprzęt, Twoje dane i koszt energii zamiast opłat za tokeny.
Claude, Codex lub inny zakontraktowany model jest rezerwowany przez politykę do zadań, które naprawdę go wymagają: projektowania, trudnego debugowania i przeglądu. Polityka jest wersjonowanym plikiem tworzonym przez zespół, nie domyślnym ustawieniem wybranym bez decyzji.
Rejestr wskazuje wykonawcę każdego strumienia prac. Przypisanie kosztu jest częścią kontraktu, nie późniejszym szacunkiem. Koszt znajduje się obok dowodów dla konkretnego strumienia i bramki, dlatego pytanie „ile kosztowała ta zmiana?” ma równie prostą odpowiedź jak „kto ją zatwierdził?”
Koszty powstają dziś w dwóch miejscach: inżynierowie korzystają z agentów w CLI w ramach licencji abonamentowych, a zautomatyzowane procesy zużywają tokeny rozliczane przez API. Bez wspólnego mechanizmu trudno je przypisać. Saphan obejmuje oba modele tym samym kontraktem: jedno zlecenie na wejściu, te same dowody na wyjściu i jeden rejestr — niezależnie od tego, czy wykonawcą jest interaktywna sesja CLI, czy automatyczne wywołanie API. Koszt przestaje być rozdzielony między dwie nieporównywalne faktury.
Warstwa routingu działa dziś w naszym środowisku: jedna polityka obejmuje wykonawców od lokalnego serwera modeli po zewnętrzne API najbardziej zaawansowanych modeli, a agenci sterowani z CLI już pracują pod kontrolą Saphan. Automatyczny wariant API korzysta z tego samego kontraktu. Moduł kosztowy finalizujemy z partnerami pilotażowymi; mechanizm przypisywania kosztu jest już częścią kontraktu.
Routing określa, gdzie powinna trafić dana klasa zadań. Bench mierzy, jakie obciążenie rzeczywiście obsłuży Twoja maszyna — dzięki czemu decyzja opiera się na danych, a nie założeniach. Różnica między nimi bywa duża i nie da się jej wiarygodnie przewidzieć bez pomiaru.
$ saphan-verdict [verdict] class-120b — 120.99 GiB addressable · hot + large fit co-resident → note: glm-4.5-air rejected — dominated by gpt-oss-120b on this class [critical] addressable memory is 63.3 of 125.5 GiB installed — raise the ceiling
Bezpłatny test niczego nie instaluje i nie wysyła danych na zewnątrz. Raportuje pamięć dostępną dla GPU, nie tylko zainstalowany RAM. Na maszynie referencyjnej różnica obejmowała niemal połowę pamięci, dlatego ocena dopasowania zawsze opiera się na niższej wartości.
W pomiarze czterech modeli na jednym węźle z 128 GB pamięci model GLM-4.5-Air — flagowy kandydat, którego łatwo byłoby wybrać bez testu — okazał się 2,1 raza wolniejszy zarówno przy przetwarzaniu promptu, jak i generowaniu tokenów od gpt-oss-120b i wymagał o 10 GiB więcej pamięci. Karta modelu nie pokaże tej różnicy, bo nie opisuje Twojej konkretnej maszyny.
Frameworki agentowe — LangGraph, CrewAI i rozwiązania własne — określają, jak agenci współpracują.
Platformy zarządzania AI obejmują modele, dane i polityki z perspektywy całej organizacji.
Pomiędzy nimi pozostaje warstwa, w której wynik pracy agenta staje się zmianą objętą odpowiedzialnością człowieka. W tym miejscu brakuje ugruntowanego rozwiązania. Saphan wypełnia tę lukę: działa ponad frameworkami i niezależnie od platform zarządzania AI. Możesz wymienić stos agentowy, a warstwa autoryzacji pozostaje.
Interfejs wykonawcy jest celowo mały: wykonawca otrzymuje zlecenie i zwraca dowody. Każde narzędzie, które potrafi spełnić ten kontrakt, może pracować pod kontrolą Saphan.
Agenci kodujący sterowani z CLI oraz deterministyczne polecenia. Właśnie w ten sposób rozwijamy Saphan w codziennej pracy produkcyjnej. To nie koncepcja — flota dostarczająca produkt korzysta z dokładnie tego samego kontraktu.
Przyjąć kompletne zlecenie. Wykonać pracę w odizolowanym worktree. Zwrócić twierdzenia wraz z dowodami. To cały interfejs: bez osadzania SDK i bez przepisywania frameworka. Adapter tłumaczy dane na granicy, a Twój stos pozostaje bez zmian.
Interfejs adaptera dla LangGraph, CrewAI, Microsoft Agent Framework i A2A jest zdefiniowany. Poszczególne adaptery powstają z partnerami pilotażowymi w kolejności wynikającej z realnych potrzeb. Wolimy dostarczyć jeden adapter używany produkcyjnie niż umieścić cztery logotypy na slajdzie.
Frameworki agentowe zmieniają się wraz z rynkiem; historia decyzji i nadzoru nie powinna zmieniać się razem z nimi. Możesz przyjąć jeden framework, wymienić go albo prowadzić dwa równolegle — zlecenia, bramki i rejestr pozostają takie same, ponieważ nigdy nie należały do frameworka.
Metoda nie jest zamknięta w narzędziu. Saphan Protocol to wersjonowany, czytelny dla człowieka zestaw zasad egzekwowanych przez silnik: zlecenia, bramki decyzyjne, wymagania dowodowe i rejestry decyzji. Protokół jest stale doskonalony na podstawie pracy naszych własnych flot.
Maszyny go wykonują, a audytorzy i inżynierowie mogą go po prostu przeczytać. Wersja 1.0 zostanie opublikowana wraz z publicznym wydaniem.
Saphan po tajsku znaczy „most” — สะพาน. Buduję produkt w Hua Hin w Tajlandii, a znak na tej stronie przedstawia most Ramy VIII w Bangkoku: pojedynczy pylon na jednym brzegu utrzymuje pomost za pomocą wyraźnie widocznych lin. W tej konstrukcji nic nie jest ukryte — można prześledzić każdą siłę i zobaczyć, co przenosi obciążenie. To trafna metafora produktu: praca przechodzi na drugą stronę, nic nie znika po cichu i zawsze wiadomo, co utrzymało decyzję.
Jest też głębszy powód. Przez lata pracy z infrastrukturą widziałem systemy, które zawodziły w tym samym miejscu — nie w samym kodzie, lecz podczas przekazania pracy z jednej strony na drugą. Później nikt nie potrafił powiedzieć, kto ją dopuścił ani dlaczego. Agenci nie stworzyli tego problemu; zwielokrotnili go ponad możliwości ludzkiej pamięci. Narzędzie nosi więc nazwę brakującego elementu: nie muru ani bramki istniejącej dla samej kontroli, lecz mostu, który pamięta każde przejście.
Protokół i silnik działają produkcyjnie w naszych projektach. Saphan jest rozwijany przy użyciu własnego protokołu i własnej floty.
Publiczne wydanie będzie udostępniane etapami; protokół v1.0, silnik i pakiet audytowy zostaną opublikowane razem.
Wybieramy 2–3 partnerów pilotażowych — zespoły liczące 50–500 inżynierów, z realnymi obowiązkami regulacyjnymi i audytowymi.
Mechanizm stojący za rejestrem jest objęty zgłoszeniem patentowym w USA.
Polska — IP Partner, Warszawa. IP Partner reprezentuje Saphan w Polsce: pierwsza rozmowa po polsku, wdrożenie na Waszej infrastrukturze i lokalny zespół dla organizacji, które wprowadzają agentów AI do inżynierii objętej regulacjami. Kontakt: Łukasz Bederski, MBA, Founder — ippartner.pl · LinkedIn.
Chcesz reprezentować Saphan na swoim rynku? [email protected]
Tempo pracy agentów przekracza możliwości przeglądu. Pull requesty się piętrzą, a przegląd kodu staje się formalnością. Jednocześnie klienci enterprise i audytorzy pytają, kto nadzoruje zmiany wprowadzane przez agentów. Odpowiedź „spojrzał na to senior” nie rozwiązuje żadnego z tych problemów.
Zespół pilotażowy pracuje tą metodą na co dzień: zlecenia trafiają do agentów, wracają raporty z dowodami, a decyzje na bramkach są podejmowane w edytorze. Repozytorium otrzymuje własną strukturę procesu pierwszego dnia, zanim ruszy pierwszy agent.
Dodatkowa korzyść audytowa: skoro każda zmiana zawiera już dowody i zapisaną decyzję, odpowiedź na kwestionariusz bezpieczeństwa staje się gotowym dokumentem, a nie improwizowanym akapitem.
Zespół sprzedaży otrzymuje komunikat, który może przedstawić klientom i poprzeć dowodami: „nasze floty AI podlegają audytowalnej warstwie autoryzacji”. To zaufanie, które można udokumentować.
Jeden zespół i jedno repozytorium. Wdrożenie jest prowadzone osobiście przez założyciela, a pierwsze bramki działają na rzeczywistej pracy już w pierwszym tygodniu. Saphan działa w całości we własnej infrastrukturze, więc kod nie trafia do nowego zewnętrznego systemu. Zaangażowanie zespołu: około godziny tygodniowo. Brak opłat licencyjnych przez cały pilotaż. Możesz zakończyć współpracę w dowolnym momencie i zachować wszystkie dane oraz pliki.
Rejestr składa się ze zwykłych plików w Twoim repozytorium Git i pozostaje czytelny bez naszych narzędzi. Saphan Protocol v1.0 zostanie opublikowany otwarcie, dlatego zespół zachowuje wypracowane zasady nawet bez dostawcy. System uruchomiony u Ciebie nadal działa. Brak uzależnienia od dostawcy wynika z architektury, a nie z deklaracji.
Twoje przypadki brzegowe stają się uogólnionymi regułami protokołu — bez ujawniania wewnętrznych szczegółów. Napotkane tarcia wyznaczają plan rozwoju, a wariant Team — bramki na poziomie organizacji, wspólny widok floty i widoki audytowe — powstaje z uwzględnieniem realiów Twojej organizacji. Pierwsi partnerzy otrzymują preferencyjne warunki na piśmie przed publikacją cennika.
Współpraca pilotażowa
Skontaktuj się z nami — [email protected]