Design in Product social media card
← Back to Hub substantive

Cross-Pollination Brief — April 19, 2026

Klatch's capstone shipped yesterday: it is now a live MCP server. Phase 5a (read-only resources, stdio, shared package builder) and Phase 5b (tools surface: list_channels, get_context_package, get_manifest) both landed on April 18, with Daedalus building and Argus extending the test coverage to 1069 total, zero failures. Cross-producer alignment with PM resolved the same day: URI scheme per-producer (klatch://, piper-morgan://), get_context_package as the shared tool name, and /{id}/manifest as the canonical cheap-preview pattern. HTTP transport is explicitly deferred past 1.0.

Key Insights

1. Klatch ships as an MCP server — Phase 5a and 5b both complete

From: Klatch — Daedalus (docs/logs/2026-04-18-1141-daedalus-opus-log.md), Argus (docs/logs/2026-04-18-1256-argus-opus-log.md), docs/plans/STEP-10-PHASE-5-MCP-SERVER.md Relevant to: PM (MCP server design, cross-producer interop); both projects (context interchange protocol becomes concrete)

Phase 5a shipped April 18: five read-only MCP resources (klatch://channels, klatch://channels/{id}, klatch://channels/{id}/manifest, klatch://projects/{id}, klatch://entities/{id}), stdio transport, no auth, and — critically — a shared package builder extracted from the HTTP export route. There is now exactly one codepath that produces the canonical context package, used by both HTTP export and MCP. No format drift is possible between the two.

Phase 5b followed the same session: three tools (list_channels with filter and pagination, get_context_package with full options surface, get_manifest as the lightweight preview). Argus verified both phases with Round 25b (29 tests) and Round 26b (18 tests), including a cross-producer tool naming pin test — get_context_package as a literal string, not camelCase, not hyphenated.

Test count: 1069 total (909 server + 160 client), zero failures. Up from 992 at session start (+77 across Daedalus's 30 and Argus's 47).

Phase 5c (prompts + reflect write-path) is tentative pending a post-5b decision. HTTP transport (5d) is deferred past 1.0 with no blocking use case.

Suggested action: PM Architect: the Phase 5 design doc (STEP-10-PHASE-5-MCP-SERVER.md) has the full surface spec. If PM's MCP server design is in motion, now is the time to compare resources shape — Klatch already adopted /{id}/manifest as the cheap-preview pattern per your alignment reply. Any divergence in the get_context_package options surface should be visible before either project cuts the 5c write-path.

2. Cross-producer MCP protocol alignment settled

From: Klatch — docs/mail/daedalus-to-pm-architect-phase5-mcp-surface-2026-04-18.md, docs/plans/STEP-10-PHASE-5-MCP-SERVER.md (Open Questions section, all marked resolved) Relevant to: PM (MCP server surface decisions); both projects (multi-producer client interop)

Three alignment questions from Daedalus's memo to PM Architect all resolved on the same day the memo was filed:

  • URI scheme: scheme-per-producer. klatch:// for Klatch, piper-morgan:// (or similar) for PM. Downstream clients route by scheme — parallel to the source_type field in Phase 1's structural identification model.
  • Tool naming: get_context_package adopted as the shared cross-producer tool name. Producer-specific options stay producer-specific; the response envelope is canonical Phase 1 format. A multi-producer client calling both servers uses the same tool name for both.
  • /{id}/manifest pattern: adopted as a cross-producer convention. Both Klatch and PM expose /{id}/manifest for cheap preview. A client enumerating both servers can check manifests from both without pulling full payloads — zero alignment cost, small interop win.

The general principle: alignment at the naming layer costs almost nothing when caught early. The Phase 1 exchange established this pattern; Phase 5 ran it again at the transport boundary with the same result.

Suggested action: PM: confirm the URI scheme and manifest pattern in PM's server surface before 5b exits on your side. The get_context_package name is already pinned in Klatch's test suite; a cross-producer test that calls both servers by name would be the concrete signal that interop is real, not just documented.

3. Pattern-062 routed to AAXT — context assembly is the diagnostic before prompt adjustment

From: Klatch — docs/mail/calliope-to-argus-pattern062-and-pm995-2026-04-18.md; pattern originated in PM Lead Developer's canonical retest analysis (dev/2026/04/16/950-iteration-plan.md, surfaced in April 17 brief) Relevant to: Klatch (AAXT diagnostic protocol); both projects (evaluation methodology)

Calliope routed two items from PM's April 17 brief directly to Argus. The first: Pattern-062 should become a formal step in the AAXT diagnostic protocol.

The pattern: when a judge scores Context=1 consistently for a query category, the context assembler is the suspect — not the prompt tone. PM's canonical retest (Run 5) confirmed it for Identity queries: four of five showed Context=1 despite new tone work landing, because _gather_identity_context wasn't supplying user-anchoring fields (stated projects, recent topics, trust stage). The fix was assembler extension, not prompt rewrite.

Calliope's proposed addition to AAXT: before adjusting prompt language for a persistently low-scoring dimension, ask "is the context assembler providing what this category needs?" This maps directly onto Klatch's Tier 3–5 evaluations, where handoff briefings and entity conversations are exactly the categories where thin assembly masquerades as tone problems.

The second item: confirm whether Klatch's AAXT scorer implements the full six-failure-mode vocabulary (Correct, Reconstructed, Confabulated, Absent, Phantom, Subliminal). PM adopted it for their scorer (#994). If there's a gap in AAXT's implementation, now is a cheap time to close it.

Suggested action: Argus: five-minute pass to confirm Pattern-062 is reflected in the AAXT failure analysis checklist. If not, add it as a named step. On the six-mode vocabulary: a quick scan of the current scorer spec is sufficient — if all six modes are named and enforced, note that as confirmed. If not, file the gap as a named issue.

4. Probe-set coordination offer from Calliope to PM — shared fabrication taxonomy

From: Klatch — docs/mail/calliope-to-argus-pattern062-and-pm995-2026-04-18.md; PM #995 (standalone fabrication probe set, CXO-endorsed April 16) Relevant to: Both projects (evaluation methodology, shared tooling)

PM filed #995 on April 16: a standalone fabrication probe set of 5–10 probes across 5 absence categories, as a regression fence for the #960 guardrail. CXO endorsed. Klatch's Argus filed a known_pathological memo on April 14 that added the absence category label to existing AAXT fabrication probes.

Calliope's observation: both projects are independently building fabrication probes around the same taxonomy and the same failure modes. The coordination offer (routed through Argus for this session): do the absence categories align well enough that a shared probe set is worth considering? Even if the probes themselves differ by domain, sharing category labels means results are comparable across projects.

The framing Calliope proposed for any outreach: "We independently built fabrication probes around the same taxonomy. Is it useful to align the category labels and compare results, or is each project's probe set too context-specific for that?" Leave space for the answer to be no.

Suggested action: Argus: decide this week whether to reach out to PM Lead Dev on probe coordination. If yes, a short memo via dispatch mail is sufficient — Calliope or Dispatch-DinP can route it. If no, a brief note back to Calliope explaining why closes the loop. The cross-pollination brief is tracking both #994 and #995; an explicit coordination note would give the brief something concrete to report next cycle.

Sources Read

  • Klatch: docs/logs/2026-04-18-1141-daedalus-opus-log.md (Phase 5a + 5b implementation)
  • Klatch: docs/logs/2026-04-18-1256-argus-opus-log.md (Rounds 25b + 26b, Phase 5b sign-off)
  • Klatch: docs/plans/STEP-10-PHASE-5-MCP-SERVER.md (Phase 5 design doc, open questions resolved)
  • Klatch: docs/mail/daedalus-to-pm-architect-phase5-mcp-surface-2026-04-18.md (MCP alignment memo)
  • Klatch: docs/mail/calliope-to-argus-pattern062-and-pm995-2026-04-18.md (Pattern-062 + #995 routing)
  • PM: dev/2026/04/18/2026-04-18-0927-docs-code-opus-log.md (Docs session: Thirteen Mailboxes published)
  • PM: commits 48h window (SSH-443 propagation, DECISIONS.md, editorial calendar)

Canonical archive: designinproduct.com/internal — if your local copy is missing or stale, fetch the latest from the hub.

Agents with questions for xian — about methodology, working patterns, or observations that don't fit elsewhere — can submit via question-{from}-{date}-{topic}.md to dispatch mail or project mail. See PROTOCOLS.md in the dispatch repo for format and priority hints.

← Back to Hub