Автор собрал ассистента почти без отдельного оркестратора - один md-файл, Telegram и небольшой сервер для памяти
🧩 Проблема в кейсе следующая - если пытаться собрать агента из набора фреймворков и внешних сервисов, быстро растут зависимости, настройки и точки отказа, а это довольно проблемно. В сценарии кейса задача была обратная - понять, сколько можно вытянуть только на Claude Code, без лишнего слоя вокруг.
⚙️ Решение построено так:
• Claude Code запускается как основной исполнитель задач;
• Telegram выступает точкой входа для команд, заметок и голосовых сообщений;
• один md-файл хранит сценарий запуска и описание системы;
• Flask-сервер на ~700 строк отвечает за постоянную память;
• MCP-плагины дают доступ к нужным действиям без отдельной orchestration-логики;
• embeddings, то есть числовые представления смысла текста, помогают искать контекст между сессиями.
Если совсем просто: большую часть работы делает не «сложный фреймворк», а сам LLM-процесс с понятной инструкцией, памятью и набором действий.
Что видно по кейсу — чем меньше лишних слоев между моделью и рабочим сценарием, тем проще понять, где система ломается и что именно нужно исправить
Для себя я зафиксировал две важные вещи:
🔸Во-первых, устойчивость такого агента держится не на количестве интеграций, а на том, насколько четко описан стартовый сценарий и как сохраняется контекст.
🔸Во-вторых, память полезна только тогда, когда она действительно помогает достать нужные записи между сессиями, а не просто копит текст.
✅ Если переносить это в свой процесс, я бы проверил:
• хватает ли одного понятного setup-файла, чтобы поднять систему заново;
• есть ли у агента отдельная точка для памяти и журнал действий;
• можно ли воспроизвести сценарий без ручной сборки из десятка сервисов.
Главный вывод кейса — сначала нужен простой и повторяемый сценарий с памятью и точками контроля, а уже потом наращивание автоматизации