Workflow engines and durability

Three different lifecycles

A Kubernetes Run is a request reconciled to a Job. The Rust DAGExecutor is an embedded graph executor with nodes and dependencies for bounded work. The Go Temporal WorkRequestWorkflow executes ordered Work Items with persistent history, activity retries, and approval or rework signals. These are distinct paths in the source, not one automatically connected end-to-end Process API.

Use a DAG for bounded dependency work

DAG validates acyclic dependencies, then topologically orders ready nodes. DAGExecutor starts currently-ready nodes concurrently and waits before releasing dependent nodes; cancellation is cooperative and node retries use backoff. K8sOffload can submit specialized work to the cluster; Inline nodes in the current source return a simulated output, so do not treat the generic DAG executor as a complete arbitrary model/tool runner.

• Graph edges describe dependencies; retries are node-level attempts, not cycles in the graph.
• A failed node stops the graph; an external side effect may already have occurred.
• Offload is useful for specialized images or device placement, but requires adequate cluster permissions.

Use Temporal for long-lived decisions

WorkRequestWorkflow records phase and current step, executes a Work Item as an activity, and waits on approval/rework signals for gated steps. Its activity timeout is 30 minutes with at most three attempts; it caps rework at three and restarts from the first step after rework. Temporal persistence lets workers recover workflow state, not guarantees exactly-once tool writes. Do not assume Process.spec.maxReworkAttempts is passed to this workflow in the current integration.

Choosing and connecting a path

• For a simple Agent invocation, use a Run and observe its Job and status.
• For in-process dependency graphs, integrate the Rust DAG library explicitly; test Inline and K8sOffload behavior in the version you run.
• For approval waits or steps spanning worker restarts, use the separately configured Temporal Work Request adapter; test signals and resume behavior.
• If combining paths, define how Run ID, Work Request ID, status, artifacts, and authorization are propagated; the existence of both components is not automatic wiring.

Source

See engine/crates/kaigents-core/src/dag.rs, temporal-adapter/internal/workflow/workrequest.go, operator/internal/controllers/run_controller.go and the chart Run target schema. The domain-model document describes broader branching and Work Requests; distinguish that design from the concrete v1alpha1 contracts.