Tasks

The tasks namespace is the platform's confirmation gate. Any action an agent wants to take that mutates real state — sending an email, posting to a social network, creating a deal — passes through TASKS before it executes.

The rule

Agents propose. Users dispose.

Read-only operations (semantic search, dashboard queries, summary generation) run inline during an agent turn. Write operations are serialized to a planned action in TASKS and surface in the Inbox.

You see the planned action, review it, and click Confirm. Only then does the worker actually execute. Until you confirm, nothing in the outside world has happened.

Why this design

Three reasons:

LLM hallucination is a real risk. Agents are confident even when wrong. Auto-executing every "I'll send this email" the agent generates would be a way to lose customer trust fast.
Audit trail. Every action in your tenant has a single point of provenance — "user X confirmed this planned action at timestamp Y." Compliance + DSAR-friendly.
Undo affordance. A pending action is reviewable, editable, and discardable. An executed action is none of those.

The planned-action shape

When the orchestrator decides to act, it emits a planned action that looks like:

{
  "kind": "send_email",
  "to": "alex@acme.com",
  "subject": "Following up on Q3 pricing",
  "body": "Hi Alex,\n\nQuick follow-up...",
  "rationale": "Alex's last reply was 12 days ago; the deal is in 'proposal sent' stage.",
  "cites": ["deal:acme-q3", "contact:alex@acme.com"]
}

The TASKS namespace renders this into the prompt as a structured block so the agent knows what's pending — useful in multi-turn flows where the next user message might be "actually change the subject line" rather than "Confirm."

Confirmation flow

Agent generates a planned action.
Worker writes it to the tasks table, status pending.
Realtime push surfaces it in the user's Inbox.
User reviews, optionally edits any field, clicks Confirm.
Worker picks up status confirmed, executes the action via the appropriate integration adapter (Gmail SMTP, Ayrshare API, CRM write, etc.).
Status moves to executed (or failed with the error captured).
The execution event becomes part of episodic memory for future recall.

Editing before confirm

Every field of a planned action is editable in the Inbox. The edit is logged as part of the action's audit trail — so when you look back at "what did we actually send", you see both the agent's proposal AND your edits, side by side.

If you edit substantively (the rationale would change), the Inbox prompts you to re-run the orchestrator with your changes so the rationale stays accurate. This is optional — you can confirm with edits as-is.

Discarding

Discarded actions move to status discarded with the reason optionally captured. They stay queryable for audit purposes but don't reappear in the Inbox.

The orchestrator sees discarded actions in MEMORY on subsequent runs — so if it proposes the same action again, it's already aware you rejected the prior version, and can choose to either modify or drop the suggestion.

TASKS in multi-turn flows

When you ask a follow-up question in a chat that already has a pending action, the TASKS block is in the prompt — so the agent's response can reference it ("I see I proposed an email to Alex; do you want me to revise it instead?"). This keeps the conversation coherent without you having to repeat context.

Auto-confirm

Some action types support auto-confirm — useful for internal, low-risk actions (e.g. "create an internal note on this deal"). The allowlist is per-tenant + per-action-kind, configured in Settings → Tasks. Off by default; opt in deliberately.

Even when auto-confirmed, the action still goes through TASKS — the audit trail and ability to discard retroactively don't disappear, they just don't block.

Bulk operations

If the agent proposes 10 deals to advance to the same stage, you see one pending action with 10 entities attached, not 10 individual pending actions. Confirm once, execute all. Edit one to drop a specific entity, confirm the rest.