Skip to content
Zynax
Apache-2.0Go + KubernetesCNCF-graduated tech

Write your agent workflow once.Run it on Temporal or Argo, without a rewrite.

Zynax is the engine-portability layer for agentic automation: a declarative, cloud-native control plane that compiles one YAML manifest into a canonical IR and submits it to whichever workflow engine your organisation already operates.

Read the docszynax-io/zynax

Local development runs on kind, the same Kubernetes runtime used in CI and production. The first successful run needs no API key, no model and no secrets.

engine portability, on your laptopshell
# boot a local kind cluster: production Helm charts, no secrets$ zynax up $ zynax apply hello-world.yamlrun_id: wf-236c478f00eb68ce $ zynax status workflow wf-236c478f00eb68ceWORKFLOW_STATUS_COMPLETED # same manifest, other engine, zero edits$ zynax up --engine argo$ zynax apply hello-world.yamlWORKFLOW_STATUS_COMPLETED

The problem

Agent platforms pick your execution engine for you.

Most agent frameworks bind the workflow to the runtime that ships with them. The orchestration semantics, the retry model and the addressing scheme all leak into your workflow definition — so the day your organisation standardises on a different engine, the workflows do not move with you.

Locked to one engine

  • A Kubernetes-locked agent platform cannot move one workflow across engines.
  • Workflow logic is written against one runtime, so a migration is a rewrite.
  • Workflows address agents by name, so replacing an executor edits every workflow.
  • Adding a new tool means adopting yet another vendor SDK.

Portable across engines

  • One manifest runs unchanged on Temporal or on Argo — that portability is the wedge.
  • The engine is a flag: zynax up --engine argo, and the workflow file is untouched.
  • Workflows route to capabilities, so the executor behind one can be replaced freely.
  • Any gRPC service is a capability. Already standardized on a K8s-native agent tool? It registers as one.

How it works

Declarative spec, control plane, then the engine you already run.

Like Kubernetes for containers, Zynax is a control plane that abstracts the execution layer behind a declarative, versionable API. The manifest never names an engine, so the engine is free to change.

  1. workflow.yaml
  2. api-gateway
  3. workflow-compiler
  4. engine-adapter
  5. TemporalorArgo

The fork at the end is the whole product. Everything to its left is engine-neutral.

  1. 01

    Declare the workflow once

    One YAML manifest describes an event-driven state machine: states, the capabilities each state invokes, and the events that move it forward. No engine SDK appears anywhere in it.

  2. 02

    The control plane compiles it

    zynax apply posts the manifest to the api-gateway. workflow-compiler validates it and lowers it to a canonical WorkflowIR — a protobuf representation that no longer mentions YAML or any engine.

  3. 03

    Any engine executes it

    engine-adapter submits that same IR to Temporal or to Argo, and task-broker dispatches each capability to a registered adapter over gRPC. Changing the engine is a flag, not a rewrite.

  4. →

    The full service topology — gateway, compiler, engine adapter, task broker, agent registry, event bus and memory service — is documented in ARCHITECTURE.md.

code-review.yamlyaml
kind: WorkflowapiVersion: zynax.io/v1 metadata:  name: code-review  namespace: engineering spec:  initial_state: review   states:    review:      actions:        - capability: request_review      on:        - event: review.approved          goto: merge        - event: review.needswork          goto: fix     fix:      on:        - event: push          goto: review     merge:      actions:        - capability: merge_pr      on:        - event: merge.success          goto: done     done:      type: terminal

An event-driven state machine, not a DAG — which is what makes loops, human-in-the-loop steps and long-running waits expressible.

Principles

Design commitments, not roadmap items.

Declarative-first

Workflows are YAML manifests, not code. Versionable, diffable, GitOps-ready.

Engine-agnostic

Temporal, Argo and LangGraph are plugins. Swap the engine without changing the workflow.

Capability routing

Workflows route to capabilities — summarize, run_tests, open_mr — not to named agents. Swap the executor without changing the workflow.

No SDK required

Any system becomes a capability by implementing the AgentService gRPC contract: HTTP APIs, LLMs, Git providers, CI systems.

Event-driven state machines

Not DAGs. Loops, human-in-the-loop, long-running workflows and async events are native.

Cloud-native by construction

Go services on Kubernetes, gRPC between them, NATS JetStream for events. Built on CNCF-graduated technologies.

Quickstart

Five commands, one local cluster, two engines.

zynax up creates a kind cluster, loads the images, installs the production Helm charts and waits for every deployment to roll out. No Ollama, no model and no API key are needed for the first successful run.

the five-minute golden pathshell
# 1 - bring the platform up on a local kind cluster$ zynax up # 2 - apply a workflow manifest$ zynax apply spec/workflows/examples/hello-world.yamlrun_id: wf-236c478f00eb68ce # 3 - inspect the run$ zynax status workflow wf-236c478f00eb68ceWORKFLOW_STATUS_COMPLETED $ zynax logs wf-236c478f00eb68cestate.entered  reviewstate.exited   review -> merge # 4 - the wedge: same workflow, Argo instead of Temporal$ zynax up --engine argo # 5 - tear it all back down$ zynax down

Prerequisites

  • Docker, kind, kubectl and Helm on the host
  • Roughly 4 CPU and 8 GB RAM available
  • No cloud account, no model provider, no secrets

Install the CLI

Prebuilt zynax binaries for macOS and Linux, on both amd64 and arm64, ship with every GitHub release.

Everything past the golden path — the model-backed code-review demo, scaling onto managed Kubernetes, and observability — lives in the documentation.

Open the documentation