Model operacyjny: kto odpowiada za harness, bramki i ewaluacje

Model operacyjny dla oprogramowania budowanego przez agentów wskazuje jednego rozliczalnego właściciela każdego artefaktu, który steruje agentami albo ich sprawdza: wspólnych reguł, skilli, hooków, rejestru MCP, tożsamości agentów, zestawów ewaluacji, rejestru autonomii, pętli nienadzorowanych i bramki produkcyjnej. Zespoły produktowe odpowiadają za intencję i akceptację, funkcja platformowa za harness, a bezpieczeństwo i wskazany właściciel wydań pilnują bramek.

Sześć zespołów wdrożyło Claude Code, Codex i Cursora w jednym kwartale i dziś każde repozytorium ma własny CLAUDE.md, trzy kopie skilla „secure review” rozjechały się, a serwer MCP działa na prywatnym tokenie konkretnej osoby. W poniedziałek aktualizacja hooka blokuje wszystkie commity w dwóch zespołach i nikt nie wie, kto może ją wycofać. To problem własności, a nie narzędzi, i rośnie z każdym kolejnym agentem.

Ta strona jest dla CTO lub VP Engineering, który musi odpowiedzieć „kto za to odpowiada?” dla każdego elementu, oraz dla członka zarządu, który chce wiedzieć, czy ktokolwiek odpowiada.

Co daje ci ten model operacyjny

• Tabelę RACI dla jedenastu artefaktów kontrolujących pracę agentów, z dokładnie jednym rozliczalnym właścicielem w każdym wierszu.
• Mapę tego, gdzie znajduje się każdy artefakt i jak jest egzekwowany w Claude Code, Codeksie i Cursorze.
• Szablon rejestru autonomii: jeden wiersz na pętlę, z poziomem, klasą ryzyka, wyrocznią, tożsamością i właścicielem.
• Kryteria decyzji, kiedy wystarczy wskazany właściciel, a kiedy uzasadniony jest zespół platformowy.
• Opis tego, co zespół platformowy robi z przepustowością code review i jak nie dopuścić, by sam stał się wąskim gardłem.
• Jednostronicowy szablon karty (charter) do przyjęcia bez zmian oraz pięć pytań, które zarząd może zadać CTO.

Czym jest harness i dlaczego każda jego część potrzebuje właściciela?

Harness to wszystko wokół modelu, co sprawia, że jego wynik jest przewidywalny i sprawdzalny: instrukcje, powtarzalne procedury, kontrole w czasie działania, dostęp do narzędzi, poświadczenia, testy i ewaluacje oraz bramki decydujące o tym, co trafia na produkcję. Łańcuch artefaktów opisuje, jak praca przez niego przepływa. Model operacyjny rozstrzyga, kto odpowiada, gdy któreś ogniwo zawiedzie.

Każdy artefakt z tabeli poniżej jest stanem współdzielonym. Jedna zmiana trafia do każdej sesji agenta, która go wczytuje, dlatego „ten, kto ostatnio go ruszał” nie jest właścicielem.

Artefakt	Co kontroluje	Co się psuje bez właściciela
Reguły repozytorium (CLAUDE.md, AGENTS.md, Cursor Rules)	Co agent wie o tej bazie kodu	Sprzeczne reguły; agent słucha niewłaściwej
Polityka zarządzana	Uprawnienia, dozwolone modele, hooki, serwery MCP i marketplace’y pluginów dla wszystkich	Każdy programista ma inną efektywną politykę
Wspólne skille i pluginy	Powtarzalne procedury (review, migracja, release notes)	Rozjechane forki; zepsuty skill trafia do wszystkich
Wspólne hooki	Deterministyczne kontrole w momencie wywołania narzędzia	Zablokowana praca albo wszystko przepuszczone po cichu
Rejestr MCP	Do jakich narzędzi i źródeł danych agenci mają dostęp	Niesprawdzone serwery z szerokimi tokenami
Tożsamości i poświadczenia agentów	Co agent może zrobić poza sandboxem	Pętle na tokenie człowieka
Wyrocznie (kryteria akceptacji i testy)	Czy zmiana robi to, o co proszono	Agent przechodzi, osłabiając testy
Zestawy ewaluacji harnessu	Czy zmiana reguły, skilla, hooka lub modelu poprawia pracę agentów, czy ją pogarsza	Regresje wychodzą jako incydenty
Rejestr autonomii	Która pętla działa na jakim poziomie drabiny i w jakiej klasie ryzyka	Autonomia rośnie przypadkiem
Pętle nienadzorowane	Uruchomienia agentów z harmonogramu i ze zdarzeń	Osierocone zadania dalej wydają pieniądze
Bramka produkcyjna	Co trafia do użytkowników i kto to autoryzował	Autor sam zatwierdza swoją zmianę

