Build avatars once. Run them anywhere.

ASMI (Avatar State Machine Interface) is a design-time builder for conversational avatars. You shape the avatar at broen.tech/apps/asmi — face, personality, behaviour, knowledge — and a coding agent (Claude Code, Cursor, Lovable, v0, base44, Replit, Cline, ChatGPT Dev Mode) implements it directly in your site. Once implemented, the avatar runs on your stack with your LLM keys. There is no ASMI runtime to depend on.

Version 1.1 — June 2026. This page is the umbrella for the 1.1 feature docs. Each section below links to a focused page; this overview is the map. For the full technical specification, see ../../asmi-product.md.

What ASMI is

Every "AI avatar" or "chatbot widget" I evaluated made the same bargain: either it locked me into a vendor runtime — proprietary SDK, a per-seat monthly fee, your site goes dark when their backend does — or it left me to hand-roll the entire face, state-machine, and expression-swap layer from scratch. ASMI splits the problem so you get neither.

The design of the avatar happens in a visual editor on broen.tech: what it looks like, what it knows, how it behaves, what it sounds like. The implementation happens in your own codebase, written by whatever coding agent you already use. What you publish is a blueprint, not a service.

Concretely: you build the avatar, click Deploy, and copy a one-paragraph briefing into your coding agent. The agent connects to ASMI's MCP server, which hands it the avatar definition, a step-by-step embedding guide, and instructions to install two open npm packages — both public, both MIT-licensed:

• @avatar-state-machine-interface/runtime — the state-machine evaluator that runs each conversation turn: classification, guards, transitions, prompt assembly, expression resolution. Pure logic, zero runtime dependencies, framework-agnostic.
• @avatar-state-machine-interface/react — the React component that renders the animated face and chat shell (<AsmiAvatar>, <AsmiFace>, and the useAsmiSession hook). It depends on the runtime; on a non-React stack you install the runtime alone and render the face yourself.

The agent installs those two and writes the glue around them — a backend chat route and the frontend mount — straight into your repo. From that point your site owns the avatar: your LLM provider, your hosting, your data. Both packages are open on npm, so there is no closed SDK in your critical path — your avatar keeps answering even if broen.tech goes offline tomorrow.

What you can do with it

• Build a face that stays one person. Lock identity once — gender, hair, eyes, skin, framing — and the avatar looks like the same individual across every wardrobe, expression, and animation frame.
• Give it a voice. Seven brand-voice sliders, a persona, language and multilingual settings, and free-form rules compile into the system prompt on every turn.
• Wire how it behaves. An XState-compatible state machine with structured, data-only guards — it survives JSON round-trips and a coding agent regenerating its scaffold.
• Teach it your business. A per-avatar knowledge base (RAG) you fill by hand, by URL, by file, or by crawling your own site.
• Test it before anyone sees it. Record a canonical happy-path and replay it; chat against the live state machine in a simulator and watch every transition and classification as it happens.
• Ship it anywhere fetch reaches. React, Next.js, Vue, vanilla — the coding agent does the integration through the MCP server, then verifies it against your recorded happy-path.

What's new in 1.1

1.1 is mostly about one promise: the face you design is the face that ships — every frame, every look.

• Consistency by construction. Every generated face and animation frame is now checked against the identity you locked — right hair, right wardrobe, right features — and regenerated automatically when it drifts. The old failure mode (a braid that quietly turned into loose hair on three frames out of nine) is gone: generation is QA-gated with targeted auto-retry, not hope.
• Baseline-replacement cascade. Change the baseline identity once and every dependent expression, wardrobe set, and animation frame regenerates from the corrected reference — with a before→after grid and a QA post-pass so you can see exactly what moved.
• Looks: multiple wardrobes, scheduled. Reusable wardrobe templates plus full alternative looks that swap at runtime. Event looks auto-activate against holidays, fixed dates, or custom observances; activation splits into Static and Dynamic with a calendar preview, and set selection into Default / Forced / Dynamic.
• Animation on Nano Banana 2. Blink and motion frames now generate a true base↔full midpoint (the "Mid" blend frame) and can combine several effects in one frame. I dropped the effects the model couldn't render reliably instead of faking them.
• A knowledge base that fills itself. Crawl a company site straight from the database dialog; crawled pages land as draft knowledge items you accept one by one, retrieval is page-aware, and you can un-accept (archive) an item and restore it later without losing it.
• An MCP server that tells the coding agent the truth. Deployed avatars are publicly readable, get_avatar defaults to fetching the live definition instead of a stale inline snapshot, responses survive aggressive client truncation, and the embedding guide now spells out text-contrast rules so agents stop shipping unreadable widgets.
• Cost math that adds up. Fixed a double-count of image-generation output in the Vertex cost path, so the credit ledger and the admin cost dashboard agree.
• Six demo avatars. A gallery-ready set across six industries (listed below), each versioned 1.1.0 with its own demo page.

