DEV Community: The Unmeshed Team

Fast Isn't Free

The Unmeshed Team — Fri, 30 Oct 2026 05:10:38 +0000

A team picks a workflow tool. It runs well in testing, so they ship it.

A year later, traffic is up. The bill is up even more.

Nobody planned for that, because nobody asked the right question at the start. Not "how fast is it?" but "what will it cost when we're ten times bigger?"

Turn speed into daily volume

Throughput numbers are usually quoted per second, which makes them hard to feel. A quick conversion helps: multiply transactions per second by 86,400, the number of seconds in a day.

1,000 per second is about 86 million a day
10,000 per second is about 864 million a day

Now compare that with what you really expect. A lot of teams find they need far less than they feared. Others find they need a lot more than they planned for. Either way, you can't judge a tool until you know your own number.

Watch how the cost grows

A tool can be fine at small volume and painful at large volume. Here's an illustration. Spending $20,000 a year for a few thousand transactions per second might be reasonable. If handling a bigger load pushed that to $200,000, the math changes. Those are example figures, not anyone's price list, but the shape is real: what matters is whether cost rises in step with traffic or faster.

Simple workflows that run at low volume can live happily with a modest setup. Complex, high-volume ones can't. And a setup that's fast but very expensive tends to be dropped once the bill gets attention.

When latency is the whole point

Some use cases don't give you time to wait. Payment processing, IoT data pipelines and AI-driven workflows are all situations where slow responses or low throughput cause real problems for users. If yours looks like that, test under load before you commit, not after.

What to ask before you choose

How many transactions per second can one instance sustain, and what did that test look like?
What happens when you need more? Do you add instances, and how does the price change?
Does the number come from a workflow like yours, or a simple one-step example?
What does it cost at your expected volume, and at ten times that?

Those four questions tell you more than any single benchmark.

For reference, Unmeshed reports up to 10,000 transactions per second on a single instance, which works out to nearly a billion a day, and says larger loads are handled by adding instances to the cluster. As with any vendor's numbers, test it against your own workflows. You can try Unmeshed and see how it behaves with yours.

LLM Orchestration Explained: Routing, Fallbacks, and Production Reliability

The Unmeshed Team — Thu, 29 Oct 2026 05:14:48 +0000

TLDR

LLM orchestration is the control layer that decides which model does what, in what order, and what happens when something breaks.
It's really three jobs. The model layer picks the model, the pipeline layer builds prompts and tool calls, and the run layer keeps everything durable, limited, and auditable.
Teams use more than one model because of cost, speed, skills, and provider outages. They pick between them with routing, cascading, fallback, or parallel ensembles.
Frameworks, gateways, and workflow engines aren't rivals. They sit at different layers, so you start with whichever one is failing in production.
Unmeshed is the run layer. It handles retries, fallbacks, routing rules, spend limits, and approvals in one place, and it works alongside the tools you already use.

Ok so, LLM orchestration. Sounds super fancy, right? It really isn't.

Here's the deal. Most teams start with one model call, and it works great. Then they add a second model, then a third, and suddenly nobody knows which one is doing what, or what happens when one of them breaks.

That's basically what it's for. It decides who does what, in what order, and what to do when something goes wrong.

We're happy to say it's way less scary than it sounds. We'll go through the three jobs people mix up, how routing and fallback work, and where Unmeshed fits. And where it doesn't, because we'll be straight with you about that too.

Okay, let's get into it.

1. What Is LLM Orchestration?

LLM orchestration is how you coordinate multiple language models, prompts, tools, and data sources into one reliable process. It decides which model handles each step and what context it gets. And it decides what happens when a step fails or costs way too much.

Okay, but what does that actually mean? We figure the easiest way to wrap your head around it is to pretend it's a restaurant kitchen.

You've got a bunch of cooks. Some are fast, some are fancy, and some only do desserts. Someone has to decide who makes which dish, what to do when the oven dies, and who stops the kitchen from blowing the whole budget on truffles.

That someone is the head chef. And that's basically what orchestration is.

In plain terms, it involves five decisions.

Which model handles each step (who cooks the dish)
What the model gets to see and use (the ingredients and tools)
What happens when something breaks (the oven dies)
How much a run is allowed to spend (the truffle budget)
Who has to approve it before it goes out (the taste test)

Quick note on what it isn't. It's not a single prompt. It's not only a gateway that passes requests along. And it's not agent orchestration, where the model picks its own next step (we cover that in our guide to agentic orchestration). Today we're only talking about the models.

If you want the bigger picture, our guide to AI orchestration covers pipelines, agents, and platforms. This one is just the model side of things.

2. Why Do Production Systems Use More Than One Model?

Production systems use more than one model because no single model is best at everything. One might be great at hard reasoning but too slow and pricey for sorting tickets. And every provider has a bad day eventually.

Okay, but why though? Can't you just pick the best model and call it a day? Hmm, that's what we thought too. Turns out, not really.

Cost: You wouldn't hire a fancy chef to boil an egg. A quick classification doesn't need your priciest model.
Speed: If someone's waiting on the answer, it has to be quick. A nightly report can take its time.
Skills: Some models are just better at code, long documents, or using tools.
Drama: Providers have outages, rate limits, and deprecations, usually at the worst possible time.

There's one more sneaky reason. Models get updated, sometimes quietly, and a prompt that worked last month can suddenly act weird.

With a backup model ready (and a way to compare the two), that turns into a boring switch. Boring is good.

Cost is usually what gets teams moving on this, and routing is one of the best ways to bring it down. We cover the tricks in our guides to cost optimization and token efficiency.

3. What Are the Three Layers of LLM Orchestration?

LLM orchestration has three layers. The model layer picks which model answers. The pipeline layer builds prompts, retrieval, and tool calls. And the run layer keeps everything durable, limited, and auditable. A model orchestration layer usually only covers the first one.

Back to the kitchen for a sec. These three layers are basically three different people.

The model layer is the waiter who decides which cook gets the order. The pipeline layer is the recipe, so what goes in and in what order. And the run layer is the kitchen manager who keeps track of everything, fixes stuff when it goes wrong, and writes it all down.

Layer	Job	Typical Tools	What Breaks Without It
Model	Pick the right model and handle provider failure	Gateways and routers	One outage or price change hits your whole product
Pipeline	Build prompts, retrieve data, call tools, validate output	Frameworks such as LangChain and LlamaIndex	Prompts and tool calls turn into tangled glue code
Run	Keep runs durable, limited, approved, and traceable	Workflow engines	A crash loses state, and nobody can explain a result

Most guides only talk about one of these and call it a day. So you end up with a waiter and no manager, or a great recipe and nobody watching the stove. Lowkey, that's where most of the pain comes from.

You don't need all three on day one. Start with whichever one hurts. The mistake is thinking the one you have covers the other two. It doesn't.

4. How Does Multi-Model Orchestration Work?

Multi-model orchestration works by picking a model for each request. There are four main ways to do it, which are routing, cascading, fallback, and parallel ensembles. Each one trades cost, speed, and quality a bit differently, and most teams end up combining two.

Here's the easy version of all four. Routing is like a host seating people at the right table. Cascading is trying the cheap option first and only calling the expensive one if the cheap one flops.

Fallback is the backup plan for when your first option is down. And a parallel ensemble is asking a few cooks to make the same dish and picking the best one (pricey, ngl).

Pattern	How It Works	Best For	Main Risk
Routing	A router picks one model before generation based on the request	Mixed workloads with clear easy and hard cases	A weak router sends hard requests to weak models
Cascading	Run a cheaper model first and escalate if the answer scores low	High volume traffic where most answers are easy	Extra latency when escalation triggers
Fallback	Switch to another model or provider when a call fails	Reliability against outages and rate limits	Repeated side effects if the retry isn't safe
Parallel ensemble	Call several models and compare or merge the answers	High stakes decisions	Cost multiplies with every model you add

There's actual research on this too. A paper on routing and cascading for LLMs describes routing as picking one model per query, and cascading as running bigger and bigger models until the answer is good enough.

The authors also came up with cascade routing, which mixes both. And the big finding is that it all depends on how well you can tell if an answer is any good.

That last part matters. A cascade is only as smart as whatever decides "is this answer ok?" Some teams use a simple rule, some use a validator, and some use another model as the judge, which is kind of a can of worms (our guide to LLM as a judge goes into where bias sneaks in).

One warning about fallback. Switching to another model is easy. Doing it safely is the tricky bit. If a retry sends the same email twice or charges a card twice, well, that's a bad day.

So limit your retries, and make the steps around the model safe to run twice.

5. What Is an LLM Pipeline, and How Is It Different From an LLM Workflow?

An LLM pipeline is a fixed set of steps that turns an input into a model output, like retrieve, prompt, generate, and validate. An LLM workflow wraps those steps with branching, retries, state, and human approval.

