Code-first AI workflows

Code-first AI workflows for product teams

Your team estimated 4 months to build an AI workflow editor in your product. Workflow Builder ships most of it. Visual editor. Reference back-end. Swappable Temporal integration. Your team spends those 4 months on what your product actually needs.

Open-source AI workflow SDK.

15 years
in workflow tools
170+
workflow tools shipped to production
20+
enterprise customers
AI workflow showing a sales inquiry pipeline with nodes for classification, routing, and specialist responses.

THE PROBLEM

AI workflows look easy in a demo. Production is a different problem set.

Most agentic AI projects stall on structure, not models. Durability. Governance. Integration. A UI that shows what non-deterministic systems are doing. One Gartner number from 2025 makes the gap concrete.

Production AI workflows need three things. Durable execution that retries safely. A structured event log you can audit. A UI that shows what each step did. Workflow Builder ships the surface and the execution layer. You keep what should stay yours - models, data, engine choice.

40%

of agentic AI projects will be canceled by 2027

Gartner cites escalating costs, unclear business value, and inadequate risk controls. Governance and audit footprint move from nice-to-have to deal-breaker.

Gartner, June 2025.

CASE STUDIES

What you would have to build

An AI workflow surface has three layers. Workflow Builder ships two.

Grouped by layer, not by feature. The visual AI workflow editor, the reference back-end, and the engine integration. Workflow Builder ships the first two as building blocks and an integration with Temporal for the third. Your team owns the parts that should stay yours.

Layer
Workflow Builder ships
Your team owns
1. Visual AI workflow editor

The React front-end your users see and edit.

Canvas with libavoid edge routing (industrial-grade orthogonal routing) and ELK auto-layout (open-source diagram layout engine)*. Schema-driven properties panels (JSON Schema in, validated forms out). Plugin system with a factory-function contract. JSON serialization for stable saves. Real-time execution highlighting on the canvas via SSE (Server-Sent Events).
Node type definitions for your domain. Product-specific plugins. The React app shell it embeds in.
2. Reference back-end

Engine-agnostic API and graph runner.

Hono HTTP routes on /api/workflows and /api/executions. Topological graph runner with parallel waves and decision pruning. Public engine contract (three port interfaces). Structured event log and graph-level run history.
Where the events are stored. How you host it. Identity and auth (the back-end does not touch them).
3. Engine integration

Durable execution adapter.

Temporal integration shipped today as the reference adapter. Per-activity retry profiles, V8 sandbox (isolated JavaScript runtime), deterministic replay. Architecture ready for additional engine integrations through the same engine contract.
The engine your platform runs. Authorization and auth stay in your stack - the back-end does not touch them. Activities your nodes call: LLM providers, vector DB, internal tools, your observability stack.

* Edge routing and ELK auto-layout available in the Enterprise Edition.

Building a comparable visual AI workflow editor from scratch (Layer 1 only) takes 700+ engineering hours and 300+ design hours. The reference back-end and engine integration save more time on top of that, depending on which durable engine you target.

How code-first works in practice

Author nodes and plugins in code. Render them as a runnable graph.

Engineers define what the canvas can do in code: schemas, plugin factories, and adapter classes. The visual editor is a faithful surface for whatever you defined, no more, no less.

Define a node type in JSON Schema

Describe each node type once. The properties panel renders automatically, validation runs, the JSON serializer keeps your shape stable across saves.

// ai-agent-node.schema.json
{
  "type": "ai_agent",
  "label": "AI Agent",
  "schema": {
    "type": "object",
    "properties": {
      "model": { "type": "string",
        "enum": ["gpt-4o", "claude-sonnet-4-6", "gemini-2.5-pro"] },
      "systemPrompt": { "type": "string" },
      "temperature": { "type": "number",
        "minimum": 0, "maximum": 2, "default": 0.2 },
      "tools": { "type": "array", "items": { "type": "string" } }
    },
    "required": ["model", "systemPrompt"]
  }
}

The engine port — the contract that keeps you portable

Three TypeScript interfaces sit at the boundary between the back-end and your engine. Implementing them is what makes a new adapter possible. Temporal is the integration shipped today as the reference adapter. The architecture is ready for additional engines through the same contract.

// apps/execution-core/src/ports/workflow-engine.port.ts
export interface WorkflowEnginePort {
  submit(input: WorkflowExecutionInput): Promise<void>;
  cancel(executionId: string): Promise<void>;
}

