Feed

The Feed is the daily-priorities view for your reps: the one list that answers what needs doing today. Not an inbox to clear out — a worklist the system assembles from everything that happened in the workspace. Every card carries a decision or an action; once it’s done, it disappears.

This is where the product’s purpose pays off: more revenue with fewer people, because nobody is hunting for where their attention belongs.

The four lanes

Every card falls into exactly one of four lanes, in this order:

Lane	What’s in it
Call	call hints, when a signal makes direct contact the right move
Reply	inbound replies with their draft, due follow-up messages, escalations
Follow up	stalled threads, nurture cases, booked meetings, meeting prep, manual tasks
Approve	qualification and reply reviews, deliverability alerts, new learnings, workflow notifications

Within a lane, priority (1–10) sorts, and age breaks the tie — the most urgent card sits on top. A reply therefore doesn’t land in an inbox that lives apart from the rest: it stands next to the meeting booked yesterday and next to the approval still outstanding.

Where the cards come from

From live operations, not from a separate task manager. Around twenty producers write into the same card list:

• Inbound replies from the channel webhooks (email, LinkedIn, WhatsApp) — thread and draft attached to the card
• Proactive routines — follow-up alerts, nurture, meeting prep, deliverability warnings, sequence standstill
• The optimizer — proposals out of the learning loop, learnings to approve
• Your own automations — a workflow posts a card with a feed_notify step, an agent does it through the create_feed_action tool

The path for “tell me here when X happens” is a step, not a special case.

Card types are data, not code

The Feed is not fixed to its built-in card types. Every type is an entry in a registry — shipped globally or added per workspace — and any individual card may override it:

• Display (card_config) — label, icon, colour, the text on the primary button
• Execution (execution_config) — which MCP tool runs when “Execute” is clicked, with arguments drawn from the lead, the card and the draft

The Feed therefore makes the same promise as the rest of the building kit: the platform supplies the lanes, the sorting and the gates — the agent points the cards at how this particular workspace operates, without any platform code being written for it.

State and history

Every card runs pending → executed, skipped, auto-handled or failed. “Open” is the default view; “Done” and “All” are history. Purely informational items never render as a card at all — they roll up into the auto-handled line at the foot of the list. The Feed stays a worklist, not a log.

Skipping is not dismissing: on an optimizer proposal, the underlying decision is rejected and written back, and the negative signal returns to the learning loop.

”Mine” or “all”

The Feed can be narrowed to your own area of responsibility. “Mine” shows what belongs to the signed-in user’s playbooks and senders; “all” shows the whole workspace. Workspace-wide cards that belong to no playbook — a learning awaiting approval, say — stay visible in both views so they can’t slip past anyone.

On top of that you filter by playbook (multi-select), by sender and by status, plus free-text search across lead, company, reasoning and draft.

Individual lanes are switchable per workspace — call hints or knowledge approval, for instance. When a lane is off it is entirely invisible, rather than sitting around as an empty section.

The principle: nothing pauses silently

When the system spots a problem — poor deliverability, a disconnected account, copy that isn’t landing — it does not stop on its own. It puts a proposal in the Feed and you decide. This is deliberate: a silent automatic stop is indistinguishable from “running normally” from the outside, and that is exactly how outages nobody notices come about. The rule holds in the other direction too: anything that goes live and takes effect externally passes through the Feed as an approval first.

Proposals have to be evidenced. Cards from the optimizer only appear together with the comparison data they rest on. A blanket “refine playbook” with no data behind it is suppressed rather than shown.

The gates apply here too

A reply is edited in the Feed, not merely displayed: review the draft, adjust it, send — or reject and escalate. The thread hangs off the card, so nobody has to switch tools to form a judgement.

The send button is no side door. Every send out of the Feed runs through the same gates as any other: unsubscribe and blacklist are checked first, and the check fails closed rather than waving things through when the lead can’t be loaded reliably. Unsubscribes, bounces, out-of-office and clearly negative replies never produce a card in the first place.

A card can also halt a lead’s live outreach across every channel at once — email, LinkedIn and WhatsApp, with a farewell message for approval if you want one.

What the Feed is not

Not a replacement for the detail views: changing structure, rebuilding a campaign or running a table happens in the web app or through Command. The Feed bundles the decisions that are due today — not the work you plan around them.