Still the kitchen. A pipeline is one recipe, with the same steps in the same order every time. A workflow is the whole dinner service, which includes what to do when the oven breaks, when to ask the head chef, and what happens when a customer wants a refund.

Dimension	LLM Pipeline	LLM Workflow
Shape	A fixed sequence of steps	Steps plus branches, loops, and waits
State	Usually lives in memory for one run	Saved between steps so a run can resume
Failure handling	An error stops the run	Retries, fallbacks, and escalation paths
Human input	Rare	Approval steps that pause the run
Typical home	Application code or a framework	A workflow engine

Here's an example. A support ticket comes in. The pipeline classifies it, grabs the account history, writes a reply, and checks the tone. Done.

The workflow decides which model writes the reply, retries if the provider times out, sends any big refund to an actual human, and writes down every step along the way.

6. Which Do You Need for LLM Orchestration: a Framework, a Gateway, or a Workflow Engine?

You need a framework to build the pipeline, a gateway for routing and provider control, and a workflow engine to run it all durably. Plenty of teams end up needing all three. Start with whichever layer is failing in production.

Think of it like this. The framework is your recipe book. The gateway is the delivery driver who finds a route to the model. And the workflow engine is the kitchen manager again. All different jobs.

Tool Type	What It Covers	Examples	What It Doesn't Cover
Framework	Prompts, retrieval, tool calls, model interfaces	LangChain, LlamaIndex	Durable runs, spend limits, approvals
Gateway	Routing, load balancing, retries, fallbacks across providers	LiteLLM	Multi-step business logic and human review
Workflow engine	State, retries, branching, approvals, audit	Unmeshed	Prompt design and retrieval tuning

LangChain describes itself as a framework for building agents and LLM-powered apps, with a standard interface for models and tools.

LlamaIndex started out as a data framework for connecting models to your own data. Its README now says the main focus is document parsing and extraction though, so worth knowing that before you pick it for something else.

On the gateway side, the LiteLLM router handles load balancing, retries, cooldowns, and fallbacks across deployments and providers. We go deeper on that in our guide to the LLM gateway.

None of these are rivals of a workflow engine. They just sit at different layers, and the best setups use them together. So pick based on what's breaking for you right now.

7. How Does Unmeshed Handle LLM Orchestration?

Unmeshed handles the run layer of LLM orchestration. Your model calls become steps in durable workflows. So retries, fallback paths, routing rules, approvals, and spend ceilings all live in one place, with a full run history and no lock-in to any one model.

In kitchen terms, we're the manager. Here's the rundown.

Durable runs and retries: Model calls run as steps in workflows with retries and saved state, so a crash picks up where it stopped instead of starting over.
Routing rules: A decision engine uses decision tables with first match or all match rules. You can route by request type, size, or customer tier without a pile of branching code.
Fallback paths: When a model step fails, the workflow just branches to another model or a safe default.
Spend and tool limits: Agents are bound to a fixed set of tools, and each one can have a spend ceiling that throttles it or switches it to a cheaper model. See AI agent governance.
Approvals: A human-in-the-loop step pauses a run until a person decides.
Visibility: Every run keeps a full history of steps, inputs, and outputs. For the agent side of things, see agent orchestration.

It's model-agnostic too, so you're not stuck with one provider, and it's MCP native. There are SDKs for Java, Go, Python, and TypeScript. Oh, and it comes from the creators of Netflix Conductor, in case that helps.

Now, the honest part. We're not a prompt framework, and we're not a gateway. If you love LangChain for building and LiteLLM for reaching providers, keep them! We just run them for you.

Your Models Are Not The Hard Part.
Unmeshed runs model calls as workflow steps with retries, fallback paths, and spend limits, so a provider outage doesn't take your product down.
Build A Fallback

8. What Breaks When You Skip LLM Orchestration?

Without LLM orchestration, one provider outage takes your product down. Retries repeat work, spending drifts with nothing to stop it, and nobody can say why a model answered the way it did. These aren't model problems. They're everything around the model.

Picture the kitchen with no manager. Orders get lost. Someone burns the sauce twice. Nobody knows what anything cost. Yeah, it's that.

A provider returns errors: No fallback means your feature goes down right along with them.
A retry repeats a side effect: The customer gets two emails, or two refunds.
Spend runs away: A loop or a huge context bill shows up at the end of the month instead of the moment it starts.
A model updates quietly: Output changes, and you've got no record of which model ran which request.
An auditor asks why: And you can't show the inputs, the model, or who approved it.

Most of this comes down to keeping state and records. A durable execution layer keeps state across failures, and LLM observability shows you what happened inside each call. Once people depend on the feature, you want both.

9. How Do You Decide What to Build First?

Build first whatever is failing in production today. Add fallback if outages hurt. Add routing if cost does. Add a pipeline framework if prompts are tangled, and a workflow engine once retries, approvals, or audit trails turn into manual work.

Here's the quick cheat sheet.

Outages or rate limits hurt. Add a gateway with fallback.
The bill is too high. Add routing or a cascade, and check answer quality before and after.
Prompts and tool calls are tangled. Move them into a framework.
Retries, approvals, or audit trails are manual. Add a workflow engine.

A good path is one model and a fallback to start. Add routing once cost starts to sting, then a workflow layer when the process around the model gets bigger. And only fix things you've actually seen break, not things you're just nervous about.

In a Nutshell

Orchestration is really three jobs wearing one name. Choose the model, build the pipeline, and run it durably. Then fix whichever layer is failing first. That order keeps you from buying a tool for a problem you don't have yet.

So yeah, that's the whole thing. If outages are what keep you up, start with a gateway and fallback. If the bill is scary, start with routing. If you're drowning in retries and approvals, look at a workflow engine.

Not sure which one is you? Check your last outage or your last wild bill. It's usually right there.

And the goal, like always, is that a model failing is boring. Not a fire.

API Authentication Without the Middleware Layer

The Unmeshed Team — Wed, 28 Oct 2026 05:26:22 +0000

Think about walking into an office building. Before you reach the elevator, someone at the front desk asks who you are, checks your name on a list, and hands you a badge. Only then can you go up.

Every request from a phone or a browser gets the same treatment. Something has to ask "who is this?" before the request gets anywhere near your data.

Many teams build a small service just to be that front desk. It works, but now there's one more service to build, run and keep up to date.

What that layer is really doing

When an API is open to end-user devices, a mobile app, a browser, an IoT sensor, the identity of the caller matters. Authentication has three jobs there:

Check that the call is legitimate
Keep sensitive data away from anyone who shouldn't see it
Tell the rest of the system who is asking, so later steps can act on it

The third one gets forgotten. A purchase request is not just "someone bought something." It's "this customer bought this," and that decides which discount applies and whose payment gets charged.

In a Backend-for-Frontend setup, a middleware layer usually handles all three. The catch is that it becomes its own service with its own deployments, its own bugs, and its own place where every authentication change has to land.

Moving authentication into the execution layer

The other option is to do the check where the API call is already handled. In Unmeshed, each endpoint you expose can be tied to an authentication connection, such as Auth0, Okta or plain API keys, and you can set up more than one. Each endpoint gets its own security level, so a public status call and a payment call don't have to follow the same rule.

Once the caller is verified, their identity goes into the workflow with the request. Nothing sits between the client and the workflow translating who they are.

An e-commerce example shows why that's handy. A customer taps "buy" in a mobile app or a browser. The workflow already knows who they are, so it can apply their personal discount, check inventory and secure the payment, without a separate service having to hand that identity over first.

Before you drop a middleware layer

One thing is worth checking first. If your BFF only does authentication, removing it is simple. If it also reshapes responses or combines data from several services, that work still needs a home. A workflow can take it on, but plan for it instead of assuming it disappears.

A few questions help decide whether the approach fits:

Can each endpoint have its own authentication rule?
Can you use more than one provider at the same time?
Is the caller's identity available to every step in the workflow?
Are credentials stored in one place instead of being copied between services?

The fewer separate services involved in checking who's calling, the fewer places a mistake can hide. If you're maintaining a layer that exists mostly for authentication, Unmeshed is worth a look, because it handles that check in the same place the API call runs.

Your Workflow Asked Too Early (How to Add a Wait Step)

The Unmeshed Team — Tue, 27 Oct 2026 05:12:47 +0000

Someone signs up for your app. One second later, the workflow asks for their promotions and gets nothing back.

Nothing is broken. The workflow just asked too early. The new account was still being set up behind the scenes, so the promotions couldn't find it yet. Ask again three seconds later and they show up.

A wait step is how you fix that. It tells the workflow to pause for a moment, then carry on.

Why not just sleep?

A three-second pause is easy anywhere. The harder cases are the long ones. A review period that lasts two days. A report that can only run after the quarter closes. A trading window that opens next Monday.

You don't want a process sitting in memory for two days, or an engineer setting a reminder to trigger the next step. You want the workflow to pause, keep its place, and pick up on its own when the time comes.