RACI: kto odpowiada za który artefakt harnessu?

Czytaj tabelę wierszami. A (accountable, rozliczalny) to jedna osoba lub rola, która odpowiada za artefakt i może powiedzieć „nie”; w każdym wierszu jest dokładnie jedna. R (responsible) wykonuje pracę. C (consulted) przegląda przed zmianą. I (informed) dowiaduje się po fakcie. Agent nigdy nie jest A i nigdy nie jest R dla bramki.

Artefakt	Zespół produktowy (tech lead)	Właściciel lub zespół platformowy	Bezpieczeństwo	Właściciel wydań (właściciel usługi)	CTO
Reguły repozytorium	A, R	C	I	—	—
Polityka zarządzana	C	R	A	—	I
Wspólne skille i pluginy	C, współtworzy	A, R	C	—	—
Wspólne hooki	C	A, R	C	I	—
Rejestr MCP (allowlista)	C, zgłasza	R	A	—	I
Tożsamości i poświadczenia agentów	I	R	A	C	—
Wyrocznie (kryteria akceptacji, testy)	A, R	C	C (testy bezpieczeństwa)	C	—
Zestawy ewaluacji harnessu	R (przypadki zadań)	A, R	C	—	I
Rejestr autonomii	R (proponuje zmiany)	C	C	C	A
Pętle nienadzorowane	A, R (dla każdej pętli)	C	C	I	—
Bramka produkcyjna	C	C	C	A, R	I

Cztery zasady sprawiają, że tabela działa w praktyce:

1. Zespół, który dostarcza produkt, decyduje, co znaczy „poprawnie”. Kryteria akceptacji i testy zostają w zespole produktowym, bo tylko on wie, jakie ma być zachowanie. Zespół platformowy może dać narzędzia do ochrony wyroczni, ale nie decyduje, co wyrocznia sprawdza.
2. Bezpieczeństwo odpowiada za zasięg, platforma za zachowanie. Wszystko, co poszerza to, czego agent może dotknąć (serwery MCP, poświadczenia, uprawnienia zarządzane), wymaga zgody bezpieczeństwa. Wszystko, co zmienia sposób pracy agenta w tym zasięgu (skille, hooki, ewaluacje), należy do właściciela platformy. Same tożsamości definiuje strona tożsamość agentów, poświadczenia i sekrety.
3. Podniesienie autonomii to decyzja kierownictwa. Przesunięcie pętli w górę drabiny zmienia ryzyko organizacji, dlatego za rejestr odpowiada CTO (albo wskazany head of engineering). Zespoły proponują, rejestr zapisuje dowody.
4. Bramka produkcyjna ma ludzkiego właściciela, który nie jest autorem zmiany. Agent-autor plus agent-recenzent to nie jest rozdział obowiązków: mogą dzielić poświadczenia, konfigurację i martwe pola. Właściciel wydań zatwierdza przez mechanizm platformy, tak jak opisuje to governance i autonomia.

Zarządzany bot do review nie jest bramką

Dokumentacja zarządzanego Code Review od Anthropic mówi, że jego check run „always completes with a neutral conclusion so it never blocks merging” (sprawdzone 2026-08-28). Agenci recenzujący dokładają ustalenia. Bramką jest twoja ochrona gałęzi, wymagane checki i zgoda właściciela wydań, a każde z nich musi mieć właściciela w RACI.

Gdzie w Claude Code, Codeksie i Cursorze znajduje się każdy artefakt

RACI nie zależy od narzędzia; egzekwowanie już tak. Właściciel platformy musi wiedzieć, który plik lub konsola czyni dany wiersz wiążącym, bo instrukcja w pliku reguł jest radą, a ustawienie zarządzane jest polityką.

Claude Code

Warstwa polityki. Ustawienia zarządzane (managed settings) są najwyżej w kolejności pierwszeństwa, ponad argumentami wiersza poleceń oraz ustawieniami projektu i użytkownika. Dostarcza się je jako managed-settings.json, przez MDM albo jako ustawienia zarządzane z serwera w konsoli claude.ai (Team i Enterprise).

