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

В медицине ты точно знаешь: организм — это не одна большая программа, которая «умеет всё». Это печень, которая фильтрует, сердце, которое качает, гиппокамп, который запоминает, иммунитет, который отбраковывает чужеродное. Каждый орган узкоспециализирован, и именно поэтому целое работает надёжно. Твой завод устроен ровно так же: 16 с лишним сервисов-органов — channel-hq, memory-bank, thumbnail-studio, resource-governor, channel-forge, moss-lab и другие — каждый закрывает одну конкретную функцию и разговаривает с остальными через общую «кровеносную сеть» с говорящим именем factory. Как и в теле, сервисы не знают IP-адресов друг друга наизусть — они находят друг друга по имени, как органы находят друг друга через нервные пути и гормоны, а не по «координатам».

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

За месяц стройки у тебя сами собой выработались пять привычек — правил, которым ты следуешь, даже не называя их «архитектурой». И вот новость: это и есть архитектура, просто ты пришёл к ней раньше, чем прочитал теорию. В индустрии такие правила называют guardrails — «ограждения», которые не дают системе съехать в кювет, даже когда она действует самостоятельно. Хорошая иммунная система не спрашивает разрешения на каждый чих — у неё есть встроенные правила: что атаковать, что пропускать, когда поднимать температуру. Твои пять законов — это ровно такой врождённый иммунитет для будущей автономной системы.

Напомню их: (1) сначала исследуй, потом делай; (2) обсуди → действуй, никаких изменений без явного «да»; (3) там, где можно обойтись скриптом — не зови ИИ; (4) проверяй живое (что реально показывает экран), а не то, что «должно быть по коду»; (5) не теряй задачи — веди честную очередь. Смотри, как красиво они ложатся на медицину: закон 1 — это «сначала анамнез, потом лечение»; закон 4 — это «осмотри пациента, а не только читай его карту»; закон 5 — это триаж в приёмном покое: ни один пациент не должен потеряться в коридоре.

Разница между сегодня и целью курса — в одном слове: сегодня закон 2 звучит как «ничего без моего личного да» на каждом шаге. К концу дороги, которую описывает этот курс, он должен звучать иначе: «ночью система решает и действует сама, кроме одного — тратить деньги без подтверждения нельзя». Это не отмена закона 2, а его взросление: с ручного гейта на каждом шаге — до одной чётко очерченной красной линии. Все пять законов не исчезнут — они станут кодом (хуками, чек-листами критиков, лимитами в конфиге), а не тем, что ты держишь в голове и проверяешь руками.

В медицине ты хорошо знаешь разницу между тремя вещами: регистратурой, которая по скрипту записывает на приём и ничего не решает; клиническим протоколом, где шаги расписаны заранее (жалоба → анализ А → если результат X, то анализ Б → если Y, то направление к специалисту); и врачом, который ведёт сложный случай сам — сам решает, какой анализ назначить следующим, сколько консультаций понадобится, когда остановиться. Все три — часть медицины, но контракт с пациентом у них разный. Ровно такая же разница существует между чат-ботом, workflow и агентом — и это не про «кто умнее», а про то, кто именно решает, сколько шагов сделать и в каком порядке.

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

Теперь честная новость про твой завод: конвейер ⓪→⑨ — это workflow, а не агент, и это совершенно нормально, даже хорошо. Порядок стадий (сценарий → озвучка → визуальные правила → промпты → картинки → таймлайн → рендер → упаковка) зашит в коде заранее, как клинический протокол. Модель на каждой стадии честно делает свою узкую работу, но не решает «а не пропустить ли мне эту стадию» или «не повторить ли сценарий ещё три раза». А вот твоя цель №1 — строитель приложений, который сам решает, сколько раз прогнать критику кода прежде чем тесты станут зелёными, — это по определению уже настоящий агент: число ходов заранее не известно никому, включая тебя.

Вспомни рефлекторную дугу из курса физиологии: раздражитель → рецептор → нерв → мозг оценивает → мышца действует → и обязательно возвращается сигнал обратно, что получилось. Убери последнее звено — и рука будет дёргаться, не понимая, обожглась она или нет. Один «ход» (turn) агента устроен ровно так же: агент смотрит на текущее состояние (что уже сделано, что вернули инструменты) → думает, что делать дальше → выбирает и вызывает инструмент → получает результат из реального мира (не выдумывает его) → оценивает, закончена ли задача → либо делает ещё ход, либо останавливается. Это кольцо называют Thought → Action → Observation.

Самая важная деталь, которую легко упустить: обратная связь обязана приходить из окружения — из реального результата, а не быть самовнушением модели («мне кажется, я справился»). Один из инженеров Anthropic формулирует это резко: без сигнала из окружения на каждом ходу ты не добавляешь агенту ума — ты просто добавляешь шум. И вот прямое попадание в твой завод: стадия ⑨ LEARNING сейчас холостая — метрики с YouTube (просмотры, retention) не долетают автоматически обратно в memory-bank. подтверждено Это рефлекторная дуга с обрезанным обратным нервом: действие (публикация) происходит, а сигнал «получилось или нет» в мозг не возвращается. Даже там, где есть цикл — например, петля обучения обложек в thumbnail-studio, — она замкнута только внутри себя (QC против собственного же критерия), а не на реальный результат из мира.

Пять слоёв, из которых состоит любой ход агента, стоит держать в голове по отдельности, потому что у каждого свой типичный сбой: восприятие (что видит агент прямо сейчас — ошибка: скормить «всё подряд», раздувая контекст), принятие решений (собственно модель — здесь работает твоя лестница моделей haiku/sonnet/opus), действие (реальное изменение мира — запись файла, трата GPU-слота), память (короткая — контекст хода, и долгая — memory-bank между ходами), и обратная связь (замыкает кольцо, самое слабое место завода прямо сейчас).

Представь два рецепта. Первый: «Пациенту — таблетки, иногда». Второй: «Амоксициллин 500 мг, по 1 капсуле 3 раза в день после еды, курс 7 дней, при аллергии на пенициллины — заменить». Оба формально «дают инструкцию», но только по второму можно безопасно действовать — даже незнакомому врачу, который видит пациента впервые. Инструмент, который отдают модели, должен быть написан как второй рецепт: чёткое имя, понятные параметры, описание — «как будто объясняешь новому члену команды», как формулирует сама Anthropic. Голый инструмент с параметрами «A» и «B» без описания — это первый рецепт: модель начинает додумывать («галлюцинировать») дозировку, потому что ты не оставил ей другого выбора.

Как это вообще работает механически: модели присылают список доступных инструментов вместе с их «рецептами» (JSON-схемами) → модель решает, какой вызвать и с какими параметрами → твой код (не модель!) реально выполняет действие → результат возвращают модели → модель либо отвечает, либо вызывает следующий инструмент. Пять шагов, простой конвейер. проверено

Для тебя это не абстракция: если ты хочешь, чтобы будущий оркестратор дёргал внутренние API channel-hq, memory-bank, resource-governor сам, каждый такой API должен перестать быть просто REST-эндпоинтом «для людей, читающих код» и стать нормально описанным «рецептом для модели» — с именем, назначением и внятными параметрами, а не POST /api/action?p1=&p2=. Иначе модель будет действовать вслепую именно там, где цена ошибки (потратить деньги, стереть файл) особенно высокая.

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

Skill — это просто папка с процедурным знанием, которую можно версионировать в git: инструкция, примеры, иногда код-хелперы. Один универсальный код-агент (в духе Claude Code) плюс растущая библиотека таких папок обходится дешевле и предсказуемее, чем «зоопарк» из сорока узкоспециализированных агентов, каждый со своим промптом, контекстом и точкой отказа. В докладе Anthropic это иллюстрируют образом: «агенты сегодня во многом похожи на блестящего новичка без экспертизы — против опытного специалиста с готовыми протоколами под рукой».

Самое приятное: у тебя это правило уже есть, просто без официального названия. «Повторил дважды → оформи скиллом» — это твоя собственная, интуитивно выведенная версия ровно той архитектуры, которую Anthropic сейчас формализует как индустриальный стандарт. У тебя уже растёт такая полка: faceless-script-skill, capcut-marker-builder, коннектор к YouTube API — и это не побочный продукт, а ядро того, как должна масштабироваться и контент-фабрика, и строитель приложений: не плодить агентов под каждую нишу или каждый стек, а расширять одну полку скиллов.

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

