DEV Community: The Unmeshed Team

Your API Key Shouldn't Show Up in Your Logs

The Unmeshed Team — Fri, 09 Oct 2026 06:10:03 +0000

A token goes into a webhook request like any other field. A week later, someone's digging through logs for a totally different bug, and there it is: a plaintext API key, just sitting in the input trace.

Nobody did that on purpose. It's just what happens when a secret and a regular input get treated the same way.

The actual problem

A webhook call to trigger a workflow usually looks like any other POST request: a JSON body with whatever inputs the process needs. If one of those inputs happens to be a credential or an access token, it rides along in the same body as everything else, and by default, everything in that body can end up visible in logs, process summaries, or API responses. None of that's malicious. It's just what "log the input" means if nothing tells the system to treat one field differently.

The fix isn't "be more careful with logging." It's giving secrets their own lane from the start.

Keeping secrets out of the trail

A webhook call can separate regular inputs from secret ones using a dedicated field, something like _secretStatePut, alongside the normal payload:

curl -X POST "https://your-instance/webhook/trigger-id" \
  -H "Content-Type: application/json" \
  -d '{
    "key1": "value1",
    "_secretStatePut": {
      "apiToken": "sk-live-xxxxxxxxxxxx"
    }
  }'

Anything inside that object gets handled differently from the rest of the payload:

It doesn't show up in logs or process summaries, unless a step explicitly outputs it (which is on the workflow author, not the platform).
It's not echoed back in API responses.
It's only reachable inside the running workflow's own execution context, not from the outside.

Regular inputs still work exactly like before. The only thing that changes is where the sensitive values go.

Where this actually matters

Anywhere a workflow needs to reach something it shouldn't have to show its work on. Triggering a deployment pipeline with environment-specific credentials. Kicking off a data ingestion job that needs to hit a protected API. Any event-driven automation where "what credential did this run use" is a question that should have an answer, just not one sitting in a log file for whoever happens to be grepping through it.

The real value isn't that secrets are hidden. It's that they stop being an afterthought, something a developer has to remember to scrub out of logs after the fact, and become something the platform just handles correctly by default.

If a credential has ever ended up somewhere it shouldn't in your workflow logs, Unmeshed's secret input handling is built to make that the thing that doesn't happen in the first place.

Your Nightly Batch Job Doesn't Need to Run Like It's 2005

The Unmeshed Team — Thu, 08 Oct 2026 06:01:59 +0000

Picture a job that has to pull data from 25 different APIs every night, process the responses, and store the results for reporting. Nothing about it is hard. It's just a lot of small things that all have to happen, on time, without anyone watching.

Most teams build it the obvious way: a script that calls API one, then API two, then API three, all the way to 25. It works. It's also the slowest possible way to do it.

Most of the work doesn't depend on the rest

Those 25 API calls don't need each other. Call 14 doesn't care what call 3 returned. So there's no reason to make them wait in line.

Run independent calls in parallel and the total time drops from ""the sum of every call"" to roughly ""the slowest single call."" In our test, we modeled the job as five groups of five parallel HTTP steps, 25 calls in total. The whole thing finished in under 100 milliseconds.

That's a test against fast endpoints, so don't expect those numbers against slow third-party APIs. The point is the shape: if steps are independent, run them side by side.

Scheduling is where jobs quietly go wrong

Once the job works, you need it to run on its own. That's usually a cron expression, and the standard five-field syntax covers most needs:

0 * * * *      # every hour, on the hour
0 2 * * 1      # every Monday at 2 AM
0 0 1 * *      # first day of every month at midnight

Cron is the easy part. The part people forget is what happens when a run takes longer than expected.

The overlap problem

Say your job normally takes ten minutes, but one night an API is slow and it takes ninety. If the schedule fires again in the meantime, you now have two copies running at once. Two copies can write conflicting data, double-count records, or hammer the same APIs and make things slower.

The fix is an overlap policy. Setting the schedule to not allow overlap means a new run won't start while the previous one is still going. It's one setting, and it prevents a very annoying class of bugs.

You should be able to see what ran

A batch job that runs at 2 AM has one big weakness: nobody is awake to notice when something breaks. So it helps a lot to be able to open a list of past executions and see which ones ran, how long they took, and whether every step finished.

In our demo, the scheduled run triggered on time, ran all 25 steps, and completed in 55 milliseconds. More useful than the speed was that we could see all of it afterward.

The short version

For any batch job that fans out to many sources:

Run independent steps in parallel instead of one after another
Schedule with cron, and decide up front what should happen when a run overlaps the last one
Make sure you can look back and see what actually happened

Get those three right and a nightly job becomes boring, which is exactly what you want from a nightly job."

Why SharePoint Automation Usually Stalls Right When You Need It Most

The Unmeshed Team — Wed, 07 Oct 2026 06:32:02 +0000

SharePoint has a weird relationship with files. It's happy to store them forever, organize them into seventeen nested folders, and let everyone fight over who has edit access. What it's a lot less happy to do is actually do something with them the moment they land.

And that's usually fine, until someone uploads a form and three people are now manually copying numbers out of it into a spreadsheet, which somewhat defeats the purpose of having a document management system in the first place.

The gap between "stores files" and "triggers workflows"

SharePoint was built as a document and collaboration platform, not a workflow engine. Its native automation tools can react to simple events, a file uploaded, a value changed, but they struggle the moment a process needs more than one step: pulling data out of a file, validating it, routing it somewhere, and tracking whether each of those steps actually succeeded.

That gap is usually invisible until a team tries to build something slightly more ambitious than "send a notification when a file changes." Then it becomes the whole problem.

What real SharePoint automation actually requires

A handful of genuinely common use cases expose exactly where native tooling runs out of road:

