Workflow layer
Start here. This is the preferred way to build with ProviderPlane when you want explicit multi-step orchestration with less boilerplate.
Start with workflows, not raw provider calls. These docs take you from installation and provider configuration to a first workflow.
Most users only need a few pages to get moving: install the library, understand the workflow model, copy a representative example, then use the API reference for exact signatures.
ProviderPlane has multiple public layers, but they are not equal starting points. Most applications should stay at the workflow layer unless there is a clear reason to move lower.
Start here. This is the preferred way to build with ProviderPlane when you want explicit multi-step orchestration with less boilerplate.
Use jobs when you need lower-level control over individual executions. Compared with the workflow layer, they require more manual orchestration.
Use direct client calls only for isolated capability access. This is the thinnest layer and the most manual once calls start depending on each other.
Use these runnable examples as practical patterns once the basic workflow model makes sense.
The recommended way to build with ProviderPlane: explicit multi-step workflows with fan-out, fan-in, approval, and custom logic.
A workflow example that fails intentionally, persists state, and resumes from a later run.
A single capability call run through the job system for finer execution control.
The thinnest public layer for one-off capability calls when you do not want jobs or a workflow graph.