Runtime, not just a library
Contenox was a complete runtime environment – with API gateway, background workers, storage, and observability – not just a collection of helper functions.
Archived runtime project for sovereign GenAI applications
Build and operate AI workflows as observable state machines.
Contenox was a self-hostable runtime for deterministic, chat-native AI applications. It orchestrated language models, tools, and business logic without giving up control over data, routing, or behaviour.
The Contenox venture has been shut down. The kernel remains available as open-source software and can be used as a reference implementation or for experiments in AI workflow runtimes.
- ⚙️ Runtime, not a library
- 🧩 Explicit state machines
- 🧠 Built-in RAG & tools
- 🛡️ Self-hosted & sovereign
Contenox is no longer under active development. This page remains as documentation and context for engineers, analysts, and curious people exploring the ideas and architecture behind the project.
See Contenox in action
A short walkthrough of the chat interface, state-machine workflows, and observability tools. The demo reflects the state of the project before it was sunset.
Chat-native interface & workflow inspector
The Contenox UI combines a chat client with a visual workflow inspector and execution traces – so you can see exactly which states, tools, and hooks were involved in each conversation.
What was Contenox?
Contenox was a self-hostable runtime for building and operating enterprise-grade AI agents, semantic search systems, and chat-driven applications. It modelled AI behaviour as explicit, observable state machines instead of opaque prompt chains.
State machines, not black boxes
Workflows were explicit graphs of tasks, handlers, and transitions. Every step was visible, controllable, and replayable.
Chat-native interface
Users interacted via chat, but under the hood each message drove a deterministic workflow – from RAG queries to tool calls and side effects.
Vendor-agnostic & self-hosted
It could run on-prem, in your cloud, or air-gapped. Requests could be routed across OpenAI, Ollama, vLLM, or custom backends without lock-in.
Why the idea still matters
Even though the Contenox venture has ended, the core thesis remains relevant: modern AI systems drift into opacity. Runtimes that make logic, data flow, and side effects explicit help teams reason about behaviour instead of guessing.
Sovereignty
The runtime was designed so teams could own data, execution, and decision boundaries – with no hidden SaaS layer that might change behaviour unexpectedly.
Reliability & control
Workflows were deterministic state machines: tasks, transitions, retries, and human approvals were defined explicitly instead of being buried in prompts.
Transparency & compliance
Every state change, model call, and hook invocation was logged and traceable – a foundation for auditing, governance, and regulation.
When Contenox was a fit
During its active lifetime, Contenox complemented APIs like OpenAI’s tools or MCP. It was most useful once single AI calls turned into real workflows.
It made sense when…
- Agents triggered real side effects in production systems.
- You needed multi-step logic, branching, retries, or approvals.
- Production observability and replay mattered.
- Self-hosting or regulated environments were requirements.
It was probably overkill when…
- You were building a simple Q&A chatbot.
- A single OpenAI tools / MCP call per request was enough.
- You were just exploring ideas without persistence or complex workflows.
AI workflows as explicit state machines
Contenox executed AI workflows as explicit state machines. Every step – LLM call, data fetch, or external action – was a task with defined inputs, outputs, and transitions.
Hooks: connect to anything
Agents were extended with hooks – remote services that integrated external APIs, databases, or tools. Any OpenAPI-compatible endpoint could be registered and turned into callable tools for models.
Declarative & observable
Workflows were defined in YAML or via API. Each execution was logged and traceable: transitions, model calls, hook results, and intermediate state were all visible.
Knowledge-grounded workflows
Built-in RAG pipeline with document ingestion, embeddings, and vector search (e.g. via Vald) enabled agents to answer based on your data.
Multi-model orchestration
Requests could be routed across Ollama, vLLM, OpenAI, or other providers, with configurable fallbacks and policies per task.
Architecture at a glance
Contenox was built as a modular, container-first system. The runtime could be embedded into existing stacks or deployed as its own AI infrastructure layer.
Core components
- Backend: Go runtime & API gateway.
- Workers: Python for parsing, embeddings, and long-running jobs.
- Storage: PostgreSQL for metadata and state.
- Cache & queues: Valkey / Redis.
- Vector search: Vald for RAG indices.
Interface & deployment
- Frontend: React + TypeScript chat client and visual builder.
- Backend-for-frontend pattern for the UI.
- Containerised and designed for Kubernetes.
- Suitable for on-prem, cloud, or air-gapped setups.
Contenox was not a black-box SaaS, but software you could run and adapt – a runtime that sat between LLMs and real systems.
Project status
The core kernel of Contenox remains open-sourced at github.com/contenox/runtime .
A preliminary OpenAPI specification for the runtime API is available as JSON and YAML. It reflects the last public state of the project.
The Contenox venture has been shut down. There is no hosted product, no commercial offering, and the code is not actively maintained. Issues and pull requests on GitHub may only be reviewed occasionally.
For occasional questions or historical context about the project, you can still reach out at hello@contenox.com, but replies cannot be guaranteed.