Как я сделал консьержа для Claude Code и Codex

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

Claude Code пишет код, Codex проверяет изменения, третья сессия ищет причину сбоя, четвёртая ждёт ревью. Параллельно работать они умеют. Мой мозг — не очень. В фокусе рабочей памяти держится несколько независимых элементов; в исследованиях обычно получается около четырёх смысловых блоков. Точное число зависит от задачи и умения собирать информацию в крупные куски. Но это точно не десятки живых сессий.

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

Первой попыткой был Agent Dashboard — отдельное Electron-приложение с проектами, сессиями и последними событиями. За компьютером он часть нагрузки снял: вместо десятка окон один экран.

Следом я добавил к нему Telegram-бота. С телефона удобнее задать короткий вопрос: «Что там с Logicore?» Или переслать сообщение коллеги со словами «передай это в проект». Я рассчитывал, что мобильного входа в тот же дашборд хватит.

Первый прототип показал разницу между доступом к событиям и пониманием работы. Однажды я спросил бота, что происходит в проекте. Он посмотрел на время последней записи и уверенно сообщил: сессия зависла полтора часа назад. На экране моего Mac в этот момент горело 2 running tasks. В другой раз я поручил через того же бота работу. Агент всё закончил, результат уже лежал в дашборде, а Telegram молчал. Через двадцать минут я написал: «ну?»

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

Так появился Консьерж.

Когда делегировать задачи уже недостаточно

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

На одном проекте это чистое ускорение. Я ещё помню, зачем открыта каждая сессия, что ей объяснили и какой ответ надо проверить. Управление незаметно, потому что занимает меньше времени, чем сама работа.

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

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

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

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

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

Открыть схему в полном размере ↗

Зачем понадобился отдельный агент

Консьерж живёт в Telegram и принимает сообщения только от меня. Текст, голосовое, скриншот, документ, кусок пересланной переписки.

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

Чинить проект сам Консьерж не должен. Я несколько раз ловил его на попытке быстро помочь: сходить по SSH, открыть базу, прочитать репозиторий напрямую. Быстрее получалось только на первом шаге. Дальше смешивались роли, права и история работы.

Правило теперь простое. Консьерж разбирает запрос и координирует. Работа внутри проекта остаётся в сессии проекта.

Это же определило выбор модели. Сначала мы маршрутизировали по стереотипу: код — Codex, операторская работа — Claude. На деле важнее преемственность. Если проект уже ведётся в Claude Code, там накоплены инструкции, навыки, открытая ветка и память о прошлых решениях. Открывать Codex только потому, что в задаче встретилось слово «код», смысла нет.

Поэтому Консьерж ищет существующую сессию и продолжает разговор там. Новую создаёт, только если продолжать нечего. Провайдер новой сессии тоже наследуется от истории проекта.

Как выглядит один запрос

Допустим, я пересылаю в Telegram вопрос куратора. За секунду до этого успеваю написать отдельной строкой: «это наш куратор».

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

Дальше Консьерж сверяет упоминания с проектами из дашборда и своей рабочей памятью. Связь надёжная — сразу предлагает действие. Контекста мало — в Telegram появляются две-три кнопки: передать в найденную сессию, создать отдельное поручение, просто сохранить информацию. До нажатия не меняется ничего.

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

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

Новое сообщение здесь не мелочь. Если отредактировать старое, Telegram часто не покажет уведомление. Формально ответ доставлен, а человек его не увидел.

Открыть схему в полном размере ↗

Что работает без модели

За понимание запроса отвечает закреплённая сессия Claude Code на Sonnet. После каждого ответа она не закрывается. Процесс ждёт следующего сообщения на стандартном вводе: в простое токены не тратятся, а новый запрос не ждёт запуска ещё одной сессии.

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

Локальная очередь держит готовый ответ, пока Telegram не подтвердит доставку. При сетевой ошибке повторяется отправка, а не рассуждение Sonnet. Планировщик сам считает время следующего запуска. Наблюдатель следит за поручениями без постоянного опроса через ИИ. Сторож поднимает сервис после сбоя с тем же ID сессии.