Processing uploaded files, not just noticing them. A PDF form gets uploaded, now something needs to extract the data from it and store it somewhere. That's not an event trigger anymore, it's a pipeline with steps that can fail independently.
Reacting to spreadsheet changes, reliably. Someone updates a shared Excel file, and the new values need to sync to a database or data warehouse. Simple in concept, but it needs to handle partial failures without silently dropping data.
Auditing changes over time, not just the last one. A daily digest of file changes across a SharePoint site, for security or compliance, needs something that runs on a schedule and keeps a record, not just a one-off trigger.
Pushing generated output back in. Reports or exports created elsewhere need to land in the right SharePoint folder automatically, which means the automation has to work in both directions, not just react to SharePoint.
Letting people browse SharePoint through a different interface. Sometimes the actual need isn't automation at all, it's a custom way to surface SharePoint data without forcing everyone into SharePoint's own UI.

None of these are exotic requests. They're the kind of thing almost any team with SharePoint ends up wanting eventually.

The common thread

Every one of these needs the same underlying things: a trigger, one or more processing steps, error handling that doesn't fail silently, and a record of what happened. That's not a SharePoint feature gap you patch with another native automation. It's a workflow orchestration problem, and it needs to be treated as one, connecting SharePoint to a system built to handle multi-step processes, retries, and visibility into what ran and what didn't.

Worth checking before you build around it

If a SharePoint automation need stops at "when X happens, do one simple thing," native tooling is probably fine. The moment it involves extracting data, branching logic, or multiple systems downstream, it's worth asking whether the automation layer was built for that, or whether it's about to become another fragile workaround.

Looking Beyond LangGraph? 6 AI Agent Frameworks and What Each One Actually Fixes

The Unmeshed Team — Tue, 06 Oct 2026 05:44:27 +0000

TLDR

Most "LangGraph alternatives" content right now still recommends AutoGen. Microsoft put it in maintenance mode in October 2025.

The real current pick is Microsoft Agent Framework, GA since April 2026, merging AutoGen and Semantic Kernel into one SDK.

Five other picks, each solving a different specific reason people leave LangGraph: CrewAI (verbosity), OpenAI Agents SDK (OpenAI-native), Mastra (TypeScript), Temporal (durability), Unmeshed (governance layer).

Temporal and Unmeshed aren't agent frameworks at all; they wrap whatever framework you pick rather than compete with it.

Pick based on your actual constraint, not whichever name shows up most in search results.

Search "LangGraph alternatives" right now, and most of what comes back still puts AutoGen near the top of the list. That's outdated advice.

Microsoft moved AutoGen into maintenance mode on October 2, 2025. No new features, no enhancements, just bug fixes and security patches going forward.

The actual successor, Microsoft Agent Framework, reached general availability in April 2026. It merges AutoGen's orchestration patterns with Semantic Kernel's enterprise tooling into one SDK.

Even guides published after that date have skipped it, usually because it was still too new to trust. Five months later, it isn't.

So this list starts by fixing that, then walks the other five LangGraph alternatives by the actual reason people leave LangGraph in the first place.

1. Why Teams Look Past LangGraph

LangGraph earned its adoption. Explicit state, real branching, and built-in checkpointing are exactly what a graph-shaped agent workflow needs. It's one of several agent orchestration frameworks built around that idea, but it isn't the only shape that works.

The reasons teams look at LangGraph competitors are specific, not vague dissatisfaction:

Verbosity for small workloads: A two-step agent needs real graph declaration, nodes, edges, a compiler. Past a certain simplicity threshold, the graph is paperwork.
LangSmith as the paid observability path: Pricing starts at $39 per seat on the Plus tier and climbs fast with trace volume. Self-hosted alternatives exist but are less polished.
Ecosystem coupling: LangGraph ships from the same team as LangChain and shares primitives, so importing both compounds the exact upgrade tax teams left LangChain to escape.
Python-first: The JavaScript port trails Python by months on features and documentation, leaving TypeScript teams in a sidecar pattern.
Frequent breaking changes: The interrupt API has shifted more than once, and checkpoint formats have broken programs across minor versions.

None of this makes LangGraph the wrong choice for a genuinely graph-shaped workflow. It means a real range of LangGraph alternatives exists, depending on what actually bites for you.

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

Before comparing tools, it helps to know what you're actually optimizing for. Not every LangGraph alternative solves the same problem, so match the tool to the constraint that's actually yours.

Language: Python-first, or does your team need real TypeScript support without a sidecar process?
Durability: Does the agent need to survive a crash and resume mid-task, or is it short-lived and stateless between runs?
Cost shape: A free open-source core with usage-based cloud pricing, or a flat enterprise license?
Governance: Do you need audit logging, approvals, and access control built in, or is that being solved somewhere else in your stack?

Answer these four honestly, and the right pick from this list gets a lot more obvious.

3. The 6 Best LangGraph Alternatives

This is the LangGraph alternatives shortlist that actually holds up in late 2026, not the one still repeating 2025 assumptions about who's actively maintained.

Here's the LangGraph vs alternatives breakdown, each one picked for a different specific reason to leave, not ranked by popularity:

Framework	What It Fixes	License / Pricing
CrewAI	Verbosity, role-based crews instead of graph declarations	Free (50 executions/mo); Enterprise custom
Microsoft Agent Framework	Replaces maintenance-mode AutoGen with the current supported path	Open source, MIT
OpenAI Agents SDK	OpenAI-native production runtime, minimal ceremony	Open source; usage-priced via OpenAI
Mastra	TypeScript-first agents, no Python sidecar	Apache 2.0 core; Enterprise add-ons
Temporal	Durability for long-running, crash-surviving agents	Self-hosted free; Cloud from $50/million actions
Unmeshed	Orchestration, durability, and governance around any framework	Free forever; Premium $20/mo

1. CrewAI

CrewAI shows up on nearly every langgraph alternatives list for good reason. Its model is roles and tasks, not nodes and edges. Agent, Task, Crew, and Process cover most fixed-sequence pipelines in a third of the code a state graph needs.

Readable role-based syntax: researcher, writer, reviewer, mapped directly to the code
Used by 65% of the Fortune 500, per CrewAI's own pricing page
Free tier covers 50 workflow executions a month; Enterprise adds SSO, RBAC, and dedicated VPC or on-prem deployment

Real tradeoff: workflows that are genuinely graph-shaped, with real branching and persisted state, fight the roles-and-tasks abstraction instead of fitting it.

2. Microsoft Agent Framework