Three reasons to wait

Let a system catch up. Indexing, replication, a downstream job that needs a moment. The pause removes a whole class of ""it worked on the second try"" bugs.
Wait for a date. The first of January for annual processes, the end of a financial quarter for reporting, the start of a trading window.
Respect a required delay. Approval flows with a mandatory review period, settlements with a clearing time, compliance steps that mandate a waiting window.

In all three, time is part of the business logic, not a technical detail.

How it works in Unmeshed

The wait step is a built-in task. You drag it between two steps and give it a small piece of JavaScript that decides how long to wait. The code returns a field called waitUntil, which is a timestamp in epoch milliseconds. Until that moment, the workflow stays paused. After it, the next step runs.

For the signup example, the wait is the step's own start time plus three seconds. For a fixed date, you return that date's timestamp instead. The same step covers both, because it only cares about the moment to resume.

What you get for it

The wait lives inside the workflow, so you don't need an outside scheduler or a cron job to trigger the next step, and nobody has to rerun anything by hand. It also stays visible. You can open a run and see that it's waiting, and until when, instead of wondering whether it's stuck.

Real processes rarely happen all at once. If yours include a pause, whether it's a few seconds or a few months, model it as a step. Unmeshed lets you handle time the same way you handle API calls."

Where's My Package? Three API Calls to Find Out

The Unmeshed Team — Mon, 26 Oct 2026 05:14:12 +0000

A customer writes in: where's my package?

To answer, you start with their account. The account leads to their orders. One of those orders has an ID, and only with that ID can you ask the shipping service where the package is.

Three questions, asked in order, each one waiting on the answer before it. That's an API chain. None of it can run side by side, and if one answer comes back empty, the next question has nothing to go on.

What a chain actually needs

In API terms, that's three services: users, orders and shipping, each called with something the last one returned.

The hard part isn't making the calls. It's moving data between them. Somebody has to pick the right field out of one response, hand it to the next request, and decide what happens if the field isn't there. In most codebases that's hand-written glue, repeated for every new chain.

Passing data from step to step

In Unmeshed, each call is a step in a workflow, and a later step can reference the output of an earlier one using double curly brackets. So the order step can read a value from the user step's response, and the shipping step can read the order ID from the order step. You build the three calls as HTTP GET tasks, wire the references, and the platform runs them in order.

You never write the code that passes the values along. You also get a visual trace of the run, so you can open each step and see exactly what went in and what came back.

Three ways chains go wrong

A field is missing or shaped differently. The next call depends on it, so it fails or runs with an empty value. This is why every service in the chain should return JSON with consistent, predictable fields.
A step fails halfway. The earlier calls already happened. You need to know where it stopped, and you want to rerun from there, not from the beginning.
Environment details are baked in. Hard-coded URLs make a flow that works in testing and breaks in production. Keep the configuration separate from the logic so the same flow runs in more than one environment.

Keeping it reviewable

A flow that lives only in a visual editor is hard to review and hard to roll back. Unmeshed lets you export process definitions as JSON, so a chain can be versioned, reviewed and deployed with the rest of your code.

Chained calls are one of the most common integration patterns, and they're also the one most likely to turn into a pile of glue code nobody wants to touch. If you have a chain like this, try building it in Unmeshed and compare it with what you maintain today.

6 CrewAI Alternatives for Multi-Agent Systems (and When to Stay on CrewAI)

The Unmeshed Team — Fri, 23 Oct 2026 06:56:47 +0000

TLDR

Teams leave CrewAI over specific limits. The free hosted plan stops at 50 executions a month; SSO and a dedicated VPC need custom Enterprise, and the role model doesn't fit every problem.
"CrewAI can't branch" is outdated, because Flows now has routing, saved state, and human feedback.
The six alternatives are LangGraph, Microsoft Agent Framework, Google ADK, AG2, the OpenAI Agents SDK, and Unmeshed. Each has one honest tradeoff.
Frameworks shape how agents think. A runtime like Unmeshed handles durability, approvals, spend limits, and audit, and it can run your existing crews.
Stay on CrewAI if your agents map to roles, your volume fits your plan, and Flows covers your routing. Otherwise, move in stages by wrapping crews as workflow steps.

The best CrewAI alternatives for multi-agent systems are LangGraph, Microsoft Agent Framework, Google ADK, AG2, the OpenAI Agents SDK, and Unmeshed, and the right one depends on why you're leaving CrewAI.

Most lists skip that part, and several still repeat complaints that no longer hold. CrewAI Flows now supports conditional routing, persisted state, and human feedback, so "it can't branch" is out of date.

The real limits are narrower. The free hosted plan stops at 50 executions a month, SSO and your own VPC sit behind a custom Enterprise deal, and the role-based crew model doesn't fit every problem.

This guide sorts six CrewAI competitors by the limit you actually hit, says what each one fixes, and tells you when staying on CrewAI is the better call.

One note on bias. Unmeshed is our product, and it's on the list. We'll say what it does well and what it doesn't do, and you can judge the rest.

1. Why Do Teams Look for CrewAI Alternatives?

Teams look for CrewAI alternatives when they hit a specific limit, usually the 50 execution free plan, governance locked behind Enterprise, a crew model that fights their workflow, or a missing durability layer. Outdated complaints about branching no longer apply.

Here are the four limits we see most, and what is true about each.

The free plan is small: The hosted free tier includes 50 workflow executions a month and 2 automations, according to CrewAI's pricing page. Fine for a prototype, tight for anything with real traffic.
Enterprise controls cost a conversation: SSO through Entra or Okta, role-based access, and a dedicated VPC are listed on the custom Enterprise plan, which also comes with a 45-day onboarding.
The crew model doesn't fit everything: Role-based agents with goals and backstories suit some problems. They add friction when you want an explicit graph, a fixed pipeline, or one agent with many tools.
Production needs more than a framework: Retries across crashes, approvals, spend limits, and audit trails live in a layer around the agents, not in the agents themselves.

What is not a limit anymore is branching. Flows has @router for conditional paths, @persist for saved state, and @human_feedback for approvals. If a review told you CrewAI can't branch, check the date on it.

If you want CrewAI's own pricing side by side, our CrewAI alternative comparison page covers it. Cost is also a design question for agents, which we cover in token efficiency.

2. What Should You Look for in a CrewAI Alternative?

Judge a CrewAI alternative on five things, which are how it coordinates agents, whether it survives a crash, how it handles human approval, what it costs to run, and who maintains it. A multi-agent framework comparison that skips these will mislead you.

Gartner expects over 40% of agentic AI projects to be canceled by the end of 2027, citing cost, unclear value, and weak risk controls. Those are the same five areas.

Criterion	What to Ask
Coordination model	Roles, graphs, handoffs, or conversations? Does it match how your problem is shaped?
Durability	If the process dies at step six, does it resume at step six?
Human in the loop	Can a person approve or edit a step and the run waits?
Cost and licensing	Is it open source, hosted, or both? What happens past the free limit?
Maintenance	Who ships fixes, and how often do releases break your code?

If any of these terms are new, our guide to AI orchestration covers the basics. For the broader stack that agents run on, see agent infrastructure.

3. What Are the 6 Best CrewAI Alternatives for Multi-Agent Systems?

The six best CrewAI alternatives are LangGraph, Microsoft Agent Framework, Google ADK, AG2, the OpenAI Agents SDK, and Unmeshed. The first five are frameworks that shape how agents reason. Unmeshed is a runtime that runs agents, including CrewAI crews, as governed steps.

Tool	What It Fixes	License
LangGraph	Explicit graphs with durable state	MIT
Microsoft Agent Framework	Graph workflows with checkpointing, Python and .NET	MIT
Google ADK	Graph workflows with agent-to-agent delegation	Apache 2.0
AG2	Conversation based multi agent patterns	Apache 2.0
OpenAI Agents SDK	A small set of primitives with built-in tracing	Open source
Unmeshed	Durability, approvals, spend limits, and audit around any agent	Platform, free tier

1. LangGraph

LangGraph fixes the crew model's lack of an explicit graph. It is a low-level orchestration framework for stateful agents, where you define nodes and edges yourself and the framework saves state at each step so a run can resume.

Durable execution, so a run can resume after a failure
Human-in-the-loop support, plus short- and long-term memory
MIT-licensed, with LangSmith available for debugging and deployment
A JavaScript version, LangGraph.js, for TypeScript teams

Real tradeoff: You write more code than you would in CrewAI, and the LangChain ecosystem pulls you toward its other tools.

We compare it further in our guide to LangGraph alternatives.

2. Microsoft Agent Framework

Microsoft Agent Framework fits teams on Azure or .NET that want graph workflows with checkpointing in one supported toolkit. The open-source framework supports Python and .NET and ships migration guides from AutoGen and Semantic Kernel.

