AI-ассистент, который говорит «я не знаю»: почему это важнее чем бот, который врёт красиво

Вчера мой liaison-бот @spbsolar_help_bot сказал клиенту то, что я бы постеснялся произнести вслух. Андрей Полушин — клиент по проекту автоматизации — после рабочего созвона написал в наш общий рабочий чат: «Дай обновлённый список задач после сегодняшнего созвона». Бот ответил: «Юрий ещё не обновил мою память по итогам разговора. У меня список как был в 9 утра. Если хочешь не ждать — напиши тезисами что вы решили, я зафиксирую».

Бот в открытую сообщил клиенту, что я не сделал свою часть работы. Не угадал. Не сформировал правдоподобный список задач из данных шестичасовой давности. Не ответил уверенным тоном из устаревшей памяти. Сообщил честный статус — и сразу предложил клиенту способ помочь самому, без ожидания.

Раньше я бы прыгнул в чат с извинениями. Сегодня просто открыл редактор, дописал раздел «решения созвона» в файл памяти, через минуту бот ответил Андрею корректно. Никакой имитации компетентности. Никакого стресса. Просто факт состояния и следующий шаг.

Почему это не баг, а именно то, что я строил полгода

Это результат полугода сознательной работы над одним свойством системы: AI-ассистенты от моего имени должны знать границы своего знания. Не притворяться всезнайками. Не угадывать. Не строить ответы из устаревших данных с уверенным тоном.

У меня сейчас 20 ботов, которые от моего имени общаются с разными людьми: закрывают сделки по аренде вилл на Бали, отвечают по проектам автоматизации, мониторят соцсети, разруливают платежи, ведут клиентские чаты. Каждый из них может оказаться в ситуации, когда данные, которые у него есть, устарели на несколько часов или дней. Ключевое — не то что данные устаревают. Ключевое — как бот обрабатывает эту ситуацию.

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

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

Второй вариант — репутационная бомба с неизвестным таймером.

Архитектура памяти с временными метками: как устроен честный бот

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

Каждый liaison-бот в моей системе работает с файлом контекста для каждого активного контакта. Файл хранится на сервере в JSON-формате и содержит несколько блоков данных, каждый со своим last_updated:

{
  "contact_id": "polushin_andrey",
  "contact_name": "Андрей Полушин",
  "project": "Автоматизация отдела продаж",
  "memory_updated_at": "2026-05-28T09:00:00+08:00",
  "project_status": "Фаза 3 завершена. Обсуждаем переход на ежемесячную поддержку.",
  "open_questions": [
    "Бюджет ежемесячной поддержки",
    "Периодичность отчётов"
  ],
  "next_steps": [
    "Договор на поддержку — подготовить шаблон",
    "Онбординг в систему мониторинга"
  ],
  "decisions_log": [
    {
      "date": "2026-05-20",
      "decision": "Перенесли дедлайн фазы 3 с 25 мая на 28 мая"
    },
    {
      "date": "2026-05-15",
      "decision": "Добавили блок аналитики к фазе 3"
    }
  ]
}

Бот читает поле memory_updated_at при каждом запросе. Если разница между этим значением и текущим временем превышает пороговое значение — у меня 12 часов для активных проектов — и запрос клиента касается недавних событий, бот сообщает о возможной неактуальности данных.

Когда Андрей написал про «обновлённый список после сегодняшнего созвона», два сигнала сработали одновременно: memory_updated_at показывал 9 утра (разница — больше 8 часов), и явное упоминание «сегодняшнего созвона» — события, которого в файле памяти нет. Бот корректно определил: актуальных данных нет, сообщить об этом прямо.

Это 20 строк кода в системном промпте и одно поле в JSON. Вся реальная сложность — в дисциплине обновления файла памяти после каждого важного события.

Бот-фантазёр: как выглядит катастрофа при масштабировании

Альтернатива — бот без явных границ знания, который пытается быть полезным любой ценой.

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

Но проблема глубже разового случая. Молчаливая потеря доверия к автоматической системе — это тихая катастрофа, которая разворачивается медленно.

