Design pattern for providing workflow-level customization in Temporal agents built using a code-first approach

Developer Corner
, ,
1

I’m building an agent platform on Temporal (Python SDK) where agents and workflows are implemented using a code-first approach. These workflows orchestrate multiple activities and AI-driven steps to perform tasks such as document drafting, validation, analysis, and human-in-the-loop interactions.

The same agent framework is deployed for multiple customers, but different customers want to introduce custom behavior on top of the base workflow. This customization can include things like:

  • Custom validation logic before certain workflow steps

  • Calling customer-owned APIs for policy checks or data enrichment

  • Adding additional workflow steps before or after certain stages

  • Implementing customer-specific business rules or guardrails

The goal is to allow customers to extend or customize workflow behavior without forking the base workflow or maintaining separate workflow implementations per customer.

Currently we are exploring several approaches:

  1. Defining extension points (hooks) in the workflow where custom activities can be executed.

  2. Using tenant-specific workers or task queues that implement certain activities differently.

  3. Delegating customization to external services via Temporal Nexus.

  4. Introducing a configuration-driven extension layer that determines which custom logic should run at specific stages of the workflow.

Our main goals are:

  • Keep the core workflow orchestration reusable and stable

  • Avoid introducing customer-specific branching logic inside workflows

  • Allow customers to customize behavior safely and in a controlled way

  • Maintain deterministic workflow execution and clean versioning

I’m interested in understanding what patterns others have used when building multi-tenant platforms on Temporal where workflows need to support customer-specific customization.

Specifically:

  • What are recommended patterns for workflow-level extensibility in Temporal when using a code-first approach?

  • Is it better to implement such customization through activities, task queues, Nexus, or external services?

  • Are there any known architectures or examples for building extensible workflows in a multi-tenant Temporal system?

Any guidance or real-world experience would be very helpful.

1 Like