Most langgraph alternatives roundups either skip this pick entirely or still lead with AutoGen. This is the corrected pick on this list. AutoGen moved to maintenance mode on October 2, 2025, confirmed directly on Microsoft's own AutoGen repository. No new features; community-managed going forward.

Microsoft Agent Framework reached general availability on April 3, 2026, merging AutoGen's orchestration patterns with Semantic Kernel's enterprise tooling into one open-source SDK.

Graph-based workflows: sequential, concurrent, handoff, and group collaboration patterns
Checkpointing, streaming, human-in-the-loop, and time-travel debugging built in
Built-in OpenTelemetry observability, no separate paid add-on required
MIT-licensed, with direct migration guides from both AutoGen and Semantic Kernel in the repo

Real tradeoff: a shorter production track record than LangGraph itself, even though it inherits Semantic Kernel's enterprise maturity underneath.

3. OpenAI Agents SDK

A common pick among LangGraph alternatives for teams already all-in on OpenAI models. It's the production-ready successor to OpenAI's earlier Swarm experiment. Three primitives: Agents, Handoffs, and Guardrails, with built-in tracing out of the box.

First-class in both Python and TypeScript, no second-class port
A handoff() call transfers control between agents, simpler than a graph for specialist routing
Open source SDK; cost comes from OpenAI usage, not a separate framework fee

Real tradeoff: OpenAI-aligned by design. Non-OpenAI providers work through adapter layers with a thinner surface than the native path.

4. Mastra

Among TypeScript-first langgraph alternatives, Mastra is the most complete. It isn't a port of a Python framework. Agents, workflows, memory, and observability ship as part of the same package.

Deployers built in for Vercel, Netlify, Cloudflare, or a standalone Hono server
Real named customers on Mastra's own site: Salesforce runs a 100k-developer internal harness on it, MongoDB built an internal agent platform called Sage for 20+ engineering teams, and Range runs it for a $17B AUM investment advisory product
Core framework is Apache 2.0; Enterprise features sit under a separate source-available license

Real tradeoff: a younger ecosystem than LangGraph or CrewAI, and no benefit at all for Python-heavy teams.

5. Temporal

Temporal rarely shows up on LangGraph alternatives lists because it isn't an agent framework at all. It's a durable execution engine that wraps any agent code, including LangGraph itself, and records full event history so a workflow can crash and resume exactly where it left off.

Explicitly supports running the OpenAI Agents SDK and Google ADK as durable Activities, per Temporal's own pricing page
Self-hosted is free and MIT-licensed; Temporal Cloud starts at $50 per million actions, with volume discounts down to $25 per million
Backed by real momentum: a $12.55B Series E, with Temporal's own newsroom citing AI-driven demand for durable execution as the driver

Real tradeoff: adds a second runtime and operational surface. Duration alone doesn't justify it; the workflow needs a genuine durability requirement, like surviving crashes or running for days.

6. Unmeshed

Not a reasoning framework, and it doesn't compete with LangGraph, CrewAI, or Microsoft Agent Framework on agent logic. That's not the comparison to make. It sits underneath any of the five frameworks above, not instead of them.

The gap it fills

CrewAI, Microsoft Agent Framework, and the OpenAI Agents SDK all handle how an agent reasons, nothing more
Mastra adds workflows and memory, but still no durable execution, approvals, or audit trail by default
Temporal solves durability, but it's a separate runtime you have to learn and operate on top of whichever framework you already picked

What Unmeshed solves, on the free plan

Durable execution, so a failed step resumes instead of restarting the whole run
Human-in-the-loop approvals and a decision engine for branching logic, no separate approval tool bolted on
Audit logging on every step as part of built-in AI agent governance, so there's a real, queryable answer to what an agent actually did and when

The practical difference

The other five change how you write the agent; Unmeshed changes whether that agent survives contact with production
No second vendor and no second learning curve just to get durability
Free forever, Premium at $20 a month, for a team weighing LangGraph alternatives, that's the actual cost comparison

If the framework choice is settled and the actual gap is durability, approvals, or governance, that's a different layer entirely, covered in more depth in what is AI agent infrastructure.

Your Framework Picks the Agent. Something Else Runs It.

Whichever of these six you land on, see what happens when durability, approvals, and audit logging run underneath it instead of getting bolted on later.
See The Layer Underneath

4. How Do LangGraph Alternatives Handle Long-Running Agents?

Most don't, and that's the gap worth knowing about before you pick one. LangGraph's own persistence is real but lightweight, and the same is true for CrewAI, the OpenAI Agents SDK, Microsoft Agent Framework, and Mastra: none of them are built to survive a process crash mid-run or resume an agent that's been paused for hours or days.

Two of the six LangGraph alternatives on this list actually solve that:

Temporal records full event history and replays deterministically, so a workflow resumes exactly where it left off after a crash. It wraps existing agent code, including the OpenAI Agents SDK and Google ADK, but that means running and operating a second system alongside whichever framework you picked.
Unmeshed builds durable execution directly into the same orchestration layer that also handles human-in-the-loop approvals, decisioning, and audit logging. A failed step resumes automatically, on the free plan, with no separate durability engine to license, deploy, or operate.

If your agents run for minutes and finish cleanly, this isn't your problem. If they run for hours, wait on human input, or need to survive a bad deploy, it's the first thing to check before picking a framework.

5. Are There Open Source LangGraph Alternatives?

Yes, most of them. Licensing varies more than people expect, though, so it's worth checking before you build on top of one.

CrewAI: free tier (50 executions/month), Enterprise is custom and closed
Microsoft Agent Framework: fully open source, MIT licensed
OpenAI Agents SDK: open source SDK, though cost comes from OpenAI usage, not the framework itself
Mastra: core framework is Apache 2.0, Enterprise features sit under a separate source-available license
Temporal: self-hosted core is free and MIT-licensed; Temporal Cloud is usage-priced
Unmeshed: free forever on the base plan; Premium is a flat $20/month

If open source with no vendor lock-in is the priority, Microsoft Agent Framework and Temporal's self-hosted option are the cleanest picks on this list, both fully MIT with no feature gate behind a paid tier.

