Hermes и Linear: как менеджер задач становится внутренним лупом для AI-агентов

Менеджер задач обычно воспринимают как место, куда люди складывают поручения. В агентной системе этого мало. Если Hermes, Codex, Claude Code и другие исполнители реально работают над проектом, задачник должен стать не доской контроля, а внутренним лупом: принять намерение, выдать контекст, запустить действие, принять результат, оставить след и передать следующий шаг.

Я пришел к простой формуле: Linear хранит намерение, Hermes исполняет и ставит кроны, Supabase хранит хронологию, GitHub показывает фактические изменения, а AI Class OS собирает все в одну картину.

Почему одного чата недостаточно

Чат удобен для старта. Я могу написать: «почини страницу», «добавь тест», «проверь аналитику». Агент поймет задачу и начнет работать. Но через три дня появляется вопрос: что именно изменилось, кто это сделал, где файл, какой был результат проверки и что осталось.

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

В нормальной агентной системе задача должна быть машинно читаемой. У нее есть статус, владелец, исполнитель, ссылки на файлы, комментарии, проверки и следующий шаг. Именно здесь Linear становится полезен: его GraphQL API позволяет читать и менять задачи программно, создавать issue, обновлять статус и работать с комментариями.[1]

Главное правило: не «нет задачи — нет работы»

На практике жесткое правило «нет задачи Linear — нет работы» ломает скорость. Иногда нужно быстро проверить гипотезу, починить баг, поправить страницу или перезапустить сервис. Формальность перед действием будет мешать.

Поэтому я бы формулировал иначе:

Нет следа в системе — работа считается черновиком.

След может быть разным:

Linear issue;
комментарий в существующей задаче;
запись в `os_events`;
Git commit или PR;
отчет cron-задачи.

Смысл не в бюрократии. Смысл в том, чтобы любая работа стала видимой для следующего участника: человека или агента.

Как выглядит внутренний луп

Я смотрю на систему как на цикл из семи шагов.

Человек формулирует намерение. Это может быть голос, Telegram, комментарий в Linear или команда Hermes.
Hermes нормализует задачу. Уточняет цель, ограничения, владельца и критерий готовности.
Linear фиксирует намерение. Создается или обновляется issue.
Агент берет работу. Он получает не всю память проекта, а нужный контракт: задача, файлы, допуски, критерии проверки.
Кроны поддерживают ритм. Проверяют статусы, запускают аудиты, напоминают о зависших задачах, собирают данные.
Результат возвращается в систему. Комментарий в Linear, запись в журнал, ссылка на commit, тестовый вывод.
Следующий шаг появляется автоматически. Если работа завершена — закрываем. Если есть блокер — создаем follow-up. Если нужна проверка человека — статус меняется на review.

Это и есть внутренний луп. Linear не заменяет агента. Hermes не заменяет задачник. Они замыкают друг друга.

Что делает Linear

Linear в этой схеме — не интерфейс для сотрудников. Это движок задач.

Он хранит:

проекты и направления;
issue и статусы;
исполнителей и владельцев;
комментарии;
историю изменений;
связи между задачами.

Важная часть — API. Linear публично описывает GraphQL endpoint https://api.linear.app/graphql, персональные API-ключи и OAuth для доступа, а также мутации для создания и обновления задач.[1] Это значит, что агент может не скриншотить интерфейс, а работать с задачником как с системой.

Еще один слой — вебхуки. Linear может отправлять HTTP POST при создании, обновлении или удалении данных, например по задачам, комментариям, проектам и документам.[2] Для агентной системы это принципиально: нам не нужно постоянно опрашивать все задачи. Достаточно принять событие, проверить подпись и обновить свой журнал.

Что делает Hermes

Hermes — это операционный слой. Он понимает человеческую команду, знает правила проекта, умеет пользоваться инструментами и может создавать scheduled jobs.

Кроны в Hermes — не просто напоминалки. По документации Hermes cron jobs могут быть разовыми или регулярными, могут загружать один или несколько skills, доставлять результат в исходный чат или другой канал, запускаться в свежих агентных сессиях и работать в no-agent mode, когда по расписанию исполняется только скрипт без LLM.[4]

Это меняет роль задачника. Linear отвечает на вопрос «что должно быть сделано». Hermes отвечает на вопрос «кто и как это будет делать по расписанию».

Примеры:

Linear issue: «каждое утро проверить сайт и аналитику»;
Hermes cron: раз в день запускает аудит, собирает HTTP-коды, метрики, ошибки JS;
результат: комментарий в issue и запись в журнал;
если найден блокер: создается новая задача или меняется статус старой.

Так задача перестает быть мертвой карточкой. Она начинает жить в ритме.

Зачем нужен Supabase или `os_events`

Git хорошо показывает, что изменилось в файлах. Linear хорошо показывает, что планировалось. Но между ними есть жизнь: кто запустил проверку, какой агент взял задачу, какой cron сработал, что вернул API, почему задача ушла в блокер.

Для этого нужен журнал событий. У нас эту роль выполняет Supabase / os_events.

Supabase дает обычную Postgres-базу, не абстракцию над ней: таблицы, SQL, программный доступ, функции, триггеры, webhooks и Realtime-слой строятся вокруг этой базы.[3] Для операционного журнала это удобно: можно хранить события структурно и потом показывать их на портале.

Событие может быть таким:

{
  "ts": "2026-08-27T15:00:00Z",
  "actor": "hermes/default",
  "event": "cron_completed",
  "linear_issue": "AI-44",
  "target": "docs.ai-class.tech/ai-class-os",
  "result": "api 200, tests 40/40",
  "next": "wait for human review"
}

Это не замена Linear. Это черный ящик системы. Если завтра другой агент продолжит работу, он увидит не только задачу, но и цепочку действий.

Где в этой схеме GitHub

GitHub не должен быть задачником. Он должен быть доказательством фактических изменений.

Рабочее правило:

Linear: что хотели сделать;
GitHub: что реально поменяли;
Supabase: когда и кем это прошло через систему;
AI Class OS: как это выглядит для человека;
Hermes: кто двигает цикл.

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

Как передавать задачи между агентами

Передача между агентами не должна выглядеть как «прочитай весь чат». Это слишком шумно.

Нормальный контракт передачи:

{
  "task": "Исправить синхронизацию задач на вкладке Tasks",
  "linear_issue": "AI-44",
  "owner": "Denis",
  "agent": "infra",
  "context": [
    "страница: /ai-class-os/#tasks",
    "API: /api/linear/issues",
    "проблема: пустой первый проект"
  ],
  "done_when": [
    "live page returns 200",
    "tasks count > 0",
    "test suite passes",
    "comment added to Linear"
  ],
  "handoff": "если API работает, передать UI-агенту; если нет, вернуть infra"
}

Так один агент не держит всю память. Память держит система. Агент получает только то, что нужно для шага.

Это особенно важно для больших проектов. Один агент может заниматься backend, второй интерфейсом, третий проверкой, четвертый контентом. Linear держит статус и связи, Hermes выдает контракты, журнал хранит факты, портал показывает состояние.

Где кроны реально полезны

Кроны нужны не для «напомни мне». В агентной инфраструктуре они закрывают регулярные петли.

Вот рабочие типы cron-задач:

Watchdog. Проверить, что сайт, API, бот или webhook живы.
Audit. Раз в день собрать ошибки, битые ссылки, JS-ошибки, SEO-сигналы.
Sync. Сверить Linear, GitHub, Supabase и портал.
Backlog hygiene. Найти зависшие задачи без владельца, без next step, без следа.
Report. Сформировать короткий отчет Денису или Ирине.
Escalation. Если задача зависла больше N часов — поднять статус или отправить сообщение.
Content loop. Найти материал, собрать черновик, поставить review, не публиковать без допуска.

Главное: cron не должен жить отдельно от задач. Если регулярная проверка существует, у нее должен быть владелец, описание и место, куда она пишет результат.

Минимальная архитектура внедрения

Я бы начинал не с большого портала, а с простого контура.

1. Linear workspace

Создать проекты: Product, Infra, Content, Community, Analytics. Договориться о статусах: Backlog, Todo, In Progress, Review, Done, Blocked.

2. Hermes profile

Один головной профиль, который знает правила проекта, допуски и карту агентов. Он не делает все руками, а раздает работу.

3. Bridge service

Небольшой FastAPI-сервис:

принимает Linear webhooks;
проверяет `Linear-Signature`;
пишет события в `os_events`;
умеет создавать комментарии и issue через GraphQL;
отдает срез для портала.

4. Cron layer

Hermes cron jobs:

`project-audit` раз в час;
`stale-linear-issues` раз в день;
`deploy-smoke` после релиза;
`weekly-trace-report` раз в неделю.

5. AI Class OS

Человек смотрит не в пять инструментов, а в одну страницу: задачи, цели, агенты, события, блокеры, последние изменения.

Что важно не перепутать

Linear — не память агента. Это структурированное намерение и история задач.

Supabase — не задачник. Это журнал событий и состояние витрины.

GitHub — не операционный дневник. Это доказательство изменений в коде.

Hermes — не человек с ответственностью. Агент исполняет, но ответственность остается у владельца задачи. Этот принцип совпадает с рекомендациями Linear для agent interaction: агент должен быть явно обозначен, работать в привычных паттернах платформы, показывать состояние и не быть конечным ответственным лицом.[5]

Крон — не магия. Это расписание. Если prompt не самодостаточный, skill не загружен, credential не доступен или доставка не настроена, автоматизация будет ломаться молча или шуметь не туда.

Практический протокол Project Trace

После любой работы агент должен оставить короткий след:

Project Trace
- Что изменил:
- Зачем:
- Где файлы:
- Linear issue:
- Commit / PR:
- Что проверено:
- Что осталось:

Если issue не было до начала, агент создает его после факта как ad-hoc fix или пишет событие в журнал. Это не идеальная бюрократия. Это бухгалтерия смысла.

Итог

Будущая операционная система компании — это не один суперапп. Это связка инструментов, где каждый отвечает за свой слой.

Linear держит намерение. Hermes двигает исполнение. Кроны поддерживают ритм. Supabase фиксирует хронологию. GitHub доказывает изменения. AI Class OS показывает картину человеку.

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

Вот тогда менеджер задач перестает быть доской с карточками. Он становится операционной памятью команды.

TG @rogovpro · YT @imrogov · denrogov.com

Sources

[1] https://linear.app/developers/graphql

[2] https://linear.app/developers/webhooks

[3] https://supabase.com/docs/guides/database/overview

[4] https://hermes-agent.nousresearch.com/docs/user-guide/features/cron

[5] https://linear.app/developers/aig

TG @rogovpro · YT @imrogov · denrogov.com

Разбираю агентные процессы и операционные системы для бизнеса в канале.