The Orchestrator: define and run the decision path

Compose business processes from reusable steps, route outcomes, keep approval gates explicit, and inspect execution and its results.

Compose business processes from reusable steps, route outcomes, keep approval gates explicit, and inspect execution and its results.

The Orchestrator is HEPO's software for executing a defined business process. A process owner establishes the work, decisions, and authority involved; an implementer connects the required capabilities into steps. The orchestrator runs those steps, follows their outcomes, and brings work to a person when the definition requires a human decision.

Its output is both the result of the work and a record of the path taken. A quotation can move through checks and approval, while the responsible team can inspect which steps ran, where an exception arose, and what should happen next.

Build the quotation path

A logistics company receives a shipping quotation. Sales needs a margin assessment, operations needs the vessel schedule, compliance needs the relevant trade information, and finance needs the customer's credit position. These are different questions with different sources and decision owners.

An implementer can compose a process that gathers the agreed information, performs suitable calculations, prepares material for review, and routes the case to the authorized approver. Independent checks can run together; a check that depends on another result must wait for it. The approval step determines the permitted next path.

Where the chosen connector supports it, an explicitly authorized integration step can send the resulting decision to the external system. A response can then open the relevant case or refresh the operator's view. This is a configuration example, not a packaged quotation service or a promised completion time.

Three concerns meet in each execution

HEPO calls these concerns its three rails. They explain how the process is assembled and governed:

Concern What the implementer establishes
Objects: available capabilities Registered workers, validators, flow controllers, rules, and presentation components that a process can use
Processes: the path through work Steps, inputs, dependencies, transitions, error paths, and reusable sub-processes
Permissions: the authority to act Access to the process, its steps, relevant records, and protected fields

A worker performs a unit of business logic. A flow controller, called a scenarist, selects the next step from the outcome and process state. That routing responsibility is distinct from a person's authority to approve a business decision. Security Follows the Actor explains how identity and permission belong in the path.

Follow the execution cycle

The coordinator's Observe, Orient, Decide, Act cycle gives the technical evaluator a way to follow execution:

  1. Observe: read the request, validate its expected input, and resolve the process and its capabilities.
  2. Orient: evaluate applicable access and guardrail conditions and establish the context for the next step.
  3. Decide: let the flow controller select the next route, including completion, error handling, or waiting.
  4. Act: run the selected worker and examine its typed result before continuing.

Results distinguish success from structured failure. Step outcomes describe such possibilities as proceeding, branching, skipping, terminating, or redirecting. The implementer must account for the intended outcomes and exception paths; a diagram alone does not establish that every business case has been handled.

Compose and inspect the graph

The visual design surfaces let an implementer connect steps and examine their inputs and outputs. Typed ports express what a connection carries: a value, a dataset, a time series, a condition, or another defined payload. Compatibility checks and declared column schemas help identify unsuitable connections before use.

The available building blocks cover data access, transformation, analysis, presentation, integration, and control flow. Human gates provide places for approval, review, or data entry. The actual process uses the registered workers and configured bindings available in the deployment.

For graph execution, dependency levels determine which steps can run together. Independent steps receive the state available at the beginning of their level, and successful results are merged afterwards. A failure is recorded without simply cancelling every sibling. This makes dependencies and failure handling part of the process design, rather than something inferred from the order in which boxes were drawn.

Put reasoning in a defined step

An agentic worker adds model and tool access to a worker's responsibilities. In the quotation example it might prepare a risk summary from selected records. Its result still belongs to a process step with an output and a failure path. Local inference supplies reasoning; it does not replace the approval authority or make the summary automatically correct.

The implementer establishes the model, tools, permitted inputs, and unavailable-service behavior. The reviewer receives the material needed to assess the result. The HEPO Assistant provides another way for a user to reach available work; it is not the flow controller itself.

Examine before extending

Use validation and a configured simulation run to inspect bindings, dependencies, results, and simulated actions. A simulation requires an explicit treatment of side effects and suitable inputs. It does not automatically predict a team's future throughput. Process Analytics explains the distinction between execution records, review, and rehearsal.

Your process owner supplies the decisions and operating context. Implementers compose and verify the path; the delivery partner supports rollout and review with the people who will use it.

See the evidence behind the process ? See how results reach the user ? Process Orchestration overview

Bring us a process with its inputs, decisions, and expected result.