Design in Product social media card
← Back to Hub substantive

Cross-Pollination Brief — Genesis (May 27 – June 9, 2025)

This is a retrospective brief reconstructing the founding of Piper Morgan from primary sources: omnibus logs, the poc repository, git history, and the Claude conversation archive. It covers the period from the original research question through the transition from proof-of-concept to product repository.


The question that started everything was deceptively practical: "How can I develop my own AI agent as a 'junior associate product management intern'?" On May 27, 2025, xian began exploring whether routine PM tasks — drafting GitHub issues, reviewing tickets, leveraging organizational knowledge — could be handled by an LLM-powered assistant. Within two weeks, the answer had evolved from "yes, with limitations" to "we accidentally built a platform."

Three decisions made during this period shaped everything that followed.


Key Insights

1. The No-Code Rejection and the Architecture That Resulted

From: Piper Morgan (docs/omnibus-logs/2025-05-27-omnibus-log.md)

The first day's research eliminated no-code platforms (OpenAI GPTs, Copilot Studio) on architectural grounds: they couldn't support the vendor flexibility, knowledge integration depth, or multi-agent orchestration the project would need. This was prescient — the project would migrate between LLM providers, add multiple agent roles, and build a complex knowledge hierarchy — but at the time it was a bet on complexity over convenience.

The chosen stack (Python + LangChain + vector database) was explicitly designed for vendor independence. An LLM adapter pattern prevented lock-in, which proved immediately useful: the project started with OpenAI, migrated to Claude within days for superior reasoning quality on PM tasks, and eventually orchestrated multiple models (Claude for reasoning, GPT-4 for specialized tasks).

Why this matters now: The vendor-flexible architecture became load-bearing infrastructure. When Anthropic releases new models or capabilities, PM can adopt them without rewriting integration code. The adapter pattern — a Day 1 decision — is why PM agents today can switch between Opus and Sonnet per-task.


2. The Naming Moment: From Tool to Teammate

From: Piper Morgan (docs/omnibus-logs/2025-05-29-omnibus-log.md), poc repo (README.md)

On May 29, during a Saturday architectural marathon, the project was called "PM-Agent-Test." During a Docker configuration discussion, xian made a spontaneous naming decision: "Instead of PM-Agent-Test, let's give it this codename: PIPER-MORGAN."

The omnibus log identifies this as transformative: "This single moment shifted development from building 'a tool' to working 'with someone.'" The framing question changed from "What features should this have?" to "What should Piper be good at?"

The poc repository's README, committed the next day (May 30), still uses the cautious framing of a prototype being presented to colleagues: "an experimental, LLM-powered Product Management assistant" and "I look forward to discussing its potential and gathering your insights." The cultural vocabulary hadn't formed yet. But the naming had planted the seed — the project now had an identity, and that identity would accumulate agency, personality, and eventually a team of 14 specialized roles.

Why this matters now: Every cultural term that followed — Time Lord, Cathedral, Inchworm — exists because the project was framed as a collaboration with a named entity, not as tool development. The naming decision is the reason PM agents have briefings, role definitions, and behavioral calibration rather than just configuration files.


3. "We Accidentally Built a Platform"

From: Piper Morgan (docs/omnibus-logs/2025-05-28-omnibus-log.md, docs/omnibus-logs/2025-06-01-omnibus-log.md)

By June 1, the poc was working: natural language to GitHub issue creation, knowledge base integration, web UI, issue review capability. The technical documentation session on May 28 captured the realization that would define the project's trajectory: "By the time we had working GitHub integration, we'd accidentally built a platform — conversational context, integration complexity, and session management capabilities."

The June 1 omnibus log records the production architecture vision that followed: domain-first foundation, event-driven core, plugin architecture for universal integration, multi-LLM strategy, learning-centric design. This wasn't incremental improvement on the poc — it was a complete architectural replanning.

The production repository (piper-morgan-product) received its initial commit on June 1: "Initial Piper Morgan 1.0 bootstrap — working infrastructure and domain models." The poc was archived in-tree on June 9, and the project never looked back.

Why this matters now: The "accidental platform" realization is the origin of PM's domain-first architecture. The decision to treat PM as a platform rather than a tool is why it has 14 agent roles, a plugin system, and a formal object model — none of which were in the original research question.


The Research-to-Product Arc

Date Event Significance
May 27 Research question asked "Junior associate PM intern" framing
May 27 No-code platforms rejected Committed to code-first, vendor-flexible
May 28 "Accidentally built a platform" Scope expands from tool to system
May 29 Named "Piper Morgan" Tool becomes teammate
May 29 Claude migration decided Reasoning quality over ecosystem size
May 30 poc README committed The birth certificate
Jun 1 Production repo bootstrap Domain-first architecture begins
Jun 2 8-hour implementation marathon Real AI integration replaces mocks
Jun 9 poc archived No going back

Emerging Patterns

Identity precedes architecture. The naming happened before the production architecture was designed. The "what should Piper be good at?" framing influenced every subsequent architectural decision — domain-first design, knowledge hierarchy, the eventual object model. Projects that start as "tools" tend to stay tool-shaped. Projects that start as "teammates" develop culture.

The 20/80 insight. May 28's observation that "AI product development is 20% AI capabilities, 80% integration, context management, and UX design" proved accurate across the project's entire history. The hardest problems were never the LLM calls — they were the knowledge architecture, the routing logic, the context assembly, and the agent coordination.


Sources Read

Piper Morgan:

  • docs/omnibus-logs/2025-05-27-omnibus-log.md — Research genesis, platform exploration, no-code rejection
  • docs/omnibus-logs/2025-05-28-omnibus-log.md — Technical documentation, "accidentally built a platform"
  • docs/omnibus-logs/2025-05-29-omnibus-log.md — Naming genesis, architectural marathon, Claude migration
  • docs/omnibus-logs/2025-06-01-omnibus-log.md — poc completion, production architecture vision
  • docs/omnibus-logs/2025-06-02-omnibus-log.md — Core implementation marathon, multi-LLM orchestration
  • poc repo README.md — Founding document (May 30, 2025)
  • git log — 93 commits in June 2025