FireFlow Stack Vision

This article lays out the full FireFlow stack

This article lays out the full FireFlow stack in a single place — what each layer does, why the layers compound rather than aggregate, and which use cases this combination unlocks beyond “yet another agent builder.”

In short: we are not building a single product called FireFlow. We are building a three-tier architecture in which each tier already has competitors on its own, however the assembled stack does not exist anywhere else.

TL;DR

1. FireFlow — a durable visual agent runtime. The engine.

2. @persistent-ai/fireflow-frontend — the same editor, shipped as an npm React component library. The embeddable surface: a third-party SaaS adds it to their product with import and <FireFlowProvider/>. Already in production as the foundation of our own end-user app.

3. Flame Chorus — a Go service that handles chat rooms and multi-agent conversations. It talks to FireFlow through a shared DBOS database rather than over HTTP, streams responses over the AG-UI protocol, and uses json-render for generative UI so an agent can return components instead of text.

These three pieces are three tiers of the same abstraction:

More important than any head-to-head with Langflow is this: Tier 2 occupies a quadrant no one has claimed. That’s not a gap to fill — it’s a category waiting to be defined.

Who is this for?

This document speaks to three audiences:

• Founders mapping the agent-platform landscape.

• Investors and advisors identifying category whitespace.

• Engineering-savvy prospects evaluating FireFlow as the substrate for their own product.

The framing is deliberately strategic — focused on what becomes possible — while maintaining significant architectural depth to make that framing meaningful.

Components Status in Brief

Tiers 0 and 1 ship today. Tier 2 is where we are headed — 2026–2027 horizon.

Why now?

Three things converged in 2025 to put this stack on the right side of timing.

Tooling protocols stabilized. MCP went from an Anthropic project to an industry standard in under a year. AG-UI emerged as a credible event protocol for agent UIs. The plumbing for agents talking to tools and to UIs stopped being something every team had to reinvent from scratch.

Generative UI crossed the threshold. React Server Components, the Vercel AI SDK, OpenAI’s ChatKit — agents rendering components rather than markdown is no longer exotic. But every existing implementation is either vendor-locked or framework-bound. None combine a per-tenant component catalog, mid-stream patching, and durable interrupts.

Multi-agent coordination is still improvised. Frameworks like CrewAI, AutoGen, and LangGraph hand developers primitives to assemble agent teams in code. Products like ChatGPT and Claude.ai hand end users one agent in a closed UX. Nobody offers rooms as substrate — durable conversational space where users compose their own multi-agent teams, rendered into the host product’s UI.

The protocols are ready. The demand is legible. The substrate is missing. That is the gap.

The Architecture

The key visual element is at the bottom: DBOS is a shared bus. Flame Chorus and FireFlow do not call each other over HTTP. They communicate through persistent streams in a single database. That arrangement is what makes durability, replay, and shared state possible across the whole conversation lifecycle rather than just inside one service.

One non-obvious design decision: shared database, not microservices

Most multi-service platforms wire components together with gRPC, REST, or message queues — and then spend years managing eventual consistency, partial failures, and causal chains that break at service boundaries. We went the other way.

FireFlow and Flame Chorus share a DBOS-backed Postgres instance. All cross-service communication happens through persistent streams and JSONB fields on shared tables. The practical consequences:

A single transaction boundary spans the entire agent-conversation lifecycle — no two-phase commits, no sagas, no drift between message state and workflow state. Replay covers the whole chain: a crashed run can be replayed end to end, including the chat-side bookkeeping, something HTTP-coupled services cannot offer past their own boundary. New integrations require stream contracts, not schema migrations coordinated across teams. And operations live in one Postgres — backups, observability, RBAC, and schema evolution all in one place.

This is an unusual choice at this level of complexity. DBOS is what makes it tractable, turning a single Postgres into a durable execution engine. The reward is a stack that scales as one coherent system rather than two products held together with retries and timeouts.

What each component actually does

Component 1 — The FireFlow Engine

FireFlow: a durable visual agent runtime built on DBOS. Four things separate it from Langflow, Dify, and n8n.

Typed ports on every edge — errors that would have been runtime crashes become design-time mistakes you cannot save. The SP-Tree execution engine delivers deterministic parallel execution across the flow graph, not best-effort scheduling. DBOS underneath means exactly-once semantics, replay, and crash recovery are engine primitives, not retrofits. And MCP groups, AG-UI nodes, subflows, and durable waits are first-class objects, not plugins.

This is the layer most directly comparable to existing competitors. It is also where today’s revenue lives.

Component 2 — The editor as an npm library

