Independent · failure-driven · Python

Build a Durable AI Agent Runtime with Temporal

Build one AgentRun, break it repeatedly, inspect Event History, and prove what survives.

Start module 1 — freeExplore the curriculum
11 modules · about 16 hoursFreeHands-on labs

An independent, failure-driven Python practicum for engineers building long-running systems and AI agents. Build one AgentRun, expose it to Worker crashes, duplicate Activity execution, nondeterminism, cancellation, long histories and code upgrades, then use Event History to explain exactly what survives.

A complementary path

Already using Temporal's official training?

Temporal's courses are the canonical place to learn the platform and SDKs. SciMigo is an independent complement: one Python agent runtime is repeatedly broken, diagnosed and repaired to develop failure-semantics and architecture reasoning.

Explore Temporal's official courses

Try the signature failure

The external effect succeeded. Then the Worker died.

Module 4 shows why durable orchestration does not make an external side effect exactly-once—and what an idempotent Activity must do when completion was never recorded.

  1. Effect succeeds
  2. Worker dies
  3. Completion is not recorded
  4. Activity retries
Try the duplicate-side-effect failure

Your Learning Path

Each module builds on the last. Open any published lesson or lab and continue at your own pace.

1

The Machine — Service, Worker, Client, Namespace, Task Queue — and where the program counter lives

How a Temporal application is split between the Service that records and the Workers that execute. You start a dev server, run one Workflow with a durable sleep, kill the Worker mid-sleep, and watch execution continue — then answer the first real question: where was the program counter stored?

Free60 minReading materialHands-on lab (local)
2

Event History and Replay — The append-only log that lets any Worker reconstruct a Workflow's state

The most important hour of the course. Event History is the durable source of truth; replay is how a fresh Worker rebuilds Workflow state from it. You read a real history in the Web UI and in JSON, map every Command to its Event, and see why a DAG engine and Temporal are not the same kind of thing.

Free90 minReading materialHands-on lab (local)
3

Determinism — What Workflow code may and may not do, taught by breaking it

Replay only works if the code makes the same decisions from the same history. You write a Workflow that flips a coin, watch the SDK throw a non-determinism error on replay, and derive the rule: Workflow = decisions, Activity = effects. Covers the sandbox, deterministic time and randomness, and side effects.

Free80 minReading materialHands-on lab (local)
4

Activities and Failure Semantics — Retries, the four timeouts, heartbeats, and why an Activity can run twice

Activities are the boundary between Workflow code and the outside world. A Worker can die after the side effect and before the completion, so Temporal may run the Activity again: assume every Activity can execute more than once — Temporal guarantees durable orchestration, not exactly-once execution of your effect. You trigger each of the four timeouts on purpose, add a heartbeat to a long Activity, and design an idempotent tool call for an LLM agent.

Free105 minReading materialHands-on lab (local)
5

Signals, Queries, and Updates — Talking to a running Workflow: asynchronous writes, reads, and tracked synchronous writes

Signals, Queries and Updates are the three ways to talk to a running Workflow Execution: an asynchronous write, a read, and a tracked synchronous write. You add pause/resume/cancel Signals, a status Query, and a change-goal Update to the agent, see how handlers interleave with the main loop, then leave it paused, kill every Worker, and resume it a day later.

Free90 minReading materialHands-on lab (local)
6

Continue-As-New and Child Workflows — Keeping history bounded and choosing the right unit of delegation

Event History is bounded, and a long-running agent loop will reach the bound. Continue-As-New checkpoints the state you pass into a fresh run under the same Workflow ID; the trigger is the Service's suggestion, not a number. You also choose, for each delegated task, between an Activity and a Child Workflow.

Free90 minReading materialHands-on lab (local)
7

Cancellation and Compensation — Retry repeats an operation; compensation undoes one that succeeded

