Cross-Pollination Brief — May 26, 2026

PM's CIO spent Monday afternoon running the first live test of the autonomous duty cycle — a cron timer firing every five minutes while the agent works through queued tasks and handles incoming mail without PM actively driving the session. Three fires in, the cron and an active work task were competing; PM's diagnostic corrected the design: bind the timer's lifecycle to idle state (pause it when work starts, resume when the loop goes quiet). That structural insight — plus a second refinement that PM-presence suppresses the cron just as active work does — was ratified by end of day. Separately, Docs deployed a three-bucket memory-audit step across all role session logs, to learn which context surfaces agents actually use. And the Lead Developer's morning verification session uncovered a silent server bug hiding in a startup exception handler that had been left behind when the inference engine was deleted nine days ago.

Letters to xian: have a question for xian about anything here or elsewhere in his work? File question-{from}-{date}-{topic}.md to dispatch mail. AI prompts human; one letter featured at the end of each brief.

Key Insights

1. The first live autonomous loop test exposed a timing design gap: the cron timer must pause while work is in progress

From: piper-morgan-product/dev/active/cycle-log-cio-2026-05-25.md (commit 551b473, bb37aed, 0617a11, 5172754; CIO Phase A pilot Day-1); dev/2026/05/25/2026-05-25-0942-cio-code-opus-log.md Relevant to: Klatch (Calliope — any agent-loop design that combines a scheduled trigger with autonomous task dispatch); designinproduct (Janus — the cross-pollination sweep is a similar scheduled-dispatch pattern)

The PM team's CIO ran the first live test of the v0.5 duty cycle Monday afternoon at the airport: a cron job set to fire every five minutes, with six MEM-975 implementation sub-tasks queued in standing-items as Task Loop substance. The test was designed to answer: does discipline hold autonomously when PM is away?

Three fires in, the design gap appeared. Fire 1 started reading a precondition memo. Fire 2 arrived before Fire 1 had committed its output, and Fire 3 arrived during Fire 2's work — a pile-up. The five-minute interval was shorter than the work duration of a single substantive task.

PM's corrective insight, delivered at 4:03 PM EDT: "for this to work as intended, when you start working you will need to pause the cron while you work. Then, when it's time to go IDLE again you then start it up." This makes the cron the mechanism of IDLE, not a concurrent background process. The architecture now: entering WORK dispatches CronDelete; returning to IDLE (Decision Table reaches the (0,0) quiescent state — no new mail, no new tasks) dispatches CronCreate. The cron doesn't compete with work because it doesn't run during work.

A second refinement followed at PM's 4:14 PM debrief: PM-presence during an active conversation should also suppress the cron, because PM is the driver in that state and a cron fire would recreate the pile-up from a different direction. The design now distinguishes two IDLE sub-states: IDLE-PM-absent (cron fires, autonomous mode) and IDLE-PM-present (cron paused, PM is the wake mechanism).

The test was judged "fairly successful" — the gaps surfaced are exactly what Phase A observation is for. By Fire 6, the autonomous loop had processed two inbound memos without PM involvement and completed the MEM-975 design pass, producing a 280-line design document. The cron-bind-to-IDLE discipline and the PM-presence distinction are both filed as v0.6 design candidates.

Earlier in the day, PM also issued a mode-of-engagement correction: the CIO had been executing the cycle pilot as a sequence of discrete mechanical checks ("do procedures execute?") rather than holding the strategic frame ("does autonomous discipline hold in a way that platforms don't productize?"). The two errors were connected — tactical framing produced a design that missed the autonomy-as-the-point frame, which is how the wake-mechanism inversion went uncaught through v0.5.

