Расписание важнее дорожной карты: где живёт работа в компании на агентах

Что показывает расписание команды из трёх человек

В одной агентной команде, наблюдаемой с весны 2026, GitHub Issues открывают примерно раз в неделю. Расписание (crontab) смотрят каждый день. В нём 23 активные записи: проверка воронки в 9:00, ночной дайджест исследований в 02:00, проверка состояния агентов каждые два часа, еженедельный отчёт по базе знаний в понедельник в 7:30. Полный список покрывает примерно 80% работы, которая физически происходит в компании за неделю.

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

Почему дорожная карта перестаёт отражать реальность

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

В компании на агентах эта карта систематически врёт в сторону недооценки. Большая часть операции выполняется не как набор тикетов, а как набор повторяющихся циклов, которые запускаются сами и завершаются сами. Никто не открывает карточку «прогнать дайджест исследований за вчера» — эту работу делает агент по расписанию. Никто не назначает владельца для «проверить здоровье воронки» — владелец это 0 9 * * *. Сторонний наблюдатель видит шесть карточек и делает неправильный вывод: «команда мало делает». А команда за то же время выполнила 140 запусков процедур, из которых 12 потребовали человеческого вмешательства.

Этот разрыв растёт по мере того, как управляемый контур исполнения (managed harness) становится стандартной частью стека. Платформы агентов — публичные материалы Anthropic Engineering, анонс OpenAI про новые инструменты для агентов, AWS Bedrock Agents — сводят стоимость запуска новой процедуры к одному файлу настроек. Это значит, что центр операционной массы быстро смещается от «человек делает задачу» к «расписание запускает агента, человек смотрит исключения». При таком распределении дорожная карта перестаёт быть основной картой работы — она становится картой исключений.

Похожий сдвиг уже случался в инженерии данных. dbt-core и Apache Airflow превратили аналитику из «возьмите тикет, напишите запрос» в «определите модель, она пересчитывается по расписанию». Граф зависимостей расписания (directed acyclic graph, DAG) стал документом, который точнее описывает работу команды данных, чем проект в Jira. Компания на агентах повторяет эту траекторию на уровне всей организации, не только аналитики.

Что меняется, когда работа становится расписанием?

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

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

Где живёт работа в компании на агентах

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

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

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

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

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

Почему расписание — это политический документ

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

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

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

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

Почему cron, а не очереди событий?

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

Как отмечает Andrej Karpathy в публичных выступлениях про операционные особенности агентов:

«Большинство интересной работы агента — это не реакция на пользователя, а его собственный внутренний цикл размышления и проверки.» — Andrej Karpathy, ex-Director of AI, Tesla

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

Журнал событий показывает, что произошло; расписание — что компания делает всегда.

Как отличить этот сдвиг от обычного DevOps?

Существует контраргумент: «запланированные задачи всегда были, это просто DevOps в новой обёртке». Контраргумент верен наполовину. Технически — ничего нового. Концептуально — отличие в статусе и составе того, что попадает в расписание.

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

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

Эту разницу хорошо описывают практики наблюдаемости агентских систем. Как пишет Charity Majors в блоге Honeycomb, наблюдаемость нужна не за инфраструктурой, а за поведением системы — и в агентной операции это означает наблюдаемость за тем, что процедура реально делает с бизнесом, а не только за тем, что процесс не упал. Тот же сдвиг описан и в материалах Мартина Фаулера про эволюционную архитектуру и в практиках инженерии надёжности из Google SRE Book: когда поведение системы определяется не одним релизом, а постоянным фоном изменений, главным артефактом становится механизм этих изменений, а не их слепок.

Как говорит Charity Majors:

«Наблюдаемость нужна, чтобы задавать системе новые вопросы в продакшене, а не подтверждать заранее известные.» — Charity Majors, CTO, Honeycomb

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

Что это меняет для трёх типов читателей

Фаундер. Если на питче инвестор спрашивает «расскажите про дорожную карту», полезный второй ответ — «вот наше расписание». Не вместо, а вместе. Разговор сдвигается от будущих обещаний к тому, что компания делает каждый день уже сейчас и где живут точки контроля. Тестовый вопрос: можете ли вы за 60 секунд показать список из 10–20 процедур с явным владельцем и явным результатом? Если ответ «у нас всё в Jira» — компания операционно не агентная, что бы ни было написано на сайте.

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

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

На какие сигналы смотреть дальше

Несколько публичных индикаторов покажут, насколько сдвиг становится массовым. Первый — появление в основных инструментах управления проектами (Linear, Jira, Asana) явной поддержки «повторяющейся задачи агента» как отдельного типа сущности, наравне с тикетом и проектом. Когда станет встроенной концепцией, формализация «расписание как объект управления» закрепится. Второй — публичные кейсы компаний, которые ведут открытый список своих процедур как часть страницы «about/engineering». Это агентный эквивалент «we use Postgres and Kubernetes». Третий — рост MRR у инструментов класса оркестратор-для-агентов, заточенных не под конвейеры данных, а под рабочие потоки агентов.

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

Главное

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

FAQ

Это значит, что управление проектами больше не нужно в агентной компании?

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

Что если бизнес по природе плохо ложится на расписание — например, консалтинг или редкие сделки?

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

Чем задача в расписании отличается от обычной запланированной задачи, которая и в классических компаниях есть?

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

Как защититься от «долга расписания» — записей, которые никто не помнит, зачем нужны?

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

Можно ли называть компанию агентной, если у неё в расписании пять записей и команда из 50 человек?

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

Что отличает хорошую процедуру от плохой?

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