Why the distinction matters
It is tempting to call every durable background process orchestration. That makes products harder to understand and harder to adopt.
A developer who only needs one model request to finish should not have to model a graph, configure provider routing, or adopt a no-code workflow builder.
Request execution is smaller
Request execution has one job: accept a request, run it to a terminal outcome, record attempts, and expose status.
That is the unit ReqRun focuses on. It is the reliability layer around the OpenAI-compatible LLM request itself.
Workflow orchestration is broader
Workflow orchestration coordinates multiple steps, dependencies, branching, scheduling, external systems, and often human approval.
Those systems are valuable when the whole business process needs to be modeled. They are not always the right answer when the failure mode is one unreliable model call.
Where ReqRun fits
ReqRun can be called from a workflow, queue worker, API route, cron job, or agent runner. It does not own the surrounding process.
It owns the reliability record for the LLM request: queued, processing, retrying, completed, or failed.
queued -> processing -> completed
queued -> processing -> retrying -> processing -> completed
queued -> processing -> failedThe practical lesson
A narrow reliability layer can be easier to trust than a large orchestration platform when the failure mode is one model request.
Start with the smallest durable boundary that solves the problem. For many LLM applications, that boundary is the request.