Klucze odpowiadające wierszom RACI (wszystkie obecne w changelogu Claude Code do v2.1.283):

• Wspólne hooki: allowManagedHooksOnly ignoruje hooki użytkownika i projektu. Hooki z pluginów wymuszonych przez ustawienia zarządzane nadal działają, więc zespół platformowy dostarcza hooki w swoim pluginie.
• Skille i pluginy: strictKnownMarketplaces i blockedMarketplaces ograniczają źródła pluginów; enabledPlugins włącza pluginy platformy.
• Rejestr MCP: allowManagedMcpServersOnly i deniedMcpServers.
• Uprawnienia zarządzane: allowManagedPermissionRulesOnly; permissions.disableAutoMode to wyłącznik trybu auto dla całej organizacji.
• Modele: availableModels i enforceAvailableModels.

{
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "anthropics/claude-plugins-official" },
    { "source": "github", "repo": "acme/*" }
  ],
  "extraKnownMarketplaces": {
    "acme-plugins": { "source": { "source": "github", "repo": "acme/acme-plugins" }, "autoUpdate": true }
  },
  "enabledPlugins": { "acme-harness@acme-plugins": true },
  "allowManagedHooksOnly": true
}

acme/acme-plugins to repozytorium marketplace’u zespołu platformowego, a acme-harness to jego plugin ze wspólnymi skillami i hookami. Ewaluacje: claude plugin eval uruchamia przypadki ewaluacyjne pluginu i raportuje wyniki względem wariantu bez pluginu, co daje właścicielowi platformy bramkę dla każdego wydania skilla lub hooka.

Codex

Warstwa polityki. Codex oddziela wartości domyślne od ograniczeń. config.toml trzyma wartości domyślne, requirements.toml ograniczenia egzekwowane przez administratora. Wytyczna samego OpenAI: „Keep config.toml defaults, requirements.toml constraints, and managed or administrator policy separate.”

Klucze odpowiadające wierszom RACI (z config_requirements.rs w openai/codex, sprawdzone 2026-09-26): allow_managed_hooks_only i managed_hooks dla wspólnych hooków; mcp_servers dla rejestru MCP; plugins i marketplaces dla skilli i pluginów; permission_profile, approval_policy i approvals_reviewer dla uprawnień zarządzanych; enforce_residency dla lokalizacji danych.

# requirements.toml: ignoruj konfiguracje hooków użytkownika, projektu i sesji
allow_managed_hooks_only = true

Ustawienie allow_managed_hooks_only w config.toml nic nie robi; OpenAI dokumentuje ten klucz jako dostępny wyłącznie w requirements.toml. Reguły repozytorium są w AGENTS.md. Od Codeksa 0.150.0 niezaufane projekty nie dostarczają projektowego AGENTS.md, więc decyzja o zaufaniu sama jest częścią polityki.

Cursor

Warstwa polityki. Cursor pakuje te same typy artefaktów: Rules, Agent Skills, Hooks, Plugins („package rules, skills, agents, commands, MCP servers, and hooks”) i MCP (dokumentacja Cursora, sprawdzone 2026-08-28). Dla wierszy bramek Bugbot recenzuje pull requesty, a PR Routing & Approval „assigns reviewers based on code ownership and commit history, and can approve low-risk PRs when your criteria are met”.

Ta ostatnia funkcja przenosi część wiersza bramki produkcyjnej do narzędzia, więc RACI musi mówić, kto odpowiada za kryteria zatwierdzania. Przypisz je właścicielowi wydań, a regułę automatycznego zatwierdzania traktuj jak zmianę w rejestrze autonomii.

Kontrole administracyjne zespołu w Cursorze (sprawdzone 2026-08-28) często się zmieniają; zanim wpiszesz je do karty, potwierdź w dokumentacji administracyjnej Cursora, co da się wymusić. Strona jedna polityka dla wszystkich agentów kodujących porównuje trzy narzędzia obok siebie.

We wszystkich trzech narzędziach wzorzec jest ten sam: właściciel platformy publikuje skille, hooki i konfigurację MCP jednym wersjonowanym kanałem (marketplace pluginów albo wewnętrzne repozytorium), a polityka zarządzana czyni ten kanał jedynym dozwolonym. O dystrybucji piszemy w zespołowym marketplace pluginów oraz w rejestrach i bramach MCP.

