Scaling AI-powered education with durable workflows

The Customer#

Maria Educação is a Brazilian EdTech building an end-to-end, AI-powered education platform. Our mission is to democratize access to quality education by turning learning materials into personalized experiences for millions of public- and private-school students — “technology in favor of learning.” We serve education networks, municipalities, publishers, and non-profits, covering the full learning cycle: AI-assisted content creation, adaptive assessment, automatic grading, curriculum alignment (Brazil’s BNCC), AI tutoring, and school management. Our platform reaches 80+ municipalities and impacts 10M+ students, with a team of 38.

We have four core solutions on a single platform, which include editorial production at scale, assessments at scale, context indexing, and intelligent assistants.

Editorial production at scale provides an end-to-end AI-assisted content pipeline. Assessments at scale create a full assessment lifecycle, going from exam authoring all the way to IRT/TRI (Item Response Theory) reports. Content indexing creates an automatic alignment of resources to the BNCC national curriculum (components, grade, skills). Intelligent assistants include Lisa (LISA), our AI tutor for students, plus content-creation and grading assistants for teachers.

We serve key customers in many areas such as B2B, B2G, and non-profit. Some of them include FTD Educação, SOMOS Educação, Prefeitura de Palmas, and Instituto Alfa e Beto.

The Challenge#

Our platform runs long, multi-step AI pipelines — e.g. turning a raw PDF textbook into a fully structured, personalized course, or processing tens of thousands of answer cards and grading them with IRT. These pipelines chain dozens of LLM calls, file-processing steps, and database writes. Initially we tried to handle this asynchronous work with raw Python threads. The core problem: thread-based flows had no durability — every new deployment (which restarts the processes) broke in-flight async flows and lost their state, and thread errors were hard to debug. We briefly moved to Celery + Redis, which handled task execution but still didn’t give us durable, resumable, observable multi-step workflows. Individual steps, especially LLM and API calls, needed to retry without rerunning the entire pipeline. We also needed reliable fan-out with controlled concurrency and end-to-end visibility into each document’s progress.

We learned about Temporal through a recommendation from a friend at another company who had used Temporal in production. We decided to test it, liked it, and — because it’s a managed service we don’t have to operate ourselves — adopting it made sense. Rubens Aguiar, our CTO, was the first to start using Temporal on our team.

The criteria we used to evaluate Temporal was durable execution, first-class retry policies per step, native support for long-running work (heartbeats/timeouts) since LLM calls can be slow, controlled parallel fan-out, strong observability, a mature Python SDK, and being a fully-managed service (no cluster for us to run). The evaluation was led by Rubens Aguiar (CTO) together with the engineering team.

Before Temporal we used raw Python threads (our original approach), then briefly Celery + Redis. The most critical factor that led us to Temporal: durable execution delivered as a managed service — the ability to write a complex, stateful pipeline as ordinary code and have it survive deploys and crashes, retrying only the failed step, with full visibility, and without us operating any orchestration infrastructure. Threads lost their state on every deploy; Celery ran tasks but couldn’t give us durable, resumable, observable multi-step workflows; Temporal did — and we didn’t have to manage it.

The Solution#

Temporal orchestrates virtually every long-running/AI pipeline on the platform — roughly 100 workflows and 240+ activities across 16 task queues, plus 13 scheduled routines, running on two Temporal Cloud clusters (a main cluster and a separate isolated one, both over mTLS).

The main ones:

• LISA content ingestion: our largest pipeline: turns a raw PDF into a complete interactive course (chapters, lessons, concepts, questions, images, and simulations). An 11-stage flow that extracts and converts the document, structures it with AI, then fans out to generate resources. Each LLM call is its own activity for independent retries and observability. It can run fully automated (one long workflow that resumes from wherever it stopped) or as human-gated stages, where a curator reviews before each step advances.

• On-demand study flows: the course isn’t static: short workflows react to the student in real time — personalizing examples to the student’s interests, generating fresh questions when the question bank runs low, or producing a requested resource — often calling the media factory as a sub-workflow.
• Assessments: three durable correction flows: answer-card (OMR) reading via computer vision, AI-based correction of open/essay questions against a rubric, and IRT/TRI psychometric grading (a long-running statistical job that polls with heartbeats for up to an hour). Batch exam runs per school/class share the same queue family — thousands of exams per network without touching the grading experience.
• AI resource generation (shared “media factory”): for each image request, several sources (multiple AI models plus an approved-asset vector library) compete in parallel and an AI judge picks the winner, which is fed back into the library so the next request improves. Technical diagrams self-heal (the workflow generates code, compiles it, and fixes its own code on failure). Shared by both the student and teacher products as a sub-workflow.
• Content processing: material parsing/ingestion, question extraction and BNCC indexing, map-reduce summarization, and exports.
• User/partner management: bulk import and partner/school synchronization.

This is the architecture for our use case:

• Backend: Python (Django), Temporal Python SDK (temporalio).
• Workers run on Google Kubernetes Engine (GKE), with a general worker hosting most task queues plus dedicated workers on isolated node pools for heavier jobs (e.g. answer-card reading). Concurrency is tuned per worker/queue.
• Each business pipeline is one Workflow; each atomic unit of work (an LLM call, a DB write, an external API call, file processing) is an Activity, with its own timeout and retry policy.
• Fan-out is done with child workflows (e.g. one child per document window/chunk) and with controlled in-workflow parallelism (a concurrency cap keeps the heavy AI phase saturated without overwhelming LLM rate limits). A workflow can call another as a sub-workflow — e.g. both the student and teacher products reuse the shared media factory.
• Agent/LLM logic uses LangGraph/LangChain inside activities, keeping the Workflow code deterministic. RAG uses a vector database.
• Runs on two Temporal Cloud clusters (the main platform plus a separate isolated service), authenticated with mTLS client certificates.

