Understand a model response before acting

Your application already calls services: a database query, a payment request, an email API. A managed model request is another service call. The difference is that generated output needs its own checks; a successful HTTP response is not proof that the answer is correct or that a proposed action has happened.

A model is trained software that produces predictions or generated output from inputs. Inference means running it on an input. An endpoint is the service address and API route. A software development kit (SDK) is a library your code uses to make calls. A deployment binds a model to a serving configuration; the exact resource and naming rules depend on the provider. An agent adds a loop that can use model results, authorized tools and observations to work toward a task. An inference call is one part of that loop.

Draw this path and label who operates each box:

Application and its SDK → Service endpoint → Selected model Application checks ← Response content + completion state

The SDK runs with your application. The model computation in these examples runs in a provider service. Installing a package does not create cloud resources, grant access or download the hosted model's weights. A managed agent runtime can host the application's loop, but it remains a different responsibility from inference.

These are selected APIs, not interchangeable interfaces for every model sold by these vendors. In particular, the Azure example is not a universal Claude API. Do not infer processing residency from a nearby VM or the client's endpoint name.

For each provider, fill in this proposed deployment card using current official documentation. Never include a key, access token or real customer record.

• Platform, API and SDK/version:
• Owning project/account/subscription and resource:
• Endpoint address and target identifier:
• Actual model/version behind that target:
• Workload identity and required access:
• Processing location/routing and relevant data terms:
• Input constraints and output allowance:
• Timeout, bounded retry/continuation policy and cost owner:
• How the app validates evidence and proposed actions:
• What you observed, versus what you have only designed:

Explain why a portal demonstration by its creator is not an acceptance test for the application's own identity. Explain why a catalog listing is not an access grant or a capacity reservation.

Everything below is synthetic. These are selected fields, not full API responses. The imaginary task summarizes ticket T-104. No cloud account is needed and no tools or models are executed. The function case comes from a separate request that declared a custom client-side get_ticket function.

Google Cloud

{"candidates":[{"finishReason":"STOP","content":{"role":"model","parts":[{"text":"Ticket T-104 is waiting for a review."}]}}]}

{"candidates":[{"finishReason":"MAX_TOKENS","content":{"role":"model","parts":[{"text":"Ticket T-104 is waiting for"}]}}]}

{"candidates":[{"finishReason":"STOP","content":{"role":"model","parts":[{"functionCall":{"name":"get_ticket","args":{"ticket_id":"T-104"}}}]}}]}

AWS

{"stopReason":"end_turn","output":{"message":{"role":"assistant","content":[{"text":"Ticket T-104 is waiting for a review."}]}}}

{"stopReason":"max_tokens","output":{"message":{"role":"assistant","content":[{"text":"Ticket T-104 is waiting for"}]}}}

{"stopReason":"tool_use","output":{"message":{"role":"assistant","content":[{"toolUse":{"toolUseId":"synthetic-call-1","name":"get_ticket","input":{"ticket_id":"T-104"}}}]}}}

Azure OpenAI

{"status":"completed","output":[{"type":"message","role":"assistant","content":[{"type":"output_text","text":"Ticket T-104 is waiting for a review."}]}]}

{"status":"incomplete","incomplete_details":{"reason":"max_output_tokens"},"output":[{"type":"message","role":"assistant","content":[{"type":"output_text","text":"Ticket T-104 is waiting for"}]}]}

{"status":"completed","output":[{"type":"function_call","call_id":"synthetic-call-1","name":"get_ticket","arguments":"{\"ticket_id\":\"T-104\"}"}]}

For each response, record:

1. Which field says why generation finished?
2. Which field says what kind of content was returned?
3. Is the next step to validate text, hold incomplete work, or authorize a function?
4. What does this response fail to prove?

Then consider a fourth capture: HTTP 200 with body {}. Do not fill in missing fields from memory. State what you would withhold, which safe diagnostic you would retain, and what you would inspect next.

An adapter is a small piece of code that translates one interface into another. Think of three shipping companies sending different tracking messages. Your app still needs one clear decision about a delivery. Here the vendor field names differ, but your application needs to decide what to do with the result.

This adapter runs in your Python process. It is not an agent, model or cloud SDK. It reads saved, fictional JSON fragments and produces one of four decisions:

Authorize is a next step, not an authorization grant. The lab cannot identify a real caller or check their ticket access. It never invokes the function.

Download the Python response lab into a new training folder. Read it before running. Use Python 3.11 or later; it uses only the standard library and does not install packages, read credentials, make network calls or write files. The python3 command may be python or py -3 in your environment.