Co wpisać do rejestru autonomii?

Rejestr autonomii to jeden wiersz na pętlę agenta, czyli nazwany przepływ pracy, na przykład „aktualizacje zależności w serwisie płatności” albo „od zgłoszenia do PR dla zmian tekstów w UI”. Zapisuje poziom pętli na drabinie autonomii oraz klasę ryzyka zmian, które pętla wprowadza. Poziom mierzy zaufanie do pętli; klasa ryzyka (niska, średnia, wysoka, krytyczna) mierzy, ile kosztuje błąd. Rozdzielenie ich sprawia, że dojrzała pętla nie dostanie zmian krytycznych tylko dlatego, że dotąd dobrze działała.

Pętla	Właściciel (A)	Poziom	Klasa ryzyka	Wyrocznia	Zestaw ewaluacji	Tożsamość agenta	Warunek stopu	Następny przegląd
Aktualizacje łatek zależności, web-app	Tech lead web	L4	niska	Pełny zestaw testów plus audyt lockfile’a	evals/deps (12 przypadków)	bot-deps-web (zapis w repo, bez deployu)	Dwie rundy CI, potem zwrot do człowieka	2026-12-01
Od zgłoszenia do PR, teksty UI	Tech lead growth	L3	niska	Snapshoty wizualne plus linter tekstów	evals/copy (8 przypadków)	bot-issues-growth	Jeden PR na zgłoszenie; merge robi człowiek	2026-11-15
Refaktoryzacja płatności	Tech lead płatności	L2	krytyczna	Testy charakteryzujące plus testy właściwości	jeszcze brak	tylko sesja programisty	Człowiek zatwierdza każdy plan	na żądanie

Warunek stopu w pierwszym wierszu pochodzi z opublikowanego przez Stripe limitu dla ich Minions: „at most two rounds of CI”, po czym gałąź wraca do człowieka (blog inżynierski Stripe, 2026-02-09). Każdy wiersz potrzebuje takiego warunku stopu, nazwanej tożsamości i zestawu ewaluacji, zanim poziom wzrośnie powyżej L3.

Zmiana dowolnego wiersza przechodzi przez CTO lub osobę wskazaną w karcie, z dołączonymi dowodami: wynikami ewaluacji, odsetkiem zaakceptowanych zmian pętli i ewentualnymi incydentami. Zasady działania samych pętli opisuje strona nienadzorowane uruchomienia agentów.

Kiedy zespół platformowy ma uzasadnienie?

Zespół platformowy ma uzasadnienie wtedy, gdy artefakty harnessu są współdzielone przez zespoły i błąd w jednym trafia do wszystkich. Wcześniej wystarczy wskazany właściciel. Raport DORA 2025 stwierdza, że „90% of organizations have adopted at least one platform and there is a direct correlation between a high quality internal platform and an organization’s ability to unlock the value of AI” (Google Cloud, 2025-09-23). To korelacja, a nie przyczynowość, ale stawia platformę na ścieżce krytycznej.

Stripe pokazuje, czym platforma zarządza w skali: ich Toolshed „currently contains nearly 500 MCP tools for internal systems and SaaS platforms” (blog inżynierski Stripe, 2026-02-19). To jeden katalog wspólny dla każdego uruchomienia Minion.

Skorzystaj z tabeli decyzyjnej. Progi są roboczą regułą tego przewodnika, a nie opublikowanym benchmarkiem; dopasuj je do swojego profilu ryzyka.

Twoja sytuacja	Model własności	Co robi właściciel
Jeden zespół, jedno lub dwa repozytoria, brak pętli nienadzorowanych	Wskazany właściciel harnessu: tech lead, kilka godzin tygodniowo	Trzyma reguły, skille i hooki w repozytorium; uruchamia ewaluacje przed ich zmianą
Dwa lub trzy zespoły dzielące skille lub serwery MCP albo pierwsza pętla nienadzorowana z prawem zapisu	Wirtualna grupa platformowa: po jednym właścicielu na typ artefaktu z zespołów, wspólne repozytorium, pozycja w budżecie	Publikuje jeden marketplace, odpowiada za ewaluacje, prowadzi rejestr
Trzy lub więcej zespołów dublujących pracę nad harnessem, drugi dostawca agentów, pętle nienadzorowane w wielu repozytoriach albo audytor proszący o dowody, których zespoły nie potrafią dostarczyć	Dedykowany zespół platformowy agentów	Prowadzi harness jak produkt; zob. zespół platformowy agentów
Systemy objęte regulacjami albo zmiany klasy krytycznej wykonywane przez agentów	Zespół dedykowany, z działem bezpieczeństwa w składzie albo na dyżurze przy zmianach MCP i tożsamości	Dokłada dowody kontroli dla audytu i zarządzania zmianą

