LL MM Ops

Status
in-flight
Tier
Tier 3 — Cross-cutting bet
Owner
Ryan Colston
Started
2026-04-15

One-line description. A second FUB instance for Market Manager work. Agents are the "people," not clients. Separate phone number. Separate dataset.

Why

The client FUB tracks my agents' work with buyers and sellers. The MM FUB tracks my work managing my agents.

Different people. Different pipelines. Different privacy rules. Different phone numbers. Mixing them in one instance would create a mess no one could untangle. Pipeline: Prospect → Contacted → Qualified → Offer → Onboarding → Active → Departed.

Current state

Project code home set up. Dedicated BigQuery dataset live. Secret in Secret Manager. CLAUDE.md scoped to enforce the boundary.

Next 3 actions

  1. Configure the 7-stage pipeline in MM FUB (Prospect → Departed).
  2. Wire BigQuery sync from MM FUB into pospj-480915.mm_ops with mm_ table prefix.
  3. Document the cross-FUB rule in the project CLAUDE.md (never join fub_data.* to mm_ops.*).

Decisions log

In-project decision log:

Date Decision
Initial build Dedicated dataset mm_ops with mm_ table prefix
Initial build Separate API secret FUB_MM_API_KEY in Secret Manager
Initial build Scoped CLAUDE.md to prevent cross-contamination in code
Initial build master_data.agent_hub is read-only from MM context. Joined via canonical_name after onboarding.
Initial build The rule: never cross-reference MM FUB contacts with client FUB contacts. Same agent appears once per FUB.

Open issues

References

The rule

Never cross-reference MM FUB contacts with client FUB contacts. Ever.

If an agent shows up in both FUBs, they appear once in MM ops (as an agent) and separately in client FUB (as their client work). They are not the same record. The scoped CLAUDE.md enforces this in code.