Task Registry:
память задач
между сессиями
Чат закрылся — задача исчезла? В agentic-системе так быть не должно. TASK_REGISTRY — оперативная память runtime: что открыто, кто владелец, какой статус, куда маршрутизировать. Без ID задача не существует.
Задача в чате ≠ задача в системе
«Сделай деплой до пятницы» в переписке с Claude — не задача. Это намерение в prompt. Завтра новый чат, другой агент, другой контекст — и «деплой до пятницы» растворился в истории, которой уже нет.
Task Registry переводит намерение в запись с идентификатором: одна строка в Google Sheets (или аналоге), которую видят все скиллы контура, оркестраторы и штабы разработки. Это structured memory для действий — не факты, а work-in-progress.
Чем Task Registry не является
В стеке IRI Lab два реестра не конкурируют — они про разное:
-
MEM
MEMORY_REGISTRY Правила, решения, протоколы (MEM-XXX). «Как мы работаем» — долго, стабильно, редко меняется.
-
TSK
TASK_REGISTRY Конкретные действия (LOS-XXX, BOS-XXX, AS-XXX). «Что делаем сейчас» — живёт неделями, меняет статус каждый день.
Если записали «всегда деплоить через GitHub Actions» — это MEMORY. Если «задеплоить gateway v2 до 25.06» — это TASK. Смешивать в одном bucket — главный источник путаницы у начинающих agentic-команд.
Анатомия записи
Минимальный контракт задачи в AIOS / AI-BOS:
ID — LOS-XXX (личное, AIOS, Agent Studio) или BOS-XXX (агентство, клиенты). Без ID задачу нельзя передать в dev-штаб.
ACTION — одно конкретное действие с контекстом, не «разобраться с проектом».
STATUS — OPEN → IN_PROGRESS → WAIT → DONE. Запрещены «New», «новая», произвольные статусы.
OWNER — строго Pavel (в текущей модели).
SOURCE_CHAT — реальный скилл, где задача родилась: /bos-boss, /los-hq, /ai-lab.
Перед записью задача проходит task_normalizer.py — валидация полей, формата даты, запрет пустых ACTION. Exit code 1 = исправить, не писать в таблицу.
Две таблицы — два контура
LOS Personal — личное, система, разработка AIOS, Agent Studio (AS-XXX тоже сюда).
Agency Tasks — клиенты и операционка агентства (BOS-XXX).
Разделение не бюрократия: у контуров разные оркестраторы, разные штабы (/los-hq vs /bos-hq), разная зона файлов на сервере.
Жизненный цикл задачи
1. Оркестратор или скилл фиксирует задачу → append_row в нужную таблицу → STATUS: OPEN.
2. Исполнитель берёт в работу → IN_PROGRESS.
3. Ждём внешнее (клиент, деплой, ревью) → WAIT.
4. Закрытие → DONE + CLOSED_AT + запись в dev-journal + отчёт в SOURCE_CHAT.
При старте скилла с CHAT_NAME команда skill_context.py подтягивает открытые задачи контура — агент не спрашивает «на чём остановились?», он уже видит список.
Маршрутизация в штаб
Задача без ID не передаётся в dev-штаб. Это жёсткое правило: REDIRECT PACKET в /los-hq или /bos-hq содержит только подтверждённый ID из реестра.
📦 REDIRECT PACKET (в штаб) ОТ: /bos-boss КОМУ: /bos-hq ЗАДАЧА: BOS-142 — поправить webhook AI-BOS ТАБЛИЦА: Agency Tasks → ID подтверждён в реестре
Штаб меняет код, не чат. Закрытие — обратный сигнал в SOURCE_CHAT с артефактом. Так runtime связывает «обсудили» и «сделали» без потери нити.
Антипаттерны
- Задача только в prompt — «мы же договорились вчера» без строки в таблице.
- Дубли без проверки — три OPEN на одно и то же ACTION; агенты работают параллельно и ломают production.
- STATUS как настроение — «почти готово», «в процессе» вместо enum; фильтры и automation не работают.
- Нет SOURCE_CHAT — непонятно, куда отчитаться; задача висит в WAIT вечно.
Task Registry в мультиагентной системе
Оркестратор (/bos-boss, /ai-lab) планирует и ставит задачи. Специализированные агенты (agent-dev-backend, agent-mkt-direct) исполняют в своей зоне. TASK_REGISTRY — общая доска, на которую все смотрят: что OPEN, что блокирует, что эскалировать.
Это не замена таск-трекеру Jira для больших команд. Это минимальный контракт для одного оператора + рой агентов: достаточно структуры, чтобы система не теряла нить между сессиями.
Связка с памятью
MEMORY_REGISTRY — «как работаем». TASK_REGISTRY — «что делаем сейчас». Вместе с persistent memory это continuity agentic-системы. Вопросы — форма связи.