Zanim zatrudnisz zespół, przeprowadź na jednej pętli pilotaż, który czegoś dowodzi. Platforma zbudowana przed pilotażem zwykle standaryzuje domysły.

Co zespół platformowy robi z przepustowością code review?

Analiza Faros AI z 2025 roku („AI Productivity Paradox”, ponad 10 000 programistów) podała, że programiści w zespołach intensywnie korzystających z AI scalali około 98% więcej pull requestów, a czas review rósł o około 91% (Faros AI, 2025; źródło wtórne). Zespół platformowy rozwiązuje to nie przez więcej review, lecz czyniąc review zbędnym dla większości zmian i trzymając się z dala od ścieżki review produktu.

1. Przenieś sprawdzanie z czytania do bramek. Zespół platformowy dostarcza hooki, fitness functions i zestawy ewaluacji, które łapią to, co recenzenci łapali wzrokiem, oraz pakiet dowodów, który mówi recenzentowi, co zostało zweryfikowane.

2. Kieruj według klasy ryzyka. Zmiany klasy niskiej z kompletnym pakietem dowodów dostają lżejsze review; zmiany wysokie i krytyczne trafiają do właściciela wydań. Reguły kierowania są w rejestrze, a nie w głowach poszczególnych recenzentów.

3. Ogranicz liczbę otwartych prac agentów na recenzenta. Pętla, która otwiera więcej pull requestów, niż właściciel zdąży przejrzeć, płaci za rosnącą kolejkę, więc jej warunek stopu ogranicza liczbę otwartych pull requestów.

4. Recenzuj harness, nie produkt. Zespół platformowy zatwierdza zmiany we wspólnych skillach, hookach, polityce i ewaluacjach. Nigdy nie stoi na ścieżce zatwierdzania pull requestów produktu; jeśli stoi, stał się bramką, której ten model ma unikać.

5. Mierz kolejkę. Śledź czas oczekiwania na review w podziale na klasy ryzyka i odsetek pull requestów agentów scalonych z kompletnym pakietem dowodów. Definicje są w frameworkach metryk, a codzienna praktyka w prowadzeniu kolejki code review.

Jak udowodnić, że model operacyjny działa?

RACI na wiki niczego nie dowodzi. Model działa, gdy każdy rozliczalny właściciel potrafi pokazać dowody bez czytania każdego diffa:

• Zmiany harnessu przechodzą ewaluacje przed wdrożeniem. Zmiana skilla, hooka, polityki lub modelu uruchamia zestaw ewaluacji harnessu i jest porównywana z bieżącą wersją; właściciel platformy zatwierdza wynik, nie diff. Zob. ewaluacje agentów kodujących.
• Każda akcja agenta prowadzi do tożsamości i pętli. Commity, pull requesty i deploye niosą tożsamość agenta i wiersz rejestru, więc właściciel wydań i audytorzy widzą, która pętla co wytworzyła.
• Bramki są mechanizmami platformy. Ochronę gałęzi, wymagane checki i zatwierdzanie deployów egzekwują platforma repozytorium (GitHub, GitLab) i system wdrożeń, a każde z nich ma swoje A w RACI.
• Rejestr zgadza się z rzeczywistością. Comiesięczne zadanie wylicza każde uruchomienie agenta z harmonogramu lub ze zdarzenia, a wszystko, czego nie ma w rejestrze, zostaje wstrzymane.

Raz na kwartał przećwicz model tak, jak ćwiczysz odtwarzanie z kopii zapasowej:

1. Zmień wspólny skill na gałęzi i potwierdź, że bramka ewaluacji blokuje regresję.
2. Unieważnij jedną tożsamość agenta i potwierdź, że jej pętle się zatrzymują, a żaden człowiek nie traci dostępu.
3. Spróbuj zainstalować nieuwzględniony w rejestrze serwer MCP na zarządzanej maszynie i potwierdź, że polityka to blokuje.
4. Zaproponuj podniesienie pętli o jeden poziom i potwierdź, że zmiana wymaga wskazanego zatwierdzającego i dowodów.
5. Wycofaj wspólny hook i zmierz, ile czasu zajmuje dotarcie wycofania do każdego programisty.

Prompty do skopiowania: zmapuj swój obecny harness

Uruchom je w Claude Code, Codeksie lub Cursorze z katalogu głównego repozytorium. Działają tak samo we wszystkich trzech narzędziach, bo tylko czytają pliki i piszą raport.

Prompt do skopiowania: inwentaryzacja artefaktów harnessu i propozycja właścicieli

Read-only task. Do not edit, commit or install anything.
Inventory every artifact in this repository that steers or checks coding agents:
CLAUDE.md and AGENTS.md files at any depth, .claude/ (settings, skills, agents, hooks),
.codex/ and .agents/ directories, .cursor/ (rules, hooks, mcp.json), .mcp.json,
plugin manifests, CI workflows that run an agent (claude-code-action, codex-action,
Cursor CLI), CODEOWNERS, and branch-protection or required-check configuration
referenced from CI.
For each artifact, output one table row: path, artifact type (repository rules,
skill, hook, MCP server, agent identity or token reference, eval, unattended loop,
gate), who changed it last according to git log, whether CODEOWNERS covers it,
and a proposed accountable role from: product team, platform owner, security,
release owner, CTO.
Flag separately: any token or secret referenced by an agent workflow that looks
like a personal credential, any agent workflow with write access and no stop
condition, and any skill or hook duplicated under different names.

Prompt do skopiowania: szkic wierszy rejestru autonomii z CI

Read-only task. List every scheduled or event-triggered job in .github/workflows
(or .gitlab-ci.yml) that invokes a coding agent. For each job, draft one autonomy
register row with these columns: loop name, trigger, repository scope, credential or
identity used, permissions it holds (contents, pull-requests, deployments), what
tests or checks run before its output is merged, its stop condition (max runs,
max CI rounds, max open PRs), and what a human must approve.
Write "UNKNOWN" instead of guessing, and list every UNKNOWN at the end as a
question for the loop's owner.

Jednostronicowy szablon karty modelu operacyjnego

Skopiuj szablon do podręcznika inżynierskiego, uzupełnij nazwiska i daj do podpisu CTO. Przeglądaj go co kwartał i po każdym incydencie spowodowanym przez agenta.

# Karta modelu operacyjnego agentów: <organizacja>, v<N>, <data>

## Cel
Agenci piszą i zmieniają tu kod w ramach jednej polityki. Karta wskazuje, kto
odpowiada za każdy artefakt, który nimi steruje lub ich sprawdza, i jak rośnie autonomia.

## Rozliczalni właściciele
<Wklej tabelę RACI ze strony o modelu operacyjnym. W każdej komórce A wpisz
konkretną osobę i jej zastępcę.>

## Zasady
1. Agent nigdy nie jest rozliczalny i nigdy nie zatwierdza bramki.
2. Wspólne skille, hooki, konfiguracja MCP i polityka trafiają do ludzi wyłącznie
   przez <kanał> i przechodzą ewaluacje harnessu przed wdrożeniem.
3. Każda pętla nienadzorowana ma wiersz w rejestrze, nazwaną tożsamość, zestaw
   ewaluacji i warunek stopu, zanim ruszy. Pętle spoza rejestru są wstrzymywane.
4. Podniesienie poziomu lub klasy ryzyka pętli wymaga <zatwierdzającego> i dowodów.
5. Grupa platformowa recenzuje zmiany harnessu, nigdy pull requestów produktu.

## Poziomy usług
- Odpowiedź na wniosek o zmianę harnessu w ciągu <N> dni roboczych.
- Wycofanie zepsutego wspólnego hooka lub skilla w ciągu <N> godzin.
- Unieważnienie tożsamości agenta w ciągu <N> minut od zgłoszenia incydentu.

## Dowody, które przechowujemy
Wyniki ewaluacji każdego wydania harnessu; historia rejestru; powiązanie tożsamości
z commitami; zatwierdzenia bramek; wyniki kwartalnych ćwiczeń.