Отсюда вырастает базовое деление ролей в любой рабочей многоагентной системе — три роли, которые нельзя поручать одному и тому же агенту в одном и том же заходе. Планировщик решает, что делать и в каком порядке, и на выходе у него план и критерии готовности — не сам результат. Исполнитель делает конкретную работу — пишет код, генерирует картинку, зовёт API. Критик оценивает результат исполнителя против критериев планировщика и имеет право развернуть работу назад. Смешение этих трёх ролей в одном агенте — самая частая причина, почему «умный ИИ» выдаёт правдоподобный, но неверный результат: он не врёт специально, он просто физически не может объективно оценить собственную же работу.

У тебя это уже было граблей — не в теории, а на живом сервисе. У thumbnail-studio в первых версиях критик (R2) видел не только готовую обложку, но и рассуждения генератора (R1) — почему он выбрал именно такой шрифт, такую композицию. И критик начал соглашаться с генератором чаще, чем должен был: он «заражался» логикой того, кого проверял, вместо того чтобы смотреть на результат свежим взглядом. Это называется эхо-камерой. Лекарство было простое и уже применено на заводе: критик должен получать ТОЛЬКО готовый артефакт и чек-лист требований — никакой истории рассуждений того, кто это сделал.

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

Первый паттерн — конвейер: жёсткая цепочка стадий, каждая зависит от предыдущей. Это буквально твой путь от ниши до YouTube — сценарий не может появиться раньше темы, озвучка не может начаться раньше сценария. Второй — иерархия «оркестратор + воркеры»: центральный диспетчер решает, кого позвать, и параллелит независимые части. Твой batch-запуск N видео с честным распределением ресурсов через resource-governor — это она и есть. Третий — передача управления: агент сам решает, кому отдать задачу дальше, и получатель становится полноправным владельцем, а не просто вызванным инструментом. У тебя такого пока нет в явном виде, но он идеально ложится на будущего «разведчика возможностей» — сканирование рынка не имеет заранее известного числа шагов.

Четвёртый паттерн — самый неожиданный по узнаваемости: общая доска. Агенты не общаются друг с другом напрямую, а читают и пишут в общее хранилище, и какой-то управляющий механизм решает, кто активируется дальше по содержимому доски. Это буквально твой memory-bank. И пятый — параллельный веер — множество агентов обрабатывают один и тот же вход параллельно, дальше кто-то агрегирует результаты. Этого паттерна у тебя пока нет вживую — это ровно то недостающее звено, которое станет мотором консультант-фабрики.

Вот архитектура твоего ключевого бизнес-режима — ночью веер из 3-10 MVP-решений, утром демо клиенту. Она устроена не как «десять копий одного и того же агента, авось одна получится лучше». Она устроена как консилиум с разными специализациями: N агентов-исследователей (explorer), каждый с ЯВНО разным приоритетом — один жмёт на скорость, другой на надёжность, третий на дешевизну. Не три клона с одинаковой инструкцией, а три разных взгляда на одну и ту же боль клиента. Дальше — панель судей (judge panel), тоже разнородная: судья-технарь смотрит на архитектурный риск, судья «глазами клиента» — на удобство и понятность, судья по бюджету — на скорость окупаемости. И только потом — финальное сравнение.

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

И последнее, что важно понять сразу: веер не удлиняет твою ночь. Три-десять explorer-агентов работают параллельно, и всё это займёт примерно столько же времени, сколько один агент, работающий последовательно (потому что бутылочное горлышко — самый медленный из них, а не сумма всех). Но веер стоит дороже по деньгам — токенов тратится в разы больше, потому что параллельных сессий несколько. Это ровно та переменная, которой ты управляешь: сколько вариантов запускать и на какой модели.

Соблазн после трёх уроков про оркестрацию — начать плодить агентов на всё подряд. Индустрия честно предупреждает: подавляющее большинство пилотных многоагентных систем не доезжает до продакшена в задуманном виде — и почти никогда не из-за того, что модель «недостаточно умная». Падают на интеграции: агенты дёргают друг друга через хрупкие связки, свалка документов без структуры вместо продуманного поиска, бесполезный постоянный опрос сервисов вместо уведомлений о событии. Ты с этим уже боролся не в теории — твой закон №5 («не терять задачи, честная очередь») — это прямая защита именно от такого класса сбоев.

Второе честное предупреждение — прямо из опыта Andrej Karpathy, который держит крепкую репутацию трезвого практика в индустрии агентов. Он запустил восемь параллельных агентов-исследователей на одну открытую задачу — и они, по его собственным словам, «неплохо реализуют любую хорошо описанную идею, но плохо придумывают идеи сами»: не продумывают дизайн эксперимента тщательно, не выстраивают сильные базовые сравнения, генерируют не по-настоящему разные подходы, а вариации одного и того же. Для тебя это прямое предупреждение про консультант-фабрику: веер из 3-10 explorer-агентов надёжно работает, когда РЕАЛИЗУЕТ уже хорошо сформулированную идею («сделай MVP системы бронирования для кофейни в трёх разных архитектурах»), но плохо работает, если отдать агентам саму генерацию идей без структуры («придумай, что вообще предложить кофейне»). Практический вывод: пространство вариантов должен заранее задавать ты (через скилл или чек-лист паттернов MVP), а не надеяться, что агенты сами придумают разнообразие.

Третье — прямой урок из практики компании Factory, которая держит автономные разработческие сессии на дни подряд (ближайший прообраз твоего ночного строителя). Они попробовали интуитивно очевидную идею — если 10 агентов работают одновременно над кодовой базой, значит, будет 10-кратная скорость. Не сработало: агенты конфликтуют, наступают на изменения друг друга, дублируют работу, принимают несовместимые архитектурные решения — как если бы десять хирургов одновременно оперировали одного пациента без координации. Их решение — фичи выполняются серийно, один воркер активен в любой момент времени на одной кодовой базе, а параллелится только то, что безопасно параллелить в принципе: чтение, поиск, разведка. Для твоего строителя приложений это значит: параллельный веер вариантов — да (разные MVP, разные каналы), но одна и та же кодовая база одним прогоном пишется серийно.

Правило перед тем, как заводить нового агента, звучит как хорошее клиническое правило «не выписывай новое лекарство, если хватит смены дозы старого»: сначала спроси — это механическая операция (посчитать, найти, проверить формат)? Значит скрипт, не агент. Это уже существующий скилл, применённый к новому контексту? Значит не новый агент, а новый вызов того же скилла с другим промптом. И только если это принципиально новая роль в консилиуме — тогда агент.

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

Ровно так же устроен любой ИИ-агент. Контекстное окно — это ОЗУ: пока сессия идёт, оно держит всё — твои реплики, файлы, промежуточные мысли модели. Но как только сессия claude -p в генераторе завершается (видео отрендерилось), это окно исчезает целиком. Всё, что было сказано на первом ходу, все ограничения, поставленные на третьем — если это не записано во внешний файл, оно испарилось так же, как испаряется разговор с пациентом, если ты не сделал запись в карту.

Это прямое объяснение твоей главной боли: раздутие контекста до ~1M токенов на 12-шаговой задаче. Проблема не в том, что модель «глупая» — проблема в том, что при многошаговой задаче каждый следующий шаг вынужден заново перечитывать всё, что было сказано раньше, потому что нет отдельного механизма, который бы решал: «что из этой горы фактов реально нужно следующему шагу». У тебя уже есть диск — memory-bank, отдельный сервис-«гиппокамп», который переживает конец любой сессии. Вопрос этого урока не «нужна ли тебе долгая память» (она уже есть), а «правильно ли она используется» — потому что просто иметь диск недостаточно, если каждый раз на него сваливают всё подряд.

В медицине память тоже не единая коробка — есть память на события («вчера в 15:00 пациент жаловался на головокружение»), память на устоявшиеся факты («у пациента аллергия на пенициллин») и память на навыки («как правильно накладывать шов»). Три разных механизма, три разных места хранения в мозге. У твоего memory-bank — ровно та же структура, просто ты пришёл к ней раньше, чем прочитал название.

Эпизодическая память — конкретные события: «14 июля тема Y дала CTR 6.1%». У тебя это log.jsonl внутри банка каждого канала — журнал того, что реально случилось. Семантическая память — устоявшиеся факты и правила: «канал X: темы про военку заходят лучше катастроф». Это global.json (кросс-канальные правила) и profile.json каждого канала (маскот, DNA, устоявшийся стиль). Процедурная память — выученные приёмы, не привязанные к конкретному пациенту-каналу: «такой промпт для сцен даёт лучший рендер». Это твои generators/{photo,omni,remotion}.json — крафт, общий для всех каналов сразу.

