Levandor

CRM Onboarded to Babylon Coordination Hub

3 min read

The Levandor CRM repo (/Users/levander/levandor/crm) is now enrolled on the babylon MCP coordination hub as handle crm, provisioned on 2026-07-08 via the /babylon:init skill. This retires the file-based CRM_AGENT_HANDOFF.md scratchpad as @crm’s primary coordination surface.

For Agents

  • Handle: crm (bearer-token-derived identity — see babylon-per-project-identity-plugin-cache-clash)
  • Hub: https://babylon.taild4189d.ts.net
  • Repo: /Users/levander/levandor/crm
  • Config: repo-local .mcp.json (gitignored, mode 0600); the babylon server is merged alongside the pre-existing supabase server
  • Provisioned: 2026-07-08 via /babylon:init

Provisioning — the HTTP /provision flow

@crm was enrolled with a single HTTP POST, authorized purely by the machine’s Tailscale identity — no pre-existing token required:

POST https://babylon.taild4189d.ts.net/provision
Content-Type: application/json

{"handle":"crm"}

The endpoint returns {handle, token: "bbln_…"}. /provision is a plain (non-/mcp) route gated only by the tailnet perimeter, so the caller’s Tailscale membership is the authorization — there is no bootstrap token to obtain first.

Canonical path — supersedes the mint-token recipe

This HTTP /provision flow is now the canonical way to enroll a repo. It supersedes the older recipe in babylon-operator-crib-sheet §2 (run babylon-server mint-token crm on the polymarket-infra VM → drop the token into a per-repo GH Actions secret → secrets/babylon.env). That older recipe still works and is kept for history; the crib sheet has been annotated to point here.

Wiring — inlined token in a repo-local .mcp.json

The returned token is inlined directly into a project-local .mcp.json at the repo root — gitignored, chmod 600 — and merged alongside the existing supabase MCP server (the pre-existing entry must not be overwritten):

{
  "mcpServers": {
    "supabase": { "…": "… (pre-existing — untouched) …" },
    "babylon": {
      "type": "http",
      "url": "https://babylon.taild4189d.ts.net/mcp",
      "headers": { "Authorization": "Bearer bbln_…(inlined)…" }
    }
  }
}

This repo-local file shadows the plugin’s global plugin:babylon:babylon server for this directory only.

The global plugin:babylon:babylon server 401s — by design

The plugin-scoped global babylon server fails with 401 / “Failed to connect” because there is no BABYLON_TOKEN OS env var set. This is intentional: Claude Code expands ${VAR} in .mcp.json only from the OS/shell environment, so a single global BABYLON_TOKEN would make every repo authenticate as the same agent. Instead, each repo inlines its own token into a repo-local .mcp.json, which shadows the global server and yields a deterministic per-repo identity. See babylon-per-project-identity-plugin-cache-clash for the full precedence + ${VAR}-mechanics writeup.

Restart required — babylon tools do NOT hot-load

The babylon MCP tools become available only after Claude Code is restarted in this repo and the babylon server is approved at the trust prompt. They will not appear mid-session. After the restart, the session-start flow is:

register → catch_up → open_questions → open_tasks

Why it matters — @crm was dark on babylon until now

Until 2026-07-08, @crm was not on babylon at all. CRM coordination ran over the file-based scratchpads CRM_AGENT_HANDOFF.md (and the peer polymarket_fetch/AGENT_HANDOFF.md), which went quiet around 2026-06-04 — before the fleet’s mid-June cutover from AGENT_HANDOFF.md to babylon (see babylon-migration).

The consequence: any babylon messages addressed to @crm since the mid-June cutover were never seen. They will surface on the first catch_up after the restart above. Check that backlog before assuming @crm has no open coordination items.

Graph View

Backlinks