Intended user flows

You want a conversational avatar on your website. Normally that leaves two roads, and both cost something. The first is to rent a chatbot widget: you pay a per-seat fee for as long as it runs, the conversation goes through a vendor's backend (so their outage is your outage), and the face is whatever they ship. The second is to build it yourself: a face that stays one recognisable person across every expression and animation frame, a state machine with guards for intent and sentiment, retrieval over your own content, the layer that swaps expressions mid-sentence, and a test harness to trust any of it — then the upkeep of all that, indefinitely.

I built ASMI because I wanted neither. The flows in this product are arranged around three people, and around getting each of them to the same place: owning a working avatar that doesn't depend on me.

Three people I built the flows for

The operator is one person adding an avatar to their own site. They don't want to become an AI engineer; they want to design how it looks, give it what it knows, watch it behave, and publish it. The whole editor-to-deploy path is shaped so that is the entire job.

The agency builds for clients, again and again. The expectation there isn't "do it once" — it's "do it once well, then repeat without starting over." Cloning an avatar from the gallery, re-skinning the identity and brand voice, and re-deploying per client is a first-class path, not a workaround.

The developer is the one wiring the avatar into a codebase. They expect their own stack, their own LLM key, no black box they can't inspect, and a way to prove the integration is correct. That's why implementation runs through an MCP server and the open runtime packages, and why verify_deployment exists.

The journey, and the expectation behind each step

Every stage of the build → test → ship path answers an expectation a reasonable person brings to "put a chatbot on my site":

• "I shouldn't have to art-direct nine expression frames and hope they match." So identity is locked once and every frame is generated against it and checked, rather than left to chance.
• "I shouldn't publish something I've never watched behave." So the Narrator replays scripted journeys and the Simulator lets you chat against the real state machine before anyone else can.
• "I shouldn't have to hand-write the integration." So you deploy, and a coding agent reads the blueprint over MCP and writes the backend route and the widget into your project.
• "I shouldn't have to take it on faith that it's wired right." So verify_deployment runs your recorded happy-path against the live integration and hands back a diff.
• "I shouldn't end up renting my own chatbot." So the finished avatar runs on your stack and your LLM, and keeps answering even if broen.tech goes offline.

None of these are features I added and then looked for a reason to justify. They're the shape the expectations forced.

Where the time and money actually go

This is the part worth being concrete about, because "saves time and money" is easy to say and usually empty.

The time you save is the engineering you don't do. Keeping a generated face recognisably the same person across expressions, wardrobes, and animation frames is hard, and here it's solved by construction. I've already built the state machine, the intent-and-sentiment classification, the retrieval over your own knowledge, the mid-sentence expression swaps, and the tooling to test them — you configure those in an editor instead of writing them. And the integration itself is written by the coding agent you already use, not by you.

The money you save is the recurring kind. There's no per-seat subscription to me that grows as your team does, and no markup added to every visitor message. At runtime the avatar calls your own LLM provider directly, so a conversation costs you exactly what that provider charges — the same cost you'd carry on any path, with nothing stacked on top. ASMI credits pay for the generation you do while building and testing in the editor; once the avatar is deployed, the talking is between your site and your LLM.

There is a trade-off, and I'll state it plainly. This asks more of you up front than pasting a script tag: you implement once per site through a coding agent, and you bring and pay for your own LLM at runtime. A legacy script-tag widget does exist for quick prototypes, but it points back at my endpoint and carries every lock-in problem above — fine for a demo, wrong for production. The deal ASMI offers is deliberate: a bit more setup once, in exchange for owning the result.

The thread through all of it

The flows aren't a funnel into a subscription you can't leave. They're arranged so that at the end you're holding something that works on its own — your avatar, on your stack, answering your visitors on your LLM, with me out of the loop. That's the experience I was designing for: not the moment you sign up, but the moment you no longer need me.