What the MCP + Durable Execution Stack Actually Looks Like in Practice

You've read the docs. You've seen the diagrams. You've maybe even cloned a demo repo that uses MCP and Inngest separately. But when you try to actually put the two together for a real agent workflow — one that calls tools, handles retries, survives crashes, and doesn't explode if a tool times out on step 3 of 7 — that's where most developers hit a wall.

The gap between "MCP + durable execution" as a concept and as a working production stack is where most agent builds die.

This article closes that gap. Here's what the MCP + durable execution stack actually looks like when it's built right — and how to get there without spending weeks wiring things together yourself.

The Problem: Two Good Things That Don't Auto-Magically Combine

MCP and durable execution are both solving real problems. MCP standardizes how agents talk to tools. Durable execution (via Inngest or Temporal) makes sure that when something breaks mid-workflow, the agent doesn't lose progress — it checkpoints and resumes.

Individually, both are solid. Together? That's where it gets interesting.

Here's what actually happens when most developers try to combine them:

Step 1: You wire up MCP. Your agent can call tools via the standard JSON-RPC interface. Great. It works in your local test.

Step 2: You add Inngest for durability. You wrap your agent loop in steps. Each step calls the LLM, gets a tool call, executes it. You add retries.

Step 3: Something breaks in production. Maybe the LLM returns a tool call your MCP server doesn't recognize. Maybe a tool call times out. Maybe the process crashes entirely because your agent loop is running in-memory and your server restarted.

Step 4: You spend two weeks debugging what should have just... worked.

The problem isn't either technology. It's the integration layer between them — the part that nobody writes blog posts about because it's all glue code and edge cases.

What actually breaks

• Tool call schema mismatches — MCP enforces structured inputs/outputs, but your LLM prompt doesn't always generate them correctly on the first try
• Mid-loop crashes — If your agent loop is running as a long-lived process and your server restarts, you lose everything unless each step is checkpointed
• Silent tool timeouts — A tool call hangs for 30 seconds and your entire workflow blocks or fails with no visibility into which step died
• LLM non-determinism — The same input can produce different tool call sequences; without step-level retry, you can't isolate which call actually failed
• Sub-agent orchestration — Once your workflow spawns a sub-agent (one agent handing off to another), you need both MCP for tool access AND durable execution across agent boundaries

This is the gap. MCP gives you the tool interface. Durable execution gives you reliability. But you still need the layer that makes them work as a single system.

The Stack That Actually Works

Here's what the MCP + durable execution stack looks like when it's built right — and specifically how it works in LotsAgent.

Layer 1: MCP as the tool communication layer

MCP handles the protocol. You connect your agent to any tool via the standard MCP interface — Gmail, GitHub, Google Calendar, a custom API. The agent doesn't care what the tool is. It sends a JSON-RPC request, gets a structured response back.

This is meaningful because it means you're not writing custom tool wrappers for every integration. The protocol is the abstraction. Connect once, use everywhere.

In LotsAgent specifically, you get access to [INTERNAL LINK: topic] through the MCP server — tools are available the same way regardless of whether you're triggering them from an email, a webhook, or a scheduled task.

Layer 2: Inngest-powered durable execution as the reliability layer

Each agent action — every LLM call, every tool call — becomes a step. Steps are independently checkpointed. If a tool call fails, only that step retries. Everything before it is preserved.

This is the part that actually matters in production. Here's what it looks like in practice:

Agent loop: 
  Step 1 → Retrieve task context (checkpoint)
  Step 2 → Reason about what to do (checkpoint)  
  Step 3 → Call MCP tool (this is where things fail)
           → If it fails: retry this step only
           → If it times out: retry with timeout handling
           → If it returns unexpected schema: handle gracefully
  Step 4 → Store result, continue (checkpoint)

Each step has its own retry logic, timeout configuration, and observable output. You can inspect exactly what happened at step 3 without re-running steps 1 and 2.

The Inngest blog on agent harnesses puts it well: "Every LLM call or tool call becomes a step — an independently retryable unit of work." That's the model. It's clean, debuggable, and it survives production.

Layer 3: Subagent orchestration for complex workflows

When a workflow is too complex for a single agent, you split it across subagents. One agent handles classification, another handles research, another handles drafting. Each subagent runs as its own durable function — with its own retries, its own step history, its own MCP connections.

