Open LLM provider support
Run agents on any model, configured centrally and switchable at runtime, from hosted Anthropic and OpenAI to self-hosted and private models.
What it is
The Flowable Agentic Case Platform doesn’t tie agents to a fixed list of model vendors. The previous OpenAI, Anthropic and Azure choices are replaced by configurable provider endpoints, so you point an agent at whatever model you are entitled to run. That includes hosted Anthropic and OpenAI models, any third-party service that implements the OpenAI API, and self-hosted or privately hosted models.
A team can run agents on a public hosted model while a regulated business unit routes the same agent design to a privately hosted, approved model, with no change to the agent itself.
What’s included:
- Custom OpenAI-compatible providers, so an agent can target any third-party endpoint that implements the OpenAI API
- Custom Anthropic-compatible providers, and the Claude Platform on AWS through Amazon Bedrock.
- The OpenAI Responses API, enabling Responses-based models such as the Codex family.
- Polymorphic authentication that replaces the single fixed API key, with a choice of auth schemes per provider.
- Custom request headers, fixed or custom endpoint paths, and a “None” authentication option for endpoints that supply the token themselves.
- Updated built-in Anthropic and OpenAI model lists in the agent editor
- Central Agent connections configured in Flowable Hub, referenced by name from agents, so the model an agent uses can be changed at runtime without redeploying the agent.
Why it matters
Model choice is a procurement, cost and compliance decision, and it changes over time. Letting agents run on any provider means an organisation can pick the best model for each task, keep sensitive workloads on models it controls, and switch models as the market moves, all without re-modelling its agents.
How it works
A provider is defined by its endpoint, its authentication scheme and, where needed, custom headers and request paths. The agent references the provider and a model name. At run time the platform calls that endpoint using the configured authentication, whether that is an API key, a custom header, or no platform-managed credential at all when the endpoint doesn’t need authentication. Built-in model lists give a fast path for the common hosted models, while OpenAI-compatible support covers everything else.
Central connections, switchable at runtime
Provider and model configuration does not have to live inside each agent. You can define an Agent connection once, centrally, in Flowable Hub, and have agents reference it by name. The agent carries the reference, not the credentials or the model name, so administrators own model configuration in one place.
Because the reference is resolved at run time, the model behind a connection can be changed without redeploying anything. This matters most when a provider deprecates a model: an administrator points the existing connection at the newer model version, and every agent that uses it picks up the change on its next run, with no re-modelling and no redeployment.
Example
During development, a team runs its agent against a self-hosted, OpenAI-compatible model on its own infrastructure. That model needs no authentication, so the Agent connection points at the local endpoint with authentication set to none.
For test and production, the same agent moves to a model approved for regulated data. That model requires authentication, and the credentials differ between the two environments, so test and production each configure their Agent connection with their own authentication. The agent design does not change, only the connection it resolves to in each environment.
Later, the provider announces that the approved model is being retired. An administrator points the Agent connection at the successor model, and every agent that references it moves to the new model on its next run, with no re-modelling and no redeployment.