SCENARIO 01
Successful request
Record the requested and actual model, policy version and provider attempt.
THE GOVERNATLAS RESEARCH LIBRARY
A buyer’s operating playbook for AI gateways: compare SDK and proxy boundaries, test retries and partial streams, inspect key controls, reconcile provider spend and document an exit path. Includes a private failure-testing worksheet and cost reconciliation calculator.
GovernAtlas editorial analysis
Published October 15, 2026
Original operating recommendations. Model-assisted research, with primary-reference and editorial review. No paid placement or unperformed product testing.
The research library ↗THE QUESTION
Evaluate the request path under failure before optimizing the happy path. Preserve the model that actually answered, every attempted call, the policy that allowed it and the usage you can reconcile. A successful HTTP response is not sufficient evidence of a correct, authorized or economical outcome.
01 / THE METHOD
An AI gateway sits on a model-request path and can centralize routing, provider access and related controls. An SDK embedded in each application, a self-operated proxy and a vendor-operated service place those responsibilities in different hands. Begin with a simple request-path diagram: caller, identity check, gateway, provider, telemetry destination and any external evaluator. Mark which party operates and can change each part.
Write down the decision you expect the gateway to make. Examples include selecting an approved model, applying a tenant budget, allowing a fallback provider or refusing an unauthorized key. Keep those decisions separate from observing what happened after the request. A dashboard that reports spending does not by itself establish that an over-budget request is prevented. A guardrail score does not by itself establish where a request was blocked.
Treat distribution and deployment as buying criteria. A project may publish an open-source gateway while a managed service adds enterprise controls. Record the exact release, license and feature bundle you intend to operate, the person responsible for upgrades and the party responsible for provider contracts. Do not infer managed-service support from a successful local installation or self-hosted parity from a shared product name.
02 / THE METHOD
Create a route manifest for each application and data class. Record the preferred model, allowed alternatives, region constraints, permitted features and the person allowed to change the route. Fallback is a policy decision as well as an availability mechanism: the alternate provider may differ in data handling, supported output format, tool-call behavior or commercial terms. The cheaper or healthier endpoint is not automatically an acceptable replacement.
The current LiteLLM documentation describes retries followed by fallback between model groups and distinguishes ordinary failures, context-window failures and content-policy failures. Portkey’s documentation also describes configured fallback paths. These are descriptions of particular implementations. Our recommendation is to inspect each error category separately and decide whether your application should retry, choose an approved alternative or stop. Do not turn a content-policy refusal into permission to search for a less restrictive model.
Test configuration in the form actually deployed. LiteLLM currently documents that certain mock fallback flags no longer affect Proxy requests from version 1.85.0, although direct Router tests retain them. A passing library mock can therefore say little about the live proxy path. In an authorized non-production environment, produce the intended upstream error and inspect the normal caller request, route decision and resulting attempt record.
03 / THE METHOD
Use synthetic data and a bounded test budget. Start with an ordinary successful call, then introduce a rate limit, a timeout before output and a stream interrupted after some output. Record the caller deadline separately from each provider timeout. If the client, gateway and application all retry independently, the operator needs to explain the combined attempt sequence rather than count only the final response.
A partial response deserves its own review. Determine whether the caller sees a terminal error, a partial result or a replacement response. If a retry or fallback follows, inspect how the application prevents mixed answers or duplicate tool actions. For an agent that writes to another system, a model-level retry is not proof that the external action is safe to repeat. Use a non-production receiver and preserve the actual side-effect record.
Set acceptance criteria before the demonstration. For example, the caller must be able to distinguish complete from interrupted output; every provider attempt must have an identifier and outcome; a disallowed route must remain unused; and an uncertain external action must reach an owner. These are proposed operating criteria, not results from tests performed by GovernAtlas. Preserve deviations and incomplete evidence instead of reducing the trial to an unexplained pass percentage.
04 / THE METHOD
Separate provider credentials, application keys and human administration. A team-scoped key should not silently inherit access to every configured model or another tenant’s budget. Ask the operator to demonstrate creation, restriction, revocation and rotation using the intended role. Inspect the configuration change record as well as a successful request, then send a request that should be denied.
Budgets need an explicit operating definition. Find out whether a number is a reporting threshold, an alert, a rate limit or a hard spending boundary. Ask how concurrent requests, delayed usage reporting, cached responses and retries are handled. Use a small synthetic quota in the pilot; do not assume that a dashboard total explains enforcement timing or reconciles exactly with a provider invoice.
Test sensitive-data handling with markers rather than real secrets. Inspect the gateway log, tracing backend, evaluator requests and exports for those markers. A configuration described as disabling body storage may still emit metadata or forward content to another service. Record each destination, retention rule and operator. Keep redaction effectiveness and access isolation as observations requiring evidence, not automatic conclusions from a product feature label.
05 / THE METHOD
Keep an attempt ledger with request ID, attempt ID, provider, actual model, route-policy version, outcome, usage fields and the applicable price reference. Distinguish provider-reported usage from an estimate. A failed caller request may still involve provider work; an apparent cache hit needs a separate accounting rule. Preserve unknown charges as unresolved rather than assigning them zero to balance a report.
Compare the same period, currency and cost scope. Provider invoices can include items outside the gateway view; internal estimates may exclude discounts, commitments, tools or other service charges. Record those differences before calculating a discrepancy. The worksheet below subtracts your entered attempt-cost total from your entered provider total. It does not fetch billing data, estimate tokens or determine which amount is correct.
For an illustrative reconciliation, three attempts recorded at $0.02, $0.03 and $0.05 total $0.10. A same-scope provider total of $0.12 leaves a $0.02 difference to investigate. That difference is not evidence of overbilling or gateway failure until timing, price version and missing usage are checked. When comparing alternatives, also record whether the final response passed the same task-level acceptance criteria; cheaper unusable answers are not the same outcome.
06 / THE METHOD
Interrupt telemetry delivery separately from the gateway request path. Can the application keep operating while the operator knows evidence is missing? If the gateway itself is unavailable, the team needs a defined response: queue, reject, degrade or use an explicitly approved alternate path. An emergency direct-provider bypass can also bypass policy and logging, so it requires its own authorization and test rather than an undocumented workaround.
Export the configuration and evidence needed to investigate an incident after the trial ends. Keep key secrets out of the export, but retain model aliases, policy versions, attempt IDs, evaluator references and ownership decisions. Review whether another operator can reproduce the investigation without access to a salesperson’s demo environment. Include deletion, credential rotation and support escalation in the exit exercise.
Finish with a decision record tied to the tested version and use case. State what was observed, what remains unknown, who accepts the unresolved issues and which change triggers a repeat review. New models, providers, routing rules, SDK versions and deployment modes can invalidate an earlier assumption. A useful pilot produces an operating agreement and inspectable evidence, not a permanent platform-wide endorsement.
YOUR WORKING MATERIALS
REFERENCES / METHOD / SCOPE
The procedures, scenarios and acceptance questions in this guide are GovernAtlas editorial recommendations. They are not a prescribed standard, legal determination, certification or independent test result. Primary references were inspected October 15, 2026; source-specific concepts remain distinct from our recommended implementation method.
Implementation-specific retry/fallback categories and the current Proxy mock-testing deprecation. Not a recommendation to bypass content policies.
Configured fallback behavior in this implementation; current deployment and commercial scope require separate confirmation.
Supported-model instrumentation and pre-ingestion drop-filter concepts; monitoring remains distinct from gateway enforcement.
CONTINUE THE RESEARCH
These related profiles contain source-scoped statements and diligence questions. Their inclusion here is an editorial reading path, not a ranking or evidence that every platform performs every workflow in this guide.
Datadog presents Agent Observability, also referenced as LLM Observability, with end-to-end tracing, datasets, experiments, offline/online evaluations, prompt workflows and annotations. It describes SDK and OpenTelemetry/API integration paths.
LiteLLM project documentation distinguishes its Python SDK from the self-hosted proxy gateway and describes provider routing, retry and fallback logic. The gateway description includes virtual keys and cost tracking; enterprise features and managed-service entitlements remain separate.
New Relic documents AI monitoring through its APM agents for supported models and frameworks. It describes token and request/response events, user feedback, trace-level investigation, alerts and dashboards, and pre-ingestion sensitive-data drop filters.
Portkey documentation now labels the offering Prisma AIRS AI Gateway and describes a unified model interface with observability, gateway and guardrail workflows. Its managed service and open-source gateway are distinct operating scopes.
Pydantic describes Logfire as OpenTelemetry-based application and AI observability, correlating model, tool, API and database spans. It describes SQL querying, span-linked evaluations and human review, while distinguishing open-source SDKs from its closed-source server.
Splunk documents Agent Observability as an observability, evaluation and guardrail offering with on-premises and Splunk Observability Cloud SaaS deployment options. Current documentation explicitly says features/configuration vary by deployment; legacy Galileo onboarding scope is separate.
SUPERWISE currently presents Sentinel as an AI gateway, Chat as a business AI workspace and a shared platform for policies and audit trails. It also offers implementation and governance services; these are separate from software capabilities.