Destroy

Як worker згортається, коли агенту він більше не потрібен. Життєвим циклом володіє orchestrator — а не LLM — тож teardown детермінований і нічого не тече.

Життєвий цикл: Deploy → Use → Destroy.

Стани сесії

Рядок у Postgres — AgentRuntimeSession — відстежує живий рантайм; под не тримає довговічного стану:

pending → starting → running → idle → stopping → stopped
                       ▲          │
                       └──────────┘  a follow-up turn reuses the session, resets the idle timer

AgentRuntimeSession { agentId, taskId?, status, runtimeType, cpu/mem/storageLimit, ttlSeconds, k8sJobName, namespace, workerUrl, logsUrl, started/lastActivity/stoppedAt }.

Два виходи

Тригер	Хто	Що відбувається
Кінець турну → idle	orchestrator	сесія позначається idle і лишається теплою, не вбивається, тож наступний турн тієї самої розмови перевикористовує її (без холодного старту)
Явний release	мозок (LLM)	коли роботи явно більше немає (one-shot задача, користувач попрощався) мозок негайно шле release через control-канал

LLM може видати підказку done для раннього release, але типово все автоматично через reaper.

Idle-reaper

Реалізований як delayed-задачі BullMQ за ключем sessionId, переплановуються на кожному heartbeat:

• Light idle 60–120с → стоп · Heavy 30–60с · Browser живий до простою браузера · Warm/преміум 10–30 хв.
• Наступний турн у вікні перевикористовує сесію і скидає таймер.
• Зниклі heartbeat'и → Core позначає сесію failed і гасить її (захист від зомбі).

Очистка при стопі (порядок важливий)

По спливанні або release, перш ніж Job зникне:

1. Переконатися, що виходи вивантажено з workspace у system/file (об'єктне сховище).
2. Стерти emptyDir-workspace.
3. Видалити Job; виставити AgentRuntimeSession.status = stopped.

ttlSecondsAfterFinished — підстраховка для нормально завершених Job; reaper закриває idle і зомбі-сесії, які не завершилися чисто.

Жорсткі стелі (щоб нічого не текло)

• activeDeadlineSeconds — жорсткий max час виконання (RuntimeProfile.maxExecSeconds); runaway-рантайм вбиває k8s.
• Стеля max-idle — навіть профіль Warm лише подовжує idle-вікно; він ніколи не вимикає стелю.
• Аудит — кожна сесія логує start/stop/tools/artifacts через admin/audit.

А агент живе далі

Знищення worker'а не завершує агента. Мозок лишається живим: він далі стримить користувачу, обробляє agent/cron і follow-up'и, і може викликати свіжий worker пізніше. Worker був лише тимчасовим придатком; агент (рядок у DB + цикл api) персистить.

Дивіться також

• Deploy — провіжен, Job, runtime-профілі.
• Канал інструментів — кадр release, його вікно на завершення і що означає мовчання.
• Use — модель сесії та control-канал, який несе release.
• Implementation — build-prompt для цієї підсистеми.
• Модель рантайму — потік одного турну від початку до кінця.