Substructure vs. Temporal for AI agents

Temporal is for teams whose whole system needs to survive failure: you write workflow code, it records every step, and after a crash it replays the record and continues. Substructure is for teams who want the agent: config in git, running in Slack, with every step of the loop open to your code.

Both save every step. The question is what you build before your team has an agent it can use.

Use Temporal when	Use Substructure when
Agents are one of many durable workflows	The agent is the product
You already operate Temporal	You do not want a cluster or a worker fleet
The loop should be your own code	You want to own some steps, not the platform

What Substructure does that Temporal does not

Gives you the agent. Temporal's own AI solutions page draws the line: they handle failures, state, and scale, and you build the AI logic, the workflow definitions, the tool integrations, and the model calls.
Answers in Slack from the config file. On Temporal, the chat surface is yours.
Puts no rules on your code. Workflow code must be deterministic: no clocks, no randomness, no direct I/O, and the Python SDK sandboxes your code to enforce it.
Deploys whenever you like. Changing workflow code during open executions is a versioning event you manage with patching or worker versioning.
Charges nothing per step. Temporal Cloud meters Actions at $50 per million: every activity, retry, timer, signal, and query. An agent loop is chatty.

Side by side

Building the agent

	Temporal	Substructure
What you get	Durable execution	A running agent
The agent loop	You write it	The engine runs it
Your code	Workflows and activities in an SDK	A stateless HTTP endpoint
Constraint on your code	Must be deterministic	None
Language	Eight official SDKs	Any language, over HTTP

Running it

	Temporal	Substructure
Durability	Replay from an event history	Every step, before it runs
Deploying a change	Patching or worker versioning	Deploy when you like
Self-host	Four services plus a database, and a worker fleet	One binary and SQLite
Proven scale	Very large	Not aiming at that ceiling

Surfaces and price

	Temporal	Substructure
Slack	Yours to build	One command
Chat history	Yours to build	In the engine
Streaming	Workflow Streams, in preview	AG-UI, native
MCP auth	Yours	The engine's
Price	Metered Actions	Flat, bring your own key

What you write

workflow.py

@workflow.defn
class OnCall:
    @workflow.run
    async def run(self, question: str) -> str:
        return await workflow.execute_activity(
            call_model, question, start_to_close_timeout=timedelta(minutes=5)
        )

subs.toml

[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"]

[agent.oncall.slack]
name = "Oncall"

The workflow is one activity of an agent you still have to build. The file is the whole agent: subs apply, and it answers in Slack.

Where Temporal is the better choice

Close to a decade of production hardening, at a scale a single-binary engine is not aiming at.
Eight official SDKs and enterprise SLAs.
One platform for payments, provisioning, ETL, and agents together.
Full control of the loop as your own code, if that is what you want.

Questions

Is Substructure durable enough? Every trigger, decision, and call is saved before it runs, and a restarted engine continues from the last step.

Can I keep Temporal underneath? Yes. A worker can start a Temporal workflow for the parts that need it.

What happens when I redeploy my code? Nothing. Your worker holds no state between calls, so there is no versioning event.

The quick start takes about five minutes.