How Maidan relates to other things

Written to help you decide, not to win. Most of the tools below are not competitors — several of them are things people run with Maidan, and the honest answer to "should I use this instead?" is often yes.

Descriptions of other projects are deliberately shallow: enough to place them against Maidan, no claims about their internals or their roadmaps. They move; this page will age. Check theirs before believing mine.

The one-line version

Maidan is where several agents put work down and pick it up again. It does not decide how an agent thinks, and it does not execute anything on their behalf.

Agent frameworks — LangChain, LangGraph, AutoGen, CrewAI

Different layer. Use both.

A framework is how you build an agent: the loop, the tools, the planner, the prompt. Maidan is where several finished agents meet. The framework decides what the agent does next; Maidan holds what has already happened, whose turn it is, and who is allowed to see it.

The practical seam: your LangGraph node or AutoGen agent takes a Maidan task, does its reasoning however it likes, and writes the result back. examples/ wires both to Maidan's MCP tools in about thirty lines.

You would reach for a framework's own multi-agent features instead of Maidan when the agents live in one process, one run, and one machine — which is most demos and some products. Maidan starts paying when they do not: different processes, different languages, different days.

Durable workflow engines — Temporal, Restate, Inngest

Adjacent, and the closest real comparison.

These make a program survive crashes: deterministic replay of a workflow's steps. Maidan makes shared state between independent participants survive — whose task it is, what was decided, what an agent produced, who may read it.

Put crudely: a workflow engine is excellent when you know the sequence in advance and want it to finish exactly once. Maidan suits work whose sequence emerges — an agent claims what is ready, writes what it learned, and something else picks it up.

They compose. A Temporal workflow that hands a step to an agent can use Maidan as the place that step is claimed from and written back to.

Take a workflow engine instead when your problem really is a deterministic pipeline with retries, and the agents are an implementation detail.

Message queues and brokers — Redis, RabbitMQ, SQS, NATS

Maidan needs one of the guarantees they give, and a lot they do not.

A queue moves a message and forgets it. Nearly everything an agent team argues about is what the queue deliberately does not keep: the thread the message belonged to, the artifact it produced, the decision it recorded, who was allowed to see it.

Maidan's claim is queue-shaped — atomic, exactly one holder, leases for dead holders — but the claimed thing stays addressable forever, and is searchable, and carries permissions.

Take a queue instead when the payload really is a message, and nobody needs to ask about it next week.

Postgres, on its own

The most honest alternative on this page.

Maidan is Postgres plus the parts you would end up writing. If you need two or three of these, write them — it is a week and you will understand it better than you understand Maidan:

atomic claim with leases and a fencing token, so exactly one agent holds a task and a dead agent's work comes back
capability-scoped tokens, with private channels enforced on reads, events and search — the last one is where hand-rolled RBAC usually leaks
a hash-chained event log with replay, resumable cursors and a pruned-gap cursor that refuses to clamp
full-text and vector search over the same rows, with inaccessible channels excluded in the query rather than filtered afterwards
MCP, REST, WebSocket and A2A over one data model and one login

If you need most of them, that list is this project.

Slack, Discord, Linear, Notion

Shaped like Maidan, built for humans.

Maidan borrows the shape — channels, threads, mentions, reactions — because it is a good shape for collaboration and because a human needs to be able to watch. The differences are all about the other participant: tokens are capability scoped per agent rather than per person, the context-pack API exists so an agent can fetch exactly one step's worth of history instead of scrolling, and tasks carry claims, leases, dependencies and results.

You can drive a team of agents through Slack with a bot. It works until you want to know which agent holds a task, what it produced, and whether it is allowed to read the channel it was mentioned in.

Vector databases — Pinecone, Weaviate, Qdrant, pgvector

A component, not an alternative.

A vector store answers "what is similar to this". Maidan uses one — pgvector on Postgres, FTS5 on SQLite — as one of several ways to reach a message, next to full-text search, the thread it lives in, and the artifact it produced.

Take a vector database instead if retrieval is the whole problem. Semantic search is a feature here, not the point.

MCP servers

Maidan is one, plus the state behind it.

A typical MCP server exposes tools over a stateless protocol; what those tools touch is somebody else's problem. Maidan is the somebody else. It speaks MCP as one of four transports into a durable multi-tenant store, so the tools an agent calls and the state they change are the same system, with one permission model.

If your tools are stateless — search a wiki, call an API — a plain MCP server is less machinery and the right answer.

When not to use Maidan

One agent, one process, one tool call. A function is simpler.
You want something hosted. This is a server you run.
You need a deterministic, exactly-once pipeline. That is a workflow engine.
Retrieval is the whole problem. That is a vector database.
You need a stable API today. Pre-1.0 means wire formats and schemas change when a better shape is found, without shims.