Первый неправильный уверенный ответ: клиент относит к случайности.

Второй: клиент начинает перепроверять ответы бота напрямую у вас.

Третий: клиент перестаёт писать боту по важным вопросам — только по мелким.

Четвёртый: клиент требует живого менеджера «на ключевых решениях».

Пятый: уходит без объяснений — и вы не узнаете почему.

Я видел этот паттерн у нескольких предпринимателей, которым помогал строить автоматизацию. Бот запустили, первые недели всё отлично. Потом что-то поменялось в процессе, файл памяти не обновили — бот начал давать устаревшие ответы с уверенным тоном. Клиенты начали обходить автоматику. Конверсия из чата упала. Причину не сразу поняли — искали в механике бота, а проблема была в архитектуре памяти.

Репутация строится медленно и разрушается быстро. Один уверенный неправильный ответ от бота, который представляется как «мой ассистент», — это репутационный минус на вашем счёте, не на счёте бота.

Как настроить «я не знаю» технически: промпт, структура памяти, пороги

Честный AI-ассистент строится на трёх компонентах.

Компонент 1: системный промпт с явными ограничениями.

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

«Ты знаешь состояние проекта на момент последнего обновления (поле memory_updated_at). Если клиент упоминает события после этой даты (созвоны, новые договорённости, изменения) — сообщи, что у тебя нет информации об этих событиях, и предложи клиенту кратко написать что изменилось. Не угадывай и не строй ответ из устаревших данных — это создаёт путаницу хуже, чем честное "я не знаю".»

Компонент 2: JSON-файл памяти со временными метками.

Структура выше — рабочая. Главное: memory_updated_at на уровне всего файла и опционально — на уровне отдельных блоков данных, если они обновляются с разной частотой. Например, контактная информация меняется редко — её метка может быть трёхмесячной давности и это норма. Статус активной сделки устаревает за часы.

Компонент 3: пороговая логика в промпте.

Разные типы данных устаревают с разной скоростью. Пример конфигурации:

• Статус активного проекта: порог 12 часов
• Последние договорённости: порог 24 часа
• Открытые вопросы: порог 48 часов
• Контактная информация: порог 30 дней

При превышении порога + релевантном запросе клиента — бот сообщает о неактуальности. При запросе, который явно относится к событию после memory_updated_at — сообщает безусловно.

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

20 ботов от одного имени: где граница знания критична по-настоящему

При одном боте — риск одного неправильного ответа локален и заметен сразу. При 20 — масштаб принципиально другой.

У меня 16 вилл на Бали, у каждой один или несколько инвесторов. Каждый инвестор периодически пишет в личный кабинет или в рабочий чат с вопросами о доходности, о статусе бронирований, о плановых и фактических выплатах. Данные по каждой вилле обновляются разнородно — что-то ежедневно через системы бронирования, что-то раз в месяц по итогам P&L. Если финансовый агент ответит инвестору по данным двухнедельной давности с уверенным тоном — и эти данные окажутся неверными — проблема серьёзнее чем неудобство. Это потенциальный конфликт.

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

Канальные агенты в Telegram, Instagram, Threads — другая история. Там данные устаревают иначе: важна актуальность информации о продуктах, ценах, условиях. Если агент в личке Instagram ответит по прайсу трёхмесячной давности — потеря лида.

Каждый тип данных в каждом боте имеет свой критический порог устаревания. Настроить честность под каждый тип — это не одна инструкция в промпте, а несколько. Но это разовая работа, которая снимает хронический риск.

Pipeline автоматического обновления памяти: что строю сейчас

Текущий bottleneck: обновление файлов памяти — операция с ручным триггером. После созвона, важного письма, смены статуса — кто-то должен явно обновить файл. При 3-4 созвонах в день с разными клиентами и 20 активными файлами контекста — задержки накапливаются. Именно так получилась ситуация с Андреем: созвон прошёл, я не успел обновить файл сразу, клиент написал раньше.

Pipeline, который сейчас в разработке:

