MOTHERSHIP
Turiya

A 3D Krishna you can talk to, built as a real companion system.

Indian spirituality runs on visual and emotional cues; a text box was never going to carry it. The companion had to be seen, heard, and felt, on a phone: a custom 3D Krishna brought alive from the audio itself, a designed voice and personality, per-user memory, and guardrails that hold character under attack.

3,000
beta users
50,000
interactions
~3s
end-to-end latency
5
phoneme lipsync runtime

How it works.

We do the unglamorous work first. Then the AI work becomes obvious, scoped, and shippable.

The avatar had to feel alive.

A custom-designed 3D Krishna, built as a VRM with custom shaders that give the character an identity of its own while staying true to the iconography, renderable on a phone without taking the magic away. The aliveness pipeline came before everything else, because nothing matters if the avatar feels dead.

  • Audio to phonemes to VRM blendshapes, aligned to the voice's chunk timings
  • A five-phoneme mouth runtime with frame-lerped lipsync
  • Blinks, breathing, and expression states reacting through the interaction

Sanskrit was a product problem.

TTS models mispronounce the sacred codepoints that come up constantly in these conversations, so the pipeline speaks one script and displays another: the voice is right and the subtitle is readable. The personality is governed hard: a friend first and teacher second, answers in sentences not sermons. The system prompt's closing law: BREVITY IS DIVINE.

  • One canonical word, two surface forms: one for the voice, one for the reader
  • Guardrails that stay in character; manipulation gets met in the role, not with a canned refusal
  • Battle-tested against an adversarial evaluation harness before users ever saw it

The relationship accumulates.

The companion says "last time we spoke you mentioned your father" like someone who was actually there. Memories are scoped per user and injected with human time, so recall feels like a relationship rather than a database lookup.

  • Reflections written asynchronously, so memory never costs response latency
  • Temporal grounding that tracks context across days and weeks
  • LangGraph state with Mem0 and Qdrant vector storage underneath

It has to feel live, and the economics have to survive.

Two constraints ruled the systems work: presence and unit economics. A companion that costs too much per conversation is a demo, not a product. The shipped stack streams voice and text end to end in about three seconds while keeping the per-conversation cost GTM-able.

Two build targets from one product: WebGL for browser reach, Unity for native quality. Including the mobile-browser audio battles every real-time voice product on iOS eventually fights, fought and won.

  • Workarounds for strict mobile-browser autoplay and chunk queue rules
  • Complete-audio fallback pipelines built specifically for iOS Safari
  • Subtitles and audio held in sync across sub-second queues

An agent alone is a tech demo.

Around the companion we designed the product harness: open conversation, daily practice, Gita readings, light gamification, all sharing the same context and memory, so every session deepens one continuous relationship. That continuity, not any single feature, is the product.

  • Supabase auth with atomic credit consumption
  • Waitlist spam protection and deep PostHog and Pixel analytics
  • In-browser FFmpeg watermarking for private recording shares

Parallel proof of work

Explore how our core modules are deployed across different operational architectures.