Внутри получилось несколько простых частей:

У Sonnet есть Full Access: Chrome, навыки, плагины, подключённые MCP-серверы. При этом перехватчик блокирует shell и прямой доступ к проектным файлам из сессии Консьержа. Текстового обещания «не лезть в проекты» оказалось мало.

Ошибки, из которых получилась архитектура

Первая версия поднимала новую Claude-сессию на каждый запрос. Бот отвечал, завершался, забывал разговор. Фраза «перепроверь» закономерно вызывала встречный вопрос: перепроверить что? После перехода на одну закреплённую сессию контекст перестал пропадать, а ответ стал быстрее.

Дальше выяснилось, что передать задачу мало. У Claude Code нет события, которое само заставит уже ответившую модель заговорить снова, когда другая сессия закончила работу. Так появился независимый наблюдатель. Писать «ну?» ради проверки готового результата больше не нужно.

Следующая поломка выглядела мистически: часть ответов «не отрисовывалась». В журнале Telegram всё успешно. Оказалось, начальный ответ и трекер прогресса редактировали один message_id. Кто писал последним, тот и оставался на экране. Старое сообщение мы закрепили только за прогрессом, а смысловой ответ стали слать отдельно. Заодно добавили технический журнал доставки: метод API, ID результата, номер попытки, запасной способ, хеш текста. Сам текст в журнал не попадает.

Ещё один сбой выдавал пользователю внутреннее исключение:

Claude returned an invalid intake proposal

Причина будничная. Модель правильно разобрала запрос, но придумала подпись для кнопки длиннее 48 символов. Теперь такие поля сначала нормализуются локально. Если структура всё ещё неверна, сервис один раз просит модель исправиться. Последний запасной вариант отдаёт безопасные действия только для чтения вместо трассировки ошибки.

Отдельная история — права записи. У Консьержа было два разных ограничения: обычное разрешение на изменение и дополнительное подтверждение опасной операции. Оба возвращали похожий отказ. Даже агент не мог объяснить, почему соседние задачи ведут себя по-разному.

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

Что он помнит обо мне

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

Консьерж отдельно индексирует мои решения из локальных сессий Claude и Codex. Для каждой записи сохраняются предшествующий разговор, моя формулировка, последующий ответ агента и названия использованных инструментов. Аргументы команд и результаты инструментов в индекс не попадают.

Например, однажды я жёстко сказал: «ai-panel — другой проект, не трогай его». Позже похожая задача про новый интерфейс получила полезный прецедент: заводить отдельный репозиторий, а не пристраивать функцию к проекту с похожим названием.

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

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

Поручения, которые возвращаются сами

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

По будням в десять присылай сводку по Logicore до первого сентября.

Или:

Каждые три часа проверяй статус миграции, всего восемь раз.

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

База расписаний лежит на Mac и переживает перезапуск сервиса. Пропущенный день не создаёт очередь из десятков устаревших запусков. Одна задача не запускается параллельно сама с собой. После трёх устойчивых ошибок она останавливается и сообщает причину.

Для публикации, платежа, удаления или продакшен-деплоя постоянное расписание постоянным согласием не считается. Каждый такой запуск требует подтверждения заново.

Где система находится сейчас

На 31 июля 2026 года локальная проверка установки показывает одну живую закреплённую Sonnet-сессию. Дашборд видит 12 проектов и 38 сессий Claude и Codex. В индексе лежат 4 246 записей решений из трёх типов источников. Текущий набор из 171 теста проходит полностью.

Цифры быстро устареют. Ограничения останутся.

Mac и Agent Dashboard должны быть включены, иначе до проектных сессий Консьерж не доберётся. Чужая сессия может остановиться из-за сети, авторизации или отсутствующего инструмента. Пересланный скриншот без пояснения иногда действительно неоднозначен. Модель решений ищет аналоги, а не читает мысли.

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

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

Ради этого всё и затевалось.