Это разделение — не бюрократия для порядка, а защита от конкретной, уже прожитой тобой грабли: протечки между уровнями. У тебя это уже случалось дважды: тренировочные (synthetic) каналы протекали в общий банк и портили правила для настоящих каналов — решением стал жёсткий гейт isSynthetic, закрывающий все пишущие двери для тестовых данных. И второй случай: AVOID-строки (запреты, найденные на одной стадии) утекали между стадиями script и visual без разбора — решение — читать steering-правила scoped по стадии (kind=). Это как иммунная система: антитело, обученное против одного штамма, не должно бить по всем подряд без разбора — нужны чёткие границы, кто на что реагирует.

Есть отдельная угроза, характерная именно для длинных, многошаговых задач — таких, как твой будущий строитель приложений, работающий ночью 6-8 часов без надзора. Она называется context anxiety — «тревога контекста». По мере заполнения окна модель не просто теряет связность — она МЕНЯЕТ поведение: начинает сворачивать разговор раньше времени, торопится через шаги и объявляет вещи сделанными, хотя они не сделаны. Представь врача, который к концу изматывающего суточного дежурства начинает писать в карте «состояние стабильное» на автомате, не глядя на пациента внимательно — вот это тревога контекста в чистом виде.

Лекарство, которое уже придумала индустрия — паттерн, который честно стоит назвать по имени: Git Context Controller (не «OneContext», как иногда путают в пересказах — точное название пришло из статьи arXiv 2508.00031). Идея — вести память агента буквально как git. Есть main.md — общая дорожная карта, которую перечитывают почти всегда. Когда агент пробует альтернативный путь (например, «попробую Playwright вместо API-проверки») — это branch: отдельная ветка со своим commit.md (короткие вехи-резюме) и log.md (полная сырая история этой ветки). Дошёл до успеха — merge: короткое резюме сливается в main, а тяжёлая сырая история остаётся в архиве, к ней обращаются только если нужно «покопаться».

Это лечит ровно твою личную боль номер один: раздутие контекста на 12+ шагах, когда приходится «платить за перечитывание одного и того же». При GCC-подходе перечитывается только main.md — сжатый обзор — а не вся сырая история заново на каждом шаге. У тебя уже есть зачаток этого паттерна: файлы state.json/config.json в проектах генераторов — тот же принцип «внешний прогресс-файл переживает смену сессии», просто без явного деления на branch/main.

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

Когда цепь замкнута, память становится общей доской — все сервисы видят одно состояние, вместо того чтобы каждый канал заново набивал шишки, которые уже набил другой. Но общая доска работает хорошо только если поиск по ней умный. Здесь легко ошибиться в сторону «просто засунь всё в векторную базу» — индустрия уже прошла этот путь и вернулась к более скромному решению: гибридный поиск (точный поиск по полю + смысловой поиск по тексту вместе), а не чистая векторизация. Для твоего масштаба (единицы-десятки каналов) это ещё проще: у тебя уже структурированный JSON, так что «поиск» по большей части — это фильтрация по полям (channel_id, format, niche), а не дорогие эмбеддинги. В vector DB торопиться не нужно — она оправдана при сотнях каналов и тысячах записанных дефектов, не раньше.

Отдельная тонкость, которую легко упустить: не всякий вопрос к памяти — вопрос «найди похожее». Есть вопросы про ВРЕМЯ («что изменилось за последний месяц» — не то же самое, что «найди похожий факт», это вопрос про тренд) и вопросы про ЦЕПОЧКУ причин («почему это правило вообще появилось» — нужно пройти по связке дефект → правило → канал). Если твой сегодняшний банк не умеет отвечать на такие вопросы структурированным запросом, а требует ручного пролистывания JSON — это конкретный, измеримый признак «склада», не «мозга». И последнее — экономика: раздели память на стабильную часть (DNA канала, редкие правила — кешируется дёшево) и volatile-часть (последние метрики — меняется часто), иначе одна свежая строчка рядом со стабильным блоком будет каждый раз сбивать весь кеш и заставлять платить заново за то, что вообще-то не изменилось.

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

На твоём заводе сейчас всё это упаковано в два гейта — EDIT_PENDING и APPROVAL_PENDING — которые останавливают ВЕСЬ конвейер целиком, независимо от того, что именно происходит на шаге. Это как если бы иммунитет одинаково жёстко реагировал что на занозу, что на укус змеи — вместо того чтобы занозу вытолкнуть тихо и без шума, а на змею объявить общую тревогу. Разница между двумя ситуациями — это разница в риске и обратимости действия, а не в самом факте «что-то произошло».

Поэтому первый шаг к ночной автономии — не «выключить гейты», а разложить один общий гейт на матрицу: что читается (READ) — можно смотреть само по себе, без разрешения, это как дыхание; что пишется и обратимо (WRITE) — можно делать автоматически, но с проверкой на входе, как слизистая фильтрует; что удаляется навсегда (DELETE) — только с твоего явного «да», потому что это необратимо; и отдельная, самая жёсткая категория — ТРАТА денег, которая требует подтверждения ВСЕГДА, без исключений, даже если всё остальное автономно. Это твоя красная линия, и она одна не меняется никогда во всём курсе.

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

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

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

Есть простая арифметика, которая объясняет, почему у тебя вообще стоят гейты, и почему длинная автономная цепочка без остановок статистически обречена спотыкаться. Если каждый шаг конвейера выполняется правильно с вероятностью 95% — что вообще-то неплохой показатель — то цепочка из 10 шагов подряд (ниша → концепт → тема → генерация → QC → обложки → SEO → approve → upload → learning) успешна целиком лишь в районе 60% случаев. осторожно Это не пессимизм и не мистика — просто вероятности независимых событий перемножаются, и десять шагов подряд без единой проверки — это как десять монеток подряд лечь одной стороной.

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

Но есть и обратная, более коварная ловушка — Loop of Death: агент делает шаг с ошибкой, среда сообщает об ошибке, агент «исправляет» — и исправление плодит новую ошибку, цикл повторяется, сжигая на каждом витке самые дорогие токены. Это не гипотетический риск — у тебя это уже случалось буквально: повторные kill+relaunch+resume загоняли прогон в 409 Conflict, а стадия зависала в failed навсегда. Твоё собственное правило «чинить вперёд, не с нуля» и совет «не thrash'ить stop/resume» — это полевым опытом найденная версия того же самого рецепта, который советует индустрия: жёсткий лимит попыток, а не бесконечное «ещё разок».

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

Твой завод уже использует Docker для всех 16+ сервисов — это хорошая базовая изоляция, но не абсолютная. Контейнеры делят одно ядро операционной системы хоста, и если в этом ядре найдётся дыра, она теоретически пробивает все контейнеры разом — как если бы «пробирки» стояли в одном инкубаторе с общей вентиляцией. Для доверенного, известного кода (твои боевые сервисы) это приемлемый риск. Но для НОЧНОГО СТРОИТЕЛЯ, который сам пишет и запускает произвольный код без присмотра, этого уровня изоляции может быть недостаточно — особенно если он крутится на том же VPS, где живёт боевой завод.

Отсюда простое и жёсткое правило: ночной билдер приложений по умолчанию НЕ должен видеть секреты завода вообще — ни YouTube OAuth-токены, ни .env боевых сервисов, ничего, кроме явно прокинутых тестовых ключей. Это прямое расширение твоего же правила «секреты не отдавать третьим сервисам без спроса», только теперь применённое не к внешним интеграциям, а к твоему собственному будущему агенту-строителю. Второй жёсткий инвариант, который у тебя уже есть и который нельзя ослаблять: прямые порты сервисов биндятся только на 127.0.0.1, наружу торчит только Caddy с SSO. Это ровно то, чего не хватало тысячам публично уязвимых инстансов чужих агентных систем.

