Inside Psyclone AIOS: The Architecture
Psyclone AIOS™ is a real-time AI operating system: a C++ runtime that lets slow, powerful reasoning (frontier LLMs, planners) and fast, deterministic control (sensors, actuators, live conversation) run as one coordinated system. This page is the technical deep-dive. For the category-level pitch, see Sub-millisecond AI; for the product overview, see Psyclone AIOS.
Why the technical depth matters commercially: if you’re evaluating Psyclone for production, three properties decide whether it fits — latency you can budget for (a message layer designed for sub-100μs delivery, not “usually fast”), reliability engineered rather than assumed (a hardened core with the failure modes designed out, not patched around), and integration that meets your stack where it is (C++ and Python modules, mixed clusters, live introspection). Everything below exists to deliver those three properties. If the details check out for your use case, the licensing model is deliberately simple, and the deployment record shows the same architecture surviving contact with real hardware and real customers.
The core runtime: a real-time message bus in C++
At the centre of Psyclone is a high-performance message bus written in C++, designed for sub-100μs message delivery between modules. Modules never call each other directly — all interaction happens through semantically typed messages published to and consumed from shared spaces. This message-based scheme is fundamentally more flexible than remote method invocation (the CORBA/DCOM model): senders don’t need to know who is listening, receivers subscribe by message type (with wildcard subscriptions), and the topology of the system can change while it runs. Psyclone implements the OpenAIR specification, extended with support for real-time data streams — so raw audio, video, and sensor feeds move through the same runtime as discrete messages, under the same timing discipline. The runtime is written for performance and robustness and runs on Windows and UNIX-based platforms.
Whiteboards™: publish-subscribe on a blackboard
Psyclone’s coordination model is built on patent-pending Whiteboards™ — a publish-subscribe realisation of the classic blackboard pattern from AI systems research. Multiple modules post semantically typed messages to a Whiteboard; any module can subscribe to the types it cares about and react as data arrives. This decouples producers from consumers completely: a perception module doesn’t know or care whether one module or fifty are consuming its output, and new consumers can attach without touching existing code. Modules written in different languages interoperate through Plugs — small code stubs that speak the standard AIR message protocol regardless of implementation language. The result is what we call divisible modularity: systems are built incrementally out of heterogeneous, multi-granular pieces, rather than forced into one monolithic design or one rigid protocol.
On top of the messaging layer sits a hierarchical context system: activation states that sequence and switch system behaviour dynamically. Instead of hard-wiring control flow, you declare which modules are active in which contexts, and the runtime handles the switching — so a system can move between, say, “listening,” “deliberating,” and “acting” configurations without a central controller becoming a bottleneck or a single point of failure.
Why sub-100μs matters: three time scales, one system
Real-world AI systems live on three very different clocks at once. Physical control — motors, actuators, high-frequency sensing — runs in kilohertz loops, where a millisecond of jitter is a failure. Human conversation runs on 300–500ms turn-taking rhythms; miss that window and the interaction feels broken. And frontier-model reasoning takes multiple seconds per call. A coordination layer can only serve all three if its own overhead is negligible against the fastest of them — which is why Psyclone’s messaging is designed for the sub-100μs band. At that speed, the bus effectively disappears from the latency budget: a kilohertz control loop can run through the same runtime that is simultaneously brokering a five-second LLM call, without either interfering with the other.
This is the “System 1 / System 2” architecture — fast reflexes and slow deliberation in one mind — realised as an operating system. Typical LLM-orchestration frameworks are built for request-response: chain a prompt, await a reply, pass it on. That model works for chatbots and batch pipelines, but it has no concept of deterministic timing, concurrent time scales, or streams that can’t wait. Psyclone natively schedules components of wildly different latencies in a single runtime — sub-millisecond local control and interaction loops coexisting with deep-reasoning model calls — which is precisely what request-response chains cannot do. For the business-level version of this argument, see Sub-millisecond AI.
Distributed by design: laptop to server farm
Distribution is not bolted on. Psyclone is natively multi-node: modules communicate over TCP/UDP whether they share a process, a machine, or a rack, and the publish-subscribe model means a module neither knows nor cares where its peers physically run. A system developed on a single laptop scales out to a mixed Windows/Linux cluster by redeploying modules — not by rewriting the architecture. Because senders and receivers are decoupled through Whiteboards, moving a compute-heavy module (a vision model, a local LLM) onto dedicated hardware is a deployment decision, not a refactor. Modules and even whole nodes can join or leave a running system at will, which also means capacity can be added live.
Integration surface: C++ core, Python-native modules
The core is C++ for a reason — deterministic performance without garbage-collection pauses — but the integration surface is deliberately broader. Psyclone 2.0 added native Python support: modules can be written entirely in Python, either inline or as separate processes, running alongside native C++ modules in the same mixed-cluster system. That combination was exercised hard in the CoCoMaps project, which ran dozens of concurrent modules in mixed C++ and Python — including integration with ROS (Robot Operating System) via Python. Java modules are supported through the same common message protocol, and the Plug mechanism keeps the door open to other languages. For operations, PsyProbe provides web-based monitoring: inspect and control a running system live, without taking it down.
Reliability engineering: hardened, not just tested
A real-time platform earns trust through its failure modes, and this is where Psyclone’s recent engineering effort has gone. A dedicated stability-hardening pass across the core engine eliminated race conditions, fixed memory-safety issues, and closed a shared-memory corruption bug — the class of defects that in a concurrent C++ system produce rare, unreproducible, catastrophic failures. Alongside the fixes, the automated test suite was expanded with stall detection, so a component that silently stops making progress is caught by the tests rather than discovered in production.
For systems that can’t afford downtime — industrial control, live voice interaction, commercial deployments with uptime expectations — this is a genuine differentiator, not a changelog footnote. Orchestration frameworks that assume a stateless request-response world can crash and retry; a runtime coordinating kilohertz loops cannot. Deterministic behaviour under load, and failure modes that are detected rather than discovered, is the standard the platform is engineered to. The same architecture has already carried live demonstrations and paying deployments — see Proven in the Field.
From live reconfiguration to self-programming
Psyclone’s architecture already lets modules and whole nodes join or leave a running system at will — proven in earlier Psyclone versions. That proven capability is the foundation for an LLM Supervisor designed to author, load, test, and refine its own modules: because the runtime treats modules as hot-swappable participants on a message bus rather than compiled-in components, a supervising model could generate a new module, load it into the live system, evaluate its behaviour, and iterate without stopping anything. The live hot-join and reconfiguration this builds on is proven in earlier Psyclone versions; the full self-programming loop is an active research direction rather than a shipped capability.
Going deeper
The full Psyclone Platform System documentation (87 pages) covers the message model, module API, and deployment in detail, and Psyclone Platform use cases show the architecture applied. For evaluation and deployment terms — open-source LGPL/BSD releases with a commercial licence available — see Licensing.