Mastra Agent Builder puts permissions at the center of internal agents

Mastra announced Agent Builder on May 28, 2026. Mastra describes it as an "internal agent platform": developers prepare tools, models, workflows, and agents in code, while PMs, operations teams, support teams, and other non-developers use the Builder UI to assemble, test, and publish internal agents.

Reading the launch as a low-code UI story misses the more important design choice. Mastra's example starts with allow-lists, not natural language generation. Developers configure tools.allowed, agents.allowed, workflows.allowed, and models.allowed inside MastraEditor, and Builder can only create new agents from those approved primitives. A teammate may be able to create an agent, but code and policy still decide which tool can touch CRM data, which workflow can trigger an operational action, and which model provider can be used.

Mastra's blog example is deliberately concrete. It allow-lists crm-lookup-tool, ticket-search-tool, account-research-agent, customer-onboarding-workflow, OpenAI and Anthropic providers, and observational memory. When a user asks Builder to create a new agent, Mastra discovers the descriptions of the approved tools, agents, and workflows, then stores the generated agent in configured storage. Until publication, the agent can remain private and move through a draft state.

export const mastra = new Mastra({
  editor: new MastraEditor({
    builder: {
      enabled: true,
      configuration: {
        agent: {
          tools: { allowed: ["crm-lookup-tool", "ticket-search-tool"] },
          agents: { allowed: ["account-research-agent"] },
          workflows: { allowed: ["customer-onboarding-workflow"] },
          models: { allowed: [{ provider: "openai" }, { provider: "anthropic" }] },
          memory: { observationalMemory: true },
        },
      },
    },
  }),
});

That code snippet captures the product direction better than the UI screenshots do. The agent creation surface can be opened to non-developers, but the CRM lookup, ticket search, onboarding workflow, and model provider choices stay constrained by developers. In internal automation, the risky moment is not the prompt that creates an agent. It is the tool call that reaches customer records, support queues, billing systems, or approval workflows.

The permission model follows the same pattern. Agent Builder starts with admin and member roles. A member can be scoped with IAM-style permission patterns such as stored-agents:write, tools:execute, and workflows:read. Mastra describes roles as permission bundles. Agents remain private until published and can pass through a draft status. If a company wants an internal agent marketplace, create, test, publish, and execute permissions cannot all belong to the same undifferentiated role.

For engineering teams, the first governance question is not "who can make an agent?" It is "who can combine which primitives?" A support team might be allowed to use ticket search and customer summary tools while only reading a refund workflow. A sales team might get CRM lookup and follow-up drafting, while pricing approval requires a separate review path. Agent Builder's allow-list moves those organizational rules closer to code, where they can be reviewed and versioned.

Mastra's Workflows Enhanced announcement from the same week is part of the same story. The May 27 post describes Temporal integration for durable execution, advanced retries, scheduling, and observability. If Agent Builder answers who may create and share an agent, Temporal answers what happens when that agent kicks off a long-running job and a worker restarts, an API times out, or a scheduled step needs to resume later.

Mastra separates single-agent reasoning from structured workflows. The Mastra Workflows page frames workflows as the right tool for repeatable, predictable, auditable multi-step processes. Steps have input and output schemas and can be composed sequentially, in parallel, through branches, or through loops. A workflow step can call agents, tools, memory, and MCP. Instead of asking one agent to decide everything in one turn, developers expose the path of recurring work as code.

Temporal extends that path across time and failures. Mastra's May 12 Temporal support post introduces @mastra/temporal alongside @temporalio/client, @temporalio/worker, and @temporalio/envconfig. In that model, createWorkflow() becomes a Temporal workflow and createStep() becomes a Temporal activity. Mastra recommends Temporal for workflows that call external APIs, run for hours or days, or need to survive worker restarts.

This is the part of agent products that demos often compress away. A user asks for a contract renewal reminder agent or a customer onboarding agent. The implementation becomes a series of smaller obligations: collect email context, query the CRM, generate a document, request approval, send a Slack notification, retry failed calls, preserve audit logs, and run on a schedule. The system has to decide whether a failure restarts the whole workflow, retries one API call, resumes from a specific step, respects a timezone, or exposes the execution history to a manager.

The Workflows Enhanced post explains retries at that level. Mastra's own RetryConfig supports maxRetries, retryDelayMs, backoffMultiplier, maxRetryDelayMs, and retryableErrors. With Temporal attached, teams can control retries at the action or call level, add jitter, set a maximum retry window, and manage retries through a separate server. Those details are less dramatic than an agent demo, but they determine whether a production workflow fails loudly, retries safely, or silently performs duplicate work.

Scheduling has the same operational weight. A Mastra workflow can run from a cron string, such as a daily report workflow. Temporal treats schedules as separate definitions and supports interval schedules, calendar schedules, timezone-aware schedules, and inspection through Temporal UI. If an internal agent generates a customer risk report every morning or drafts weekly release notes, scheduling is an operating contract, not a convenience feature.

