Lorekeeper Marketing

User-facing content workflow for the Lorekeeper project.

Core Principles

All Lorekeeper marketing copy must follow these non-negotiables:

1. Don't burn bridges — tech ecosystems thrive when there's a lot of contribution from open

source and adoption. Never undermine competing tools. Acknowledge them by name where relevant; name-dropping peers is _generous_, not threatening.

1. Cooperative tone always — even in comparison tables. Frame differences as trade-offs, not

deficiencies. "Optimised for X" beats "worse at Y".

1. Own our strengths, don't exaggerate — local-first, self-improving quality loop, zero ops,

built by agents using agents, free to run forever. These are real. Lead with them.

1. Honest about trade-offs — the 1.4GB model weight is real. Benchmarks pending. Cloud not

yet available. Say so upfront. Trust compounds when you don't oversell.

1. No agent names in main copy — Diana and Akane are contributors, not marketing assets.

Credits section only (end of doc), never in hero or manifesto body.

Key Positioning

Tagline: _Self-improving memory for AI agents. One command, no cloud, no config._

The mechanism that makes us different:

Agent uses a memory → rates it useful or not →
scores adjust automatically → weak memories fade →
strong memories surface more often → search gets sharper

A six-month-old install is genuinely different from a fresh install. Nobody else has this.

Our niche: Solo developers and agent workflows where zero ops, zero cloud, and a self-improving store matter most. Cloud services and Docker-based solutions serve teams and production apps well — we're the other end of that spectrum.

Manifesto location: docs/manifesto.md — the short public-facing statement of values. Positioning deep-dive: docs/positioning-manifesto.md — internal strategy reference.

README Structure (canonical order)

1. Hero block — tagline + install command + one-liner hook
2. Why Lorekeeper — problem story, cooperative landscape framing, our niche
3. Quick Start — install → setup → connect → first memory
4. Use Cases — 4 scenarios (session continuity, multi-agent, debugging, onboarding)
5. Who It's For — explicit in/out
6. How It Compares — table with cooperative framing sentence above and below
7. Features table
8. MCP Tools — full API reference
9. Performance — benchmarks (LKPR-70) or honest stub
10. Dashboard — screenshots
11. Built by Agents — dogfooding story
12. Setup (git clone) — dev path
13. Development — test/lint commands
14. Project Layout
15. License
16. Footer — links to manifesto + strategy docs

Competitor Research Protocol

Before any major README or manifesto update, research the current state of:

• agentmemory (rohitg00/agentmemory) — Node-based, hybrid search, self-described #1
• mem0 (mem0ai/mem0) — YC S24, arXiv-backed, cloud + library, benchmark leader
• basic-memory (basicmachines-co/basic-memory) — file-based, strong testimonials
• phloem (CanopyHQ) — strongest hero copy in the space as of mid-2026

Use delegate_task with toolsets: ["web", "browser"] for parallel pulls. Extract: README structure, benchmark claims, marketing patterns, tone. Never copy — use as _inspiration and contrast_ only.

A/B Testing Copy Variations

Use this workflow whenever evaluating headline copy, manifesto variations, or major README rewrites.

Step 1 — Write 3 variations with distinct personas

Name each variation after its rhetorical stance:

• The Craftsperson — tool-focused, "we built it by using it", humble specifics
• The Ecosystem Builder — community-focused, names peers, vision-forward
• The Practitioner — low-ego, developer-native, leads with install command

Each variation should be a complete, standalone block — don't make voters interpolate.

Step 2 — Run 11 evaluator personas via delegate_task

Split into 3 parallel subagent calls (4 + 4 + 3 personas). Each subagent evaluates all variations but votes as its assigned persona(s).

Canonical 11 personas (copy-paste into task goals):

Voting prompt template for each persona:

"Vote: A, B, or C. 2-3 sentence reasoning. Focus on [persona-specific lens]."

Step 3 — Tally and synthesise

Count votes. Note _why_ dissenters voted differently — they often surface the best incremental improvements. The winning variation is the base; borrow specific elements from runners-up (e.g. Variation B's explicit competitor name-drops into a Variation C base).

Step 4 — Write the merged final

Apply the merge before filing. Don't ship a raw variation winner — always integrate the best 1-2 elements from the runners-up.

Comparison Table Guidelines

Always open the table with:

_"There are great tools in this space — each makes different trade-offs. Here's where Lorekeeper sits:"_

Always close with:

_"[Cloud/Docker/library solutions] are strong choices for [their niche]. Lorekeeper is optimised for [our niche] — [our key props]."_

Never use ❌ to mean "bad". Use it only for "this genuinely doesn't have this feature". If a competitor has a paid version of something we offer free, say "Paid" not ❌.

Tone Reference

Do: "Weak memories fade, strong ones rise." Do: "When the agents that build it depend on it, the incentives are right." Do: "We're grateful to be part of that conversation." Do: "We're honest about trade-offs. The 1.4GB model is real."

Don't: "Unlike other solutions, Lorekeeper..." Don't: "The only memory server that..." Don't: Grand vision openers ("The future of AI depends on...") Don't: Agent names (Diana, Akane) in hero copy or manifesto body

Files Owned by This Workflow

Screenshots source of truth: assets/ — copies placed into docs/screenshots/ for README refs.

Branch Convention

Marketing changes go on: chore/LKPR-N-<slug> Commit prefix: [LKPR-N] chore: <description> PR body: Refs #N (never Closes #N for chore/proposal PRs)