# How Realm compares with LangGraph, CrewAI, Temporal, n8n and others

Checked 5–6 October 2026. This is the Markdown copy of https://realmengine.dev/compare/.

Realm against eight tools people consider for the same job: getting an AI agent to do multi-step work reliably. Every answer below cites the tool's own code or docs, and each column names the release that was checked and when. Where Realm is behind, the page says so.

The difference that matters most: the other eight run the work themselves and call the model when they need it. Realm can do that too, but an outside assistant, such as Claude or Cursor, can also work through a Realm workflow one step at a time. Realm refuses a step taken out of order, and an answer that breaks the schema the step declares.

## Summary

- **Only Realm:** An outside AI agent can be driven through it one step at a time
- **Level with the field:** Decides which step runs next; Checks the model's output against a schema; Pauses for a person's decision, with a time limit; Records each step's input and output; Can be used as an MCP server
- **Realm is behind:** Records who made the decision, and checks it; Carries on after a crash, by itself; Steps can call other MCP servers as tools
- **Nobody has it:** Shows if a record was changed afterwards

## Nine tools, 10 questions

After Realm, the tools are ordered by GitHub stars on 6 October 2026, most first. The order says how popular each one is, not how good. Partial always means something is missing; the answers below say what.

| Question | Realm | n8n | Dify | CrewAI | LangGraph | Mastra | Temporal | Microsoft Agent Framework | Inngest |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| An outside AI agent can be driven through it one step at a time (Only Realm) | Yes | No | No | No | No | No | No | No | No |
| Decides which step runs next (Level with the field) | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Checks the model's output against a schema (Level with the field) | Yes | Yes | Partial | Partial | Partial | Partial | Partial | Partial | No |
| Pauses for a person's decision, with a time limit (Level with the field) | Yes | Yes | Yes | Partial | Partial | Partial | Yes | Partial | Yes |
| Records who made the decision, and checks it (Realm is behind) | Partial | Partial | Partial | Partial | No | No | Partial | No | No |
| Records each step's input and output (Level with the field) | Yes | Yes | Yes | Partial | Yes | Yes | Yes | Yes | Partial |
| Shows if a record was changed afterwards (Nobody has it) | No | No | No | No | No | No | No | No | No |
| Carries on after a crash, by itself (Realm is behind) | Partial | Partial | Partial | Partial | Partial | Yes | Yes | Partial | Yes |
| Can be used as an MCP server (Level with the field) | Yes | Yes | Yes | No | Partial | Yes | No | Partial | Yes |
| Steps can call other MCP servers as tools (Realm is behind) | Partial | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |

| Fact | Realm | n8n | Dify | CrewAI | LangGraph | Mastra | Temporal | Microsoft Agent Framework | Inngest |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Defined in | YAML + JSON Schema; JavaScript extensions | Visual editor (JSON); code nodes; TS SDK | Visual editor; YAML export | Python + JSONC/YAML; visual editor on the paid platform | Python or JS/TS code | TypeScript code; JSON (beta) | Code, 8 SDKs | Python, C#, Go code; YAML | Code: TS, Python, Go, Kotlin/Java |
| Run through | CLI, MCP, library, webhooks. No UI | UI, API, CLI, MCP, Cloud | UI, API, CLI, MCP, Cloud | CLI, SDK, platform UI and API | Library, CLI, API, Studio, cloud | CLI, SDK, API, Studio UI, cloud | CLI, SDKs, Web UI, Cloud | SDK; DevUI sample; Azure Foundry | CLI, SDKs, dashboard, API, Cloud |
| Hosting and storage | Self-hosted; JSON files on one machine | Both; SQLite or Postgres (+ Redis) | Both; Postgres, Redis, a vector store | Both; SQLite, LanceDB | Both; SQLite, Postgres, MongoDB (server: Postgres + Redis) | Both; about 20 storage adapters | Both; Cassandra, Postgres, MySQL | Both; file, Cosmos DB, Foundry | Both; SQLite, or Redis + Postgres |
| License | Apache-2.0 | Sustainable Use License (source-available) | Apache-2.0 with added conditions | MIT | MIT (Agent Server: Elastic-2.0) | Apache-2.0 + source-available ee/ | MIT | MIT | SSPL server; Apache-2.0 SDKs |
| First release | 2026-06 | 2019-06 | 2023-05 | 2023-11 | 2024-01 | 2024-10 | 2020-09 (1.0) | 2025-10 | 2021-07 |