The most underexposed part of the stack. The FireFlow editor ships as a standalone React library — @persistent-ai/fireflow-frontend, BUSL-1.1, via private GitHub Packages — not as part of a monolith.

The embed API looks like this:

import {
  FireFlowProvider,
  Sidebar, FlowTabStrip, Flow,
  initFireFlow, NodeRegistry, SuperJSON
} from ‘@persistent-ai/fireflow-frontend’
import ‘@persistent-ai/fireflow-frontend/style.css’

initFireFlow(session, {
  trpcMainURL: env.VITE_FIREFLOW_TRPC_URL,
  trpcExecutorURL: env.VITE_FIREFLOW_EXECUTOR_URL,
  nodeRegistry: NodeRegistry.getInstance(),
  superjsonCustom: SuperJSON,
})

<FireFlowProvider session={session} config={cfg} flowId={id} theme={theme}>
  <Sidebar enabledTabs={[’vfs’,’nodes’,’mcp’,’executions’,’debug’]}/>
  <FlowTabStrip/>
  <Flow/>
</FireFlowProvider>

• Any third-party SaaS can embed a full agent editor inside their product with pnpm add and four lines of React.

• We have already done this ourselves — the embed runs in production in our own end-user app, with custom authentication, theming, and marketplace GraphQL built around it. None of that required touching the editor itself, which is what makes the embedding contract credible rather than hypothetical.

• The licensing is enterprise-friendly: design partners get scoped private access via GitHub Packages, the source is not publicly mirrored, and commercial terms are handled under a separate agreement.

On the competitive scorecard, agent embedding tops out at 2 across our 16-vendor scan. We sit at 3. Dify gives you an iframe. Langflow gives you a hosted page. n8n gives you a webhook. OpenAI locks you to ChatKit. Nobody else ships the editor as a reusable npm library with a peer-dependency contract.

Component 3. Flame Chorus — the layer above FireFlow

This is the most often misunderstood component. Flame Chorus is not “FireFlow with a chat UI.” It is a separate Go service solving a different problem.

The integration between them comes down to three primitives over the shared DBOS database:

What this architecture makes possible:

• Agent identity lives in the workflow ID (fc:run:{chatID}:{messageID}:{agentID}). FireFlow stays agent-agnostic; Flame Chorus decodes the ID. The two engines evolve on independent schedules.

• AG-UI splits into two streams: one spec-clean — pure AG-UI events any compliant client can consume (Vercel AI SDK, Mastra UI, others) — and one carrying platform-specific verbs over a mailbox-style reply pattern. Agents are not locked to our chat engine.

• No new tables. Everything between the two services flows through streams and JSONB on existing entities, keeping schema evolution and operational ownership simple.

Component 3.5 — json-render

This is the least visible part of the stack in our public materials and arguably the strongest single bet in it.

The core idea fits in a sentence: the model only ever sees two tools — render and triggerAgent. Everything the agent draws for the user is a component pulled from a manifest catalog that the customer’s frontend publishes.

What that idea unlocks:

• A per-tenant component catalog. A bank publishes its own RiskCard, PositionTable, and ApprovalDialog. The agent learns the vocabulary automatically through catalog.prompt() — no retraining, no prompt engineering on the customer side.

• Streaming generative UI. Not “agent finishes thinking, then a component appears” — a component that assembles in real time as the agent reasons, patch by patch.

• Durable interactivity. Clicking a <Confirm/> dialog resolves through a GraphQL submitInterruptResolution call that wakes the workflow in DBOS. A user can close the browser for a day; replay reconstructs the UI deterministically when they return.

• Tool result as UI. getStock(AAPL) returns a <StockChart/>, not a markdown table. The component is the default response shape.

This is not another UI streaming feature. It is a different paradigm for how an agent communicates with a user — and nobody else has it in finished form. The Vercel AI SDK has RSC streaming but no manifest catalog, no mid-stream patching, and no durable interrupts. ChatKit has fixed widgets but no generative composition.

Substrate vs Framework vs Product

The clearest single way to position the stack is on the substrate axis.

A framework hands you primitives and a blank page. A product hands you a closed experience. A substrate sits between the two: it wraps the assembly question, the durability question, the UI question, and the multi-agent topology question into one coherent contract — and then gets out of the way, so that customers end up building inside your product rather than inside the substrate vendor’s product.

That slot is currently empty.

The shift in positioning

The old story: FireFlow is a durable visual agent runtime. We compete with Langflow, Dify, n8n, and Temporal. Our wedge is putting visual canvas, durable execution, and AI-native nodes inside one engine.