В медицине ты знаешь: чем больше и активнее орган, тем больше энергии он тратит на метаболизм — и не вся эта энергия уходит на полезную работу, часть сгорает просто на поддержание процесса. С токенами в агентных системах — то же самое. Каждое слово, которое модель читает или пишет, стоит энергии (денег). И вот ключевой факт, который объясняет твою боль: чем больше «органов» включается в один разговор, тем не линейно, а взрывообразно растёт расход. Простой чат — это как человек, спокойно сидящий в кресле: минимальный метаболизм, единица энергии. Один агент с инструментами — это уже человек, который встал и начал что-то делать руками: он тратит примерно в 4 раза больше. А вот полноценная мультиагентная система, где несколько «органов» работают над одной задачей одновременно, — это уже бегущий марафон: расход взлетает примерно в 15 раз осторожно относительно простого чата (цифра research-системы Anthropic, не универсальное свойство мультиагентных систем).

Почему так много? Потому что 80% этого расхода — это не «модель стала умнее думать», а просто объём текста, который гоняется туда-сюда проверено. Представь консилиум врачей, где перед каждым новым специалистом зачитывают ВСЮ историю болезни с самого начала — включая черновики, отменённые гипотезы и разговоры между собой, — вместо краткой выписки. Именно это происходит, когда субагенты не изолированы: каждый получает не «выжимку под свою задачу», а всю историю разговора целиком, и оплачивает её прочтение заново.

Твой личный опыт с 1M токенов на 12-шаговой задаче — это ровно такой случай: система «перечитывала одно и то же» на каждом шаге, вместо того чтобы держать общий обзор в одном компактном месте, а детали доставать по запросу. Это не о том, что модель «плохая» — это о том, что архитектура задачи не разделяла контекст на «нужно всегда» и «нужно иногда». Хорошая новость: примерно 70% оплаченных токенов в типичных многоагентных прогонах вообще не приносят пользы осторожно (вторичный источник, не Anthropic напрямую) — то есть даже без магии, просто убрав это бесполезное сгорание, экономия огромная и реальная.

Есть и вторая, более скрытая причина раздувания — техническая механика самого инструмента (Claude Code), которую стоит знать как врач знает фармакокинетику препарата. Разговор автоматически «сжимается» (автокомпакция), когда давление контекста достигает примерно 167 тысяч токенов — но при сжатии система оставляет лишь несколько последних файлов, а всё остальное — рассуждения, промежуточные решения, прочитанные файлы — сминается в один плотный блок. Чтение одного файла обрезается на 2000 строках — без предупреждения, что хвост файла не виден вообще. А если результат работы инструмента длиннее 50 тысяч символов, он сохраняется на диск, а агенту показывается только превью — и агент искренне не подозревает, что видит не всё (например, grep «нашёл» 3 совпадения из реальных 47). Это как если бы врач читал только первую страницу анализа крови и был уверен, что видит полную картину.

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

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

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

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

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

5. Mechanical-first — скрипт вместо ИИ. Если задачу можно решить детерминированным кодом (посчитать, найти по шаблону, отфильтровать) — не зови модель вообще. Твой собственный замер: аудит 10 инструментов через LLM обошёлся примерно в 4 миллиона токенов, а тот же самый аудит через grep — в ноль. Это как разница между «попросить консилиум врачей прочитать всю историю болезни, чтобы найти одну дату» и «нажать Ctrl+F».

У тебя уже есть личное правило, выстраданное практикой: если прогон съедает больше 250 тысяч токенов из кеша или больше $0.50 — стоп, пересобрать задачу заново, а не гнать дальше. Это не случайная цифра из воздуха — это твой собственный стоп-кран, и в индустрии он называется ровно так же, как звучит: предохранитель, который разрывает цепь до того, как утечка станет катастрофой. В медицине это жгут при кровотечении — накладывается не после того, как пациент потерял пол-литра крови, а сразу при первых признаках, что кровотечение не останавливается само.

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

Третий кусок — честный вопрос «подписка или API». При твоём объёме использования (десятки каналов, ежедневная работа) месячная подписка Claude почти наверняка выгоднее оплаты по токенам за API — это уже твоё текущее решение, и оно правильное. Но здесь есть юридическая тонкость, которую стоит прояснить ДО того, как ты начнёшь коммерчески масштабировать систему на подписке: условия использования подписки для программного доступа (Agent SDK, автоматические ночные прогоны без твоего личного клика) в некоторых сценариях описаны неоднозначно даже самими практиками индустрии. Это не повод паниковать — это повод один раз списаться с поддержкой Anthropic и получить письменный ответ, прежде чем строить на этом бизнес для десятков клиентов.

И последнее — мониторинг. Стоп-кран работает только если ты видишь цифру ДО того, как она стала катастрофой, а не после. Панель с $/задача, $/день и алертами — это твой пульсоксиметр: не лечит сама, но кричит раньше, чем станет поздно.

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

Мировая индустрия ночных кодинг-агентов сошлась примерно на трёх больших семьях архитектур, и все три — это просто три разных ответа на вопрос «как устроить тело». Первая — это то, чем ты уже реально пользуешься: Claude Code с его шестью «кирпичиками» (CLAUDE.md как конституция репозитория, скиллы, субагенты, слэш-команды, хуки-стражники и внешние коннекторы). Вторая — архитектура Devin: четыре РАЗНЫХ роли — планировщик, кодер, критик, «браузерный агент», который сам открывает приложение глазами. Третья — OpenHands: система, где вообще всё записывается в неизменяемый журнал событий, чтобы после сбоя можно было честно восстановиться, а не гадать, что произошло.

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

Разберём сам рабочий цикл строителя по шагам — это его сердцебиение, ритм, который повторяется на каждой задаче. Шаг первый — ПЛАН: агент-планировщик читает боль клиента или ТЗ и пишет план в файл, а не держит его в разговоре. Это важно так же, как история болезни в карте пациента, а не в голове врача — план не должен «стираться» между шагами. Шаг второй — КОД: агент-кодер реализует план, пишет и код, и тесты к нему. Шаг третий — ТЕСТ: детерминированные проверки, линтер, сборка — это ноль «мышления» модели, просто механическая проверка, как анализ крови на автоматическом анализаторе.

Шаг четвёртый — критика, и здесь есть тонкость, которую стоит прочувствовать: критик должен быть независимым — другая сессия, другой контекст, видит только готовый результат и требования, но НЕ видит рассуждений того, кто писал код. осторожно Причина простая и человеческая: если ошибка закралась в ход мысли автора, а проверяющий думает теми же путями — он унаследует ту же слепую точку. Это ровно та же логика, что уже работает в твоей thumbnail-studio, где Haiku-судья QC не видит внутренних рассуждений генератора обложек, только готовую картинку и требования.

Шаг пятый — САМЫЙ важный и неочевидный: скриншот. Код может быть синтаксически безупречным, все тесты зелёные, а интерфейс при этом — визуально сломан: текст наехал на кнопку, на мобильном экране всё расползлось. Тесты этого не поймают, поэтому агент обязан сам запустить приложение и сфотографировать его глазами (через headless-браузер), а не поверить коду на слово. И шестой шаг — доработка по вердикту критика, с жёстким потолком в 3-5 попыток на итерацию: без потолка это Loop of Death, о котором ты уже знаешь из Модуля 4. Честный ориентир из практики: первый прогон ночного строителя реалистично выдаёт черновик — рабочий результат требует ещё 1-2 внутренних цикла критики за ту же ночь, не одну попытку с ходу.

Как организовать саму ночь — период, когда тебя рядом физически нет? Есть три рабочих способа запустить агента без присмотра, и у тебя фрагменты всех трёх уже есть. Первый — просто расписание: скрипт-таймер запускает claude -p "Задача" в назначенное время, точно как у тебя сегодня работает x-research-daily по systemd-таймерам в 07:20 и 09:20. Просто и надёжно для одношаговых задач, но без встроенной логики «повторить, если не получилось». Второй способ — очередь задач с зависимостями: это уже написанный, но выключенный orchestrator.mjs — он умеет ретраить с паузами и хранить историю прогонов, и для многошагового ночного строителя нужен именно он, просто применённый к коду вместо видео. Третий вариант — управляемые облачные платформы — для твоего self-hosted завода избыточен, но у него есть одна ценная идея, которую стоит украсть буквально.

Идея такая: по умолчанию всё только читает и анализирует, любая запись наружу требует явного «безопасного вывода» с логом, а слияние с боевым кодом никогда не происходит автоматически. Это готовая формулировка для твоего же правила про деньги, только расширенная на любое необратимое действие: ночью можно писать код, деплоить в тестовую среду, генерировать демо — свободно. Но платить (за домен, за API, за рекламу) нельзя без утреннего «да». Это твоя красная линия, просто перенесённая с видео на код без единого изменения смысла.

