Mayura vs the Vercel AI SDK

The Vercel AI SDK is the most widely used TypeScript library for working with language models. It gives you one API over many providers for text, structured output, tools, embeddings, images and speech, streams the result, and has UI hooks such as useChat for React, Vue and Svelte. On top of that it has agents: ToolLoopAgent in the ai package, and WorkflowAgent in @ai-sdk/workflow, which runs on Vercel's Workflow SDK so an agent survives restarts.

Mayura is narrower. It is an agent and workflow runtime: you tell it what runs may use, who they act for and how much they may spend, then submit agents and durable workflows to it. Nothing is allowed until you grant it, every run has a hard budget, and a durable step that may have acted is never run again.

The two overlap on the agent loop and much less elsewhere. Many agent frameworks build on the AI SDK's providers; Mayura doesn't, and has its own provider packages. We say below where they can be used together.

We make Mayura, so read this with that in mind. We checked every statement about the AI SDK against its own documentation, repository and npm listing, and link the sources at the end. If something here is wrong or out of date, please tell us.

Compared on October 12, 2026: the AI SDK (ai) 7.0.137, @ai-sdk/workflow 2.0.69 and the Workflow SDK (workflow) 5.2.0, against Mayura 1.1.0.

#At a glance

#Where they differ most

#A toolkit you call, or a runtime you configure

The AI SDK is a set of functions and classes you call from your own code: generateText, streamText, a ToolLoopAgent's generate or stream. You own the process, the request, the storage and the authorization around it. Its centre is the model call and the stream back to a user interface, and it is very good at both.

Mayura is a runtime you configure once with permissions, a scope (who the run acts for) and limits, and then submit agents to. It validates the input before the model is called and the output before it is released, ends every run with one typed outcome, and comes with the pieces a production service needs around that: an HTTP server and client, workers for durable workflows, storage and an operator console.

#Tool access: run unless stopped, or denied unless granted

The AI SDK documentation states the default plainly: tools with an execute function run automatically when the model calls them. toolApproval changes that per tool or per call, with four statuses: run normally, approve automatically, deny, or wait for a person. @ai-sdk/policy-opa moves those rules into Open Policy Agent policies, which also see the run's message history, so a policy can count earlier writes or deny a second irreversible action. You can build a default-deny policy this way; it is yours to write.

In Mayura, default-deny is the starting point. A runtime allows nothing until you list it: model:<id> for each model, tool:<id> for each tool, every capability the tool declares (such as payments:refund) and effect:write if it writes. A missing grant blocks the call before it runs, and nothing the model, the user or a tool result says can add to the list. Child agents get the intersection of their own grants and their parent's. See Permissions.

#Budgets: stop after, or reserve before

The AI SDK bounds an agent with stop conditions, which are checked after a step that produced tool results. ToolLoopAgent stops after 20 steps unless you choose otherwise; WorkflowAgent has no default limit. The loop control guide shows a custom condition that adds up token usage and stops once an estimated cost passes $0.50, and OPA policies can deny calls once a running total is reached. In both cases the check sees what has already been spent, so the step that crosses the line has already been paid for.

Mayura checks before the call. Every model and tool call declares the most it can cost, the runtime reserves that amount from the run's budget, and a call that doesn't fit never starts. A paid model is refused until you set a limit at all, and a child run's cost counts against its parent's budget. See Costs and budgets.

#Durability: retry the step, or never run it twice

A ToolLoopAgent runs in memory; the AI SDK documentation says that if the process crashes, all progress is lost. For durability it offers WorkflowAgent, which runs inside a workflow of the Workflow SDK: each model call and tool call becomes a durable step, completed steps are reused on replay, failed tool calls are retried automatically, and approvals survive suspension. The Workflow SDK retries a step up to three times by default and asks for side effects such as payments and emails to be idempotent. The WorkflowAgent guide is explicit that completed-step replay "does not guarantee exactly-once effects for an interrupted attempt".

Mayura records each workflow step as started before it calls the tool, and never calls it again. If the process dies mid-step, the next process to advance the run settles the step as unknown once its deadline has passed, and the run ends outcome_unknown for a person to reconcile instead of paying twice. There are no automatic retries, and every run stays pinned to the workflow definition it started with. Never twice covers the mechanism and its limits.

Neither approach is free. Retrying recovers from transient failures without a human, and is right when steps are idempotent. Never retrying is right when a duplicate is worse than a pause, as with payments, emails or deletions, and it means someone occasionally reconciles a run.

#Where the AI SDK is ahead

• Models. Far more providers out of the box, one interface across them, and the AI Gateway for reaching many through one key.
• User interfaces. useChat and related hooks for React, Vue and Svelte, a stream protocol, resumable streams and generative UI. Mayura's React bindings show runs, workflow progress and forms for human requests; they are not a chat toolkit.
• Modalities. Image and video generation, reranking and realtime, besides text, speech and transcription. Mayura has voice and vision, and no image or video generation.
• Conversations. Agents work on message arrays, and chat history is a first-class idea in AI SDK UI. Mayura has no thread store: a chat app passes earlier turns in the run's input.
• Approval inside an agent. toolApproval pauses an ordinary ToolLoopAgent before selected tool calls. In Mayura, approvals are steps of durable workflows, and an agent run can't pause for a person; the agent starts a workflow that holds the sensitive step, as in the refund guide.
• Reach. Harnesses that run Claude Code or Codex behind the same interface, a much larger community, and a longer track record. Other agent frameworks build on its providers, so what you learn carries over.

#When to choose which

Choose the AI SDK if the centre of your app is a conversation with a model: a chat interface, streaming answers, many providers behind one API, or generated images and audio. Its agents are a good fit when the tools are safe to run when the model asks, and its WorkflowAgent when a long agent should survive restarts and its steps are safe to retry.

Choose Mayura if your agents act on things that matter, like money, customer records or messages, and you want the framework to enforce the rules: nothing allowed by default, a hard budget on every run, approvals bound to the exact input, and durable steps that never run twice. Also if you want one Apache-2.0 license for everything.

Using both works, because they sit at different layers. Mayura's model adapter interface is documented for wrapping an SDK you already use, so an AI SDK model can become a Mayura model, with the prices and per-call ceiling you give it; Mayura doesn't ship such an adapter. In the other direction, an AI SDK app can keep its chat interface and call a Mayura server through mayura/client, or start a Mayura durable workflow from a tool for the one step that needs an approval and must not run twice.

#Sources

AI SDK facts were checked on October 12, 2026:

• npm: ai (version 7.0.137, release dates, license, downloads), @ai-sdk/workflow and workflow
• GitHub: vercel/ai (stars, repository history)
• Agents overview, Loop control and Workflow patterns
• Tool approvals and Policy tool approvals
• WorkflowAgent
• Memory
• Providers and models, Choosing a provider and Navigating the library
• Telemetry, MCP tools and Harnesses
• Workflow SDK: Deploying and Worlds and Errors and retries

Mayura facts come from its documentation.