Add a tasks system: run ObjectiveAI commands on a schedule.
Why
Plugins no longer have a persistent daemon. A plugin's lifecycle is now tied to an agent connecting to its MCP server (#271, #272) — when no agent is connected, nothing of the plugin is running. That's the right model for on-demand tools, but it removes the plugin's ability to do work over time: there is no longer a long-lived process that can wake up, poll, react, or run periodic work on its own.
Tasks fill that gap at the platform level rather than by giving plugins back a daemon. A task runs an ObjectiveAI command on a schedule. If a plugin needs to perform actions of its own over time, it doesn't need its own runtime — it can schedule a task that, for example, spawns a script agent which uses the plugin. The scheduled command is the unit of recurring work; everything a plugin could want to do over time composes from "run this command on a schedule."
Big picture
- A task is an ObjectiveAI command plus a schedule. When the schedule fires, the platform runs the command.
- Tasks are created and deleted — there is a way to add a task and a way to remove it.
- Recurring work is expressed as scheduled commands; a plugin's "background" behavior is a task that runs a command (e.g. spawning a script agent that uses the plugin), not a resident plugin process.
Deliberately open (design phase)
This issue intentionally does NOT pin down the mechanics — scheduling model, storage, where tasks execute, identity/auth of a scheduled run, the exact command surface, failure/retry behavior, or how tasks relate to the daemon lifecycle. Those are for the design phase; the goal here is to establish the need and the shape (scheduled ObjectiveAI commands, creatable and deletable), not to lock in an architecture.
Relationship
Motivated by the containerized, daemon-less plugin model (#271, #272) and the agent-tied plugin lifecycle. Composes with script agents (a natural payload for a scheduled run) and the plugin frameworks (#277–#280), which may want to expose task creation as a first-class authoring affordance.
Add a tasks system: run ObjectiveAI commands on a schedule.
Why
Plugins no longer have a persistent daemon. A plugin's lifecycle is now tied to an agent connecting to its MCP server (#271, #272) — when no agent is connected, nothing of the plugin is running. That's the right model for on-demand tools, but it removes the plugin's ability to do work over time: there is no longer a long-lived process that can wake up, poll, react, or run periodic work on its own.
Tasks fill that gap at the platform level rather than by giving plugins back a daemon. A task runs an ObjectiveAI command on a schedule. If a plugin needs to perform actions of its own over time, it doesn't need its own runtime — it can schedule a task that, for example, spawns a script agent which uses the plugin. The scheduled command is the unit of recurring work; everything a plugin could want to do over time composes from "run this command on a schedule."
Big picture
Deliberately open (design phase)
This issue intentionally does NOT pin down the mechanics — scheduling model, storage, where tasks execute, identity/auth of a scheduled run, the exact command surface, failure/retry behavior, or how tasks relate to the daemon lifecycle. Those are for the design phase; the goal here is to establish the need and the shape (scheduled ObjectiveAI commands, creatable and deletable), not to lock in an architecture.
Relationship
Motivated by the containerized, daemon-less plugin model (#271, #272) and the agent-tied plugin lifecycle. Composes with script agents (a natural payload for a scheduled run) and the plugin frameworks (#277–#280), which may want to expose task creation as a first-class authoring affordance.