Multi-Agent Workflows Preview
These walkthroughs describe a validated internal setup currently in use at Booz Allen. The two baselines they reference (temporal-workflow-worker-starter, temporal-workflow-api-starter) are undergoing final hardening prior to open-source release. Until those repositories are publicly available, links in this section point to internal sources. The strands-base-agent baseline is already publicly available.
Coordinate multiple Foundry agents with Temporal for durable, long-running workflows with human-in-the-loop steps.
Walkthroughs
This section is three stacked guides. Start at the top.
- Getting started — Stand up the full local stack: Temporal Server, the workflow worker (with a mock agent), and the workflow API. Confirm everything talks end-to-end before adding a real LLM.
- Swap in a real agent — Replace the mock agent with the Foundry Strands Base Agent (AWS Bedrock). Same workflow, real LLM responses.
- Loops & advanced workflows — Build a multi-phase research workflow with human-in-the-loop feedback loops, iteration tracking, and signal/query handlers.
What you'll have at the end
Four services running together:
| Service | URL | Description |
|---|---|---|
| Temporal Server | http://localhost:8080 (UI), localhost:7233 (gRPC) | Open-source Temporal orchestration engine |
| Workflow Worker | — (no exposed port) | Executes workflows and activities; talks to Temporal |
| Workflow API | http://localhost:8000 | FastAPI gateway for starting/managing workflows |
| Strands Base Agent | http://localhost:8081 | Real LLM-backed A2A agent (swapped in at step 2) |
Why Temporal?
Temporal was selected over AWS Step Functions, LangGraph, Kafka+Airflow, LlamaIndex Workflows, and Microsoft Agent Framework. Reasons:
- Cloud-agnostic — deploys to any Kubernetes cluster, no vendor lock-in
- Proven at scale — used in production by Replit, Netflix, DoorDash
- Architecture alignment — orchestrates independent HTTP services rather than embedding agent logic
- Native HIL — pause/resume semantics are first-class, not bolted on
Foundry pairs Temporal with A2A so the workflow worker stays a thin orchestrator — agent intelligence lives behind A2A, the worker only manages state, timing, retries, and human interactions.
Architecture at a glance
Three baselines collaborate:
- Strands Base Agent (available) — provides each agent behind A2A
- Temporal Workflow Worker Starter (preview) — runs workflows, calls agents via A2A activities, manages HIL state
- Temporal Workflow API Starter (preview) — REST gateway for starting, signaling, and querying workflows
Key concepts
A quick refresher — see the glossary for full definitions.
- Workflows define orchestration logic and must be deterministic.
- Activities perform side effects like A2A calls to agents — non-deterministic is fine.
- Signals send commands to a running workflow (e.g., "approve this plan").
- Queries read workflow state without modifying it (e.g., "what phase is this in?").
All A2A agent calls happen in Activities, never directly in Workflows.
Reference configuration
Shape is stable; defaults will be finalized at OSS release.
| Variable | Description |
|---|---|
TEMPORAL_HOST | Temporal server address |
TEMPORAL_NAMESPACE | Temporal namespace |
TASK_QUEUE | Worker task queue |
DEFAULT_AGENT_URL | Default agent A2A endpoint |
AGENT_TIMEOUT_SECONDS | Per-agent call timeout |
HIL_TIMEOUT_HOURS | Human-in-the-loop approval window |
See also
- Strands Base Agent — the agent baseline these guides build on
- Temporal Workflow Worker Starter — preview baseline (worker)
- Temporal Workflow API Starter — preview baseline (API gateway)