Multi-Agent Orchestration: When CrewAI, LangGraph, and Custom Stop Being the Same Conversation

The framework discourse, and the question underneath it

Every quarter, a new multi-agent framework arrives with a launch post, a benchmark, and a community of early adopters convinced the previous one is now obsolete. CrewAI crossed forty-five thousand stars and powers, by its own count, more than twelve million daily agent executions. LangGraph is sitting inside the LangChain ecosystem at ninety-seven thousand stars with LangSmith and LangServe alongside it. Microsoft retired AutoGen into maintenance mode and shipped Agent Framework 1.0 for .NET and Python. OpenAI deprecated Swarm in favour of the Agents SDK, which reached a model-native harness and sandbox execution.

The framework discourse is loud. The engineering question underneath it is quieter: when a production multi-agent system fails at 02:00, what does the on-call engineer need to reconstruct what happened, fix the cause, and resume the run without losing state? Read the frameworks against that question and the apparent symmetry between them breaks. They are not the same conversation. They optimise for different things, and the things they optimise for trade against each other.

This piece reads each option on engineering terms. The pattern we recommend is not loyalty to one framework. It is matching framework to constraint, and being honest about what no framework solves.

What each framework actually optimises for

CrewAI optimises for the legibility of agent teams to non-engineers. You define agents with a role, a backstory, and a goal. You assign tasks. The framework handles the coordination loop with prompt templates that surface as readable structure. For a content pipeline, a research workflow, or anything that maps cleanly onto a human team structure, this is the fastest path to a working prototype — often two to four hours from blank file to running crew. The metaphor carries real engineering value because product stakeholders can read the configuration. The cost is that customisation lives behind abstraction. Once you need conditional routing that does not match the task model, or you need to debug a stuck agent in step seven of a twelve-step crew, you are working against the framework, not with it. Observability is being added but remains less mature than what the LangChain ecosystem offers.

LangGraph optimises for the explicit state machine. Agents are nodes in a directed graph with a typed shared state. Transitions are conditional functions. Checkpoints are first-class. The cost is verbosity — a graph that does in CrewAI what fits on a page takes more code in LangGraph. The benefit is that the verbose code is the documentation. When the system breaks, the graph tells you which node held control, what state it received, and what state it produced. The integration surface around it — LangSmith for tracing, LangServe for deployment, the AgentCore checkpointer for AWS-native persistence — is the broadest in the ecosystem. For stateful, auditable, long-running flows, this is the most battle-tested option.

Microsoft Agent Framework is the production-grade successor to AutoGen. AutoGen contributed the conversation-based, actor-model architecture and the research-grade orchestration patterns: sequential, concurrent, handoff, group chat, and the Magentic-One planner. The 1.0 release promoted these to stable, added streaming, checkpointing, human-in-the-loop approvals, and pause/resume across both .NET and Python, and merged in the enterprise scaffolding from Semantic Kernel. For organisations already on the Microsoft identity and Azure substrate, this is the path of least friction. AutoGen continues for research and prototyping but receives no new features.

OpenAI Agents SDK is what Swarm became. Swarm was deliberately small and deliberately experimental — a reference design for lightweight handoffs between agents. The Agents SDK kept the simplicity and added what production needs: persistent sessions, guardrails, tracing, and a model-native harness that owns the agent loop, tool routing, handoffs, approvals, and run state. The current release added sandbox execution with providers including Cloudflare, E2B, Modal, Daytona, Vercel, Runloop, and Blaxel. For OpenAI-first teams, the SDK is now the supported production path. Swarm itself should be read as a reference design, not a deployment target.

Custom means something specific in the teams we work with. It is not a from-scratch reimplementation. It is a thin state-machine layer in Python, typed with Pydantic, deployed on the team's existing infrastructure-as-code substrate, with prompt-tuning and tool-calling logic written explicitly. Teams reach for custom when the framework abstractions are paying a cost they cannot recover — when the workflow does not match any framework's coordination model, when the audit and compliance surface needs to be inspectable line-by-line, or when the deployment substrate already imposes constraints (regulated environments, air-gapped infrastructure, specific identity providers) that the frameworks treat as edge cases.

