Quickstart: connect a first workload

Before you begin

Choose one task with a clear input and expected output. Identify its owner, the environment where you will experiment, and the data classification of the request. Confirm that your organization permits the intended data to be sent to the provider you plan to use.

Decide how you will identify a request, handle an error, and observe a result. Keep credentials in your platform’s secret manager or equivalent secure configuration store. Do not put secrets in browser code, source control, sample prompts, or logs.

Define the task contract

Write down the fields the task accepts, the output shape the application expects, and what should happen when the model cannot satisfy the request. Include input size limits and a timeout suitable for the user experience. If the output is structured, validate it before downstream use. Treat a parse error, refusal, timeout, and provider failure as distinct outcomes so the application can respond appropriately.

Keep product authorization in the application. Decide which user may run the task, which records can be included as context, and whether the output can trigger any state change. A model response should not grant itself permission to read or modify data.

Connect in a development environment

Use your approved client library or internal gateway to make a request from a server-side environment. Supply the task input, the selected route configuration, and a request identifier if your stack supports correlation. Start with a non-sensitive example. Capture the status, elapsed time, route identifier, and usage fields that are available and appropriate for your environment.

Add bounded timeout and retry behavior. Retry only failures that are safe to retry, and avoid repeating downstream side effects without an idempotency or reconciliation strategy. Return a clear error to the caller when a request cannot be completed. Do not silently turn a failed generation into an empty or misleading success response.

Validate before expanding

Run a small representative set of task examples and review the results for output quality, formatting, and failure behavior. Verify that logs contain the fields your operators need and omit data they do not need. Confirm that credentials are not exposed to the client or stored in application logs. Ask the application owner to review edge cases and define when a person should take over.

Before connecting real traffic, document the workload owner, route choice, data assumptions, alert contact, and rollback plan. Expand access gradually when the evaluation and operational review support it.