Skip to main content

Run a workflow

In this guide you will run the platform's sample durable workflow, agent-pipeline. It invokes an agent twice — carrying the conversation session from the first call into the second — with automatic retries on every call. You will start it, watch it complete, and read its execution history.

What the sample does​

The workflow (AgentPipelineWorkflow) takes three inputs: an agent name and two messages. It then runs two activities in sequence:

  1. InvokeAgent — sends the first message to the agent's invoke endpoint. The agent answers and returns a session_id.
  2. InvokeAgent again — sends the second message with that same session_id, so the agent remembers the first exchange.

Each activity carries this retry policy (from the sample's workflow.go):

SettingValueMeaning
StartToCloseTimeout30sEach attempt must finish within 30 seconds.
InitialInterval1sFirst retry comes 1 second after a failure.
BackoffCoefficient2.0Each wait doubles: 1s, 2s, 4s...
MaximumAttempts3Give up after 3 attempts and fail the workflow.

If the agent is briefly unavailable — cold-starting, for instance — the activity fails, waits, and retries without you writing a line of retry code. If the worker itself dies between the two calls, the workflow resumes at call two; call one is not repeated.

Before you begin​

  • kubectl access to the platform cluster. Durable Execution has no public endpoint in this alpha — everything here runs against the cluster directly.
  • A deployed agent to invoke. This guide uses research-buddy from the agent quickstart.
  • The sample lives in the platform repository at examples/workflows/agent-pipeline. Its worker image must be available in the cluster's registry (your platform operator's standard image build publishes it).

1. Deploy the worker​

The worker is a normal Kubernetes Deployment that hosts the workflow and activity code and polls the agent-pipeline task queue.

kubectl apply -f examples/workflows/agent-pipeline/deploy.yaml

You should see:

deployment.apps/agent-pipeline-worker created

It runs in the cai-services namespace and connects to the Temporal frontend at temporal-frontend.cai-services.svc.cluster.local:7233 (set via its TEMPORAL_ADDR env var). Confirm it is running:

kubectl -n cai-services get deploy agent-pipeline-worker

You should see:

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
agent-pipeline-worker   1/1     1            1           30s

2. Find the Temporal admin-tools pod​

The temporal CLI ships in the platform's admin-tools pod, so you don't need to install anything locally:

POD=$(kubectl get pods -n cai-services \
  -l app.kubernetes.io/component=admintools \
  -o jsonpath='{.items[0].metadata.name}')
echo "$POD"

You should see a pod name like:

temporal-admintools-6d9f7c9b8d-x2k4p

Every Temporal pod shares the label app.kubernetes.io/name=temporal, so the selector above picks the admin-tools role out with app.kubernetes.io/component.

3. Start the workflow​

The workflow takes three positional JSON inputs — one --input flag per argument, each a JSON string (hence the doubled quotes):

kubectl exec -n cai-services "$POD" -- temporal workflow start \
  --type AgentPipelineWorkflow --task-queue agent-pipeline --workflow-id demo-1 \
  --input '"research-buddy"' \
  --input '"My boat is a Mastercraft Maristar 245."' \
  --input '"What boat do I have?"'

You should see output that includes (abridged; exact formatting varies by temporal CLI version):

Running execution:
  WorkflowId  demo-1
  Type        AgentPipelineWorkflow
  TaskQueue   agent-pipeline

The workflow type (AgentPipelineWorkflow) and task queue (agent-pipeline) are fixed by the sample — they must match what the worker registered.

4. Watch it complete​

kubectl exec -n cai-services "$POD" -- temporal workflow describe --workflow-id demo-1

You should see output that includes:

Status  COMPLETED

If it still shows Running, the agent may be cold-starting — the retry policy is doing its job. Check again in a few seconds.

5. Read the history​

The full event history is the payoff of durable execution: every activity call, retry, and result is recorded.

kubectl exec -n cai-services "$POD" -- temporal workflow show --workflow-id demo-1

You should see two ActivityTaskCompleted events (both InvokeAgent), and a final result of the shape:

{"First":{"session_id":"...","output":"..."},"Second":{"session_id":"...","output":"..."}}

Check that Second.output answers the boat question — proof the second call reused the first call's session_id and the agent remembered the conversation.

Honest scope of alpha support​

Know what you are running
  • This is a sample integration, not a managed workflow service. There is no REST API, no platformctl command, and no console page — only kubectl and the temporal CLI, as you just used them.
  • The Temporal frontend is in-cluster only and has no platform authentication; any in-cluster workload can reach it. Do not put secrets in workflow inputs.
  • All projects share one Temporal namespace — workflow IDs are cluster-global, so prefix yours to avoid collisions.
  • Temporal's server roles (frontend, history, matching, worker) each run 3 replicas and the read-only web UI runs 2, so losing one pod does not pause workflows. The real single point of failure is Temporal's state store: a single-instance CNPG Postgres cluster (temporal-postgres). While it restarts, running workflows stall — but nothing is lost.

To run your own workflows today, copy examples/workflows/agent-pipeline as a template: write a Temporal worker, point it at temporal-frontend.cai-services.svc.cluster.local:7233, deploy it in-cluster, and drive it with the temporal CLI.

Clean up​

Remove the worker Deployment (the completed workflow's history stays in Temporal):

kubectl delete -f examples/workflows/agent-pipeline/deploy.yaml

You should see:

deployment.apps "agent-pipeline-worker" deleted

Next steps​