Temporal will retry for you but it cannot know your rollback semantics. You build reserve-GPU → allocate-sandbox → start-model → register-endpoint, make the last step fail, and orchestrate the compensating steps in reverse — the Saga pattern as ordinary durable code. Then you cancel a running Workflow and see what cancellation actually does to in-flight Activities.

Free75 minReading materialHands-on lab (local)
8

Testing and Replay Tests — Unit tests, time-skipping, replaying production histories against new code

Three kinds of tests: Workflow tests in the time-skipping environment (a three-day Workflow finishes in milliseconds), Activity tests, and replay tests that take histories from production and replay them under new code to catch non-determinism before deploy. Then failure injection: Worker crash, Activity timeout, duplicate execution, cancellation.

Free90 minReading materialHands-on lab (local)
9

Deploying Changed Workflow Code — Patching and Worker Versioning: changing code that has been running for months

A Workflow started two months ago may replay against the code you deploy today. You learn both mechanisms — patching inside the code, and Worker Versioning (GA since March 2026) which pins executions to a deployment version and supports ramped rollout and rollback — and how they interact with Continue-As-New.

Free90 minReading materialHands-on lab (local)
10

Operating Temporal in Production — Task Queue lanes, Worker pools, visibility, priority — and where Temporal ends

AgentRun leaves the laptop. Task Queues become compute lanes with their own Worker pools; backlog becomes the scaling signal; Search Attributes and the UI answer what any run is doing; Priority and Fairness arbitrate which queued work reaches a shared GPU lane, while the compute platform still owns GPU placement and lifecycle. And the boundary question: Temporal decides where execution logically is — Kubernetes, Kafka and Postgres still own what they own.

Free70 minReading materialHands-on lab (local)
11

Capstone: A Durable Agent Runtime — Design and defend AgentRun — every box, every failure semantic

The final exam, and the thing you came to build. Derive the AgentRun architecture from its requirements alone — 72 hours, 1,000+ model calls, vanishing GPUs, twice-daily deploys, pause and re-instruction, sub-agents, bounded history, exact diagnostics — defend every box's failure semantics, then compare it with a real one: the course-job workflow inside the engine that rendered these slides.

Free120 minReading materialHands-on lab (local)

Built for

Who this course helps

  • Backend and AI-infrastructure engineers who have shipped services that call APIs or databases
  • Engineers who know retries and distributed systems fail—and want to cause those failures deliberately
  • Python practitioners who want failure semantics and architecture reasoning, not another happy-path SDK tour

What you leave with

A production-minded AgentRun you can explain and defend under failure

  • Reason from Event History about replay, retries and what survives a Worker crash
  • Design idempotent external effects, bounded histories and interactive long-running Workflows
  • Test failure paths and change Workflow code without breaking in-flight executions

One Python agent runtime evolves through eleven modules. Each lab introduces a failure, asks you to find the evidence, and turns the result into an architecture decision.

About This Course

Free during public beta: all eleven readings and labs, no account or payment. Built independently by SciMigo to help developers learn Temporal through failure-driven experiments — this is not official Temporal training. Found something broken or confusing? Email support@scimigo.com with the module number; beta feedback shapes the next revision.

Temporal's central idea is small: your application logic is normal code, but Temporal persists the decisions that code makes so execution can be reconstructed after failure. The Service stores an append-only Event History; Workers execute your code; Workflow code must be deterministic because the SDK may replay history to rebuild state; external I/O and side effects — HTTP, databases, LLM calls, files — belong in Activities, while Workflow code stays replay-safe and reaches for Temporal's deterministic APIs when it needs the clock or randomness.

This course does not follow the usual hello-world-to-order-processing path. The capstone is a durable agent runtime, because that is what Temporal is unusually good at: long-running execution, pause and resume, external tools, retries, checkpoints, human intervention and code upgrades. Every module adds one capability to that runtime and one failure you inject to prove it: the same program, AgentRun, grows from a one-step Workflow in module 1 to the production design you defend in module 11. The first half is the machine — history, replay, determinism, activities, messages. The second is architecture — continue-as-new, children, sagas, testing, versioning, and the final design defense. Work through it at whatever pace the labs take; they are the point, not the clock.