The four production constraints that decide the choice

Framework choice is decided by four constraints. The frameworks all do tool-calling. They all do orchestration. The differences appear here.

State management asks where conversation state lives, who owns checkpoints, and what happens to in-flight runs on deployment. LangGraph treats state as a typed object that flows through the graph, with pluggable checkpointers — Postgres, Redis, Bedrock AgentCore Memory, DynamoDB with S3 offloading, or Valkey. CrewAI keeps state inside the crew object with optional memory plug-ins. The OpenAI Agents SDK ships persistent sessions. Microsoft Agent Framework gives you checkpointing and pause/resume on long-running workflows. Custom puts state wherever your platform team already runs stateful services. The right question is not "does it have checkpoints" but "what do my checkpoints cost to inspect, replay, and migrate."

Observability asks whether an on-call engineer can reconstruct what happened from logs. Multi-agent failures are not single-call failures. They appear in causal chains across steps where the output of one step conditions the next, tool invocations and their interpretations are non-deterministic, and the failure mode is often a wrong handoff or a corrupted state field rather than an exception. LangSmith is the deepest integration for LangGraph stacks and adds virtually no measurable overhead. Langfuse is the strongest self-hosted option for teams with data residency requirements, at the cost of higher overhead — around fifteen percent in step-level instrumentation. Observability is the constraint that breaks teams who picked frameworks for prototype velocity and now cannot debug production.

Error semantics asks what happens when an agent fails mid-flow. Three sub-questions sit underneath: does the framework retry, does the framework hand off to a fallback agent, and does the framework surface the failure to a human approver. LangGraph treats this as graph design — you express retries, fallbacks, and human-in-the-loop nodes as edges. Microsoft Agent Framework ships the patterns natively across all orchestrations. CrewAI handles retries inside the task abstraction with less control over fallback routing. The OpenAI Agents SDK exposes approvals and tracing as part of the model-native harness. Custom forces you to design this explicitly, which is either the cost or the value depending on your compliance posture.

Deployment model asks where the agents run. Single-process is the prototype. Distributed is what most teams build. Serverless is what scales without operational overhead — and is the deployment model Bedrock AgentCore was built for, with LangGraph multi-agent systems deployable directly onto the AgentCore Runtime with checkpointing into Bedrock Session Management Service or ElastiCache Valkey. The OpenAI Agents SDK integrates with Cloudflare, Modal, E2B, Vercel, and Temporal. CrewAI Enterprise runs the same code on the team's own infrastructure. Microsoft Agent Framework runs on Azure with the identity and isolation patterns of that ecosystem. Custom runs wherever the team already runs services. The question is not which deployment model is best. It is which deployment model your existing operational maturity can support.

Decision matrix

The matrix below maps each framework against the four constraints. Strengths are stated first, gaps second. Read it as a starting position for a conversation, not a verdict.

The pattern is clear when you read it column by column. LangGraph is the deepest on state and observability. Microsoft Agent Framework is the strongest on built-in orchestration patterns. The OpenAI Agents SDK is the cleanest if your tooling is OpenAI-first. CrewAI is the fastest from blank file to working prototype. Custom is the only honest answer for teams whose constraints do not match any framework's defaults.

The honest production architecture

Most enterprise teams we work with converge on a similar shape, regardless of which framework they started with. It is not the architecture any single framework documents. It is the architecture that survives the four constraints.

The state-machine layer is LangGraph. Not because it is fashionable but because the graph is legible to auditors, the typed state is legible to engineers, and the checkpointer choice — Postgres for self-host, Bedrock AgentCore Memory for AWS-native, ElastiCache Valkey for low-latency — is decoupled from the framework. Teams running on Azure substitute Microsoft Agent Framework here; teams OpenAI-first substitute the Agents SDK. The shape is the same: an explicit state machine, typed state, pluggable storage.

