Your prototype answers a question correctly once. Now a second user opens it on a phone, the provider takes too long, and the first user's document appears in the response. The model's successful demonstration did not test the responsibilities of the application around it.
Before you begin: Complete the beginner API, workflow, and tool-design lessons.
Choose one complete user journey
Build a small notice helper: a user supplies a notice, asks a question, sees an answer with evidence, and can return to their own saved work. Start with text notices and a narrow question flow. Adding voice, payments, and autonomous actions would create more boundaries before this one is understood.
Write down what each part owns. The interface collects input and shows state. The server authenticates the user, validates the request, selects allowed data, and calls the provider. Storage preserves records with ownership. The response layer validates and presents the result. Logging supports diagnosis without becoming a copy of every private document.
Keep the credential and identity on the right side
The browser is not a place for a secret provider API key. Send the user's request to your server, and let that server make the provider call. The server should identify the user from the authenticated session rather than trusting a user ID typed into a request body.
When reading a saved notice, check ownership before retrieval and before returning the record. If two people have similar document titles, titles are not an access-control mechanism. Use stable record IDs and authorization tied to the actual session.
Validate before spending a model call
Reject missing questions, oversized inputs, malformed identifiers, and unsupported operations early. Provide a useful error the person can fix. These checks are ordinary application logic; a model does not need to decide whether a required field is empty.
Construct the model input from allowed source text and explicit instructions. Keep source material identifiable as data. After receiving output, check the expected structure and inspect the evidence relationship appropriate to the task. A success status from the provider is not proof of a correct answer.
Design honest states
Before a request starts, show the question and source clearly. While it runs, show that work is pending and prevent accidental duplicate submission where needed. If it fails, preserve the user's input and explain whether retrying is appropriate. An empty answer should not look like a completed response.
If output streams into the page, treat it as provisional until the response is complete. A partial sentence is not a validated final answer. If the stream disconnects, mark the result incomplete instead of silently treating the visible text as finished.
For saved work, distinguish saving, saved, and failed states. A green check shown before storage confirms the write is not durable progress.
Test the journey, not only the model
Use a known-answer notice, an unanswered question, a conflicting notice, an empty input, and a provider timeout. For saved records, test reload, a second device if supported, sign-out, and a second account. The second account should not see the first account's data even if it guesses a record ID.
On a phone, the question, evidence, and answer should remain readable without page-wide horizontal scrolling. Controls need labels and keyboard access. Long code or tables may scroll within their own region, but they should not push the whole page off screen.
Define the first release honestly
You can release a narrowly scoped application with clear limitations. Do not claim it is a production-ready autonomous assistant simply because a model call succeeds. Record what was tested, what is external or untested, and which failures remain.
Keep a small evaluation set and a way to reproduce bugs. When a user reports a wrong answer, you need to distinguish source selection, model behavior, validation, and UI state. That distinction makes improvement more efficient than repeatedly changing the prompt.
Locate a cross-user failure
A server retrieves a notice by ID and only later asks the model not to reveal other users' data. Where must the fix happen?
Move the check before retrieval
The server must authorize access using the current session and record ownership before including the notice in the request or returning it. Prompt wording cannot undo an unauthorized data read. Add a two-user regression case that attempts to access the other user's record.
You have now followed the application from task to evidence to action. The intermediate track returns to the model's internal machinery so you can understand why different architectures and retrieval methods behave differently.
Further reading
OWASP's authorization guidance explains access-control principles. The W3C forms tutorial covers accessible input and feedback design.