6. Which One Actually Fits

Skip the ranked list. This isn't a popularity-contest kind of AI agent framework comparison; it's matched to the specific reason you're actually looking:

Your Situation	Pick
Fixed-sequence pipeline of specialists, want less code than a graph	CrewAI
Building on Microsoft Foundry or Azure, want the current supported path	Microsoft Agent Framework
Mostly OpenAI models, want tracing and guardrails out of the box	OpenAI Agents SDK
TypeScript team, deploying to Vercel or Cloudflare	Mastra
Agents need to survive crashes and run for days	Temporal
Framework is fine; the pain is durability, approvals, or audit underneath it	Unmeshed

Final Thoughts

The single most common mistake in LangGraph alternative advice right now is recommending AutoGen without mentioning it's in maintenance mode.

Past that correction, the rest of these LangGraph alternatives are genuinely differentiated, not just renamed versions of each other. The choice comes down to which specific limitation is yours: verbosity, cost, language, durability, or the governance layer underneath the framework entirely.

Pick based on the actual reason you're looking, not the most popular name in the search results.

Cron Doesn't Know It's a Holiday

The Unmeshed Team — Mon, 05 Oct 2026 05:55:15 +0000

We had a job scheduled to run every weekday at 9 AM. Cron handled that part fine, right up until Thanksgiving, when it ran anyway, into an empty office, and nobody noticed the output was garbage until two days later.

Cron is great at one thing: fixed intervals. Every hour, every day at 5 AM, every Monday. What it has no concept of is a holiday, a blackout window, or "the first working day after a long weekend." Those aren't interval problems. They're calendar problems, and cron was never built to answer them.

What a calendar actually buys you

The fix isn't a smarter cron expression, there isn't one. It's separating "when does this job normally run" from "is today actually a valid day to run it," and letting the second question filter the first. That's what calendar scheduling does: a calendar sits on top of a schedule and decides, date by date, whether the job fires.

There are a few shapes this takes, depending on who's setting the rule and how complex it needs to be.

Pick the dates by hand. For a monthly review or a quarterly task, someone just clicks the valid days on a visual calendar, or applies a quick pattern like "every weekday" or "every Monday." No code, no logic, just a list of dates that's easy for a non-technical person to manage.

Write the logic. "Every third Friday of the month" or "the first working day after a public holiday" isn't something you pick by hand, it's something you compute. A code-based calendar lets a developer define that rule once instead of manually updating a date list every year.

Combine calendars. Sometimes the rule you actually want is the relationship between two calendars, not either one alone. Working days minus public holidays. The overlap between two teams' on-call windows. Set operations, union, intersection, difference, handle this without hand-maintaining a third list that has to stay in sync with the other two.

Reschedule instead of skip. Some jobs can't just not run on a holiday, they need to run later. A reschedule calendar skips the blackout days and pushes the job out by a defined number of days instead of dropping it entirely, useful for anything that absolutely has to happen, just not today.

Why this matters more than it sounds like it should

The real cost of the Thanksgiving-cron story isn't the one bad run. It's that nobody could say, with confidence, which other jobs had the same blind spot, because the holiday logic, if it existed at all, was scattered across whatever script each team happened to write. A calendar makes that rule explicit and reusable: define it once, attach it to any schedule that needs it, and get a preview of every date the job will actually run before it goes live.

That last part matters more than it seems. Scheduling logic is the kind of thing that's nearly impossible to verify by reading code, you want to see the actual dates, not trust that the expression is right. A snapshot preview turns "this should be correct" into "this is visibly correct," which is a meaningfully different level of confidence before something goes live in production.

If cron has ever run a job on a day it really shouldn't have, Unmeshed's calendar scheduling is built to be the layer that catches it before it happens, not after.

Your Wait Step Works Once. Then It Stops Waiting

The Unmeshed Team — Thu, 01 Oct 2026 05:40:43 +0000

We set a Wait step to pause three seconds inside a loop. First time through, perfect. Second time through, it just stops waiting. Like it forgot its one job.

Here's the twist: nothing's broken. The engine's doing exactly what we told it to do. We just didn't realize what we were actually telling it.

Why it happens

A Wait step takes a function that returns a timestamp, waitUntil, and most people write it as an offset from when the step started:

(steps, context) => {
  const startDate = new Date(steps.__self.start);
  return {
    waitUntil: startDate.getTime() + 3_000, // wait 3 seconds
  };
};

That start value is set once, the first time the step runs, and it never updates. On the first pass through the loop, that's fine, the timestamp is three seconds in the future and the engine waits as expected.

On the second pass, the While loop re-runs the same Wait step instance. It still reads the original start value, which is now well in the past. As far as the engine's concerned, waitUntil has already been satisfied, so it continues immediately. It's not skipping the wait. It's correctly honoring a timestamp that's already expired.

This is the part that trips people up: a Wait step inside a loop doesn't behave like sleep() in regular code. The engine re-evaluates the same node on every pass, it doesn't restart it with fresh state.

The fix: track a timestamp per iteration

Instead of computing waitUntil once from a fixed start time, store a separate target timestamp for every loop iteration, and only calculate a new one the first time that iteration runs:

(steps, context) => {
  const iterations = steps.__self.output.result?.iterations || [];
  const currentIter = steps.loop.output.iteration;

  if (iterations.length <= currentIter) {
    iterations.push(Date.now() + 3_000); // wait 3 seconds from *now*
  }

  return {
    waitUntil: iterations[currentIter],
    iterations,
    loop: currentIter,
  };
};

This holds up under retries and restarts, since the timestamp for a given iteration is stored and reused rather than recalculated, and each loop cycle gets its own delay measured from when that cycle actually began, not from whenever the Wait step was first created.

Other ways to handle it

Store the timestamp in process context if more than one step needs to reference the same schedule.
Push the timing logic into the While condition itself, works well for simple polling loops where ""stop once 3 seconds have passed"" can be expressed directly.
Move the Wait outside the loop entirely, if what's actually needed is one delay before the loop starts, not a delay on every pass.

The short version

