Tasks
Tasks manage assigned work, due dates, delegation, and review state.
Tasks organize assigned work, due work, delegation, completion, and review state. Use the Tasks screen at /dashboard/tasks to see work needing attention, then use the tasks pack when an agent needs the matching review corpus. Tasks are different from Workflows, which automate a graph instead of organizing assigned work.
The app screen is the place to review task context and ownership. Architect discovers a current capability before it reads or changes task data, so it does not assume that every request for “my tasks” means the same task collection. Use Modes when a task action has a possible external effect.
Read the task review work
tasks.tasks.list is a free, synchronous read of the campaign review corpus. It merges campaign items, pending outreach items, and engagement-gated inbound-reply tasks. That corpus is not a general to-do list, so start by describing the work you need reviewed instead of supplying an assumed task id.
Architect uses search to locate the task capability and get to obtain its exact schema before running the read. In the app, compare the returned items with the Task screen before you choose one for review. The capability contract, rather than the display label alone, determines which task attributes and actions the current request can use.
Inspect the item before review
Read the selected item’s task kind and displayed context before asking Architect to review it. A task can represent ordinary assigned work, a campaign decision, outreach work, an inbound-reply follow-up, or a publishing decision. The same review verb can have a different effect depending on that kind.
Ask Architect to explain the proposed state change in plain language. Check the audience, channel, scheduled content, or related object on the Task screen, then decide whether the action reflects the work you intend. This separates reading the review corpus from carrying out an action that could affect another system.
A task can point to work created elsewhere in Dreamstate. Follow the linked object when it is present, and use its JSON id for later calls when the returned data needs to identify it. A web_url can open the object in the app, but it does not replace an identifier in a capability request.
Understand review effects
tasks.tasks.review is synchronous, but synchronous does not mean harmless. It can update task state and, for designated task kinds, pass content to an external social provider. Read the fetched review contract and the task’s effect before using it in live work.
| Review action | Result |
|---|---|
| List | Reads the campaign review corpus without changing an item. |
| Reject | Sets the reviewed item to rejected and does not publish content. |
| Accept an ordinary item | Changes task state for task kinds that do not carry a provider action. |
| Accept a publishing item | Can submit LinkedIn or X content for real scheduling or publication. |
Use Tasks with the other execution surfaces
Tasks help a person or agent decide what needs attention. A Workflow can create or route operational work, while a Sequence controls a prospect journey, and an Inbox thread is the place to read an existing conversation. Keep these concepts separate so that a review decision does not get mistaken for an automatic delivery action.
When the task concerns an outreach reply, inspect the conversation first in Inbox. When it concerns a post, inspect the draft and Calendar context described in Social posts and publishing. When it concerns a run already in progress, check its Run record rather than trying to reproduce the work through task review.
This separation also makes handoffs clearer. The Task identifies the decision, the destination surface shows the work itself, and the Run records durable execution when there is one. Use all three records when an outcome involves several teams or systems.
When it goes wrong
Search and get before run, especially when the request says “my tasks.” The task review corpus and a personal to-do list are different reads, so a broad request can return the wrong kind of work for the decision you need to make. Ask for the related campaign, outreach, inbound reply, or publishing work when that is the intended scope.
If the selected task would create an outward effect, do not guess its kind or use the review action against an unfamiliar item. Preserve the item for later, inspect its displayed context, fetch the current review schema, and confirm the effect it describes. Rejection is the safe recorded state when the decision is not to submit the item.
If a result names a Run, open the Run and read its status instead of assuming the provider action has completed. A completed review request and a completed scheduled or published post are not the same fact. Use the returned object identifiers and app links to follow the state in the appropriate screen.
Keep the task visible until the corresponding destination surface shows the expected state. This avoids treating a request receipt as evidence that a later delivery or schedule has occurred. If the result is incomplete, use its related Run or object record for the next investigation.