Hybrid AI + Deterministic Execution

TL;DR

Orkestia's flagship execution model separates two jobs that most "AI workflow" tools conflate:

1. Design — figuring out what steps to run, in what order, with what inputs. This is open-ended, benefits from reasoning, and is where AI (DGI and agents) earns its keep.
2. Execution — actually running those steps reliably, every time, with locking, retries, observability, and an audit trail. This wants determinism, not creativity.

The hybrid model uses AI for design, then compiles the resulting plan into a deterministic virtual workflow (a composition) that the engine runs with no LLM in the hot path. You explore once with AI, capture the result as a reusable composition, and from then on it runs like any other DAG: byte-stable, cheap, and fully auditable.

Why split design from execution

An LLM in the execution path is a liability: it is non-deterministic, slow, expensive per invocation, and hard to audit ("why did it do that this time?"). But an LLM is also the best tool we have for turning a vague human goal into a concrete plan against a large, changing catalog of capabilities.

Orkestia resolves the tension by letting the model operate only where its strengths apply:

The key insight from the platform's internal substrate: the compiler emits a dict that matches the real engine's DAGWorkflow format exactly — there is no runtime marker. The engine does not know or care that a config was authored by an AI. Once compiled, a virtual workflow is indistinguishable from a hand-written one, which is precisely what makes it trustworthy.

The lifecycle: explore → capture → run

The three phases:

1. Explore with AI

A human expresses a goal. DGI (the Dialog Generative Interface) or an autonomous agent reasons about it, discovering available capabilities over MCP rather than against a static, hand-maintained list. The catalog is whatever is installed and importable — so the model plans against ground truth, not a stale snapshot.

The model emits a plan in the VirtualWorkflow wire format: layers of steps, where every step references a {provider}.{service}.{operation} workflow type and every input is an explicit mapping with a known source.

{
  "name": "provision_and_tag_bucket",
  "layers": [
    {
      "name": "create",
      "steps": [
        {
          "name": "s1",
          "workflow_type": "aws.s3.create_bucket",
          "input_mapping": {
            "name": { "source": "input", "field_name": "bucket_name" }
          }
        }
      ]
    },
    {
      "name": "tag",
      "steps": [
        {
          "name": "s2",
          "workflow_type": "aws.s3.put_bucket_tagging",
          "input_mapping": {
            "bucket":  { "source": "step", "step": "s1", "field_name": "bucket_name" },
            "tagging": { "source": "static", "value": { "TagSet": [{ "Key": "env", "Value": "demo" }] } }
          }
        }
      ]
    }
  ]
}

Input mappings come from exactly three sources, with no implicit global scope and no runtime string templating:

This explicitness is what makes the plan compilable — and later, auditable.

2. Capture as a composition

Before anything runs, the plan goes through three-phase validation, each phase short-circuiting with a typed error so the AI can self-correct in a loop:

A failure is structured data, not a stack trace in a string — designed to be fed straight back into the model:

{
  "phase": "references",
  "step_id": "s2",
  "workflow_type": "aws.s3.put_bucket_taging",
  "reason": "unknown workflow type; did you mean 'aws.s3.put_bucket_tagging'?"
}

Once validated, compile_workflow emits engine-ready JSON:

{
  "id": "provision_and_tag_bucket",
  "layers": [
    { "steps": [ { "id": "s1", "workflow": "aws.s3.create_bucket",
                   "inputs": { "name": {"from": "input.bucket_name"} } } ] },
    { "steps": [ { "id": "s2", "workflow": "aws.s3.put_bucket_tagging",
                   "inputs": {
                     "bucket":  {"from": "step.s1.bucket_name"},
                     "tagging": {"value": { "TagSet": [{ "Key": "env", "Value": "demo" }] }}
                   } } ] }
  ]
}

This JSON is the composition. It's the durable artifact you version, diff, review, and reuse.

3. Run deterministically

From here the AI is gone. The compiled DAG is dispatched to the workflow engine, which runs it like any other workflow: PG advisory locks for concurrency, the middleware pipeline, retries, and an event-sourced history that records every transition. The workflow.transition events flow through Kafka to the consumer (the canonical async path), and Lumen captures observability and the audit trail.

No tokens are spent. No model is queried. The run at 3am behaves exactly like the run at noon.

When to stay AI-driven vs. when to compile

Compiling is not always the right move. The decision turns on how stable and repeated the task is.

A useful mental model: AI authors the first run; the composition owns every run after. You let the model explore until a plan is good, then "freeze" it into a deterministic workflow. If requirements change later, you go back to the AI, regenerate, re-validate, and ship a new compiled version — the same way you'd edit and re-merge code.

How AI reaches the catalog

The design phase doesn't guess at capabilities — it discovers them. Agents and DGI talk to the engine over MCP (MCP integration): listing workflow namespaces and types, fetching schemas, checking prerequisites, then starting and watching runs. The same surface that an AI uses to discover capabilities is the one it uses to run a compiled composition, so there's a single, consistent contract from exploration through execution.

The dgi.* workflow family makes the design phase itself a first-class, discoverable surface — construction, conversion, template resolution, and execution are workflow types the engine can run, not hidden internal calls. See Concepts → DGI.

Governance fits naturally

Because compilation produces a reviewable artifact and execution produces an event-sourced history, the hybrid model slots cleanly into Staff governance: a fleet of AI agents can propose compositions, while approval gates decide which ones are allowed to compile and run. The deterministic phase is where oversight has teeth — you approve a frozen plan, not a probability distribution over future model behavior.

Notes & limitations

Where to go next