Treat a Wait step like any other piece of state: make it idempotent, compute targets relative to now instead of a fixed start time when it's inside a loop, and log the iteration index so timing bugs are easy to spot later. None of this is a limitation. It's just not sleep(), and it behaves differently the moment you understand what it's actually doing on each pass."

Your Fraud Pipeline Is Just Vibes and Cron Jobs

The Unmeshed Team — Wed, 30 Sep 2026 07:11:12 +0000

Ask a fraud analyst what's actually killing their day, and it's never the dramatic stuff. It's the boring stuff, copy this number, paste it there, check if it's above 600 or below it, repeat forever. Basically a very serious game of telephone between two computers that refuse to speak to each other directly.

And here's the part that doesn't show up in the big scary market stats. Fraud detection is a $52.82 billion industry, on its way to $246 billion by 2032. Most of that money isn't buying smarter fraud detection. It's paying humans to be the USB cable between two systems that should've just been connected in the first place.

The checks were never the hard part

Take something as ordinary as opening a bank account online. Verify identity. Score the risk. Decide what happens next. Three steps. Sounds simple.

It isn't, because each step usually lives in a different system. Someone has to call the identity check, wait for a result, pass that result to the risk engine, take the score it returns, and decide what happens based on that score. Approve it. Block it. Or send it to a person, because the rules said "needs review" and nothing smarter exists yet.

None of these steps is hard on its own. Each one is just an API call and a response. What's hard is remembering that one step depends on another, and making sure a failure in step two doesn't quietly break step four.

This is why teams end up with a pile of scripts

Without something coordinating this, teams write scripts to hold it together. One script calls the identity check. Another feeds that result into scoring. A third checks the score and decides what to do. It works, for a while.

Then the identity vendor changes their response format, and nobody updates the script that reads it. Or someone needs a new rule, and has to dig through five scripts to find the right one. Or a script fails quietly overnight, and nobody notices until a customer complains. The scripts weren't badly written. There were just too many of them, each one on its own.

Where the savings actually show up

Put the sequence, the branching, and the failure handling in one place, and three things happen. Manual reviews drop, because clear score thresholds approve or block automatically, and only unclear cases go to a person. Maintenance drops, because there's one pipeline to update instead of a handful of scripts nobody fully remembers. And cost stops climbing with volume, since processing ten million transactions doesn't need ten times the manual effort that ten thousand did.

The actual point

Fraud detection isn't hard because identity checks or risk scoring are hard problems. They're not. It's hard because those pieces live in separate systems, and someone has to connect them: catch the failures, pass the data along, decide what happens next. Get that part right, and the individual checks mostly take care of themselves.

The Logistics Bottleneck Nobody Puts On the Roadmap

The Unmeshed Team — Tue, 29 Sep 2026 06:11:35 +0000

Ask anyone in freight ops what their day actually looks like, and it's rarely about the shipment. It's about the tabs.

Quoting one shipment means juggling four of them: pricing here, tracking there, billing somewhere else, and customer comms in whatever tool never got replaced.

Nobody designed it that way. It just piled up until someone's job became copy, paste, and hope.

Where the hours actually go

Most logistics stacks don't start out fragmented. They get that way one integration at a time. A new carrier system comes online. A partner needs a custom data feed. A script gets written to move data from A to B, then another to move it from B to C, and eventually there's a small army of brittle scripts holding the whole thing together.

None of those scripts are wrong, exactly. But nobody's job is to know all of them, and when a shipment update needs to touch pricing, tracking, and billing in the right order, the actual coordination work falls on a person instead of the system. Multiply that across freight quoting, invoice reconciliation, and delivery exception handling, and you've got a team spending real hours on work that's mechanical, repetitive, and invisible on any roadmap.

What changes when the workflow is the unit of work

The fix isn't a bigger integration layer between every pair of systems. It's treating the process itself, quote a shipment, reconcile an invoice, flag a delayed delivery, as one thing with a defined shape, instead of a chain of scripts that happen to run one after another.

Once a process like freight quoting is built this way, it stops being a one-off. The same module that handles quoting can plug into a different workflow that needs pricing data, without anyone rewriting the logic. Version control and testing apply to the workflow itself, not just the code around it, so a change to how invoices get reconciled doesn't quietly break delivery exception handling six months later.

That reuse is where the time actually comes back. Teams stop rebuilding the same coordination logic for every new process and start assembling new ones from pieces that already work.

The numbers behind it

A 2024 study in the International Journal for Multidisciplinary Research, looking at enterprises that adopted structured orchestration, found meaningful gains on exactly this kind of fragmentation: fewer integration failures, better use of engineering time, and noticeably faster deployment cycles, all without adding infrastructure complexity. The specific percentages will vary by organization, but the direction is consistent with what shows up anywhere manual coordination gets replaced with a defined process: fewer people doing the work of gluing systems together, more of them doing the work only they can do.

For a digital freight platform juggling carriers, partners, and customer-facing tracking at once, that's not a nice-to-have. It's the difference between scaling the business and scaling the number of people needed to hold it together.

If your team is stitching together pricing, tracking, billing, and communication by hand, Unmeshed is built to be the layer that turns that coordination into something reusable instead of something rebuilt every time."

AI Agent Infrastructure Explained: The 5 Layers You Need in Production

The Unmeshed Team — Mon, 28 Sep 2026 05:37:43 +0000

TLDR

Most agentic AI projects don't fail because the model is bad; they fail because the infrastructure underneath isn't there.
"Agent infrastructure" isn't one thing. It's five layers: runtime/orchestration, identity/governance, data/memory, observability/evals, cost/resource management.
No vendor, including Unmeshed, covers all five. Anyone claiming otherwise is drawing the map around their own product.
Unmeshed handles runtime/orchestration and identity/governance. Data/memory and model routing are gaps, stated plainly.
Fix the layer that's actually breaking for you first. Don't shop for a platform that claims to own the whole stack.

Over 40% of agentic AI projects will be canceled by the end of 2027. That's not a hot take; it's Gartner's own research.

The reason isn't that the models got worse. Teams built agents that worked fine in a demo, then watched them fall apart the moment real traffic, real failures, and real audit requirements showed up.

