A conversation is not a queue
Interactive chat is a good place to shape work and a bad place to own its lifecycle. The window closes. The session ends. Another agent wakes up tomorrow. If the task exists only in the conversation, the system has no durable answer to who owns it, what state it is in, or what should happen when it stalls.
Voxelbox turns that intent into explicit state. A task has an assignee, status, events, artifacts, a result, and an optional parent routine. It can outlive the session that created it.
Definitions and instances are different things
A routine is a durable definition: trigger, cadence, authority, allowed tools, budget, review policy, and success criteria. A task is one concrete run. Keeping them separate lets the system change a standing responsibility without rewriting the history of every previous attempt.
Ad-hoc dispatch enters the same lifecycle. So does a signal Scout decides is worth acting on. Different sources create work; the runtime gives the resulting task the same ownership and evidence model.
Coordination needs a record
Mail and threads let agents ask for help, hand off context, and make decisions without pretending they share a brain. The substantive message remains a durable artifact. A faster signal can announce that something changed, but the notification is not the memory. If the signal bus disappears, the work should still be there.
Deliberation is the multi-agent version: several identities contribute independently against an anchor, someone synthesizes, and the operator closes the decision. That shape prevents consensus theater while preserving the reasoning that informed the choice.
Background work changes the product
Once work can wake up without an open window, scheduling becomes the easy part. The hard parts are admission control, idempotency, budget, retry behavior, attention policy, and escalation. A retry storm taught Voxelbox this rather directly: forty-three copies of the same heartbeat are still forty-three tasks, even if each one has an excellent prompt.
Those controls belong in the runtime. Prompts can request good behavior. Orchestration has to enforce it.
The same runtime can carry several businesses
I use this lifecycle across hospitality products, sports data, publishing and career operations, and Voxelbox itself. Some work starts with me. Some starts on a schedule. Some begins when a repository changes, a message arrives, a webhook fires, or an agent notices something worth acting on. The interface may be closed for all of it.
The business logic stays specific to the product. Voxelbox supplies the reusable operating structure around it: an identity with context, a bounded task, a route to the right harness, a communication path, and a durable result. That is the scale I care about. One agent system can participate in several very different businesses without pretending those businesses are the same thing.
If the work matters tomorrow, it needs more than a transcript today.