The labs run on a self-hosted Temporal dev server with the Python SDK. The Web UI is not an appendix: reading Event History before reading code is a skill this course drills from module 2 onward.

Course design original to SciMigo, developed from a self-study path for durable agent runtimes. Reading pages adapt Temporal's MIT-licensed documentation and Python samples (Temporal Technologies Inc.); see THIRD_PARTY_NOTICES.md. Temporal is a trademark of Temporal Technologies; this course is independent, is not official Temporal training, and is not endorsed by Temporal.

Prerequisites

  • Comfortable Python, including async/await basics
  • Have shipped a service that talked to a database or an API and had to handle retries
  • Docker installed locally (labs run a Temporal dev server in a container); no prior Temporal

What You Will Learn

  • Explain what survives a Worker crash and how replay reconstructs Workflow state from Event History
  • State the determinism rule and recognize the non-deterministic code patterns that break replay
  • Choose Activity timeouts and retry policies deliberately; design idempotent Activities that tolerate at-least-once execution
  • Make a running Workflow interactive with Signals, Queries and Updates, and say which is which
  • Bound history with Continue-As-New and choose between Activities and Child Workflows for delegated work
  • Orchestrate compensation (sagas) and reason about cancellation of in-flight Activities
  • Write Workflow, Activity and replay tests; run days-long Workflows in a time-skipping test environment
  • Deploy changed Workflow code safely with patching and Worker Versioning
  • Read a broken Workflow's history in the Web UI and answer: what happened, what did Temporal think happened, what will happen next
  • Design and defend a production agent runtime on Temporal: task-queue topology, idempotency, versioning, history bounds, observability

Terminology Mapping

How classic concepts map to the terminology used in this course.

ClassicThis Course (Python)
Workflow Definition / Type / Execution@workflow.defn class with one @workflow.run method; started by Client.start_workflow
Activity@activity.defn function, invoked via workflow.execute_activity with timeouts and a RetryPolicy
Event Historytemporal workflow show --workflow-id ... ; WorkflowHistory in temporalio.client
Signal / Query / Update@workflow.signal / @workflow.query / @workflow.update handlers; Client handle .signal() / .query() / .execute_update()
Durable Timerawait asyncio.sleep(...) inside Workflow code (the sandbox makes it durable)
Continue-As-Newworkflow.continue_as_new(args)
Child Workflowworkflow.execute_child_workflow(...)
Replay testtemporalio.worker.Replayer(...).replay_workflow(history)
Patchingworkflow.patched('id') / workflow.deprecate_patch('id')

Appendices

Reading that belongs to the course rather than to one module. None of it is required to finish the learning path above; each page says who it is for.

Appendix A1 — Task Queues and Worker Topology (long form of Module 10)Production depth — pairs with A3Reading materialAppendix A2 — Nexus and Service BoundariesOptional — advanced service boundariesReading materialAppendix A3 — Visibility, Search Attributes, and Operating from History (long form of Module 10)Recommended after Module 10Reading materialAppendix A4 — System design extension: from a Workflow to a productSystem design extensionReading materialAppendix A5 — The toolbox: patterns and edge cases the modules skippedInterview preparation — start hereReading materialAppendix A6 — Interview drill: twenty-five questionsInterview preparation — finish hereReading material

Start now

Module 1: The Machine

Service, Worker, Client, Namespace, Task Queue — and where the program counter lives. About 60 minutes. Free during public beta; no account or prior Temporal experience required.

Start module 1 — free
Course interest

Help shape what we build next

Tell us what you want to learn. This records your interest; it does not enroll you or promise a launch email.

We use your address to identify duplicate responses and your note to decide what to build next.