The 1.1 capability map

The detail for each topic lives on its own page. This is the index.

Build

1. Make a new avatar — The wizard: start blank or clone from the gallery, add company context (with an optional website crawl), set brand voice, switch on awareness — then into the editor.
2. Baseline identity — The stable traits the face keeps everywhere: gender, hair, eyes, skin, framing, and the identity-reference image. Lock it once; everything else is built from it.
3. Baseline expressions — The six-to-nine transparent-PNG faces (neutral, smiling, attentive, thinking, concerned…) and their animation frames, generated to match the baseline and QA-checked frame by frame.
4. Wardrobe — Reusable styling presets — hair, clothing, accessories — that any appearance set can consume. The generated styled-neutral preview becomes the consistency anchor every styled frame is built from.
5. Styled expressions — Full appearance sets: a wardrobe applied across the same expression grid, with Default / Dynamic / Forced activation, calendar scheduling, and a year-at-a-glance preview of which look is active when.

Teach

1. The Avatar Database — The per-avatar knowledge store (RAG): accept crawled pages or write items by hand, normalize them to Markdown, and move each draft → published → archived. A deployed avatar retrieves the published items per turn, page-aware.

Test

1. Narrative Player — Play scripted visitor journeys through the real state machine and watch it run. The canonical happy-path you record becomes the ground truth verify_deployment checks every integration against.
2. Simulator — Free-form chat against the live state machine in the real production widget, with the active state lit on the canvas and live intent / sentiment / confidence readouts.

Ship

1. Implementing with Lovable — Connect ASMI's MCP server as a custom connector (bearer token), then ask the coding agent to implement the avatar. Lovable caps response size, so the embedding guide auto-recovers — or paste the inline full-spec briefing.
2. Implementing with base44 — The same flow via base44's account-level MCP connections (x-api-key header). The deployed app calls base44's built-in InvokeLLM instead of a user-supplied key — base44's intended pattern, not a constraint.
3. Implementing with v0 — The same flow via v0's custom-MCP connector (explicit Headers auth). The generated app runs on your own stack and LLM key, like the Lovable path.

Under the hood

1. Use of generative AI — Where Gemini does the work: face and animation generation (Nano Banana / Nano Banana 2 / Pro), intent-and-sentiment classification, website-crawl classification, knowledge normalization, and the consistency-QA pass — all inside the editor, on credits. A deployed avatar's live chat runs on the host's own LLM.
2. Intended user flows — The journeys 1.1 is built around: the operator who builds and deploys, the agency that builds once per client, the developer who drives the MCP + verify_deployment loop.
3. Avatar consistency mechanisms — How the face stays one person: consistency by construction (every frame seeded from one approved reference), QA-gated auto-retry up the model ladder, and the baseline-replacement cascade.

Try it — the 1.1 demo avatars

Six avatars across six industries, all in the gallery and clone-ready. They double as the showroom: a coding agent built every embed there by following the steps above — none are hand-coded.

Start at broen.tech/apps/asmi, or clone one of these from the gallery and make it your own.

One trade-off worth stating

ASMI is honest about what it asks of you. There is no single script tag that drops a production avatar onto your site — you implement once per host, through a coding agent, because that is what keeps the runtime (and your data, and your LLM bill) on your side rather than mine. A legacy script-tag widget exists for quick prototypes; it points back at ASMI's endpoint and carries every lock-in problem the main path avoids. And ASMI's credits cover generation inside the editor only — the host site brings its own LLM provider and pays that cost directly. That is the deal: a little more setup once, no vendor in your critical path afterwards.

Reference

• Full technical specification: ../../asmi-product.md — architecture, every MCP tool and endpoint, the runtime npm packages, pricing.
• Editor / try it: broen.tech/apps/asmi
• Pricing: broen.tech/apps/asmi/pricing
• MCP server: https://broen.tech/api/asmi/mcp
• npm: @avatar-state-machine-interface/runtime · @avatar-state-machine-interface/react

— Stian Broen · Broentech Sentinel AS · Horten, Norway · stian@broentech.no