Observability is the third link between Builder and Workflows. Mastra says workflows support debugging through snapshots, suspend/resume, time travel, and run traces. With Temporal UI, teams can inspect execution history, query workflow attributes, and monitor workers and queues. Looking only at the final agent output rarely explains why a decision was made. A workflow trace can reconstruct which step received which data, which tool call happened before a pause, and where retries were spent.

Mastra's position is different from the large SaaS platforms. Microsoft Copilot Studio and Salesforce Agentforce already sit inside broad application suites with identity, admin consoles, billing surfaces, and business records. Mastra starts as a TypeScript framework. Agent Builder's message is closer to "compose agent platform primitives inside your existing TypeScript app and infrastructure" than "move all enterprise data into our platform."

The Mastra homepage says the core framework is Apache 2.0 open source, while enterprise features require a separate license. The Agent Builder launch says it is available for self-hosting and Mastra Platform enterprise edition, and that teams can try it in local Mastra Studio, but deployment requires a license key. That split matters during evaluation. Experimenting with the framework and operating an internal builder for many teams are not the same buying decision.

Open source frameworks are adding enterprise surfaces because the cost structure of agent development is changing. Early agent projects asked whether a team could make an agent at all. The next question is how a company catalogs, permissions, traces, updates, and retires agents made by many teams. As internal agents multiply, duplicate tools, stale prompts, unclear owners, and mismatched model choices become governance problems. A Builder UI alone does not solve that. Roles, storage, publish states, run logs, and workflow state have to travel with it.

Mastra's May 2026 release rhythm points in that direction. Its blog index lists ClickHouse observability, background tasks, response caching, A2A support, an upgraded CLI, Elasticsearch RAG, Temporal workflows, Agent Builder, and multi-user multi-channel agents across the month. Each item looks small in isolation. Together they fill out the operating surface of an agent runtime: caching for cost, background tasks and Temporal for long work, Builder for collaboration, MCP and A2A for external connections, and observability for debugging.

The competitive map includes Vercel AI SDK, LangGraph.js, OpenAI Agents SDK, LlamaIndex.TS, Microsoft Copilot Studio, and Glean Agent Builder. Vercel AI SDK is strong in UI, streaming, and provider abstraction. LangGraph emphasizes graph-based orchestration and durable execution. Microsoft and Glean emphasize enterprise context and governance. Mastra is betting that TypeScript application teams want agents, workflows, memory, evals, and observability in the same language and deployment environment as the app itself.

Community reaction is still limited. I did not find a broad Hacker News or Reddit debate centered on the Agent Builder announcement itself. The visible search surface is mostly Mastra's official blog and docs, release aggregators, Enterprise DNA's open source directory, and Thoughtworks Technology Radar's mention of Mastra as a TypeScript-native framework for AI applications and agents. That makes Agent Builder an early-adopter evaluation story rather than a product category already validated by wide discussion.

Teams evaluating it should examine the gaps before inviting non-developers to create agents. First, the permission patterns need to match the organization's real risk boundaries. If tools:execute is too broad, a sensitive operational action and a safe lookup may end up under the same permission. Second, teams need to define where generated agents are stored and how review works. When an agent moves from private to public, someone should approve the prompt, tool bindings, model choice, and owner.

Third, Temporal brings power and operational load at the same time. It requires a Temporal server, worker processes, task queues, and deployment configuration. Mastra's Temporal support post also marks @mastra/temporal as experimental and warns that APIs can change between releases. Before using it for regulated workflows or customer data operations, teams should check package stability, migration plans, observability export paths, and failure replay policy.

Fourth, template quality becomes a product requirement once non-developers can build agents. If tool descriptions are vague, Builder can pick the wrong primitive. If workflow names are abstract, users will misunderstand what the agent can do. A useful internal agent platform needs a curated tool catalog, examples, owners, and risk labels before it needs a large free-form prompt box.

The practical meaning of Mastra Agent Builder is not simply that PMs can make agents. It is that developers can publish safe building blocks into an internal platform, then constrain the combinations through permissions and execution history. Temporal integration keeps long-running workflows from losing state and retry policy when they fail. For TypeScript teams, the choice is becoming explicit: keep agents as sidecar scripts beside the app, or promote them into a permissioned internal platform.

The first test should be small and read-heavy. Customer feedback summaries, release note drafts, or onboarding checklist generation are better candidates than payment, refund, or account mutation workflows. Allow-list only the tools, models, and workflows needed for that job, create a draft agent, and inspect traces and retries. That exercise answers a more useful question than whether Mastra's Builder UI looks convenient: whether the organization has structured the work tightly enough to delegate part of it to an agent.