Celery and Agency lifecycle =========================== Celery moves work onto background workers. It is **not** the Agency domain lifecycle. Not the same thing ------------------ :: Celery Task ≠ Execution Celery Task ≠ Run +--------------------+--------------------------------------------------+ | Concept | Meaning | +====================+==================================================+ | Celery Task | Transport job (``task_id``, worker, retries) | +--------------------+--------------------------------------------------+ | Execution | Business intent (mission + agent + user) | +--------------------+--------------------------------------------------+ | Run | One technical graph attempt on a Thread | +--------------------+--------------------------------------------------+ Domain status fields live on Agency models. Flower / Celery state can disagree temporarily; trust the DB for product status. What Celery does here --------------------- Tasks in ``agency.tasks`` (names as registered): * ``agency.start_mission`` — run ``Agent.execute`` for a dispatch * ``agency.resume_mission`` — ``ThreadRunner.resume`` after HITL answer * ``agency.tasks.minute`` — sample / ops helper * ``ollama_models_update`` — refresh Model rows from a provider (Ollama tags or OpenAI-compatible ``/models``) Host apps may add more (indexing, scrapers, scheduled jobs). Same rule: persist business outcomes on domain models when the work matters to Agency. HITL and workers ---------------- On interrupt, the ``start_mission`` worker exits after persisting Run / Interruption. Hours later, answering the interruption enqueues ``resume_mission``. No worker sits blocked in ``ask_human``. Behaviour note -------------- ``resume_mission`` currently assigns ``execution.status = SUCCESS`` after resume returns. Prefer reading **Run** statuses when diagnosing multi-step HITL; see :doc:`../../tutorials/human-in-the-loop`. See also: :doc:`execution`, autodoc :doc:`../../framework/agency/tasks`.