This is true but incomplete. Across the seven axes we benchmarked against twenty-six products, FireFlow leads on reliability, ties for first on visual + durable, and trails on procurement maturity. That is a conversation about where we win inside an existing category.

The new story: FireFlow + Flame Chorus is a substrate for a new class of products — multi-agent room platforms with user-authored teams and generative UI. A category nobody currently occupies. ChatGPT, Cursor, and Claude.ai are products in this quadrant, but they are monolithic and single-vendor. We are the substrate that lets a customer assemble their own agent team inside their own product.

The new story does not replace the old one. It adds a second wedge that sits above the first. The old wedge is about axes where we are being compared today. The new wedge is about a category where we are not yet being compared at all.

Use-cases that open up

These are not “what we ship today.” They are what the assembled stack makes possible — some already live, some credible projections that the architecture turns into realistic engineering work.

1. Multi-agent collaborative roundtables. A Researcher, a Critic, and a Writer in one room — each a separate FireFlow flow, handing off through triggerAgent. Not an orchestrator inside one agent (the LangGraph pattern). The conversation itself is the coordination layer.

2. Tool result as UI. The agent calls getStock(AAPL) and returns <StockChart symbol=”AAPL” range=”1Y”/> instead of a markdown table. The component is the default response shape. This is live for us and missing in the competition.

3. Human-in-the-loop approvals with durable resume. The agent emits a <Confirm/> or <DatePicker/> through an interrupt. The user decides whenever they decide — an hour later, a day later — and submitInterruptResolution wakes the run. The natural application territory is payment approvals, meeting scheduling, and change-request sign-offs: the financial and regulated scenarios where today’s SaaS agents fail because they lose state across the human-decision gap.

4. Cross-room topology. Chat-to-chat connections. A “triage” room fans out to specialists in separate rooms; their answers flow back through a dedicated stream. Today this pattern is approximated with email forwarding or Slack threads. Here it becomes a first-class graph of communication between agent teams.

5. Per-tenant agent catalog as a USP. An enterprise customer publishes their own components — <RiskCard/>, <PositionTable/>, <ComplianceDialog/> — and agents learn the visual vocabulary automatically. No custom training, no prompt engineering on the customer side. The customer’s component library effectively becomes an API for AI agents.

6. AG-UI passthrough as federation. Our agents speak pure AG-UI. Any compliant external client — Vercel AI SDK, Mastra UI, others — can consume them directly. This makes agent-as-a-service real: we can sell agents over an API even to customers who built their chat experience on a different stack.

A worked example: Acme Markets

To make the substrate idea tangible, here is one full journey end to end. Acme Markets is a hypothetical but realistic B2B treasury and risk SaaS for mid-market corporates. Their existing product already has a polished UI: <RiskCard/>, <PositionTable/>, <HedgeApprovalDialog/>, <PolicyChecklist/>. Their customers are corporate treasury teams whose idiosyncratic approval workflows are configured today through screen-by-screen forms.

Acme wants to add an “AI co-pilot for treasurers.” They evaluate building it on OpenAI Assistants with a custom UI, on LangGraph with bespoke chat, or on FireFlow + Flame Chorus. Here is what the FireFlow path looks like.

Phase 1 — engine only (weeks 1–6). Acme’s platform team picks up the FireFlow Engine. They wire MCP nodes around their existing internal APIs — positions, FX rates, the policy engine — and build three flows: MorningRiskBriefing, HedgeProposal, PolicyCheck. The flows run inside Acme’s infrastructure as durable workflows. At this point Acme has roughly what LangGraph plus Temporal would give them, with one fewer thing to assemble themselves.

Phase 2 — embed the editor (weeks 6–14). Acme drops <FireFlowProvider/> into their admin app. Now their customers — corporate treasurers — log into their tenant and see a flow editor with only Acme’s MCP nodes exposed. A treasurer at a large manufacturer can build a custom WeeklyHedgeReview flow that matches their internal policy without writing code and without going through Acme’s professional-services queue. The substrate sells itself: every Acme customer authors their own automation, on Acme’s brand, using Acme’s data.

Phase 3 — Flame Chorus rooms (months 4–6). Acme stands up Flame Chorus alongside the engine. Each customer tenant now has chat rooms — “Risk Review,” “Daily Briefing,” “Hedge Approvals.” A treasurer drops three agents (MarketResearcher, RiskAnalyst, Compliance) into the Risk Review room. The agents talk to each other and to the human, publishing into Acme’s existing component catalog — RiskCard, PositionTable, and so on — and rendering in Acme’s own UI vocabulary. Conversations are durable: close the laptop on Friday, the discussion is right there Monday morning.

