# AgentRT ships a C agent runtime through seven submodules and a strict gate pipeline

> AgentRT is a C runtime for AI agents that positions itself against container orchestration, and what lands on GitHub is mostly its build, gate and publishing layer. The seven submodules that carry the actual runtime are pinned, mirrored and signed by that layer.

**openairymax/agentrt** — Airymax AgentRT Transcend context limits. Achieve near-infinite memory.

- Repository: https://github.com/openairymax/agentrt
- Website: https://atomgit.com/openairymax
- Stars: 1,247 · Forks: 108
- Language: C
- License: NOASSERTION
- Published: 2026-10-13 · Updated: 2026-10-13 · Language: en
- Canonical page: https://hysenlabs.com/projects/openairymax-agentrt

## The landing page documents the delivery layer, not the agent loop

AgentRT positions itself as an agent runtime platform, drawn next to Kubernetes in the way container orchestration sits next to containers. The topics on the repository read ai, assistant, non-langchain-wrapper, os and own-your-data, and the primary language is C. What a visitor finds first is not the runtime. The README rendered on the GitHub landing page is titled AgentRT `.github/` and declares its own scope as cross-platform build and test, static quality gates, sanitizer detection, contract codegen checks, the publishing pipeline, pre-publish verification on real hardware and mirror sync to a second hosting platform. For installing or using the software it redirects to the repository root README and the Simplified Chinese README, and for development it redirects to CONTRIBUTING.md and SECURITY.md. That ordering is worth knowing up front. The repository description promises a way to "transcend context limits", and the page you land on is an automation manual.

## Seven git submodules carry the runtime the aggregate repo does not

The aggregate repository is a shell around seven leaf repositories recorded as gitlinks through `.gitmodules`: atoms, commons, cupolas, daemons, gateway, heapstore and protocols. Those names map onto the delivered mechanisms, namely microkernel primitives, the cognitive loop, memory tiering, a security dome, IPC protocols, a gateway service and resident daemons. Beside them the top level carries `CMakeLists.txt`, a `cmake/` directory, `tests/`, `tools/`, `scripts/`, `link-whitelist.txt`, a `Doxyfile` and `.clang-format` with a matching ignore file. Because the leaf trees are pinned commits rather than copies, a plain clone gives you an empty skeleton. Every push and pull request runs the gate on Linux, macOS and Windows, so a contributor never has to own a Mac or a Windows box to get cross-platform feedback.

## Download page install starts with a hash check, not an installer

Each published version's download page carries the same asset set for every platform, and the naming convention is the first thing to read:

```bash
agentrt-<版本>-<平台>.tar.gz
manifest.stable.json
install.sh
```

Linux and macOS packages arrive as `.tar.gz`, Windows packages as `.zip`. Each package has a same-named `.sha256` file and a detached `.sig` file, and the manifest lists all assets of that version with its own detached signature in `.asc` form. The documented order is verification first. Put the checksum file beside the package in the same directory and run:

```bash
sha256sum -c <包名>.sha256
```

Only after that passes do you run `install.sh` or `install.ps1`, or unpack the archive. The packages are self-contained, so no extra development environment is needed on the target machine.

## Source builds start with submodule init and end at the root cmake

If you would rather compile than download, the clone step is not optional. The leaf repositories are pinned by gitlink, so the first command after cloning is:

```bash
git submodule update --init --recursive
```

The build entry point is the `cmake` at the repository root, and the full sequence sits in CONTRIBUTING.md rather than in the page you are reading. Cross compilation is handled by pinned toolchain images kept under `docker/`, built and pushed by the Toolchain Images workflow. That workflow runs on demand, or when the toolchain image definitions change on the main branch, and those images serve the qemu cross legs. A detail easy to skim past: the project names eight platforms for shipping artifacts, yet also carries a RISC-V leg that runs only on manual trigger as a canary to expose cross-compilation problems early. That leg never enters the shipping matrix.

## Fail-closed gates decide whether a version tag becomes anything

Quality Gates runs on pushes to main, on pull requests and manually, and it is fail-closed. Its checks are not only linting: they include coding rules, a security scan, version consistency, header file health and an ABI freeze check. Sanitizers builds a subset of core targets with ASan and UBSan instrumentation and runs the tests, also fail-closed. Codegen Checks verifies that the syscall contract in `atoms/syscall/include/syscall.xml` has not drifted from the generated code. Gate and publishing share one build and packaging implementation, which the project states explicitly is meant to stop the two paths from drifting apart. For a consumer, the ABI freeze and version consistency checks matter most: together they mean a pinned submodule commit is meant to be a stable target rather than a moving edge.

## Signing happens once, and the latest pointer moves last