export interface ActivityRunnerPort {
  executeNode(
    node: WorkflowNodeDefinition,
    ctx: ExecutionContext,
  ): Promise<NodeExecutionResult>;
}

export interface EventEmitterPort {
  emitEvent(executionId, type, payload?, nodeId?): Promise<void>;
  updateStatus(executionId, status, error?): Promise<void>;
}

Two adoption paths

No path is forced. The block contracts are public, so a path that fits your platform today does not paint you into a corner tomorrow.

Workflow editor interface showing nodes library, workflow diagram, and node settings on a dark background.
Path A

Visual editor only

Take the visual AI workflow editor (the React front-end) and embed it in your product. On save, your existing back-end and runner take the JSON and execute it however you already do. Fastest path when you already shipped execution and just need the editor inside your product.

Flowchart showing icons connecting to Reference Back-end API, which links to Temporal service.
Path B

Visual editor + reference back-end + engine integration

Adopt the full Workflow Builder SDK. The reference back-end gives you the API surface and the structured event log. The engine integration ships with Temporal today as the reference adapter. The back-end is engine-agnostic by design. Additional engine integrations follow the same three ports.

BUILD OR BUY?

Honest comparison

Workflow Builder vs LangGraph, Temporal-only, n8n, and a custom build

Strengths of every alternative listed in the same row. The wrong tool fits some teams better than us - we say so.

CapabilityWorkflow BuilderLangGraphTemporal (alone)n8nCustom build
Embeddable inside your React productYes - the visual editor renders inside your React appNo - Python/JS framework, no UINo - infrastructure layerPartial - iframe or SaaS, not nativeYes - you build it
Visual editor for engineers and non-engineersYes - production canvas, libavoid routing*NoNoYes - aimed at end usersOnly if you build one
Code-first authoringYes - JSON Schema nodes, plugin SDKYes - code onlyYes - code onlyLimited - JS in nodesYes by definition
Execution engine choiceOpen engine contract. Temporal shipped today; architecture ready for additional engine integrations.n/a - no engineTemporal onlyn8n engine onlyYour choice
Durable execution out of the boxYes - Temporal integration shipped today. Architecture ready for additional engine integrations.No - bring your own runtimeYes - this is what Temporal doesPartial - own runtime, less hardenedNo - you build retries and replay
License and source ownershipApache 2.0 open source. Enterprise Edition available.MIT frameworkApache 2.0 + paid cloudSustainable Use License + paid cloudn/a
Time to a working editor in your productDays to weeksWeeks - no editorWeeks - no editorHours - less controlMany months
When this winsIn-product editor with engine choice intact, code control keptPython-first agent framework, no UI requirementPure durable execution at hyperscaleHosted automation tool for ops usersUnique constraint with time and budget

* Edge routing and ELK auto-layout available in the Enterprise Edition.

Who this is for

What changes for the three people on the buying side

Workflow Builder lands on three desks. Each one needs a different answer.

AI Head Circuit icon

For product owners

Speed to MVP, iteration velocity, user retention.

  • Ship the in-product AI workflow editor in days, not quarters.
  • Templates are the iteration unit. Add a vertical-specific flow without a sprint.
  • Plugin patterns make in-product workflow review natural for your users.
  • The canvas doubles as a debugging surface for power users.
Users icon

For lead devs

SDK ergonomics, debuggability, escape hatches.

  • Factory-function plugin contract. No module-load side effects.
  • Public API surface. No deep imports needed for non-trivial plugins.
  • Public engine contract lets you write an in-memory adapter for tests in a short spike.
  • Live SSE execution stream. Hook into events and drive your own UI.
Shield Check icon

For CTOs

Architecture, vendor risk, governance.

  • Source code in your repo. Apache 2.0 or perpetual Enterprise, no subscription.
  • Engine integration story: Temporal shipped today, architecture ready for additional engines.
  • Structured event log and graph-level run history feed your audit and compliance pipeline.
  • Operational footprint is well-known: standard databases, your existing observability stack.

When this is the right tool

When to choose Workflow Builder, and when not to

The list runs both ways. Workflow Builder is not the right pick for every team.

Workflow diagram interface showing a Simple Workflow Template with nodes named Discovery Agent and Work-plan Agent connected to actions like Fetch meeting notes and Load meeting transcript, featuring AI Chat Models and memory buffers.

