Bus Engine Architecture

AI participates in a controlled Linux engineering loop.

Bus Engine runs its engineering loop through Bus Workers backed by Claude or Codex/GPT engine integrations, including Codex App Server for Codex workers. Linux-specific tools, blueprints, policies, isolated build environments, boot tests, logs, and evidence stay on the Bus side. The model handles reasoning; deterministic tools build and verify the system.

Architecture flow

Bus Engine architecture flow Operator requests flow through Bus Engine UI, CLI, or API, then orchestration and policy, then an agent runtime, then a selected hosted or local model. Bus Engine Linux tools use isolated build and validation environments and write blueprints and evidence. Operator Bus Engine UI / CLI / API Orchestration, policy, approval, and audit Agent runtime Hosted or local model provider Linux tools System blueprint Build environment Boot tests and evidence

Agent runtime boundary

Bus Workers are engine-agnostic. Each worker template can select a Claude engine such as Fable 5, Opus 4.8, Sonnet 5, or Haiku 4.5, or a Codex/GPT engine such as GPT 5.5. Bus Engine supplies Linux-specific tools, blueprints, policies, build environments, target information, and validation workflows, while each engine integration exposes its own bus.<engine>.* Events boundary.

Codex workers use Codex App Server as a separate open-source runtime component. Codex App Server uses bidirectional JSON-RPC 2.0; its normal local transport may use standard input/output, and other supported transports depend on the deployed version. Bus Engine HTTP APIs for status, start, stop, and SSH session requests remain Bus Engine APIs, and the worker lifecycle surface is shared across Claude and Codex/GPT templates.

Lifecycle loop

StageWhat happens
DiscoverCollect declared requirements and available evidence from target profiles, Linux systems, inventories, workloads, source repositories, build systems, logs, and acceptance tests.
InferDetermine required capabilities, dependencies, kernel features, packages, services, boot components, filesystems, policies, and validation requirements.
ConfigureCreate or update the versioned blueprint for kernel, userspace, services, boot, filesystems, networking, security, targets, outputs, and tests.
BuildCompile kernels and packages, resolve dependencies, construct filesystems and images, calculate checksums, and produce repeatable artifacts.
VerifyBoot the generated system in an isolated environment, run platform and workload tests, inspect logs and failures, and compare the result with declared requirements.
Diagnose and repairAnalyze build, boot, dependency, kernel, service, and test failures, then revise the blueprint or source inputs and repeat the controlled process.
MaintainUpdate the system as workloads, source code, kernels, packages, toolchains, policies, and upstream projects change.

Permissions and approvals

The agent may inspect, decide, modify, build, diagnose, and repair within the permissions and policies configured for the project. High-impact operations can require explicit approval, while lower-risk workflows may be automated according to customer policy. Privileged work should run inside controlled build and target environments with logs and validation evidence.