The short answer

AgentPlat can call OpenAI and compatible Chat Completions endpoints through a dependency-light ModelAdapter. An application can also choose the separate OpenAI Agents SDK provider when it needs that runner. The host supplies credentials and selects the model; the adapter does not read environment variables or grant authority for external actions.

Choose the integration that matches your execution model

AgentPlat exposes two different OpenAI paths. @agentplat/model-openai-compatible implements the public ModelAdapter contract for a chat completion call. Its chatModel helper has presets for OpenAI, Gemini, Ollama and OpenRouter, and accepts a custom base URL for another endpoint that follows the OpenAI Chat Completions wire format. For the OpenAI Agents SDK runner, the separate @agentplat/provider-openai package implements an AgentProvider.

These choices let an application select a narrow model call or a fuller agent runner. The first execution guide shows the transition from deterministic local execution to an explicit model adapter. The Inference Control guide describes where a host can place controls around calls made through an integrated path.

Your application configures the provider

For an OpenAI call, the application chooses a model and passes an API key to the adapter. The adapter does not discover secrets from the process environment. That keeps secret storage and tenant-specific resolution in the server or deployment that owns those credentials. With a compatible service, the application also selects the base URL and whether a key is required.

Protocol compatibility does not mean every model service accepts the same parameters or supports identical features. Check the endpoint and model behavior your application plans to use, then test streaming, cancellation and usage handling along that exact path. If the service speaks a different protocol, use its native AgentPlat adapter or implement the small public ModelAdapter interface.

A model response is not an approval

The adapter returns model output and provider metadata to the application. Your AgentPlat integration still decides how to interpret that response, whether a human must review it and which protected actions may run. A generated recommendation does not itself authorize a payment, message, record update or other external effect.

If an agent can perform protected actions, connect the provider execution path to your application policy and checkpoint controls. The model adapter governs the invocation boundary only when the application routes calls through it; separate SDK calls or direct HTTP requests need their own controls. Keep the scope of the integration visible in code and test the paths that can actually reach a provider.

Check the package and endpoint before adoption

The adapter packages are published independently from any model provider, and provider access remains subject to the provider account and terms. Before installing, check AgentPlat's release channels and the package's current instructions. Start with a mock or local compatible server, then configure real credentials in the environment that runs the application.

This guide describes integration behavior from AgentPlat source and package contracts. It does not claim comparative model quality, availability, pricing or latency. Those vary by model, endpoint, region, account and application workload; evaluate them with your own representative inputs and operational requirements.

Sources and further reading

Documentation reviewed . Consult the linked documentation for current implementation details.