We don’t have a one-workflow-per-agent design— our approach is pipeline/domain-oriented, and Temporal and LangGraph work at two different layers rather than one replacing the other. A Workflow represents an end-to-end business pipeline (course ingestion, AI correction, IRT grading, material parsing, etc.), and Activities are fine-grained steps (one per LLM/DB/API call). Temporal owns the durable, macro-level orchestration — sequencing stages, retries, fan-out, scheduling, and surviving deploys and crashes. When an agent or LLM needs its own multi-step reasoning, that logic runs as a LangGraph graph inside a single activity: because Workflow code has to stay deterministic (for replay), any non-deterministic LLM/agent work lives in an activity. So the split is consistent across the platform — Temporal is the durable orchestrator, LangGraph is the in-activity “agent brain” — and we did not replace one with the other. Larger jobs fan out into child workflows (e.g. material parsing spawns one child per window).

These are some of the most valuable Temporal capabilities we see for AI:

• Durable execution and state management: an 11-stage AI pipeline with heavy per-lesson fan-out survives crashes and picks up exactly where it left off; we never re-run an expensive LLM call that already succeeded.
• Per-activity retry policies: flaky LLM/API calls retry independently.
• Heartbeats and long timeouts: essential because a single multimodal LLM call can run for many minutes.
• Observability: we can see exactly which step every document/exam is on, and why something failed.
• Controlled fan-out: child workflows plus concurrency caps let us parallelize per-lesson/per-concept work without hitting provider rate limits.

In our case, these are the features we are using the most:

• Retry policies (used extensively, with dedicated policies per domain).
• Activity heartbeats and heartbeat timeouts for long-running LLM/polling activities (e.g. psychometric grading that polls an external job for up to an hour).
• Child workflows and sub-workflows for fan-out and for sharing pipelines across products (the media factory is called by multiple pipelines).
• Human-in-the-loop pipelines, where stages advance only after a curator approves.
• Timers (e.g. rate-limit backoff loops).
• Schedules: cron-based (recurring maintenance and notifications) and interval-based (cleanup jobs); ~13 scheduled routines in total.
• Multiple task queues / dedicated workers for workload isolation (16 task queues plus a separate isolated cluster).

We’re a lean team, and running a highly-available Temporal cluster ourselves (persistence, scaling, upgrades, backups) would pull engineers off the product. Temporal Cloud gives us production-grade durability and scale with mTLS security and no cluster ops, so the team focuses on the education product, not on operating the orchestrator.

The Results#

Temporal is core infrastructure: it lets a small team run complex, reliable AI pipelines at scale. The volume these Temporal-orchestrated pipelines have processed: 3B+ data points, 1M+ pages of content produced, 1M+ assessments processed, 3M+ questions indexed, 10B+ AI tokens. This content reaches a network of 80+ municipalities and, indirectly, millions of students. Before Temporal, this kind of long-running async work broke and lost state on nearly every deploy; now it runs durably end-to-end.

The single biggest win is reliability of asynchronous work across deployments. With our old thread-based approach, in-flight async flows broke and lost their state on essentially every new deploy; with Temporal, we have zero loss of pipeline state on deploys — work resumes automatically.

On top of that:

• Reliability: from async flows breaking on nearly every deploy → no pipeline runs lost to deploys or crashes.
• Development time: new asynchronous/AI pipelines ship faster, with far less custom orchestration/retry code to write and maintain.
• Debugging and infrastructure time: durable, observable workflows cut the time to locate and recover from a failed step, and we operate no orchestration cluster of our own.

This is how we would quantify the business value:

• Reliability: effectively no state lost on deploys, versus in-flight flows breaking on nearly every deploy under the old thread-based system.
• Engineering leverage: a lean team operates ~100 workflows / 240+ activities across 16 task queues on 2 clusters — powering AI content and assessment across a network of 80+ municipalities — without running any orchestration infrastructure of its own (fully managed via Temporal Cloud).

The clearest ROI is engineering time we never have to spend: we don’t build or operate durable orchestration in-house (no Temporal cluster to run, scale, upgrade, or back up), and we don’t maintain custom retry/scheduling/state-recovery code. That frees a lean team to focus on the education product. On LLM spend, retrying only the failed step (instead of re-running whole pipelines) avoids re-paying for expensive AI calls that already succeeded.

Our advice to other companies evaluating Temporal is to model each external/expensive call (especially LLM calls) as its own activity with a tailored retry policy from day one — you get observability and cost control for free. Keep workflow code deterministic and push agent/LLM logic into activities (we run LangGraph inside activities). Use child workflows and concurrency caps to fan out AI work without hitting provider rate limits.

We plan to expand our agentic/AI workflows on Temporal and adopt newer Temporal capabilities as we scale to more municipalities and students, deepening Temporal’s role as the backbone of our async and AI orchestration.

The Takeaways

1. Durable execution turned fragile AI pipelines into reliable infrastructure — an 11-stage PDF-to-course pipeline with heavy AI fan-out now survives failures and retries only what broke, at national scale.
2. A small team ships complex, stateful AI workflows because Temporal owns retries, scheduling, fan-out, and observability — while LangGraph handles fine-grained agent logic inside activities.
3. Temporal Cloud (mTLS, no cluster ops) let us keep engineering focus on education, not on operating an orchestrator, while powering AI content and assessment across a network of 80+ municipalities.