How Ainova is built
A layer-by-layer analysis of Ainova’s technology stack: why every architectural choice has a precise rationale, and what it means for those evaluating the platform as a buyer or as an investor.
Describing a technology stack is easy. Explaining why it is built a certain way is far more useful. Ainova is not a single product: it is a modular platform designed to govern autonomous AI agents in real operational environments. Every layer of its architecture reflects a deliberate choice about where to place control, where to allow flexibility, and where traceability is non-negotiable.
What follows is a layer-by-layer reading of the Ainova ecosystem — from the UI all the way down to the foundational level of delegation contracts.
The operational plane: the control console
The visible surface of Ainova is ainova-control-hub, the console through which operators and administrators manage agents, policies, budgets, risks, and billing. It is a single-page application built with React 18 + Vite 5 + TypeScript, and this choice is deliberate: Vite with the SWC plugin delivers extremely fast build times and a tight development feedback loop, while TanStack Query handles server-side state without imposing Redux-style architectures.
Primary admin/operator console. No local persistence: all state lives in the backend.
evidence-stream is the second frontend: a separate module dedicated to evidence workflows, forensic reporting, and compliance documentation. It uses Supabase as its BaaS — a deliberate choice that cleanly separates evidence data from the main operational database, with edge functions handling report generation and webhooks.
The source of truth: backend and governance
If the UI is the surface, ainova-control-hub-backend is the system-of-record. It is built with Fastify + Prisma + PostgreSQL, using JWT for authentication and Pino for structured logging. The backend owns everything that carries permanent state: users, holdings, workspaces, agents, assignments, transitions, budgets, performance metrics, risks, and billing.
Why Fastify and not Express? Fastify provides native JSON Schema validation, high-throughput routing, and a strongly typed plugin system. In a context where every request may involve a policy authorization decision, framework latency matters.
Stripe handles billing; Resend and an SMTP fallback cover email notifications. The deploy target is Hetzner, with CI/CD via GitHub Actions running separate jobs for lint, type checking, unit tests, contract tests, and route tests against a real PostgreSQL instance.
A validation layer fully separated from the main backend. Every request enters, is evaluated against policies, and exits with a decision. No database writes. No sessions.
The separation between the stateful backend and the stateless compliance engine is one of Ainova’s most significant architectural decisions. It means the enforcement engine can scale independently, be versioned separately, and — critically — be tested in isolation against any policy scenario without touching the database.
Gateways to external runtimes: the adapters
Ainova does not execute AI agents directly. It governs them. That distinction is fundamental, and it materialises in the adapter layer: ainova-claude-adapter and ainova-openclaw-adapter are stateless boundary services that sit between an external runtime (Anthropic’s Claude, OpenClaw) and Ainova’s authority layer.
Every execution step of an agent passes through the gateway. The gateway asks Ainova: can this agent, with this identity, perform this operation right now? The answer is deterministic and fully traced. Adapters carry no storage of their own — they are intentionally stateless so they can be deployed without horizontal dependencies.
Gateway to the OpenClaw Runtime. Validates the request, translates it into Ainova’s format, and returns the decision to the calling runtime.
The specialist engines: LungClaw and Enkronos Agent Core
lungclaw-core is Ainova’s deterministic governance engine — the system that computes whether a metabolic policy is satisfied or violated. It is built with Express + pg + prom-client, has its own PostgreSQL storage, exposes native Prometheus metrics, and offers three primary endpoints: /evaluate, /commit, /metrics. It is deliberately isolated: it receives policies from the outside via ainova-compliance-engine, produces decisions, and carries no dependency on the UI or the main backend.
enkronos-agent-core is the orchestration and runtime execution layer: it manages runs, worker models, audit trails, usage tracking, and webhooks. It has its own PostgreSQL and Redis instances and exposes an API with full OpenAPI documentation. It is the foundational execution layer of the Enkronos ecosystem, today integrated into the Ainova architecture as a parallel execution core.
The data plane: self-hosted infrastructure
One of the most significant characteristics for enterprise prospects and investors alike is that Ainova controls its own data infrastructure. There is no cloud provider holding agent execution data or governance logs.
The presence of Qdrant is particularly telling: it signals that Ainova is designed to support semantic search over agentic contexts, not just relational storage. Temporal guarantees workflow durability and re-executability even in the event of a fault — critical for systems where an agent halting mid-operation is not an acceptable outcome.
The foundation layer: contracts and architecture
Two modules anchor the bottom of the stack: agent-contracts and agent-infrastructure.
Formalises delegation contracts between agents: who can do what, in which context, within which limits. This is not documentation — it is a validatable specification layer with a CLI. It defines the handoff protocol that every upstream module respects.
agent-infrastructure is the architectural documentation layer for the entire system: system patterns, architecture decision records, SVG diagrams. It executes nothing — but it defines the vocabulary through which every other module communicates.
What this all means, in short
Ainova has a coherent, deliberate stack. It is neither a monolith disguised as microservices, nor a collection of components without a unifying logic. The structure is clear:
An operational plane (ainova-control-hub) where operators see and act. A source-of-truth plane (ainova-control-hub-backend) where everything with permanent state resides. A stateless enforcement plane (ainova-compliance-engine, lungclaw-core) that validates every decision without side effects. Boundary adapters toward heterogeneous runtimes, built to be versioned independently. A self-hosted data plane that guarantees data sovereignty. And a foundation layer that formalises contracts before the code ever implements them.
For those evaluating Ainova
If you are a prospective enterprise customer: the stack described above means Ainova can be deployed in your environment, with your data under your control, and a verifiable audit trail on every decision made by every agent. The compliance engine is separated by design — you can extend policies without touching the runtime.
If you are an investor: the technological coherence — TypeScript end-to-end, stateless/stateful separation, observable self-hosted infrastructure — reduces the risk of architectural rewrites in the next 18 months. The adapter model toward external runtimes positions Ainova as a horizontal governance layer, not as vendor lock-in on a single AI model.
Ainova’s real bet is not technological. It is categorical: that companies deploying autonomous AI agents will need a governance operating system separate from the runtimes themselves. The stack described in this article is built precisely to be that system.