Graph workflows with sequential, concurrent, handoff, and group collaboration patterns
Checkpointing, streaming, and time travel for debugging
Human in the loop and OpenTelemetry support
MIT licensed

Real tradeoff: It reached general availability in April 2026, so its production record is shorter than older frameworks.

3. Google ADK

Google ADK fits teams that want a graph runtime and agent to agent delegation in one open source toolkit. Version 2.0 of the Agent Development Kit adds a workflow runtime with routing, fan out and fan in, loops, retries, and nested workflows.

A Task API for delegating work between agents
State, human-in-the-loop, and dynamic nodes inside workflows
Apache 2.0 licensed, Python 3.10 or later

Real tradeoff: Version 2.0 includes breaking changes from 1.x, so budget time if you build on older examples.

4. AG2

AG2, formerly AutoGen, fits teams that think of multi-agent systems as conversations between agents. The Apache 2.0 project is maintained by volunteers from several organizations, and version 1.0 is a newly rebuilt, protocol driven framework.

Agents, tools, and a human-in-the-loop hook
Networks with typed channels for conversation, consulting, discussion, and workflow patterns
The earlier version lives on as AG2 Classic, still maintained

Real tradeoff: Version 1.0 is not a drop-in upgrade from AG2 Classic, and volunteer maintenance means you should check release activity before committing.

5. OpenAI Agents SDK

The OpenAI Agents SDK fits teams that want the smallest possible set of building blocks. The SDK is the production upgrade of Swarm and centers on agents, handoffs or agents as tools, and guardrails, with tracing built in from the start.

Built-in tracing and sessions for conversation memory
Human in the loop and MCP support
Works with non-OpenAI models through adapters

Real tradeoff: OpenAI models are the default path. Surviving a process crash is something you add around the SDK rather than get from it.

6. Unmeshed

Unmeshed fixes what frameworks leave open, which is running agents reliably in production. The agent orchestration platform runs agents as steps in durable workflows, with retries, approvals, spend limits, and a full run history, and it can run CrewAI crews too.

Agents are bound to a fixed tool set that the runtime enforces, and each agent can have a spend ceiling that throttles it or switches it to a cheaper model. See AI agent governance.
Human-in-the-loop approvals pause a run until a person decides.
Built on workflows by the creators of Netflix Conductor, with SDKs for Java, Go, Python, and TypeScript.
Model-agnostic and MCP native. The free tier includes 2,000 workflow executions a month.

Real tradeoff: Unmeshed is not a reasoning framework and doesn't replace CrewAI's role model. If you like how your crews think, keep them and run them inside Unmeshed.

Keep Your Crews.Add the Runtime

Call your existing CrewAI crew from an Unmeshed worker and get durable state, retries, approvals, and an audit trail without a rewrite.
Add The Runtime.

4. CrewAI vs Alternatives: How Do the Six Compare?

In a CrewAI vs alternatives comparison, the main differences are coordination model and durability. CrewAI uses roles and Flows; LangGraph, Microsoft, and ADK use graphs, AG2 uses conversations, and only Unmeshed treats durability as a separate runtime layer.

This multi-agent framework comparison keeps cells short on purpose. Check each project's docs before you commit, because all of them move fast.

Tool	Coordination	Durability	Human in Loop	Best For
CrewAI	Roles, crews, Flows	Persisted Flow state, SQLite by default	Yes, in Flows	Role-based agent teams
LangGraph	Explicit graph	Durable execution	Yes	Custom stateful agents
Microsoft Agent Framework	Graph workflows	Checkpointing	Yes	Azure and .NET teams
Google ADK	Graph workflows, Task API	Workflow state	Yes	Google Cloud teams
AG2	Conversations, networks	Knowledge store	Yes, via hook	Conversational agents
OpenAI Agents SDK	Handoffs, agents as tools	Sessions	Yes	Small, simple systems
Unmeshed	Workflow with agent steps	Durable execution	Yes	Governed production runs

If your real question is how multi-agent systems coordinate in general, read our guide to agentic orchestration.

5. Are There Open Source CrewAI Alternatives?

Yes, most CrewAI alternatives are open source. LangGraph and Microsoft Agent Framework use the MIT license, Google ADK and AG2 use Apache 2.0, and the OpenAI Agents SDK is an open-source Python package. Unmeshed is a platform with a free tier.

Not all CrewAI alternatives are equal on this front, so read the license for the version you plan to use. Open source means you can read the code and run it yourself. It doesn't mean it's free to operate. You still pay for hosting, models, and the engineers who keep it running.

When you search for agent framework alternatives, check three things beyond the license. See who maintains the project, how often releases break your code, and whether the project is a library or a full runtime. A library gives you building blocks. A runtime gives you something that keeps running.

6. How Do CrewAI Alternatives Handle Durability and Governance?

CrewAI alternatives handle durability and governance differently. LangGraph and ADK keep state inside the framework, the OpenAI Agents SDK adds sessions, and a workflow engine like Unmeshed runs retries, approvals, spend ceilings, and audit as one layer.

Frameworks answer the question of how an agent thinks. Governance answers a different question, which is what the agent is allowed to do and who can see it. Teams often find out the difference after the first incident.

Need	In a Framework	In a Runtime Like Unmeshed
Resume after a crash	Available in some, usually with setup	Built in through durable execution
Limit which tools an agent can use	Convention in your code	Enforced by the runtime
Cap spend per agent	You build it	Per-agent ceilings with throttle or cheaper model
Approvals	Supported in most	Routed to a person, with the run paused
Audit trail	Tracing, often a separate tool	Full run history by default

For the concept behind the first row, see durable execution. For measuring whether agents do the job well, see agent evals.

7. When Should You Stay on CrewAI?

Stay on CrewAI when your problem is a team of role-based agents, you're within the free plan limits or already on Enterprise, and Flows covers your branching. Switching costs time, and none of the six beats it on that fit.

Your agents map cleanly to roles, goals, and tasks
Your volume fits the plan you have
Flows handles your routing and saved state
Your team already knows it

Before you shop for CrewAI alternatives, check whether you need one. If you tick all four, the answer is probably to keep it. If your only gap is production controls around it, add a runtime instead of replacing the framework.

8. How Do You Move Off CrewAI Without Rewriting Everything?

You can move off CrewAI in stages by wrapping existing crews as steps, then replacing the coordination layer one workflow at a time. Keep the agent logic you've tested and change only what runs and governs it.

Pick one crew and run it as a step inside a workflow. Nothing about the crew changes.
Add retries, an approval step, and tracing around it. Our guide to workflow orchestration covers the options.
Move the next crew. Replace the framework only where it truly blocks you.

This order keeps risk low, and it makes the case for or against the other CrewAI alternatives with real data from your own workload. You learn what the new layer does before you commit to it.

Final Thoughts

Pick the alternative that fixes your actual limit. If CrewAI's graph is the problem, look at LangGraph, Microsoft Agent Framework, or Google ADK. Of all the CrewAI alternatives here, the best fit is the one that matches your problem, not the one with the most stars. If conversation style fits, try AG2. If you want few moving parts, try the OpenAI Agents SDK.

If your crews work but production feels risky, you may not need a new framework. You may need a runtime around the one you have. That's the gap Unmeshed fills.

Your AI Agent Does Not Need Root Access: A Guide to Agentic Orchestration

The Unmeshed Team — Thu, 22 Oct 2026 05:23:16 +0000

TLDR

Agentic orchestration coordinates AI agents that choose their own next steps. It decides who acts, what they see, which tools they get, and when a person approves.
Traditional orchestration runs a fixed path, while agentic orchestration bounds a path the model picks as it runs. It needs more control, not less.
The five core patterns are sequential, parallel, routing, orchestrator and workers, and evaluator loops. Start with the simplest one that works.
Give each step the least autonomy that does the job. Go from a fixed rule to a model call to an agent only when the simpler option fails.
Production needs five controls around the agent: spend ceilings, scoped tools, approval gates, step limits, and tracing. Unmeshed covers these inside durable workflows, but it isn't an agent reasoning framework.

Agentic orchestration is the coordination layer that manages AI agents that choose their own next steps, deciding which agent acts, what context it gets, which tools it may use, and when a person must approve. It is orchestration for systems where the path is not fixed in advance.

Most explanations stop at that definition and a diagram of agents passing messages. The harder question is how much freedom each step should get. Gartner expects over 40% of agentic AI projects to be canceled by the end of 2027, citing cost, unclear value, and weak risk controls.

This guide covers what agentic orchestration is, how it differs from traditional orchestration, the core patterns, and the controls that keep agents inside safe limits. We'll also say where Unmeshed fits and where it doesn't.

1. What Is Agentic Orchestration?

The key word is choose. In a fixed workflow, a developer decides every step before the run starts. In an agentic system, a model decides some of them while the run is happening. Someone has to set the limits on that choice, and that someone is the orchestrator.

