FloMorphic, Answered

Every time I show FloMorphic to someone new, the same handful of questions come back. Not the deep architectural ones — those come later. The first ones are simpler, and I think they deserve a plain answer before any demo starts.

So this is that: the questions I actually get asked, answered the way I answer them in the room.

What is FloMorphic?

FloMorphic is a platform for building agents.

Not a chatbot, and not a single autonomous agent you set loose and hope for the best. It's a builder — you compose an agent, or a system of several agents working together, on a canvas. And the thing that makes it different from the other agent builders is the shape it forces the agent into.

Every agent you build follows a contract pattern. You declare, up front and in the open, what the agent is allowed to do: which states are valid, which transitions are permitted, where a policy is checked, where a human signs off, and exactly how far the model's discretion reaches. The model still does the reasoning — it reads, it weighs, it proposes. But it proposes inside a structure that was drawn before it ran.

That structure is what people in the industry have started calling a harness — the scaffolding you put around a model so its power becomes usable in a system that has consequences. Most harnesses today are a thin wrapper: some output validation, some logging, some retries. FloMorphic gives you the harness as the first-class thing you build, not an afterthought you bolt on.

The one-line version I keep coming back to: the model proposes; the graph decides.

Okay, but what is it for?

For putting AI inside processes that have to be defensible.

There's a difference between "get me a smart answer" and "run this claim, this credit decision, this triage, this compliance check — and be able to tell me afterward exactly why it went the way it did." The first one, a chat model already does well. The second one is where almost every AI project stalls, because when someone asks on what basis was this decided, and where is the record?, the honest answer is usually "it's somewhere in the prompt, or in the agent's loop, or in the model's weights" — three places you cannot audit.

FloMorphic exists to close that gap. It lets you use the full reasoning power of a language model, but only under conditions you set and can see. I describe that as AI performance on a transparent surface — the model stays as capable as it is, but every path it could take, and every path it did take, is drawn somewhere a human can read.

Those two things — the power of the model, and the transparency of the surface it runs on — are really one idea. You don't get to keep the intelligence and throw away the accountability. FloMorphic's whole bet is that you can have both, and that the way you get both is by drawing the process first.

What is Inflowenger, and how is it different from FloMorphic?

This is the question I most want people to get right, because they're not the same thing.

Inflowenger is the runtime. FloMorphic is one product built on it.

Inflowenger is a flow-diagram runtime, written in Go for performance and scale. Its job is to execute a workflow — a graph of nodes and edges — over a living context, fast, and to scale from one laptop to a cluster without changing shape. It doesn't know anything about AI specifically. What it knows is how to run logic that lives in a dynamic layer instead of being frozen into code.

That's the part worth sitting with. In most enterprise systems, the business logic is the code — spread across services, buried in branches and handlers, changeable only through a deploy pipeline. The process the business actually runs exists nowhere as a single artifact; you reconstruct it by reading the code. Inflowenger inverts that. The process becomes the artifact — a workflow graph an operator can see and change — and your existing systems wire into it as participants. If you're running an enterprise system whose logic isn't static, that needs to change as the business changes, Inflowenger is built to carry exactly that, and it has clean ways to wire into the business logic you already run.

So: Inflowenger is the engine. FloMorphic is what you get when you draw one particular palette — the agent-building palette — on top of that engine.

Which came first?

FloMorphic did not come first as the goal. It came first as the proof.

Inflowenger was the thing being built — a general runtime for logic that lives in a dynamic layer. FloMorphic started life as a way to show what that runtime could do: take the primitives, draw an agent-building palette on them, and demonstrate that a serious, real-world use case falls out of the same small set of parts.

And then something shifted. Once there was a proper model node on the runtime — a node that runs an LLM, gives it outbound tool calls, and knows how to speak MCP — the demo stopped being a demo. It became obvious that this exact shape filled a real gap that the whole industry is fighting with right now: how do you use everything a language model knows, but only on your terms, in a way you can inspect and govern?

So FloMorphic grew up from "here's what the runtime can do" into "here's a product that needed to exist." Both things are still true. It's the proof that nothing in Inflowenger is reserved or hidden, and it's a real answer to a real problem.

