A provider-neutral logical reference architecture for assigning specialist model workers on demand - with Temporal-backed workflow durability, explicit policy controls, and evidence-based completion criteria.
This logical component and runtime-flow view separates organization policy, durable orchestration, model access, governed tools, and evidence. It is not a deployment diagram or security proof. Arrowheads show the initiating direction; responses return on the same integration path unless separately drawn.
This deployment and dynamic view applies the components from View 01 to a hybrid execution topology. The organization and durable control plane persist; specialist Activity Workers, regional gateways, inference endpoints, and tool capacity can scale independently where policy and cold-start requirements permit.
The organization definition is a versioned application artifact. Each objective can create a temporary set of specialist worker nodes operating under explicit policy; this behavior is implemented by the application graph rather than supplied automatically by any one platform.
A versioned YAML, TOML, or equivalent application schema can define roles, authority, model policy, assignment rules, budgets, and typed work contracts. This schema is an architectural design choice - not a LangGraph or Temporal standard.
Temporal Service persists Workflow Event History and coordinates timers, Task Queues, retries, and Signals. External calls execute as Activities; write Activities must be designed for idempotent retry or explicit compensation.
A LangGraph application graph can implement planning, conditional routing, dynamic fan-out through the Send API, merging, and completion gates. Those behaviors come from application nodes and edges, not from an autonomous built-in organization.
Specialists are selected through application policy. Prefer deterministic checks first; where an LLM judges another model, an independently chosen model family can reduce - but cannot eliminate - self- and family-preference risk.
LiteLLM can provide a common provider interface plus gateway authentication, authorization, routing, fallback, rate limits, spend tracking, and budgets. A custom capability registry preserves model-specific constraints rather than pretending all models are equivalent.
An MCP host creates clients that communicate with focused servers and must enforce consent and security policy. Git worktrees separate working directories and branches; they are not security sandboxes. Use containers or equivalent process isolation for untrusted execution.
Temporal owns durable Workflow Event History. PostgreSQL and artifact storage are optional application choices for cross-run state and retained evidence; they do not replace Temporal durability or a LangGraph checkpointer within the official integration.
Completion policy can combine deterministic tests, evidence requirements, model-based review, and human approval. OpenTelemetry instrumentation emits and propagates telemetry; an external observability backend stores, queries, and visualizes it.
Temporal Task Queues are durable demand buffers polled by one or more Worker processes. Separating Architect, Research, Builder, and Critic Activity work into capability-oriented queues is an application design choice that enables independent routing, throttling, and fleet scaling.
Activity Worker replicas can scale independently from the Temporal Service and the small control-Worker pool. Replica count, task slots, and poller count are separate controls; scale from backlog and schedule-to-start latency while respecting downstream provider quotas.
A custom placement controller can combine capability, residency, security, latency, cost, quota, and cold-start policy to select eligible on-premises or cloud execution cells. Temporal and LangGraph do not provide this multi-cloud placement policy automatically.
Workers should stop accepting new work, finish or safely abandon in-flight Activities, and drain before infrastructure termination. Scale-to-zero is appropriate only when startup latency is acceptable; slow model loading and privileged workloads may require a configured warm minimum.
Platform capabilities, deployment boundaries, and cloud scaling mechanisms were checked against current first-party documentation on 5 September 2026. The organization schema, capability queues, placement controller, completion policy, agent-role taxonomy, and combined operating model are explicitly identified as architectural design choices. Research evidence is labeled separately and does not constitute a platform guarantee.
StateGraph provides explicit state and controlled graph transitions; its Send API supports dynamically created worker nodes for orchestrator-worker flows.
Worker pattern ↗The official integration is Python and Public Preview. Each graph node or task must declare Workflow or Activity execution; LLM, network, database, and file I/O run as Activities.
Integration guide ↗Temporal persists application state and supplies Workflow Event History, Task Queues, timers, Signals, and retry coordination so executions can resume after infrastructure failure.
Platform docs ↗Activities contain failure-prone or nondeterministic operations. Temporal recommends idempotency because an Activity can execute more than once before completion is recorded.
Activity semantics ↗The gateway supports a common multi-provider interface, authentication and authorization, routing, fallback, rate limits, spend tracking, and budgets. Its current provider catalog includes Bedrock, SageMaker, Azure OpenAI, Azure AI, and Vertex AI.
Provider catalog ↗MCP retains a host-client-server architecture but now has a stateless protocol core: each request carries its version and client capabilities.
Architecture spec ↗Servers validate inputs and enforce access controls; clients confirm sensitive operations, validate results, apply timeouts, and log tool use. These are implementation duties, not automatic protocol guarantees.
Tool security ↗Worktrees provide multiple working trees attached to one shared repository. The documented mechanism separates Git working state; process and security isolation require another control.
Git manual ↗OpenTelemetry generates, collects, and exports traces, metrics, and logs. It is not an observability backend; storage and visualization belong to other tools.
OTel overview ↗Current research reports self- and same-family preference in LLM judges. Independent judges and deterministic checks mitigate risk but do not prove correctness.
Bias study ↗C4 distinguishes the software system in scope from external systems and reserves deployment details for deployment diagrams. This page therefore labels its view and external dependencies explicitly.
C4 guidance ↗Task Queues are lightweight and created on demand. Workers poll when they have capacity; Workflow and Activity Tasks persist when Workers are unavailable, and queues load-balance work across Worker processes.
Task Queue semantics ↗Temporal distinguishes Worker replicas, task slots, and pollers. Current guidance covers backlog metrics, resource-based slot suppliers, and poller autoscaling for managing Worker fleet throughput.
Worker performance ↗Temporal Cloud manages Temporal Server capabilities but does not run customer applications or Workers. Worker programs execute in customer-controlled containers, Kubernetes clusters, virtual machines, or other hosting environments.
Cloud security model ↗AWS documents event-driven scaling on EKS with custom metrics and KEDA, including GPU inference scaling from queue depth and latency. Node capacity can scale through EKS Auto Mode, Karpenter, or Cluster Autoscaler.
EKS AI autoscaling ↗AKS supports pod, node, and event-driven scaling through HPA, cluster autoscaling, node autoprovisioning, and KEDA. KEDA is the relevant mechanism when an external backlog should activate workloads or permit scale-to-zero.
AKS scaling overview ↗GKE can scale workloads from custom, Prometheus, or external metrics. Google documents queue backlog as an example signal for increasing replicas while work accumulates and reducing them as demand falls.
GKE metric autoscaling ↗