The "Extend" direction. Bidirectionality as the brand's core tension: you extend Lyra, Lyra extends you.
The duality: the tool shapes the maker, the maker shapes the tool.
For the tinkerer who wants to OWN their stack. Speaks to Yuki directly.
You + AI > either alone. The "intelligence engine" concept — not replacing you, augmenting you.
Understated and powerful. For the dev who will run from marketing fluff.
For developers who self-host and build on their own terms,
Lyra is a Personal Intelligence Engine — an always-on, extensible hub that compounds your capabilities across every tool, channel, and workflow you own.
Unlike cloud AI assistants that lock in your data and limit what you can build,
Lyra runs on your hardware, learns your workflows, and grows as you extend it — giving back more than you put in.
Landing page & README: Lead with the category name "Personal Intelligence Engine" in the hero. Follow immediately with the capability proof: always-on, memory, multi-agent routing, extensible adapters. The positioning statement above can run as a subheading or an About section verbatim.
Conference talks & demos: Open with the problem ("every useful AI tool sends your data somewhere you don't control"), then introduce the category. Let the architecture do the positioning — show the hub, the bus, the pools. The statement is implicit in the demo.
Community channels (early adopters): Only here does "learns your workflows" become the lead. The relationship framing is earned, not announced. Use it in onboarding copy, in-product messages, and persona-level outreach — not on the public homepage.
The dev version leads with architecture signals. "300 lines", "extension point", "fork it" — these are not for everyone. They are deliberate shibboleths. Yuki hears "300 lines" and immediately understands: auditable, lightweight, no magic. Non-devs hear it and move on. That is intentional.
The non-dev version leads with the outcome, not the mechanism. "Runs on your own computer", "remembers your context", "nothing leaves your machine" — these are the same claims, translated. The category name ("Personal Intelligence Engine") appears at the end as a label for what they have already understood, not as an upfront definition they need to decode.
Intelligence framing is the lead everywhere a stranger reads you first. When Yuki lands on your README or sees your landing page, she is evaluating a tool, not a relationship. She wants to know what it does, how it does it, and whether the architecture is trustworthy. "Personal Intelligence Engine" signals a category claim she can verify. It respects her as an engineer. Intelligence framing is honest, precise, and impossible to misread as surveillance.
Relationship framing earns its place after trust is established. Once Yuki has cloned the repo, run the hub, and built her first skill, the experience starts to feel personal in a way she chose. This is when Relationship language becomes accurate — and only then. In community channels, early adopter DMs, and onboarding copy, "Lyra learns your workflow" is not a marketing claim. It is a description of what actually happens. The key move: frame it as workflow, not identity. "Lyra adapts to your patterns" is grounded. "Lyra knows you" is creepy.
The language that makes Relationship work without the surveillance edge: anchor every claim in what the user chose to do. "You added a memory namespace for your work notes — Lyra uses that context in every subsequent query." Not "Lyra remembers you." The user is the agent in these sentences. Lyra is the engine that serves what the user deliberately configured. Autonomy and consent are in every word choice.
What to avoid in both framings: Anthropomorphism that implies awareness Lyra does not have ("Lyra cares about your privacy"), possessiveness that implies lock-in ("your Lyra"), and performance claims that substitute for proof ("the smartest personal AI"). The brand's tone is understated and technically honest. It trusts the product to speak through the architecture, not through adjectives.