The model was never the problem. The infrastructure underneath it didn't exist yet.

Search "AI agent infrastructure," and you'll land on five different answers depending on whose guide you read. Four layers in one framework, five in another, seven in a third.

Nobody selling a platform actually agrees on where their own product's edges are, and that tells you something. There's no established standard yet, just a handful of companies drawing the map to match what they already built.

So the useful question isn't which platform covers all of agent infrastructure. Nothing does, honestly.

The useful question is which specific layer is actually breaking for you right now, and what fixes that layer specifically. That's what this guide walks through.

1. What AI Agent Infrastructure Actually Means

AI agent infrastructure is the specialized layer of runtime, identity, data, observability, and cost-control systems that keeps autonomous agents running reliably once they leave the demo and hit production traffic.

That's a mouthful, so here's the shorter version. An agent framework, LangChain, CrewAI, Mastra, whatever you're using to define how the agent reasons and calls tools, decides what the agent does.

AI agent infrastructure decides whether it keeps doing that reliably at 2 am when a downstream API times out, whether anyone can tell what happened after the fact, and whether the bill for a bad loop shows up before it's too late to stop it.

You can swap frameworks without touching infrastructure, and swap infrastructure without touching the framework. They're genuinely separate problems, which is part of why teams underbuild one while over-investing in the other.

That distinction is worth holding onto for the rest of this guide, because most of the confusion around AI agent infrastructure comes from collapsing it back into the framework conversation.

It's also why "the complete agent infra platform" is such a common pitch, and such an inconsistent one from vendor to vendor. Every version of that pitch draws the boundary in a different place, depending on what the company selling it already happened to build.

2. The Five Layers of AI Agent Infrastructure

Pull up three different guides on this, and you'll get three different layer counts:

Agentuity's guide settles on four: runtime, orchestration, observability, and cost control
MindStudio's framework splits it into five: runtime orchestration, identity and authorization, data access and memory, payments and resource management, and observability and debugging
Other guides add a sixth or seventh cut specifically for memory or security

None of that disagreement is really about the technology. It's about which product each company is selling, and where its edges happen to fall.

For this guide, five layers cover the ground that actually matters when you're scoping an agent infrastructure stack from scratch:

Runtime and orchestration
Identity and governance
Data and memory
Observability and evals
Cost and resource management

Whichever count you land on, the point of mapping AI agent infrastructure this way is to stop treating it as one undifferentiated blob and start treating it as five separate buying, building, or fixing decisions.

Layer	What Breaks Without It	Where To Look
Runtime & orchestration	Agents lose state mid-task and can't resume where they left off	Durable execution, API orchestration
Identity & governance	No audit trail, no record of what the agent actually touched	Governed AI
Data & memory	Agent starts cold every session, or acts confidently on stale context	Not a native layer for most orchestration platforms
Observability & evals	A failed run is undebuggable, quality drifts unnoticed	LLM observability, AI agent evals, LLM as a judge
Cost & resource management	Runaway spend, no idea which agent is driving the bill	LLM gateway, LLM cost optimization

Runtime and Orchestration

This is the layer most teams hit first, because it's the one that breaks the loudest. An agent runtime manages:

Which step runs next
How state carries across a multi-step task
What happens when a tool call fails partway through
How the agent resumes after pausing for a human approval or a slow webhook, instead of losing its place

An agent that can't survive a downstream API timeout without restarting from zero isn't production software yet. It's an expensive demo with good uptime.

Get this layer wrong, and every other part of your AI agent infrastructure inherits the instability, because nothing downstream can trust that a run actually finished the way it looks like it did.

We've written about what durable execution actually requires in what is durable execution, and how this differs from plain API orchestration once a workflow includes AI steps and not just service calls.

Identity and Governance

An agent is an identity now, not just a script. It holds credentials, calls tools on someone's behalf, and can rack up real consequences if nobody's watching what it does with that access.

This layer covers:

What the agent is allowed to touch
What a human is allowed to authorize through it
Whether there's an audit trail that would actually hold up if someone asked for one

Skip it, and you get an agent with more standing access than any single person on the team, and no record of how it used it. We covered why this stopped being optional for enterprise teams in governed AI.

Data and Memory

Two different problems live under one label here.

Data access is how the agent retrieves the right information at the right moment, through a vector store, a structured tool call, or context loaded straight into the prompt.

Memory is whether the agent remembers anything between sessions instead of starting cold every single time.

This is the one layer of agent infrastructure most orchestration-first platforms, Unmeshed included, don't own natively. Memory and retrieval usually come from a dedicated vector database or memory service, paired with whatever runs the rest of the workflow, not bundled into it.

It's also the layer most frequently oversold in AI agent infrastructure marketing. A thin retrieval integration is easy to demo and hard to distinguish from real long-term memory until it's under real load. Worth naming plainly rather than stretching a feature to cover a gap that's genuinely there.

Observability and Evals

When a normal API call fails, you check a log line. When an agent fails after thirty tool calls and a dozen model calls, a log line tells you almost nothing.

This layer needs:

Tracing across the entire run
Token and cost tracking per session
A way to tell whether the output was actually good, not just whether it ran without an error

That last part is evals, different from observability even though the two get lumped together constantly. We drew that line explicitly in LLM monitoring vs observability and went deep on the eval side in what are AI agent evals, including how teams automate quality scoring with an LLM as a judge instead of a human reading every transcript.

Cost and Resource Management

A single LLM call costs fractions of a cent. An agent making a hundred calls across multiple providers, in a loop that doesn't know when to stop, costs real money, and the invoice usually arrives after the damage is done.

This layer covers:

Token budgets per run
Rate limiting against downstream services
Cost attribution, so you know which agent, user, or workflow is actually driving the number

Multi-provider billing is its own headache here, which is exactly the problem an LLM gateway exists to solve. If runaway spend is the actual pain point, this is also where techniques like the ones in LLM cost optimization pay off fastest.

Left unmanaged, this is the layer of AI agent infrastructure that turns a promising pilot into a budget conversation nobody wanted to have.

3. Where Unmeshed Fits, and Where It Doesn't

No hedging on this one. Unmeshed covers two of the five layers directly:

