A lightweight AI client seems simple: send a message, receive an answer, display the result. The difficulty is that a model response becomes part of an application with configuration, identity, session history and failure states. A demo that hardcodes a secret, assumes every response is valid or sends the complete conversation forever may work once and then become unsafe or expensive. A good first client keeps the path from user text to trusted result understandable.
A help-desk chat client can explain published laptop instructions but cannot perform an account reset or authorize replacement hardware. It must protect credentials, bound conversation history, validate responses and make service failures understandable. Microsoft AI-901 requires a lightweight Foundry SDK client. Foundry SDK basics establishes the application lifecycle, while the backend must enforce read-only permissions regardless of what the model proposes.
Decide what the client is allowed to answer
Suppose an IT support portal offers a text assistant for common laptop setup questions. The product owner supplies an approved article explaining how to connect to the corporate wireless network and another about requesting a replacement device. The assistant may summarize those instructions, ask which device the user owns and link to the relevant approved help article. It should not claim to reset an account or approve a hardware purchase, because no authorized tools for those actions are part of the application.
Write the product boundary before any API call. Specify supported topics, an expected response length, what constitutes an acceptable source and how the client should behave if the answer is missing. Generative AI and agents distinguish generating a plan from having the tools, state and permissions needed to complete that plan. Keep that boundary intact as the client gains features.
Choose and verify the deployed model
The client needs a real model deployment that accepts the intended text input. Review the model card, supported endpoint shape, deployment configuration and regional availability before coding against a guessed resource name. A project identifier is not a substitute for a model deployment; a familiar model family name may not equal the deployment alias your application must use. Record configuration by environment so development requests do not silently call a production model.
Confirm model behavior in the Foundry playground with the same representative setup questions the client will use. Test a straightforward help query, a question with missing context and a request outside the approved topic area. Use Deploying a model in Foundry to verify the project, selected deployment and endpoint before debugging the chat client. If the model already fails these basic cases in the playground, wrapping it in a polished web page will hide rather than fix the problem.
Put sensitive configuration behind the backend
A browser should not contain a broad secret that lets anyone impersonate the application. Use a supported identity and authentication flow for the deployment, with permissions constrained to what the service needs. Keep project endpoint and deployment identifiers in validated configuration, and protect credentials using the platform’s recommended mechanisms. Authentication and authorization are different: the backend should also know whether the current user may access the app’s particular knowledge or tools.
Test a missing configuration variable and a denied permission. A secure client should stop with an actionable error rather than switching to an unknown default resource. Do not log the raw access token or resource key to help debug a failed request. If an identity works under the developer’s account but not the application’s role, fix the role assignment deliberately instead of expanding the production identity to unrestricted contributor access.
Keep the first request small and inspectable
Build one request with durable system instructions and a user message. The system instruction might ask the model to explain only approved support topics and admit when the available knowledge does not answer the question. The user message contains the current request, not a secret internal policy. Avoid combining dozens of objectives into one opaque prompt. A clear request gives developers a chance to understand whether poor output came from the model, missing context or inappropriate instructions.
Handle the response as data. Confirm the service actually returned a successful result, extract the intended message content, and distinguish completion from refusal, filter intervention or an API error when that information is exposed. If the model produces a malformed structure, do not interpolate it into trusted HTML or pass it to a downstream action. When the interface uses Markdown rendering, ensure the chosen renderer sanitizes unsafe content. An AI response must cross ordinary application security boundaries like any untrusted external input.
Use conversation history deliberately
Users may ask a follow-up such as ‘What about on a Mac?’ The application needs enough recent context to know the previous question concerned wireless setup. That does not require resending every prior message indefinitely. Choose a bounded history strategy, separate trusted system instructions from previous user text and prune irrelevant exchanges when they no longer help. Long histories can increase latency, consume context and create privacy concerns without improving the answer.
Distinguish a conversational preference from an authoritative fact. If a user says ‘my device is compliant,’ the assistant should not treat that as confirmed security posture. The application may remember the stated preference for short steps, but it should consult trusted policy when the next action depends on access permissions. Clear ownership of state makes the client more predictable than an unlimited transcript masquerading as a database.
Build error states the user can understand
Test a rate-limit response, invalid deployment identifier, network timeout and an input the application cannot process. The user-facing result should explain that the answer was not obtained; it must not generate a fake response to hide the service error. A retry button may be appropriate for a read-only request, but bounded backoff and clear cancellation behavior prevent many clients from creating a traffic spike during a regional incident.
Think about error handling before adding streaming. If an answer is delivered token by token, a later failure can leave the user with a convincing but incomplete statement. Label partial output or wait to mark it final until the request completes. If the client is extended to use agent tools, distinguish text generation from external action success. A timeout after submitting an account update is not permission to blindly repeat the update with a new identifier.
Protect the quality of the context you supply
A help-desk assistant that answers only from its own model memory may give outdated instructions for the organization’s latest login process. Before supplying private or changing knowledge, decide how the approved documents will be retrieved and what permissions apply. If the user is not entitled to see an article or record, the application must enforce that boundary before sending the text to the model. A prompt that says ‘do not disclose secrets’ cannot compensate for feeding the wrong person’s data into context.
For a small fundamentals project, use a limited set of permissioned, synthetic support instructions or a well-defined public source. Record which passage the model used for a response if the application needs evidence. Ask the model to express uncertainty when the source lacks the answer. The test becomes whether the app is grounded and appropriately constrained, not whether the model can confidently improvise a plausible IT procedure.
Test a conversation across its full path
A compact evaluation plan includes a normal answer, a follow-up, an unsupported request, an attempt to override system instructions, missing context and a simulated service failure. Inspect the portal result first, then the same scenario through the client. A mismatch might indicate serialization, message ordering, configuration or state handling rather than a change in model capability. Keep simple logs of status, latency, model deployment and test ID, while excluding private messages unless explicitly required and properly protected.
Use responsible AI scenario tests to check transparency about missing evidence, safe refusal, privacy behavior and accessible fallbacks. A client that always produces a pretty answer is not necessarily successful. If it invents a password-reset completion or exposes another user’s record, the user experience has failed regardless of its language quality.
Know when to move beyond a direct chat request
When a help-desk assistant starts calling multiple services, requiring approvals or executing stateful steps, the application is no longer only a chat client. Single-agent portal test results can reveal whether a workflow needs explicit tool schemas, bounded state, permission checks and reliable completion evidence. These are functional conditions, not reasons to add autonomy for its own sake. Keep the original read-only question-answer client until the new workload truly needs actions and the backends are authorized to perform them.
The AI-901 client is complete when another developer can identify the supported model deployment, authenticate safely, send a correctly structured request, handle and display responses without trusting model text as code, manage modest conversation context and demonstrate sensible behavior when the service fails. Those capabilities are foundational because they establish the boundary between a generative model and software that real people can rely on.