The discovery loop runs on the developer's laptop or a small worker pod, not in a managed ML environment. Embedding is the one ML hop in the pipeline, and it stays on-device: a Rust-built Candle BERT server (loopback, port 7799) serves 384-dim vectors over HTTP to the Python graph. Candle gives us BERT inference on Metal (Apple silicon) or CPU with no Python runtime in the hot path, no CUDA setup, no cloud egress. The practical consequence: a full candidate scan costs roughly $0 in inference and never leaks the sourcing target to a third party. Scoring itself is pure-Python arithmetic over the hydrated GraphQL fields — fast enough at 50k candidates that it doesn't justify a non-Python implementation.

# backend/leadgen_agent/embeddings.py — Candle BERT 384-dim local pass
async def embed_texts(texts: list[str]) -> list[list[float]]:
    # Local Rust/Candle HTTP server on 127.0.0.1:7799 — Metal on Apple silicon,
    # CPU elsewhere. No external network, no per-call cost.
    async with httpx.AsyncClient() as c:
        r = await c.post("http://127.0.0.1:7799/embed", json={"texts": texts})
    return r.json()["embeddings"]   # 384-dim vectors

# backend/leadgen_agent/gh_patterns_graph.py — rising_score composite
def compute_rising_score(c: Candidate) -> float:
    density    = contribs_per_follower(c)    # undiscovered talent
    novelty    = account_age_score(c)        # newer accounts
    breadth    = distinct_ai_repo_score(c)   # # of AI repos
    activity   = real_activity_score(c)      # commits/PRs/reviews
    relevance  = ai_skill_score(c)           # skill tag count
    engagement = profile_completeness(c)     # email/hireable/etc
    obscurity  = 1.0 / (1.0 + c.followers / 500.0)
    recency    = last_90d_signal(c)
    quality    = external_star_quality(c)

    composite = clamp(linear_combo(...), 0.0, 1.0)
    return composite * hireable_multiplier(c) * recency_multiplier(c)

Every discovery channel has a characteristic false-positive mode. Bio search surfaces people who describe themselves as AI engineers but don't ship AI code. Stargazer mining surfaces hobbyists who starred a framework once. Contributor mining surfaces real capability but misses anyone who hasn't contributed to the specific 12 repos we track. Org-member mining is biased toward visible AI labs and misses senior engineers at quiet companies. Follower-graph expansion surfaces community-embedded engineers but has a 1-hop limit before noise dominates. Seed-domain extraction only fires for companies already in our enriched set. Running all six and intersecting the results — each candidate carries tags for every channel that surfaced them — produces a candidate pool where every shortlisted profile has multiple independent pieces of evidence.

# backend/leadgen_agent/gh_patterns_graph.py — 6-channel fan-out
# Channel 1: Bio/keyword search (passes A–O)
for label, query in search_queries():
    await gh.search_users(query, sort="followers", order="desc", per_page=100)
    # tag: src:bio/{label}

# Channel 2: Stargazer mining (13 AI repos)
for repo in stargazer_repos():
    await gh.list_stargazers(repo, per_page=100)
    # tag: src:star/{repo}

# Channel 3: Contributor mining (12 core libs)
for repo in contributor_repos():
    await gh.list_contributors(repo, per_page=100)
    # tag: src:contrib/{repo}

# Channel 4: AI org public members
for org in ai_orgs():
    await gh.list_org_members(org)
    # tag: src:org/{org}

# Channel 5: Follower expansion from top-k seeds
# Channel 6: Seed domains (company team pages)

Every signal that surfaced a candidate is preserved as a tag on their contact row — no black-box scoring. A recruiter looking at a shortlisted engineer sees github:rising-star, github:score:A, github:trend:rising, skill:pytorch, skill:rag, seniority:senior, opp:opp_20260415_principal_ai_eng_ob, opp:skill-match:85pct, src:bio/C, src:contrib/langchain-ai/langgraph, src:org/huggingface — which answers 'why this person?' without requiring access to scoring internals. Tags are stored as a JSONB array with a GIN index, so containment queries ('show me everyone with src:contrib/langchain AND seniority:senior') are O(1).

