The system
Each card is one part of the AIOS. Select a part to see its role, or trace a request from start to finish. The dashboard below is the User Interface in use.
Overview
About the system
How the AIOS works, in plain language
An AIOS (AI operating system) is the layer that lets several AI agents do real work for a firm in an orderly, controlled way. It does for AI agents what a computer’s operating system does for programs: it schedules the work, shares memory and storage fairly, controls access, and keeps a record. The map and the dashboard above show one system from two sides: how the parts connect, and what your team actually sees.
What it is, and why a firm would want one
The idea
The design follows published research from Rutgers University on an LLM agent operating system (arXiv 2403.16971). In that design, agents run as applications, and a kernel provides the shared services they depend on: scheduling, model access, memory, storage, tools and access control.
This page adds the business-side parts a firm needs around that kernel: approval by a person, written policy, an audit trail, and the firm’s own software and records.
The problem it addresses
Without a shared layer, each agent talks to models and tools on its own. Common results:
- Agents compete for the same model and slow each other down.
- Each agent keeps its own memory, so knowledge is not shared.
- No one controls which agent can see or change what.
- There is no single record of what happened and who approved it.
An AIOS puts one set of services between the agents and everything they use.
Speed, in the research
The researchers report up to 2.1 times faster execution when agents were served through the kernel in their tests. These are laboratory benchmarks, not a promise for any firm.
Control
Permissions before actionEach agent has a defined role, and the system checks it before the agent opens a file or uses a tool.
Accountability
People approve, the system recordsA named reviewer signs off before work is released, and each step is written to an audit trail.
The four groups
The map shows every part as a card. Cards are grouped by what they do, and the same four groups appear as filters beside the map.
Kernel services
The shared coreA scheduler and six managers (LLM Core, Context, Memory, Storage, Tool and Access). Every request from an agent passes through here. Think of it as the office manager who decides what runs next, who may use what, and where things are kept.
Applications
Where work is asked forThe User Interface people use, the Orchestrator that plans a workflow, the Agent Applications that do the tasks, and the SDK agents use to reach the kernel. They ask for services. They never take resources directly.
Oversight
Who approves and what is recordedHuman Approval, Policy & Guardrails and the Audit Trail. These keep people in charge, set the limits, and leave a record that can be reviewed later.
Business resources
What the system connects toThe firm’s Knowledge Base, System of Record, Business Software and the Model Providers that supply the AI. The system connects to these. It does not replace them.
The components
Every card on the map, with its role and the parts it talks to. Filter by group, or select Show on map to find a part in the diagram above.
How the parts communicate
Parts do not call each other freely. Requests travel along defined paths, and each path has a purpose. These are the lines you see on the map.
| From | To | What is sent | Example |
|---|---|---|---|
| User Interface | Orchestrator | A request from a person | “Draft the September client report.” |
| Orchestrator | Agent Applications | A task assignment | “Write the summary section.” |
| Agent Applications | SDK, then Kernel | A system call, which is a standard request for a service | “Read the report template.” |
| Kernel scheduler | The managers | Queued calls, dispatched in order | A model request goes to the LLM Core queue. |
| Access Manager and Policy | Kernel, tools, stored data | Permission rules and checks | “This agent may read project files, not finance.” |
| Storage Manager | Knowledge Base | Retrieval of procedures and templates | Past reports are loaded as context. |
| Tool Manager | Business Software, System of Record | Tool calls that read or write within permission | Pull this month’s figures from accounting. |
| LLM Core | Model Providers | Prompts and responses | Assembled material goes in, a draft comes back. |
| Memory and Context Managers | Storage Manager | Working state and snapshots | A paused job is saved and resumed later. |
| Orchestrator | Human Approval, then User Interface | A review request, then the released result | A named reviewer signs off, then the report appears. |
| Kernel | Audit Trail | Event records | Each call and approval is logged with a time. |
Six ground rules
- Everything goes through the kernel.Agents send requests to the kernel through the SDK. They cannot open a model, a file or a tool on their own.
- The scheduler queues and dispatches.Each call joins a queue for the right manager. The research describes first-in-first-out and time-sliced (round robin) scheduling, so no single agent takes over a shared resource.
- Permissions are checked before action.The Access Manager places each agent in a privilege group and blocks access outside it. Irreversible actions, such as deleting or overwriting, require a person to confirm.
- Tools and data are reached through managers only.Software goes through the Tool Manager and stored knowledge through the Storage Manager. Results come back the same way.
- Work can pause and resume.The Context Manager saves a snapshot of a job in progress. The Memory Manager keeps working memory and moves older items to storage.
- People approve, and the system records.The Orchestrator sends finished drafts to a named reviewer. The kernel writes events to the Audit Trail.
Life of a request
One example, from start to finish: a staff member asks for the monthly client report. The same steps run in the map’s Trace a request walkthrough.
What it does and does not do
What it does
- Runs many agents at once without one blocking the others.
- Limits each agent to the data and tools its role allows.
- Keeps a person in the loop before anything is released.
- Records requests, calls and approvals so work can be traced.
- Connects to software and records the firm already uses.
- Lets cloud or locally hosted models be swapped without changing the agents.
What it does not do
- It does not replace your systems of record. It reads and writes them within permission.
- It does not guarantee an outcome. Drafts are reviewed by a person before release.
- It does not decide the rules. The firm sets policy, roles and approval requirements.
- It does not make legal, tax or compliance determinations. Those stay with qualified professionals.
- It is not one fixed product. Every real build differs by firm, software and risk tolerance.
Common questions
Does it replace my team?
No. Agents prepare drafts and handle routine steps. Named people review, approve and decide. The dashboard is where they do that.
Can an agent act without approval?
Only where the firm’s policy allows it. In the model shown here, anything released outside the firm and any irreversible action waits for a person.
Which AI models does it use?
The LLM Core treats each model like a processor core, so cloud or locally hosted models can be swapped without changing the agents. Which models a firm uses is a design decision made for each build.
What if two agents need the same tool at once?
The scheduler queues the requests, and the Tool Manager checks each call and resolves conflicts, so agents do not collide over a shared tool.
Where does my data live?
The AIOS reads from and writes to your existing systems through approved connections. Where any copies are stored, and how they are protected, are design decisions for each build and need review by a qualified IT, security or legal professional. This page does not make those determinations.
Is the dashboard above a live product?
No. It is a design preview that uses sample data, and its answers are simulated. It shows how the User Interface layer would look and behave.
About this page
The kernel services and SDK follow the published AIOS research architecture from Rutgers University (arXiv 2403.16971). The oversight and business-resource parts are SageLogic’s own grouping. The dashboard is a design preview with sample data, not a live product, and its answers are simulated. Components and tool categories are generic and are not specific products.
Every part of the system runs under the AI governance you approve in design. What AI governance means.
Want to see how a project runs, week by week? Read how a project runs.