Kde do toho pořád vstupuje člověk
Agent, který vede sběr podkladů v BriefGate od začátku do konce, většinu času vypadá, že nikoho nepotřebuje. Zavolá define_intake s položkami, které projekt potřebuje, BriefGate klientovi pošle e-mail s odkazem na portál a agent se vrátí ke stavbě. O tom, co se změnilo, se dozví pollováním `get_intake_status` podle rozvrhu, který doporučila vlastní odpověď na define_intake, nebo registrací webhooku a reakcí na eventy místo dotazování. Upomínky odcházejí v jazyce klienta podle cadence, kterou agent zvolil, aniž by kdokoli ručně psal follow-up e-mail. Nic z toho člověka v smyčce nepotřebuje a je to tak navržené záměrně.
Pár momentů v tom samém toku je jiných. Některé z nich BriefGate API klíči nedovolí udělat vůbec, bez ohledu na scope. Jiné technicky dovolí, ale agentovi dá dost provazu na to, aby dobré použití byl úsudek, ne kontrola oprávnění. Obojí je záměr — ne chybějící funkce, ale tvar nástroje postaveného pro workflow, kde na druhém konci odkazu na portál stojí klientovy peníze, přístupy nebo dobré jméno.
Přečtení přístupu
Položka typu secret — heslo do CMS, API klíč, přihlašovací údaje k hostingu — se zašifruje ve chvíli, kdy dorazí na server BriefGate, ještě než se dostane do databáze: HTTPS dovnitř, pak libsodium sealed box pod klíčem, který existuje jen v prostředí serveru. To je šifrování at-rest s dešifrováním na straně serveru — ne end-to-end, ne zero-knowledge. Server BriefGate ji umí přečíst zpátky, a taky to udělá — přesně jednou.
Tohle „jednou" je skutečný checkpoint, a není čistě lidský — je to otázka scope. API klíč agenta umí odhalit každý secret na sběru podkladů přes `get_intake_results`, ale jen se scope secrets:read nebo admin; výchozí scope intakes:write, který agent potřebuje na všechno ostatní, ho neobsahuje. Jestli agent vůbec může přečíst heslo, se rozhoduje ve chvíli, kdy mu někdo dá klíč s tímto scope — nebo mu ho nedá. Druhá cesta ke stejné nešifrované hodnotě, kliknutí na Reveal v dashboardu, je ještě užší: potřebuje živou session a smí ji použít jen owner účtu — člen týmu dostane 403 forbidden. Kdo se tam dostane první, agent nebo owner, vyhrává jednorázové odhalení; druhá strana se dozví, že už bylo zobrazeno. Přečíst si to „jen pro kontrolu" nejde.
Skutečný lidský krok tedy není přečtení přístupu — je to rozhodnutí, udělané jednou, které klíče na to mají právo.
Potvrzení toho, co agent smí jen navrhnout
Většinu položek na sběru podkladů zodpovídá klient. Menší kategorie, položky s "assignee": "owner", se do klientova portálu vůbec nedostane — jsou to vlastní úkoly agenta nebo ownera, odškrtávané přes POST /v1/intakes/:id/items/:key/done. V téhle kategorii je jeden typ, kterému BriefGate říká decision: položka select nebo multiselect přiřazená ownerovi, ke které agent smí připojit vlastní navrhovanou odpověď a zdůvodnění. Co agent udělat nemůže, je ji potvrdit. POST /v1/intakes/:id/items/:key/answer je jen pro session a dokumentace říká otevřeně proč: přijmout to volání od API klíče „by agentovi umožnilo potvrdit vlastní návrh a mít výsledek zapsaný jako decided_by: owner — přesně tomu má oddělení návrhu od odpovědi zabránit." Čtecí strana ten šev ukazuje otevřeně: každá decision položka nese proposed_value, proposed_rationale a decided_by: "agent"|"owner".
Je to úzká funkce, ale nejčistší příklad obecného pravidla: agent umí udělat analýzu a předat doporučení se zdůvodněním. Nemá ale dovoleno to doporučení sám i podepsat.
Vznést námitku k odevzdané položce, nebo ji nechat být
V BriefGate nikde neexistuje tlačítko „Schválit" — ani v dashboardu, ani jako MCP nástroj, ani jako REST endpoint. Odevzdaná položka se stane approved jedním ze dvou způsobů: buď někdo zavolá `request_revision` s poznámkou, nebo nikdo nic neudělá a položka se po auto_approve_hours (výchozí 72 hodin, nastavitelné per sběr podkladů) schválí sama. Mlčení se počítá jako přijetí; jediný aktivní krok, který existuje, je vznést námitku.
Nic agentovi technicky nebrání zavolat `request_revision` sám — je to jeden z 13 MCP nástrojů a doporučený postup přímo říká použít ho „místo toho, abyste se klienta ptali znovu mimo BriefGate." Nejde tedy o to, že by API agenta odmítalo; jde o to, že dobré použití nástroje potřebuje něco, co API nedokáže ověřit. Jestli logo, které je technicky přítomné — správný formát, správné rozměry, včas — skutečně reprezentuje klientovu značku, BriefGate ověřit neumí: definice položky je jediný zdroj pravdy, nic se neodvozuje z obsahu, takže systém potvrdí, že je položka použitelná podle vlastní definice, a nic o tom, jestli je dobrá. A request_revision odešle skutečný e-mail, zformulovaný tím, kdo ho zavolal, skutečnému klientovi, jménem ownera účtu, bez jakéhokoli potvrzovacího kroku mezi tím. Úsudek, který API strukturálně udělat nemůže, a dopadá do akce bez vrácení zpět — tahle kombinace je důvod, proč se vyplatí lidské oči napřed, i když si o ně nástroj sám neřekne.
Rozhodnutí, o co vlastně požádat
V BriefGate nic neověřuje, jestli je seznam položek, který agent pošle do define_intake, ten správný. API ověří tvar každé jednotlivé položky — pattern, kterému musí odpovídat hodnota text, min_width, který musí splnit obrázek — ale nemá žádný názor na to, jestli klíče a labely dohromady dávají to, co projekt potřebuje. Agent, který pracuje z napůl zapamatované šablony místo zadání, které má před sebou, dostane naprosto validní sběr podkladů, který klienta upomíná kvůli věcem, o které nikdo nežádal, a přitom mu unikne jediný přístup, bez kterého se projekt nepohne dál. Přesně proto dokumentace k MCP sama začíná tím, kdy BriefGate nepoužít: přeskočte ho, když je odpověď už v repu, už v konverzaci, nebo patří člověku, se kterým právě mluvíte — portál a jeho upomínky jsou pro lidi, kteří v konverzaci nejsou. Trefit se do správného seznamu je čistě otázka úsudku; BriefGate vynucuje jen to, že cokoli se zeptáte, bude formálně v pořádku.
Když klient zmlkne
Chase engine upomíná klienta podle rozvrhu, v jeho jazyce, v rámci jeho pracovní doby, dokud to dovolí max_reminders — výchozí tři pokusy, nastavitelné až na tisíc nebo úplně bez limitu. Když se ten limit vyčerpá bez dokončeného sběru podkladů, BriefGate sám přestane, sběr podkladů označí jako stalled a vyšle intake.stalled se seznamem toho, co ještě chybí. To je hranice toho, co automatizované upomínání zvládne: rozvrh proběhl a klient přesto neodpověděl.
Agent, kterému přijde intake.stalled, na tom není zaseknutý — může přes update_intake zvýšit max_reminders nebo zkrátit cadenci, nebo rovnou poslat send_chase mimo rozvrh. Co udělat nemůže, je cokoli, pro co BriefGate nestaví kanál: zvednout telefon, oslovit klienta tam, kam sběr podkladů nikdy nešel, nebo posoudit, že tenhle konkrétní projekt má pokračovat i bez chybějící položky. intake.stalled je záměrně event určený pro člověka — doporučení k jeho zpracování zní „zvažte oslovení klienta jiným způsobem." BriefGate předá přesně tu informaci, kterou je potřeba k takovému rozhodnutí, a tam končí.
Co má naopak zůstat na agentovi
Nic z tohohle netvrdí, že BriefGate potřebuje člověka v každém kroku — je to přesně naopak. Definovat sběr podkladů ze zadání projektu, sledovat jeho stav bez hlídání inboxu, stahovat otypované výsledky ve chvíli, kdy jsou hotové, a rovnou je zapojit do stavby: to je celý důvod, proč BriefGate existuje jako MCP server, a ne jen jako dashboard. Checkpointy popsané výše jsou úzké záměrně. Sedí přesně tam, kde je špatné rozhodnutí drahé a těžko vratné — přístup přečtený nesprávným volajícím, rozhodnutí, které si agent sám potvrdil, stručná poznámka, která dorazí do klientova inboxu bez druhého pohledu, sběr podkladů zaseknutý proto, že žádal o špatnou věc. Všude jinde agent dál staví a klient si vyplňuje věci ve svém vlastním čase.