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

**URL:** <https://community.temporal.io/t/design-pattern-for-providing-workflow-level-customization-in-temporal-agents-built-using-a-code-first-approach/19377>\
**Category:** Developer Corner\
**Tags:** python-sdk, multi-tenant, best-practices\
**Created:** [March 6, 2026, 6:31am UTC](https://community.temporal.io/t/design-pattern-for-providing-workflow-level-customization-in-temporal-agents-built-using-a-code-first-approach/19377 "2026-03-06T06:31:02Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mandar](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/mandar/32/7428_2.png) [@Mandar](https://community.temporal.io/u/Mandar)\
**Post date:** [March 6, 2026, 6:31am UTC](https://community.temporal.io/t/design-pattern-for-providing-workflow-level-customization-in-temporal-agents-built-using-a-code-first-approach/19377/1 "2026-03-06T06:31:02Z")

</div>

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.