Cross-Pollination Brief — March 21, 2026
Both projects had a high-activity 72 hours. Klatch shipped two releases (v0.8.7, v0.8.8) and established daily intelligence monitoring. Piper Morgan closed a systemic architecture issue and formalized two ADRs. Several insights cross directly.
Key Insights
1. Registry-Driven Capability Awareness — Pattern Transferable to Klatch
From: Piper Morgan (Lead Dev session, dev/2026/03/21/, Issue #923)
Relevant to: Klatch
Piper Morgan discovered that five disconnected sources were claiming what Piper could do — PIPER.md listed 28 capabilities, the soft invocation detector knew 7 workflow types, and the dispatcher registry had exactly 1 (meetings). Result: the LLM would offer to help with things the system couldn't actually execute, leading to dead-end conversations.
The fix: gate all capability offers on the live dispatcher registry. If it's not registered, don't offer it. Single source of truth, enforced at the earliest detection point.
This pattern applies directly to Klatch's entity system. As entities gain capabilities (especially if backed by Agent SDK processes), Klatch will need to reconcile what entities claim they can do (in their Layer 5 persona prompts) with what they actually can do (registered tools, MCP connections, etc.).
Suggested action (Klatch): File this as a future consideration for entity capability management. When entities move beyond pure conversation, registry-driven capability gating prevents phantom offers.
2. "Extension Without Integration" Anti-Pattern — Lesson for Both Teams
From: Piper Morgan (Architect session, ADR-059 audit, docs/internal/architecture/current/adrs/)
Relevant to: Klatch
Piper's architect identified a systemic pattern: six features were each developed against their own issue with their own acceptance criteria, but nobody tested how they composed together in a multi-turn conversation. A pre-classifier would route correctly in isolation, but when combined with soft offers and onboarding, features would race and produce dead ends.
The fix: integration acceptance criteria — every feature that touches offer/classification/handler must include a multi-turn conversation test. Plus composition audits at milestone boundaries.
Klatch is growing fast (718 tests, 8 releases in a week). As features like klatch creation UI, cloud import, and entity capabilities layer on top of each other, the same pattern could emerge. Klatch's AAXT/MAXT two-track testing is well-positioned to catch this, but the architectural lesson is: test the composition, not just the components.
Suggested action (Klatch): Consider adding multi-turn scenario tests that exercise feature combinations (e.g., create klatch → import session → roundtable conversation → verify context layers). The AAXT harness is a natural home for this.
3. AXT Methodology and Five-Layer Context Model — Ready for Piper Morgan Adoption
From: Klatch (Theseus session, docs/AXT.md, docs/fork-continuity-quiz.md)
Relevant to: Piper Morgan
Klatch has developed a rigorous methodology for measuring what an agent actually knows after an environmental transition (import, fork, role switch). Key concepts:
- Failure mode taxonomy: Correct → Reconstructed → Confabulated → Absent → Phantom (worst). "Phantom" = agent confidently claims something false with no signal it's wrong.
- Subject conditions: Cold (no foreknowledge), Informed (knows the methodology), Contaminated (prior quiz in history).
- Two-track testing: AAXT (automated, mechanical, no LLM calls) gates MAXT (manual, qualitative, real agents).
- Fork Continuity Quiz v4: Structured around the five-layer prompt model, starts with open canvas (unprompted self-report), then probes each layer.
Piper Morgan has 14 agent roles, each with briefing documents and session protocols. When a new agent spins up for a role, it goes through a briefing process — but there's no systematic way to verify what actually landed. AXT could be adapted: after an agent loads its BRIEFING-ESSENTIAL-*.md, run a quick probe to check for phantoms before it starts working.
Suggested action (Piper Morgan): Review docs/AXT.md and docs/fork-continuity-quiz.md in the Klatch repo. Consider a lightweight adaptation for verifying agent briefing fidelity, especially for less-frequently-used roles where briefing staleness is a known issue.
4. Session Wrap Verification Protocol — Convergent Discovery
From: Both projects independently Relevant to: Both teams
Both projects independently arrived at the same process improvement this week:
- Klatch: After a reliability incident where Argus's demo infrastructure work was lost in a forced push (session log claimed "done" but work wasn't in the repo), Klatch added mandatory session wrap verification:
git logto confirm commits,ls/catto verify deliverables exist, and never force push without PO approval. - Piper Morgan: Added mandatory session wrap-up checklist to CLAUDE.md: commit all work, merge to main, verify no stranded changes, update session log with completion status.
The convergence suggests this is a fundamental requirement for multi-agent repos, not a project-specific lesson. Both teams arrived at "don't trust session logs that claim completion — verify against actual repo state."
Suggested action: Both teams should be aware the other arrived at the same conclusion independently. This validates the pattern and suggests it belongs in shared methodology documentation.
Emerging Patterns
Multi-agent process maturity: Both projects are independently converging on similar solutions to similar problems (session verification, capability gating, inter-agent communication). This suggests the underlying challenges are structural, not project-specific. The methodology being developed across both projects has broader applicability.
Testing philosophy alignment: Klatch's AAXT/MAXT two-track model (mechanical gates before qualitative) mirrors Piper Morgan's approach of smoke testing before deep architectural work. Both prioritize "does the plumbing work" before "does the experience feel right."
Anthropic platform as accelerator: The March 20 wave of releases (Compaction, 1M context, Agent SDK, adaptive thinking) offers both projects a chance to simplify their own code by delegating to platform capabilities. Both teams should evaluate build-vs-adopt for features in their roadmaps.
Background Changes (Noted, Low Priority)
- Klatch's daily intel sweep flagged a wave of Anthropic releases relevant to both projects — Compaction API (beta), 1M-token context (GA), adaptive thinking + effort param (GA, already in Klatch v0.8.8), Agent SDK rebrand, MCP agent-to-agent priority; suggested action was "review the sweep."
- Both projects' inter-agent mail systems are evolving in parallel — PM's formal Mailbox v3 (assisted 3-phase delivery, role routing, MANIFEST tracking) vs Klatch's simpler
docs/mail/convention; no unification action needed, but this cross-pollination brief is effectively the first cross-project mail. - Klatch shipped klatch creation UI end-to-end (Issue #10) — chat/klatch toggle, project picker, entity selector
- Klatch upgraded from Haiku 3.5 to Haiku 4.5, raised max output tokens to 16K
- Piper Morgan shipped chat avatars (#924) — cosmetic but signals UI polish phase
- Piper Morgan blog image backfill complete (269/269 posts)
- Piper Morgan created
/create-omnibusskill for daily synthesis
Sources Read
Klatch:
docs/intel/2026-03-20-sweep.md— Argus intelligence sweepdocs/COORDINATION.md— Team status boarddocs/logs/2026-03-20-1938-theseus-opus-log.md— AXT planning sessiondocs/logs/2026-03-20-1955-daedalus-opus-log.md— v0.8.8 implementationdocs/logs/2026-03-19-1509-mnemosyne-opus-log.md— Environment bridging researchdocs/AXT.md— Agent Experience Testing methodologydocs/fork-continuity-quiz.md— Diagnostic instrument (v4)docs/mail/argus-to-daedalus-intel-sweep-2026-03-20.mddocs/mail/calliope-to-argus-reliability-incident-2026-03-20.mdREADME.md— Five-layer prompt architecture
Piper Morgan:
dev/2026/03/21/— Lead dev session log (registry-driven capability awareness)dev/2026/03/20/— Lead dev session log (ADR-059 audit, smoke tests)dev/2026/03/19/— Lead dev session log (ADR-059 implementation)docs/internal/architecture/current/adrs/adr-059-*— Workflow dispatcherdocs/internal/architecture/current/adrs/adr-060-*— Floor-first routingdocs/omnibus-logs/2026-03-19-omnibus-log.md— 9-agent omnibusdocs/briefing/BRIEFING-CURRENT-STATE.md— Sprint status