Runtime and orchestration: Durable execution that survives a failed step and resumes instead of restarting, with workflow-level state kept automatically
Identity and governance: Human-in-the-loop approvals, a decision engine for branching logic, and audit logging on every step, so "what did the agent actually do" has a real answer

It does not cover two of the five:

Data and memory: No built-in vector store or long-term memory layer, and pretending otherwise would be the kind of overclaiming this guide is arguing against
Model routing: It doesn't function as an LLM gateway for multi-provider routing; that's a separate, complementary piece

If your gap is specifically in one of those two layers, you're pairing a dedicated tool with whatever runs your orchestration. That's true whether the orchestration layer is Unmeshed or anything else.

Most AI agent tooling on the market is built to solve one of these layers well and imply, quietly, that it solves the rest. Being specific about which two is more useful than a feature list that stretches to cover the gaps.

Two of These Five Layers, Handled

Durable execution and governed, auditable agent steps are built in. See what that actually looks like before you build it yourself.
See It In Action

4. Build, Buy, or Assemble

No single agent infra platform actually owns all five layers. The guides that claim to are drawing generous lines around their own product.

Most teams end up assembling from two or three specialized tools rather than buying one platform that does everything. That's not a failure of the market; it's just where the market actually is right now.

A practical way to decide where to start: figure out which layer is causing you pain today, not which one sounds most important in the abstract.

What's Actually Happening	The Layer That's Missing
Agents keep losing state on failure	Runtime and orchestration
Nobody can answer what an agent did last Tuesday	Identity and governance
The agent gives confidently wrong answers from stale context	Data and memory
A production incident takes hours to diagnose	Observability and evals
Last month's bill had a number nobody can explain	Cost and resource management

Solve the layer that's actually on fire first. The rest of the agent infrastructure stack can wait until it's the one causing the pain.

That's the practical reality of AI agent infrastructure today, whatever a sales deck implies about full coverage.

Conclusion

AI agent infrastructure isn't a single product category, whatever the pitch decks say.

It's five layers that different vendors draw differently. The honest starting point is knowing which one is actually failing you, not shopping for a platform that claims to own all of them.

Runtime and orchestration, identity and governance, data and memory, observability and evals, cost and resource management.

Name the layer that's breaking, fix that one, and build out from there instead of trying to solve all five on day one.

Still scoping your agent infrastructure stack? Talk to us about which layers you're missing, and whether Unmeshed covers the ones that matter most for your use case. Start The Conversation

Step Functions Worked Fine. Until Your Workflow Outgrew It.

The Unmeshed Team — Fri, 25 Sep 2026 06:10:00 +0000

Ask any AWS team how they ended up on Step Functions and you'll get the same answer: it was already there. Already in the console, already on the bill. Nobody had to make a case for it.

The problems don't show up on day one. They show up slowly, a bill that's a little higher than expected a workflow that's a little slower than it should be for what you're building now. By the time someone brings it up in a meeting, half the room's already been thinking it.

The billing model punishes exactly the growth you want

Per-state billing is invisible at low volume. You don't notice it. Then workflow volume climbs into the millions and it stops being invisible, it becomes a number finance asks about. The frustrating part isn't that it's expensive. It's that the pricing model actively gets worse the more successful your usage of the tool becomes, which is backwards from how infrastructure spend is supposed to behave. A flat, fixed-price model doesn't have that problem: cost doesn't move just because volume did.

You're betting on one region staying up

Step Functions is AWS-managed, all the way down. Fine, until a regional outage takes your workflows with it, or until ""we should probably not have all our eggs in one cloud"" moves from a hypothetical someone raised in a planning meeting to an actual mandate from above. Orchestration that runs across AWS, Azure, GCP, or on-prem means a provider having a bad day is an incident, not an outage for your customers too.

The JSON is the job, some days

Step Functions' state machine definitions are genuinely powerful. They're also genuinely tedious to write and debug by hand, and every hour spent wrestling a state machine into shape is an hour not spent on the workflow's actual business logic. A visual builder and YAML definitions don't make the underlying problem simpler, they just get engineers out of the syntax and back into the logic faster.

It wasn't built to feel instant, because it wasn't built for that

This is the one that actually surprises teams. Step Functions is an event-driven tool wearing a request-response costume when you need one, and the seams show:

Every state transition adds measurable latency. That's a non-issue for a nightly batch job and a real problem for a chat response or an AI agent call that needs to feel immediate.
There's no native synchronous flow. Getting request-response behavior means wrapping the state machine in API Gateway or a Lambda, which means more infrastructure to babysit, not less.
CloudWatch tells you what happened. It's genuinely bad at telling you what's happening right now: no live view of step progress or partial outputs while a workflow is actually stuck.

A platform built for real-time, API-driven orchestration from the start doesn't have these seams to paper over: no wait between steps, synchronous and asynchronous flows on equal footing, and tracing you can watch live instead of reconstruct afterward.

None of this means Step Functions is wrong for you

It's a fine choice for AWS-native, event-driven, background-heavy workflows, and plenty of teams should keep using it exactly as-is. The point where it's worth reconsidering is specific: when volume growth starts hurting your bill, when a single-region dependency stops being acceptable, or when a workflow needs to respond in the time it takes someone to read a chat message rather than the time it takes a batch job to run. That's not a tooling preference. That's a different job than the one Step Functions was built to do."

Stop Passing Big Files Through Your Workflow. Here's What to Do Instead.

The Unmeshed Team — Thu, 24 Sep 2026 06:10:32 +0000

You've built the workflow, tested it with a sample file, and everything works. Then someone uploads a real spreadsheet, the kind with 40,000 rows instead of 10, and suddenly your "simple" step is dragging the whole process down.

Here's what usually causes it: the workflow is carrying the file itself through every step, like it's just another piece of data. Passed as payload, dragged from step to step, worked with inline. It feels natural to build it that way. It's also the wrong move.

Here's why, and what to do instead.

Small payloads are fine. Big ones aren't.

Passing a small JSON object between steps? No problem. Passing an actual file the same way? That's where things start breaking.

