Understand built-in workflows

Built-in workflows are system-managed workflows that handle internal operations such as document conversion and agent execution.

Unlike user-created workflows, built-in workflows use durable execution on a dedicated task queue. If a pod crashes or restarts during a background operation, the system automatically retries the workflow from its last checkpoint. This replaces earlier background processing that could not retry failed operations and ensures that no work is silently lost.

How built-in workflows differ from user workflows

Built-in workflows share the same execution engine as your workflows, but the system manages them separately.

Read-only: You cannot edit, delete, or disable a built-in workflow. If you open one in the workflow builder, it displays in read-only mode with a banner indicating that you cannot modify it.
Dedicated task queue: Built-in workflows execute on a dedicated task queue, separate from user workflow executions. This isolation prevents long-running background operations from competing with your workflows for worker resources.
System-managed lifecycle: The system creates built-in workflows during deployment and updates them automatically. They belong to a dedicated built-in project and do not appear in the default workflow list.
Retry and durability: The system defines a retry policy and timeout for each built-in workflow. The execution engine persists workflow state, so operations survive pod restarts and infrastructure disruptions.

Built-in workflow types

Automation orchestrator includes the following built-in workflows:

Document Conversion: Converts uploaded files to formats that AI agents can process. Runs automatically when you upload context files to an AI Agent step.
Agent Execution: Orchestrates AI agent interactions with large language model (LLM) providers and tools. Runs when a workflow reaches an AI Agent step during execution.

Visibility and access control

Only administrators can view built-in workflows. The system scopes them to a dedicated built-in project and filters them from the All Projects view on the Workflows page.

When you select the built-in project from the Project list, built-in workflows display a Built-in badge to indicate that they are read-only.

Regular users cannot view or access built-in workflows.

Background worker scaling

Built-in workflows run on dedicated background worker pods that the operator deploys separately from the pods that handle user workflows. Administrators can configure scaling behavior for these workers through the AutomationOrchestrator custom resource (CR).

Background workers handle I/O-bound operations such as document conversion and large language model (LLM) calls. Consider the following when you configure scaling:

Start with a small replica range: A minimum of one or two replicas is sufficient for most deployments. The Horizontal Pod Autoscaler (HPA) adds replicas automatically when CPU utilization exceeds the target threshold.
Monitor the queue depth metric: The orchestrator_temporal_queue_depth Prometheus gauge reports the number of pending tasks per queue. Filter by the background worker task queue to monitor load. For details, see Understand Prometheus metrics in automation orchestrator.