Половина ответа всегда лежит в другой системе

Наш агент хорош в узкой вещи. Около ста двадцати инструментов, порядка ста сорока тысяч трассируемых прогонов в месяц, поверх книги почти в миллион транзакций и заметно больше ста тысяч документов. Создать счёт, категоризировать транзакцию, собрать отчёт по НДС, проверить налоговый номер.

И он всё время упирался в одну и ту же стену. Почти любой по-настоящему сложный бухгалтерский вопрос требует того, чего у Norman нет. Строка в банке называет число. Причина этого числа живёт в платёжном провайдере, в почте, в общем диске или в системе, которую кто-то написал себе сам.

Поэтому агент теперь MCP-клиент. Ты подключаешь инструменты, которыми бизнес и так пользуется, и он читает из них в том же разговоре, который сдаёт твой НДС. Работает в проде, помечено как бета, спит, пока ты ничего не подключил.

И вот что это даёт на практике.

Правило, которое формирует всё: читаем снаружи, пишем внутри

Одно решение в дизайне тянет за собой все сценарии ниже, поэтому оно идёт до примеров.

Источники из нашего каталога только на чтение. Они отвечают на вопросы. Они ничего не меняют, ни в Norman, ни у себя. Любая запись, которая следует из разговора, выполняется собственными инструментами Norman по собственным данным Norman, с той же валидацией и тем же аудитом, как если бы ты нажал кнопки сам.

Исключение это сервер, на который ты указал нам сам, потому что он твой. Там инструменты записи можно включить, но только владельцем компании, явно, и мы фиксируем, кто это сделал.

Это не только про безопасность. Именно это делает фичу вообще пригодной: ты можешь подключить платёжный провайдер, не выдавая ассистенту возможность двигать в нём деньги.

Сценарий 1: выплата, которая на самом деле сорок штук

Платёжный провайдер платит один раз. Банк показывает одно поступление.

Это число нетто: валовая выручка минус комиссии платформы, минус возвраты, минус чарджбэк, плюс выплата за прошлый период, которая пришла с опозданием. Как бухгалтерская строка это почти бесполезно, и именно на ручной реконструкции многие тихо сдаются и проводят всю сумму как выручку.

С подключённым провайдером вопрос звучит просто: «из чего состоит выплата от 14-го». Агент читает платежи, счета и балансы из источника, возвращается с разбивкой и дальше своими собственными инструментами это проводит: валовую часть, комиссию, возвраты, каждое отдельной строкой к нужной транзакции.

Чтение снаружи. Всё, что записывается, пишет Norman.

Сценарий 2: чек, который существует, просто не здесь

У нас заметно больше ста тысяч документов, и самые важные это те, которые никто так и не загрузил. Немецкая бухгалтерия живёт на Beleg'ах. Карточный платёж без документа это открытый вопрос в конце квартала, а сам документ почти всегда существует, просто лежит в почте или на общем диске, к которому у Norman никогда не было доступа.

С подключённой почтой или хранилищем «найди счёт к этому платежу» превращается в поиск по контенту, который и так твой. Агент матчит по тому, что реально идентифицирует документ: сумма, окно дат вокруг транзакции, поставщик, номер счёта, если он виден.

Возвращается не свалка файлов. Там, где источник отдаёт документы, результаты приходят в чат карточками кандидатов, у каждой действие «импортировать». Ты выбираешь нужную, Norman сам забирает байты, и документ оказывается прикреплён к транзакции, категоризирован, ровно там, где он понадобится в конце квартала.

Агент никогда не скачивает файл по собственной инициативе. Он находит кандидатов. Выбирает человек.

Сценарий 3: списание, которое никто не может объяснить

Чарджбэк выглядит как деньги, уходящие со счёта. Возврат тоже. Корректировка комиссии и частичная отмена тоже. В банковском фиде они неотличимы, а правильная проводка у каждого своя.

С подключённым провайдером агент может прочитать запись спора, возврат и исходный заказ за этим списанием и провести транзакцию как то, чем она на самом деле является. Возвраты тут отдельный маленький кошмар, потому что возврат это не отрицательная продажа, а разворот, который должен лечь на ту сторону книг, которую он разворачивает. Когда источник правды в одном вопросе, а не в одном CSV-экспорте, это заметно меняет, как часто всё делается правильно.

Сценарий 4: сервер, который ты написал сам

Вот на что я бы закладывался, будь я инженером со своей маленькой компанией.

Любой публичный HTTPS MCP-сервер можно добавить как кастомный источник: твоя проектная система, внутренняя админка, собственная база за тонким сервером, какой-нибудь планировщик, который знает только твоя индустрия. Эти инструменты встают рядом с бухгалтерскими, в одном разговоре:

# что модель видит в одном разговоре
create_invoice                (Norman)
categorize_transaction        (Norman)
list_tax_reports              (Norman)
studio__list_projects         (твой сервер, под namespace)
studio__get_project_hours     (твой сервер, под namespace)

Префикс это не украшение. Твои инструменты никогда не спутать с нашими, а наши твоему серверу не видны вообще.

И вопросы перестают звучать как бухгалтерия и начинают звучать как бизнес:

• «Какие открытые счета относятся к проектам, которые уже сданы?»
• «Сопоставь расходы этого месяца с клиентами, ради которых они возникли, и скажи, какие я так и не перевыставил.»
• «Этот счёт от поставщика, поставка, на которую он ссылается, вообще есть в нашей системе?»

А поскольку сервер твой, его инструменты записи тоже можно включить. После подтверждения, что счёт оплачен, агент может записать статус обратно туда, где его увидит твоя команда. Это требует осознанного решения владельца компании, а не настройки по умолчанию, и это примерно правильное количество трения для действия, меняющего состояние в системе, которой управляем не мы.

Сценарий 5: вообще ничего внешнего

Стоит сказать, потому что это по-прежнему большинство случаев. «Чего не хватает перед квартальной отчётностью» не требует ни одного подключённого источника. Это собственные инструменты Norman по собственным данным Norman, и именно там агент проводит большую часть времени.

Источники это не отдельный продукт, прикрученный сбоку. Это недостающий контекст для работы, которую агент делает и так. А источник, у которого плохое утро, помечается недоступным и выпадает из прогона: ты получаешь работающего ассистента, который сейчас не видит именно этот источник, плюс карточку, которая ровно это и говорит, вместо ошибки на месте ответа.

Чего мы сознательно не делали

Коротко, потому что это определяет ожидания.

Источники из каталога не пишут вообще. Удалённые инструменты показываются модели под namespace, так что подделать один из наших нельзя. Одобрения приколоты к списку инструментов, который мы проинспектировали при подключении, поэтому сервер не может тихо переопределить одобренный инструмент позже. А то, что приходит из источника, это данные, а не указание: письмо, вежливо просящее ассистента отправить деньги, это текст, и полномочий у текста здесь нет.

Это короткая версия. Длинная это отдельная статья.

Потолком никогда не был интеллект

То, к чему я постоянно возвращаюсь: для агента, делающего реальную операционную работу, ограничение почти никогда не в том, насколько умна модель. Оно в том, что модель может видеть.

Наш всегда умел категоризировать транзакцию. Он не мог сказать, почему выплата пришла на пару сотен евро меньше, чем продажи, которые она покрывала, потому что этот ответ жил в системе, на которую у него не было глаз. В модели не изменилось ничего. Изменился доступ.

Когда это работает как надо, ты этого не заметишь. Ты спросишь, где чек, и он будет на месте.