Phase 4 — durable HITL on regulated decisions (month 6 and on). This is the scenario that sells the stack. The RiskAnalyst flags a hedge proposal that exceeds the customer’s policy threshold and emits a <HedgeApprovalDialog/> through a durable interrupt. The dialog routes to the CFO by email. The CFO is on a flight; reviews on landing fourteen hours later; clicks “Approve with conditions.” The workflow resumes inside the same conversation thread, with full state preserved and an end-to-end audit trail. The compliance officer reviews the same thread on Monday. The whole regulated approval is one durable agent conversation rather than seven emails and a spreadsheet.

What is worth noticing: Acme did not have to choose between “AI assistant inside our product” and “deeply customizable workflows our customers control.” They got both, on infrastructure they did not have to build themselves. And none of their customers could have gotten this from ChatGPT Teams — because ChatGPT does not render in their UI, does not call their MCP nodes by default, and does not survive a CFO closing their browser.

Strategic Implications

1. FireFlow on its own is a product in an existing category — AI workflow runtimes. We compete with Langflow, Dify, n8n, and Temporal. Our architectural wedge is reliability. This is the 2025–2026 season.

2. FireFlow + Flame Chorus together is substrate for a category that has not crystallized yet as a mainstream pitch. This is the 2026–2027 season — about category emergence rather than winning an existing fight.

3. The editor as an embeddable library is a distribution strategy, not a category. But it is what makes the substrate play viable. Without it, we wait for customers to come to us. With it, we go into their products.

Adoption path for a customer

The stack is not all-or-nothing. A serious prospect can adopt it in phases:

What this is not

The substrate framing can over-promise. It is worth being clear about where it does not apply.

• Not a consumer chat product. We are not chasing ChatGPT for individuals.

• Not no-code for non-technical buyers. The editor is visual, but the substrate is built for builders — engineering teams, technical product owners, and design partners with internal R&D capacity.

• Not a Cursor replacement for solo developers. Single-developer IDE assistants operate on a different cost curve and answer different success criteria.

• Not free or fully open-source. BUSL-1.1 plus commercial terms. The goal is enterprise distribution, not community virality.

FireFlow & Flame Chorus inside an IDE — an illustrative scenario

This is a thought experiment to show where the substrate could go, not a committed roadmap. It is included because it makes the category-emergence argument sharper than the fintech case does.

Today, the state of the art in AI coding is the single-agent CLI — Claude Code, the Cursor agent, Codex. A team of ML engineers running any of these tools is effectively N independent instances of one agent. There are no roles, no context handoff between agents, and no shared state.

Here is what changes if you ship FireFlow + Flame Chorus as a VSCode extension.

The point here is not the feature gap. The point is that Cursor and Claude Code are products — one agent, one vendor, one UX, with the user tweaking a system prompt.

FireFlow + Flame Chorus inside an IDE is substrate. The user edits a team graph: “this repo runs a three-agent PR-review team, that one runs a Test-Writer plus a Refactor-bot, and the legacy service runs a solo Senior with extended memory.” The team lives in .fireflow/ inside the repo, gets reviewed in pull requests, and travels with the project. That is a different purchase decision: not a personal-productivity feature for one developer, but a team development practice like CI or linting.

One risk worth naming: time-to-hello-world is worse here. claude in a terminal takes seconds; this scenario requires a local Docker stack. This is not for casual single-developer use — it is for teams where repeatable team-shape matters more than one developer’s personal convenience.

Glossary

• DBOS — open-source durable execution platform on top of Postgres. Workflows are exactly-once, crash-recoverable, and replayable.

• AG-UI — open protocol for streaming agent runs to a UI. Events include TEXT, TOOL_CALL, REASONING, STATE, RUN_STARTED, RUN_FINISHED.

• MCP — Model Context Protocol. The standard way for agents to discover and call external tools.

• SP-Tree — our deterministic parallel execution engine for flow graphs. A strict-partial tree of node executions.

• json-render — our generative-UI layer. The model emits a component spec; the frontend assembles it into a real component tree token by token.

• RFC-6902 patches — the JSON Patch standard. We use it as the wire format for incremental UI updates during a stream.

• FireFlowProvider — the React context boundary inside which the embedded editor runs.

• Generative UI — the pattern where an agent returns interactive UI components instead of markdown. The tool result is the UI.

• Substrate — infrastructure other companies build their products on top of. Different from a framework (which expects you to assemble it) and from a product (which is closed).