## Every answer, with its source

Each source says how it was checked: CODE read in the tool's source, DOCS stated in its own docs, EXECUTED run, INFERRED reasoned from what was read.

### An outside AI agent can be driven through it one step at a time

The question: Can an assistant such as Claude or Cursor work through a workflow step by step, and be refused when it skips ahead or answers in the wrong shape?

**Only Realm.** Only Realm does this built in. The others give an outside agent, at most, tools that run a whole workflow.

| Tool | Answer | What it does | Source |
| --- | --- | --- | --- |
| Realm | Yes | An MCP client calls execute_step for one step at a time. A step that is not eligible yet is refused, and when a step declares a schema, an answer that breaks it is refused. | CODE + EXECUTED: execution-loop.ts:1591-1605; probe on 0.46.0 over MCP |
| n8n | No | MCP execute_workflow runs a whole workflow, and does not support workflows with human-in-the-loop steps. | DOCS: docs.n8n.io MCP server tools reference |
| Dify | No | An app published as an MCP server is exactly one tool. | CODE: api/core/mcp/server/streamable_http.py:181-203 |
| CrewAI | No | No MCP server in the open-source code; outside callers start a crew through A2A or the paid platform's API. | CODE + DOCS: grep lib/ @1.15.23; processes.mdx |
| LangGraph | No | Agent Server exposes each graph as one MCP tool; one call runs the whole graph, with no sessions. | DOCS: docs.langchain.com/langsmith/server-mcp |
| Mastra | No | MCPServer exposes a workflow as one tool, run\_\<key\>, which runs the whole workflow. | CODE: packages/mcp/src/server/server.ts:280-310 |
| Temporal | No | Not built in. Temporal's own MCP server searches its docs; you can write a server whose tools start workflows. | DOCS + CODE: docs.temporal.io/with-ai; cli commands.yaml (no mcp) |
| Microsoft Agent Framework | No | WorkflowMCPTool (alpha) runs a whole workflow, and refuses one that needs human input. | CODE: hosting-mcp/\_workflow_tool.py:99-105 |
| Inngest | No | Its MCP server sends events, runs functions and reads traces. A client does not hand in step results through it. | DOCS + CODE: inngest.com/docs ai-dev-tools/mcp; pkg/devserver/mcp.go, pkg/api/v2/apiv2mcp/tools.go @v1.45.1 |

### Decides which step runs next

The question: Does the tool, not the model, decide the step order?