First predict the decision for Google Cloud's function proposal. Then run:

python3 --version
python3 cloud-model-response-lab.py --provider gcp --case tool --predict authorize

The terminal shows the JSON excerpt, the observed finishReason=STOP; content=tool, the authorize decision and the next check. The program actually parses the JSON and applies local rules; it does not ask a model to grade your answer. Exit code 0 means the prediction matched, not that an operation was approved or executed. A wrong prediction returns 1 with an explanation; use it to revise your reasoning.

Now test the same idea with different vendor fields:

python3 cloud-model-response-lab.py --provider aws --case limit --predict incomplete
python3 cloud-model-response-lab.py --provider azure --case tool --predict authorize
python3 cloud-model-response-lab.py --provider azure --case mixed --predict investigate
python3 cloud-model-response-lab.py --check

Expect stopReason=max_tokens for the AWS case and status=completed; content=tool for Azure's proposal. The mixed case is held because this small adapter deliberately supports one item at a time. That is our teaching policy, not a claim that providers cannot return multiple items. --check tests all three providers and boundary mutations, including complete-looking text that still has an output-limit finish.

Every provider has text, limit, tool, unknown, mixed, bad-arguments, unknown-stop and malformed cases. Use --help to inspect the controls. Try --case bad-arguments: a numeric ticket ID does not satisfy this exercise's string-valued function contract. Well-formed JSON alone is not enough.

Copy one JSON excerpt from section 2 into a local file named response.json. Keep synthetic data only. Before editing it, write your predicted decision and the one field that supports it. Run your own excerpt through the same adapter:

python3 cloud-model-response-lab.py --provider gcp --stdin < response.json

Use the matching provider name for your excerpt. The < passes the file to the program's standard input; the program does not open paths or execute the contents. It accepts at most 8,192 characters. If your shell does not support this syntax, use the supplied cases or edit a copy of specimens() in the downloaded script. No cloud SDK or credentials are required. Do not use eval or execute model-supplied code. A function name in JSON is data, not permission to invoke arbitrary code.

Try these mutations and explain the changed outcome:

• Replace the normal finish with the token-limit finish but retain complete-looking text. Expected: incomplete; appearance does not override completion evidence.
• Keep STOP or completed, but replace text with the custom function item. Expected: authorize; normal completion does not mean final prose.
• Remove the content entirely, or replace its type with an unknown value. Expected: investigate; no invented answer.
• Mix a function proposal and text in one result. Do not silently publish the text or drop the proposal. For this deliberately narrow adapter, classify the mixed shape as investigate until you design an explicit multi-item policy.
• Supply malformed JSON. Your error path must preserve the failure without trying to repair or execute it automatically.

The adapter accepts exact selected excerpt shapes, including a single candidate and content item. Extra fields, refusals, filters, unfamiliar finish states and multiple items deliberately go to investigate. These may be valid provider responses; they are outside this small lab's contract. Duplicate JSON keys, non-standard constants and invalid JSON also stay explicit failures. Do not use this exercise as a complete production response decoder.

Retain the fixture, expected decision, observed decision and one explanation. Ask another learner to add a counterexample. Passing these local cases proves only the behavior of your adapter for the tested shapes, not vendor access or production correctness. Delete the disposable directory when finished; there are no cloud resources to clean up.

Normal text goes to evidence and output checks before display. An output-limit result remains incomplete; review input size, allowance and bounded recovery. A client-side function call is a proposal. Validate its name and arguments, bind the trusted caller and authorize the requested record before any execution. Send back only a permitted result if the workflow continues. An unknown response needs an explicit failure path, not an optimistic default.

In a real client, add documented handling for refusals, safety filters, service errors, streaming, timeouts, retries and multiple content items. Distinguish your client-side functions from provider-hosted tools. Do not claim this small exercise covers every provider behavior or grants a certification.

To deepen the exercise, add one clearly specified case to your own adapter and a test that would fail if you silently dropped part of the response. For a real client, choose the current provider SDK and documented response types, then implement the full content, completion and error policy for that API. Keep permission checks in the application; a model cannot grant them.

Continue with the guided AI-platform lesson for Google Cloud, AWS or Azure. Those lessons require training access; this lab remains free.

• Google Cloud GenerateContent
• Google Cloud response and finish reasons
• Google Cloud function calling
• AWS Converse API
• AWS inference profiles
• Microsoft Foundry endpoints
• Azure OpenAI Responses
• Microsoft Responses reference