Choose Workflow Builder when

  • You ship a workflow or AI feature inside a B2B SaaS product, and the editor must live under your brand and auth.

  • Your users are a mix of developers and non-developers, and both need to read the same workflow.

  • You want code-first authoring with a visual canvas for review, debugging, and human approval gates.

  • You want durable execution as a default, with the freedom to pick which engine runs it.

  • You care about owning the source code and avoiding subscription lock-in.

  • You work in a regulated industry and want a clear audit footprint without locking in to a single vendor's stack.

Screens showing workflow automation chains connecting apps like Notion and Zapier in dark and light modes.

Pick something else when

  • You need a SaaS app your end users sign up for directly. Use n8n, Make, or Zapier.

  • Your workflows are pure code with no graph structure to authorize or review. Use Temporal, Trigger.dev, or Inngest directly.

  • You are building a generic agent framework, not a workflow product. Use LangGraph or CrewAI.

  • You need a single LLM call, not a workflow. Use the SDK of your LLM provider and skip the editor entirely.

Architecture

How the blocks fit together in an AI orchestration platform

Four layers, clear seams. The visual editor lives inside your product. The reference back-end is the engine-agnostic shell. The engine adapter is the bridge. The engine itself is whatever your platform already runs.

Layer 01

Your B2B SaaS product

your React app
Auth & identityStays inside your platform — WB never touches auth.
In-product UI shellYour routes, your nav, your brand surrounding the editor.
@workflow-builder/sdkReact components, plugin system, JSON Schema panels.
Layer 02

Reference back-end

engine-agnostic shell · WB ships
Hono HTTP routes/api/workflows, /api/executions, SSE event stream.
Pure-domain graph runnerTopological + parallel waves, decision pruning.
Public engine contractThree port interfaces define the engine integration boundary.
Layer 03

Engine adapter

swappable bridge
Temporal integrationShipped today as the reference adapter. Per-activity retry profiles, V8 sandbox, deterministic replay.
Custom engine adapterArchitecture ready for additional engine integrations through the same three-port contract.
Layer 04

Execution engine, activities, your data

whatever your platform already runs
Durable engine runtimeTemporal Cloud, self-hosted, others.
LLM providers + retrievalOpenAI, Anthropic, Gemini, vector DB.
Internal tools & APIsYour services, webhooks, data stores.
Observability & auditYour existing stack.

The reference back-end (Layer 2) is engine-agnostic. The engine adapter (Layer 3) is a separate, swappable block. Temporal ships today as the reference adapter. More engine integrations follow the same contract.

Built for the SDK, opinionated about the stack

The reference back-end records structured events for every run, exposes them via Server-Sent Events to the front-end, and stores a graph-level run history. That gives you a clean audit footprint without dictating which storage, IAM, or observability tool you use.

Building for a regulated industry (fintech, HR, healthcare, insurtech, edtech) where audit, human oversight, or vertical-specific compliance maps onto the workflow? Talk to the team behind Workflow Builder — the same engineers who built the SDK help you map compliance requirements onto it, without taking over the build.

Where it slots into your stack

  • Identity and authorization stay in your platform. The SDK and reference back-end do not touch auth.

  • Customer data stays where it already is. The reference back-end's tables sit alongside, not inside, your business schema.

  • LLM providers, vector DBs, and tools sit behind the engine contract. Swap any of them without touching the editor.

  • Observability is whatever you already run. The engine adapter you pick provides metrics; the SSE stream carries node-level events.

CASE STUDIES

Customers

AI product teams already shipping on Workflow Builder

Two of the AI-native companies that embedded the SDK as their workflow surface.

Screenshot of athenaintel.com showing a contract summary workflow with steps, properties, and data results.AI orchestration

Athena Intelligence

Athena Intelligence was building a data and AI orchestration platform. Their users needed to design multi-stage agent pipelines connected to a Neo4j knowledge graph. They had the canvas live in production within the first sprint - their execution engine, their brand, no compromise.

“The actual integration into our stack was very painless for how heavy the UI is.”

Athena Intelligence, engineering
Read the full case study
Dark-themed AI call flow chart showing steps for conversations, eligibility, and call endings.AI automation

Plura AI

Plura AI is an automation platform for AI-native workflows - the visual editor is the core product, not a side feature. They needed to ship fast, keep full white-label control, and own their execution layer. Workflow Builder gave them all three. Production-ready editor in weeks, not quarters.

