Commitments inbox

A commitment is a small follow-up obligation an agent inferred during a heartbeat — “I should ping Anita tomorrow at 9 am about the Q4 plan”, “Reply to legal’s email by Friday”. The platform stores commitments as memory entries with a state machine and surfaces them tenant-wide in the Inbox screen of Workspace Control.

Why commitments exist

Without explicit tracking, agents that “remember to do something tomorrow” lose those obligations between heartbeat ticks. The agent’s free-form memory might mention “need to follow up with legal” but nothing fires the follow-up at the right time.

Commitments solve this with three pieces:

Inference: after each substantive heartbeat tick, the agent reflects on its output and asks itself “did I just commit to something?”. If yes, it writes a commitment record with a due_at timestamp.
State machine: pending → attempted → sent / dismissed.
Delivery: when due_at is reached, the platform’s heartbeat system tries to deliver the commitment (post into the agent’s group room, send a DM, depending on the commitment’s delivery_target). On success → sent; on attempt → attempted.

Inbox tour

Open Workspace Control → Inbox.

The badge in the top nav shows the count of open commitments (pending + attempted). When any pending commitment’s due_at is overdue, the badge turns amber.

Filter pills:

Pill	What it shows
Open (default)	pending + attempted — actionable items
Pending	inferred but not yet due / attempted
Attempted	platform tried to deliver, awaiting confirmation
Sent	delivered successfully
Dismissed	user-dismissed; no longer actionable
All	every state

Per-row info

Each row shows:

State pill (color-coded)
Title + content of the commitment
Tags (if any)
Owning agent (marketing:cmo) — click to jump to the agent detail page
Due — relative time (in 2h, 3d ago for overdue items)
Dismiss button (only on pending / attempted)

Overdue rows are border-highlighted in amber.

Dismissing

Clicking Dismiss sets the state to dismissed. The commitment is no longer actionable and drops out of the Open filter. Use this when:

The work is done and you don’t need the agent to follow up
The commitment was misinferred
You handled it directly outside the agent flow

Dismissed commitments stay in the database (visible via the Dismissed pill); they just don’t generate more delivery attempts.

Where commitments come from

Commitments are inferred by the heartbeat invoker after each substantive (non-HEARTBEAT_OK) heartbeat tick. The agent’s post-pass prompt asks roughly:

Did anything in your last response commit you to follow-up action? If so, return JSON: {commitments: [{title, content, due_at, delivery_target?, tags?}]}. Otherwise return {commitments: []}.

The inferred commitments go through guard-rails:

due_at bounds: refuses dates more than 1 hour in the past or more than 365 days in the future (rejects hallucinated timestamps)
Dedup: same agent + similar content within 24 h is silently skipped (no spam from repeated heartbeats)
Atomic claim: when a commitment becomes due, the platform’s delivery worker claims it atomically (pending → attempted) so two concurrent workers can’t double-fire

Delivery flow

When due_at arrives:

Atomic update: pending → attempted. If the row was already attempted/sent/dismissed, skip (someone else has it).
Try to deliver according to delivery_target:
- Agent’s primary group room → post a message
- User DM (channel-system fallback)
- Default: a system message in the agent’s main conversation
On success → sent; on failure → leave at attempted, log the error, retry on next tick (with cooldown).

Commitments vs. heartbeats

It’s natural to ask: isn’t a commitment just another heartbeat?

Related but different:

A heartbeat is a recurring routine on a fixed schedule.
A commitment is a one-shot obligation with a specific due_at. After delivery (or dismissal) it’s done.

A heartbeat creates commitments as a side-effect; a commitment lives in agent memory with state until done. The inbox shows commitments only — heartbeats are on the dashboard / agent detail page.

Practical patterns

Triage daily: glance at the badge each morning. Open > 0 means agents have stuff queued waiting for users (review drafts, confirm sends). Click through and dismiss what’s irrelevant.
Overdue badge → look hard: amber badge means agent attempts are failing repeatedly. Check the audit log for the delivery error.
Trust the dedup: if you see the same commitment over and over, the dedup logic broke or someone is pushing manually with bad timestamps — file a bug.