The Cognitive Scheduler: Decoupling Time from Execution
VANI's Cognitive Scheduler strictly separates the determination of *when* a task should run from *what* the task does, acting purely as a gatekeeper of time and priority rather than an executor of logic.
- Reference
- V019
- Project
- VANI
- Status
- Implemented — Phase 0
- Evidence
- high
- Source
- 019-cognitive-scheduler.md
Context
For an AI system to be truly autonomous, it must be able to schedule its own future work—consolidating memories at night, following up on a task in two hours, or running periodic self-evaluations.
This requires a scheduler. However, tightly coupling the scheduling logic with the cognitive tasks creates a tangled architecture. VANI solves this with a dedicated Scheduler subsystem designed with strict boundary constraints.
The Decision
From docs/architecture/SCHEDULER.md:
"The Scheduler decides when work is eligible to run. It never performs the work itself."
The Scheduler's responsibilities are rigidly constrained:
- Task scheduling (delayed and periodic)
- Priority management
- Queue management
- Execution ordering
What it explicitly does not do:
- Task execution
- Business logic
- AI inference
- Event routing
The Lifecycle of Scheduled Work
A task passes through the Scheduler in a decoupled lifecycle:
- Created (by any cognitive service)
- Registered (into the Scheduler's queues)
- Waiting (held until conditions/time are met)
- Ready (marked as eligible)
- Dispatched (handed off to the execution layer)
- Completed
The Scheduler merely transitions tasks from Waiting to Ready when the clock or event conditions dictate. It then relies on the Event Bus or Runtime to actually hand the task back to the relevant domain owner for execution.
Evidence
docs/architecture/SCHEDULER.md— Scheduler subsystem specificationdocs/phases/phase0/IMPLEMENTATION_REPORT.md— Scheduler implemented in Phase 0
Diagnosis
Established: The Scheduler exists as a fully implemented Phase 0 infrastructure component, following the exact same Foundation → Context → State Machine → Engine → Executor → Orchestrator layering as the rest of the OS.
Observation: This design allows cognitive services (like Memory or Planning) to enqueue future thoughts or actions without keeping a thread alive or writing custom sleep loops. It provides the foundation for proactive AI behavior.
What I Learned
To build proactive AI, you cannot rely on user-prompted execution or basic cron jobs. You need an internal system scheduler that understands priority, queues, and delays, but remains entirely ignorant of what the AI is actually thinking or doing. Separation of concerns applies to time just as much as it applies to data.
Broader Principle
Orchestration is not execution. A robust system scheduler should be a dumb calendar with a smart queue. It knows exactly when an item is due and how important it is, but it has zero understanding of the item's contents.
Technical References
docs/architecture/SCHEDULER.md— Architecture doc
Failure sequence
On the record- Attempt
- Failure
- Diagnosis
- **Established:** The Scheduler exists as a fully implemented Phase 0 infrastructure component, following the exact same Foundation → Context → State Machine → Engine → Executor → Orchestrator layering as the rest of the OS. **Observation:** This design allows cognitive services (like Memory or Planning) to enqueue future thoughts or actions without keeping a thread alive or writing custom sleep loops. It provides the foundation for proactive AI behavior.
- Lesson
- To build proactive AI, you cannot rely on user-prompted execution or basic cron jobs. You need an internal system scheduler that understands priority, queues, and delays, but remains entirely ignorant of what the AI is actually thinking or doing. Separation of concerns applies to time just as much as it applies to data.
- Next iteration