“Why would we build this ourselves when we don’t have the expertise and could delegate to specialists?”

Plura AI, on the build vs SDK decision
Read the full case study
Four people working on laptops around a wooden table in a casual office setting.

The team behind Workflow Builder

Workflow Builder is built by the team who spent 15 years building workflow and visual configuration tools. The team is available if you are looking for a partner to guide you through implementation, customization, and development of your project on top of the Workflow Builder SDK.

CASE STUDIES

FAQ

Questions engineering teams ask before adopting

Direct answers, no padding. Each question came from a real procurement or technical-eval conversation.

  • What is a code-first AI workflow platform?

    A code-first AI workflow platform lets engineers define workflows in code (typed SDKs, schema files, plugin functions) and renders the result as a runnable graph. It pairs developer ergonomics with a visual surface for review, debugging, and human-in-the-loop gates. Workflow Builder is a code-first platform: a visual AI workflow editor (React front-end), a reference back-end with three port interfaces, and engine integrations you compose to fit your stack.

  • What execution engines does Workflow Builder support?

    The reference back-end is engine-agnostic by architecture. Workflow Builder ships a Temporal integration today as the reference adapter. The architecture is ready for additional engine integrations through the same public engine contract. Other engines can be added by your team, or as part of an engineering engagement with the team behind Workflow Builder.

  • Can I embed an AI workflow editor inside my own SaaS product?

    Yes. The visual AI workflow editor is the React front-end of the Workflow Builder SDK, published as the @workflow-builder/sdk npm package. You compose plugins, pass node types and templates, and render it inside your React app. The bundle is small, ships as ES modules, and exposes a public API surface for non-trivial plugins without deep imports. Embedding it takes hours, not weeks.

  • How do I build durable AI workflows that survive crashes and retries?

    Run AI workflows on a durable execution engine. Workflow Builder is engine-agnostic by architecture - the engine contract in the reference back-end lets any durable engine plug in. Today Workflow Builder ships a Temporal integration with deterministic replay, sandboxed runs, and per-activity retry profiles. The architecture is ready for additional engine integrations through the same contract.

  • What is the difference between LangGraph and Workflow Builder?

    LangGraph is a Python and JavaScript agent framework. It assumes you write the workflow in code, you run it, and you build the UI yourself. Workflow Builder is an SDK with three composable blocks: a visual AI workflow editor, a reference back-end, and engine integrations. It gives you the visual editor, the persistence model, the execution stream, and the human-in-the-loop primitives, with code-first node and plugin authoring.

  • What is agentic AI workflow automation?

    Agentic AI workflow automation is the practice of letting LLM agents drive a multi-step process with tool calls, decision branches, and feedback loops. It differs from classic automation because steps can be non-deterministic, retries are expensive, and human approval is often required. A durable execution engine and an editable visual graph make it manageable in production.

  • How does Workflow Builder compare to n8n, Make, or Zapier?

    n8n, Make, and Zapier are SaaS automation platforms aimed at end users automating their own tasks. Workflow Builder is an SDK (visual AI workflow editor + reference back-end + engine integration) aimed at product teams embedding a workflow surface inside their own product. If you want a hosted tool, pick the SaaS. If you ship workflows as a feature of your product, the SDK pattern wins on brand, data residency, and source ownership.

  • What does the EU AI Act require for AI workflow audit trails?

    Annex III of the EU AI Act (the high-risk AI category) takes effect February 2027 for fintech, HR, edtech, healthcare, and other named verticals. Workflow Builder's reference back-end records every workflow event in a structured log and exposes a graph-level run history through the SDK - useful inputs for an audit footprint. Full Annex III mapping in a regulated vertical is an engineering and compliance exercise; the team behind Workflow Builder offers consulting support to map those requirements onto the SDK.

  • What is the difference between the Workflow Builder SDK, the reference back-end, and the Temporal integration?

    The Workflow Builder SDK is the whole offering: three composable blocks. The visual editor is the React front-end you embed in your product. The reference back-end is the engine-agnostic execution shell: HTTP API, graph runner, three port interfaces. The Temporal integration is the adapter that wires the back-end to Temporal as the durable engine. You can adopt all three, swap the engine integration for one against your own engine, or take just the visual editor and run the JSON in your existing runtime.

Button Text