// src/db/schema.ts — contacts table (GitHub-relevant columns)
export const contacts = pgTable("contacts", {
  id: serial("id").primaryKey(),
  github_handle: text("github_handle"),              // unique partial index
  profile: jsonb("profile"),                   // ContactProfile
  authority_score: real("authority_score"),          // ← strength_score
  tags: jsonb("tags").default([]),                   // GIN-indexed
  // ...
});

// Example tag set on a single contact row
[
  "github:rising-star",
  "github:score:A",
  "github:trend:rising",
  "github:active-this-week",
  "skill:pytorch", "skill:langchain", "skill:rag",
  "seniority:senior",
  "opp:opp_20260415_principal_ai_eng_ob",
  "opp:skill-match:85pct",
  "src:bio/C", "src:contrib/langchain-ai/langgraph",
  "src:org/huggingface"
]

The third sibling alongside outbound B2B (/how-it-works) and inbound recruitment (this page) is auto-apply — a self-directed pipeline that ingests live job postings and submits applications. Source: the Hacker News 'Who is Hiring?' threads via the Algolia API at https://hn.algolia.com/api/v1/search (paginated by date, AI/remote-filtered). Triage: a batch_fit_scorer node that chunks 8 jobs per Claude Sonnet 4.6 (claude-sonnet-4-6) call, with cache_control=ephemeral on the SYSTEM_PROMPT + resume prefix — every chunk after the first pays only the cache-read rate (10% of input tokens), collapsing what was N sequential per-job triage calls into one prefix-cached batch. Cover-letter generation reuses the same cached prefix on the same model. Submission is a Playwright browser session with cookie-banner dismissal via page.evaluate(); end-to-end submission success rate sits at ~77%. Entry point: pnpm jobs:apply → backend/scripts/auto_apply_cli.py → backend/leadgen_agent/auto_apply_graph.py.

# backend/leadgen_agent/auto_apply/batch_fit_scorer.py
PROMPT_VERSION = "batch-fit-v1-2026-05"
DEFAULT_BATCH_SIZE = 8

# One Sonnet 4.6 call per chunk — system prompt + resume cached
# (cache_control=ephemeral). Chunk #2+ hits cache_read_input_tokens.
async def _score_one_chunk(jobs):
    payload = [{"idx": i, "role": j["role"], "company": j["company"],
                "jd_slice": j["jd"][:2000]} for i, j in enumerate(jobs)]
    client = make_sonnet(temperature=0.0)
    result, tel = await ainvoke_anthropic_json_with_telemetry(
        client,
        system_blocks=_system_blocks(),   # ← cached prefix
        user_content=BATCH_USER_TEMPLATE.format(jobs_json=json.dumps(payload)),
        max_tokens=200 + 80 * len(jobs),
    )
    return result["scores"], tel  # [{"idx": i, "score": 0..100, "reasoning": "..."}]

# Pipeline shape:
# discover (HN Algolia) → prioritize → batch_score (Sonnet, chunked) →
# pop_next → fetch_jd → cover_letter (Sonnet, same cache prefix) →
# submit (Playwright) → persist

The rising_score deliberately inverts follower count through an obscurity component: 1 / (1 + followers / 500). An engineer with 10,000 followers gets an obscurity multiplier of ~0.05; an engineer with 50 followers gets ~0.91. The intent is explicit: the product is a discovery tool, not a re-ranking of already-famous accounts. A 20k-follower AI influencer is not the target hire — a 200-follower engineer who ships three high-star repos is. This is paired with a recency multiplier that boosts candidates active in the last 7/30/90 days, so obscurity alone doesn't surface dormant accounts.

# backend/leadgen_agent/gh_patterns_graph.py
def obscurity(c: Candidate) -> float:
    return 1.0 / (1.0 + c.followers / 500.0)

def recency_multiplier(c: Candidate) -> float:
    days = c.days_since_last_active
    if days <= 7:   return 1.15   # active this week
    if days <= 30:  return 1.10   # active this month
    if days <= 90:  return 1.05   # active this quarter
    return 1.0

def hireable_multiplier(c: Candidate) -> float:
    return 1.15 if c.is_hireable else 1.0