Writing from Inflowenger
Essays and notes on the runtime, the workflow-graph model, and building AI systems whose every decision is visible before it runs and traceable after.
Jev Bounds the Answer. Who Bounds the Process?
TypeSafe just shipped a model that cannot answer outside the options you give it. That is the FloMorphic thesis, pushed one layer down — and it makes the layer above it more necessary, not less.
Glass-Box Agents Are Not Optional
The AI industry is trying to make the model explainable. That is the wrong box. The weights will stay opaque; what can be made transparent is the process around them — what the model read, what it wrote, which rule accepted it, where the path went next. Agent frameworks let the model's opacity swallow the whole process: routing, tool choice, loop, stop condition. A flow shrinks the black box to exactly one node with a name and a position on a canvas. This post argues that glass-box agents are the precondition for deploying AI anywhere a decision has to survive a question — and that building them means updating how we develop software, not adding an audit log to what we already have.
Your Fleet Is a Live Database. Ask It Something.
With osquery and osctrl behind it, Venapce can pull any fact from any enrolled host, live — processes, ports, packages, containers, firewall rules, files. That makes the fleet a monitoring and data resource, not a set of alerts someone else decided on. This post walks one real workflow end to end: a prompt in Claude Desktop, sent to FloMorphic over MCP, that becomes a graph auditing Docker and external port exposure across Linux nodes, retrying, recording every failure in Stage, and promoting only validated findings to Issues — then charting the result in Venapce's dashboard builder. Nothing was hardcoded. The feature is the flow.
An Agent Can't Act on What It Can't Name
AI agents get vague because their inputs are vague. Before a model can act reliably it has to know what an entity is — which host, which customer, which record is authoritative — and that is a data engineering problem, not a prompting problem. This post looks at how ontology makes agents precise, how Palantir handles it at enterprise scale with objects, links and governed actions, and how FloMorphic implements the same idea as flows you author rather than a platform you buy — a substrate built by a durable flow, verbs that are nodes, and a path drawn before anything runs. That is what makes software progressive and its actions AI-native.
Your Semantic Layer Is a Flow
Emil Eifrem's AIEWF talk argues for thin agents on a shared, ontology-based semantic layer — knowledge engineered as data instead of stuffed into prompts. He's half right. The prompt was quietly doing three jobs: instruction, knowledge, and control. Data engineering removes the knowledge job; flow engineering removes the control job; what's left is a small prompt doing bounded judgment. FloMorphic is the platform where all three layers — the data substrate built as a durable flow, the path drawn as a graph, and the bounded prompt — live in one material and get better through a trace loop.
Venapce: A Nervous System for Security Governance
Venapce is the security segment of Inflowenger, past its feasibility study and now in active development. It is the first product built the FloMorphic way end to end: all of its business logic — collection, correlation, evaluation, reasoning — lives in FloMorphic workflows, and Venapce itself is purely posture and presentation. A Go backend API and a Vue web app, a full BI dashboard and chart builder, and nginx ship together as a single container image, backed by one Postgres database. Two tables carry the model: Stage, where everything the osquery agents collect lands raw, and Issues, where FloMorphic promotes the enriched, real signal. A click on an issue runs an AI-driven workflow that acts like a person — but only inside the flow you designed, with no false-positive actions. Vein, the agents across your compute; synapse, the signal when something is wrong.
Cardinality Is the Loop You Didn't Write
A pattern you reach for constantly — sweep an entire dataset held in some external store, transform each record, write it somewhere — is the same shape behind migrations, backfills, cleanups, and re-embeddings. This post uses one concrete instance of it (re-embedding a Qdrant collection from one model into another) to depict the runtime capabilities that make a flow like this usable in the real world: a plugin installed next to a store the runtime was never compiled against, cardinality that runs one node once per record with payload bound from its own runtime values, and a topology loop — a scroll cursor turned by a backward edge and stopped by a rule — that sweeps the collection page by page. The takeaway is the capabilities, not the example.
Your Evaluator Is a Node. Your Loop Is an Edge.
A hands-on FloMorphic flow where one LLM node evaluates another. The Senior Evaluator observes the worker's whole conversation, decides continue or answered through two bound functions, and — on continue — writes the next question back into the worker's history and loops. The loop is a backward edge and a counter; the observer is a node with two ports; the LLM-judge is a system prompt. Plus the new clear_history flag: why a judge must re-read the context every pass while the worker it judges must not, and why that's now one checkbox instead of a JS node that wipes messages.
Build Your Own Workflow Product — the Runtime Is the Part You Don't Have to Write
The hard part of a workflow product isn't the canvas — it's a durable, cyclic, resumable execution engine that survives crashes and waits on humans for days. Inflowenger ships that engine as a reusable runtime. This post walks the full build: an authoring surface (Vue Flow / React Flow today, or any format you write a compiler for — even a GitHub-Actions-style YAML), the inflow-fusion SDK to own your data and talk to the engine, and a compiler that lowers your source format to the runtime's primitive node set. The compiler stage is the seam: Vue Flow is the one that ships, but the format is open. FloMorphic is built exactly this way; here's how you build your own product on the same foundation.
Yes, It's a Graph. That's Why We Call It Flow Engineering.
In AI-agent teams a role split has hardened: flow engineers build sequential, DAG-shaped automations (n8n, Zapier, CrewAI Flows); graph engineers build cyclic, stateful, dynamically-routed agent systems (LangGraph, AutoGen, Temporal). So which is FloMorphic? Architecturally it's a durable cyclic graph — no dodging. Here is why the split exists at all, why it's a property of the tools rather than of the work, and why the runtime being a graph is exactly what makes 'flow engineering' the honest name for the discipline you practice on top of it.
Integration Count Is a Vanity Metric Now
For a decade, automation platforms competed on one number: how many integrations they shipped. Flomorphic's new Connect page bets that the number stopped mattering. The expensive half of an integration was never the API call — it was OAuth, token refresh, and credential storage. Connect routes that to open-connector's auth gateway (hosted as the OOMOL cloud, or self-hosted), so a thousand-plus SaaS platforms are already authorized once, reusably. The other half — turning an authorized service into a native flow node — is now a short, agent-written plugin. When both halves are cheap, bragging about 400 connectors is bragging about a moat that melted.
FloMorphic Is Now an MCP Server — Drive It From Claude or Any Agent
FloMorphic ships an embedded MCP server mounted at /mcp that mirrors its entire REST surface as tools: author and compile workflows, run read-only SQL against document-store databases, seed context, launch and stop runs, manage prompts, search and index vector memory, add settings profiles for plugins and builtin nodes, answer human tasks, wire triggers, and build a flow from the same AI designer the web app uses. Every write goes through the exact call path a web-app click would, so an MCP-authored flow is indistinguishable from a hand-drawn one. Here's the full catalog of supported actions — including querying databases, adding node settings, and building a workflow step by step — and how to connect Claude Desktop or any MCP agent in under a minute.
Flow Engineering Is an Architecture, Not a Prompting Trick
In 2024 'flow engineering' named a technique: break an LLM task into states and transitions, and accuracy jumps. Nobody built the runtime for it. FloMorphic is that runtime — flow engineering grown up into infrastructure. This is an honest map of where it stands in a crowded market, and the two hard requirements — real loops and durable long-running — that decide who is actually building agents and who is wiring pipelines.
Context-Oriented Software Development
Most Software 3.0 discussion is about prompts and reasoning. The harder question is the execution model: how should an intelligent system operate continuously, over days, across failures and people? Context-Oriented Software Development is the answer this blog has been circling — context becomes the primary unit of execution, AI becomes a routing mechanism, and a durable runtime keeps it all alive. On FloMorphic, none of that is a feature you install. It's the shape of the runtime itself.
Pausing Is Easy. Resuming Is the Hard Part.
A process that pauses is easy. A process that resumes correctly — against a world that changed while it slept — is the whole problem. This is the design decision the FloMorphic runtime rests on: keep the snapshot (where I was) and the context (what is true now) as separate entities, so a resumed process reads its world fresh instead of trusting a week-old copy. From there, joins are WaitGroups, loops are edges that point backward, sub-flows are callable routines, and the runtime guarantees position and integrity while the designer owns meaning.
You Extend Flomorphic the Way You Install a Browser Extension
Most platforms make 'extend it' mean fork the repo, add your code, and redeploy the whole thing. Flomorphic doesn't. A plugin speaks the Inflowenger runtime's own protocol, carries its own SDK and its own configuration UI, and drops into the node palette through a menu — the way an extension drops into your browser. Write it once and it runs on every product built on the runtime.
Reason Once, Reuse Many Times
As frontier models get more capable they get more expensive, and most teams pay the premium on every request. There is another path: small local models handle the bulk, a growing library of reused reasoning does the heavy lifting, and a frontier model is called only when a problem genuinely needs it. Each layer is a shape you draw in FloMorphic — not a framework you install.
Your Company Doesn't Need Its Own LLM. It Needs a Brain.
Owning a frontier model is out of reach for almost everyone. But the thing people actually mean — a company that learns, remembers, and acts on everything it does — isn't a training run. It's a living memory fed by workflows. That's a runtime problem, and it's the one Inflowenger was built for.
FloMorphic, Answered
Every time I show FloMorphic, the same questions come back. What is it, exactly? Is it another agent framework? What is this Inflowenger runtime it keeps mentioning? This is the plain-language version — the answers I give in the room, before the demo starts.
Build a Claims Adjudicator You Can Actually Audit
A hands-on FloMorphic walkthrough. Install, describe a surgical-claims adjudicator to AI Build, and get a workflow that judges each invoice line with a model, calculates money in code, gates deterministically, and parks on a human — every path drawn before it runs.
A Practical Path Forward
AI can clearly write code. The more important question is whether writing ever-larger codebases is the optimal path for AI-driven software engineering. An alternative: design systems at the level of intent — processes, contracts, policies, decisions — where AI works with the architecture instead of reconstructing it from source.
Stop Chat. Start Work.
The AI industry has spent years teaching machines how to talk, yet the human is still doing most of the work. For business operations, conversation is not the goal — execution is. This is the case for governed intelligence operating inside engineered flows.
Two Ways to Extend an Agent Platform — and They're Not the Same Axis
FloMorphic gives you two ways to make the platform do something new — an MCP node and a plugin SDK. The common mistake is treating them as competitors. They live on different axes: one reaches a system you don't own, the other grows a native capability of your own.
The Model Proposes, the Graph Decides
Most teams try to govern AI by writing better prompts. FloMorphic inverts that: the process is drawn first, and the model operates inside it as one bounded participant. The model proposes; the graph decides.