From Conversation to Work Queue: Tasks, Dependencies, and Review
A LobeHub conversation becomes a different kind of object when the user needs an Agent to keep working after the chat window is closed. This chapter examines how a Task preserves the instruction, assigns responsibility, records one or more runs, orders dependencies, and creates a review boundary. The practical result is a way to design asynchronous work without confusing “the Agent produced an answer” with “the work is complete and acceptable.”
The difference is not just a new status label. A chat turn is organized around a response. A Task is organized around an outcome that may require several turns, several Agents, comments, documents, and a human decision. LobeHub’s Task system carries the operation model from the conversation into a durable work object.
A Task has a lifecycle and an owner
The current Task schema stores more than a name and a checkbox. A Task has an identifier, an instruction, a creator, optional project and parent relationships, an Agent assignee, an optional human assignee, priority and order, lifecycle status, visibility, configuration, execution context, and timestamps. It can be connected to run Topics, comments, documents, dependencies, and activity records. This gives the system a place to keep both the request and the history of what happened to it.
The first lifecycle boundary is creation versus execution. When a user says, “Break the launch research into three pieces,” the correct result may be a set of Tasks in a backlog, not three Agents starting immediately. LobeHub’s Task tools make that distinction explicit. Creating or editing a Task records work; runTask is the action that actually starts an assigned Agent in a new or continued Topic. Changing a status to running is not equivalent to launching the Agent. That separation prevents an ambiguous planning statement from becoming an unintended model run with real cost or external effects.
The instruction and the description have different jobs as well. The instruction tells the Agent what to accomplish; the description helps a person recognize the work in the interface. A useful instruction states the deliverable, relevant material, constraints, and completion condition. A title such as “Competitor briefing” is not enough for an Agent to know which competitors, time range, sources, or output format matter. LobeHub’s own guidance treats Task creation as something to describe as one would describe work to a teammate.
Assignment has two independent dimensions. assigneeAgentId names the Agent that performs the work. assigneeUserId names the workspace member who owns the outcome. They can coexist, because execution and accountability are not the same role. A research Agent may gather the evidence while a product manager remains responsible for deciding whether the briefing is ready to use. The system also requires a real workspace member before assigning a human owner; a name or chat handle is not enough, and the Task tools instruct the Agent to resolve it rather than guess an identifier.
LobeHub snapshots the assigned Agent’s model and provider when a Task is created. This is a subtle but important form of reproducibility. If the Agent’s default model changes tomorrow, an existing Task should not silently change its execution assumptions merely because it has not yet run.