Isn't this just another agent framework?

The pieces will look familiar if you've built with agent frameworks — RAG, tool use, an agent loop, guardrails, reflection, multi-agent orchestration, human-in-the-loop. The difference is that in most frameworks you assemble those in code, as separate concerns, each one opaque to someone. Here they're all compositions of the same small set of primitives, drawn on one canvas.

The agent loop isn't a hidden while loop you can't see into — it's a cycle on the graph. A guardrail isn't a prayer in a prompt — it's a rule node the flow passes through. Multi-agent orchestration isn't a special feature — it's one graph calling other graphs, with real parallelism underneath. The thing you compose on day one is the thing that runs in production and the thing you audit afterward. Not three different representations — one artifact.

How is this different from n8n, Make, or Zapier?

On the surface, it isn't — and I'll say that plainly, because pretending otherwise fools no one. You draw boxes, you connect them, work flows through. In appearance and in the diagram, FloMorphic and the visual automation tools — n8n, Make.com, Zapier, and the rest — are cousins. The resemblance is real.

The difference is underneath, and it's not cosmetic.

Tools like n8n are built in TypeScript/JavaScript. Inflowenger is built in Go. That's not a language preference — it's a ceiling. Go gives you the concurrency, the throughput, and the memory behavior you need to run this as infrastructure, at industry scale, not as a convenient tool for personal automations and lightweight tasks. When the goal is a claims engine or a compliance process running under real load, the runtime underneath stops being an implementation detail and becomes the whole game.

But the deeper difference is what Inflowenger is. These are automation products. Inflowenger is a runtime with an architecture built to bind systems together and to have whole products drawn on top of it — and yes, that includes something shaped like one of them. The trigger-and-connector automation builder is one palette you could author on the runtime. FloMorphic is a different palette — the agent-building one. Neither is the engine; both are configurations of the same primitives.

Put it this way: if n8n is an app, Inflowenger is the framework that could build an n8n for you. And n8n is genuinely excellent in its own segment — if you want quick, connector-driven automations, reach for it. But if you want to build a no-code / low-code system that's fully wired into and integrated with one coherent system, Inflowenger is the better approach.

That's the Software V3 claim, and I don't make it lightly. The bet is that we're in a transition from legacy software — where business logic is frozen into code across a hundred services — to context-driven software, where the process is a living artifact over a shared context, changeable without a redeploy. Inflowenger is the runtime for that transition. FloMorphic is the first proof it holds up: a genuinely novel take on the AI harness, and a no-code / low-code agent builder aimed at entering industries — the places where processes have consequences — not just wiring up personal shortcuts.

So the honest answer is: if you line them up as diagrams, they look alike. If you ask what each one is for, and what it's made of, they're not in the same category.

Do I have to rewrite my systems to use it?

No. That's usually the point where these conversations die, so it's worth being clear.

Your existing backend doesn't get replaced or migrated. It joins. It answers the graph over a request/reply call, and the graph calls it. A system that's been in production for a decade can become AI-native without a rewrite, and can grow from a single machine to a cluster by attaching more processors — not by re-architecting.

It's open source, Apache-2.0, and self-hostable. The model and MCP nodes are ordinary plugin binaries with no privileged access — whatever you build gets the same contract they do. There's no hosted-only trick holding the interesting part back.

Where do I start?

If you want to run it, Docker is the only prerequisite, and the canvas comes up on localhost:8090:

curl -fsSL https://raw.githubusercontent.com/FloMorphic/getting-started/main/install.sh | bash

Repo: github.com/FloMorphic/getting-started

Concepts and docs: inflowenger.com/flomorphic

I keep building this because I keep meeting the same wall: the model is good enough, and the system around it isn't defensible. As AI moves into processes with real consequences, the hard problem stops being how do we get an intelligent response and becomes how do we understand, govern, and evolve the system that produced it. That's the question FloMorphic is my answer to. If you work somewhere that "why did the system decide that?" carries legal weight, I'd genuinely like to hear where this framing holds and where it breaks.

If you want the longer argument behind all this, start with The Model Proposes, the Graph Decides.