Missions: close your data gaps, together

    A mission is a named, persistent campaign to fill a missing field, or a few, on a set of records, collaboratively. People drop in answers, Rig's agent proposes values from your data, a Slack heartbeat keeps the team chipping away, and confirmed values write back to your source of truth only once an admin approves.

    The problem it solves

    Every team has a version of the same complaint: our data is incomplete for field X. Deal attribution is missing, account owners are stale, a segment column is half empty. Fixing it is an ad-hoc chore that nobody owns, so it never quite happens, and the reporting built on top slowly stops being trustworthy.

    The frustrating part is that the answers usually exist, scattered across call recordings, outbound tools, and the memories of whoever worked each record. In the launch demo above, the gap is CRM attribution: one simple question reveals that 62 deals, 61% of the demo CRM, have no attribution at all. A mission turns recovering those answers from a spreadsheet exercise nobody finishes into a tracked, measurable campaign with a finish line.

    How missions work

    A mission converges three inputs on one gap: people, the agent, and a heartbeat that keeps both moving. It works in five moves:

    1. Start from a question. Ask Rig in Claude or Slack how bad the gap is, for example how many deals are missing attribution. When the answer comes back ugly, kick off a mission with one message: start a mission and fill this in.
    2. Rig stages the campaign. A mission is named and persistent, so it survives until the gap is actually closed. Rig sets it up with allowed values that follow the target system's existing configuration, and a staging table you can watch fill up as answers arrive.
    3. People contribute. Answer in a conversation with Rig, or just reply in the mission's Slack thread: Acme came from the June webinar. Human answers land as confirmed values, each with a record of who gave it.
    4. The agent proposes. An opt-in nightly run has Rig's agent work each open mission, deriving missing values from your data: a query, a join, a pattern, never a guess. Agent answers land as proposed, and the agent can never confirm a value, close a mission, or write anything back.
    5. The heartbeat, then an approved writeback. A twice-daily heartbeat posts progress in Slack: a progress bar, a contributor leaderboard, and rotating questions about the gaps that remain. When the mission is complete, an admin reviews the staged values and approves the writeback. Rig never bulk-writes to your systems unattended.
    Example mission: backfill deal attribution
    crm.deals62 deals, 61%, missing attribution
    dealstageattribution
    AnalyticalProposalMissing
    StreamflowDiscoveryMissing
    Acme CorpClosed wonWebsite
    Your team in Slack

    The mission heartbeat posts progress and asks: who knows where Streamflow came from?

    Analytical: investor referral
    Agent: outbound campaigns

    A nightly run checks your other connected sources for signal.

    11 deals matched in HeyReach
    Agent: call recordings

    Granola calls had no signal: reps never ask where deals heard of us. Useful coaching note.

    No signal found
    attribution_backfillvirtual data model · 1 row per deal
    dealattributionstatus
    AnalyticalReferralConfirmed
    11 dealsLinkedIn outboundProposed
    Streamflow?Open
    Admin approves, Rig writes back to the CRM
    Diagram of an example mission: a CRM where 62 deals are missing attribution. Answers arrive from reps in Slack, which land as confirmed, and from the agent's nightly run matching deals against HeyReach outbound campaigns, which land as proposed; call recordings are checked but hold no signal. Every value stages in a per-mission virtual data model called attribution_backfill with its status (confirmed, proposed, or open) and source recorded, and an admin approves the writeback to the CRM at the end.

    An example: backfilling deal attribution

    The launch demo above runs the first mission use case: backfilling attribution on the 62 deals missing it. The first answer is a human one, telling Rig that one deal came from an investor referral. It shows up in the mission table moments later as a confirmed value, marked as a referral, with a log of who wrote it.

    Then the agent takes a turn. Asked to look at sales call recordings and propose other sources, Rig reports that the Granola call recordings hold little signal, because the reps never ask prospects where they heard about the company. That is a sales coaching insight in its own right. But it also finds 11 of the missing companies inside HeyReach LinkedIn outbound campaigns, so one instruction stages all 11 as proposed values with outbound as the source.

    The rest will not come from data at all, and that is the point of the heartbeat. The mission posts its status in Slack, shows how many records are still open, and asks directly for help on the ones it cannot resolve, so the team keeps chipping away until the mission is complete.

    For technical audiences

    For technical audiences

    Missions are deliberately not a new subsystem. The mission itself is just campaign identity and status. The data lives in a per-mission virtual data model overlay with per-field provenance, so every value knows where it came from, and an agent proposal can never downgrade a human confirmation.

    The agent's nightly run is code-restricted to propose-only: it derives candidate values from your data but cannot confirm, close, or write back. The writeback is a human-approved step that writes only confirmed values that differ from the source, through the same approval path as any other Rig action.

    The spec is declarative: the record set is defined by a query, the fields are arbitrary, and the writeback target is pluggable. That is what makes missions generic. Any fill-in-the-blanks-on-this-set-of-records problem fits the same shape, and CRM fields are just the first. Cross-source proposals work because missions sit on top of Rig's context layer, which spans every connected source rather than just the system being backfilled.

    Was this guide helpful?