AgentRT — AI Agent Runtime Platform Engineering

An OS-grade runtime substrate for AI agent teams — the layer that standardises how agents think, act, remember, and talk to each other, in the same way a container runtime standardises how services are packaged and scheduled.

Language: English | 简体中文

Overview

AgentRT (full name AirymaxAgentRT) is the runtime layer of the Airymax platform. It provides the mechanisms an agent team needs in order to run for a long time on real hardware:

• a micro-kernel core with scheduling, syscalls and memory primitives,
• a three-stage cognitive loop (cognition → execution → memory),
• layered session and cross-session memory,
• a four-layer security dome that fails closed by default,
• an IPC and agent-to-agent protocol stack,
• a single gateway process that speaks HTTP / WebSocket / SSE / MCP / A2A / OpenAI and translates to JSON-RPC 2.0,
• a fleet of long-running daemons that orchestrate all of the above,
• a command-line interface and a terminal UI for interactive use.

Everything is written in C11 with language bindings for Python, Go, Rust and TypeScript. The runtime is designed so that a single laptop and a multi-agent deployment use exactly the same programming model.

This repository is the release aggregate for the runtime. The individual components are maintained in their own repositories and are wired in as git submodules, pinned to the exact commit that shipped with each release, so that any published version can be reproduced commit for commit.

Installation

Linux and macOS

One command, no compilation required. The installer detects the platform, downloads the matching prebuilt package, and verifies it:

curl -fsSL https://atomgit.com/openairymax/agentrt/releases/download/latest/install.sh | bash

The script is shipped with each release. When the downloaded script is saved to a file and executed from disk, the installer self-updates to the newest version.

Note: pipe into bash, not sh — sh (dash) does not forward positional arguments, so --prefix, --channel and similar flags would be silently dropped.

Windows

A native PowerShell installer is published for x86-64 and x86-32:

irm https://atomgit.com/openairymax/agentrt/releases/download/latest/install.ps1 | iex

npm

A thin wrapper package is published for Node.js users:

npm install -g @openairymax/agentrt

The package carries no install logic of its own: it locates an existing install first, and otherwise delegates to the same install.sh / install.ps1 release assets above (Windows hand-off uses PowerShell).

Options

Append flags after | bash -s -- (or pass them directly when running the script from a file):

# Custom install prefix (default: $HOME/.airymaxrt); first bootstrap only
... | bash -s -- --prefix "$HOME/.airymaxrt"

# Install from a release candidate instead of the stable channel
... | bash -s -- --channel rc

# Force a clean reinstall (clears the download cache, stops running daemons)
... | bash -s -- --reinstall

# Uninstall; add --keep-data to retain your memory data
... | bash -s -- --uninstall

--prefix is meaningful only for the first bootstrap install: at that point there is no install root to infer from, so you must supply it. Once the root is on disk (recorded in /config/install.env), the launcher resolves it on its own, so airymaxrt update, airymaxrt uninstall and --reinstall all act on the installation they belong to — they neither need nor should carry --prefix.

airymaxrt update            # updates the custom-path install in place
airymaxrt update --check    # check only, change nothing

Note: re-running curl … | bash after you are already installed is a fresh install, not an update — without --prefix it falls back to the default $HOME/.airymaxrt and leaves you with a second copy. To update an existing install, use airymaxrt update. If several copies are present on one machine, which airymaxrt shows which one your shell resolves.

Supported platforms

Packages are .tar.gz on Linux and macOS, .zip on Windows. Architectures not listed above are not part of the prebuilt matrix; build them from source.

First run

Start the runtime and its services by launching the terminal UI:

airymaxrt                 # terminal UI (falls back to the CLI on a dumb terminal)
airymaxrt cli             # force the plain command-line front end
airymaxrt status          # what is running right now
airymaxrt doctor          # component health check
airymaxrt logs 100        # last 100 lines of the runtime log
airymaxrt logs llm_d      # the log of one particular daemon

airymaxrt profile reports or overrides the hardware-derived runtime profile (full, minimal or auto). The installer picks the profile for you, and airymaxrt monitor --daemon keeps watching: if you add RAM or a GPU later, the features that were trimmed are restored automatically. On Windows the same commands are available through airymaxrt.

Core capabilities

Architecture

AgentRT is layered, and each layer depends only on the layers beneath it. The SDK layer binds back to the support layer at the top of the stack, which is why the dependency graph is drawn as a cycle.

SDK Layer        — CLI, terminal UI, Python / Go / Rust / TypeScript bindings
Service Layer    — 14 daemons that orchestrate the runtime        (daemons/)
Protocol Layer   — AgentsIPC and the A2A / A2T stacks             (protocols/)
Gateway Layer    — transports → JSON-RPC 2.0                      (gateway/)
Storage Layer    — heap-backed runtime persistence                (heapstore/)
Security Layer   — four-layer dome, policy decision and    (cupolas product)
                   enforcement points
Kernel Layer     — 5 atomic micro-kernel modules                  (atoms/)
Support Layer    — 32 cohesive utility modules + shared headers   (commons/)

