Add it without buying into a heavyweight framework
ProviderPlane is meant to be adopted incrementally. Start with the workflow layer, keep your application structure, and go lower only when the use case demands it.
Why teams reach for ProviderPlane
ProviderPlane is for teams building systems where one model call is no longer enough. It gives you a place to define workflow shape, execution policy, and provider strategy without letting those concerns leak through the whole codebase.
One workflow layer above many providers
Route work across OpenAI, Anthropic, Gemini, Mistral, and future providers through one orchestration layer instead of rewriting call sites every time provider strategy changes.
Add structure without hiding application decisions
ProviderPlane adds structure without pretending it should own every application decision. Provider-chain fallback can live in the library while terminal failure handling and business-specific logic stay explicit.
Support the workflows people actually build
Model workflows that mix generation, moderation, transcription, translation, and other multimodal steps in one explicit graph instead of reducing everything to prompt in and text out.
Extend the workflow with your own capabilities
Add custom capability steps when the built-in operations are not enough, so the workflow layer can still model the application you actually need.
Where ProviderPlane helps
Orchestration spreads through app code
Once fallback rules, timeouts, sequencing, and provider-specific branching are spread across individual steps, the workflow gets harder to follow and harder to change.
Your workflow includes application-specific steps
Real workflows mix provider operations with application-specific steps like approvals, persistence, and custom processing. That gets awkward fast when everything has to be modeled as raw provider calls.
You want a workflow layer, not a platform rewrite
You should not need a platform rewrite just to add workflow structure. ProviderPlane is meant to layer into the application you already have.
You want structure without framework magic
A workflow layer should make execution easier to see, not bury it behind hidden conventions. ProviderPlane gives you explicit workflow structure while leaving lower-level escape hatches available.
Where it fits in your stack
Application code triggers workflows
Routes, workers, or services should express intent and consume outputs, not own orchestration details.
ProviderPlane organizes workflow execution
It gives you one place for workflow structure, runner behavior, provider-chain fallback, and exports without pretending to own every application decision.
Providers stay implementation detail
OpenAI, Anthropic, Gemini, Mistral, and future integrations remain below the workflow layer where they can change without reshaping the app.
When not to use it
If you only need one provider call
Use the provider SDK directly. ProviderPlane becomes useful when one model call turns into a workflow.
If you want to stay at the lowest layer
The core client and job system are there when you need lower-level control, but most applications should not have to live at that layer just to build a workflow.