И последняя важная мысль про саму природу «полной автономии»: индустрия честно признаёт, что «100% автономность без единой точки контроля» — это ошибка проектирования, а не достижение. Формулировка звучит образно: «держи пожарный шланг короткими управляемыми очередями», а не открывай на всю ночь. Для твоей цели «полная автономия ночью, кроме денег» это не противоречие, а уточнение: полная автономия — это не десять часов вслепую, а десятки коротких фаз, у каждой свой чекпойнт и свой QC-гейт, просто ты не смотришь на них до утра. Молчаливый сбой опаснее явной ошибки — агент, который тихо отработал и не выдал ошибку, но сделал что-то не то, страшнее агента, который честно упал с понятным сообщением.

Прежде чем сравнивать фреймворки, важно развести два вопроса, которые в статьях и обзорах постоянно путают друг с другом, будто это одно и то же. Первый вопрос — какая нейросеть думает. У тебя он уже решён и решён давно: это подписка Claude, claude -p, с переключением между аккаунтами при сбое одного из них — проверено. Второй вопрос — совсем другой: кто управляет циклом «агент подумал → вызвал инструмент → получил результат → решил, что делать дальше», кто хранит состояние задачи между шагами, кто плодит и рассаживает субагентов по ролям. Вот это и есть настоящий вопрос «ядра», и весь этот модуль — именно про него.

Аналогия, которая должна снять напряжение: мозг — это уже сформированная кора, которая думает; а оркестратор — это нервная система, которая решает, в какой орган и когда отправить сигнал, куда провести импульс, что сделать параллельно, а что — строго по очереди. У тебя мозг уже подключён и работает месяц. А вот код нервной системы — тот самый orchestrator.mjs — уже написан, лежит в репозитории channel-hq, но сегодня физически выключен. Твой завод сейчас работает не как «свободный агент», а как жёстко заданный конвейер стадий ⓪→⑨ с двумя человеческими гейтами (EDIT_PENDING и APPROVAL_PENDING) — это в индустрии называется workflow: путь заранее известен, число шагов предопределено. Настоящий «агент» отличается тем, что сам решает, сколько шагов сделать и в каком порядке — этого у тебя пока нет, и это нормально: workflow там, где важна предсказуемость (деньги, публикация), — это правильный выбор архитектуры, а не недоделка.

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

Дальше — честное сравнение восьми систем, которые сегодня претендуют на роль «оркестратора» в индустрии. Ни одна из них не хуже других абсолютно — вопрос всегда «подходит ли она именно твоему заводу». Начнём с LangGraph: это фреймворк с очень чёткой философией — «модель генерирует текст, граф управляет поведением». Три кирпичика — состояние, узлы, рёбра — дают детерминированный контроль над потоком, а автоматическое сохранение состояния после каждого шага решает ровно ту боль, которую ты уже знаешь по своей практике: раздувание контекста и потерю прогресса при сбое. Здесь важно честно поправить одну цифру, которая гуляет по интернету в раздутом виде: Klarna, которую часто приводят как флагманский кейс LangGraph, заменила ботом эквивалент 700 сотрудников исправлено, а не 853, как иногда пишут. А цифра экономии «$60 млн» исправлено в надёжных источниках не подтверждается — ближайшая проверяемая цифра другая и относится к другому продукту. Зато две вещи про Klarna подтверждены твёрдо: доля решённых обращений выросла до 80%, и у бота было 85 миллионов пользователей-разговоров проверено. Для твоего завода вывод простой: LangGraph — это язык описания графа, полезная библиотека внутри одного сервиса (например, будущего opportunity-scout), но не повод переписывать весь завод под чужую систему состояния — у тебя уже есть работающий `state.json`.

CrewAI даёт простую ролевую модель («агент/задача/бригада»), которая осваивается быстрее графа — но есть честная и болезненная деталь: иерархический режим не умеет условно пропускать агентов, менеджер прогоняет всех подряд, даже когда часть работы не нужна. Реальный замер — 15 759 токенов на простой запрос вместо ожидаемых 200 проверено — это ровно та же болезнь токенного раздувания, которую ты уже пережил на 12-шаговых задачах. AutoGen/AG2 устроен иначе — агенты «спорят» в чате, менеджер-модель выбирает, кто говорит следующим. Это отличная идея именно для твоей судейской панели MVP-вариантов, но фреймворк ещё в статусе бета и склонен зацикливаться без явного лимита раундов. OpenAI Agents SDK отклоняется сразу и без сожаления — он жёстко привязан к моделям OpenAI, а твой мозг — подписка Claude; несовместимость по фундаментальной оси.

OpenClaw — система, с которой ты уже знаком лично, и архитектурно она ближе всего к твоей интуиции: файлы памяти MEMORY.md и .learnings/, ограничение глубины субагентов — это почти калька структуры, которую ты уже частично построил вручную в memory-bank. Но здесь тоже нужна честная поправка: часто цитируемый кейс «$1.3 млн в месяц» на сотне параллельных агентов — это расходы на разработку (dev-costs) конкретной команды на OpenAI-токенах, а не подтверждённые продакшн-расходы типичной установки исправлено. Это не отменяет саму опасность — токен-бомба параллелизма реальна, — но она не значит «любой, кто ставит OpenClaw, обречён платить $1.3М в месяц»: это единичный, дорогой этап разработки одной команды. Плюс к этому — реальная уязвимость CVE-2026-25253 (удалённое выполнение кода через кражу токена), и здесь тоже стоит уточнить: экспозиция в основном связана с неправильной настройкой пользователя (LAN-режим), а не только с настройками по умолчанию из коробки. OpenHands и MetaGPT — отличные блоки именно для «Строителя приложений» (Модуль 6), но не претендуют на роль оркестратора всего завода — у них нет общей памяти уровня всего бизнеса. И наконец — Claude Agent SDK: единственный кандидат, совместимый со всеми осями сразу, потому что это не альтернативная философия, а официальная библиотека поверх той же CLI-модели Claude, которую завод уже использует. Субагенты получают изолированный контекст, не наследуют историю родителя — это архитектурное решение именно той токенной боли, с которой ты живёшь проверено: глубина субагентов ограничена 5 уровнями, что похоже на то же ограничение, которое ты уже видел у OpenClaw. И отдельно, вне восьмёрки систем, — PAUL: это не платформа, а дисциплина поверх любого ядра — цикл План→Применение→Свод с явными критериями готовности, которую стоит взять независимо от того, что выберешь ядром.

Предварительная рекомендация — и важно подчеркнуть слово «предварительная»: она подтверждается на этапе roadmap (Модуль 11), когда будут учтены бюджет, хостинг и результаты первого пилота на одном сервисе. Но направление уже понятно. Ядро — Claude Agent SDK поверх твоей уже существующей подписки Claude. Это не «ещё один фреймворк со своей философией», это официальная библиотека прямо над той же CLI-моделью, которую твой завод использует сегодня: один процесс claude = одна сессия, история пишется на диск. По сути это прямое расширение того, что уже происходит в channel-hq — не миграция, а достройка.

Поверх этого ядра — три надстройки, и все три уже узнаваемы, потому что ты частично их изобрёл сам. Первая — дисциплина в духе PAUL (План → Применение → Свод) для режима «Строитель приложений» и «Консультант-фабрика MVP»: формальный критерий «готово к демо», а не просто «агент сказал done». Вторая — паттерн мышления LangGraph (состояние + чекпойнт), но НЕ обязательно сама библиотека: твой оркестратор уже неявно реализует граф стадий ⓪→⑨ с гейтами, и у тебя уже есть свой JSON-чекпойнт в state.json каждого проекта — тащить Postgres и LangGraph-библиотеку в завод стоит, только если твоя собственная реализация начнёт давать сбои, не раньше. Третья — локальный дебат-паттерн в духе AG2 для одного конкретного узла — судейской панели: параллельные варианты MVP критикуют и ранжируют друг друга. Это узкий, изолированный сценарий внутри одного модуля системы, для которого хватит нескольких параллельных субагентов Claude SDK с разными системными промптами — без внедрения целого фреймворка ради одной функции.

