From prototype to a visitor-facing assistant
Launch needs more than a demo.
What you will learn
- Explain: check access before use
- Apply the idea in an example: From prototype to a visitor-facing assistant
- Recognize limitations and verify the exercise outcome
Launch needs more than a demo. Finish with a widget, budget, access limits and a maintenance process.
These steps refer to features identified in the application code. This material has not been validated on a live instance; check the documentation and the options in your version.
How it works, step by step
Check access before use
Permissions must be enforced by servers and the data layer. Do not let the model decide whether a user may see a document. Filter sources before they enter context, not after generating the answer. Use minimal-access credentials, keep them out of prompts, screenshots and browser code, and rotate exposed keys. A widget domain allowlist does not replace API authentication. Authentication identifies you; authorization determines the operations and data you can use. Test denied access too.
Errors need explicit paths
A timeout differs from a permission error. Retry only transient errors, with bounded attempts and increasing delays. An operation with side effects may execute before its response is lost; retrying without an idempotency key can duplicate the effect. Streaming shows progress but does not guarantee completion. Checkpoints may allow failed stages to resume within runtime limits. Store the run identifier, stage, duration and error while removing secrets from logs. Measure slow paths as well as averages.
Cost belongs to the whole path
Count model calls, input and output tokens, embeddings, reranking, vision and tools. Reasoning can consume billable tokens without an equally long visible response. Indexing costs and conversation costs differ. Use current prices rather than a permanent number from a course. A simple estimate is tokens/1,000,000 × price plus additional operations; application credits may have their own conversion. Compare cost per successful task, not just per call. Parallel execution can reduce latency while increasing total consumption. A budget needs a verified stopping condition.
The visual map
Follow the solid arrows for the main flow. Dashed blue arrows supply data or context; dashed pink arrows show feedback or returning results. Colors and shapes distinguish models, stores, decisions and outputs. On smaller screens, scroll horizontally to follow the entire diagram.
A complete example
The widget states its role, runs on permitted domains and uses a tested target. Check sources, errors, mobile and costs, then define who reviews policies.
Try it yourself
- Complete access, quality, domain, mobile, budget and maintenance checks before publishing.
- Record the input, source and expected outcome before running the experiment. Use only the fictional data in the example.
- Follow the diagram stages. At every step record what information is received and produced; do not confuse intermediate output with the final outcome.
- Repeat after removing necessary information or making the input ambiguous. Check whether the system clarifies, stops or invents an answer.
- Compare with the explained solution. Keep the configuration, date, result and an explanation for differences. Change one thing and retest.
An explained solution
Deliver integration, allowed/denied tests, launch criteria and a review date. A successful exercise lets you show the connection between input, stages and outcome. When information is missing, a cautious answer is more useful than invented details. Compare more than style: check conditions, sources and operations too.
When it helps and what can go wrong
Do not promise unconfirmed scheduling or approval features to visitors. Choose this approach when it improves a measured need. Keep a simple baseline and compare outcomes using identical inputs. One successful example does not establish reliability in every situation.
Check your understanding
Why is removing a private source after answering too late?
The data has already entered model context and can be disclosed.
Does a timeout prove the operation did not execute?
No. Check state before retrying an action with side effects.
What outcome should this exercise produce?
Deliver integration, allowed/denied tests, launch criteria and a review date.
Words to remember
- Autorizare / Authorization: Checking the right to access an operation or resource.
- Idempotency: Controlled repetition without duplicating an effect.
- Latență / Latency: Time until a useful result.
Sources and your next step
To prepare: A03 — An agent connected to knowledge · R03 — Naive RAG: your baseline · D04 — Good questions for testing RAG · U02 — Playground as a laboratory · U05 — An AI widget on your website · E05 — Tokens, credits, budgets and total cost · S01 — Prompt injection and untrusted data · S02 — Permissions and protecting data