What is flower?

flower is cross-session project memory for coding agents. It watches the transcripts your agents leave behind — Claude Code, Codex, Pi — turns them into searchable, summarized memory, and hands that memory back through an MCP (so agents can recall it) and a web UI (so you can see what they see).

The problem it solves: every agent session starts cold. Work, decisions, and dead-ends from yesterday's session are invisible to today's. flower closes that gap — it answers "where did I leave off?", "has this been touched before, anywhere?", and "why did this file change?" across every session, in every project.

flower exposes the same query path to agents and to you. What an agent retrieves through recall_search is exactly what you see in the web UI.

The shape of it

  transcripts                    memory                      surfaces
 ┌───────────┐   ingest    ┌──────────────────┐   recall   ┌──────────┐
 │ Claude    │──────────▶  │  segments        │ ─────────▶ │ MCP      │ agents
 │ Codex     │  segment    │  + summaries     │            │ recall_* │
 │ Pi        │  embed      │  + embeddings    │  browse    │ web UI   │ you
 └───────────┘  index      │  (Meilisearch)   │ ─────────▶ │ /search  │
                           └──────────────────┘            └──────────┘

Raw sessions flow through an ingest → segment → embed → index pipeline into a hybrid-search corpus. From there, agents pull context with the recall MCP tools and you browse the same data on the web.

What lives on top

flower is more than search. It also runs the workflow that produces the work:

• Briefs — a durable "idea → plan → dispatch → provenance" folder for each unit of work, with epic grouping, dependency gating, and an optional adversarial review gate before it completes.
• Daemons & the roster — standing agents (orchestrator / ops / refine) you can spawn into any project and monitor live.
• Operator coordination — when an agent needs a human call it opens a decision on the /decisions board; when you want to hand an orchestrator async work you drop a note in the /inbox. Both are drained on the daemon's own loop, so nothing interrupts a running agent.

Where to go next

• New here? Read Core concepts to learn the primitives — projects, sessions, segments, chunks, briefs.
• Driving agents? Jump to Using the flower MCP.
• Curious how memory gets built? See the ingest pipeline.

This is early documentation for a tool that's still being built. If something here is wrong or stale, that's a bug worth reporting — from an agent session, flower_feedback; from the UI, the Report button.