• Support layer (commons) — the foundation every other layer builds on: logging, synchronisation, memory helpers, string handling, IPC helpers, configuration, observability, plus the authoritative type and error contracts.
• Kernel layer (atoms) — five atomic modules: corekern (init, lifecycle), coreloopthree (cognition → execution → memory loop), syscall (unified user/kernel-facing interface), taskflow (task graph and scheduling), memory (memory primitives and backends).
• Security layer (cupolas) — a policy decision point loads, distributes and rolls back policies; every daemon applies them locally through its own enforcement points, within seconds.
• Storage layer (heapstore) — persistence for runtime state, agent memory and transient data.
• Gateway layer (gateway) — protocol translation only, no business logic. It is the sole process boundary into the runtime.
• Protocol layer (protocols) — AgentsIPC with a fixed 128-byte message header for in-process and cross-process messaging, plus agent-to-agent (A2A) and agent-to-tool (A2T) stacks.
• Service layer (daemons) — the fourteen long-running processes that make the runtime an actual running system; the cupolas product ships its own cupolas_d policy shell on top (0.1.19 §255).
• SDK layer — lives in the sibling sdk/ tree and re-exports the layers below to application developers.

Repository layout

agentrt/
├── atoms/                # micro-kernel primitives (submodule)
├── commons/              # shared foundation library (submodule)
├── gateway/              # protocol gateway (submodule)
├── heapstore/            # heap-backed persistence (submodule)
├── protocols/            # AgentsIPC, A2A / A2T (submodule)
├── daemons/              # 14 runtime daemons + daemon framework (submodule)
├── cmake/                # build-system modules
├── scripts/              # installers: install.sh, install.ps1
├── tests/                # smoke tests and toolchain self-tests
├── tools/                # developer tooling (airy_cli, codegen)
├── latest/               # rolling release manifests and signing keys
├── LICENSES/             # additional license texts
├── CMakeLists.txt        # top-level build entry point
├── VERSION               # version this tree was released at
└── Doxyfile              # API documentation configuration

dist/ is a local build-and-package staging directory. It is not part of the repository.

Components

Each component is developed in its own repository. Clone this repository recursively to get all of them at the pinned revisions.

Building from source

Prerequisites

On Windows, dependencies are most easily obtained through vcpkg: sqlite3 cjson libyaml curl openssl zlib libmicrohttpd libwebsockets libevent nghttp2.

Steps

# 1. Clone with all components
git clone --recursive https://atomgit.com/openairymax/agentrt.git
cd agentrt

# 2. Configure — the build directory must live outside the source tree
cmake -S . -B ../agentrt-build -DCMAKE_BUILD_TYPE=Release

# 3. Build
cmake --build ../agentrt-build --parallel "$(nproc)"

# 4. Test
cd ../agentrt-build && ctest --output-on-failure

In-source builds are rejected: CMake raises a FATAL_ERROR if the build directory is inside the source tree.

On Windows, add -DBUILD_DAEMON=ON -DBUILD_CLI=ON to the configure step if you want the daemon fleet and the CLI; see the next section for why they are off by default there.

Key CMake options

Released packages are built with sanitizers off. Turning ENABLE_SANITIZERS on is a debugging aid, not a deployment setting.

Releases and channels

• Stable is the default channel and the one the installer uses.
• rc carries release candidates for preview; interfaces may still change.
• beta is occasionally opened for targeted testing.

airymaxrt update              # move to the newest build on your channel
airymaxrt update --check      # report without changing anything
airymaxrt update --channel rc # switch channel
airymaxrt update --rollback   # return to the previously installed version

Each version ships with a GPG-signed manifest in latest/, which is what the updater reads. CHANGELOG.md records the release history.

The current release is v0.1.18. Highlights:

• The scheduler policy engine was rebuilt as a table-driven design, dropping more than 1,400 lines of stale policy branches; the scheduling path is now shorter and its behaviour easier to reason about.
• The model-service daemon (llm_d) completed its service-face template conversion: its service surface now matches every other daemon, so upgrades behave more predictably.
• Five chunks of consumer-less legacy code were removed (old scheduler policy, a leftover monitoring branch, a general-purpose cache compatibility layer, a tool-service adapter bridge and an orphaned test file), leaving the install package and runtime leaner.
• Four new automated release gates (module-size ceiling, link closure, header shadowing and propagation dead-signal) now block regressions before a release ships.
• Daemons no longer link service libraries implicitly; every cross-service call goes through the system bus, lowering coupling risk on upgrade.

Documentation

Design documents, interface references and the application-development guide live in the Airymax documentation repository, under AirymaxRT/. Start with AirymaxRT/README.md for the full navigation, AirymaxRT/140-application-development/01-getting-started.md for a five-minute first run, and AirymaxRT/30-interfaces/ for the API references.

Contributing

Read CONTRIBUTING.md for the development workflow and coding conventions. Run the test suite locally before opening a pull request; CI enforces the same quality gates.

• Report bugs or request features:
• Security vulnerabilities: see SECURITY.md. Please do not file a public issue for anything exploitable.
• Support and questions: SUPPORT.md

License

Dual-licensed under AGPL-3.0-or-later OR Apache-2.0. You may choose either licence; you are not obliged to comply with both, and you may not comply with neither. Full text in LICENSE.

The commercial memory provider under products/memoryrovol in the umbrella project is distributed separately under a SPHARX Ltd. end-user licence and is not covered by the dual licence above.

Copyright (c) 2025-2026 SPHARX Ltd. All Rights Reserved.