AI-Native Y1 · tool map

1 · The master map

four clusters, the edges that actually exist, and the ones that are only planned

In plain words The crews build two of the platform products. ysible is the data hub everything wants to talk to. Most other links are either deploy-time plumbing or still on the wish list. The full edge list, including copy-paste reuse, sits in the connection matrix.

%%{init: {'flowchart': {'useMaxWidth': false, 'nodeSpacing': 70, 'rankSpacing': 85}}}%%
flowchart TB
  subgraph C2["CREWS · Paperclips runtime · Hetzner"]
    CORE["y1-crew-core
the shared office"]:::shell
    CRY["y1-crew-ysible
pilot crew"]:::agent
    CRL["y1-crew-lb
Ludwig Beck pilot"]:::agent
  end
  subgraph C1["AGENT PLATFORMS & RUNTIMES"]
    YSI["ysible
planning & data hub"]:::ok
    YAMA["yama
shop monitoring"]:::ok
    YARA["yara
agent runtime 2.0"]:::alert
    SP["y1-superpowers
the Y1 method"]:::ok
  end
  subgraph C3["RADARS & MONITORS"]
    M2SD["m2-status-dashboard"]:::ok
    M2O["m2-orchestrator"]:::dec
    RADAR["y1-radar"]:::port
    JMON["jira-monitor"]:::ok
    KMON["kunden-monitor"]:::port
    MEET["meeting-summary-worker"]:::dec
  end
  subgraph C4["PIM & CONTENT AI"]
    PIME["PIM Enricher"]:::ok
    PXM["pxm-maturity · MCP"]:::ok
    CPIM["y1-cpim-pilot · GEO"]:::ok
    PHT["ph-pim-translator"]:::dec
    DSA["pxm-dsa"]:::alert
    SHT["shopify-translator"]:::alert
  end
  PX["projectx · the proposal"]:::neutral
  ANTH["Anthropic Claude
every tool calls it"]:::neutral
  JIRA["Jira Cloud
5 independent integrations"]:::neutral
  SPN["shared dev-time method
used across every cluster"]:::neutral
  CORE -->|"submodule + GH Action"| CRY
  CORE -->|"submodule + GH Action"| CRL
  CRY ==>|"builds and ships"| YSI
  CRL ==>|"builds and ships"| PIME
  CORE -.->|"vendors skills, pinned SHA"| SP
  YSI -->|"post-deploy QA ping"| CRY
  YARA <-->|"blocked, no CF Access token"| YSI
  YSI -.->|"yama_id reserved, dormant"| YAMA
  RADAR -->|"hosted at /10x/"| M2SD
  M2O -->|"reads projects.yaml"| M2SD
  M2SD -->|"hosts"| PX
  RADAR -.->|"planned, yara LLM router"| YARA
  CPIM -.->|"planned, maturity signals"| PXM
  PXM -.->|"MCP server, mountable"| YARA
  SP -.-> SPN
  YARA -.- ANTH
  CRY -.- ANTH
  JMON -.- ANTH
  CPIM -.- ANTH
  CORE -.->|"Mia writes"| JIRA
  JMON -.->|"reads"| JIRA
  RADAR -.->|"evidence gate"| JIRA
  classDef ok fill:#d2efe7,stroke:#04a777,color:#0a4a36,stroke-width:1.5px;
  classDef port fill:#ffffff,stroke:#d6438c,color:#000000,stroke-width:1.5px;
  classDef dec fill:#f1f3f4,stroke:#828d8c,color:#2a302e,stroke-width:1.5px;
  classDef alert fill:#f9dadc,stroke:#dd343e,color:#7a1418,stroke-width:1.5px;
  classDef shell fill:#ffffff,stroke:#000000,color:#000000,stroke-width:1.5px;
  classDef neutral fill:#f1f3f4,stroke:#aeb6b4,color:#2a302e;
  classDef agent fill:#e2f8f5,stroke:#43d9c4,color:#0b3f38,stroke-width:1.5px;
  linkStyle 2 stroke:#d6438c,stroke-width:2.5px;
  linkStyle 3 stroke:#d6438c,stroke-width:2.5px;
  linkStyle 6 stroke:#dd343e,stroke-width:2px;

The master map. Curated to the edges that matter. The two bold magenta edges, crews building products, are the only fully autonomous loop in the set. The full edge list is in the matrix below. drag to pan · ctrl/cmd+scroll or buttons to zoom · double-click to zoom in

prod pilot / PoC wip dormant / blocked core / office solid = live dashed = planned / dormant / pattern crew builds product

2 · Where it runs

one default platform, two Hetzner machines, a local layer, and one outlier

In plain words Cloudflare "Y1 Studio" is the default home and holds most of the workers. Hetzner runs two separate machines: the Paperclips VM for the crews and the ops VPS for the Magento dashboard. The rest runs locally on demand, plus one Fly.io deploy.

The four hosting worlds. One default platform, two separate Hetzner machines, a local layer. Teal marks the crew runtime.

Cloudflare · "Y1 Studio"default platform

Workers + Hono + D1 + KV + Queues + R2, TypeScript, React 19 + Tailwind 4. Note: pxm-maturity sits on a different CF account, "Y1 Studio" is a naming convention across a couple of accounts.

yarayamaysiblejira-monitorkunden-monitormeeting-workerPIM Enricherph-pim-translatorcpim-pilotpxm-dsa webappsuperpowers landing

Hetzner · Paperclips VMcrew runtime

The crews' machine: Postgres, port 3100. Runs the y1-crew-core office and the two live crew tenants (YSIB, LBPIM).

y1-crew-corey1-crew-ysibley1-crew-lb

Hetzner · ops VPSmagento-uptime.ops.y1.de

Docker, nginx + FastAPI. Runs the Magento status dashboard, which also serves the projectx, superpowers and 10x static landing sites behind capability URLs.

m2-status-dashboard/projectx//superpowers//10x/

Local / on-demand+ one Fly.io outlier

Tools that run on a laptop when needed. The one deploy outside Cloudflare and Hetzner: y1-shopify-translator on Fly.io + Docker.

y1-superpowers pluginm2-orchestratory1-radar generatorpxm-dsa pipelineshopify-translator · Fly.io

Two siloed infra worlds. The Hetzner ops stack (Magento monitoring) and the Cloudflare Studio stack grew independently and share no code or deploy path today. The only bridge is that the ops VPS hosts the static landing pages.

3 · Agent platforms & runtimes

ysible is the hub; yara is deployed but dark; yama is mature and alone

ysibleprodCF Workers · Y1 Studio

Internal revenue and resource planning with forecasting. Two-way sync of deals, projects and invoices from Teamleader Orbit into D1. The data hub of the platform cluster: yara wants to read it, the crews build it, and a reserved yama_id column waits for yama.

github ysible.y1-studio.workers.dev · CF Access

yamaprodCF Workers + Durable Objects

Multi-tenant white-label shop monitoring for Shopware 6, Magento 2 and Shopify. 25+ anomaly types, multi-channel alerts, Claude-Vision headless checkout tests. The most product-complete tool in the set, and a code-level island.

github yama.y1-studio.workers.dev

yarawipblockedCF Workers · Y1 Studio

Agent runtime 2.0: cron and queue background agents (project, unpaid-invoice and unbilled-time detectors, chat, a stubbed meeting-summarizer) that read and write the ysible API. Tiered LLM router (Haiku → Sonnet → Opus), cost cap, undo. Deployed but not live: the Anthropic key is unset and the ysible CF Access service token was never issued.

github yara.y1-studio.workers.dev

y1-superpowersprodLocal plugin + Pages landing

The encoded Y1 ticket method: 39 skills (/solve /refine /spec /plan /implement /estimate /offer /comment /map /tt /frontend /qa). A shared dev-time methodology, not a runtime.

github y1-superpowers.pages.dev

flowchart LR
  YARA2["yara
deployed, not live"]:::alert
  YSI2["ysible
the data hub"]:::ok
  YAMA2["yama
monitoring island"]:::ok
  SP2["y1-superpowers
the method"]:::ok
  YARA2 <-->|"blocked · CF Access token unissued"| YSI2
  YSI2 -.->|"yama_id column · dormant"| YAMA2
  SP2 -.->|"dev-time method"| YARA2
  SP2 -.->|"dev-time method"| YSI2
  SP2 -.->|"dev-time method"| YAMA2
  classDef ok fill:#d2efe7,stroke:#04a777,color:#0a4a36,stroke-width:1.5px;
  classDef alert fill:#f9dadc,stroke:#dd343e,color:#7a1418,stroke-width:1.5px;
  linkStyle 0 stroke:#dd343e,stroke-width:2px;

Platform cluster edges. The yara ↔ ysible integration is fully coded on both sides and blocked only by an unissued service token. ysible → yama is a reserved column, nothing flows yet.

The cheapest win on the board. yara's detectors and ysible's /auth/resolve role lookup are both live code. Issuing one CF Access service token turns the platform cluster's biggest dormant edge on.

4 · The crews

the live pipeline behind the "AI-Native Y1 / projectx" proposal

In plain words This already runs. Two crews of six AI agents each autonomously build and ship two real products on the Paperclips runtime (Hetzner VM, Postgres, port 3100). A person signs off at two gates. Code review runs on a different vendor on purpose: BBQ Chef judges Claude's code with OpenAI GPT-5.

y1-crew-coreprod · infra layerHetzner Paperclips · git submodule

The shared office: helpers.sh, the HEARTBEAT protocol, six canonical agent personas, the bootstrap-crew scaffolder and the cross-vendor GPT-5 reviewer. Changes auto-propagate to consumer crews via GitHub Actions. Vendors y1-superpowers skills at a pinned SHA.

github Paperclips VM · Postgres :3100

y1-crew-ysibleprod / pilottenant YSIB · live 2026-05-28

The original pilot crew. Builds the ysible product, with a richer skill and wiring layer and Playwright QA against staging.

github tenant YSIB

y1-crew-lbprod / pilottenant LBPIM · live 2026-06-02

The Ludwig Beck pilot crew. Builds the PIM Enricher (y1-ai-pim-enhancement), the second product shipped by an AI crew.

github tenant LBPIM

flowchart TB
  FELIX["Felix · human"]:::shell
  G1{"G1
plan"}:::gate
  G2{"G2
ship"}:::gate
  subgraph PC["Paperclips runtime · Hetzner VM · Postgres :3100"]
    CRON["HEARTBEAT cron
wakes the roles"]:::neutral
    subgraph OFFICE["y1-crew-core · the shared office"]
      ROLES["Mia-PM · Polly-PO · Architect
Theo-Dev · BBQ Chef · Dragan-QA"]:::agent
      HB["helpers.sh · bootstrap-crew"]:::neutral
    end
    CRY2["y1-crew-ysible
tenant YSIB · live 2026-05-28"]:::agent
    CRL2["y1-crew-lb
tenant LBPIM · live 2026-06-02"]:::agent
  end
  GPT["OpenAI GPT-5"]:::neutral
  SPV["y1-superpowers skills
vendored · pinned SHA"]:::neutral
  YSIP["ysible
the product"]:::ok
  PIMP["PIM Enricher
the product"]:::ok
  FELIX -.- G1
  FELIX -.- G2
  G1 -.->|"approves the plan"| ROLES
  CRON -->|"wakes"| ROLES
  OFFICE -->|"submodule + GH Action"| CRY2
  OFFICE -->|"submodule + GH Action"| CRL2
  ROLES -->|"BBQ Chef sends Theo's diff"| GPT
  OFFICE -.->|"vendors"| SPV
  CRY2 ==>|"builds & ships"| YSIP
  CRL2 ==>|"builds & ships"| PIMP
  G2 -.->|"approves the release"| YSIP
  G2 -.->|"approves the release"| PIMP
  YSIP -->|"staging deploy wakes Dragan · Playwright"| CRY2
  classDef ok fill:#d2efe7,stroke:#04a777,color:#0a4a36,stroke-width:1.5px;
  classDef agent fill:#e2f8f5,stroke:#43d9c4,color:#0b3f38,stroke-width:1.5px;
  classDef neutral fill:#f1f3f4,stroke:#aeb6b4,color:#2a302e;
  classDef shell fill:#ffffff,stroke:#000000,color:#000000,stroke-width:1.5px;
  classDef gate fill:#ff78ba,stroke:#d6438c,color:#000000,stroke-width:1.5px;
  linkStyle 8,9 stroke:#d6438c,stroke-width:2.5px;

The crew pipeline. One office, two crews, two shipping products. Felix signs off at two gates (G1 plan, G2 ship). The ysible product pings its own crew back: a post-staging-deploy GitHub Action wakes Dragan for Playwright tests.

Mia · PMJira and comms · Haiku/Sonnet

Polly · POrefinement, pins down "done"

Architecttech plan · Opus

Theo · Devbuilds and tests · Sonnet

BBQ Chefcross-vendor review · GPT-5

Dragan · QAPlaywright on staging

5 · Radars & monitors

everything that watches something, split across two infra worlds

m2-status-dashboardprodHetzner VPS

FastAPI dashboard with health, version, patch, pipeline and Jira status for ~14 Magento projects. Also the static host of the /projectx/, /superpowers/ and /10x/ landing sites behind capability-URL tokens.

github magento-uptime.ops.y1.de

m2-orchestratorwiplocalhost only

Local orchestration API that scans ~/Sites. Depends on m2-status-dashboard's projects.yaml and defaults to the live dashboard URL.

github local / on-demand

y1-radarpilotlocal generator · hosted at /10x/

PageSpeed Insights plus a Jira-evidence-gated sellable opportunity board (EN/DE). The config carries a stub seam for "the yara LLM router later", not wired today.

github magento-uptime.ops.y1.de/10x/

jira-monitorprodCF Workers · Y1 Studio

Read-only Jira triage cockpit. Syncs issues to D1 on a 15-minute cron; Claude Haiku classifies who is on the hook for each ticket.

github jira-monitor.y1-studio.workers.dev

kunden-monitorpilotCF Workers · Y1 Studio

DACH e-commerce and retail news radar per client and competitor. Claude Haiku scores relevance, Sonnet enriches. CSS and Cloudflare Access policy copied from jira-monitor.

github

y1-meeting-summary-workerwipCF Workers · not yet deployed

"YARA Meeting Agent": polls MS Graph every 5 minutes for Teams transcripts, Claude summarizes, publishes to Confluence, notifies Teams via a Langdock bot. Overlaps with yara's own stubbed meeting-summarizer.

github

flowchart LR
  subgraph HOPS["Hetzner ops world"]
    M2O2["m2-orchestrator
local"]:::dec
    RAD2["y1-radar
local generator"]:::port
    M2SD2["m2-status-dashboard"]:::ok
    LAND["/projectx/ · /superpowers/ · /10x/"]:::neutral
  end
  subgraph CFW["Cloudflare Studio world"]
    JMON2["jira-monitor"]:::ok
    KMON2["kunden-monitor"]:::port
    MEET2["meeting-summary-worker
not deployed"]:::dec
  end
  JIRAA["Jira Cloud
the shared anchor"]:::neutral
  GRAPH["MS Graph · Confluence · Teams"]:::neutral
  M2O2 -->|"reads projects.yaml"| M2SD2
  RAD2 -->|"docker cp to /10x/"| M2SD2
  M2SD2 -->|"hosts"| LAND
  KMON2 -.->|"copied CSS + Access policy"| JMON2
  M2SD2 -->|"reads · own client"| JIRAA
  RAD2 -->|"reads · evidence gate · own client"| JIRAA
  JMON2 -->|"reads · 15-min cron · own client"| JIRAA
  MEET2 -.->|"polls · publishes · not live"| GRAPH
  classDef ok fill:#d2efe7,stroke:#04a777,color:#0a4a36,stroke-width:1.5px;
  classDef port fill:#ffffff,stroke:#d6438c,color:#000000,stroke-width:1.5px;
  classDef dec fill:#f1f3f4,stroke:#828d8c,color:#2a302e,stroke-width:1.5px;
  classDef neutral fill:#f1f3f4,stroke:#aeb6b4,color:#2a302e;

Two silos in one cluster. The Hetzner ops trio and the CF Studio trio share no code or deploy path. Three of the six wrote their own Jira client against the same instance.

Two silos in one cluster. The Hetzner ops world (m2-status-dashboard, m2-orchestrator, the radar's only live hosting) and the CF Studio world (jira-monitor, kunden-monitor, meeting-worker) watch adjacent things and share nothing but Jira credential patterns.

6 · PIM & content AI

six tools, no shared library

y1-ai-pim-enhancementprodCF Workers · Y1 Studio

"PIM Enricher": AI researches and generates missing Akeneo product data, a human reviews in a "Tinder for PIM" swipe UI before write-back. Built by the y1-crew-lb crew.

github pim-enricher.y1.studio

ph-pim-translatorwipCF Workers

Peter Hahn: ContentServ PIM translation DE → FR/EN/NL via Claude, with write-back. Datadog tracing copied from the meeting-worker.

github

pxm-maturityprodCF Pages + Workers

PXM maturity index: outside-in scoring of ~942 B2C brands. Ships an MCP server (mcp-pxm-data, 6 tools), the most platform-ready surface in the set.

github pxm-explorer.y1.studio

pxm-dsadormantlocal + CF Workers

Digital Shelf Analytics: GTIN "golden record", scores retailer listings. Geberit PoC, stale since 2026-03-11. Notable: an 86% token-cost cut via an extraction cascade.

github local / on-demand

y1-cpim-pilotprod · multi-clientCF Workers · Y1 Studio

GEO / AI-visibility measurement, not a PIM tool despite the false-friend name: measures how LLMs recommend a brand. Runs Stihl, HiPP and Scott plus geo-scans for verpackgo, cybex, lusini, melitta and tesa. Uses Langdock as its LLM gateway.

github

y1-shopify-translatordormant / pilotFly.io + Docker · the outlier

Schiesser: embedded Shopify Admin app that auto-translates shop content via Claude. The only non-Cloudflare deploy. Prod blocked on PIM-app detection.

github

flowchart TB
  subgraph CLI["client-specific"]
    PIME2["PIM Enricher
Ludwig Beck · Akeneo"]:::ok
    PHT2["ph-pim-translator
Peter Hahn · ContentServ"]:::dec
    DSA2["pxm-dsa
Geberit PoC · stale"]:::alert
  end
  subgraph FLY["Fly.io · the only non-CF deploy"]
    SHT2["y1-shopify-translator
Schiesser"]:::alert
  end
  subgraph GEN["generic / multi-client"]
    PXM2["pxm-maturity
+ MCP server"]:::ok
    CPIM2["y1-cpim-pilot · GEO
Stihl · HiPP · Scott + geo-scans"]:::ok
  end
  NOLIB["no shared PIM or translation library
reuse is copy-paste"]:::dec
  RT["yara · crews
agent runtimes"]:::agent
  CPIM2 -.->|"planned · maturity signals"| PXM2
  PXM2 -.->|"MCP · mountable as agent tool"| RT
  CLI -.- NOLIB
  GEN -.- NOLIB
  FLY -.- NOLIB
  classDef ok fill:#d2efe7,stroke:#04a777,color:#0a4a36,stroke-width:1.5px;
  classDef port fill:#ffffff,stroke:#d6438c,color:#000000,stroke-width:1.5px;
  classDef dec fill:#f1f3f4,stroke:#828d8c,color:#2a302e,stroke-width:1.5px;
  classDef alert fill:#f9dadc,stroke:#dd343e,color:#7a1418,stroke-width:1.5px;
  classDef agent fill:#e2f8f5,stroke:#43d9c4,color:#0b3f38,stroke-width:1.5px;
  classDef neutral fill:#f1f3f4,stroke:#aeb6b4,color:#2a302e;

PIM cluster. Both planned edges are dashed: neither exists yet. The two translators and the two PXM tools each wrote the same fetch-translate-write-back loop.

No shared translation or PIM library. Reuse in this cluster is copy-paste. pxm-maturity's MCP server is the exception, and the template to follow.

7 · Shared anchors

the real connective tissue: external systems everything hangs on, integrated separately every time

In plain words The tools rarely talk to each other, but they all talk to the same outside systems. Jira is integrated at least five separate times, Orbit twice, and Anthropic Claude runs everywhere. That duplication is where a shared layer would pay off first.

Anchor	Who hangs on it, and how
Jira Cloud y1digital.atlassian.net	Integrated independently by ≥5 tools: the crews (Mia, write) · m2-status-dashboard (read) · jira-monitor (read) · y1-radar (read, evidence gate) · y1-superpowers (read/write). No shared Jira client exists.
Teamleader Orbit	ysible syncs deals and invoices in · y1-superpowers `/tt` books timesheets. Shared external anchor, no shared client.
Anthropic Claude	Used by all tools. Common tiers: Haiku for cheap triage, Sonnet for the work, Opus for planning.
LLM gateway fragmented	No single gateway today. Most repos call the Anthropic SDK directly · y1-cpim-pilot and the meeting-worker bot go through Langdock · y1-radar plans a "yara router" · yara has its own tiered router · the crews call the Claude CLI directly plus GPT-5 for review · the projectx proposal recommends LiteLLM.
Cross-vendor review	The crews' BBQ Chef judges Claude's code with OpenAI GPT-5. Deliberate: the reviewer never shares a vendor with the author.
Datadog LLM-Obs datadoghq.eu	yara · yama · y1-meeting-summary-worker · ph-pim-translator. A mid-2026 shared observability rollout.
y1-brand-guide pages.dev	Shared design tokens for yara, yama, the superpowers landing, and this map.
y1-ai-app-template	The Cloudflare-worker scaffold behind jira-monitor and the meeting-worker. Rejected by the Fly-based shopify translator.
y1-superpowers	The shared dev-time methodology: most repos are built with its spec/plan workflow (`docs/superpowers/`, CLAUDE.md-as-README).

The key finding. LLM access is fragmented across five-plus patterns: direct SDK, Langdock, a planned "yara router", a proposed LiteLLM, and the Claude CLI. One org-wide gateway would unlock cross-vendor review and cost caps everywhere at once.

8 · Connection matrix

every real, deploy-time, pattern-only and planned edge, in one honest table

From	To	Type	What flows
y1-crew-lb	y1-ai-pim-enhancement	live · build	the crew autonomously writes and ships the product's code
y1-crew-ysible	ysible	live · build	the crew autonomously writes and ships the product's code
ysible (product)	y1-crew-ysible (Dragan)	live	post-staging-deploy GitHub Action wakes the QA agent for Playwright tests
y1-crew-core	y1-crew-ysible & -lb	live	git submodule; core changes auto-propagate to both crews
y1-crew-core	y1-superpowers	live · vendored	superpowers skills vendored into core at a pinned SHA
yara	ysible	live but blocked	REST read + critical-flag write-back; blocked on an unissued CF Access service token
ysible	yara	live	`/auth/resolve` exposes role lookup for the YARA service account
ysible	yama	dormant	a reserved `yama_id` column, no live sync yet
m2-orchestrator	m2-status-dashboard	live	reads `projects.yaml` and defaults to the live dashboard URL
y1-radar	m2-status-dashboard	deploy-time	the radar's only live hosting is /10x/, pushed via `docker cp`
m2-status-dashboard	projectx / superpowers / 10x	deploy-time	serves the three static landing sites
ph-pim-translator	y1-meeting-summary-worker	pattern-only	copied the Datadog LLM-Obs tracing setup
kunden-monitor	jira-monitor	pattern-only	reused CSS + Cloudflare Access policy
y1-shopify-translator	schiesser-event-worker-app	stack ref	modeled its stack on that repo
y1-radar	yara	planned	intends to route LLM calls through the yara router
y1-cpim-pilot	pxm-maturity	planned	deferred: pull PXM maturity signals into GEO measurement
pxm-maturity (MCP)	yara / any runtime	opportunity	its MCP server could be mounted as an agent tool

live / deploy edge in production coded but blocked dormant / pattern-only / reference planned / opportunity

9 · What this means for connecting the tools

The crews are the one working AI-native pipeline. They already build and ship two real products (ysible, PIM Enricher). The projectx proposal describes something that already runs.
ysible is the natural data hub. The yara ↔ ysible link is blocked only by an unissued service token, the cheapest win on the board.
yama is the most product-complete tool and the most isolated. ysible already reserved a yama_id; wiring shop health into the planning view is a small, clear next step.
LLM access is fragmented across 5+ patterns. A single gateway (LiteLLM or Langdock, org-wide) is the highest-leverage consolidation, and it unlocks cross-vendor review and cost caps everywhere.
Jira is integrated 5 separate times, Orbit 2 times. A shared Y1 client library, or MCP servers, would remove duplicated, drift-prone code.
pxm-maturity already ships an MCP server. That is the template for exposing every tool as an agent-mountable capability, which is how the crews and yara would actually consume them.
No shared PIM or translation library. The two translators and the two PXM tools each reimplement the same loop; a shared connector package is an obvious refactor.
y1-superpowers is the de-facto shared standard already, as the method and soon as a runtime skill source for the crews. It is the connective tissue to lean on.
There are two meeting summarizers: the yara stub and the standalone YARA Meeting Agent worker. Pick one.

The shortlist, in order of effort-to-payoff

Issue the CF Access service token and turn the yara ↔ ysible link on. Both sides are already coded.
Wire yama → ysible through the reserved yama_id: shop health inside the planning view.
Stand up one LLM gateway org-wide and migrate the five access patterns onto it.
Extract shared Jira and Orbit clients (or MCP servers) out of the five and three duplicate integrations.
MCP-ify the tools on the pxm-maturity pattern, so crews and yara can mount them.
Merge the two meeting summarizers into one.