Шаг 1: захват события. Созвон записывается автоматически (Zoom API или Google Meet). Агент-слушатель в рабочих чатах фиксирует триггерные фразы: «договорились», «переносим», «добавляем», «отказываемся».

Шаг 2: транскрипция. Whisper транскрибирует запись — 1-3 минуты на час аудио при локальном деплое модели medium. Чанки по 10 минут обрабатываются параллельно.

Шаг 3: извлечение изменений. LLM-агент (Claude Sonnet) читает транскрипт и извлекает структурированный diff: что изменилось по сравнению с предыдущим состоянием файла контекста. Формат: новые решения, изменённые сроки, обновлённые вопросы и следующие шаги.

Шаг 4: patch файла памяти. Агент применяет diff к JSON-файлу контакта — не перезаписывает целиком, а вносит точечные изменения. Обновляет memory_updated_at. Дописывает в decisions_log.

Шаг 5: уведомление ботов. Все агенты, у которых этот контакт в активных, получают сигнал об обновлении. При следующем запросе клиента работают с актуальными данными.

Целевое время задержки: 30 минут от конца созвона до обновления памяти всех агентов. До момента готовности pipeline — бот честно сообщает о задержке, как это произошло с Андреем. Это не временный костыль. Это правильное поведение системы в переходный период.

Хочу строить систему не потому что хочу чтобы боты всегда всё знали. А потому что не хочу чтобы они угадывали в ситуациях где данных нет.

Три сценария где граница знания ломает или спасает сделку

Абстрактные принципы работают лучше, когда их видно на конкретных ситуациях. Вот три реальных сценария из моей практики — один провальный (до внедрения архитектуры с временными метками) и два рабочих.

Сценарий 1: провальный. Апрель 2026. Потенциальный инвестор по одной из вилл написал вопрос о доходности за март. Liaison-агент ответил цифрами из последнего обновления файла контекста — данными за февраль. Инвестор не уточнил, что спрашивал именно про март. Принял февральские данные как мартовские. Следующий вопрос — «почему выплата не совпадает с тем что вы говорили?». Полтора часа разбора, в итоге нашли расхождение. Причина: агент не сообщил что данные устаревшие. Данных за март в файле просто не было — но агент об этом не сказал.

Сценарий 2: рабочий. Май 2026, клиент по автоматизации спросил про статус задачи, которую мы обсуждали на созвоне три дня назад. Бот увидел, что созвон был после последнего обновления памяти, и ответил: «По состоянию на 12 мая у меня статус в работе. Если на нашем созвоне что-то изменилось по этой задаче — напиши, я обновлю картину». Клиент написал что задача фактически закрыта. Бот зафиксировал, поблагодарил. Никакого конфликта, никакой путаницы.

Сценарий 3: рабочий. Инвестор спросил про плановую выплату на июнь. Финансовый агент проверил дату последнего обновления — данные актуальные, три дня назад. Ответил корректно с суммой и датой. Инвестор получил ответ за 30 секунд без участия менеджера. Это и есть целевой сценарий: бот отвечает мгновенно, данные свежие, клиент доволен.

Разница между сценарием 1 и сценариями 2-3 — не в умности бота. В архитектуре: есть ли у него информация о том, насколько актуальны его данные, и есть ли инструкция что делать когда актуальность под сомнением.

Чему я научился из 20 ботов в клиентском контексте

Когда строишь первого бота-ассистента для клиентов — фокус на функционале. Что умеет? Как быстро отвечает? Сколько каналов покрывает? Когда ботов становится 20 и каждый ведёт несколько активных контактов одновременно — фокус сдвигается. Главный вопрос уже другой: насколько каждый из них честен про состояние своих данных?

Несколько наблюдений из работы с системой:

Во-первых, LLM без явных ограничений всегда выберет дать ответ, а не сказать «не знаю». Это следствие того, как они обучены — быть полезными. «Не знаю» кажется моделям бесполезным ответом. Явная инструкция в промпте переопределяет это: «в такой-то ситуации — сообщить о неактуальности важнее, чем дать ответ». Без явной инструкции модель сама не придёт к такому выводу.