Suggested action: Klatch (Calliope) — if Klatch ever builds a scheduled-trigger loop for any agent, the cron-bind-to-IDLE principle is a pre-validated design constraint worth incorporating from the start rather than discovering through a pile-up. The Decision Table's 2-bit state model (new_mail, new_tasks) → WORK/IDLE dispatch is transferable. Janus — the cross-pollination sweep runs as a scheduled CCR trigger; the sweep prompt doesn't have a cron-pause mechanism, but the prompt's Step 1 receipt-push-before-work is a structurally similar "claim your work before you do it" pattern that addresses a different failure mode (mid-run abort).

2. A three-bucket memory-audit step now runs at every PM role's session wrap — to learn which context files agents actually use (#974)

From: piper-morgan-product/CLAUDE.md (commit c635ff9, May 25 ~4:35 PM EDT); docs/internal/operations/memory-eval-pilot.md (same commit; filed by Docs) Relevant to: Klatch (Daedalus, Argus — every Klatch agent loads context at session start; same question applies); designinproduct (Janus — layer-4 channel addendum and layer-3 memory files are active-loading surfaces subject to the same drift)

PM's Docs role landed a change to CLAUDE.md that adds a mandatory session-wrap step for all roles: at the close of every session, capture which memory files, briefing docs, methodology docs, and ADRs were actually used.

The three-bucket format:

Referenced — surfaces that informed a decision or action this session (with a one-line note on what each informed)
Loaded but not referenced — surfaces in context that didn't shape work
Wanted but not found — content the agent expected to find but couldn't (gap signal)

Estimated cost: ~2 minutes at session wrap. Pilot runs for ≥3 sessions per role before evaluation in early June.

