Part 3 - Orchestrating Agents with Mastra Workflows (Why I Stopped Using Temporal)

---

---

We’re entering a new phase of software architecture — one where programs don’t just execute logic, they reason. And when software reasons, “control flow” becomes heavily dependent on “context flow”. That’s why orchestration is now one of the most important layers in AI systems: the ability to coordinate multiple agents, track state, manage memory, retry intelligently, and involve humans at the right time… that’s where the magic actually lives.

For a long time I leaned on Temporal for workflow orchestration. It’s rock-solid, battle-tested, used at scale for microservices and distributed systems. But once I moved deeper into agentic systems — where conversation matters, context evolves, memory accumulates, and agents don’t just call services but reason about them — Temporal started feeling like trying to conduct a jazz band with a traditional orchestral conductor: powerful, but mis-suited to the rhythm.

So I made a shift. I adopted Mastra Workflows. And it changed everything.

---

Why Temporal Didn’t Fit the Agentic Model

Let’s start by being fair: Temporal is engineered for purpose-built workloads in distributed systems. In Temporal “Workflow Definition” is the code that defines a workflow — a sequence of steps executed in code, which is durable, scalable and scalable.

These features make Temporal phenomenally suited for microservice orchestration, financial transactions, and any system where determinism and exact recovery are paramount.

However, agentic systems are not simply microservices orchestration. They are:

• Conversational, evolving with context.

• Memory-driven (not just stateless flows).

• Non-deterministic (LLM responses, branching logic).

• Interactive with human-in-the-loop.

• Stateful in semantic and episodic ways.

Temporal tries to force determinism in a domain where intentional non-determinism exists. In agentic AI we often need emergent behaviour, evolving context, multiple agents with overlapping memory — things Temporal handles less elegantly.

I found myself building a deterministic layer to drive a non-deterministic intelligence layer. That’s double orchestration. It slowed down prototyping, made memory integrations awkward, and made branching for human feedback painful.

In short: Temporal is brilliant for what it’s built for. But for agentic workflows, I needed something built for context, memory, and evolving logic — not just durable task orchestration.

---

Enter Mastra Workflows

Mastra is a TypeScript-native framework for building agentic applications. Workflows in Mastra help’s orchestrate complex sequences of operations with features like branching, parallel execution, resource suspension, and more.

In short: Mastra treats agents, tools, and workflows as first-class primitives. It was designed for agentic systems from the ground up. Here are some of the immediate things I loved:

• Native agent orchestration: Agents + tools + workflows are unified primitives.

• Thread-aware memory / context pipelines: workflows integrate with memory stores and shared threads.

• Integrated semantic recall: agents can access memory stores, vectors, and retrieval as part of workflow definitions.

• Non-deterministic logic supported: Not everything has to be “exact same every time”.

• Human-in-the-loop support: Built-in mechanisms for suspension/resume allow approvals, external inputs.

• Developer experience: Less boilerplate, more cognitive focus.

Here’s how Mastra describes the value: “Define an execution graph of agents and tool calls. Suspend for human review. Re-use steps and workflows.” To me, this feels like Temporal + Replay + LangGraph + Vector memory, but designed for AI engineers instead of backend SREs.

---

The Architecture Shift I Made

Before (with Temporal)

• I had a Temporal Worker, queue, and activities.

• Separately I managed memory stores (Redis, vectors, etc).

• I had to explicitly manage context propagation, state snapshots, branching for human approvals.

• Retry/fault logic via Temporal was solid but built for tasks, not for “agent reasoning loops”.

• Evolution of context required custom plumbing.

• Onboarding new agent types or new workflows was heavy.

Now (with Mastra)

• My orchestration layer is a Mastra Workflow definition.

• Shared memory thread or resource ID passes context seamlessly between steps.

• Agents embedded in steps each know about memory context automatically.

• Human approval or external event support via built-in suspend/resume is straightforward.

• Less friction in branching, loops, mistakes, dynamic flows.

• Faster prototyping of new agent workflows.

In short: I’m no longer orchestrating machines, I’m coordinating thinking processes. Huge difference.

---

Real Example: Infrastructure Flow in Our Platform

Here is a case study from our platform (Flurit) showing how we use Mastra to build a multi-agent infrastructure flow.

Goal: Convert user goal → architecture diagram → Terraform code → plan → apply.

Workflow (conceptual):

const deployAppWorkflow = defineWorkflow({
  id: “deploy-app”,
  steps: [
    plannerAgentStep(),
    architectureAgentStep(),
    terraformAgentStep(),
    validationAgentStep(),
    deploymentAgentStep(),
  ],
  memoryThread: “project-1234”,
});

Flow Explanation:

• The plannerAgent interacts with the user, determines requirements, stores those in memory.

• The architectureAgent reads memory (past infra decisions, cost constraints) and produces a diagram + spec.

• The terraformAgent generates IaC code based on spec + memory, puts it into a repo.

• The validationAgent runs checks, looks at logs, consults memory for past failures, retries or proposes corrective actions.

• The deploymentAgent applies the code, records output in memory for future recall.

Key advantages of using Mastra here:

• Shared memory thread means each agent sees prior context (decisions, constraints, outcomes) automatically.

