Building an AI support widget with a 3D avatar (not another chat bubble)
Hey IH, first post here, so a quick intro.
I'm a full-stack/AI engineer who's spent years building software for businesses and individuals. A few months ago I started Atina, an embeddable AI assistant for SaaS products, think Intercom or Drift, but instead of a text bubble in the corner, users talk to a responsive 3D humanlike avatar. Voice, text, and avatar mode, all embeddable with one script tag.
The idea came from noticing that even with the rise of Gen AI and agents, automated support systems and bots still feel cold, deliver a bad user experience, and aren't production-ready for the real world.
Atina exists to fix that gap. We're building an experience where users feel like they're talking to a real human — in avatar or text mode — while getting their issues solved. I'm not building just a support system, I'm building an AI employee for the full user experience, 24/7.
Where things stand:
Live product, subscription-based pricing, working SDK
Applied to YC to scale this faster, currently waiting to hear back.
Great at technical building, genuinely bad at marketing/distribution - which is why I'm here
I'm offering free 30-day access to the embeddable widget (normally a paid tier) to the first 20 SaaS founders who want to try it on their product. No strings - just want real feedback and, if you like it, permission to feature you as an early user.
If that's interesting, comment or DM me. Also happy to answer anything about the build — 3D avatar rendering, embedding architecture, whatever's useful.
Embedded AI assistants can become part of a customer’s core workflow quite quickly.
How are you planning to communicate model changes, widget updates, maintenance, or service incidents to teams using Atina AI? Are you considering release notes, email updates, or a public changelog and status page?
Thanks, I will say release notes and email updates. We have an advance emailing system which we uses for providing regular updates to our users/subscribers. We also have Atina Labs where we provide comprehensive and technical details of our model work, benchmark decisions, release notes, embedded assistant architecture, etc, and the infrastructure choices behind our reliable AI assistants.
Check out Atina Labs here
That sounds like a good split for planned communication.
Release notes and email updates cover most product changes, while Atina Labs gives technical users a deeper view into the model and infrastructure decisions.
The remaining case I’m curious about is real-time operational communication. If the widget or model service is temporarily unavailable, where would customers check for the current status and ongoing updates? Do you already have a public status or incident channel for that?
Not yet, but I will consider a better way to integrate that.
Meanwhile, to avoid service unavailability issues, we design model auto switcher into our micro service, in case a model is unavailable it switch to another, we tracks their performance records to choose the best stable one to handle request and penalize the failed/unavailable one to rest for some minutes.
We also have a support channel where we listen to users issue, either they self serve their self through other available options or open a ticket. We have in-house custom built miniLM (ICL-1) for other purposes like intent classification, they handle the user request properly.
That’s a thoughtful resilience layer. Automatic model switching should prevent many provider-specific failures from becoming visible outages, and tracking stability over time is a sensible way to choose the fallback.
I’d still treat resilience and incident communication as separate responsibilities, though. Failover may succeed while response quality or latency degrades, and there are also failures outside the model layer — routing, authentication, the embedded widget, or the support service itself.
If the fallback system can’t fully recover, or users begin seeing degraded responses, how would you proactively tell affected customers before they need to open a support ticket?
I guess that should be the next thing on my list. Based on your experience, how did you recommend me tackling this?
I’d start deliberately small rather than building a full incident-management system.
First, define the conditions that count as customer-visible degradation — for example:
all model providers unavailable
fallback latency above an acceptable threshold
response quality falling below your confidence threshold
authentication, routing, or widget delivery failures
Then create one incident record as the source of truth, with a very small first-update format:
affected capability
current severity
what is still working
one factual sentence
next update time
That same incident should feed an independently hosted status page and, where possible, a lightweight message inside the widget. For higher-impact incidents, email affected customers as well.
I would keep the first version manually approved. Your monitoring can prepare the incident draft when thresholds are crossed, but a person should confirm the audience and wording before it publishes. Once the process proves reliable, you can automate more of it.
The important part is that users should not need to open a support ticket just to discover that you already know about the problem.
This is a very awesome idea, thank you. I will surely consider it.