Evaluating the complete avatar product—and knowing when to stop

Avashi ended as experimental client research. Budget constraints closed the engagement, and the rendered experience had not met the intended mobile requirement. The useful conclusion is a precise account of what existed, what remained uncertain and what evidence would justify restarting.

A research programme can produce reusable engineering without producing a viable product. The mistake would be to turn every prototype into a production claim or to treat closure as evidence that the underlying technology is impossible.

Evaluate at four levels

A pass at one level does not waive the others. A valid GLB file can fail rendering. A fast response can contain the wrong memory. A correct conversation can still be unusable if the phone struggles to maintain the visual experience.

Build one repeatable acceptance session

The reference session begins with a cold asset load, then a text greeting and a spoken exchange. The user interrupts, changes a preference, leaves the session and returns through another channel. The test ends with background/resume and resource cleanup.

This sequence exercises the important joins: renderer readiness, text/audio identity, cue cancellation, memory correction, retrieval scope and session teardown. Keep the input script and asset fixed when comparing candidates.

The downloadable acceptance matrix contains authored test specifications. It is not a historical test-results report. Its purpose is to make “ready for another pilot” a reviewable decision.

Use hard gates before preference scores

Some failures should block the candidate regardless of how attractive it looks: cross-user memory retrieval, unsupported action completion, crashes, corrupt output or a persistent inability to stop speech. Other dimensions can be scored comparatively, such as facial naturalness, voice preference and visual fidelity.

Blind review can help distinguish an actual improvement from enthusiasm for a new model. Show the same scripted interaction with two configurations and record the reviewer’s reasons. Keep failure categories separate rather than hiding them inside a single quality average.

For mobile, report device model, browser version, thermal conditions, power state and session duration. A brief desktop capture does not establish sustained phone performance.

Measure the work that remains

The project crossed generation, rigging, animation, rendering, conversation, memory and operating infrastructure. Each had its own remaining work. A credible continuation estimate therefore needs work packages and acceptance gates rather than one optimistic “productionize” task.

The highest-risk dependency should be resolved first. If the chosen character cannot meet the phone budget even with a reduced profile, adding more personas or prompt features does not repair the primary product constraint.

For a restart, I would fund a narrow feasibility slice: one character family, one language pair, one bounded conversational workflow and a small device matrix. Broader generation and content libraries would follow only after that slice passed.

Calculate cost per accepted outcome

A reference economic model can separate one-time authoring and integration from variable interaction cost:

accepted-character cost = generation + cleanup + rigging + review
session cost = speech + model + memory + infrastructure + support allocation
usable-session cost = total session cost / fraction meeting acceptance

Suppose an illustrative batch costs $300 to create and review ten assets, but only six meet the animation and mobile criteria. The cost per accepted asset is $50, not $30. If a more controllable generation route costs slightly more per attempt but needs less cleanup, it can be the cheaper product route.

These numbers are a worked example. They are not the client’s budget or observed operating costs, which are not reconstructed here.

A bounded restart roadmap

First, freeze the contract. Choose the supported representation, required expressions, target phones and acceptance session. Record asset rights and the model versions actually used.

Second, prove the visual budget. Optimize one representative asset, run cold/warm and sustained sessions, and retain traces. Keep a lighter visual fallback available while testing.

Third, connect one conversational path. Use a stable event contract for text, speech and animation, then test interruption and reconnect before adding more providers.

Fourth, add scoped continuity. Make memory correction, deletion and isolation part of the same acceptance suite. Do not measure recall alone.

Finally, price the accepted result. Estimate engineering, authoring, hosting and review from the measured slice. Use that evidence to continue, reduce scope or close the next phase.

This is sequencing rather than a promised delivery timeline. The duration depends on the asset quality, device results and integration constraints found at each gate.

What the work contributed

The project produced concrete generation and runtime experiments, a layered animation approach, conversational integrations and memory boundaries that can inform future systems. My contribution connected those technical choices to the client’s broader product goal.

The closure makes the portfolio account stronger when it is specific: we investigated multiple routes, built substantial prototypes, identified mobile and investment constraints, and stopped without claiming the unresolved work was complete. That is a useful engineering outcome in a field where a visually impressive demo can conceal most of the product risk.