Одобрение при AI агенти: гоненето на документи се възлага, преценката остава

Счетоводителят не може да започне данъчната декларация, докато клиентът не изпрати извлеченията си. Адвокатът не може да поеме случай без документ за самоличност, а застрахователният брокер не може да сключи застраховка, докато формулярите не се върнат попълнени. Работата стои и чака документите. Времето на специалиста отива в това да ги иска, да чака, да ги гони и накрая да открие, че един от файловете е грешен документ или снимка, която никой не може да разчете.

Никой не обича тази работа, а и тя следва предвидими правила, затова изглежда като очевидна задача за AI агент. Но тя означава и да се пишат имейли до реални клиенти от името на специалиста, и да се преценява дали изпратеното от тях е достатъчно добро. Статията на Brand Design Ltd. Какво е агентна търговия? описва платежния вариант на този проблем с едно изречение: „Според платежния метод и политиката одобрението може да е предварително в тесни граници или да бъде поискано при самото плащане.“ Без парите въпросът пак стои.

Този текст проследява една заявка за събиране на документи от клиенти и на всяка стъпка пита кой действа, кой решава и къде човекът в процеса трябва да каже „да“. Примерът е DokuTrak, продуктът, който разработвам, и неговият конектор с отворен код за MCP (Model Context Protocol), протокола, чрез който AI асистентът достига до софтуер извън чата.

Основни изводи

• Разпределете всяка стъпка според последствията ѝ: стига ли до човек и може ли да се отмени? Това решава дали стъпката се изпълнява сама, дали следва предварително зададени граници, или чака „да“ всеки път, когато действа.
• Това, че инструкцията изглежда пълна, не значи, че е одобрена.
• Някои решения никога не бива да се делегират. Сървърът трябва да налага това, каквото и да е казано на агента, и да записва отказаните опити.

Процесът и конекторът

Специалистът изпраща заявка със списък на документите, които са му нужни, а клиентът ги качва през един защитен линк, без регистрация. Ако клиентът замълчи, напомнянията тръгват автоматично, по подразбиране на 2-рия, 5-ия, 10-ия и 14-ия ден след изпращането. Графикът може да се промени за цялото работно пространство, за шаблон или за отделна заявка.

Работното пространство може да включи и незадължителна първична проверка. Тя сигнализира за файл, който не е поисканият документ или се чете твърде трудно. Сигналът е съвет, а не присъда. Всеки файл приема специалистът, а когато отхвърли файл от таблото за управление, клиентът получава имейл „Action needed“ с молба да го качи отново.

MCP конекторът дава достъп до четири инструмента:

• create_request създава заявката и я изпраща на клиента по имейл, и двете с едно извикване;
• get_request казва на агента какво е пристигнало, какво е отхвърлено и докъде са стигнали напомнянията;
• download_documents връща всичко получено, архивирано в ZIP;
• request_replacement, след като даден файл е отхвърлен, пуска отново напомнянията за тази заявка.

Конекторът работи локално в Claude Desktop или Claude Code с ключ, който специалистът издава от приложението на DokuTrak. Уеб версията, claude.ai, не се поддържа в това издание.

Една заявка, стъпка по стъпка

Почти целият замисъл е в два от редовете. Изпращането е единствената стъпка, при която действието на агента стига до човек и не може да бъде върнато, затова то е единственото действие на агента, направено да чака „да“ всеки път. Приемането или отхвърлянето на файл е стъпката, при която решението тежи повече от действието, затова агентът никога не я извършва.

Редът за заместващия файл може да изненада. След като специалистът е отхвърлил файл, агентът може да извика request_replacement без обобщение и без наша стъпка за потвърждение: извикването връща заявката в графика на напомнянията и не се свързва с никого. Имейлът за отхвърлянето вече е уведомил клиента, а предварително одобрените напомняния поемат заявката отново, ако той не реагира. Всяко съобщение, което агентът добави, остава в одитната следа и никога не се изпраща.

Къде минава всяка граница

Статията на Brand Design Ltd. описва два начина за одобряване на плащане: предварително в тесни граници или при самото плащане. Добавете стъпките, които агентът може да прави сам, и тези, които никога не може да прави, и се получават четири вида граници.

Агентът действа сам

Четенето на статуса на заявка и изтеглянето на файловете ѝ не променят нищо в DokuTrak и не се свързват с никого. Изтеглянето все пак прехвърля файловете на клиента в приложението на агента, така че специалистът решава къде то ще ги изпрати. request_replacement също спада тук по причините, описани по-горе. Приложението на агента пак може да поиска разрешение по свои правила: в нашата сесия Claude Desktop например спря, за да попита, дори преди проверка на статуса. Това идва от настройките на приложението и не разчитаме нито да пита, нито да не пита.

Одобрено предварително, в граници

Тук са напомнянията. Специалистът задава графика веднъж или оставя този по подразбиране, а софтуерът го следва, без да пита отново; специалистът пак може да спре заявката. Това е най-близо до „предварително в тесни граници“: разрешение, дадено веднъж, за определена цел, което не се разширява тихомълком.

„Да“ в момента на изпращане

Това е изпращането на заявка до реален човек. Изпратената заявка не може да се върне, а всяка заявка може да отиде до различен клиент с различен списък, така че одобрението на предишната не казва нищо за тази. Стъпката е направена така, че да пита всеки път: описанието изисква обобщение при всяко извикване, независимо от настройките за разрешения в приложението.

Никога, каквото и да е казано на агента

