The Context Runtime for Software V3
Build intelligent systems where workflows, integrations, automation, and AI operate on a shared context. Inflowenger is a runtime architecture that transforms business logic into workflow graphs and treats data as living context rather than isolated requests.
The runtime for flow engineering — designed for AI-native applications, enterprise integration, automation, and orchestration.
Software has moved through three architectures. Each shift moved the center of the program — from the instruction, to the network call, to the context itself.
Software V1 was procedural. Programs executed linear sequences of instructions on single machines. The program was a sequence.
Software V2 became service-oriented, cloud-native, and API-driven. Systems were composed of distributed services communicating over networks. The program was a graph of calls.
Software V3 is context-driven. Systems no longer execute static logic in isolation — they continuously process information through workflows, integrations, events, policies, and AI. This is the shift Andrej Karpathy names Software 3.0: the context becomes the program, and the model is its interpreter.
The primary unit of computation is no longer a function call. It is a Context.
Karpathy named what the program becomes; he did not say what runs it. If the context is the program, something has to own it — persist it, scope who may read and write each slice, route on it, and record what happened. Inflowenger is that runtime: a place where a context is durable, scoped, inspectable, and editable, instead of a window that evaporates when a single model call returns. FloMorphic is the harness drawn on it.
Inflowenger is a backend runtime that manages how information flows through a system.
Every request, event, document, or business object enters the platform as a Context. The context travels through a workflow graph where nodes can transform data, apply business policies, invoke services, integrate external systems, execute automation, trigger events, call AI models, and make decisions.
Instead of distributing logic across dozens of services, Inflowenger centralizes execution into a transparent and observable workflow model.
One runtime, one harness on top of it, and real products implemented on the harness.
Context processing is the bottom of the stack and nothing we ship skips it. On top of the runtime sits FloMorphic, which is the system we use to build AI-native systems: a process is defined there — its valid states, its transitions, its policies and its approval points — and a model contributes judgment inside that definition instead of deciding the path itself.
Venapce and SurfStat are implemented under FloMorphic. They are not separate stacks that happen to share a vendor. Their business logic is FloMorphic flows, their durability is the runtime's, and each product is the view over what those flows produce.
Everything enters as context and travels a workflow graph. Loops, waits, child flows, crash recovery and an account of what ran.
FloMorphicWhere a process is defined as a contract and AI is given a boundary to think inside. Glass-box by design: the graph is the logic, and every run leaves a record.
The FloMorphic page →A nervous system for a security estate — fleet, network and cloud senses feeding flows, with the panel as the view.
The Venapce page →An authoring substrate for governed data — the estate made reachable, then governed, then a process drawn across it.
The SurfStat page →Which is also the test of whether the runtime is worth anything: the segments those two already cover, and what the second one cost to build after the first.
Understanding Inflowenger through a computer analogy.
| Traditional Computer | Inflowenger |
|---|---|
| CPU | Fractal Runtime |
| RAM / Heap | Context |
| Program | Workflow |
| Function | Node |
| Thread | Process Instance, Node as Embedded Flow |
| Operating System | Inflowenger Runtime |
| Extensions, Drivers & Interrupts | Plugins, Extrinsic Nodes |
| CoProcessors | Fractal Instances |
A Workflow acts as the program. A Context acts as memory. A Fractal acts as the processor. Together they form a runtime capable of executing business processes, integrations, and intelligent workflows.
The Context is the living state of a process. It is represented as a JSON document and contains everything required for execution. Every node reads from and writes to the Context. The Context evolves throughout its lifecycle.
A Workflow defines how a Context evolves. Workflows are composed of interconnected nodes that perform actions, transformations, validations, integrations, and decisions. They represent the logic of the system.
A Fractal is the execution engine of Inflowenger. It processes Context through workflow graphs. Fractals are recursive by design, allowing complex systems to be composed from smaller reusable processes.
Traditional systems embed logic inside services. Inflowenger externalizes logic into workflows.
AI Is a Capability, Not the Architecture
Many platforms place AI at the center of the system. Inflowenger takes a different approach.
AI is treated as a component within a larger execution model. The platform focuses on orchestration, governance, workflows, and integrations while allowing AI systems to participate as first-class capabilities.
This makes Inflowenger useful even without AI and increasingly powerful when AI is introduced.
Structured Intelligence
The AI Harness provides a controlled environment for integrating models, tools, memory, and reasoning systems into workflows.
Instead of tightly coupling applications to specific AI providers, the harness creates a stable execution layer for intelligent systems.
Reasoning Through Iteration
Modern AI systems often require multiple passes before reaching a reliable result. Inflowenger introduces Loop Systems as a native execution primitive.
The workflow continues until success conditions are satisfied. This allows intelligent systems to be built using transparent and controllable execution patterns.
Connect Anything
Real systems depend on APIs, databases, events, queues, cloud services, and legacy platforms. Inflowenger connects to all of them through two extension concepts: Extrinsics and Plugins.
Extrinsics are backend functions and actions implemented as NATS subjects, so the concept works natively with NATS.io and event sourcing. Relying on this node type, you can seamlessly add custom nodes that call a function at runtime and inject the result directly into workflow context.
Plugins implement the InflowV1 protocol, a shared contract between the front end and the runtime. It covers a JSON Schema-based form builder (compatible with formjson.io), long-running process handling, and stream handling. Any node with a custom structure or UI is built as a plugin — comprehensive plugins support both the front-end and runtime side of the protocol.
Depending on where it needs to run, the same kind of integration is implemented as an extrinsic or a plugin — in practice, that covers things like:
None of this ships as a core adapter — extrinsics and plugins are the patterns you implement each integration with. What you build isn't locked to one project, either: a plugin store lets you publish, add, and remove plugins across products, so each one shows up as a ready-made node in the workflow canvas's palette instead of getting rewritten from scratch for every project that needs it.
Inflowenger is a workflow operating platform that provides the runtime, coordination, and infrastructure required to build and scale workflow-driven applications. A centralized infrastructure layer coordinates multiple runtime containers, enabling scalable execution while keeping system complexity manageable.
It empowers developers and organizations to create specialized systems tailored to their unique ideas through a visual workflow experience similar to n8n, while retaining full control over their application's behavior and architecture.
With Inflowenger, teams can focus on designing and refining business logic without worrying about workflow execution, real-time processing, scalability, or infrastructure management.
What follows is ordered the way the layers actually stack: the harness first, then the products authored on it, then the pieces they reach through. The segments those products cover are the proof that the order holds, and the ecosystem map lays out every repository behind them, with the one to read first for whatever you are trying to do.
FloMorphicContract-Driven AI. Experts define the process, the valid states, the allowed transitions, the policies and the approvals — and AI contributes judgment within those boundaries, on a runtime built from explicit primitives. Everything below this line is authored on it; FloMorphic itself holds no security logic and no compliance logic.
Read the introduction →Named for its two halves — vein, the pathways between assets, and synapse, the signal when something's wrong. The first product built the FloMorphic way: all logic lives in workflows, and Venapce is the view — a posture panel and dashboard builder, shipped as one image.
See the product page →The intelligence and orchestration fabric for data governance: reachable data first, governed data second, and whatever the organization needs authored on top — an ISMS, a compliance programme, regulatory reporting, or one queryable register of what it knows. Two tables, a graph engine and an execution record that never move, so a new process is a flow an expert draws rather than a release engineering ships.
See the product page →Not a product but a library: the toolkit for building plugins against the InflowV1 protocol — now in three languages, Go (the reference implementation), Node.js / TypeScript and Python, all wire-identical. The same contract used for plugin UI and node builders across the ecosystem.
Browse the plugin catalog →An AI agent installed on a host you control, dropped onto the canvas as a node. Legate is the general pattern — a plugin that is an agent, handed an instruction rather than a script, shipping its host's own capabilities as an in-process MCP server so local files and remote MCP tools look the same to the model. The first coding agents built that way already ship: the Claude Agent and Codex Agent plugins drive the coding agent installed on the plugin's own host, working in a real tree with a port for the questions they can't answer alone.
A runtime is easy to describe and hard to believe. The honest test is whether whole systems come out of it — not demos, but the kind of software a security team or a compliance function would actually operate — and whether the second one costs less than the first. That is what the products below are for.
All of it sits on the two layers above — the runtime and the harness on it — and neither of those layers holds a line of security logic or a line of compliance logic. The segments below are authored on top: a flow, a vocabulary and a view.
Examples, not boundaries. Every line below is a flow somebody authored, and the next line is the same move — in any organization, with any mission.
A nervous system for a security estate: all logic in FloMorphic workflows, the product itself only the view.
An authoring substrate for governed data: make the estate reachable, govern it, then draw the process across it.
One destination organizations reach from the same substrate, named directly because it already has products in it.
The segment turned on the toolchain itself: an agent installed where the code is, handed an instruction rather than a script.
The claim is about the mechanism, not about a list of features. Adding a framework, a detection rule, a report or a whole new area of work means authoring a flow and a vocabulary over a schema that doesn't move: no migration, no redeploy, no release train, and the system keeps running while you do it. The two products are the same machine under different nouns — SurfStat is forked from Venapce, stage → issues became records → cases, and the runtime under both was untouched.
To show that, we built one scenario as a demo: a synthetic bank branch with 180 days of data and 38 planted findings, with fraud surveillance, credit risk and IFRS 9, and supervisory returns authored over it. Regulated finance is only the setting we picked, because it asks more of a schema than almost anything else. The result is the part worth keeping: all six sweep flows came out as the same eleven-node graph, and not one of the nine flows added a column, because a framework's vocabulary is stamps in tags.
Anything could stand where those frameworks stand. A hospital's patient-safety reporting, a ministry's procurement checks, a manufacturer's quality holds, a logistics group's customs evidence — any organization, any mission. The work is the same shape every time: a flow, a vocabulary, and nothing to redeploy.
Software is moving toward systems that understand context, coordinate workflows, integrate intelligence, and continuously adapt.
Inflowenger provides the runtime layer that makes this possible. Not by replacing existing technologies. But by connecting them through a unified model where:
Where Context Becomes Computation