The parent agent just sees a tool result: "here's what the research agent found." No shared memory corruption, no cascade failures. [INTERNAL LINK: topic] shows this pattern in the context of agent-to-agent handoffs and why checkpointing across subagent boundaries is the difference between a workflow that works in demos and one that survives the real world.

What This Prevents in Production

Once you have MCP + durable execution working together as a stack, a specific class of production failures simply stops happening:

Lost progress on crashes — If your server restarts mid-workflow, the agent resumes from the last checkpoint, not from scratch. This is the baseline expectation for any production system, but it's shockingly rare in agent builds that don't use durable execution.

Tool call cascade failures — One tool times out, retries independently, and the rest of the workflow continues. Without this, a single bad tool call can corrupt the entire agent state.

Context window waste — Because each step is independently checkpointed, you don't re-send full context to the LLM on every retry. You replay only the state needed. This matters at scale when token costs add up fast.

Debugging without replay — Every step is observable. You can inspect what the agent did at step 3, why the MCP call failed, what the tool returned. You don't have to guess — you have a trace.

The LotsAgent Angle

Here's the thing: you can build this stack yourself. You'll need to configure Inngest (or Temporal), set up MCP servers for every tool you want to connect, handle retry logic for each step, and make sure your agent loop survives crashes.

You'll also need to manage the infrastructure. The queue, the workers, the event routing, the observability layer.

LotsAgent ships this as a single system. MCP is the tool interface. Inngest is the execution engine. Every agent you build gets durable execution by default — not as an add-on, not as a premium feature. You describe what you want your agent to do. It calls tools via MCP. Steps are checkpointed and retry automatically. If something fails, you can see exactly what happened and why.

You don't wire together a reliability stack. You just build an agent and it runs reliably.

The MCP + durable execution stack isn't a unique combination LotsAgent invented — both technologies are open standards. But the combination as a default, out-of-the-box experience — where the tool protocol and the reliability layer are the same system — that's what makes it different from building this yourself or using a framework that only gives you one half of the equation.

The Practical Workflow

Enough theory. Here's what this actually looks like when you're building with LotsAgent:

1. You describe your agent. "I want an agent that reads incoming lead emails, enriches them with company data from a connected tool, and drafts a reply for my review."

2. The Agent Builder configures it. Memory, tools, and the agent logic are set up automatically. MCP tools are available from the start — no manual server setup.

3. The workflow runs durably. When the agent executes: it retrieves context (checkpoint), reasons about the lead (checkpoint), calls the enrichment tool via MCP (checkpoint, with independent retry), drafts the reply (checkpoint). If anything fails, only the failing step retries.

4. You see exactly what happened. Every step is visible in the execution trace. Tool call inputs, outputs, retry attempts, errors.

This isn't a simplified demo scenario. This is a real production workflow that runs without you watching it.

FAQ

What's the difference between MCP and a regular API integration for tools?

MCP is a standardized protocol for tool communication — it's "USB-C for AI agents," as the MCP spec describes it. Instead of writing custom code for every tool's API, you connect via MCP and the interface is consistent. API integrations are typically custom per tool. MCP is a universal layer on top.

Why does durable execution matter specifically for AI agents?

Because AI agents are non-deterministic in ways traditional software isn't. An LLM call can fail, return unexpected output, or generate a tool call your system doesn't handle. Durable execution means each of these uncertain steps is isolated and retryable — so one bad LLM response doesn't corrupt your entire workflow or lose all prior progress.

Can I use MCP with Inngest directly?

Yes. Inngest has native MCP support — the Inngest dev server exposes MCP tools you can use to test and monitor durable functions. For production, you'd wrap your MCP tool calls in Inngest steps to get checkpoint/retry behavior.

How does LotsAgent handle MCP differently from building this myself?

LotsAgent runs MCP and Inngest as a single integrated system. You don't configure the connection between them — it's the default execution model for every agent. MCP gives you the tool interface. Inngest gives you the durability. They're not two things you're wiring together; they're one platform.

What happens if a tool call returns a schema the agent doesn't expect?

MCP enforces structured inputs and outputs, which catches schema mismatches before execution. If the LLM generates a tool call with incorrect parameters, the MCP layer validates it and returns an error — which the durable execution layer then retries with appropriate error context. This prevents the silent data corruption that happens when bad tool call output flows downstream.

See the API reference → https://lotsagent.com/docs/api

If you're building agents that need to run reliably in production — not just in demos — the MCP + durable execution stack is the foundation. LotsAgent gives you that foundation without requiring you to build it.