## Przegląd
Co kwartał i po każdym incydencie spowodowanym przez agenta.
Podpisy: <CTO>, <lider bezpieczeństwa>.

Co psuje się w modelu operacyjnym agentów i jak to naprawić

Zespół platformowy staje się bramką review. Pull requesty produktu czekają na zgodę platformy. Naprawa: usuń zespół platformowy z CODEOWNERS produktu, przypomnij zasadę 5 z karty i przenieś ręczne sprawdzanie, które wykonywał, do hooka lub ewaluacji, za które odpowiada.

Wszyscy odpowiadają za reguły, więc nikt. Reguły repozytorium rozrastają się do setek linii i przeczą wspólnym skillom. Naprawa: jeden tech lead jest A dla każdego repozytorium; procedury przenieś z reguł do skilli, a przed scaleniem zmiany reguł uruchom ewaluacje harnessu. Zob. wspólne reguły agentów.

Pętla działa na tokenie człowieka. Gdy ta osoba odchodzi, pętla przestaje działać albo działa dalej z jej pełnym dostępem. Naprawa: wydaj tożsamość dla każdej pętli, zapisz ją w rejestrze, unieważnij token osobisty. Procedurę opisuje strona tożsamość agentów, poświadczenia i sekrety.

Zmiana modelu lub klienta wchodzi bez ewaluacji. Wartości domyślne zmieniają się pod tobą. 2026-09-26 kanał wydań stable Claude Code (2.1.274) nadal dawał licencjom (planom) Pro i Team Standard model Sonnet 5 jako domyślny, podczas gdy kanał latest od v2.1.280 domyślnie używał Opus 5.5. Dwa zespoły na różnych kanałach mogą pracować na różnych modelach pod tą samą polityką. Naprawa: właściciel platformy przypina kanał kluczem autoUpdatesChannel ("stable" albo "latest"), a modele kluczami availableModels i enforceAvailableModels w ustawieniach zarządzanych, i ponownie uruchamia ewaluacje harnessu przed ich zmianą; aktualne wartości domyślne znajdziesz w przeglądzie modeli.

Rejestr rozjeżdża się z rzeczywistością. Pojawiają się nowe zadania z harmonogramu bez wierszy w rejestrze. Naprawa: comiesięczna inwentaryzacja z drugiego promptu powyżej i stała zasada, że pętle spoza rejestru są wstrzymywane i nie dostają wyjątku za to, że działały wcześniej.

Zepsuty wspólny hook zatrzymuje wszystkich i nikt nie umie go wycofać. Naprawa: każde wydanie hooka jest wersjonowane, ma wskazanego właściciela wycofania i przećwiczony rollback; kwartalne ćwiczenie mierzy jego czas. Zob. governance wspólnych hooków. Gdy agent faktycznie spowoduje incydent, postmortem wskazuje wiersz RACI, który zawiódł; procedurę opisuje strona gdy incydent wywoła agent.

Pięć pytań, które zarząd może zadać CTO

1. Kto odpowiada za każdą pętlę, która działa bez człowieka w sesji, i gdzie to jest zapisane?
2. Które tożsamości agentów mogą pisać do produkcji lub danych klientów i jak szybko możemy je unieważnić?
3. Gdy zmieniamy model, skill lub politykę, jaki dowód mówi nam, że nie jest gorzej?
4. Kto może zatwierdzić zmianę produkcyjną i czy może to być ta sama osoba, która zleciła ją agentowi?
5. Czy nasza grupa platformowa przyspiesza review, czy dokłada kolejkę? Pokaż czas oczekiwania na review według klasy ryzyka.

Dokąd dalej z modelem operacyjnym

Ścieżka CTO dochodzi do tej strony po projekcie pilotażu i prowadzi dalej do ekonomii oprogramowania budowanego przez agentów, która wycenia każdy rozliczalny wiersz.

Zespół platformowy agentów Karta, backlog i poziomy usług dla harnessu prowadzonego jak produkt.

Governance i autonomia Klasy ryzyka, rozdział obowiązków i kontrakt dowodowy stojący za bramką produkcyjną.

Tożsamość agentów, poświadczenia i sekrety Tożsamości per agent, krótko żyjące tokeny i unieważnienie jako pierwszy krok reakcji na incydent.

Jedna mapa: drabina, cykl życia i stacje Poziomy, które rejestr autonomii zapisuje dla każdej pętli.