The tool-calling layer is custom Python. Tools are Pydantic-typed functions with explicit input and output contracts, registered into the agent runtime through the framework's tool-binding API. The reason this layer is custom even when the orchestration layer is not is that tools touch the team's existing services — auth, databases, secrets, external APIs — and the framework's tool abstractions are not allowed to dilute the contracts those services already enforce.

The observability surface is LangSmith for teams already on the LangChain ecosystem, Langfuse for teams with self-hosted data residency requirements, or homegrown tracing built on OpenTelemetry for teams whose platform stack already standardises on it. The constraint is not which tool. The constraint is that traces are correlatable from the user-facing request through every agent step, every tool call, every model invocation, and every state mutation.

The deployment substrate is one of three: Bedrock AgentCore Runtime for AWS-native serverless multi-agent deployments, Modal for teams that want serverless Python without committing to a cloud vendor's agent platform, or ECS Fargate (or its equivalent on other clouds) for teams that need long-running container processes with predictable cost. Each maps to a different operational posture. The choice belongs to the platform team, not the agent team.

This is the architecture that emerges, repeatedly, from teams that have stopped building demos and started running production. It is not a framework decision. It is four decisions, each independent, each owned by a different role.

What none of these solve out of the box

Four production concerns sit outside what any framework provides. They are exactly the concerns most likely to surface during a compliance review, a security audit, or a regulator's questionnaire.

Multi-tenant isolation. Frameworks ship with single-tenant defaults. Multi-tenancy demands five identity layers — trigger identity, execution identity, authorization identity, tenant identity, and session identity — with authentication happening before tenant resolution, tenant resolution before session derivation, and session loading before context compilation. Memory operations must be prefixed with tenant-scoped namespace paths. The framework does not enforce this. Your platform team does.

Secrets rotation in long-running flows. An agent run that lasts six hours may begin with one set of credentials and need to rotate to another mid-flow. None of the frameworks have a native answer. The pattern that works is short-lived tokens minted from a secrets broker per tool call, with the broker enforcing the rotation contract.

Principal scoping across handoffs. When agent A hands off to agent B, the effective authority of B must be the strict intersection of B's baseline permissions and the requesting user's permissions — never the union, never B's baseline alone. The runtime evaluates a tuple of claims (user, agent, scopes, audience, tenant, task ID, expiry) at every tool call. Frameworks do not enforce this intersection. Your authorization layer does.

Audit-trail integration. Production agents act on behalf of identified users in regulated contexts. Every action with an external side-effect needs an audit record that ties the action to the requesting user, the approving agent, the prompt that led to the decision, and the model that generated it. Tracing tools capture the technical execution. Audit-trail integration is a separate concern, owned by compliance, and must be wired in explicitly.

These are the concerns that decide whether a multi-agent system passes a procurement review for a bank or a regulated operator. None of them are framework features. They are platform-engineering work that sits underneath whatever framework you pick.

What this teaches us about enterprise scaling

The framework discourse trains attention on the wrong variable. Reading CrewAI against LangGraph against Microsoft Agent Framework against OpenAI Agents SDK as competing bets misses that the choice between them is, in production, a smaller decision than the four that surround it: where state lives, what observability you can sustain, how error semantics map to your operational posture, and what deployment substrate your platform team can run.

Enterprise scaling of multi-agent systems is not a framework problem. It is a platform-engineering problem dressed in framework language. The teams that scale these systems pick the framework that costs the least to integrate with the platform decisions they have already made — and then spend the real engineering effort on the four concerns no framework solves: tenancy, secrets, scoping, and audit. The framework choice is reversible. The platform decisions are not. Optimising for the reversible decision while leaving the irreversible ones implicit is the most common pattern of failure we see.

Companion content

• Self-Improving Agents: A Production Pattern
• Agent Code Execution: MicroVM vs Container
• Strict RBAC in Enterprise Knowledge Bases
• Glue Code Is the Job: Enterprise LLM Integration
• Why Enterprise AI Pilots Fail at Deployment

How to engage

The pattern we recommend is not the framework. It is the four-decision architecture underneath — state, observability, error semantics, deployment — designed before the framework choice and owned by the platform team that will run it. Talk to us at creativeminds.dev/contact.