--- title: "ИИ-Напарник" description: "Что такое ИИ-Напарник, как он устроен с точки зрения сотрудника, как становится единым окном к корпоративной среде и где проходит граница его ответственности" sidebar: order: 3 label: "02. ИИ-напарник" --- import { Card, CardGrid, Steps, Tabs, TabItem, Badge } from '@astrojs/starlight/components'; Здесь — ИИ-Напарник глазами сотрудника: что это за сущность, как он выглядит в рабочем дне, какие задачи берёт на себя и где останавливается. ## Из этого раздела вы узнаете - какие три свойства делают Напарника Напарником, а не чат-ботом или copilot'ом внутри приложения - как он становится единым окном к корпоративной среде и где проходит граница его проактивности - что такое персональный контекст сотрудника и как сотрудник настраивает его через скиллы - как Напарник координирует функциональных агентов и растёт по уровням зрелости - где проходит граница его ответственности (Tier-модель) и какими метриками измерять его ценность --- ## Коротко ИИ-Напарник работает как персональный агент конкретного сотрудника. У каждого менеджера свой Напарник, и он живёт в том же мессенджере, где менеджер уже общается с коллегами и поставщиками. Напарник знает приоритеты и историю решений своего человека, имеет доступ к корпоративным данным и системам в рамках его прав, координирует функциональных агентов и видит следующий шаг. С точки зрения сотрудника всё проще, чем звучит. У него появляется один собеседник, к которому можно прийти со словами *«почему упала молочка в регионе Х»* или *«подготовь к завтрашней встрече по KPI категории»*, и в ответ получить готовый разбор с рекомендацией. Под капотом для этого может задействоваться несколько разных агентов и систем, но менеджеру это знать не обязательно. :::tip[Главный тезис документа] Напарник работает как персональный собеседник сотрудника и единое окно к корпоративной среде. Он знает контекст и историю решений своего человека и вместе с ответом предлагает следующий шаг, подключая при необходимости [функциональных агентов](/03-agents); критичные решения остаются за человеком. ::: --- ## Кто такой ИИ-Напарник ИИ-Напарник работает как персональный ИИ-агент сотрудника. У Напарника есть три свойства, и важны они все вместе. Если убрать любое, остаётся либо чат-бот, либо copilot внутри одного приложения, либо функциональный агент из [третьей эпохи](/01-vision/#эпоха-3-функциональные-ии-агенты). Напарник закреплён за конкретным сотрудником. Он знает его роль, портфель ответственности, KPI, активные переговоры, стиль коммуникации и историю решений. При этом Напарник менеджера A не имеет доступа к данным менеджера B, кроме случаев явной коммуникации между сотрудниками. Один интерфейс ко всей корпоративной среде. Сотрудник уже не выбирает, к какой системе или агенту обратиться. Он формулирует задачу обычным языком, а Напарник сам определяет, кого подключить и в каком порядке. Вместе с ответом Напарник предлагает следующий шаг и критический анализ. У него нет своей повестки внутри компании, поэтому он может прямо сказать *«здесь цифры не сходятся»* или *«в прошлый раз похожее решение просадило маржу»*. Здесь же видна разница с ассистентами внутри отдельных приложений. Copilot в BI помогает работать с BI, copilot в почте помогает с почтой, а Напарник работает с ситуацией сотрудника целиком и обращается к корпоративным системам как к инструментам под конкретную задачу. --- ## ИИ-Напарник как единое окно ### Один интерфейс вместо десятка Категорийный менеджер обычно держит в голове карту систем. Ему приходится помнить, где лежат продажи и остатки, где ведутся промо и переговоры, в какой системе хранятся регламенты, а где висят задачи. Часть из этих систем дублирует друг друга, часть конфликтует, часть периодически ломается. Само переключение между ними занимает заметную часть рабочего времени, и менеджер регулярно теряет контекст. Ситуация знакомая. Зашёл в один отчёт за цифрой, отвлёкся на письмо, к цифре уже не вернулся, потому что письмо породило ещё три задачи. Напарник убирает эту карту из головы сотрудника. Например, менеджер пишет в мессенджер *«дай продажи по молочке за март по регионам»* и тут же получает ответ. За этим ответом могут стоять [Text2SQL-агент](/03-agents/#5-text2sql), обращение к DWH, проверка через агента базы знаний, но всё это происходит на стороне Напарника. Точно так же менеджер спрашивает *«что у нас по поставщику X»*, *«есть ли свободный час с Ивановым на четверг»*, *«найди регламент по делистингу»*. То есть везде остаётся один и тот же канал и обычный язык. Базовый канал коммуникации устроен как [корпоративный мессенджер](/06-integrations/#корпоративный-мессенджер) с мобильной и десктопной версиями. Веб-интерфейс и дашборды появляются позже, под конкретные сценарии. Голосовой ассистент на переговорах остаётся отдельной историей, она описана в [открытых вопросах 04-usecases](/04-usecases/#открытые-вопросы). ### Проактивность Часть полезной работы Напарник делает сам, без запроса. Это возможно, потому что у него есть расписание сотрудника, понимание его приоритетов и доступ к потокам данных. Утром он готовит брифинг, перед встречей собирает досье, по сработавшему алерту приносит готовый разбор, а коллеге сам напоминает про обещанный к среде расчёт. Как устроен этот проактивный цикл на уровне платформы, разобрано в [05-architecture, раздел «Проактивный цикл»](/05-architecture/#проактивный-цикл). Проактивность сотрудник обязательно настраивает под себя. Менеджер задаёт пороги чувствительности (например, *«не дёргай, если отклонение меньше 5%»*) и определяет приоритеты по категориям, поставщикам, SKU. Если этого не сделать, Напарник довольно быстро превращается в источник шума, и им перестают пользоваться. ### Рабочий день, в котором Напарник работает сам Менеджер делает свою работу как раньше, а Напарник параллельно с ним делает то, что иначе пришлось бы держать в голове или откладывать на потом. 1. До прихода менеджера, к 9:00. Утром в чате уже лежит брифинг с приоритетными задачами дня. По двум критичным поставкам Напарник за ночь сам написал логистам и собрал у них предварительные ответы. Менеджер видит сводку и сразу понимает, чем заниматься первым, без обхода десятка систем. 2. Около 10:30 в одной из категорий случается резкий провал по конкретным SKU. Напарник не пересылает менеджеру голый алерт. Он сам прогоняет первичный разбор, отвергает очевидные гипотезы и приходит с диагностикой и тремя вариантами действий. Менеджер выбирает один, остальное Напарник доводит сам. 3. За час до встречи, к 13:00. В календаре стоят переговоры с поставщиком в 14:00. Никто Напарника не дёргает, но он сам видит встречу и заранее готовит досье. Туда попадают индексы цен, история уступок, статусы SLA и доля SKU в категории. К менеджеру досье приходит до того, как тот успевает его попросить. 4. В течение дня Напарник контролирует договорённости: на прошлой неделе коллега из соседнего отдела обещал расчёт к среде. Сегодня среда. Напарник сам напоминает Напарнику коллеги, получает обновлённый срок и приносит менеджеру результат. Менеджеру не пришлось превращаться в контролёра. 5. После окончания рабочего дня менеджер ушёл, а Напарник продолжает мониторить метрики и события. Если случается срыв доставки или жалоба от партнёра, Напарник классифицирует событие по согласованным правилам. Срочное уведомление уходит менеджеру в мессенджер сразу же. Менее срочное копится в утренний брифинг следующего дня. Здесь видна проактивная половина работы. Реактивная половина (то есть случаи, когда менеджер сам приходит с вопросом или поручением), описана ниже в разделе «[Как выглядит диалог с Напарником](#как-выглядит-диалог-с-напарником)». --- ## Как выглядит диалог с Напарником Выше в разделе «Рабочий день» показано, что Напарник делает сам. Дальше четыре коротких диалога. Они показывают вторую половину работы, ту, где менеджер сам приходит к Напарнику с вопросом или поручением. Это не сценарии бизнес-использования, они полностью разворачиваются в [04-usecases](/04-usecases). Здесь интересна форма реплик. **Менеджер.** *«Почему упала молочка в Сибири за март?»* **Напарник.** *«Главная причина в росте закупочных цен Danone на 8% и недопоставках трёх SKU из-за SLA 91% при норме 95%. Совокупный эффект на категорию -9,2%. Доказательная база и отвергнутые гипотезы лежат в карточке ниже. Через три дня встреча с Danone, могу подготовить досье»*. **Менеджер.** *«Подготовь. И добавь в разбор демпинг конкурента, мы это видели в марте»*. **Напарник.** *«Принял. Учту в следующих похожих разборах»*. **Менеджер.** *«Saverio просит +5% к закупочной цене, встреча завтра в 14:00»*. **Напарник.** *«Готовлю досье. Аргументы против повышения такие. Индекс цен на сырьё -3% за квартал, недопоставки 17 млн ₽ из-за SLA 87% при норме 95%, на встрече в сентябре поставщик уступил при угрозе делистинга, доля SKU в категории 34%. Рекомендую начать с SLA, это самая сильная позиция. Слайды нужны?»* **Менеджер.** *«Собери у маркетинга и логистики статусы по летнему промо»*. **Напарник.** *«Отправил запросы Напарникам Петровой и Иванова. Жду ответы, обычно собирается за 20–40 минут. Пришлю сводку, как только всё валидируют»*. *Через 35 минут.* **Напарник.** *«Сводка готова. По двум промо из четырёх есть отставание от плана с указанием причин. Отдельно отметил, что у Иванова открытый вопрос по бюджету, ждёт твоего решения»*. **Менеджер.** *«Поставь встречу с Петровой на этой неделе на 30 минут, обсудить промо в кондитерке»*. **Напарник.** *«Договорился с её Напарником. Свободный слот пришёлся на четверг 11:30. Поставил, повестку добавил. К началу встречи пришлю короткий бриф, в нём будет, что у Петровой по этой категории сейчас и какие открытые вопросы остались с прошлого раза»*. В реальном разговоре будет больше уточнений, поправок и переключений, здесь это убрано для краткости. Зато хорошо видна форма реплики. Везде всё тот же единый канал из раздела «[ИИ-Напарник как единое окно](#ии-напарник-как-единое-окно)», а в ответ приходит разбор вместе с предложением следующего шага. --- ## Персональный контекст пользователя Напарник полезен ровно в той мере, в какой он понимает контекст конкретного сотрудника. Подробное устройство памяти и состав каждого слоя описаны в [05-architecture, раздел «Память и контекст»](/05-architecture/#память-и-контекст). Здесь интересно только то, что из этого видит сам сотрудник. Контекст растёт со временем. Чем дольше Напарник работает с менеджером, тем точнее он попадает в его задачи. Он запоминает, как сотрудник формулирует поручения, какой длины ответы любит, какие аргументы у него обычно срабатывают на переговорах, как он реагировал в похожих ситуациях раньше. За счёт этого «Напарник, которого включили вчера» сильно отличается от «Напарника, который работает с менеджером полгода». Это свойство сотрудник замечает в работе сам. Напарник также ведёт профили контрагентов и коллег, с которыми работает менеджер. Здесь профиль одного и того же поставщика у разных менеджеров будет разным, потому что они наблюдают его в своих переговорах. Архитектурное устройство профилей и правила обмена ими между Напарниками описаны в [05-architecture, раздел «Профили контрагентов»](/05-architecture/#профили-контрагентов). ### Скиллы как пользовательская настройка Часть персонализации сотрудник задаёт сам через скиллы. Это короткие декларативные инструкции о том, как Напарник должен работать с этим человеком. Несколько типичных формулировок. - *«Отчёты собирай в формате с разрезом до и после промо»*. - *«По поставщикам категории X сразу добавляй долю SKU в категории»*. - *«При отклонениях меньше 5% не дёргай»*. - *«При подготовке к комитету сразу добавляй разрез по конкуренту»*. Скиллы отличаются от того, что Напарник запоминает сам, тем, что в них живут правила, а не накопленная история решений. Сотрудник может добавить, отключить или поправить скилл в любой момент. Платформенный механизм скиллов разобран в [05-architecture, раздел «Скиллы»](/05-architecture/#скиллы). --- ## Координация функциональных агентов Сам Напарник как правило не делает факторный анализ, не пишет SQL и не ищет по регламентам. Эту работу он делегирует специализированным функциональным агентам. Примеры таких агентов в [03-agents, раздел «Классификация функциональных агентов»](/03-agents/#классификация-функциональных-агентов), а здесь интересно, как Напарник ими управляет. Типовой цикл выглядит примерно так. 1. Сотрудник формулирует ситуацию обычным языком, например *«почему упала молочка в Сибири»*. 2. Напарник распознаёт класс ситуации и собирает план разбора. В простом случае хватит одного агента, в сложном понадобится два-три, работающих параллельно. План остаётся внутренним, сотрудник его не видит, если сам не попросит показать. 3. Напарник делегирует задачи функциональным агентам. Каждому уходит конкретная задача с параметрами, например период, регион, категория, набор гипотез. Агенты работают либо независимо и параллельно, либо последовательно, в зависимости от поставленного плана. 4. Напарник собирает результаты в единый ответ. Это синтез, с главным выводом, доказательной базой, отвергнутыми гипотезами и предлагаемым следующим шагом, а не простая склейка трёх отчётов через слово «также». 5. Сотрудник получает результат вместе с предложением действия. Если он валидирует вывод или поправляет его, Напарник запоминает поправку и в следующий раз учтёт её в похожей ситуации. Сложные ситуации обычно требуют нескольких таких циклов. Менеджер может уточнить, Напарник в свою очередь дозапрашивает агентов и возвращает уточнённый разбор. Всё это происходит в одном диалоге в одном чате, без переключения интерфейсов. Ещё одно важное свойство в том, что добавление нового функционального агента не увеличивает когнитивную нагрузку на сотрудника. Появился агент по эластичности цен, и у Напарника становится на одну возможность больше, а интерфейс остаётся прежним. --- ## Организационная память Опыт сотрудника не должен исчезать вместе с его уходом из компании. И опыт сильного сотрудника не должен оставаться внутри одной головы, пока коллеги в соседнем отделе изобретают то же самое заново. Для этого нужна организационная память. Это многослойное хранилище контекста и опыта, к которому у Напарника есть доступ. Полное устройство памяти, состав слоёв, правила доступа и политики хранения описаны в [05-architecture, раздел «Память и контекст»](/05-architecture/#память-и-контекст). С точки зрения сотрудника организационная память даёт два пользовательских эффекта. Первый эффект состоит в преемственности. Когда сильный менеджер уходит, его личная память не передаётся новому сотруднику автоматически. Это было бы странно и небезопасно. Передаётся то, что уже стало паттерном, а именно проверенные подходы, типовые аргументы, разборы кейсов. Преемник получает их с первого дня и не восстанавливает по обрывкам файлов и устным рассказам. Механизм отбора и валидации паттернов лежит в [05-architecture, раздел «Коллективная память»](/05-architecture/#коллективная-память). Второй эффект состоит в доступе к чужим удачным решениям внутри своей роли. Если в категории кондитерки кто-то нашёл рабочий аргумент против повышения закупочной цены, после валидации куратором этот аргумент становится доступен Напарникам остальных категорийных менеджеров. Сотруднику не нужно знать, как это технически устроено. Достаточно того, что Напарник учитывает удачные практики коллег при подготовке его собственных решений. --- ## Уровни зрелости ИИ-Напарника Напарник не вводится одним релизом. Он растёт по уровням, и каждый следующий уровень опирается на зрелость предыдущего, на работающие интеграции, накопленную обратную связь и выстроенные правила безопасности. Эту лестницу удобно использовать на пресейле, чтобы договориться с заказчиком об ожиданиях от пилота и обозначить, куда внедрение движется дальше. | Уровень | Что Напарник делает | Что становится возможно | |---|---|---| | [1. Операционный помощник](#уровень-1-операционный-помощник) | Рутина по почте, календарю, голосу, транскриптам, поиску по корпоративным источникам. | Освобождается до 30–40% рабочего времени сотрудника от механической работы. | | [2. Аналитический помощник](#уровень-2-аналитический-помощник) | Доступ к данным и BI, факторный анализ отклонений, нестандартные срезы через [Text2SQL](/03-agents/#5-text2sql), подготовка разборов и презентаций, проактивный мониторинг аномалий. | Время от вопроса до обоснованного ответа сжимается на порядок, а часть проблем ловится ещё до того, как менеджер открыл отчёт. | | [3. Коммуникационный помощник](#уровень-3-коммуникационный-помощник) | Профили контактов, симулятор коммуникаций, подсказки на встречах в реальном времени (тот самый голосовой ассистент, [04-usecases](/04-usecases)), второе мнение перед решением. | P&L-эффект на переговорах и заметный рост качества внутренних коммуникаций. | | [4. Мультиагентный координатор](#уровень-4-мультиагентный-координатор) | Общение Напарников между собой, горизонтальный обмен паттернами, вертикальная агрегация. | Корпоративная среда работает как сеть взаимодействующих агентов. Преемственность экспертизы. | ### Уровень 1. Операционный помощник Базовый слой. Напарник снимает рутину, которая в крупной сети съедает значительную часть дня. Агент умеет сортировать входящую почту по срочности и теме, эскалировать критичные сигналы от поставщиков, подбирать время для встреч с учётом календарей и предпочтений сотрудника. Напарник расшифровывает голосовые сообщения менеджера в текст и превращает их в действия — письмо, задачу, поиск. Из транскриптов совещаний Напарник вытаскивает договорённости и дедлайны, а на вопросы вида *«где найти регламент Y»* или *«по какому шаблону подавать заявку X»* отвечает по корпоративным источникам. Видимый эффект на этом уровне обычно появляется раньше всего, поэтому он хорошо подходит на первые недели пилота. Метрики тоже простые. Замеряем время на типовую операцию до и после, количество писем, обработанных без участия сотрудника, и долю встреч с автоматически сформированной повесткой. ### Уровень 2. Аналитический помощник Напарник получает доступ к данным и начинает отвечать на содержательные вопросы по категории. Сотрудник спрашивает обычным языком, почему упала молочка в регионе, а в ответ приходит факторный разбор с главным выводом, доказательной базой и отвергнутыми гипотезами. Под капотом работают функциональные агенты, которые ходят в хранилище и BI, делают нестандартные срезы через Text2SQL, считают эффект промо и готовят черновики разборов и презентаций. Часть этой работы Напарник делает без запроса, потому что в фоновом режиме ловит аномалию раньше, чем она доходит до планёрки. Эффект на этом уровне виден на скорости и качестве решений. Время от вопроса до обоснованного ответа падает с дней до минут, а у менеджера на руках сразу расширенная картина, а не та, до которой он успел докопаться руками. Здесь смотрят на время до первичного разбора, долю разборов, к которым менеджер вернулся за уточнениями, и оценку точности диагностик по 5-балльной шкале. ### Уровень 3. Коммуникационный помощник Напарник начинает работать с людьми вокруг сотрудника. Он ведёт профили контактов в личной памяти, и в этих профилях лежат поставщики, коллеги из смежных подразделений и руководители. В профиле фиксируется стиль аргументации, чувствительные темы, прецеденты успеха и неудач, типичные триггеры уступок. Перед значимой коммуникацией Напарник работает как симулятор и предупреждает, например, что коммерческий директор спросит про каннибализацию, у тебя нет этого раздела. Эффект на этом уровне уже прямой, P&L-метрики начинают двигаться. Лучше подготовленные переговоры дают доли процента бэк-маржи, и на масштабе крупной сети это десятки миллионов рублей в год. Здесь смотрят на долю встреч с подготовленным досье, эффект на маржу категорий и количество итераций при согласовании внутренних документов. ### Уровень 4. Мультиагентный координатор Напарники разных сотрудников начинают разговаривать между собой по [управляемой политике межагентского взаимодействия](/05-architecture/#межнапарниковая-коммуникация-a2a). Например, менеджер просит своего Напарника собрать статусы по промо у коллег. Напарники коллег идут к своим сотрудникам, собирают данные, валидируют и возвращают ответ. Между подразделениями появляется аудируемый поток запросов, и он сам по себе становится данными о том, как работает организация. На этом уровне начинает работать горизонтальный обмен паттернами. Удачный подход одного менеджера после валидации куратором становится доступен Напарникам всей команды. Так коллективная память переходит из описания в реальный рабочий механизм. Уровень 4 не включается рывком, он добавляется поверх первых трёх и требует отдельной проработки правил. --- ## Отличие ИИ-Напарника от функционального агента Напарник и функциональный агент относятся к разным сущностям, и на словах их легко перепутать. | Критерий | ИИ-Напарник | Функциональный агент | |---|---|---| | За кем закреплён | За конкретным сотрудником | За классом задач | | Сколько в системе | По одному на сотрудника | Один общий, используется всеми Напарниками | | Как вызывается | Сотрудник пишет в обычный мессенджер | Вызывается Напарником, не сотрудником | | Что знает | Контекст и историю своего человека | Свою предметную область и инструменты | | Что возвращает | Результат с рекомендацией следующего шага | Структурированный ответ по своей задаче | | Доступ к данным | Через права своего сотрудника | По узкой инструментальной политике | | Видим ли сотруднику | Да, постоянный собеседник | Обычно нет, работает «под капотом» | В обычный рабочий день сотрудник может вообще ни разу не вызвать функционального агента напрямую. Все обращения идут через Напарника, и так получается удобнее. Но при необходимости менеджер может работать с конкретным функциональным агентом сам. Примеры функциональных агентов в [03-agents](/03-agents/#классификация-функциональных-агентов). --- ## Ограничения и границы ответственности Напарник работает как компетентный партнёр, но самостоятельность у него ограничена. На критичных решениях он сотрудника не подменяет и в обход корпоративных правил не действует. :::caution[Что Напарник не делает сам] Сюда относятся внешние коммуникации от имени организации, изменения в учётных системах, инициирование платежей, договорные изменения, листинг и делистинг поставщиков, а также любые действия, которые сложно или невозможно откатить. Напарник всё это готовит, формулирует и рекомендует, но финальное действие подтверждает сотрудник. ::: Границу автономии задаёт Tier-модель. Она разделяет действия по уровню эффекта и обратимости. Например, чтение данных и подготовка черновиков разрешены по умолчанию. А действия с внешним эффектом (отправка письма, изменение в учётной системе, бронирование встречи) требуют явного подтверждения сотрудника. Автономные действия по расписанию или триггеру включаются точечно по согласованным правилам, после периода доверия и согласования с ИБ. Конкретный состав уровней, классификация действий и механизм подтверждения описаны в [05-architecture, раздел «Tier-модель автономии»](/05-architecture/#tier-модель-автономии). Помимо Tier-модели у Напарника есть несколько ограничений по содержанию работы. С цифрами Напарник работает как передатчик, а не источник истины. Любая цифра, которую он показывает, ссылается на источник в корпоративном хранилище (таблицу, период, набор фильтров). Сотрудник может в один клик провалиться в источник и проверить. В обход прав сотрудника Напарник тоже не работает. Если у менеджера нет доступа к данным соседнего подразделения, Напарник этих данных тоже не получит. Подробности лежат в [05-architecture, раздел «Безопасность и права доступа»](/05-architecture/#безопасность-и-права-доступа). --- ## Метрики ценности ИИ-Напарника Метрики удобно разносить на операционные, бизнес-метрики и пользовательские. Нужны все три. По одним бизнес-метрикам картина пилота выходит неполной, а на одних операционных не выйдет разговор с коммерческим директором. | Уровень | Метрика | Как измеряется | |---|---|---| | Операционный | Время на типовой аналитический запрос | Замер до и после на одинаковом наборе вопросов | | Операционный | Доля встреч с подготовленным досье | Отметка в календаре или подтверждение от менеджера | | Операционный | Время от аномалии до алерта | Лог появления отклонения и времени уведомления | | Бизнес | Эффект на маржу категории | Сравнение когорт менеджеров с Напарником и без | | Бизнес | Дополнительная бэк-маржа в переговорах | Отдельная отметка по подготовленным переговорам | | Бизнес | Время адаптации нового менеджера | До выхода на целевой KPI категории | | Пользовательский | NPS менеджеров | Регулярный замер 1–2 раза в месяц | | Пользовательский | Доля задач, в которых менеджер обращается к Напарнику | Лог обращений / общий объём типовых задач | | Пользовательский | Качество диагностик | Оценка менеджера по 5-балльной шкале на каждом разборе | :::note[Калибровка под заказчика] Конкретный набор метрик и их пороги фиксируются на пресейле под конкретного заказчика. Универсального ROI у Напарника нет, он сильно зависит от того, какие сценарии входят в пилот, какая стартовая зрелость данных и какие процессы заказчик готов пересобрать. ::: --- ## Открытые вопросы Здесь темы, по которым у концепта пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика. :::caution[Граница «персональный контекст vs функциональный агент»] На словах разделение чёткое. Напарник помнит контекст сотрудника, а функциональный агент знает предметную область. На практике граница размывается. Профили контрагентов живут в личной памяти Напарника, но те же поставщики фигурируют и в данных, к которым ходят функциональные агенты. Где должна храниться истина по поставщику и кто её обновляет, пока решено не до конца. ::: :::caution[Калибровка проактивности] Между «дёргает по любому шороху» и «молчит, когда нужно было предупредить» лежит узкий коридор. Устоявшейся методики настройки порогов чувствительности под конкретного сотрудника у концепта нет, а неудачные начальные настройки по умолчанию способны оттолкнуть менеджера раньше, чем тот дойдёт до тонкой настройки. Кто и на каких данных подбирает первоначальные пороги, остаётся открытым вопросом. ::: :::caution[Риск чрезмерного доверия] Принцип «Напарник передатчик, а не источник истины» защищает от ошибок только если сотрудник реально проваливается в источник и перепроверяет цифры. На практике удобный и обычно правильный собеседник провоцирует обратное. Менеджер перестаёт перепроверять и принимает рекомендации на веру. Как удержать здоровый скепсис, не возвращая ручную работу, методологически не закрыто. ::: :::caution[Управление скиллами и их конфликты] Сотрудник сам добавляет и отключает индивидуальные скиллы, при этом поверх работают общие на компанию и встроенные. Когда индивидуальный скилл противоречит общему (например, *«не дёргай при отклонении меньше 5%»* против корпоративного порога эскалации), нужно правило разрешения конфликта и видимый сотруднику приоритет. Единого механизма пока нет. :::