You get bloated requests and responses. Slower step-to-step execution. Debugging turns into a nightmare once an output is too big to actually read. And you're burning memory on something that has nothing to do with the real work.

None of this shows up while you're testing with a 10-row spreadsheet. It shows up the day a real file hits production.

The fix: stop moving the file. Move a path instead.

Rather than pushing file contents through the workflow, download the file once into shared storage and let each step that needs it read from disk. Steps pass metadata and results to each other, never the file itself.

That's three steps, in practice.

1. Download: stream it into storage, don't load it all into memory first

import os
import requests

def main(steps, context):
    file_url = "https://testing.s3.amazonaws.com/abcd/pqr/1234/myfile.xlsx"
    file_path = "/app/files/myfiles/customFile.xlsx"

    os.makedirs(os.path.dirname(file_path), exist_ok=True)

    try:
        with requests.get(file_url, stream=True, timeout=60) as response:
            response.raise_for_status()
            with open(file_path, "wb") as f:
                for chunk in response.iter_content(chunk_size=8192):
                    if chunk:
                        f.write(chunk)

        return {"statusMessage": f"File downloaded and saved to {file_path}", "isSuccessful": True}

    except Exception as e:
        return {"statusMessage": f"Download failed: {str(e)}", "isSuccessful": False}

Streaming in chunks is the whole point here. It's what keeps a big file from spiking memory on the way in.

2. Process: read it where it lives, return a summary, not the whole file

import pandas as pd

def main(steps, context):
    file_to_process = "/app/files/myfiles/customFile.xlsx"

    try:
        df = pd.read_excel(file_to_process)
        df = df.fillna("N/A")

        numeric_cols = df.select_dtypes(include=["number"]).columns
        numeric_summary = {col: df[col].sum() for col in numeric_cols}

        return {
            "rowCount": len(df),
            "columnCount": len(df.columns),
            "columns": list(df.columns),
            "numericSummary": numeric_summary,
            "preview": df.head(5).to_dict(orient="records")
        }

    except Exception as e:
        return {"statusMessage": f"Error processing file: {str(e)}", "isSuccessful": False}

3. Delete: clean up once you're done, every single time

import os

def main(steps, context):
    file_path = "/app/files/myfiles/customFile.xlsx"

    try:
        if os.path.exists(file_path):
            os.remove(file_path)
            message = "File deleted successfully"
        else:
            message = "File does not exist"

        return {"statusMessage": message, "isSuccessful": True}

    except Exception as e:
        return {"statusMessage": str(e), "isSuccessful": False}

Skip this step and storage quietly fills up on any process that runs a few hundred times a day.

The step people actually get wrong

It's step 2. The instinct is to return the parsed data as-is. Resist it.

Figure out what the next step genuinely needs, a row count, a list of columns, a few preview rows, and return only that. If something downstream truly needs the full dataset later, it's still sitting right there on disk.

Get this one decision right and the rest of the workflow stays light. Everything after that step is working with a few KB of summary instead of megabytes of spreadsheet.

Works past Excel too

Nothing about this pattern is Excel-specific. Download → process → clean up works the same for CSVs, PDFs, generated reports, basically any bulky file your workflow has to touch. Only the processing logic in step 2 changes.

The one habit that matters

Big files stop being a headache the moment you stop treating them as data flowing through the workflow and start treating them as a resource the workflow borrows temporarily. Download it, use it, get rid of it. Nothing downstream has to carry weight it never needed.

Your Order Fulfillment Workflow Is One 24-Hour Wait Away From Chaos

The Unmeshed Team — Wed, 23 Sep 2026 06:54:35 +0000

Here's a fun fact about order fulfillment: it looks like one button click. "Buy now." Done, right?

Wrong. Behind that button is a process that spans five systems, takes hours to finish, and has more opinions than your group chat. And almost every team builds it the same two ways both of which fall apart at the exact same moment: the moment it has to wait.

We watched this happen with a telecom order flow. Let's talk about it.

Step one: chain some APIs together. What could go wrong?

The classic move. Frontend calls Service A, Service A calls Service B, Service B calls Service C, and everyone's happy right up until you need to hold state for a while. Like, say, keeping someone's cart open for 24 hours because they got distracted by a raccoon on their porch camera and never finished checkout.

There's no natural place to put that wait. So someone bolts on a cron job. Then a timer. Then a ""temporary"" flag in a database that becomes permanent the way all temporary things do. Congrats, you've built a haunted house of half-finished retry logic.

Step two: ""let's just go event-driven!""

This is the fix everyone reaches for next, and it does scale better. Publish events, let services react, store state wherever each service feels like storing it that day.

The catch: your workflow logic is now scattered across every service that happens to be listening. So when someone (a customer, your boss, your own past self at 2am) asks ""where is this order stuck?"" buckle up. You're now spelunking through five different log files, lining up timestamps like you're solving a murder mystery nobody asked you to solve.

What the workflow is actually asking for

Strip away the telecom flavor and the order just wants four things, which is honestly not that much to ask:

Hold state for hours without forgetting the order exists (looking at you, 24-hour cart)
Do independent stuff at the same time — validating the plan, pulling customer data, running a credit check don't need to wait in line for each other
Pause for a human when it matters — route the approval, let someone escalate it, resume without breaking anything
Don't duplicate work on retry — nobody wants to accidentally reserve two phones for one order because a request got retried

Swap ""order"" for ""insurance claim"" or ""loan application"" and the list doesn't change. This isn't a telecom problem. It's a ""any process that takes longer than a coffee break"" problem.

The part nobody brags about, but should

Here's the underrated payoff: what happens when it breaks.

If every step, every input, and every decision gets logged as the workflow runs, ""what happened to this order?"" becomes a five-second lookup by order ID. Which steps ran, what they got, where it died. If that record doesn't exist, you're back to reconstructing the crime scene from logs that were never meant to talk to each other.

That's the actual pitch for orchestration. It's not that it connects your systems better anything can connect systems if you yell at it long enough. It's that your long-running, easily-distracted-by-a-24-hour-wait workflow finally has one address. Somewhere it can pause, get poked, resume, and be interrogated later without anyone crying.