AIOS: An Operating System Layer for LLM Agents, Split Into Kernel and SDK

The problem AIOS targets is resource contention between agents, not agent authoring

Most agent frameworks answer the question of how to write an agent. AIOS answers a different question: what happens when several agents run at once and all want the same model, the same memory store and the same tools. The README lists the problems it is designed to address as scheduling, context switch, memory management, storage management, tool management and Agent SDK management. Those are operating system concerns, and the project names itself accordingly. The intended audience is therefore narrower than the agent framework audience. It is for people deploying LLM-based agents rather than people writing a single prompt loop. The README states the goal as a better AIOS-Agent ecosystem for agent developers and agent users, and it separates those two roles into two repositories. That separation is the design decision the rest of the project follows from, and it is also the first thing a prospective adopter has to accept.

Kernel and Cerebrum SDK: what lives in which repository

The system has two components. The AIOS kernel is this repository. The README describes it as an abstraction layer over the operating system kernel, managing the resources agents require: LLM, memory, storage and tool. The AIOS SDK lives in a separate repository named Cerebrum, and the README describes it as the component agent users and developers interact with to build and run agent applications against the kernel. The repository layout therefore matters at install time, not just at reading time. If you clone only agiresearch/AIOS you have the kernel and no agent-facing SDK. The README also notes that AIOS supports both a Web UI and a Terminal UI. The Terminal UI is not a cosmetic addition: the news entries record that the paper From Commands to Prompts: LLM-based Semantic File System for AIOS was accepted at ICLR 2025 and that its features were integrated into AIOS as the Terminal UI. So the terminal is the surface where that semantic file system work landed. The kernel also accepts agents built elsewhere. The README states that multiple agent creation frameworks are supported, listing ReAct, Reflexion, OpenAGI, AutoGen, Open Interpreter and MetaGPT, with onboarding guidelines in the documentation. That is an integration claim rather than a compatibility guarantee, and the documentation is where the actual per-framework requirements would sit.

Syscalls, scheduling and dispatch: the mechanism the README actually shows

The clearest description of the runtime data flow is in the architecture section. Agents use the SDK to talk to the kernel; the kernel receives agent queries and then uses a chain of syscalls that are scheduled and dispatched into the different modules. That is the whole mechanism in one sentence, and it is deliberately analogous to a conventional kernel: the agent does not call the LLM, memory or tool layer directly, it issues a request that the kernel turns into a sequence of syscalls. Scheduling and dispatch sit between the request and the module that executes it. This is what makes the project more than a wrapper library. A wrapper would let the agent call the model directly and add logging. Here the call path is mediated, which is what allows the kernel to make decisions about ordering and resource use across agents. The README does not publish the scheduling policy, the queueing model or any latency figures, so how the scheduler behaves under load is not something the supplied material answers. Treat the scheduling benefit as architectural intent rather than a measured property until you read the kernel source.

The computer-use variant replaces the Tool Manager with a VM Controller and MCP Server

For computer-use agents the architecture changes rather than simply scaling up. The README says the kernel keeps the LLM Core, Context Manager and Memory Manager, but the Tool Manager is fundamentally redesigned to include a VM Controller and an MCP Server. The stated purpose is a sandboxed environment where agents can interact with computer systems while maintaining a consistent semantic mapping between agent intentions and computer operations. Two things are worth pulling out. First, the sandbox is the safety boundary, so the VM Controller is not optional plumbing for this class of agent; it is the component that stands between an agent action and the host. Second, the MCP Server framing means computer operations are exposed to the agent through the Model Context Protocol rather than through bespoke tool definitions. The README points to a separate paper, LiteCUA: Computer as MCP Server for Computer-Use Agent on AIOS, and a separate codebase for that work. If computer use is your reason for looking at AIOS, the relevant code may be in the LiteCUA repository rather than in the kernel you cloned.

Getting it running, and what the README does not tell you

The README is thin on installation. It links to documentation at docs.aios.foundation, and that is where setup steps live; the repository text itself does not give a pip install line, a Docker command or a config file listing. What it does give is the shape of the setup. You need this repository for the kernel and the Cerebrum repository for the SDK, because agent applications run against the SDK and the SDK talks to the kernel. The README records that function calling is supported for open-sourced LLMs via native HuggingFace, vLLM and ollama, and that DeepSeek-r1 is supported across sizes from 1.5b to 671b, both open-sourced versions and the deepseek-chat and deepseek-reasoner APIs. Those are the model-side choices you will be configuring. External tool calling is also listed, with google search, wolframalpha and rapid API named. On the operations side the README mentions a remote kernel option for agent users, introduced alongside the v0.2 split. That is the deployment lever worth understanding early: a local kernel for development and a remote kernel for users is the arrangement the project appears to intend. Exact commands, environment variables and config keys are in the documentation site, not in the repository README, so plan to read both before you attempt a first run.

Where the abstraction costs you, and when a plain framework fits better

The kernel boundary is not free. Anything the kernel does not model has to be added to the kernel or worked around, and the syscall chain adds a layer between your agent code and the model call. For a single agent in a single process, that layer buys you little: you pay for scheduling and dispatch without contention to resolve. The README also makes the SDK a separate project with its own release cadence, which means version skew between kernel and SDK is a real operational concern, not a hypothetical one. There is a second limitation in the material itself. The licence is reported as NOASSERTION, meaning the repository metadata does not declare a standard licence identifier. For a project you intend to depend on, that is a question to resolve directly with the repository rather than infer. A third gap: the architecture figures carry most of the explanation, and the README text does not document failure behaviour, retry semantics or what happens when a tool call inside the VM sandbox fails. If your workflow depends on those paths, you will be reading source. Compare this with a framework like AutoGen, which the README lists as a supported agent creation framework rather than as a rival. That is the actual difference in approach: AutoGen gives you a conversation and orchestration model inside your process, while AIOS gives you a resource layer underneath it. They can be stacked, and the README's onboarding guidance implies exactly that. Choosing AIOS over AutoGen is not a choice between equivalents; it is a choice about whether you need the layer underneath.

Maintenance, releases and the licence question

The release history shows a long gap and then a jump. v0.2.1 landed in January 2025, v0.2.2 in March 2025, and v0.3.0 in January 2026. The README's news entries cluster around 2024 and 2025, with the most recent items being the COLM 2025 acceptance of the foundational paper and a July 2025 competition finalist placement. Between the v0.2.2 release and v0.3.0 there is roughly ten months with no tagged release, which is worth knowing if you pin versions: you may be running a tag that predates a year of main-branch work. The v0.2.2 release is described in the news as a major refactor of the codebase, which means upgrade paths across the 0.2 line are not guaranteed to be smooth. On licensing, the repository reports NOASSERTION and the README does not state licence terms. That is not a legal opinion and should not be read as one; it simply means the terms are not declared in the metadata you can see, so confirm them from the repository or the project before you depend on the code. The project also accepts sponsorship through a Rutgers Foundation link in the README, which is context for how it is funded, not a statement about governance.

Editorial conclusion

Adopt AIOS if you are building or hosting multiple LLM agents and want scheduling, memory and tool access behind a kernel interface rather than reimplemented in each agent. Do not adopt it if you need a single small agent embedded in an existing application, or if you need a settled licence before writing production code, since the repository reports NOASSERTION. Before committing, verify three things on your own checkout: that the Cerebrum SDK version you install matches the kernel version you run, which tools in the Tool Manager your workflow actually needs, and the licence terms of the specific release you pin.

Official sources

1. agiresearch/AIOS on GitHub
2. Issues
3. Project website
4. README
5. Releases