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.
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.
Built on top of Inflowenger, we are also developing the following projects — and the ecosystem map lays out every repository behind them, with the one to read first for whatever you are trying to do.
Contract-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.
Read the introduction →Not a product but a library: the toolkit for building plugins against the InflowV1 protocol, the same contract used for plugin UI and node builders across the ecosystem.
Browse the plugin catalog →A plugin node that is an agent. Installed on one machine — a build server, a jump host, a box the platform cannot reach — and handed an instruction rather than a script. It ships that host's capabilities as its own in-process MCP server, so local files and remote MCP tools look the same to the model.
See what it does →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 →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