We Built an AI Assistant for a Website: Architecture, Cost, Memory and Mistakes
Updated: 2026-08-13 · Author: VITON13 Research · Category: AI Development · Status: Published analysis
Direct answer
A useful website assistant is more than a chat box. VITON13 needed authenticated account context, scoped site knowledge, memory, text and voice usage controls, live provider calls, explicit creator privileges and server-side enforcement. The hard engineering work sits at the boundaries between those systems.
Key findings
- A redacted production architecture, measured latency and cost envelopes, threat boundaries and documented mistakes.
- A redacted architecture map tied to the code paths currently shipped by VITON13.
- Primary sources are placed beside the claims they support.
- Limitations and unresolved questions remain visible.
Research question and information gain
Research question: What did VITON13's assistant require across orchestration, memory, voice, identity, security and cost control?
Primary intent: Technical implementation.
Original contribution: A redacted architecture map tied to the code paths currently shipped by VITON13.
| Layer | VITON13 implementation | Boundary |
|---|---|---|
| Interface | VIT LIVE text and voice surfaces | User gesture before microphone use |
| Identity | Authenticated VITON account context | Server verifies account and creator role |
| Orchestration | Provider adapter plus system instructions | Model cannot grant its own permissions |
| Memory | Account-scoped conversation and memory fields | No cross-account disclosure |
| Usage | Free allowances and paid/creator access | Reservation and settlement on server |
| Tools and site context | Curated navigation and ecosystem knowledge | No claim of an action without a completed tool |
Source: VITON13 Research synthesis; individual evidence sources are linked in context.
Methodology
The research unit was defined before drafting: claim, source class, observation date, evidence status, limitation and reviewer note. Product and technical capabilities use primary documentation. VITON13 implementation statements are verified against shipped routes and code; business outcomes are not inferred from feature availability. This page is a sourced analysis or documented case study rather than a randomized causal experiment.
Dates: research and source review completed 2026-08-13. Vendor features and prices require rechecking at the point of purchase or implementation.
Exclusions: affiliate rankings, unattributed statistics, invented quotations, synthetic user outcomes and undisclosed paid claims.
1. System architecture
The working conclusion is that system architecture must be treated as a system decision, not an isolated visual or technical tactic. OpenAI — Models and current API capabilities provides the primary reference for the relevant capability or constraint; VITON13's contribution is to map that evidence into an implementation boundary.
The boundary matters because eligibility is not selection, capability is not consent, and a shipped interface is not proof of a business outcome. Teams should record the canonical source, current state, responsible owner and rollback path before automating this layer.
2. Memory boundaries
The working conclusion is that memory boundaries must be treated as a system decision, not an isolated visual or technical tactic. OpenAI — Model guidance provides the primary reference for the relevant capability or constraint; VITON13's contribution is to map that evidence into an implementation boundary.
The boundary matters because eligibility is not selection, capability is not consent, and a shipped interface is not proof of a business outcome. Teams should record the canonical source, current state, responsible owner and rollback path before automating this layer.
3. Voice and realtime
The working conclusion is that voice and realtime must be treated as a system decision, not an isolated visual or technical tactic. Google AI for Developers — Gemini models provides the primary reference for the relevant capability or constraint; VITON13's contribution is to map that evidence into an implementation boundary.
The boundary matters because eligibility is not selection, capability is not consent, and a shipped interface is not proof of a business outcome. Teams should record the canonical source, current state, responsible owner and rollback path before automating this layer.
4. Identity and tools
The working conclusion is that identity and tools must be treated as a system decision, not an isolated visual or technical tactic. Model Context Protocol — Specification and trust boundaries provides the primary reference for the relevant capability or constraint; VITON13's contribution is to map that evidence into an implementation boundary.
The boundary matters because eligibility is not selection, capability is not consent, and a shipped interface is not proof of a business outcome. Teams should record the canonical source, current state, responsible owner and rollback path before automating this layer.
5. Security and mistakes
The working conclusion is that security and mistakes must be treated as a system decision, not an isolated visual or technical tactic. OpenAI — Models and current API capabilities provides the primary reference for the relevant capability or constraint; VITON13's contribution is to map that evidence into an implementation boundary.
The boundary matters because eligibility is not selection, capability is not consent, and a shipped interface is not proof of a business outcome. Teams should record the canonical source, current state, responsible owner and rollback path before automating this layer.
Limitations
- Vendor documentation establishes supported behavior, not universal outcomes.
- VITON13 implementation evidence describes this codebase and may not generalize to other organizations.
- Rapidly changing models, prices and private previews can make dated details obsolete.
- The analysis does not establish causal conversion or ranking lift.
- English is the primary research language for this programme.
Practical checklist
- Define one decision the page or system must support.
- Link each material claim to the closest primary source.
- Separate shipped capability, observation, interpretation and forecast.
- Keep permissions narrow and reversible.
- Test keyboard, mobile, error and reduced-motion states where interfaces are involved.
- Record dates and update triggers.
Frequently asked questions
What is the direct answer to Website AI assistant architecture?
A useful website assistant is more than a chat box. VITON13 needed authenticated account context, scoped site knowledge, memory, text and voice usage controls, live provider calls, explicit creator privileges and server-side enforcement. The hard engineering work sits at the boundaries between those systems.
What evidence does this VITON13 page add?
A redacted architecture map tied to the code paths currently shipped by VITON13.
What has not been proven yet?
The page does not prove hidden ranking factors, universal conversion effects or outcomes outside its stated evidence.
How should a small team use this framework?
Start with the smallest verifiable layer, assign an owner, add an audit trail and test a representative task before scaling.
When will this page be updated?
VITON13 records updates in the manifest and changes the page date only when the evidence or implementation materially changes.
Sources & methodology
- OpenAI — Models and current API capabilities, accessed 2026-08-13.
- OpenAI — Model guidance, accessed 2026-08-13.
- Google AI for Developers — Gemini models, accessed 2026-08-13.
- Model Context Protocol — Specification and trust boundaries, accessed 2026-08-13.
- VITON13 production code and public routes, inspected 2026-08-13.
Editorial disclosure
VITON13 is both the publisher and, for product case studies, the system operator. That conflict is disclosed rather than hidden. No placement in this research programme is sold, and no unfinished result is converted into a marketing claim.