Every team that ships more than a handful of AI-powered applications eventually rediscovers a problem that operating systems solved fifty years ago: unmanaged shared state and duplicated plumbing scale quadratically, not linearly. The first three apps each carry their own database client, their own auth glue, their own LLM invocation wrapper, their own retry logic. By app twenty, a change to how you talk to a model provider is a twenty-file migration. By app two hundred — which is roughly where our production system, Luca AI Express, sits today — the codebase is either coherent because something forced it to be, or it is not a codebase anymore; it is an archaeology site.
The situation is strictly worse when the authors are AI coding agents. Human engineers at least gossip: conventions propagate through code review and hallway osmosis. Agents have no hallway. Each agent session starts from a cold context window, reads what it can, and writes what seems locally reasonable. Without a hard structural boundary, an agent fleet produces two hundred locally-reasonable, globally-incompatible implementations of everything. The interesting engineering question is not "how do we prompt agents to be consistent" — prompting is advice, and advice decays — but "what architecture makes inconsistency mechanically difficult?"
Our answer is the AIOS pattern: treat the shared substrate of an AI product portfolio as an operating system kernel, with everything that implies — module contracts, a service registry, lifecycle management, and health as a first-class, mandatory export. This page describes the pattern as we run it in production: a kernel of roughly 49 OS modules underneath about 22 business domains and 200+ application surfaces, shipped continuously by multiple AI coding agents through a serialized merge queue. Aspects of this architecture are patent-pending; we describe it here at the level of mechanism and rationale, not implementation.
Taking the OS analogy seriously
"Operating system for AI" is usually a metaphor. We mean it structurally. An OS earns its keep through three properties:
- A syscall boundary. Applications do not open disks; they open files. The kernel owns the messy substrate and exports a narrow, stable interface.
- Resource arbitration. The kernel decides who gets what — scheduling, memory, I/O — because uncoordinated consumers destroy shared resources.
- Uniform lifecycle. Processes are created, supervised, and reaped the same way regardless of what they do.
Translate each into the AI-product setting. The messy substrate is model providers, vector and relational storage, queues, telephony, email, third-party APIs, credential handling, and observability. Resource arbitration is rate limits, token budgets, connection pools, and concurrency ceilings — shared resources that one badly-behaved surface can exhaust for all the others. Uniform lifecycle is initialization order, dependency readiness, graceful degradation, and shutdown.
In our kernel, each of the ~49 modules owns exactly one substrate concern — one module owns model invocation, one owns persistent storage access, one owns scheduling, one owns outbound messaging, and so on. Application surfaces never touch the substrate directly. They compose kernel modules the way a Unix process composes syscalls. The number 49 is not designed; it is discovered. Modules split when a contract accumulates two unrelated responsibilities and merge when two contracts are always consumed together. The count drifts slowly, which we read as a sign the decomposition is tracking real seams rather than an org chart.
200+ app surfaces ~22 business domains AIOS kernel (~49 modules)
┌────┐┌────┐┌────┐ ┌───────────────┐ ┌──────────────────────┐
│ S1 ││ S2 ││ … │ ──────▶ │ domain logic, │ ────────▶ │ registry ▸ contracts │
└────┘└────┘└────┘ │ workflows, │ module │ model I/O · storage │
thin: UI + intent │ policies │ calls │ sched · msg · memory │
└───────────────┘ only │ health ── exported ──┼──▶ ops
└──────────────────────┘The load-bearing consequence: an application surface is thin. It expresses intent and domain policy; everything operational lives one contract call away. That is what makes two hundred surfaces tractable — they share one implementation of every hard problem, and the hard problems are versioned in exactly one place.
Module contracts: the unit of coherence
A kernel module in our system is not a folder convention. It is a contract-bearing unit, and the contract is enforced at load time, not by review-time goodwill. Conceptually, every module must declare:
- An exported interface — the operations it offers, with typed inputs and outputs. Consumers bind to the interface, never to internals.
- Declared dependencies — which other modules it consumes. The kernel derives initialization order from the resulting DAG and rejects cycles outright.
- Lifecycle hooks — uniform init/ready/drain/shutdown semantics, so the kernel can bring the system up and down deterministically.
- A health export — more on this below; it is mandatory, not optional.
- An ownership and versioning declaration — who (or which agent workflow) maintains it, and what compatibility regime its interface follows.
The comparison that lands with systems people is Linux kernel modules crossed with OSGi-style service manifests, applied to an AI product substrate. The comparison that lands with platform people is "an internal platform, but with the interface discipline of a kernel rather than the interface discipline of a wiki page."
Contracts matter double in a multi-agent delivery pipeline. When an AI agent modifies a module, the contract is the reviewable artifact: did the interface change? Then compatibility rules trigger, dependents are enumerable, and the merge queue can require the corresponding migrations before the change rides a release train. Did only internals change? Then the blast radius is provably the module itself. Contracts convert "trust the agent's judgment" into "check the agent's diff against a machine-verifiable boundary" — which is the difference between hoping for coherence and manufacturing it.
Every contract change also ships with its Codex entry — our institutional-knowledge requirement that each change carries an executable blueprint/playbook/runbook triple into a governed corpus, now 440+ entries. The kernel's dependency DAG and the Codex's knowledge graph are browsable side by side at ticket.lucaexpress.com, which means an agent (or a human) asking "what depends on the storage module's interface?" gets a graph answer, not a grep answer. Cold-context agents inherit the hallway we said they lacked: the graph is the gossip, made queryable.
The service registry: discovery without linkage
Modules and domains find each other through a registry rather than direct imports. A surface asks the registry for a capability; the registry resolves it to the module currently providing it. This buys three things that direct linkage cannot:
- Substitution. When we route certain workloads to small fine-tuned models produced by our Model Forge pipeline instead of frontier models, consumers do not change. The capability's contract holds; the provider behind it moves. Model portfolio decisions become kernel routing decisions, not application rewrites.
- Arbitration at the point of resolution. The registry is where concurrency ceilings, budget policies, and degradation rules attach — one enforcement point instead of two hundred well-intentioned client-side implementations.
- An honest inventory. The registry is a live census of what the system actually provides and who actually consumes it. Dead capabilities become visible; shadow dependencies cannot form, because there is no way to consume a capability without resolving it.
The classic objection is that registries add indirection and a runtime failure mode ("resolution failed") that static linkage doesn't have. True. We accept it because in an agent-authored codebase the alternative failure mode — agents importing whatever they find, creating a dependency graph nobody declared — is worse and, unlike resolution failures, invisible until it bites.
Health as a first-class export
The most consequential rule in the kernel is also the simplest: a module without a health export does not load. Health is not an afterthought endpoint bolted on by the ops team; it is part of the module contract, produced by the code that owns the concern, aggregated by the kernel into a system-level readiness picture.
Why elevate health to contract status?
- AI substrates fail non-binarily. A model provider degrades — latency doubles, a model version starts refusing a category of request — long before it "goes down." Binary liveness probes see nothing. A health export owned by the model-invocation module can report semantic degradation, because it sits where the semantics are.
- Agents need machine-readable ground truth. Our delivery pipeline gates merges and release trains on system health. An agent about to ship needs an answer to "is the system healthy enough to accept this change?" that is not a human reading dashboards. Health-as-export makes the answer a value, not a vibe.
- Aggregation follows the dependency DAG. Because dependencies are declared, the kernel can compute why a surface is unhealthy — walk the graph from a failing surface down to the degraded module — rather than presenting two hundred simultaneously red dashboards during an incident.
The candid failure mode: health signals rot. A module's health check that never fires false starts to lie; one that fires often gets tuned into silence. We treat health-check quality as reviewable code with its own Codex runbook coverage, and we still consider this an open discipline problem rather than a solved one. Anyone who tells you their health signals are trustworthy without continuous adversarial pressure on them is describing an aspiration.
Trade-offs and failure modes, honestly
The AIOS pattern is not free, and we have paid several of its bills.
The kernel is a coupling point. Forty-nine modules shared by everything means a bad kernel change has total blast radius. Our mitigations are the serialized merge queue (one change lands at a time, so causality is never ambiguous), health-gated release trains, and contract-compatibility checks — process compensating for concentration. A monorepo of independent apps would fail more locally. It would also never be coherent. We chose coherence and bought insurance.
Contract rigidity taxes exploration. Strict interfaces are exactly wrong for the prototype you don't yet understand. We run experiments above the kernel in surface-land, and only promote a capability into the kernel once its shape has stabilized. Promoting too early fossilizes a guess; promoting too late lets three divergent implementations breed. Judging that timing remains a human researcher's job.
Registries invite lowest-common-denominator interfaces. When a contract must serve twenty consumers, there is pressure to widen it until it says nothing. We counter with the split rule above — a module whose interface needs two vocabularies is two modules — but this is gardening, not automation.
The pattern presumes an enforcement point. Everything here works because load-time checks, the merge queue, and the release train can reject nonconforming changes. Teams that adopt the vocabulary (modules! contracts! registry!) without the rejection machinery get the ceremony without the coherence. The kernel is the enforcement, or it is decoration.
Where this is heading
Two threads occupy our current research. First, contracts as agent context: the module contract, its dependency neighborhood, and its Codex triple together form a near-complete working set for an agent modifying that module — we are studying how far contract-scoped context can shrink what an agent must read before it can safely write, which bears directly on using small fine-tuned models for maintenance work inside the kernel. Second, health-informed scheduling: closing the loop so that the release train does not merely gate on aggregate health but plans around it — sequencing changes by the health posture of the modules they touch. Both threads point at the same conviction: the operating system was never a metaphor. It is the missing layer between AI agents that can write code and AI systems that can be trusted to run.
Gus IT Research Institution takes on external research engagements in AI systems architecture, agent-driven delivery, and applied small-model work — reach us to discuss consulting or tooling licensing.