• If deployment fails, memory logs cause the validationAgent to reason about past outcome and propose corrective action — this loop is smooth.

• Workflow suspension for human approval (e.g., cost increases) is built-in, easier than a custom solution.

• Because the logic is memory-aware, we avoid repeating steps, redundant decisions, or misalignment.

Contrast if this were on Temporal: I’d still need to wire memory stores and context propagation manually between activities, implement branching/human approval logic manually, manage the complexity of memory-driven reasoning across steps. That slows innovation and iteration of workflows.

---

Where Mastra Workflows Shine (and Where to Be Cautious)

Where they shine:

• Multi-agent pipelines where context matters.

• Stateful, iterative flows where previous steps influence next.

• Systems where user/agent interaction, memory, and branching are core.

• AI-native product experiences (you’re coordinating reasoning, not just tasks).

• When developer velocity is more important than strict determinism.

Where caution is needed:

• If you need ultra-high deterministic replay (Temporal still leads here).

• If you’re orchestrating heavy-duty legacy microservices and tasks with simple semantics.

• If your team has strong investment in Temporal and needs full enterprise-grade guarantees.

In essence:

• Temporal = perfect for deterministic, durable business workflows.

• Mastra = ideal for reasoning workflows that embed agents, memory, context, human-in-loop.

---

What I Learned Switching from Temporal to Mastra

Here are the key lessons I gained:

• Memory is the orchestration fabric. In traditional workflows you orchestrate tasks. In agentic workflows you orchestrate knowledge + memory + decision loops.

• Context drives the next step. Agents must know “what happened before” not just execute what you tell them. With Mastra, the workflow and memory synergy makes context propagation seamless.

• Developer velocity matters. Prototyping new agent workflows in Temporal required boilerplate, whereas in Mastra you iterate faster with less friction.

• Hand-off between agents must be natural. In Mastra you can use shared threadId or resourceId patterns so context flows cleanly between steps, avoiding custom plumbing.

• Human-in-loop must be a first-class citizen. Suspension and resumption for human approvals are built-in in Mastra, making branching for human input much easier.

---

How to Get Started with Mastra Workflows (Mini-Tutorial)

Here’s a quick guide (in a TypeScript ecosystem) to get started with Mastra workflows for agentic orchestration:

Install & scaffold

npm create mastra@latest

Mastra is a TypeScript framework for agentic apps.

Define a simple workflow

import { createWorkflow, createStep } from “@mastra/core/workflows”;

const step1 = createStep({
  id: “greet”,
  inputSchema: z.object({ name: z.string() }),
  outputSchema: z.object({ greeting: z.string() }),
  execute: async ({ inputData }) => ({
    greeting: `Hello, ${inputData.name}!`
  }),
});

export const greetingWorkflow = createWorkflow({
  id: “greet-user”,
  steps: [step1],
}).commit();

Add an agent call

import { Agent } from “@mastra/core/agent”;

const chatAgent = new Agent({
  name: “chatAgent”,
  instructions: `Respond to users conversationally.`,
  model: openai(”gpt-4o-mini”),
});

const step2 = createStep({
  id: “chat”,
  inputSchema: z.object({ prompt: z.string() }),
  outputSchema: z.object({ response: z.string() }),
  execute: async ({ inputData, mastra }) => {
    const resp = await chatAgent.generate(inputData.prompt, {
      memory: {
        thread: “thread-001”,
        resource: “res-001”,
      },
    });
    return { response: resp };
  },
});

const chatWorkflow = createWorkflow({
  id: “chat-flow”,
  steps: [step2],
}).commit();

Suspend & resume for human input

const stepApprove = createStep({
  id: “approve”,
  inputSchema: z.object({ confirm: z.boolean() }),
  resumeSchema: z.object({ confirm: z.boolean() }),
  outputSchema: z.object({ ok: z.boolean() }),
  execute: async ({ resumeData, suspend }) => {
    const { confirm } = resumeData ?? {};
    if (!confirm) {
      return await suspend({ reason: “User must approve to continue” });
    }
    return { ok: true };
  },
});

const approvalWorkflow = createWorkflow({
  id: “approval”,
  steps: [stepApprove],
}).commit();

This rapid development flow would have been much harder in traditional orchestrators optimized for durable service tasks, rather than reasoning flows.

---

Where This Series Goes Next

We’ve now covered:

• Part 1: Why Memory & Context Matter

• Part 2: Architecting Context Pipelines with Mastra

• Part 3 (this): Orchestrating Agents with Mastra Workflows

Next up: Part 4 — Memory as Glue: Context Propagation Across Agents
In that post we’ll dive into how memory enables coordination between multiple agents (planner → diagram → provisioning → monitoring), how you share memory threads, how you summarise and prune memory, and how you debug “what did each agent know” in a production system.

If you’re building agentic systems (especially for DevOps, multi-agent platforms, or memory-rich workflows) this series will walk you through real patterns and design decisions I’ve made while building our own platform.

Join the Flurit AI early access — AI powered DeOps Platform

Closing Thought

Traditional orchestration engines assumed you’re orchestrating machines — defined tasks, states, responses.
Agentic orchestration assumes you’re coordinating minds — knowledge, memory, evolving context, branching intent.

Different world. Different architecture. Different tools.

And frankly — it’s fun again.