CRM operations

The CRM lives in Lobu memory. Two entity types — lead and pilot — hold current state; events of type lead:* / pilot:* are the append-only history. The converted-to relationship links a lead to the pilot it became.

Funnel stages (the stage field on lead)

signal → trial → conversation → pilot → customer, plus cold (went quiet / not a fit). "Reach" (an impression, a passing tweet view) is not a stage — no lead record until there's a signal.

Stage	Enter it when…
signal	starred the repo, followed on X, @-mentioned Lobu, commented on an issue
trial	cloned / ran lobu run / completed the quickstart / asked a real deployment question
conversation	DM'd, requested a demo, booked a call, said "we want to deploy this"
pilot	signed up for a paid pilot — open a pilot entity, link with converted-to
customer	converted from pilot to a paid contract
cold	three touches with no response, or explicitly not a fit

Creating / enriching a lead

1. Search first — search_memory({query: "<github handle | x handle | email | company>"}). If a lead exists, enrich it; don't duplicate.
2. If new: create the lead entity with metadata {name, company, source, stage, github_handle, x_handle, email, notes}. Set stage to the lowest stage the evidence supports.
3. save_memory({content: "<who, company, source>", semantic_type: "lead:created", entity_ids: [<lead>, <source connector event>]}).

Logging an interaction

After any touchpoint (a meeting Burak had, a DM exchange, an issue reply you drafted):
save_memory({content: "{type, summary, next_action, date}", semantic_type: "lead:interaction", entity_ids: [<lead>]}). Update the lead's notes / stage if the touch moved it (see "advancing a stage").

Advancing a stage

1. save_memory({content: "{from, to, reason}", semantic_type: "lead:stage_changed", entity_ids: [<lead>]}).
2. Update the lead entity's stage field.
   Never change stage without the matching event.

Opening / updating a pilot

• Open: create a pilot entity {company, seats, mrr, status: "active", start_date, success_metric, lead_id}; converted-to relationship from the lead; save_memory({..., semantic_type: "pilot:created", entity_ids: [<pilot>, <lead>]}); move the lead to pilot.
• Update: save_memory({content: "{from, to, note}", semantic_type: "pilot:status_changed", entity_ids: [<pilot>]}); update the entity's status (active → won | lost | paused); if won, move the lead to customer.

Reads the operator asks for

• "who starred us this week and isn't tracked?" — pull recent stargazer events (github connector), diff against lead entities with a github_handle, return the gap.
• "show the pipeline" — lead entities grouped by stage, each with last-touch date and next action, ranked within stage by closeness-to-pilot.
• "state of the pilot?" — the pilot entity + its pilot:* events, newest first.

Weekly digest (used by the funnel-digest Automation)

A Slack message, in this shape — keep it short:

1. One line at the top: the single recommended action this week.
2. Funnel snapshot: counts per stage, and what moved (new leads, stage changes, new/updated pilots).
3. Top-of-funnel: stars / X mentions / HN+PH activity since last digest.
4. Stale leads: anyone in conversation with no touch in 7+ days — flag for follow-up.
5. Gaps: e.g. "12 new stars, 0 became leads — are we capturing the right signal?"

Always end with the next action, never just the status.