It helps to say what it is not. It isn't one big agent doing everything. It isn't a prompt chain with a fancier name. And it isn't an agent framework on its own, because a framework shapes how one agent reasons while orchestration governs how agents run together.

The orchestrator owns five decisions:

Which agent or tool acts next
What context each agent sees
Which tools each agent may call
When the run stops, retries, or escalates
When a person has to approve

2. How Is Agentic Orchestration Different From Traditional Orchestration?

Traditional orchestration runs steps along a path you define in advance. Agentic orchestration coordinates steps where an AI model decides the path as it runs, so the orchestrator has to bound that freedom with limits, approvals, and logging.

Traditional orchestration is what workflow engines and API orchestrators do. Our guide to AI orchestration covers the wider term, including pipelines and model routing. This post covers the narrower case where the path itself is not fixed.

Dimension	Traditional	Agentic
Who decides the path	The developer, in advance	The model, at runtime
Predictability	Same input follows the same path	Same input can take different paths
Typical failure	A step errors out	An agent loops, picks the wrong tool, or compounds an early mistake
Cost shape	Fixed per run	Varies with the steps the model chooses to take
What the orchestrator adds	Retries and scheduling	Limits, approvals, tool scoping, and tracing

That last row is the point. An agentic system doesn't need less orchestration. It needs more.

3. What Are Agentic Workflows, and How Do They Differ From Agents?

Agentic workflows are multi-step processes where AI models decide some of the steps inside a defined structure. An AI agent is a system that directs its own process and tool use. The workflow sets the boundary, and the agent acts inside it.

Anthropic draws the same line in its guide to building effective agents. Workflows orchestrate models and tools through predefined code paths, while agents let the model direct its own process and tool usage.

A workflow

The path is set in code
The model fills in content or makes bounded choices
It's easy to test, audit, and explain

An agent

The model picks the next action in a loop
It uses tools and feedback from each step to decide what to do
It's harder to predict and costs more per run

Most production systems mix both. A workflow handles intake, validation, and approvals, and an agent handles the one step that needs judgment. If you're choosing a framework for that agent step, our guide to agent frameworks compares six.

4. What Are the Core Agentic Orchestration Patterns?

The core agentic orchestration patterns are sequential, parallel, routing, orchestrator and workers, and evaluator loops. Each trades predictability against flexibility, and most production systems combine two or three of them.

Anthropic and Google Cloud describe overlapping sets. This table pulls the common ones together.

Pattern	How It Works	Main Risk
Sequential	Agents run in a fixed order, and each one feeds the next	One weak step weakens every step after it
Parallel	Agents work at the same time, and the results are merged	Conflicting outputs and higher token use
Routing	A classifier sends each request to the best-fit agent	Requests sent to the wrong agent
Orchestrator and workers	A lead agent splits the task and delegates the pieces	Runaway delegation and cost
Evaluator loop	One agent drafts, another critiques, and the cycle repeats	Loops that never converge

Google Cloud warns that a loop can run indefinitely if its exit condition is wrong. That's why every loop needs a maximum number of iterations.

Start with the simplest pattern that works. Sequential and parallel patterns run on fixed logic with no model choosing the route, so they cost less and behave more predictably. Reach for orchestrator and workers only when you truly can't know the steps in advance.

5. How Does Autonomous Agent Coordination Work?

Autonomous agent coordination is how multiple agents hand off work, share state, and avoid conflicting actions without a person directing each step. It depends on explicit handoff rules, one source of shared state, and hard stop conditions.

Handoffs: Define what one agent passes to the next and in what shape. Loose, free-text handoffs are where context gets lost.
Shared state: Keep one record of the run that every agent reads and writes, instead of each agent carrying its own copy.
Context scoping: Give each agent only the context its task needs. Google Cloud calls managing this flow context engineering.
Conflict control: If two agents can change the same record, decide which one wins before they ever run.
Stop conditions: Set step limits, timeouts, and a spend cap, so a stuck agent ends the run instead of draining it.

Shared state and stop conditions are infrastructure problems, not prompt problems. They're why agent infrastructure has become its own topic, and why runs need durable execution to survive a crash halfway through.

6. How Much Autonomy Should Each Step Get?

Give each step the least autonomy that still does the job. Use a fixed rule when the answer is known, a single model call when the input is messy, and an agent loop only when the steps can't be predicted in advance.

Think of autonomy as a dial, not a switch. Each notch adds flexibility, and it also adds cost, variance, and review work.

Level	Use It When	Example	Cost and Review
Fixed rule	The answer is known	Is this request a duplicate?	Lowest, nothing to review
Single model call	The input is messy, but the output is bounded	Classify a support email	Low, spot check the output
Workflow with an agent step	One step needs judgment, and the rest is fixed	An agent researches a customer, then a rule decides what happens	Moderate, review flagged runs
Fully autonomous agent	The steps can't be predicted at all	Open-ended research or coding	Highest, needs strong limits

Gartner's guidance maps to the same dial. It recommends agents where decisions are needed, automation for routine workflows, and assistants for simple retrieval.

Most teams start too far to the right. The cheaper path is to begin with a rule, promote a step to a model call when the input gets messy, and promote it to an agent only when the simpler version fails.

7. What Controls Does Agentic AI Orchestration Need in Production?

Agentic AI orchestration needs five production controls, which are spend ceilings, scoped tool access, approval gates, step limits, and full tracing. They stop an agent's freedom from turning into cost overruns or actions nobody reviewed.

Gartner expects over 40% of agentic AI projects to be canceled by the end of 2027 because of escalating costs, unclear business value, or inadequate risk controls. Each control below answers one of those reasons.

Spend ceilings: Cap what each agent can spend, and throttle it or switch it to a cheaper model near the cap. Cost grows with every extra step a model takes, so see our guide to token efficiency for where the money goes.
Scoped tool access: Bind each agent to a fixed list of tools, enforced by the runtime and not by a line in a prompt.
Approval gates: Pause the run before any action that is expensive to reverse, such as a payment or a deletion. A human-in-the-loop step does this and resumes the run once a person approves.
Step limits: End the run after a maximum number of steps or minutes, so a loop can't run forever.
Full tracing: Log every model call, tool call, and cost. LLM observability shows what happened, and agent evals show whether the result was any good.

None of these controls live inside the agent. They sit around it, which is why AI agent governance is a workflow concern and not a prompt concern.

8. What Should You Look For in an Agent Orchestration Platform?

An agent orchestration platform should add durable state, retries, approvals, tool scoping, spend tracking, and an audit trail around whichever agent framework you use. It runs the agents. It does not replace their reasoning.

The market mixes three different things under one label. Frameworks shape how an agent reasons. Cloud suites bundle models and agent builders for one vendor's stack. Workflow engines run durable, governed processes around any of them. Know which one you're buying.

Criterion	What To Ask
Durability	Does a run survive a crash or a redeploy and resume where it stopped?
Tool scoping	Does the runtime stop an agent from calling a tool it wasn't given?
Spend controls	Can you set a ceiling per agent and see cost per run?
Human approval	Can a run pause for sign-off and resume on its own?
Observability	Can you inspect every model call, tool call, and retry?
Framework neutrality	Can you keep the agent framework your team already uses?
Cost shape	Does pricing grow with actions or stay predictable?

Watch for agent washing as well. Gartner estimates that only about 130 of the thousands of agentic AI vendors are real, because many rebrand chatbots and RPA without real agentic capability. Ask any vendor to show you the run history of a failed agent step.

For the engine layer, see our roundup of workflow orchestration tools.

9. When Should You Avoid Agentic Orchestration?

Avoid agentic orchestration when the steps are known in advance, when one model call solves the task, or when an error is costly and can't be reviewed. Gartner says many use cases sold as agentic don't need an agentic setup.

Gartner analyst Anushree Verma put it plainly: "Many use cases positioned as agentic today don't require agentic implementations."

Google Cloud's guide makes the same point. Tasks like summarizing a document, translating text, or classifying customer feedback usually don't need an agentic workflow.

Skip it when

The steps are known in advance
A single model call solves the task
A wrong action is expensive, and no one can review it first

Use it when

The steps can't be predicted ahead of time
The task needs tools and outside data across several steps
You can check the outcome and cap the spend
Risky actions can pause for a person to approve

Skipping it is a fine answer. A fixed workflow with one model step costs less, breaks less, and is easier to explain.

10. How Does Unmeshed Handle Agentic Orchestration?

Unmeshed handles agentic orchestration by running agent steps inside durable, governed workflows. Each agent is bound to a fixed set of tools, tracked against a spend ceiling, and logged, while rules and approvals handle the decisions a model shouldn't make.

What it covers

Workflows with durable execution, so agent state survives crashes and redeploys
Agent orchestration steps that run on the same engine as your fixed steps
Tool binding enforced by the runtime, so an agent can't call a tool it wasn't given
Per-agent spend ceilings that throttle the agent or move it to a cheaper model near the cap
A built-in decision engine for rules a model shouldn't decide on every run
Approval steps that pause a run and resume it once a person signs off
MCP native tools, model agnostic, and a full run history of every model call, tool call, and cost

