Back to Projects

    Helel.ai — Real-Time AI Video Companion

    Helel.ai is a production AI companion you meet over live avatar video instead of a text window. A personality assessment builds your profile, consent-gated memory retains only what you explicitly approve and retrieves it with vector search, and a provider-agnostic core lets the AI and avatar vendors be swapped by configuration.

    2026
    Full-Stack Engineer
    8 Technologies
    Next.js (App Router)React 19TypeScriptPostgreSQLVector store (RAG)Real-time avatar video (adapter)Zod schema validationServerless / Vercel
    Helel.ai — Real-Time AI Video Companion

    Verify it yourself

    Introduction

    Most 'AI companion' products are a chat box with an avatar photo pinned next to it. Helel.ai starts from the opposite premise: you meet the companion face to face in a live video session, and the conversation feels like a call rather than a thread. This was client work with a real production target, which meant the interesting problems were never the model prompt — they were session lifecycle, privacy the user can actually reason about, and an architecture that would not trap the client with a single vendor.

    The Challenge

    A live-video companion has to hold up on three fronts at once. First, real-time avatar sessions are fragile: the vendor stream can drop, a device can lose the camera, and the experience has to degrade to something usable rather than a spinner. Second, a companion that remembers you is only trustworthy if the user controls exactly what it remembers — vague 'we use your data to improve' language does not cut it for something this personal. Third, the client could not afford to be married to whichever avatar or model vendor was best on launch day; vendors in this space change pricing, quality, and availability constantly, and a rewrite to switch was off the table. On top of all that, the platform is multi-tenant, so one tenant's data must never be reachable from another's, ever.

    The Solution

    The build answers each of those directly. Live sessions run against the avatar-video vendor through an adapter, with a text fallback path that takes over the same conversation when video is unavailable or unwanted, so a user is never stuck. Onboarding is a save-and-resume personality assessment that produces a structured profile, and nothing from that profile becomes durable memory until the user consents to it explicitly. Approved memory is chunked, embedded, and retrieved over a vector store so the companion's replies are grounded in what the person actually shared, and un-approving a memory deletes its chunks rather than merely hiding them. Underneath, the language models and the avatar vendor both sit behind internal interfaces, per-tenant isolation is enforced at the database layer on every table, and every boundary between the client, the server, and the vendors is validated against a schema.

    Technical Deep Dive

    1

    The provider-agnostic core is the spine of the system. Rather than calling a language-model SDK or an avatar-video SDK directly from feature code, every feature talks to an internal interface — a companion 'brain' port and an avatar 'session' port — and each concrete vendor is one adapter behind that port. Selecting a vendor is a configuration value read at startup, not a code path sprinkled through the app, so swapping the model provider or the avatar vendor is a config change plus a new adapter rather than a rewrite of the product. This also made the text fallback natural to build: it is simply another implementation of the same conversation contract the video path uses.

    2

    Consent-gated memory is modelled as an explicit lifecycle rather than an implicit side effect of chatting. Content the user shares stays ephemeral until they approve it for memory; on approval it is chunked, embedded, and written to the vector store as durable profile chunks tied to that user. On un-approval those chunks are deleted, not flagged — the retrieval layer can only ever see what is currently approved, so 'forget this' genuinely removes it from what the companion can recall. Retrieval itself is RAG over the approved chunks: the relevant pieces of the profile are pulled by vector similarity and handed to the companion as grounding for the current turn, which keeps responses tied to what the person actually told it.

    3

    The personality onboarding is a save-and-resume assessment, because a first-time user should be able to leave halfway and come back without losing progress. Answers are persisted as they go and assembled into a structured profile that briefs the companion at session start. Keeping the profile structured — rather than a free-text blob — is what lets the rest of the system reason about it: it feeds the initial session briefing, and the portions the user later approves become the seed of durable memory.

    4

    The real-time session lifecycle is treated as a state machine with a fallback built in from the start, not patched on. A session negotiates a live avatar stream through the vendor adapter; if that stream cannot be established or drops mid-conversation, the same conversation continues over the text fallback path against the identical brain contract, so context is not lost when the medium changes. Because both paths speak the same internal interface, the companion's behaviour and memory access are identical regardless of whether the user is on video or text.

    5

    Per-tenant data isolation is enforced at the database layer, on every table, rather than trusted to application code remembering to filter. Every row is scoped to its tenant and access is constrained at the data layer, so a query from one tenant structurally cannot return another tenant's rows — the isolation holds even if a feature forgets to add a WHERE clause. For a product built around private, personal memory across multiple tenants, that guarantee living in the database rather than in convention was a deliberate requirement.

    6

    Every boundary in the system is schema-validated in TypeScript: the shapes crossing between the client, the server routes, the database, and the vendor adapters are parsed and validated rather than assumed, so malformed or unexpected payloads fail loudly at the edge instead of corrupting state deep inside. The whole thing ships with CI running on every change and a documented go-live handover — architecture, configuration, and operational notes — so the client owns and can run the system outright rather than depending on the person who built it.

    Key Features

    Live avatar sessions, not a chat box

    You meet the companion over real-time avatar video and talk to it like a call. The avatar vendor sits behind an adapter, so the session experience is decoupled from whichever vendor powers it.

    Graceful text fallback

    When live video is unavailable or the user prefers text, the same conversation continues over a text path against the identical companion contract, so context and memory carry across without a reset.

    Save-and-resume personality onboarding

    A personality assessment that persists progress as you go and can be resumed later, producing a structured profile the companion is briefed on at the start of every session.

    Consent-gated private memory

    The companion only ever remembers what the user explicitly approves. Un-approving a memory deletes its stored chunks, so 'forget this' actually removes it from what the companion can recall.

    Contextual recall with vector retrieval

    Approved memory is chunked, embedded, and retrieved with RAG, so replies are grounded in what the person actually shared rather than generic filler or hallucinated history.

    Provider-agnostic core

    The language models and the avatar-video vendor both live behind internal interfaces. Switching either is a configuration change and a new adapter, not a rewrite of the product.

    Results & Impact

    • Delivered to production as client work: a live-video AI companion with real-time avatar sessions, a text fallback, personality onboarding, and consent-gated memory all working end to end.
    • The provider-agnostic core proved out in practice — the language models and the avatar vendor can each be swapped through configuration and an adapter rather than a product rewrite.
    • Privacy is enforced by construction: memory is opt-in per item, un-approving deletes the stored chunks, and per-tenant isolation lives at the database layer on every table.
    • The client owns the system outright, with schema-validated boundaries, CI on every change, and a documented go-live handover instead of tribal knowledge.

    Lessons Learned

    "Design the fallback before the happy path. Building the text path as a first-class implementation of the same conversation contract — rather than an afterthought — is what kept live-video fragility from becoming a dead end for the user."

    "Consent is an architecture decision, not a settings screen. Modelling memory as an explicit approve/un-approve lifecycle, where un-approving deletes chunks, made the privacy story something the user can actually reason about instead of a promise in a policy."

    "Put vendor boundaries behind interfaces from day one. Because the models and the avatar vendor were adapters from the start, the client is not locked to launch-day vendor choices, and the same seam made the text fallback almost free."

    Conclusion

    Helel.ai is the kind of build I point to when the question is whether an 'AI companion' can be more than a wrapper around a chat endpoint. The value is in the parts around the model: a real-time session with a fallback that keeps the experience alive, memory the user genuinely controls, per-tenant isolation enforced where it counts, and a provider-agnostic core that leaves the client free to change vendors without changing the product. It shipped to production, it is documented, and the client owns it.

    Frequently asked questions

    What is Helel.ai?
    Helel.ai is a real-time AI video companion. Instead of typing to a chat box, you meet the companion in a live avatar video session. A personality assessment builds your profile, the companion remembers only what you approve, and it can fall back to text when video isn't available.
    Is it live and in production?
    Yes. Helel.ai was delivered as production client work in 2026, with real-time avatar sessions, personality onboarding, consent-gated memory, and a text fallback all working end to end. It shipped with CI and a documented go-live handover, and the client owns the system outright.
    How does memory and privacy work?
    Memory is consent-gated. Nothing you share becomes durable memory until you explicitly approve it. Approved content is chunked and stored so the companion can recall it with vector retrieval, and if you un-approve a memory its stored chunks are deleted — so 'forget this' genuinely removes it rather than hiding it.
    Can it switch AI or avatar providers?
    Yes. The core is provider-agnostic: the language models and the avatar-video vendor each sit behind internal interfaces, and the active vendor is a configuration value. Switching to a different model or avatar vendor is a config change plus an adapter, not a rewrite of the product.
    What's the architecture?
    Next.js (App Router), React 19, and TypeScript on the front, PostgreSQL with a vector store for retrieval, and the real-time avatar vendor behind an adapter, deployed serverless on Vercel. Per-tenant isolation is enforced at the database layer on every table, and every boundary between client, server, and vendors is schema-validated.

    Interested in a Similar Project?

    Let's discuss how I can help bring your ideas to life.

    Get in Touch

    Let's Create a Revolution