A headless execution endpoint built on the OpenFlux engine. It takes AI tasks from NexusAI OS, completes them in a project environment and returns results with a record of the work.
AI task execution layer
01 / Product overview
OpenFlux Runtime is a headless AI execution endpoint built on the OpenFlux engine and runs as the execution layer for NexusAI OS. It registers with OS and claims AI tasks, works from the Agent settings, organizational principles, goals and project materials sent with each task, and handles files, commands and code in a project environment. It then returns deliverables, the work record and any blocker that needs a person, so assigned AI work is completed in the background and leaves results that can be reviewed.
Task brief, Agent settings, project materials and workspace
Deliverables, code changes, service links and work records
The execution layer for organizational work
Built on the OpenFlux execution engine, OpenFlux Runtime has no user interface. It takes AI tasks assigned by NexusAI OS, works in the project environment and returns results and execution records to OS.
Set the Agent’s responsibilities, instructions and work requirements.
After process approval, deliver Agent settings, goals, project materials and work requirements with the task.
Complete the AI work in the project environment and return deliverables, execution records or the reason for a blocker to OS.
OS organizes goals, processes, people and decisions. Runtime registers and claims tasks, follows the Agent settings and project materials delivered with each task, works with files, commands and code in the project container and workspace, and returns deliverables, execution records or a reason it cannot continue.
Deliverable files, code changes, service links and execution records return to the relevant project for the team to review, accept and build on. Blockers requiring a human decision also return to OS.
OS defines what an AI step should do and the context it needs. Runtime claims and executes the task, then returns results, execution records or the reason for a blocker to OS.
Studio creates and configures Agents. OS references those definitions and, after process approval, delivers them with tasks to Runtime, which follows the supplied responsibilities and instructions.
Runtime sends model requests through the enterprise model gateway. Atlas applies the relevant organization’s model access, cost budget and audit rules and records usage.
OpenFlux and Runtime share an execution engine. OpenFlux serves people at the desktop; Runtime has no interface and takes organizational tasks assigned by OS.
02 / Core capabilities
Register with OS and claim tasks, renew them while working and follow pause and cancel requests. Tasks from the same run stay with the same endpoint.
Each task carries the Agent configured in NexusAI and fixed when the process was approved, together with organizational principles, the real-world situation, goals and project materials.
Each project gets its own container and workspace, and commands run inside the project container. Services started in the project get a link once reachable; containers and workspaces are removed when the project ends.
Code steps make changes on their own branch and merge into the project branch, reporting merge conflicts as they are. When a step produces several versions, each keeps its code on its own branch and only the selected one is merged.
Deliverables and a result summary go back to OS, and engine events become a work record, so OS shows what the step did and produced.
Questions the Agent raises during execution are answered from the information already available, so tasks do not stall. When work truly cannot continue, the reason goes back to OS for a person to handle.
03 / Use cases
An AI step in an OS process goes to Runtime. The Agent analyzes project materials and the previous step's results and produces a report file.
The report file, result summary and work record, viewable in the OS project.
Steps that involve code run in the project container on their own branch. Services they start are reachable by link so the people responsible can review them.
Code changes merged into the project branch, plus service links that can be opened.
OS has one step produce several results from different angles. Runtime keeps each version's code on its own branch and merges only the one selected.
Comparable implementations, with only the adopted result kept on the project branch.
04 / How it works
Runtime registers with OS and claims tasks that are ready for AI, receiving Agent settings, goals, project materials and workspace details.
The Agent works with files, commands and code in the project container and workspace, renewing the task and following pause or cancel requests.
Submit deliverables, a result summary and the work record. When work cannot continue, explain why and hand it back to a person.
05 / Scope & combinations
Runtime has no user interface. It claims and completes AI tasks as the execution layer for OS, while goals, processes and human decisions stay in OS.
Runtime stores no model provider keys. Model requests pass through the enterprise model gateway and follow Atlas model access policies, cost budgets and audit rules.
Runtime and OpenFlux share the same execution engine. Desktop actions, long-term memory and scheduled tasks for individuals remain in OpenFlux.
06 / Product relationships
OpenFlux Runtime executes AI tasks assigned by OS and returns the results. Studio Agent definitions arrive with tasks through OS. Atlas governs Runtime model access policies, cost budgets and audits.
OS organizes goals, processes and projects and assigns AI steps to Runtime. Runtime claims each task, completes it in the project environment and returns results, work records or the reason it is blocked.
Agents are configured in NexusAI and, once the OS process is approved, travel with each task to Runtime, which uses them to set the Agent's responsibilities and requirements.
Runtime model requests pass through the enterprise model gateway and follow Atlas model access policies, cost budgets and audit rules, with usage recorded under the owning organization.
OpenFlux serves people at the desktop, who assign tasks and review results. Runtime has no interface and takes tasks assigned by OS. One serves personal work, the other organizational execution.
CONTINUE EXPLORING
Review the wider architecture, or bring this product into a conversation about your team and systems.
Current productOpenFlux RuntimeAI task execution layer
