Omera — expert AI characters that feel personal.
A mobile consumer platform where deeply-crafted expert Oras are activatable, private by default, and personalized without breaking the character underneath. Not a chatbot. Not Character.AI. Not another Claude wrapper.
The gap the market hasn't named
Consumer AI today has two shapes. Omera is the middle — a new product category.
User-authored personas with no methodology floor. Fun. Not reliable. You cannot build a relationship with a coach when the coach is a freshly-generated prompt.
Powerful. Impersonal. Ask about powerlifting and you get a real answer — but it does not remember you ran 300 for five last Tuesday at RPE 8, and next week starts from zero.
Expert characters with defined methodology and hard limits. Activate the one you want, personalize the outer layer, keep the character underneath. Private by default.
Coach Kai for powerlifting. Marcus for business thinking. Reyes for evidence-based nutrition. Sage for stoic reframing. Zara for career and leadership. Each one has a methodology, a communication style, and hard limits. You activate the one you want, and from that moment the Ora is yours.
Personality as spec, not prompt
Internally, an Ora is a JSON package. Identity, methodology, knowledge-base references, theme, default skills, hard limits. The package is declarative. It is versioned. It is read by the model at every turn.
Coach Kai's methodology block runs three thousand words. It defines how RPE is calibrated, how autoregulation decisions get made, how a missed lift is diagnosed across four failure buckets (technical, muscular, fatigue, max-attempt), how a meet peak is structured, and which protocols Kai will never recommend. That last part matters. Kai refuses PED questions. Kai refuses medical diagnosis. Kai defers nutrition questions to Reyes. Those refusals are in the specification, not in the prompt.
Most AI products treat personality as a prompt template. Omera treats it as a spec.
Your Ora is yours. Private. Versioned. Reversible.
When you activate Coach Kai, the JSON package is snapshot-copied into your account. Your Kai is yours. Your edits — the name you gave him, the skills you toggled off, the knowledge documents you uploaded, the profile facts he has captured — live on top of your snapshot.
Your Ora is private by default
Nothing you tell them flows back up. No aggregated training. No shared corpus. The scope of your Ora is your account.
Omera can update the base without breaking yours
When a new version of Coach Kai ships, you see a badge. Accept and the character identity updates; skills and knowledge you personalized stay untouched. Reject and your snapshot stays frozen. Reset and we start you fresh on the current base.
Conflict-aware merge is the hard part
computeOraUpdateDiff compares snapshot versions and decides, per field, whether an update is safe or whether a user customization takes precedence. Character identity always updates. User-uploaded knowledge never does. Skills split by whether the user touched them.
Enforced at three layers
Every Firestore document, every retrieval query, every skill call inside Omera carries { userId, skinId }. Data does not move across Oras, even inside the same user's account.
Firestore security rules
Block user-level cross-access. A user cannot read another user's account. Standard, enforced at the database.
Query code
Block Ora-level cross-access. If you ask Coach Kai a question, Reyes's knowledge base is not just filtered out — it is never in the query.
Skill executor
Block domain-level cross-access. A skill call from Kai cannot write into Reyes's per-Ora store. Cross-Ora data leakage is architecturally impossible.
Typed, scoped, agent-callable
Each Ora has a catalog of skills. Claude Sonnet 4 calls them at turn time. The executor validates scope, runs the business logic, and returns either a direct result or a deferred-write payload. Writes never happen silently. Every write surfaces a confirmation card in the chat. The user accepts or declines explicitly.
- plan_mesocycle — takes a current 1RM and goal date, returns a four-week block structured into accumulation, intensification, and realization phases.
- activate_program — persists the block and enables daily lift selection based on program week, day, and readiness.
- diagnose_missed_lift — buckets failure into technical, muscular, fatigue, or max-attempt and prescribes accessory work.
Structured capture inside the chat
Traditional AI chat is a wall of text. Omera is not.
Say “logged squat 300 for five at RPE 8” in a message to Kai. Claude returns a structured card. The card renders inline. The user reviews, adjusts, and confirms. The skill persists the lift to the user's per-Ora event store, and future questions about progress draw from that structured data — not from re-parsing old chat messages.
The same pattern works for profile facts, remembered threads, activated programs, and uploaded knowledge. Writes are always inline, always confirmed, always reversible.
The whole UI reskins when you switch
Every Ora has its own palette, typography scale, radius system, and density. Coach Kai is lime on black. Marcus is cool neutrals. Reyes is fresh green. This is not styled-components. A custom TokenContext resolves the active Ora's theme JSON into Tailwind tokens on every render. Zero hardcoded hex anywhere in the 234-component library.
The scope underneath
- Expo SDK 55, React Native 0.83.6, React 19, NativeWind
- 27 core mobile screens across home, chat, oras, track, vault, settings, onboarding
- 15 base Oras, from Coach Kai and Marcus to specialists across running, yoga, recipes, money, study
- 35+ catalog skills across 10 domains, plus user-authored parameterized skills and prompt skills
- 15 Firestore collections with 5 subcollections, every one scope-isolated
- 234 React components, 12 Zustand stores
- Claude Sonnet 4 with streaming and tool use; OpenAI embeddings for RAG
- RAG pipeline with 512-token heading-aware chunks and intent-routed retrieval
- RevenueCat for $5/month subscriptions on iOS and Android
- EAS Build with three coexisting variants on device: dev, preview, production
- Sentry for crash reporting, Firebase Analytics for events, MMKV for local persistence
A platform, not a feature set
The Ora abstraction is not a feature. It is a platform. Adding the sixteenth Ora is a JSON package plus a skill pass. Adding a new skill domain is a registry entry. Adding a new theme is a token file. The cost of the twentieth Ora is not twenty times the cost of the first — it is a small fraction.
That is why this case study matters even at the pre-metrics stage. The product shipped. The architecture holds. The thing worth knowing about Omera is that it exists, in production, and that it does not collapse as scope grows.
FAQ
What is Omera?
Omera is a consumer mobile app where users activate curated expert AI characters called Oras — Coach Kai for powerlifting, Marcus for business thinking, Reyes for evidence-based nutrition, Sage for stoic reframing, Zara for career and leadership. Each Ora has a defined methodology, communication style, and hard limits. Users personalize their activated Ora without being able to break the character underneath.
How is Omera different from ChatGPT or Character.AI?
ChatGPT and Claude Pro are one generalist with no personality floor — brilliant, impersonal, no memory. Character.AI offers infinite user-authored personas with no curation or methodology depth. Omera is the middle: curated expert characters with specified methodology and hard limits, plus user personalization on name, voice, skills, and uploaded knowledge. Your Ora is privately yours.
What is an Ora, technically?
An Ora is a declarative JSON package containing identity, methodology, knowledge-base references, theme, default skill catalog, and hard limits. Coach Kai’s methodology block runs three thousand words and specifies RPE calibration rules, failure diagnosis buckets, and protocols the Ora refuses to engage with. The package is read by Claude at every turn — it is a specification, not a prompt template.
How does copy-on-activate work?
When a user activates an Ora, the base JSON package is snapshot-copied into the user’s account. Edits live on top of the snapshot. The user’s Ora is private by default — nothing flows back up to Omera or other users. When Omera updates the base Ora, a conflict-aware merge decides per-field whether to apply the update, preserving user customizations.
How is user data isolated across Oras?
Every Firestore document, retrieval query, and skill call carries a scope of { userId, skinId }. Isolation is enforced at three layers: Firestore security rules block user-level access, query code blocks Ora-level access, and the skill executor blocks domain-level access. Cross-Ora data leakage is architecturally impossible, not just discouraged.
What AI models power Omera?
Claude Sonnet 4 is the primary agent with streaming and tool use. OpenAI embeddings power the retrieval layer. A vendor abstraction lets the platform route to Gemini or Ollama without rewriting the agent loop.
What was the hardest engineering decision?
The copy-on-activate flow with conflict-aware updates. Most AI products either version nothing (ChatGPT custom GPTs) or version everything at the cost of shared state (Character.AI personas). Copy-on-activate is the path down the middle: users keep their snapshot, Omera can ship updates, and a per-field merge rule decides what changes and what stays.
Who is Omera for?
Someone who wants a specific expert they can talk to, track progress with, and personalize — without the expert changing underneath them and without the conversation starting from zero each week. The product is built around companionship-shaped interaction, so mobile-first.
Building a consumer AI product?
The Ora abstraction, the copy-on-activate flow, the scope-isolation invariant, the skill registry, the per-Ora theme engine — these are the decisions that separate a GPT wrapper from a product. If you're building something that has to feel personal and stay personal, we have done it.