Substructure vs. Temporal for AI agents

Temporal is a durable execution platform. You write workflow code, it records every step, and after a crash it replays the record and picks up where it stopped. It is very good at this. It is battle-proven at enormous scale, and if your problem is "all of our long-running code needs to survive failure," it is probably the right tool.

Substructure is a different kind of thing. It is an agent engine. You describe your agents in one file and they run: in Slack, with MCP servers, streaming to your clients. And the loop is not sealed inside the engine. Point an agent at your webhook and every step of the loop is yours to build or override, so you customize as much of the agent as you care to own without building any of the infrastructure around it.

Let's be clear about one thing up front: durability is table stakes. Temporal has it. Substructure has it. Every step of a Substructure agent is saved before it runs, so a crash or a redeploy resumes where it stopped, and you should expect exactly that from anything calling itself agent infrastructure in 2026. Nobody should pick either product because "it doesn't lose work." The real question is what you have to build before your team has an agent it can actually use.

The short answer

Pick Temporal when agents are one of many durable workflows you run, when you already operate Temporal, or when you want the loop written as your own code inside their replay model. Pick Substructure when the thing you want is an agent your whole team can use: in Slack, with MCP servers, with your own tools, this week. With Substructure you start from a working agent and take over any step of its loop, or every step, without owning the infrastructure around it.

What you build

On Temporal, the agent is yours to build. Their own AI solutions page draws the line: Temporal handles failures, state, and scale, and you build the AI logic, the workflow definitions, the tool integrations, and the LLM calls. The loop, the prompts, the chat history, the chat surface, Slack, MCP. All of it is application code, written against a Temporal SDK, running in a worker fleet you operate. Their OpenAI Agents SDK integration shortens the loop part in Python: the framework runs the agent, Temporal wraps each model and tool call in an activity. Everything around the loop is still yours.

On Substructure, the agent is a file:

name = "oncall"

[llm.openrouter]
type = "openrouter"

[mcp.sentry]
url = "https://mcp.sentry.dev/mcp"

[agent.oncall]
llm = "openrouter"
model = "moonshotai/kimi-k3"
system = "You are the on-call assistant."
mcp = ["sentry"]

[slack]
mentions = "oncall"

Run subs apply and the bot answers in Slack. The engine authorizes the Sentry connection, fetches its tools, and runs every call. Your code never holds a token.

Think of that file as a default agent, because that is what it is. When you want control, add a worker URL and the engine sends every decision in the loop to your endpoint as JSON. Return the proposal to accept it. Or rewrite the prompt, swap the model mid-conversation, run the tool inside your own system, pause for a person. You can override every single step of the loop, which is more control than most agent SDKs hand you. And your side of it is just a function: the engine sends each decision in with the state it needs, your code sends the decision back, and the engine persists whatever you return. Nothing to keep alive, nothing to store, nothing to scale. That is the whole programming model, in any language, against operating a worker fleet on a task queue with an SDK inside it.

The determinism tax

Temporal's replay model comes with a rule: workflow code must be deterministic. No clocks, no randomness, no direct I/O in the workflow. Anything non-deterministic moves into activities, and the Python SDK sandboxes your code to enforce it. Changing workflow code while executions are running is a versioning event you manage with patching or worker versioning. If your agent loop is workflow code, every edit while conversations are open is a deploy you have to reason about.

Substructure keeps the loop inside the engine, so your code never carries a replay contract. Your worker is a stateless HTTP endpoint. Deploy it whenever you like, in whatever language you like.

Streaming and clients

Token streaming reached Temporal in June 2026 as Workflow Streams, in public preview for Python and TypeScript. The chat surface on top is still yours to build.

Substructure speaks AG-UI natively, so assistant-ui, CopilotKit, and other AG-UI clients drive the same agents that answer in Slack. Conversations live in the engine too: history, editing, regeneration, branching. You do not build a chat backend.

Running it

Self-hosted Temporal is a four-service cluster over Cassandra, MySQL, or PostgreSQL, with Elasticsearch or OpenSearch recommended for visibility once load is real. Plus your worker fleet. Temporal Cloud removes the cluster and meters Actions at $50 per million. Every activity, retry, timer, signal, and query bills, and an agent loop is chatty by nature, so the bill scales with how much your agents think.

Substructure self-hosted is one Rust binary and a SQLite file, the same engine the CLI runs on your laptop, open source. The hosted version is one flat price a month with no per-step or per-token metering. The honest caveat runs the other way: Temporal's architecture is proven at Netflix-and-Stripe scale, and a single-binary engine is not aiming at that ceiling.

Where Temporal is the right call

Temporal has close to a decade of production hardening, eight official SDKs, enterprise SLAs, and customers running coding agents at very large scale. If you need one platform for payments, provisioning, ETL, and agents, use it, and reach for their agent-framework integrations to shorten the build.

But if what you want is agents your team can use, without months of building agent infrastructure first, that is exactly what Substructure is for. The quick start takes about five minutes.