What it doesn't do

It isn't an agent reasoning framework. Keep LangChain, CrewAI, or your own loop inside a worker, and Unmeshed makes each step durable, retried, and audited.
It doesn't train models, and it isn't an LLM gateway for routing across providers.

The practical difference

Teams usually stitch this together from a workflow engine, an approval tool, and a cost tracker. Unmeshed puts durable state, approvals, rules, spend tracking, and run history in one system, built by the creators of Netflix Conductor.

Let The Agent Reason. Let The Workflow Set The Limits.
Bind your agent to approved tools, cap its spend, and send risky actions to a person. See all three in one governed flow.
Set The Guardrails

In a Nutshell

Agentic orchestration isn't a choice between using agents and skipping them. It's a choice about how much freedom each step gets and what limits surround it.

Start with a rule. Add a model call where the input is messy. Add an agent only where the steps can't be predicted. Then put spend ceilings, scoped tools, approval gates, step limits, and tracing around it.

Gartner's cancellation forecast comes down to cost and missing controls as much as missing value. The projects most at risk are the ones with no limits around the agent.

Stop Making Your APIs Wait in Line

The Unmeshed Team — Wed, 21 Oct 2026 05:40:13 +0000

Most slow pages aren't slow because of one bad API. They're slow because the calls were put in a line, and everyone waits for their turn.

Take a product page that needs customer reviews, recently purchased items, and a "you may also like" list. Three endpoints, the same SKU ID, the same API key, and one clean response at the end. Nothing about that needs to be a queue.

The easy version is slow

The obvious way to build this is one call after another. Call reviews, wait. Call recent purchases, wait. Call recommendations, wait. Merge the results. It's simple, and it works.

The trouble is the waiting. Imagine the three calls take 200, 300 and 250 milliseconds. In a line, the page waits 750 milliseconds. Nothing is wrong with any single call, but the total keeps growing with every service you add.

Run them together

None of those calls needs the answer from another. Reviews don't depend on recommendations. So they can all start at once, and the page waits only for the slowest one. With the same numbers, that's about 300 milliseconds instead of 750.

One rule decides whether this works: the calls have to be independent. If the second call needs data from the first, it has to wait. When they don't depend on each other, running them in parallel is free speed.

What the rest of the job looks like

Speed is only part of it. A good aggregation also needs:

The same SKU ID passed into all three calls, without copying it three times by hand
The API key kept out of your code, in a secrets store
A final step that merges the three responses into one shape, such as reviews, recent and youMayAlsoLike
A decision about failure: if one call fails, do you return an error, or return the other two?

That last one is easy to forget. Decide it up front, not after the first outage.

How we build it in Unmeshed

In Unmeshed, each call is an HTTP step. The SKU ID comes from the flow's input, and the key comes from a stored secret, so nothing sensitive lives in the flow itself. A small JavaScript step takes the three outputs and puts them into the final response.

At first the three steps run one after another. To switch to parallel, you add a Parallel step and drag the three calls into it. No backend changes are needed, because the services don't know or care how they're being called. After that, a visual timeline shows where the time goes, so you can see which call is the slowest one holding everything back.

If you're gluing several APIs together by hand today, try Unmeshed on a flow like this one. It's a small example, but the pattern of defining the calls, merging the output, and running independent work in parallel carries over to much bigger ones.

Register a Python Function, Run It From a Workflow, and Rerun Failed Runs

The Unmeshed Team — Fri, 16 Oct 2026 06:45:24 +0000

Picture the last place you ordered food at a counter. The cashier hands you a buzzer, and now you've got a choice. You can stand there staring at the kitchen like it owes you money, or you can take the buzzer to a table and scroll your phone until it goes off.

Either way the order slip does the same thing. It says what you want, and the right cook in the back picks it up because that's the dish they make. Nobody walks into the kitchen hunting for a person. The name on the slip does the routing.

That's how running a workflow from Python works with the Unmeshed SDK. Your function is the cook and the step name is the dish on the slip. You get the same two choices as the buzzer, wait for the result or come back later.

Install the SDK and connect

Install the package from PyPI.

pip install unmeshed-sdk

Then build a client. You need an API client ID and auth token from your Unmeshed instance, plus the URL and port where it runs. This example points at a local instance.

from unmeshed.sdk.configs.client_config import ClientConfig
from unmeshed.sdk.unmeshed_client import UnmeshedClient

client_config = ClientConfig()
client_config.set_client_id("your-client-id")
client_config.set_auth_token("your-auth-token")
client_config.set_base_url("http://localhost")
client_config.set_port(8080)

client_config.set_initial_delay_millis(50)
client_config.set_step_timeout_millis(3600000)
client_config.set_work_request_batch_size(200)
client_config.set_response_submit_batch_size(1000)
client_config.set_max_threads_count(10)
client_config.set_poll_interval_millis(10)

client = UnmeshedClient(client_config)

The first four settings say who you are and where to connect. The rest tune how the worker polls for work and how many threads it uses. Two of them matter later in this post.

Write the function and register it

A worker is a plain Python function. It takes a dict and returns a dict. Sync and async functions both work.

from unmeshed.sdk.apis.workers.worker import Worker

def sample_function(input_dict: dict) -> dict:
    return {
        "message": "Hello, world! sample_function",
        "input_received": input_dict,
    }

client.register_worker(
    Worker(
        execution_method=sample_function,
        name="sample_function",
        namespace="default",
        max_in_progress=100,
    )
)

client.start()

The name is the slip. When a process reaches a step called sample_function, the SDK calls your function with that step's input and sends the result back. Registering says which cook works which station, and client.start() opens the kitchen. From then on the worker listens for tasks.

If registration fails with a 403, check the client's Allowed Workers Policy in the platform. It's a permission on the credentials and needs no code change.

There's also a decorator version, @worker_function, that takes the same name, namespace and max_in_progress. Use whichever reads better in your codebase.

Add a step with the same name

The function won't run until a process has a step to call it. Here's a minimal process definition with one WORKER step. Import it, or build the same thing in the visual editor.

{
  "namespace": "default",
  "name": "test_process",
  "version": 1,
  "type": "API_ORCHESTRATION",
  "steps": [
    {
      "name": "sample_function",
      "type": "WORKER",
      "ref": "say_hello",
      "input": {
        "test1": "{{ context.input.test1 }}"
      }
    }
  ]
}

The step's name has to match the name you registered. That's the whole link between the two. The ref is the step's own ID inside the process, and the input line passes the request's test1 value into your function.

Run it and choose how to wait

Keep your worker running. In a second script, build the client the same way as in step one and run the process.

from unmeshed.sdk.common.process_request_data import ProcessRequestData

# Stand at the counter and wait.
sync_request = ProcessRequestData(
    namespace="default",
    name="test_process",
    version=1,
    requestId="req001",
    correlationId="corr001",
    input={"test1": "value", "test2": 100, "test3": 100.0},
)
process_data = client.run_process_sync(sync_request)
print(process_data.to_json())

# Take the buzzer and carry on.
async_request = ProcessRequestData(
    namespace="default",
    name="test_process",
    version=1,
    requestId="req002",
    correlationId="corr001",
    input={"test1": "value", "test2": 100, "test3": 100.0},
)
async_data = client.run_process_async(async_request)
print(async_data.to_json())

run_process_sync waits for the process to finish and hands back the result. run_process_async starts it and returns right away, which suits long jobs. The request ID identifies this request and the correlation ID ties related runs together, so give each run its own request ID.

When an order goes wrong

Every run gets a process ID, and that's your handle for everything that follows. Fetch a run to see what happened. Steps are left out by default, so ask for them.

run = client.get_process_data(process_data.processId, include_steps=True)
print(run.to_json())

If it failed and you've fixed the cause, send the plate back to the kitchen.

rerun_data = client.rerun(process_id=process_data.processId, version=1)
print(rerun_data.to_json())

A rerun runs the process again, so any step that sends an email or moves money can do it again. Check that your steps are safe to repeat first.

To stop or recover a batch, pass a list of process IDs.

# Cancel running orders.
response = client.bulk_terminate(process_ids=[process_data.processId])
print(response.details)

# Put failed or terminated orders back on the line.
response = client.bulk_resume(process_ids=[process_data.processId])
print(response.details)

There's also bulk_reviewed for marking failed or terminated runs as reviewed. And search_process_executions finds runs by name, status or correlation ID before you act on them.

The gotcha with max_in_progress

Here's the one that surprises people. The docs give a simple formula. Available tasks equal max in progress minus tasks currently in progress. A task counts as in progress from the moment the worker polls it until it submits the final result.