**Level with the field.** Level with the tools whose workflows are ordered by code, and the only one that holds an outside agent to that order. One gap: after a gate is answered, the next automatic step waits for an explicit call ([#625](https://github.com/sensigo-hq/realm/issues/625)).

| Tool | Answer | What it does | Source |
| --- | --- | --- | --- |
| Realm | Yes | The engine works out the eligible steps after every result and refuses the others. Among several eligible steps, the caller picks. A guard step behind a gate is decided when the answer is written; an automatic step after a gate still waits for a call ([#625](https://github.com/sensigo-hq/realm/issues/625), open). | CODE + DOCS + EXECUTED: execution-loop.ts:1591-1605; CHANGELOG 0.46.0; probe on 0.46.0 |
| n8n | Yes | The graph sets node order; inside the AI Agent node the model picks tools, up to 10 iterations by default. | CODE + DOCS: ToolsAgent/options.ts:22-25 |
| Dify | Yes | Workflow apps follow the graph; Agent nodes give the model control over tools. | DOCS: docs: nodes/agent |
| CrewAI | Yes | Sequential crews and Flows follow code; in hierarchical crews a manager LLM assigns the tasks. | DOCS: processes.mdx:17-19, 53-60 |
| LangGraph | Yes | The graph's edges decide; routing can use the model's output, but only to nodes the code wires in. Inside a prebuilt agent loop the model picks tools. | DOCS: graph-api.md#conditional-edges |
| Mastra | Yes | Workflows run a graph fixed in code; in agent networks a routing LLM picks the next agent. | DOCS: workflows/overview.mdx:19-29 |
| Temporal | Yes | Your workflow code decides; when that code is an agent loop, the model picks the tools. | DOCS: docs: openai-agents integration |
| Microsoft Agent Framework | Yes | Graph workflows run typed executors along edges; in group-chat, handoff and Magentic orchestrations an LLM picks who acts. | DOCS + CODE: learn: concepts/workflows; \_magentic.py:474-519 |
| Inngest | Yes | Your code decides; in an agent loop "the model's response decides the next step". | DOCS: docs: durable-agents |

### Checks the model's output against a schema

The question: Is a step's output checked against a declared schema before the run moves on?

**Level with the field.** Level. Realm refuses a wrong-shape answer and lets the caller try again; n8n, CrewAI and LangChain's agent also send the error back to the model. In Realm the schema is optional per step.

| Tool | Answer | What it does | Source |
| --- | --- | --- | --- |
| Realm | Yes | When a step declares a schema, a wrong-shape answer is refused before it is recorded; after 6 refusals the step fails, or uses a declared default. realm agent sends the error back to the model. Schemas are optional per step. | CODE + DOCS + EXECUTED: execution-loop.ts:1836-1880; json-schema-blocks.md |
| n8n | Yes | The Structured Output Parser checks the reply against a schema; Auto-Fix makes one more model call with the error, then fails. | CODE: N8nStructuredOutputParser.ts:67-68; N8nOutputFixingParser.ts |
| Dify | Partial | Only checks that the reply parses as JSON (repairing broken JSON); not checked against the schema. | CODE: structured_output.py:121-160 |
| CrewAI | Partial | output_pydantic and guardrails check output and retry with the error up to 3 times; on the output_json path a failed conversion can let the run continue on raw text. | CODE + DOCS: task.py:1382-1390; converter.py:150-174 |
| LangGraph | Partial | The graph does not check a node's output. LangChain's create_agent checks response_format and sends errors back to the model. | DOCS: use-graph-api.md; langchain/structured-output.md |
| Mastra | Partial | An agent step's structured output is validated and fails the step by default; a plain step's output is not checked against its own schema. | CODE: output-format-handlers.ts:741-749; handlers/step.ts:112 |
| Temporal | Partial | Not checked by Temporal; your activity code validates, and failures become activity retries without the errors going back to the model. | CODE + DOCS: docs: structured-output recipe; contrib/pydantic.py |
| Microsoft Agent Framework | Partial | A Pydantic result is validated only when read; a dict schema is only parsed as JSON. No retry with errors found. | CODE: \_types.py:2470-2490, 3043-3065 |
| Inngest | No | Model output and tool arguments are not checked; event data can be. | CODE: agent-kit agent.ts:667; triggers.ts:184 |

### Pauses for a person's decision, with a time limit

The question: Is there a built-in step that waits for a person, and can it time out?

**Level with the field.** Level with n8n, Dify, Temporal and Inngest. Ahead of the frameworks that have no time limit. Realm's time limit is opt-in; by default a gate waits forever.

| Tool | Answer | What it does | Source |
| --- | --- | --- | --- |
| Realm | Yes | A gate puts the run in gate_waiting and refuses later steps. A time limit is opt-in (abort or a default answer on expiry); by default it waits forever. | DOCS + EXECUTED: gates-and-trust.md:63-114; probe on 0.46.0 |
| n8n | Yes | Send and Wait (approval, text or form), with an optional wait limit; when the limit passes, the run continues. | CODE + DOCS: sendAndWait/utils.ts; configureWaitTillDate.util.ts; cli wait-tracker.ts (n8n@2.42.3); docs |
| Dify | Yes | A Human Input node with a form, action buttons and a timeout branch (3 days by default in the editor). | CODE + DOCS: human_input/entities.py:249-290 |
| CrewAI | Partial | Open source: console input or Flow feedback, no time limit. The paid platform adds email review with a timeout. | CODE + DOCS: human_input.py:364; flow-hitl-management.md |
| LangGraph | Partial | interrupt() pauses inside a node and resume continues it. No time limit on the wait. | CODE + DOCS: types.py:461-490, 833-858; interrupts.md |
| Mastra | Partial | A step can suspend and be resumed with data. No time limit found. | DOCS: workflows/human-in-the-loop.mdx |
| Temporal | Yes | Wait for a Signal with a timeout. | DOCS: docs: design-patterns/approval |
| Microsoft Agent Framework | Partial | request_info() pauses and routes the answer back by id. No time limit in core. | CODE: \_workflow_context.py:404-434 |
| Inngest | Yes | step.waitForEvent with a timeout, which returns null on expiry. | DOCS: docs: human-in-the-loop |

### Records who made the decision, and checks it

The question: Is the person who answered recorded, and is their identity checked?

**Realm is behind.** Behind n8n's Slack and Telegram approvals, which can restrict who may approve and record who clicked; Dify, which records the account that answered on its web app and gives each recipient its own token; and CrewAI's paid platform, which checks the reviewer's email (per its docs). Realm records a name the caller states and checks nothing; in a test the agent approved its own gate, and the proof token, which shows only the conversation, recorded it as matched.

| Tool | Answer | What it does | Source |
| --- | --- | --- | --- |
| Realm | Partial | Records a name the caller states and checks nothing. Each answer also records whether it passed back the token from the reply that opened the gate, which proves the conversation, not the person: in a test the MCP agent approved its own gate, passed its token, and was recorded as matched. Slack records no name ([#603](https://github.com/sensigo-hq/realm/issues/603)). | DOCS + CODE + EXECUTED: gates-and-trust.md:72; mcp/tools.md:431-433; slack-gate-notifier.ts; probe on 0.46.0 |
| n8n | Partial | When turned on, Slack and Telegram approvals restrict who may approve: a click from anyone not listed is refused and the run keeps waiting, and the answer records who clicked (id, name, source), on a callback n8n checks came from Slack or Telegram. Its other channels send a signed link that anyone holding it can answer, recorded as {approved, respondedAt} only. | CODE: Slack/V2/SlackHitlWebhook.ts:23-53, 177-193; Telegram/hitl/webhook.ts:36-38, 131-136; sendAndWait/utils.ts:488-493 (n8n@2.42.3) |
| Dify | Partial | Records the submitting user and recipient; each recipient gets a token. Email links: anyone with the link can answer. Through its API, the answering user is a name the caller sends, and deleting a conversation deletes its answers. | CODE + DOCS: models/human_input.py:72-78; human_input_service.py; controllers/service_api/wraps.py:134-151, tasks/delete_conversation_task.py:84-89 (dify 1.17.1) |
| CrewAI | Partial | Open source: no answerer recorded, and the answer itself is kept only on the running flow unless your code copies it into the flow's state. Paid platform: the reviewer's identity is recorded and checked against a signed token (docs only). | CODE + DOCS + INFERRED: flow/human_feedback.py:180-185; flow-hitl-management.md; flow/human_feedback.py:149-185, persistence/sqlite.py:301-314 (crewai 1.15.23) |
| LangGraph | No | resume carries no field for who answered. Agent Server's auth can check the caller if you write that code. | CODE + DOCS: types.py:833-858; langsmith/auth.md |
| Mastra | No | The step result has no field for who resumed it; a permission check needs the enterprise edition. Its chat channels' tool-call approvals accept only the person who asked, and record no approver. | CODE: workflows/types.ts:74-86; workflow.ts:4701-4726; channels/agent-channels.ts:60-61, 538-680 (@mastra/core 1.74.0) |
| Temporal | Partial | The approver is a field you put in the signal; the event also stores an identity string the sender sets. Since server 1.32 an opt-in setting adds a principal the server checks to each event; it is off by default. | CODE + DOCS: api history/v1/message.proto:618-635; server v1.32.0 mutable_state_impl.go:7694-7713, dynamicconfig/constants.go:930-935 |
| Microsoft Agent Framework | No | No responder field; authentication is left to your code. | DOCS: hosting-mcp/README.md:18-20 |
| Inngest | No | Only what your code puts in the event; anyone with the environment's event key can send one. | DOCS: docs: human-in-the-loop; event keys |

### Records each step's input and output

The question: Is each step's input and output kept, and for how long?

**Level with the field.** Level. Realm keeps records until you delete them, as do the tools that store their own (LangGraph, Mastra, Microsoft Agent Framework, Dify). n8n prunes after 14 days by default, Inngest Cloud keeps traces 24 hours to 14 days below Enterprise, and Temporal Cloud keeps history 1 to 90 days.

| Tool | Answer | What it does | Source |
| --- | --- | --- | --- |
| Realm | Yes | Each step's input, output and timing; the program that took it (stated or from the OS user, not verified); every gate answer with its stated answerer; why a step was skipped and why the run ended. Under realm agent, the token counts the provider reported. Kept until purged; one-file export. | DOCS + EXECUTED: run-record-and-export.md:154-163; evidence.md; probe on 0.46.0 |
| n8n | Yes | Each node's input and output with the execution; pruned after 14 days or 10,000 executions by default. | CODE + DOCS: executions.config.ts:106-118 |
| Dify | Yes | Every node execution's inputs and outputs; kept indefinitely on self-host by default. | CODE: configs/feature/\_\_init\_\_.py:1621-1624 |
| CrewAI | Partial | Task inputs and outputs of the latest run only; full checkpoints are opt-in. | CODE: kickoff_task_outputs_storage.py:49-58 |
| LangGraph | Yes | A state snapshot at every step plus each node's writes, with a persistent checkpointer. No export file. | DOCS: checkpointers.md |
| Mastra | Yes | Each step's input, output and timestamps in the run snapshot, with persistent storage. | CODE: workflows/types.ts:74-86 |
| Temporal | Yes | The event history keeps inputs and results; Temporal Cloud keeps it 1 to 90 days, then you export. | DOCS: cloud/namespaces.md:207; cloud/export.md |
| Microsoft Agent Framework | Yes | A chain of checkpoints with messages and state. | CODE: \_checkpoint.py:35-87 |
| Inngest | Partial | Step results and a trace per run. Inngest Cloud keeps trace history 24 hours (Free), 7 days (Pro), 14 days (Business) or up to 365 days (Enterprise); self-hosted Inngest does not remove them. | DOCS: docs: limits; docs: self-host Inngest |

### Shows if a record was changed afterwards

The question: Is the record hashed, chained or signed so an edit can be detected?

**Nobody has it.** None of the tools here does this. LangGraph's optional encryption hides values but does not show that a record was changed.

| Tool | Answer | What it does | Source |
| --- | --- | --- | --- |
| Realm | No | A SHA-256 hash of each output, never re-checked. In a test, hand edits to an agent's output, a person's choice and the answerer's name all showed as real, with no warning; nothing is signed and there is no verify command. | CODE + DOCS + EXECUTED: snapshot.ts:65-70; evidence.md:90-92; probe on 0.46.0 |
| n8n | No | No hashing or signing of execution data. | CODE: grep packages/cli/src/executions |
| Dify | No | Archive bundles carry MD5 checksums against corruption only. | CODE: archive_download_preparation.py:324-326 |
| CrewAI | No | No hashing or signing in the open-source code. The paid platform claims immutable audit logs for reviews (not checked). | CODE: grep state/, flow/persistence/ |
| LangGraph | No | Optional encryption hides values but does not show tampering: a value stored as plain text, or encrypted text copied from another record, still loads; on Postgres, plain values and metadata are never encrypted; a deleted or reordered checkpoint goes unnoticed. | CODE + INFERRED: checkpoint serde/encrypted.py:26-36, 65-78; checkpoint-postgres postgres/\_\_init\_\_.py:309-343 (langgraph 1.2.13) |
| Mastra | No | No hash or signature on step records. | CODE: grep workflows/, storage/ |
| Temporal | No | No hashing or signing of the history; the same permission that sends a signal can delete a history. | DOCS + CODE: llms-full.txt grep; cli commands.yaml:4767; common/api/metadata.go:111-115 (server v1.32.0) |
| Microsoft Agent Framework | No | The only hash fingerprints the graph's shape; the docs call checkpoint storage a trust boundary. | CODE + DOCS: \_checkpoint.py; learn: workflows/checkpoints |
| Inngest | No | No hashing or signing; Inngest itself never edits a stored event, but whoever has the database can. | CODE: pkg/db/postgres/sqlc/queries.sql:235-247; migrations/000001_baseline.sql:34-47 (inngest v1.45.1) |

### Carries on after a crash, by itself

The question: If the process dies mid-run, does the run resume without a person or your code stepping in?

**Realm is behind.** Behind Temporal, Inngest and Mastra, which resume a run on their own. LangGraph, CrewAI and Microsoft Agent Framework resume when your code calls them. A Realm run survives on disk, but a person or a driver restarts it, and a crash during an agent step needs a manual reclaim that may repeat the step's work.

| Tool | Answer | What it does | Source |
| --- | --- | --- | --- |
| Realm | Partial | State is saved after every step, but nothing resumes it: someone starts a driver again. Claims now name a holder and a time, but nothing checks that the holder is alive. A crash mid agent step needs realm run reclaim --force, which may repeat the work. No fsync. | CODE + DOCS: claim-liveness.ts:116-157; atomic-write.ts:29-32; operate-runs.md |
| n8n | Partial | Waits survive a restart; an execution running at the crash is marked crashed, not resumed. | CODE: execution-recovery.service.ts:215,228 |
| Dify | Partial | Paused runs resume; no resume of a run that crashed mid-node was found. | CODE + INFERRED: workflow_execute_task.py:484-596 (inferred) |
| CrewAI | Partial | Opt-in checkpoints; a run resumes when your code restores it (completed tasks are skipped). Writes are best-effort. | DOCS: checkpointing.mdx:31-47 |
| LangGraph | Partial | With a persistent checkpointer, a run resumes from the last checkpoint when your code calls it again with the same thread_id; finished nodes are not re-run. | DOCS: checkpointers.md |
| Mastra | Yes | With persistent storage, active runs restart from the last active step. | DOCS: workflows/overview.mdx:497-520 |
| Temporal | Yes | Replays the event history and resumes from the point of failure. | DOCS: encyclopedia/event-history |
| Microsoft Agent Framework | Partial | Restarts from a checkpoint your code chooses; resuming is not automatic in core. The durable extension makes it automatic. | DOCS: learn: workflows/checkpoints |
| Inngest | Yes | Saves each step's result and retries from the step that failed. | DOCS: docs: platform overview |

### Can be used as an MCP server

The question: Can an MCP client (Claude, Cursor, …) connect to it?

**Level with the field.** Level: n8n, Dify, Mastra and Inngest have one too, and LangGraph and Microsoft's in part. What only Realm does is the first row: its tools work one step at a time, where the others run whole workflows. CrewAI has no MCP server; Temporal's own MCP server searches its docs and runs no workflows.

| Tool | Answer | What it does | Source |
| --- | --- | --- | --- |
| Realm | Yes | 10 tools over stdio (realm mcp) or HTTP (realm serve), at step level. realm serve checks one shared token. | CODE + EXECUTED: packages/mcp-server/src/tools; realm-mcp-and-serve.md |
| n8n | Yes | Per-workflow tools and an instance server that can also build workflows; not stdio. | DOCS: docs: mcptrigger; connect-to-n8n-mcp-server |
| Dify | Yes | An app as one tool, off by default; credentials in the URL. | DOCS: docs: publish-mcp |
| CrewAI | No | No MCP server in the open-source code. | CODE: grep lib/ |
| LangGraph | Partial | Only in Agent Server (Elastic-2.0, needs Postgres and Redis); one tool per graph. | DOCS: langsmith/server-mcp.md |
| Mastra | Yes | Agents, tools and workflows over stdio and HTTP; a workflow is one whole-run tool. | DOCS + CODE: connections/mcp.mdx; packages/mcp/src/server/server.ts:280-310 (@mastra/mcp 2.1.2) |
| Temporal | No | Its MCP server searches the docs; nothing built in for running workflows. | DOCS: docs.temporal.io/with-ai |
| Microsoft Agent Framework | Partial | An agent or a workflow as one tool; the workflow tool is alpha. | CODE: \_agents.py:1815; \_workflow_tool.py |
| Inngest | Yes | Cloud and local servers for operations: send events, run functions, read traces. | DOCS + CODE: docs: ai-dev-tools/mcp; pkg/devserver/mcp.go, pkg/api/v2/apiv2mcp/tools.go @v1.45.1 |

### Steps can call other MCP servers as tools

The question: Can a step use tools from other MCP servers?

**Realm is behind.** Behind. Realm supports stdio servers only, and only when realm agent drives the step.

| Tool | Answer | What it does | Source |
| --- | --- | --- | --- |
| Realm | Partial | stdio servers only, and only when realm agent drives the step. | DOCS: agent-tools.md:15, 33-36 |
| n8n | Yes | The MCP Client Tool node. | DOCS: docs: toolmcp |
| Dify | Yes | MCP servers as tool providers, HTTP only. | DOCS: docs: workspace/tools |
| CrewAI | Yes | stdio, SSE or Streamable HTTP. | DOCS: mcp/overview.mdx |
| LangGraph | Yes | Through LangChain's MCP adapter (beta). | DOCS: langchain/mcp.md |
| Mastra | Yes | MCPClient over stdio and Streamable HTTP. | DOCS: connections/mcp.mdx |
| Temporal | Yes | Through agent-framework integrations; each MCP call runs as an activity. | DOCS: openai-agents.md:309-395 |
| Microsoft Agent Framework | Yes | stdio, Streamable HTTP and WebSocket. | CODE: \_mcp.py |
| Inngest | Yes | AgentKit agents take MCP servers over HTTP, SSE or WS. | DOCS: agentkit docs: MCP as tools |

## What each one does better, and where it falls short

Where each tool is stronger than Realm, and where it falls short for making an agent follow steps and show what it did.

| Tool | Kind | Release checked | Stronger at | Weaker at |
| --- | --- | --- | --- | --- |
| Realm | This project | 0.46.0 (npm), on 2026-10-06 | Drives an outside agent step by step and refuses out-of-order steps and wrong-shape answers; works with any MCP client and no model key; records why each step was skipped and why the run ended, which program took each step, and each gate answer; refuses a misspelt trust level or an invalid schema when the workflow is loaded. | No UI: no visual editor or dashboard; no loops: a workflow cannot go back to an earlier step, repeat a step until a condition holds, or run a step once per item of a list (only a retry of the same step, or a separate run per item); runs are stored as JSON files on one machine; nothing resumes a run after a crash; a gate records the name the answerer gives and checks nothing; after a gate is answered, the next automatic step waits for a call; agent steps can use tools only from local (stdio) MCP servers, and only under realm agent. |
| n8n | Visual platforms | 2.42.3, on 2026-10-06 | 1,500+ integrations by its README (the repository description says 400+) and 9,000+ templates; human review of AI tool calls on 9 channels; visual editor; MCP server that can build workflows; queue mode. | Inside the agent node the model decides; link approvals record no one; records pruned after 14 days by default; not OSI open source. |
| Dify | Visual platforms | 1.17.1, on 2026-10-05 | A rich human-input node that records the answerer and has a timeout branch; RAG pipelines; hundreds of model providers; logs kept by default. | Structured output is only parsed, not checked; an MCP client runs a whole app; email approval links work for anyone holding them. |
| CrewAI | Agent frameworks | 1.15.23, on 2026-10-05 | Role-based multi-agent crews; memory and knowledge; A2A; a large tool catalogue; on the paid platform, email review with the reviewer checked. | A manager LLM can decide the order; output_json can continue unvalidated; open-source reviews record no one and have no time limit; no MCP server. |
| LangGraph | Agent frameworks | 1.2.13, on 2026-10-06 | Time travel and forking from any checkpoint; per-node retries, timeouts and caching; Postgres and MongoDB with encryption; Studio debugger; LangSmith tracing; Python and JS. | The graph does not check a node's output; interrupts have no time limit and no answerer; the MCP server needs the licensed Agent Server and runs whole graphs. |
| Mastra | Agent frameworks | core 1.74.0, on 2026-10-05 | One TypeScript stack for agents, memory, RAG and evals; about 20 storage backends; Studio with time travel; scheduled workflows; MCP on the latest spec. | An outside agent can only start a whole workflow; no answerer on human steps and no time limit; a plain step's output is not checked. |
| Temporal | Durable execution | server 1.32.0, on 2026-10-05 | Production record since 2020; crash recovery by design; 8 SDKs; Signals, Updates and Schedules; Cloud with high-availability tiers; integrations with 10+ agent frameworks. | Your code is the agent loop and the checks; approver identity is up to you; Cloud keeps history at most 90 days unless exported. |
| Microsoft Agent Framework | Agent frameworks | python 1.20.0, on 2026-10-05 | Python, C# and Go; ready-made multi-agent patterns; workflow types checked when built; durable execution through Azure; A2A hosting. | A dict schema is never checked; human steps record no responder and have no time limit; the MCP workflow tool is alpha. |
| Inngest | Durable execution | server 1.45.1, on 2026-10-05 | Event-driven runs; concurrency, throttling and debounce; hosted model calls; realtime streaming; evals; serverless-friendly. | Model output is not checked; approvals carry only what the event says; traces last 24 hours to 14 days below Enterprise. |

## Sources, dates and corrections

- Each answer was read in the tool's own source code, docs or release notes. A column names the main release that was read; where an answer comes from a companion package, such as a tool's SDK, CLI or MCP server, its source names the file. Blog posts, comparison articles and AI summaries were not used.
- Realm's own column was checked by a separate pass told to find its weaknesses, and its key answers were run on the published release.
- "Only Realm", "Level with the field", "Realm is behind" and "Nobody has it" are our reading of each row. The answers and their sources are the evidence.
- Claims a tool makes only in its docs are labelled DOCS and were not checked in its code. Prices change often and are not listed here.
- Every answer and its source is also in one data file, [comparison.json](https://github.com/sensigo-hq/realm/blob/main/website/src/data/comparison.json).
- Something wrong or out of date? [Open an issue](https://github.com/sensigo-hq/realm/issues/new?title=Comparison%3A%20&body=Which%20tool%20and%20which%20question%3A%0A%0AWhat%20the%20page%20says%3A%0A%0AWhat%20is%20true%20(with%20a%20link%20to%20the%20tool's%20own%20code%20or%20docs%2C%20and%20its%20version)%3A%0A) with a link to the tool's own code or docs, and we will check it and correct the page.