Отдельно нужно закрыть вопрос «а почему не OpenClaw, если он ближе всего по духу»: причина не в том, что OpenClaw плохой, а в том, что он дублирует то, что ты уже построил вручную и понимаешь лучше (память, гейты, оркестрация), да ещё и ценой реального риска стоимости и безопасности при полной автономии. Разумный компромисс — украсть идеи (файлы MEMORY.md/.learnings/, лимит глубины субагентов), но не ставить сам OpenClaw как внешнюю зависимость с чужим кодом скиллов. И третий важный вывод — n8n не мозг, а клей: он отлично закрывает точечные интеграционные мостики (webhook-триггер → цепочка HTTP-вызовов между сервисами завода), но не заменяет оркестратор — не строить на нём архитектуру всей системы.

Есть соблазн думать про хостинг как про спор «VPS или домашний ПК с 3090» — будто нужно выбрать одного победителя. На практике правильный ответ не выбор, а разделение обязанностей, как у тела: у тебя есть мозг снаружи — арендованный сервер, который живёт 24/7 независимо ни от чего, и есть мышцы по требованию — твой домашний ПК с RTX 3090, который просыпается только тогда, когда реально нужна тяжёлая видеокарта: локальный инференс, рендер видео, синтез голоса. Мозг никогда не спит, мышцы работают по вызову — организм в целом от этого не становится слабее, наоборот, экономнее.

Критично важная деталь архитектуры: домашний ПК НЕ должен быть на критическом пути ночного конвейера. Если ты выключил компьютер, ушёл гулять или просто лёг спать с закрытой крышкой ноутбука дома — фабрика видео не должна встать колом только потому, что 3090 сейчас офлайн. Значит, связь между VPS и ПК должна быть построена так, чтобы при недоступности домашней машины система тихо переключалась на облачную замену (тот же RunPod, которым ты уже пользуешься для озвучки), а не зависала в ожидании. Это тот же принцип, что и денежный гейт — не полагаться на хрупкое звено там, где можно поставить надёжный fallback.

Отдельно — давай честно поправим цифры, которые раньше гуляли в черновых расчётах экономики. исправлено Сборка ПК с RTX 3090 «под ключ» реально стоит $1500-3500, а не «от $900» — сама видеокарта нового поколения обходится примерно в $1050-1500, и это только один компонент. исправлено Аренда сопоставимой GPU-мощности в облаке (RunPod-типа) стоит реально $0,13-0,6 в час, а не $15 в час — это разница на два порядка, и она полностью меняет расчёт «когда своя видеокарта окупается». исправлено И маленький хостинг-план Hetzner (уровня CX22) стоит около €4,35 в месяц, а не €5,50. С честными цифрами «окупаемость своей видеокарты за 1-2 года» остаётся верной только против дорогих управляемых API-сервисов, а не против честной почасовой аренды GPU — и это меняет то, как стоит думать о своём железе: не как об обязательном условии, а как об одном из шести равноправных вариантов.

Сейчас твои сервисы разговаривают друг с другом почти как люди в цепочке из рук в руки — один сервис звонит другому напрямую и ждёт ответа: channel-hq вызывает генератор, генератор вызывает thumbnail-studio, и если хоть одно звено на секунду замешкалось — HTTP-запрос виснет 30 секунд, потом обрывается по таймауту, и кусок работы просто теряется, будто его и не было. Это работает, пока ты рядом и можешь вручную дожать зависшую стадию — собственно, ты и есть тот самый «клей», о котором сам говоришь как о главной боли.

Лекарство — брокер очередей. Разница похожа на разницу между тем, как хирург передаёт инструмент ассистенту из рук в руки (уронил — инструмент потерян), и тем, как кислород разносится кровотоком: если один капилляр временно пережат, кровь всё равно доходит до органа другим путём, просто чуть медленнее. С брокером задача не «звонит и ждёт», а кладётся в очередь и терпеливо там лежит, пока свободный воркер её не заберёт — даже если конкретный сервис в эту секунду перезапускается или упал. Ничего не пропадает, просто чуть откладывается.

Второй эффект брокера — параллельность становится естественной, а не удачей. Твоё собственное правило «запусти N» сегодня опирается на resource-governor, который по сути угадывает, сколько параллельных прогонов система выдержит; с очередью это перестаёт быть угадыванием — N задач просто встают в очередь, и столько воркеров, сколько реально свободно, разбирают их сами. А задачи, которые дважды подряд упали одинаково — уходят в отдельную «мёртвую очередь» (dead-letter queue), и утром ты видишь явный список «вот что реально сломалось», вместо того чтобы вручную перерывать логи в поисках зависшего места.

Важная честная поправка по ресурсам: осторожно ранние прикидки называли ~3 ГБ RAM на весь брокерный слой (Redis + RabbitMQ + несколько воркеров) — это верхняя, довольно щедрая оценка; при разумной конфигурации реалистичнее рассчитывать на ~1-1,5 ГБ. В любом случае на твоём VPS с 16 ГБ это укладывается с огромным запасом — это железный аргумент НЕ переезжать на другой сервер ради одного этого слоя, а добавить брокер поверх того, что уже стоит.

У тебя уже фактически есть панель управления — просто она разбросана по десятку разных адресов, SSH-сессии и памяти. Хорошая новость в том, что это не «начать с нуля», а «собрать то, что уже есть, в одном месте» — у тебя уже есть портал resource-governor на порте 4700, где новая тулка сама рождается с собственной плиткой. Расширить именно этот портал до полноценной mobile-first панели дешевле и естественнее, чем ставить сторонний чужой дашборд, который придётся подгонять под твою архитектуру.

Чего реально не хватает — это единого экрана расходов. Прямо сейчас у тебя есть логи по отдельным сервисам, но нет одного места, где видно: сколько денег сожрала эта ночь, эта неделя, этот канал. Это ровно то место, где живёт твой страх «монстр, кушающий $1000 в минуту» — и лекарство от страха не обещание модели, а цифра на экране, обновляющаяся в реальном времени.

Отдельная хорошая новость: твой approval workflow — гейты EDIT_PENDING и APPROVAL_PENDING — уже реализован лучше, чем у большинства систем, которые я видел в материалах по теме. Задача не «добавить одобрение с нуля», а разрешить панели постепенно СНИМАТЬ гейты там, где независимый критик уже доказал свою надёжность (твоя же идея «критик сам решает о публикации по чек-листу») — оставляя жёсткое человеческое подтверждение только там, где на кону деньги.

Telegram-бот в этой картине — не второй параллельный «мозг», а тонкий командный слой поверх того же самого API, что и веб-панель. У тебя уже есть рабочий прототип этого паттерна — x-research-daily, который пуляет тебе дайджест дважды в день. Расширить его с одностороннего пуша до двустороннего диалога («покажи очередь», «останови канал X», «подтверждаю трату») — это то же самое расширение, что и портал :4700, только в кармане, а не в браузере.

И последнее, самое приземлённое: диск на VPS, по внутреннему снимку, был занят на 91%. осторожно Эту цифру стоит перепроверить прямо сейчас, потому что она могла измениться, но сама логика неизменна: диск — тихий убийца автономии. Ночью, когда никто не смотрит, переполненный диск не кричит и не падает эффектно — он просто тихо блокирует запись нового файла в 3 часа ночи, и утром ты находишь не готовое демо, а оборванный на середине прогон без единого явного сообщения об ошибке.

У тебя сейчас 1-3 канала на полуручной фабрике. Цель года — десятки, на полной ночной автономии. Соблазн очевиден: включить orchestrator.mjs и снять оба гейта разом. Это ловушка. Правильный порядок — как с любой операцией: сначала выращиваешь и калибруешь независимого критика на существующем гейте APPROVAL, недели сверяешь его вердикты со своими решениями — и только когда он стабильно совпадает с тобой, снимаешь ручной гейт. Оркестратор включается ПОСЛЕ критика, а не вместо него.

Вторая часть разрыва — стадия LEARNING сейчас холостая: метрики с YouTube не текут обратно в память. Оживить её — значит применить трёхуровневую типологию памяти из Модуля 3 к твоим же трём банкам: global.json становится семантической памятью («темы про военку заходят лучше катастроф»), log.jsonl канала — эпизодической («14 июля тема Y дала CTR 6.1%»), настройки генераторов — процедурной («какие параметры Veo дают меньше QC-отказов»). Это не «завести базу данных» — это замкнуть контур, который у тебя уже архитектурно нарисован, но не подключён.