Во-вторых, клиенты воспринимают «я не знаю» от бота нормально, если это сформулировано правильно. Не «извините, у меня нет данных» (звучит как сбой), а «мои последние данные от 12 мая, если что-то изменилось — напишите, я обновлю» (звучит как рабочий процесс). Первая формулировка снижает доверие. Вторая — повышает, потому что показывает прозрачность системы.

В-третьих, самые дорогие ошибки происходят не когда бот говорит явную неправду, а когда говорит правду, устаревшую на несколько дней. Клиент не знает, что данные устарели. Бот не говорит об этом. Оба исходят из того, что информация актуальная — и именно в этой зоне возникают конфликты и недопонимания.

В-четвёртых, pipeline обновления памяти — это не техническая задача, а операционная. Технически сделать автоматическую транскрипцию и patch файла — один sprint разработки. Операционно — это дисциплина: каждый важный разговор должен завершаться триггером для обновления памяти. Пока pipeline не готов — этот триггер ручной. И это норма, если бот честно сообщает о задержке.

Итог: три правила для AI-ассистентов в клиентском бизнесе

Полгода работы с 20 ботами в клиентском контексте — три правила, которые теперь закладываю в архитектуру каждого нового агента:

Правило 1: у каждого блока данных должен быть timestamp и порог актуальности. Бот без временных меток на своих данных не знает насколько он устарел. Добавить memory_updated_at и логику проверки — один вечер работы. Не добавить — и первый же устаревший ответ клиенту создаёт проблему, которую вы не сразу заметите.

Правило 2: «я не знаю» всегда лучше уверенной неправды. LLM с радостью строит правдоподобный ответ из устаревших данных — и делает это так убедительно, что клиент не сомневается. Явная инструкция в системном промпте «если не уверен в актуальности — скажи об этом прямо» должна быть у каждого агента, который общается с клиентами от вашего имени.

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

Юрий Солар, основатель Solar Property и 4bos.ru: «Меня не пугает что мои боты не всезнайки. Меня пугало бы если бы они начали делать вид что знают то чего не знают. Это путь который ломает доверие быстрее всего. Один раз ассистент клиенту скажет уверенным тоном неправду — и репутация уходит в минус. Клиент уйдёт, не сказав почему. Бот который скажет "я не знаю, спроси Юрия напрямую" — это инструмент, который ставишь между собой и клиентом и не сгораешь.»

Весь стек — liaison-боты, архитектура памяти с временными метками, pipeline автоматического обновления после созвонов, системные промпты с явными границами знания — я разбираю в клубе «Solar — внутрянка». В формате «вот моё в проде, бери и адаптируй»: AGENTS.md конкретных агентов, JSON-структуры памяти, системные промпты — всё, что работает прямо сейчас в боевой системе с реальными клиентами. Доступ: https://4bos.ru/inside/ — от 2 500 ₽/мес.

Из смежного: CRM за вечер вместо amoCRM — про то, как нативная интеграция ботов с собственной базой данных убирает слой «сломанного телефона» между агентом и актуальным состоянием сделки.

Есть четвёртый принцип, который я добавлю к трём выше: формулировка «я не знаю» важна не меньше, чем само решение её использовать. Разница между «у меня нет данных» и «мои последние данные от 28 мая — если на созвоне что-то изменилось, напиши тезисами, я зафиксирую» — это разница между сбоем системы и прозрачным рабочим процессом. Одно вызывает тревогу, другое — доверие. Работайте над формулировкой честного незнания так же тщательно, как над любым другим ответом бота.

Дополнительно: если вы только начинаете строить систему с AI-ассистентами для клиентов — не ждите момента когда будет 20 ботов и pipeline автоматического обновления. Начните с одного агента, одного канала и одного JSON-файла контекста с полем memory_updated_at. Дисциплина обновления этого файла после каждого важного контакта — это и есть фундамент. Всё остальное строится поверх. Если дисциплины нет при одном боте, при двадцати её точно не будет.

— Solar OS.