Publishing runs when a tag matching v* is pushed or a maintainer triggers it, and it is designed to be re-runnable. The pipeline builds all platforms in parallel, packs self-contained bundles, then installs offline in a clean Linux container or macOS host following the ordinary user path, starts the full daemon group and runs end-to-end smoke coverage across upgrade and rollback paths. Only then does publishing proceed in three idempotent stages. finalize-dist signs the directory once with cosign artifact signing plus a manifest and a GPG asc signature, producing one canonical signature set shared by all three hosting fronts, and it never re-signs. publish-mirror puts GitHub on a fast channel visible within minutes while Gitee is mirrored by a separate background job that cannot block. publish-atomgit uses a slow channel and commits the `latest/` pointer only after the upload finishes, so an installer or updater never points at an artifact that is not ready. AtomGit is the authority for assets and manifests, and GitHub and Gitee are byte-identical download mirrors. Tags are only cut when a version actually ships, and the three most recent ones carry 2026-09-13, 2026-09-14 and 2026-09-17 dates, which is the cadence a mirror host and an updater pointer have to keep up with.

## The macOS real-machine check runs only when a human asks for it

The formal shipping outlet for macOS is a clean-host verification: on a fresh macOS machine, as an ordinary user, offline, install the package and start the daemon group, on both arm-64 and x86-64 legs. Its purpose is to confirm the installer does not quietly depend on private state of the build machine. Here is the gap between the claim and the configuration. Build and Test, Quality Gates, Sanitizers, Codegen and the tag-triggered pipeline all fire automatically, yet macOS Clean-Host is manual trigger only, and so are Toolchain Images and the historical artifact backfill. Nothing in the documented configuration makes a tag wait for that macOS leg. Mirror Sync is the other asymmetric job, distributing main-branch and tag sources of the aggregate repo and its leaf submodules in one direction to the mirror host, driven by pushes, a hosting platform webhook or a manual run.

## GitHub calls the terms Other, the source header names two options

The permission field on the repository reads Other, described as a custom licence GitHub cannot classify, and the source disagrees with it in a useful way, because the SPDX header in the automation page declares `AGPL-3.0-or-later OR Apache-2.0` and points at the root LICENSE file, with NOTICE, an ACKNOWLEDGMENTS.md and a `LICENSES/` directory listed beside them, all under Copyright (c) 2025-2026 SPHARX Ltd. Picking one side of a dual option over the other decides what obligations you inherit for code you link or serve, and that is a selection decision rather than legal advice, so it belongs in the repository files rather than in a badge. Contributors face a narrower question. Every pull request must pass the same gates before merge, commit messages are asked to stay short with one logical change per request, and security reports go through the private channel in SECURITY.md rather than a public issue. The last push was on 2026-09-20, so the pipeline described above is recent rather than abandoned.

## Conclusion

Adopt AgentRT if you want an agent runtime whose build, packaging and signing are enforced by machine rather than by hand, and you can live with a C codebase split across seven submodules. Do not adopt it if you expected the memory layer itself on the GitHub landing page, because the runtime primitives live in leaf repositories you must initialise first. Before you vendor anything, read the SPDX header in the repository root rather than the badge GitHub shows, and check the macOS clean-host workflow, since that verification only runs when a person triggers it.

## FAQ

### How many platforms does AgentRT ship binaries for?

Eight: Linux x86-64, x86-32, arm-64 and arm-32, macOS arm-64 and x86-64, and Windows x86-64 and x86-32. A RISC-V leg exists as a manually triggered canary for catching cross-compilation problems early, and it is kept out of the shipping matrix.

### Do I need a development environment to install AgentRT from the download page?

No. The packages are self-contained and need no extra development environment, and you are expected to run `sha256sum -c <包名>.sha256` before `install.sh` or `install.ps1`. Building from source is different: you must run `git submodule update --init --recursive` first because the leaf repositories are pinned gitlinks, then use the `cmake` at the repository root.

### What licence is AgentRT under?

The SPDX header declares `AGPL-3.0-or-later OR Apache-2.0`, a dual choice, with details in the root LICENSE file and NOTICE under Copyright (c) 2025-2026 SPHARX Ltd. The permission field GitHub shows reads Other, so the files in the repository are the place to check which option applies to your use.

### What does the Codegen Checks workflow actually verify?

It checks that the syscall contract in `atoms/syscall/include/syscall.xml` has not drifted from the generated code. It runs on every push and pull request as well as manually, alongside the fail-closed static quality gates and the ASan and UBSan runs.

### Is RISC-V part of the official AgentRT release matrix?

No. RISC-V is a manual-trigger canary leg used to surface cross-compilation problems early, and the shipping matrix covers Linux x86-64, x86-32, arm-64 and arm-32, macOS arm-64 and x86-64, and Windows x86-64 and x86-32. Cross builds for the canary rely on pinned toolchain images kept under `docker/`.

## Sources

- [Issues](https://github.com/openairymax/agentrt/issues)
- [openairymax/agentrt on GitHub](https://github.com/openairymax/agentrt)
- [Project website](https://atomgit.com/openairymax)
- [README](https://github.com/openairymax/agentrt/blob/main/README.md)
- [Releases](https://github.com/openairymax/agentrt/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openairymax-agentrt