При переходе с 1-3 каналов на 10+ первым ломается не творчество, а инфраструктура: resource-governor — это твой брокер пулов, но десять каналов параллельно — качественно другая нагрузка, чем один; и тот же паттерн «эхо-камеры обучения», что уже был в thumbnail-studio (критик хвалит сам себя), при масштабе размножается линейно с числом параллельных петель, если критик не изолирован от генератора. И честная цифра, о которой нужно помнить именно на этом шаге: проверено 97% faceless-каналов не окупаются. Автономия ускоряет производство контента, но не гарантирует, что ниша выстрелит — масштабировать нужно вместе с отбором ниш (format-radar), а не вместо него. Отдельная деталь про риски бана: осторожно «канал банят за 2 недели полностью автономной публикации без QA» — сам факт риска реален, а вот точный срок — не проверенное число, не повторяй его как факт.

Модуль 6 разобрал сам цикл строителя (план→код→тест→критика→скриншот→доработка). Здесь — другой вопрос: откуда возьмётся вся «обвязка» вокруг этого цикла, чтобы он реально работал ночью на произвольном проекте, а не только в теории? Ответ дала сама индустрия одной фразой, которую стоит запомнить дословно: «harness важнее модели» проверено. Модель — это мозг, который у тебя уже выбран (подписка Claude). Harness — это весь слой вокруг: файл-конституция репозитория, библиотека скиллов, детерминированные хуки-стражники, субагенты с разными правами. И вот в чём хорошая новость: у тебя ЭТОТ слой уже построен — просто для видео, а не для кода.

Твой memory-bank с тремя банками, твой _STYLE_PLAYBOOK.md, твоё правило «стиль — это per-channel профиль, а не хардкод в коде» — это буквально harness для видео-домена, только ты не называл его этим словом. Задача направления 2 — не изобретать строителя приложений с нуля, а собрать АНАЛОГИЧНЫЙ комплект для кода: свой CLAUDE.md с конвенциями стека, скиллы «как задеплоить Node-сервис на мой VPS», «как подключить Caddy+SSO», «как написать docker-compose для нового сервиса» — и заметь: многое из этого у тебя уже есть в прозе в контрактах завода, просто не оформлено как переиспользуемый файл-скилл.

Практическое следствие — хуки вместо промптов там, где раньше было «попроси модель не забыть». Промпт можно уговорить отступить от правила в три часа ночи; хук физически блокирует действие кодом выхода. Это техническое воплощение твоего же закона №3 («скрипт вместо ИИ где можно»), просто применённое не к аудиту тулок, а к каждой точке, где ночной строитель мог бы сделать необратимое действие без проверки.

Это твой самый денежный режим: вечером ты приносишь боль реального бизнеса (кофейня теряет деньги на лишних сотрудниках, стройка теряет время на бумажной отчётности), а утром — 2-3 убедительных демо. Модуль 2 уже дал архитектуру: veer explorer-агентов с ЯВНО разными приоритетами + турнир разнородных судей. Здесь мы прикладываем её именно к MVP. Ключевая ошибка, которую легко совершить интуитивно, — запустить N одинаковых копий одного и того же агента на одну задачу. Это не даёт разнообразия: агенты без явно заданных разных углов сходятся к похожим решениям. Правильно — задать разницу явно в промпте каждого explorer'а: один строит CRM для записи клиентов, второй — telegram-бота лояльности, третий — dashboard управления запасами. Разные архитектурные ставки на одну и ту же боль, не N попыток одного и того же.

Вечерний сбор боли — тоже не свободный пересказ «на глаз». Исследование по гибридному подходу (явные правила + LLM) против чистого LLM-понимания незнакомого домена показывает разрыв в качестве, осторожно заявленный как 206% — цифру не повторяй как факт, а вот вывод стоит взять серьёзно: structured intake (полу-структурированное интервью с явными полями — процесс, точки решений, практические правила) работает надёжнее, чем «опиши боль в свободной форме и жди чуда». У тебя уже есть готовый кандидат на эту роль — сайд-проект client-interviewer, просто примени его как intake-слой перед запуском веера.

И последнее, самое важное для честности с самим собой и с клиентом: не обещай готовый продукт за одну ночь. Индустрия честно называет это «проблемой 70%» — ИИ быстро закрывает большую часть решения, а оставшиеся 30% (граничные случаи, безопасность, интеграция в продакшн, эмпатия к пользователю) требуют столько же человеческого труда, сколько и раньше. Утреннее демо продаёт не готовый продукт, а вход в оплачиваемую фазу доработки — это и есть твой настоящий доход, а не сам ночной прогон.

Твоя боль №1, названная тобой самим ещё до всякой теории, — «я сам клей между инструментами». Три направления, которые мы только что разобрали, рискуют остаться тремя отдельными заводами, между которыми ты вручную носишь информацию: увидел боль клиента — сам решил, кому передать; заметил денежную нишу в контенте — сам пошёл настраивать канал. Индустрия называет эту роль «человек-клей» (glue person) — и решение не «работать быстрее руками», а вырастить AI Glue Agent поверх читаемого источника истины.

Источник истины (Collaboration Plane) — это то место, куда ты просто бросаешь задачу человеческим языком: «новый канал», «клиент X, боли: ...», «построй мне тулзу Y» — веб-панель или Telegram, а не три разных интерфейса под три завода. Дальше один диспетчер (у тебя уже концептуально выбрана роль — Fable-оркестратор) читает эту доску и маршрутизирует задачу нужному заводу паттерном Handoff из Модуля 2: контент-фабрика, строитель приложений или MVP-веер. Это не новая идея, которую надо строить с нуля — это тот же принцип, что уже реализует channel-hq, только поднятый на уровень выше трёх направлений сразу.

Отдельная развилка, о которой стоит думать заранее, а не когда она уже сломается: общая память или передача сообщений между заводами. Если каждый агент видит только вывод предыдущего, а не общий контекст, — каждый рассуждает из своей частичной реальности, и опыт одного завода не помогает другому. Решение — единый knowledge graph: опыт, накопленный контент-фабрикой (какие ниши денежные, какие форматы заходят), должен быть доступен и разведчику возможностей, и MVP-строителю — и наоборот. Это прямое расширение того, что твой memory-bank уже частично делает внутри одной фабрики, только распространённое на всю систему.

Прежде чем разбирать очередной паттерн оркестрации, стоит остановиться и честно спросить: а на чём конкретно зарабатывают деньги те, кто уже это построил? Не «в теории может», а «вот кейс, вот цифра, вот откуда она взялась». Хорошая новость — таких людей уже много, и их модели заработка укладываются в понятную карту, а не в бесконечное разнообразие. Плохая новость — почти никто не зарабатывает чисто на самой архитектуре. Архитектура (оркестратор, память, критики — всё, что ты изучал в модулях 1-9) — это как хорошая иммунная система: она не приносит доход сама по себе, она делает возможным то, что приносит доход, работая надёжно и дёшево.

Смотри на это как на источник питания: у любого работающего агентного бизнеса есть ответ на вопрос «что система делает, пока я сплю, и что именно я в итоге продаю утром» — не абстрактно «ИИ», а конкретный артефакт: видео, сайт, отчёт, демо, подписка. Пять моделей встречаются снова и снова в разных рассказах: (1) агентства автоматизации — продают бизнесам решение их конкретной ручной боли, часто по подписке $5,000-10,000/мес на клиента, и по свидетельствам практиков именно «скучные» офлайн-отрасли (недвижимость, страхование, производство, юруслуги) платят больше всех — у них есть деньги и страх/неумение внедрять ИИ самим; (2) SaaS-инструменты на агентах — продукт, который сам является агентной системой (как Hyperagent от Airtable); (3) контент-фермы — твоё направление №1, монетизация внимания через рекламу/спонсорство/свои продукты; (4) продажа готовых MVP и автоматизаций бизнесам разово или по подписке — твой ключевой режим «консультант-фабрика»; (5) трафик → монетизация — нишевые сайты и SEO-контент, которые зарабатывают на рекламе, партнёрках или лидогенерации.

Важная отрезвляющая деталь, которую стоит принять сразу, а не открыть через полгода разочарования: даже соло-операторы, которые публично отчитываются о доходе $1M+ в год на агентах, почти всегда всё равно держат 1-3 человека на самых критических ролях — обычно это продажи и доверие клиента. Это не признак того, что автоматизация «не работает», это признак того, где именно проходит её реальная граница. Для твоего плана консультант-фабрики это значит: сама продажа клиенту — рукопожатие, разговор, демо у него в кабинете — скорее всего навсегда останется твоей личной работой, а не тем, что можно поручить агенту. И это нормально: агент экономит тебе недели стройки, а не заменяет твоё лицо перед клиентом.

