Между мыслью и записью — шесть полей
Задача редко рождается за столом. Она приходит в дороге, в чужой переписке, голосом на ходу. Чтобы она попала в систему, человек должен открыть её, нажать «создать» и принять шесть решений подряд.
Каждое из них по отдельности пустяковое. Вместе они дают простой итог: дешевле запомнить, чем записать. Через день задача уже стирается из памяти, а через неделю её приходится восстанавливать на планёрке.
Мы собирали систему для себя и упёрлись в это первыми. Поэтому переставили вход местами: сначала сказать, и только потом — если надо — посмотреть.
Поля и значения — из схемы нашей же базы: так устроена любая форма, потому что форма обязана получить структуру на входе.
Основной пользователь системы — не человек
Это записано в самом начале архитектурного документа, ещё до выбора технологий: основной пользователь CRM — агент, он работает через программный интерфейс. Человеку остаётся экран, чтобы посмотреть и поправить.
На практике это значит: чтобы поставить задачу, вы пишете сообщение в Telegram — обычное, пересланное или голосовое. Агент сам ищет подходящий проект, проверяет, нет ли уже такой же задачи, ставит срок и отвечает, что сделал. Структуру, которую форма требует на входе, он достраивает сам и переспрашивает, если не хватает данных.
Фразы слева не придуманы для кейса: это дословные примеры из описаний операций, по которым агент и решает, что вызвать. Справа — сама операция и что она делает.
Шесть поводов написать первым
Переписка работает в обе стороны: половина смысла системы в том, что агент пишет сам, без запроса.
Расписание жёсткое и считается обычным кодом, без языковой модели: даже если провайдер недоступен, дедлайны всё равно приходят вовремя. С 22:00 до 09:00 проверки выключены, а вечер пятницы и выходные агент считает нерабочим временем.
Заштрихованное на шкале — тихие часы. Ночью система молчит совсем: напоминание про завтра подождёт до утра.
Так устроена сводка: сначала цифры, потом три коротких списка. Ничего не надо открывать — всё уже в сообщении.
Цифры настоящие — сняты с базы 25 августа 2026. Названия задач мы закрыли полосами: система личная, и внутри неё есть проекты под соглашением о неразглашении.
В тот же день отметка о последней доставке стояла на 09:00. Это отметка именно о доставке: почему это отличается от простого срабатывания расписания — в разделе про надёжность.
Тридцать девять команд вместо разделов меню
Агент не «имеет доступ к базе» — у него набор именованных операций, каждая делает одну вещь и возвращает понятный ответ. Это и есть его руки.
Названия важнее, чем кажется: по описанию операции модель решает, что вызвать. Поэтому в описаниях прямо записано, чем «удали» отличается от «сделал» и что удаление повторяющейся задачи — это не то же самое, что её закрытие.
Экран остался — он просто перестал быть входной дверью
Мы не убирали интерфейс. Есть вещи, которые в переписке неудобны: посмотреть месяц целиком, перетащить задачу между колонками, поправить десять карточек подряд. Для этого восемь разделов в вебе — и они никуда не делись.
Разница в том, что ни один из них больше не обязателен. Форма осталась там, где без неё хуже, и ушла оттуда, где она мешала.
Четыре бага, и ни один не про интеллект модели
Летом мы сели разбираться, почему агент «то работает, то нет»: пишет «готово, удалил», а задача на месте; не находит очевидную задачу; заводит дубликаты. Первое подозрение всегда одно — модель слабая, надо взять помощнее.
Разбор занял два полных аудита по живому коду и серверу. Ни одна из причин не оказалась в модели. Все четыре — в обвязке вокруг неё.
«Готово, удалил» — а задача на месте
успешно — даже когда не удалил ничего. Сколько строк он на самом деле тронул, код просто выбрасывал. Врала агенту сама среда — он лишь повторял то, что ему ответили.удалилось или нет, а в правилах агента появилась строка: писать «готово» только если инструмент вернул успех. Заодно удаление стало мягким — задачу и её подзадачи можно вернуть одной фразой.Агент «не находит» очевидную задачу
Правила до модели вообще не доходили
Страховка от дублей не сработала ни разу
Общий вывод мы записали в аудит одной строкой: надёжность агента — это примерно на 80 % обвязка вокруг модели (инструкция, инструменты, обработка ошибок, наблюдаемость) и лишь на 20 % её собственный интеллект. Ни один из четырёх багов не починился бы переходом на модель помощнее.
Опасно то, что падает молча
Система, которой доверили напоминать, обязана шуметь, когда ломается. Иначе выходит худший из возможных вариантов: человек перестал держать задачи в голове, а система перестала о них писать — и никто об этом не знает.
Такое уже случалось. На соседнем сервисе того же сервера утренняя рассылка несколько дней подряд падала на ошибке доступа. В логах при этом бодро стояло «отправлено»: код не читал, что ответил мессенджер.
Планировщик читает ответ мессенджера и ставит отметку времени, только когда доставка подтверждена. Мы отмечаем именно «сообщение получено».
Было: отправка логировалась всегда, включая отказ по токену.Отдельный скрипт смотрит на возраст отметки. Старше 25 часов — приходит предупреждение с подсказкой, что проверять. Он живёт вне процесса, за которым следит: иначе умрёт вместе с ним и промолчит.
Умеет писать напрямую, минуя тот же маршрут, который мог и сломаться.База не копировалась вообще. Хуже: основной файл был от 6 апреля, а весь свежий материал лежал в журнале на 2,8 МБ — обычное копирование файла потеряло бы месяцы работы.
Стало: штатный снимок в 03:30 со сведением журнала, хранение 14 дней. На 25 августа в папке 16 копий.Чтение и правка повторяются до трёх раз с растущей паузой. Создание повторяется только если запрос доказуемо не дошёл до сервера, — иначе вместо одной задачи появились бы две.
Было: одна неудачная попытка — и инструмент возвращал ошибку человеку.Каждый перезапуск открывал окно в несколько секунд, когда агент стучался в мёртвый порт и получал отказ. Лечение оказалось скучным: поднять лимит памяти процесса с 250 до 350 МБ. Замер сделан 25 августа. Это ровно то, что имелось в виду под «надёжность — в обвязке».
Что эта система не делает
Кейс написан по своей же системе, поэтому границы видны изнутри. Часть из них — сознательный выбор, часть — наш незакрытый долг.
Последний пункт — главный аргумент в пользу сторожа и отметки о доставке. Идеальной настройки не бывает: важно узнавать о поломке в тот же день.
Механизм не про задачи и не про нас
Под кейсом лежит связка из трёх частей: канал, в котором человек уже сидит; набор именованных операций над своей базой; детерминированный планировщик, который пишет первым и работает без языковой модели.
Предметная область меняется — связка остаётся той же. Ниже те задачи, где вход выглядит один в один: человек что-то сказал или переслал, а на выходе должна появиться структурная запись.
Что стоит зафиксировать до старта: в каком канале живёт команда, какие операции агент имеет право делать без подтверждения, а какие — только с ним, и по каким признакам мы поймём, что система сломалась молча.
Соберём такой же вход в вашу систему
Начинаем с одного сценария и одного канала: показываем работающий круг «сказал — записалось — напомнило» на ваших данных, а потом добавляем остальное. Сроки и стоимость считаем до старта.