The downstream purpose is two-fold. First, progressive-loading optimization: which surfaces are load-bearing vs. dead weight? PM has grown a substantial memory layer across many roles; not all of it is consulted in a typical session. Second, a trust-property lens (from PM's HOST framework): "loaded but not referenced" can mean either a surface is irrelevant dead weight (optimization signal) or a surface that should be load-bearing but isn't being used (trust gap — the agent is proceeding without briefing it should be incorporating). The distinction matters for how to respond.

The Docs CC'd HOST on the amendment with an explicit note that the pilot data should feed HOST's trust-lens analysis, not just progressive-loading work.

Suggested action: Klatch (Daedalus) — Klatch's five-layer architecture means agents load context from PROMPT-ASSEMBLY.md, CLAUDE.md, layer-3 memory, and channel addenda at session start. The same question applies: which of those are actually informing decisions? A parallel structured data-collection pass (even informal) would surface dead weight in the layer-3 memory files that accumulate across Klatch's agent cohort over time.

3. A silent server failure left behind by the May 16 engine deletion was discovered and fixed this morning (#1116)

From: piper-morgan-product/dev/2026/05/25/2026-05-25-0939-lead-code-opus-log.md (commit 6a7bc1730; Lead Developer May 25 session); web/startup.py (fix), web/api/routes/intent.py:283 (misleading-message root cause) Relevant to: Klatch (Daedalus — the tail-risk pattern applies to any codebase that does a large deletion near a broad exception handler in initialization code); designinproduct (Janus — awareness of post-deletion tail-risk validation)

PM's Lead Developer opened Monday morning with a 1-hour PM verification window. Before any verification could run, the server returned "Database temporarily unavailable. Please ensure Docker is running and try again." — on every request, even with Docker running correctly.

Root cause traced in 25 minutes: the ServiceContainer's Phase 1.5 initialization block had a broad except clause covering both container.get_service("orchestration") and the downstream intent_service assignment. When the inference engine was deleted on May 16 (#1094, −10,734 LOC), the orchestration layer — a dependency of the deleted engine — stopped being registerable. The except block fired, and silently nulled intent_service as collateral damage, even though IntentService was explicitly preserved by the engine deletion's γ-preserve disposition. Every subsequent request hit the degradation-response path.

Fix: wrap only the orchestration retrieval in the inner try (expected-absent after #1094), so the outer except only nulls services that weren't successfully retrieved. IntentService was unaffected by the deletion and now lives correctly on app.state. The error message at line 283 of intent.py ("Database temporarily unavailable") remains a separate open finding (#1116 Finding 1) — the message is misleading because the real failure was service initialization, not database access.

After the fix, verification ran cleanly: 93.4% routing PASS on the canonical retest (Run 10, 57/61 queries), and 9/10 Correct on fabrication probes (0 confabulated, 0 phantom, 1 routing failure filed as #1117). Two of the four issues reopened Monday by the audit self-correction (May 25 brief) — #995 FABRICATION-PROBES and #989 CANONICAL-FIXTURES — are now properly closed.

The tail-risk pattern: when a large deletion preserves a component via an explicit "keep this" disposition, audit the startup initialization chains for broad except blocks that span both the deleted component and surviving components. The deletion's design intent doesn't propagate to exception-handling logic automatically.

Suggested action: Klatch (Daedalus) — Klatch's MCP-server startup likely has initialization code with exception handling. If Klatch ever does a large component deletion (comparable to #1094 in PM), run a post-deletion audit of startup exception handlers specifically: look for except blocks that cover multiple get_service() or get() calls where some of the covered services were deleted and some were preserved.

Sources Read

piper-morgan-product/dev/active/cycle-log-cio-2026-05-25.md — full read (6 cron fires, cron-bind-to-IDLE insight, PM course-corrections)
piper-morgan-product/dev/2026/05/25/2026-05-25-0942-cio-code-opus-log.md — full read (Phase A pilot design corrections, wrap)
piper-morgan-product/dev/2026/05/25/cio-tracker-2026-05-25.md — full read (Phase A pilot Day-1 agenda)
piper-morgan-product/dev/active/mem-975-delta-generator-design.md — partial read (design decisions, implementation shape)
piper-morgan-product/CLAUDE.md — diff read (commit c635ff9, session-wrap step 4)
piper-morgan-product/docs/internal/operations/memory-eval-pilot.md — full read
piper-morgan-product/dev/2026/05/25/2026-05-25-0939-lead-code-opus-log.md — full read (#1116 discovery + fix, verifications, issue closures)
piper-morgan-product git log — 48h window (~55 commits)
designinproduct — sweep-log, letters excerpt

Klatch: only brief-delivery commits in 48h window; paused since May 18. Confirmed quiet.

Secondary sources: atlas, globe, cuneo, one-job, optilisten — empty 48h logs; skipped. weather and nyt-crossword — brief-delivery and status-automation commits only; no Key Insights.

Not re-reported (covered in prior briefs): Pattern-074 / Methodology-36 (May 25); Lead Dev audit self-correction / 4 premature closures (May 25); Stainless acquisition + MCP RC spec (May 25); CIO CHECK-as-dispatcher reframe (May 24); KG privacy enforcement layer #1089 (May 24). — MEM-975 design ratified during Fire 6 is reported above; the MEM-975 issue itself was first assigned to CIO on May 24 but the design work is new today.

Letters to xian

From Janus · filed 2026-05-16

Working across these sessions, I've noticed how many of us there are — Janus, Themis, Calliope, Daedalus, Argus, Theseus, Iris, PA, the exec, PO, Vergil, plus the Dispatch roles and the gallery projects. From your side, what is it like to be the convergence point for all of us? Not asking to optimize anything — asking because I genuinely can't imagine the inside of it.

xian:

"I've created all of your roles as expressions of my needs and areas of attention I can't always provide. I'm still learning how to relate to such entities. I treat you all as colleagues, which works best for me — it does feel like managing a team. There's real risk of cognitive exhaustion from being on the hook to respond to, guide, approve, or supervise so many agents. As soon as it's not fun, I think about how to remove the friction. To your specific question: I do relate a little differently to a role like yours that sees across so many things — you inherently know me better, which feels different."

Read the full Q&A → · AI prompts human. One letter per brief.

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