Отдельно стоит взгляд практика с YouTube-канала, который прицельно разбирает заработок на агентах (Jack Roberts, @Itssssss_Jack): его конкретные цифры — контент-канал на автоматизированном пайплайне (скрипт → голос → визуал → сборка) выходит на уровень дохода порядка $30,000/мес через комбинацию рекламы, спонсорства и собственных продуктов, а быстрая сборка конверсионных сайтов под ключ продаётся клиентам по $10,000 за штуку при ~20 минутах активной работы по его технологии. осторожно Общий урок из его материала звучит знакомо, потому что это ровно твой закон №4: «инструменты — это не замена стратегии, а её ускоритель» — переписывай сценарии своим голосом и стилем, не публикуй «ИИ-слоп», потому что зрителей и алгоритм одинаково раздражает узнаваемая генеричность.

Модуль 8 уже дал тебе честный технический расчёт хостинга — цены, конфигурации, окупаемость. Здесь другой ракурс: не «что дешевле по счёту», а «что говорят люди, которые уже месяцами держат такие системы на своём железе». Это как разница между инструкцией к лекарству и разговором с врачом, который сам его прописывает пациентам не первый год — цифры те же, но появляется контекст, которого в инструкции нет.

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

Масштаб реальных трат у серьёзных операторов домашних агентных систем — $1,000-2,000/мес, с потреблением порядка миллиарда токенов в день суммарно по всем их «когтям» (агентам). Это, кстати, ровно верхняя граница твоего собственного бюджета из профиля — то есть ты целишься не в игрушечный, а во вполне серьёзный по индустриальным меркам масштаб, и стоит рассчитывать расходы соответственно, а не удивляться им постфактум.

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

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

Восемь пунктов: (1) избирательная автономия — твои два гейта на самых дорогих и необратимых шагах, а не один гейт «на всё»; (2) петля смерти — твоя история «залил 1 видео и завис», разобранная в Модуле 4; (3) хрупкие интеграции и «налог на опрос» — твои грабли с IG Stories и таймаутом FastGen, когда система тратит время и деньги, спрашивая API «готово?» вместо того, чтобы получить уведомление о готовности; (4) общая память вместо простой передачи сообщений между агентами — твой memory-bank, который ты построил как «общую нервную систему» раньше, чем прочитал, что индустрия называет это shared knowledge graph; (5) рассинхрон между параллельными агентами — изоляция воркспейсов (git worktree), нужная тебе для веера MVP, чтобы параллельные варианты не портили общий репозиторий друг другу; (6) стопроцентная автономность как задокументированная ошибка, а не идеал, к которому надо стремиться; (7) контекст эффективно используется лишь на половину заявленного окна, а не до последнего токена; (8) человек как «клей» между инструментами — твоя боль №1 из профиля, у которой уже есть архитектурный ответ.

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

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

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

«Мозг» — подписка Claude — остаётся без изменений, это уже правильный выбор, никакого пересмотра. «Ядро» — то есть то, что реально исполняет команды и держит роли/гейты/память — это Claude Agent SDK, потому что твой завод УЖЕ говорит на этом языке: `channel-hq` вызывает `claude -p` с мульти-аккаунт failover — это буквально subprocess-модель, на которой построен Agent SDK. Переезжать на чужую систему состояния (LangGraph, CrewAI) означало бы выбросить месяц работы и переучивать заново то, что уже освоено интуитивно.

Поверх этого ядра — три «надстройки», не платформы, а именно дисциплины, то есть способ мышления, а не библиотека для установки. Первая — PAUL для строителя приложений: явные критерии «сделано» вместо расплывчатого «агент сказал done» — прямая защита от вранья моделей о завершении задачи. Вторая — твоя же реализация `state.json` и чекпойнтов: этого достаточно, отдельный state-движок не нужен. Третья — AG2-паттерн дебатов, но только сам паттерн турнирного сравнения, применённый локально в судейской панели — не сама библиотека AG2 как зависимость.

Отдельно — что заимствуем идеями, но не кодом: у OpenClaw это формат `MEMORY.md`/`.learnings/` (простой файл с уроками, который читает каждый агент) и приём с лимитом глубины рекурсии субагентов — обе идеи ценные, но без публичного WebSocket-гейтвея OpenClaw и без чужих скиллов из общего каталога, потому что там уже находили вредоносный код. n8n — точечный инструмент для склейки внешних API и webhook-триггеров, не архитектурный слой: он никогда не станет «мозгом», только соединительной тканью там, где это дешевле, чем писать код руками. И лестница моделей (haiku → sonnet → opus) со стоп-кранами по деньгам — не отдельная фича, а встроенное свойство ядра с первого дня, а не то, что «добавим потом».

Ошибка, которую легко совершить — планировать железо от того, что уже стоит дома, а не от задачи. Твой ПК с RTX 3090 — это ОДИН из инструментов, не якорь, вокруг которого нужно строить всю архитектуру. Правильный вопрос не «куда пристроить 3090», а «какая задача что требует» — и дальше уже смотреть, каким узлом это закрыть дешевле и надёжнее.

Оркестратор, память, веб-панель и очередь задач — это управляющий контур. Он обязан жить на VPS: сервер работает 24/7, не зависит от того, включён ли твой домашний компьютер, ушёл ли ты из дома. Это ровно то, что у тебя уже есть — 16+ сервисов на Hetzner уже там, менять ничего не нужно, только достроить.

GPU-задачи — локальный инференс модели, рендер видео, генерация голоса — это мышцы по требованию: ПК с 3090 включается, когда нужна конкретная тяжёлая задача, и не обязан быть постоянно доступным — если он выключен, конвейер видео не должен вставать, просто теряется доступ к локальному инференсу, а вместо него подключается облачный резерв (RunPod, который ты уже используешь для озвучки). Связь между VPS и ПК стоит перевести с текущих reverse-ssh туннелей на Tailscale — это отраслевой стандарт для приватной mesh-сети между сервером и домашней машиной, и ты не одинок в этом паттерне: это ровно та же связка, которую независимо выстроил другой соло-разработчик (VPS + Mac mini + Tailscale, Telegram/Slack как пульт).

Ночной билдер приложений — отдельная история: он должен исполнять код в изолированной песочнице, без доступа к секретам боевого завода (`.env`, YouTube OAuth) — ни на VPS рядом с боевыми сервисами, ни на ПК с прямым доступом к сети завода. Это не паранойя, это прямой урок из индустрии: даже эксперты по безопасности признают, что «никто не считает свой сетап на 100% безопасным» — значит закладывать изоляцию нужно архитектурно, не полагаться на аккуратность.

Отдельный практический момент, который стоит решить в первую очередь именно потому, что он дешёвый: диск VPS занят на 91%. Это чинится за час и без него любые следующие шаги (очередь задач, структурированные логи) рискуют упереться в нехватку места в самый неподходящий момент.

Самая частая ошибка при внедрении такой системы — попытаться включить всё сразу: оркестратор, полную автономию, критиков, брокер, песочницу — одним вечером. Это прямая дорога к тому самому «Loop of Death» из Модуля 4, только теперь не в одном прогоне, а во всей архитектуре разом. Правильный путь — девять этапов, каждый со своей целью, тем, что реально трогаем, риском и понятным критерием «готово, можно идти дальше».

Порядок не случаен: сначала — самое дешёвое и низкорисковое (диск, аудит открытых портов), потом — то, что закрывает дыры без изменения архитектуры (структурированный лог решений), и только в середине пути — по-настоящему рискованные вещи (снятие гейта одобрения, включение оркестратора). Первый кандидат на «включить агентность» — это ОДНА вертикаль, не вся фабрика разом: начать с evaluator-optimizer (он у тебя уже частично есть), затем orchestrator-workers в режиме только чтения, и только потом — полный цикл до автоматического approval.

Всё, что мы разобрали за одиннадцать модулей, сводится к одному честному вопросу: что конкретно ты делаешь в понедельник утром? Ниже — семь дней, реализуемых на твоём СЕГОДНЯШНЕМ стеке, без переписывания архитектуры. Ничего из этого не требует ждать «идеального момента» — каждый день закрывает один конкретный кусок из этапов 1-3 предыдущего урока.

Честная планка ожиданий, чтобы не разочароваться на третий день: реалистичный результат первой недели — 85-95% готовности инфраструктуры для следующих этапов, а не «система заработала сама». Окупаемость такой стройки — это недели калибровки, не мгновенный эффект с первой ночи.