Orchestration powered by Temporal at Zscaler: Wrap, don’t rewrite

Most orchestration stories start the same way. A script grows up. Someone wraps it in a pipeline. The pipeline gets fragile. Someone wraps the pipeline in another pipeline. The wrapper becomes the thing that breaks.

It is a recognizable arc. Most of us have lived some version of it, or watched colleagues live it. The interesting question isn’t whether it happens, it’s whether you can see it coming early enough to design around it instead of through it.

When we at Zscaler sat down to design our next-generation automation platform, that was the conversation we wanted to have. Not how do we coordinate these tools better. But what is the right shape above these tools, such that coordination becomes a property of the architecture instead of a thing we keep writing.

That reframe is what shaped the architecture. The rest is just what fell out of it.

Eight engines and no home above them#

Modern infrastructure automation is not a single-tool problem. By the time any organization gets to meaningful scale, it has accumulated a heterogeneous estate of execution engines, each excellent at its own thing.

In our case, it was eight of them:

• Ansible: for configuration management and remote execution

• Terraform and OpenTofu: for declarative infrastructure provisioning

• Helm: for Kubernetes application packaging

• ArgoCD: for GitOps-driven Kubernetes delivery

• Crossplane: for cloud-native resource management via Kubernetes CRDs

• Kubernetes Cluster API: for the lifecycle of Kubernetes clusters themselves

• AWS CloudFormation: for AWS-native infrastructure as code

• Jenkins: the one nobody talks about in modern architecture diagrams, but that is still running half the CI in most real organizations

Each engine has its own CLI, state model, and idea of what “done” looks like. Each is excellent in its lane. None was designed to be coordinated with the others. And every previous generation of automation platform, ours included in earlier forms, had handled that coordination with custom Bash, chained pipelines, and bespoke glue. That layer always ended up more fragile than the engines it was trying to coordinate.

We wanted to do something different. The shape we kept coming back to was the idea of a contract, something above the engines that didn’t run them, but held them.

A workflow, in that framing, is not a script. It is a contract between the intent of an operation and its eventual completion. The contract survives the process. It outlasts the Worker that started executing it. It remains inspectable long after the original caller has walked away. Failure becomes a recoverable state instead of a terminal condition. Retries become a configuration, not a feature you implement every time. Most importantly, it stops mattering what is actually executing at the leaf level.

That is what we built Temporal Workflows for.

Figure 1. The unifying layer: one durable orchestration contract above heterogeneous automation engines. Temporal is the only thing coordinating across the platform. Everything else is wrapped.

The workflow that crosses engines#

In any real operational sequence, you almost never stay inside one engine. A meaningful workflow looks like this: run an ArgoCD sync to deploy the new service version, then trigger a Jenkins job to run integration tests, then execute an Ansible playbook to update downstream configuration on the hosts, then poll a Crossplane resource until the underlying cloud infrastructure has reconciled.

Before Temporal, the only place this kind of cross-engine sequence could live was in a custom script or a chained pipeline, the most fragile part of the platform, written and rewritten dozens of times because the requirements kept changing. The stitching code was where every outage came from.

Figure 2. A cross-engine workflow sequenced under a single durable contract.

The brownfield part nobody talks about#

Most of us inherit estates. Jenkins jobs that everyone is too afraid to touch. Ansible playbooks with three layers of conditional logic. Terraform modules with cyclical dependencies no one wants to untangle. ArgoCD applications set up by someone before they left the company. CloudFormation stacks that were configured in a console and never re-imported into code. The estate is real. It works, mostly. And there is no business case for tearing it down to rebuild on a new orchestration layer.

The most important call we made was this: we didn’t refactor any of it.

Every engine stayed exactly as it was. We did not migrate, rewrite, or ask any of their owners to learn a new system. We wrapped them. Each became a leaf-level Activity inside a composite workflow that the orchestration layer owned. From the outside, very little changed. From the inside, several things did:

• No refactoring required. The existing automation kept running, untouched, with the same interfaces its owners already knew.
• Durability without rewriting. Every wrapped operation became survivable across worker failures, without changing a line of the underlying engine code.
• Cross-engine workflows became possible. Sequences that previously lived in fragile glue, ArgoCD then Jenkins then Ansible, now sit inside a single durable composite.
• Attribution at the step level. When a wrapped operation fails, the failure surfaces against a specific step with its own history, instead of as a vague pipeline error.
• Incremental adoption. Engines can be wrapped one at a time. The platform value compounds with each one, without requiring a coordinated migration.
• Break-glass paths preserved. The original engines remain directly usable. If the orchestration layer is unavailable, operators can fall back to the tools they already know.

Figure 3. Brownfield wrapping pattern: the engines stay; the contract above them is new.

The last benefit deserves a closing word, because it is rarely articulated. The engines we wrapped are still there, intact and usable directly. If the orchestration layer is unavailable, an operator can SSH to a host and run an Ansible playbook, log into Jenkins, run a Terraform plan from a laptop, or update a CloudFormation stack from the AWS console. Greenfield approaches that rebuild everything as workflows lose this option; we kept it because we never removed the engines. We have not had to break the glass often, but the fact that we can is part of why the new platform was adopted with so little organizational friction.

On precedent#

The idea of a unifying layer above heterogeneous orchestration domains is not new. Cloudify, for example, has used the phrase “orchestrator of orchestrators” for several years, and similar patterns have appeared in adjacent spaces. The pattern is recognized. What we built is one way of arriving at it: using Temporal as a general-purpose durable execution foundation, applied to a brownfield infrastructure estate, with the leaf engines left intact.

Durability and distributed control via Temporal Execution#

The core advantage of using Temporal as the orchestration layer is the durability it brings to the operational sequence. By wrapping existing components, such as Ansible, Terraform, and ArgoCD, as leaf-level Activities in a Temporal Workflow, the orchestration contract becomes durable. The Workflow, which represents the intent of an operation, persists across worker outages and system failures. Temporal manages execution state, making failures recoverable and retries a matter of configuration rather than custom scripting. This makes complex, cross-engine sequences reliable without refactoring the underlying brownfield automation engines.

Furthermore, Temporal Workers naturally facilitate a model of distributed control with an “inside-out” connection architecture. Instead of the Temporal Server pushing commands to external machines (an “outside-in” model often blocked by firewalls), the Workers themselves act as dedicated agents or receivers. These Workers run in the environment where the execution engines, such as Ansible or Terraform, reside and initiate a connection to the Temporal Service to poll for Activity Tasks. This “inside-out” connection pattern simplifies networking for distributed execution, especially in heterogeneous or secured environments. It decouples the long-running workflow contract from the ephemeral worker process, distributing control execution across the estate while maintaining a centralized, durable state for the orchestration contract.

AI workflows as the next leaf#

Most leaves we’ve discussed so far are deterministic. A terraform apply produces a known set of resources. A REST API call returns a structured response. An MCP endpoint invocation is a protocol-level call to a defined tool. “Done” is unambiguous, and the contract above the leaf just needs to know when the call completes and whether it succeeded. LLM invocations are different. The leaf executor is a model deciding what to do, what to return, and sometimes what to call next.

This is where the brownfield angle matters most. If you’ve already wrapped your legacy automation in durable composite workflows, then introducing agentic execution isn’t a separate project. It’s the next kind of leaf. An AI agent recommending a remediation, a model deciding which playbook to invoke next, and an LLM-driven diagnosis feeding into a deterministic action all fit inside the contract you already have.

You don’t build a new platform for agentic workflows. You add new leaf activities to the platform you’ve been quietly consolidating for years.

It is early. But the fact that the same orchestration layer that runs our infrastructure operations is also the layer we’d reach for to wrap an agentic workflow is not a coincidence. It shows that the contract is at the right level of abstraction.

A closing thought#

If you’re somewhere on the script-wrapping path right now, and most of us are at some point, the question worth pausing on might not be what’s the next wrapper.

The question might be: what would change if we stopped wrapping?