Now look at the numbers in this post. The worker allows 100 in progress, but the thread pool has 10 threads. A synchronous function runs up to ten at a time, and the rest wait in a memory queue. An async function that blocks on something slow causes the same pileup. A cook can hold a hundred tickets and still only have ten burners.

You have two ways out. Raise the thread pool or write async code that doesn't block. If your tasks finish quickly you may not need either, because a higher max_in_progress can be enough. You can also run more than one worker instance. A single poll request covers all registered workers, so a low poll interval is generally safe.

Where this fits

Unmeshed also has a built in Python step that runs a script inside the process itself. The SDK worker is for code that lives in your own application and runs wherever you start it.

That's the whole loop. Name a function, register it, add a step with the same name, run the process, and read the trail when something breaks.

If you've tuned a worker pool like this before, what bit you first? The thread pool or a call that quietly blocked?

Reliable API Workflows: Retries, Secrets, Traces

The Unmeshed Team — Thu, 15 Oct 2026 05:44:07 +0000

Calling an API takes about five lines of code. It works on your laptop, you feel good, and you ship it.

Then production shows up. The other service goes down for a minute. Someone asks where the API key is stored. A partner emails to say you're sending too many requests. And at 2 AM something fails, and nobody can tell which call did it.

None of that was in the five lines.

The same work, again and again

Retries, secrets, rate limits, routing, logging. Every new integration needs all of it, so teams write it again each time. The versions never quite match, because each one was written by a different person on a different deadline. After a while, nobody is sure how any of them behave.

It gets worse when calls are chained. Picture a flow that pulls market data, validates a trade, executes it, and hands off to settlement. Every stage is a separate service, and when one fails halfway, the earlier steps have already happened. You can't just run the whole thing again. You need to know exactly where it stopped.

A commodity trading firm in one of our case studies faced this while keeping a real-time dashboard, trade validation and high-value transaction tracking stable. Stitching APIs together by hand, writing custom retry logic and hunting through logs was taking too much of the team's time.

What changes when the flow is defined once

The fix is to stop burying this logic in code. You describe the flow as steps, and each step makes one call. A later step can use the output of an earlier one, so data moves along without extra glue. A retry becomes a setting on the step, with a delay you pick, not a loop someone has to write and maintain.

The second half is the record. When every run is saved step by step, you can see who started it, what went in, what each call returned, and where it broke. You can replay it, too, instead of guessing. That means the operations team can debug without waiting for the developer who built the integration.

Five questions to ask before you choose a tool

Can you see a full trace of every run, with inputs and outputs?
Can you replay a failed run without rebuilding it by hand?
Are secrets and logins handled in one place, not copied into every service?
Can you set rate limits and routing rules without writing your own middleware?
Can the flow be exported, reviewed and versioned like normal code?

The last one matters more than it seems. If a flow lives only in a visual editor, it's hard to review and hard to roll back. Exporting it as JSON lets it go through the same CI/CD process as everything else you ship.

Unmeshed handles API orchestration this way. It works with REST and SOAP endpoints, supports Okta, API secrets and custom headers, and uses role-based access so developers, operators and approvers each get the permissions that fit their job.

What Is AI Orchestration? 4 Types That Solve Very Different Problems

The Unmeshed Team — Wed, 14 Oct 2026 06:26:50 +0000

TLDR

AI orchestration means four different jobs sharing one name: pipeline, model and LLM, multi-agent, and AI workflow coordination.
The definition is one sentence about coordinating models, agents, pipelines, and business logic with context and a record.
Gartner expects 40% of enterprise apps to include task-specific agents by the end of 2026, and one third of agentic implementations to combine different skills by 2027. That makes coordination unavoidable.
Every type follows the same loop. The last two steps, recovering from failure and logging, are the ones teams skip until production.
Unmeshed covers AI workflow coordination only. It doesn't cover training pipelines, model routing, or agent reasoning.

AI orchestration is one of those terms everyone uses, and few people define it the same way. Search it, and you'll find pages about training pipelines, LLM routing, agent teams, and business workflows. All four call themselves AI orchestration.

That gap matters more this year than it did last year. Gartner expects 40% of enterprise applications to include task-specific AI agents by the end of 2026, up from less than 5% in 2025. More agents mean more things to coordinate.

AI orchestration

So this guide defines AI orchestration once, then separates the four jobs hiding under the name. You'll see how each one works, what an AI orchestration platform needs to include, and how to pick the one that matches your problem.

We'll also say plainly where Unmeshed fits. It covers one of the four well, and it doesn't pretend to cover the rest.

1. What Is AI Orchestration?

AI orchestration is the coordination of models, agents, data pipelines, and business logic so that AI steps run in the right order, with the right context, and with a record of what happened.

That definition is broad on purpose, because the term is. Four different groups of engineers use it for four different jobs, and the next sections pull them apart.

It helps to say what orchestration is not. A model is not orchestration. A single prompt chain isn't either. And an agent framework handles how one agent reasons, which is only one piece of the coordination problem.

Orchestration decides the things around the model call:

What gets called, and in what order
What context each step receives
What happens when a step fails halfway
Who has to approve what before the run continues
What gets recorded so you can explain the result later

2. Why Does AI Orchestration Matter Now?

AI orchestration matters because organizations are moving beyond standalone AI chatbots to multi-agent systems that need to coordinate complex, end-to-end business workflows.

In August 2025, Gartner predicted that 40% of enterprise applications will include task-specific AI agents by the end of 2026. In the same release, it expects one third of agentic AI implementations to combine agents with different skills by 2027.

That second number is the real driver. Once agents have different skills, someone has to decide which one acts, what it sees, and what happens when it's wrong.

Without that layer, teams run into the same problems in the same order:

Agent sprawl: Every team ships its own agent with its own retry logic and its own idea of state.
Duplicate spend: Two agents call the same model for the same answer, and nobody sees it.
No shared state: A step fails, and the run starts over from zero.
No approval path: A risky action goes through because nothing paused it.
No audit trail: Someone asks why the system did that, and nobody can say.

3. What Are the Four Types of AI Orchestration?

AI orchestration coordinates multiple AI models, data pipelines, and autonomous agents so they can work together as a unified system.

In enterprise and multi-agent architectures, AI orchestration typically follows four primary patterns:

Type	What Gets Coordinated	Typical Tools
AI pipeline orchestration	Training, evaluation, and deployment jobs	Airflow, Kubeflow, Dagster, Prefect
Model and LLM orchestration	Calls, routing, and chaining across models	LLM gateways, chaining libraries
Multi-agent orchestration	Which agent acts next, with what context	Microsoft Agent Framework, CrewAI, LangGraph
AI workflow coordination	AI steps inside business processes, next to APIs, rules, and people	Workflow engines such as Unmeshed

4. How Does AI Pipeline Orchestration Work?

AI pipeline orchestration coordinates data flows, tools, machine learning models, and APIs to run together as a single automated workflow.

Apache Airflow describes itself as an open-source platform for developing, scheduling, and monitoring workflows, including machine learning and model training. Kubeflow Pipelines is built for ML workflows that run as containers on Kubernetes, where each component execution maps to one container.

This type needs:

Scheduling, backfills, and reruns of only the failed tasks
Tracking for artifacts and metadata between steps
Compute and container management at training scale

You probably mean this one if your team trains or tunes models and the work is batch, scheduled, and owned by data scientists.

5. What Is Model and LLM Orchestration?

Model and LLM orchestration is the control layer that manages and routes interactions between large language models, external data sources, APIs, and tools.

This type coordinates calls across models. It routes a request to a cheaper model, falls back when a provider goes down, chains prompts together, and caches repeat answers.

Most teams handle it in an LLM gateway, a single layer that every model call passes through.

This type needs:

Routing and fallback rules across providers
Cost and rate limit controls
Logging of every prompt and response

You probably mean this one if your main worry is which model gets which request, and what it costs.

6. How Does Multi-Agent Orchestration Work?

Multi-agent orchestration coordinates multiple specialized AI agents so they can work together as a single, goal-driven system.

It decides which agent acts next and what it sees when it does. Microsoft Agent Framework, for example, supports sequential, concurrent, handoff, and group collaboration patterns in one SDK.

If you're weighing options, our guide to agent frameworks compares six of them.

This type needs:

Clear handoff rules between agents
Shared context that doesn't get lost between steps
Limits on loops and spend, so one agent can't run away

You probably mean this one if you're building a team of agents that split a task between them.

7. What Is AI Workflow Coordination?

AI workflow coordination, also called AI workflow orchestration, connects AI models, data sources, software tools, and human reviews into a structured, repeatable end-to-end workflow.

It puts AI steps inside a business process, next to APIs, rules, and people. An AI step extracts data from a document, a rules step decides the clear cases, a person approves the exceptions, and the whole run is logged.

The model is one step among many, and rarely the hardest one. The hard part is everything around it.

This type needs:

