Inbox

The Inbox is the surface that closes the loop on every agent- proposed action. Anything the agent wants to do that mutates real state — send an email, post a tweet, create a deal, schedule a meeting — passes through here for your review.

It's the user-facing side of the TASKS namespace.

What you see

A queue, newest-first, of pending actions. Each row shows:

  • Action kindsend_email, post_social, create_deal, etc.
  • Summary — one-line description of what will happen.
  • Source — which surface or run proposed it (Today card, chat, Inbox follow-up loop).
  • Recipient / target — who's affected.
  • Age — when it was proposed.
  • Status chippending, pending review, scheduled, failed.

Click a row to expand. The full action payload is editable in place (every field), with the agent's rationale shown alongside.

The two key buttons

ButtonEffect
ConfirmWorker executes the action. Status moves to executed. Becomes part of episodic memory.
DiscardAction marked discarded with optional reason. Doesn't reappear in Inbox; stays queryable for audit.

There's no auto-confirm by default. Per-tenant + per-action-kind allowlists can enable auto-confirm for low-risk action types (typically internal notes, internal task creations) — see Settings → Tasks → Auto-confirm.

Edit before confirm

Every field of a planned action is editable. Common edits:

  • Tweak the email body's tone.
  • Add a CC.
  • Move the scheduled time.
  • Change the deal stage the action will set.
  • Adjust the recipient list (e.g. exclude someone).

Edits are logged as part of the action's audit trail — when you look back later, you see both the agent's proposal AND your edits side-by-side.

If your edit substantively changes the action's intent (the rationale would no longer fit), the Inbox surfaces a small "re-run rationale" prompt so the audit trail stays accurate. Optional.

The follow-up loop

The Inbox isn't just one-shot. It maintains a follow-up loop for actions that have ongoing implications:

  • Sent an email? The Inbox tracks reply detection (via the connected email integration) and surfaces follow-up suggestions after 3/7/14 days of silence.
  • Posted to social? The Inbox tracks engagement and surfaces amplification suggestions when a post performs above baseline.
  • Created a deal? The Inbox tracks stage movement and surfaces stuck-deal recovery suggestions.

Each follow-up is itself a planned action: confirm, edit, or discard. The loop continues until you mark it complete or the underlying entity reaches a terminal state (deal closed, post expired).

Funnel metrics

For admins, the Inbox has a Funnel view showing tenant-wide:

  • Proposed — total actions agents proposed this week.
  • Confirmed — what % of proposed actions got confirmed unchanged.
  • Edited — what % got edited before confirm.
  • Discarded — what % got discarded.
  • Executed → outcome — for actions with measurable outcomes (email reply rates, deal advancement), what fraction succeeded.

This is the closest thing the platform has to "is the agent useful." A high discard rate means the agent is misreading intent; a high edit rate means it's close but not quite right; a high confirm-unchanged rate with high outcome success means the agent is genuinely operating leverage.

Realtime updates

The Inbox is a live surface — new pending actions appear without a refresh (via the Realtime WebSocket, see Knowledge graph). Status changes (pendingexecuted) push live, so multiple users watching the Inbox see each other's confirms without polling.

Bulk operations

When the agent proposes the same action across many entities (e.g. "advance 10 deals to next stage"), the Inbox groups them as a single bulk action. You can:

  • Confirm the bulk — runs all 10.
  • Edit one entity's payload while leaving the others as proposed.
  • Drop specific entities from the bulk.
  • Split into individual actions if you want different treatment per.

Bulk actions execute serially in the worker, with per-entity status. If one fails (e.g. CRM API rejects one), the others proceed; the failure is captured for retry.

Search + filter

Top-right search filters by action kind, recipient, source surface, date range. Useful when looking for "what email did the agent send to alex@acme last week" — quick sanity check.

Empty state

When the queue is empty, the Inbox surfaces:

  • A short tip about how the queue gets populated.
  • Suggested next surface based on recent activity (usually Today or the active module dashboard).
  • Recently executed actions (last 7 days), so a "what did the agent do for me this week" view is one click away.

Read next

  • Tasks concept — the lower-level model behind the Inbox surface.
  • Dashboard — the per-module view where many Inbox actions originate.