Тук са приемането или отхвърлянето на документ, а също фактурирането, настройките на работното пространство и API ключовете. Сървърът ги отказва на всеки агентски ключ: те са извън списъка с разрешения на ключа, затова опит да се приеме или отхвърли файл с агентски ключ завършва с agent-endpoint-not-allowed грешка и се записва като auth.failure събитие в одитния журнал. Зад тази защита стои и втора проверка: за одобряване или отхвърляне на файл е нужна сесия с вход в профила, затова всеки друг API ключ получава approval-requires-human грешка, която също се записва.

Ограничено и проверимо отвъд плащанията

Едно от заглавията в статията гласи „Правото за плащане трябва да е ограничено и проверимо“, а след него се добавя: „По-сигурният модел обвързва разрешението с търговец, максимална сума, валута и цел.“ При събирането на документи няма сума и валута, но принципът важи и тук. Агентският ключ достига само до списък с разрешени endpoint-и. Отнемането му в приложението действа още при следващото извикване. Отказаните опити, било за приемане на файл, било за достъп до endpoint извън списъка, се записват в одитния журнал, така че записът показва и какво е опитал агентът, и какво е направил.

Как човекът остава в процеса на ниво MCP инструмент

Научихме това от тест, който се обърка. На 15 септември, при вътрешен тест, инструкцията беше да се поиска от клиент документ за самоличност до 30 септември. Само за един ход в разговора вече беше изпратена реална заявка, без никой да я е видял преди това. Моделът имаше получател, документ и дата и прие това за разрешение. Но пълно не е същото като одобрено: никой още не беше погледнал самата заявка и не се беше съгласил с нея.

Сега конекторът пита на две нива.

Първото ниво е описанието на инструмента, което моделът чете, преди да реши дали и как да го извика. Описанието на create_request, инструмента, който изпраща заявки, изисква обобщение преди извикването: получателят, срокът, всеки документ така, както ще го прочете клиентът, и съобщението, ако има такова, „дори когато заявката вече изглежда пълна“. Това уточнение стои там заради 15 септември.

Второто ниво са анотациите на инструмента: етикети, които конекторът обявява, за да може приложението на агента да прецени колко внимателно да подходи. create_request е маркиран с destructiveHint: true, защото имейл, който не може да се върне, не е безобидно добавяне, и носи специфичен за Anthropic _meta ключ, anthropic/requiresUserInteraction. Claude Desktop иска потвърждение преди инструмент, маркиран като деструктивен, а Claude Code, като прочете този ключ, пита при всяко извикване, дори при включено автоматично одобрение.

Ето как инструментът го декларира, съкратено от изходния код на конектора (TypeScript, с MCP SDK):

server.registerTool('create_request', {
  title: 'Create and send a Document Request',
  description: CREATE_REQUEST_DESCRIPTION, // requires the recap, "even when the request already looks complete"
  inputSchema: { /* recipient_email, deadline, documents, message… */ },
  // An email to a real client cannot be recalled, so the app asks on every call
  // rather than trusting the description alone.
  annotations: { readOnlyHint: false, destructiveHint: true, idempotentHint: false, openWorldHint: true },
  _meta: { 'anthropic/requiresUserInteraction': true },
}, handler);

Инструментът само за четене get_request е деклариран с readOnlyHint: true и destructiveHint: false, без _meta ключ: разликата между двата инструмента е записана, а не е оставена на преценката на модела.

Защо и двете? Ако моделът пропусне обобщението, приложението пак спира, преди имейлът да тръгне. Но сам по себе си прозорецът показва заглавие на инструмента, без получателя, срока или документите, така че човек, който натиска Allow, може да не знае какво разрешава. Именно в обобщението той може да забележи грешен адрес.

Отхвърлихме два други варианта. Опашка с чернови в таблото за управление би била безопасна, но би превърнала всяка заявка на агента във втора работа за специалиста, а това обезсмисля делегирането. Бърз път за „очевидно пълни“ заявки пък би зависел от това как самият модел разбира „пълно“, а точно това се обърка на 15 септември.

Какво този подход още не решава

Това „да“ се казва в приложението на агента и нашият сървър никога не научава за него. За сървъра одобрената и неодобрената заявка изглеждат еднакво: същият ключ, същите данни. Ако приложението пренебрегне анотациите, между модела и изпращането остава само описанието.

Агентът избира и кой получава заявката: recipient_email е това, което той напише, а нашият сървър не може да различи верен адрес от грешен, който случайно съществува. Този риск се покрива от обобщението и от прозореца за потвърждение, но само обобщението слага адреса пред очите на специалиста и това е основната причина да не се отказваме от него.

Пет въпроса за всеки бизнес, който позволява на агенти да действат за клиентите му

Независимо дали правите конектор, или решавате какво може да прави външен агент в собствените ви системи, ето въпросите, които бихме задали за всяко действие:

1. Стига ли до човек? Ако стига, действието не е самостоятелно.
2. Може ли да се отмени? Ако не, за него се пита всеки път, преди да се изпълни.
3. Какво вижда човекът, преди да каже „да“? Името на инструмента не стига. Покажете получателя и съдържанието.
4. Какво е одобрено предварително и в какви граници? Запишете границите, за да не могат да се разширят, без никой да забележи.
5. Какво записва одитната следа? Включете и отказите. Най-много трябва да виждате опитите, които агентът е направил и за които е получил отказ.

Често задавани въпроси

Първоизточници

• Спецификация на Model Context Protocol, раздел Tools (версия 2026-07-28)
• dokutrak-mcp, конекторът с отворен код, описан тук (описанията на инструментите, анотациите и раздела „What the connector cannot do“)
• Brand Design Ltd., Какво е агентна търговия? Определение, плащания и реален тест