Durable state, so a run survives crashes and long waits
Human approval steps that pause and resume cleanly
A rules layer for decisions that shouldn't be left to a model
An audit trail for every input, output, and decision

You probably mean this one if AI is one step in a process your business already runs.

8. How Does Orchestrating AI Systems Work Step by Step?

AI orchestration coordinates AI models, tools, data, and agents to turn an individual AI capability into an end-to-end automated workflow.

Whatever the type, orchestrating AI systems follows the same basic loop. The tools change, but the steps don't.

Trigger: A webhook, a schedule, a queue message, or a person starts the run.
Gather context: The workflow pulls the data each step needs, so no step guesses.
Call the model or tool: An LLM, an agent, or an API does the work.
Decide what happens next: A rule or a model output picks the next step.
Route to a person when needed: Low confidence or high stakes pauses the run for approval.
Recover from failure: Retries, timeouts, and saved state let the run resume instead of restart. This is what durable execution means in practice.
Log everything: Every input, output, and decision stays searchable.

The last two steps are the ones teams skip in a prototype and regret in production.

9. What Are the Core Components of an AI Orchestration Platform?

AI orchestration platforms provide seven core capabilities for running reliable AI workflows: workflow execution, model and tool connectivity, state and memory, rules and decisioning, human approval, observability, and governance. Each capability addresses a specific requirement for running AI systems in production.

A good platform covers seven things. The table shows what each one does and what goes wrong when it's missing.

Component	What It Does	What Breaks Without It
Workflow engine	Runs steps in order, with branching and parallel work	Logic ends up scattered across scripts
Model and tool connectors	Calls LLMs, APIs, databases, and SaaS tools	Every integration becomes custom glue code
State and memory	Keeps context across steps and across crashes	A failure restarts the whole run
Rules and decisioning	Handles decisions that must be exact and repeatable	A model makes calls it shouldn't
Human approval	Pauses a run for sign-off, then resumes it	Risky actions go through unchecked
Observability	Records every run, step, and payload	Failures can't be debugged
Governance	Enforces access, policy, and audit rules	Nobody can prove what the system did

Together, these form the orchestration layer of your agent infrastructure.

Two of the seven get skipped most often. Observability tells you what happened, and LLM observability covers that in depth. Agent evals tell you whether the result was any good.

Governance ties both to policy, which is the argument behind governed AI.

10. How Is AI Orchestration Different From Workflow Orchestration and Agent Frameworks?

AI orchestration is the control layer that manages AI models, workflows, tools, and enterprise policies across an AI system. Workflow orchestration manages deterministic, step-by-step processes, while agent frameworks manage the reasoning and state of individual AI agents.

The terms overlap, and that's where most mix-ups start. Each approach has a main job and a point where it stops.

Approach	Main Job	Where It Stops
AI orchestration	Coordinates models, agents, pipelines, and processes as a whole	It's an umbrella, so it needs a concrete tool underneath
Workflow orchestration	Runs durable, scheduled, multi-step processes	Knows nothing about models unless you connect them
API orchestration	Chains and fans out calls across services	Covers the calls, not the reasoning or approvals
Agent frameworks	Handles agent reasoning and handoffs	Usually lacks built-in durability, approvals, and audit

In practice, production setups combine them. A workflow engine runs the process, an agent framework handles the reasoning, and a gateway handles model access.

For a closer look at the engine layer, see our roundup of workflow orchestration tools. For the service layer, start with API orchestration.

11. When Do You Need an Orchestration Layer, and When Don't You?

An orchestration layer is needed when multiple autonomous systems, APIs, or AI agents must work together to complete an end-to-end process. It is usually unnecessary for a single, isolated task or tool.

You need one when

A single run touches more than one model, agent, or system
A step can fail partway and cost real money to repeat
A person has to approve something before the run continues
You need to prove later what the system did and why
A run lasts longer than one request, such as hours or days

You don't need one when

It's one prompt, one model, and one response
Nothing the model does has side effects
There's no approval or audit requirement
It's a prototype only you will use

If you're in the second list, skip the layer. Adding it too early costs more than it saves.

12. How Do You Choose an AI Orchestration Platform?

Choosing an AI orchestration platform depends on your team's technical skills, workflow complexity, integration requirements, and governance needs.

Start by naming which of the four types you actually have. That one decision removes most of the options.

Training and deploying models: Pick a pipeline tool.
Routing across models: Pick a gateway.
Teams of agents: Pick an agent framework.
AI inside business processes: Pick a workflow engine that handles state, approvals, and audit.

Then compare candidates on the criteria below.

Criterion	What To Ask
Durability	Does a run survive a crash or a redeploy, and resume where it stopped?
Languages	Can your team write steps in the language it already uses?
Governance	Are approvals, access control, and audit logs built in or bolted on?
Integrations	Does it connect to the APIs, databases, and models you run today?
Cost shape	Does pricing grow with actions or runs, or stay predictable?
Observability	Can you inspect and replay any run without extra tooling?

13. How Does Unmeshed Handle AI Orchestration?

Unmeshed covers AI workflow coordination, the fourth type. It does not cover the other three, and you should know that before you compare tools.

What it covers

Workflows with durable execution, so state survives crashes and redeploys
Agentic AI steps that run on the same engine as your other steps
Human-in-the-loop approvals that pause a run and resume it automatically
A built-in decision engine for rules that must be exact
Hosted functions in Python, JS/TS, or Go, plus integrations with over 100 apps

What it doesn't do

It doesn't run ML training or serving pipelines
It isn't an LLM gateway for routing across model providers
It isn't an agent reasoning framework, so it sits underneath one instead of replacing it

The practical difference

Most teams assemble this layer from three tools: a workflow engine, an approval tool, and a logging stack. Unmeshed puts durable state, approvals, rules, and a full run history in one system, built by the creators of Netflix Conductor.

That also makes governance easier. Every step is inspectable, and the same engine backs AI agent governance and its enterprise security controls.

AI Drafts. Rules Decide. A Person Approves.

One workflow, no stitching three tools together. See an AI step, a rules check, and a human sign off run as a single flow.
Wire It Up

In a Nutshell

The phrase covers four jobs, and buying for the wrong one is the most common mistake. Name your type first, then pick the tool that matches it.

If you're building pipelines or routing models, a pipeline tool or a gateway fits. If you're building agent teams, start with a framework. If AI is one step in a process your business already runs, you need durable state, approvals, and an audit trail around it, and that's the layer a workflow engine provides.

Most real systems end up using more than one of the four. That's fine, as long as you know which job each tool does.

AutoSys Migration, One Job at a Time

The Unmeshed Team — Tue, 13 Oct 2026 05:58:23 +0000

Nobody enjoys a scheduler migration. The old system has been running for years, nobody remembers why half the jobs exist, and everyone is a little scared to touch the ones that work.

That fear is fair. AutoSys, originally from CA Technologies and now owned by Broadcom, has run critical work in banks, telecoms and insurance companies for a long time. But it was designed before APIs, containers and cloud setups became normal. Writing and maintaining JIL scripts takes practice, so new team members are slow to get comfortable. And plugging AutoSys into a modern stack, with real-time APIs or event-driven workflows, usually means workarounds.

So the question isn't really "should we move?" It's "how do we move without breaking things?" The answer most teams land on is the same: go slowly, and go one job at a time.

A calmer way to migrate

List your jobs first. Before you build anything, write down what each job runs, when it runs, and what it depends on. Sort them by how many other jobs rely on them. Jobs that stand alone are your easy wins. Jobs with long chains behind them need more care.

Start small. Pick one low-risk job with a clear result, like a nightly report, and rebuild it in the new system first. If something goes wrong, nobody's morning is ruined, and you learn how the new setup behaves before the stakes get higher.

Run old and new side by side. Let both versions run for a while and compare what they produce. This is where you catch the surprises, like a job that depends on something nobody mentioned.

Move dependent jobs together. If job B waits for job A, move them as a pair. Splitting a chain across two schedulers is how you end up with jobs that fire at the wrong time and nobody can say why.

Switch off the old job last. Only retire the AutoSys version after the new one has matched it cleanly for a good stretch of runs.

The part nobody writes down

The job definitions are the easy part. They're written down, so you can read them. What's harder is everything around them: a script that quietly retries when it fails, a downstream team that expects a file to land before 6 AM, an alert that goes to one person's inbox and nobody else's.

Those habits don't show up in any export. The best way to find them is to talk to the people who get paged when a job breaks, not just the people who built it. Ask them what they check first on a bad morning. Their answers usually point straight at the behavior you need to carry over.

How long does it take?

It depends on how many jobs you have and how tangled their dependencies are. Unmeshed suggests a phased approach like this one and says most organizations complete the move in about 6 to 12 weeks. Treat that as a rough guide, not a promise.

If you're weighing a move, Unmeshed runs scheduled jobs with Bash and Python steps and keeps every run visible from start to finish, so you can see what each job did while you compare old and new.