Concepts

AI agents and business reinforce each other: agents take over routine work and operate without breaks, while business gives them purpose, data, and boundaries. The transition to agents is not a one-off experiment but an inevitable transformation: models are getting cheaper, and automating typical work is becoming more profitable than keeping people for it.

Agent OS is a platform for this transformation. It turns AI from an "assistant that responds" into an "employee that acts": dozens of agents run on a single core — support, sales, HR, analytics — under the control of budget, quality, and security.

The article is written "from general to specific" and is marked by audience:

• 🟢 — for everyone (including business and beginners);
• 🔵 — for those who build agents and operate the platform;
• ⚫ — for those who write/modify the core itself.

Levels and types of agents

Adoption proceeds by levels — from simple to autonomous:

1. FAQ bot — answers from a knowledge base: search and ready-made answers.
2. Assistant — understands and reasons, works with live data through tools.
3. Agent — sets a goal, uses tools, and drives to a result: not "find the price" but "compare options and suggest the best one."
4. Autonomous agent — launches itself (triggers) and reaches out when something happens.

We distinguish four types of business agents — by whom they work with and who launches them. One set of primitives — processes, tools, triggers, IPC — combines into different roles:

Outward-facing agents — work with clients and the outside world: support, sales, consultations, first contact. They live in channels (a website widget, Telegram), and tools give them access to live data — catalogs, prices, stock, schedules. Examples from the demo: university support (ngu), car selection (drom), airline tickets (aviasales), books (chitai-gorod, labirint).

Inward-facing agents — handle internal processes: HR, documents, back office, onboarding. Instead of poring over regulations, an employee asks the agent — it searches the knowledge base and answers with references. Mechanisms: search and reading the archive (site_tool / archive_tool / pdf_tool), memory (memory), escalation to a live employee (escalate).

Observer agents — monitor data and reach out on their own when something changes. They don't wait for a question but are launched by triggers: cron (on a schedule) or monitor (when something new appears). Examples: the rss agent monitors news feeds, zakupki tracks new procurements, the result goes to Telegram / email / another agent.

Controller agents — react to events and manage other agents. Through IPC they launch child agents (subagents), through workflow they assemble multi-step pipelines with conditions and retries, through escalate they hand off complex cases to a human.

1.1 Why this is needed — what problems it solves

🟢 While there's only one agent, a script around a single model is enough: tokens aren't counted, isolation isn't needed, an error can be "restarted and forgotten." Problems begin when there are many agents and they work for the business. Then arises what a "personal agent" doesn't have:

Agent OS solves four problems that are inevitable as the number of agents grows:

1. Efficient use of resources. Agents share the platform's common resources — the language model (LLM), compute power, and storage; the core decides who runs and when.
2. Budget management. Token limits per turn / minute / lifetime — one agent won't "burn through" the entire budget.
3. Observability. Every step is logged: you can see what the agent did and why.
4. Security and isolation. An agent doesn't read someone else's context and doesn't spend someone else's budget.

1.2 What Agent OS is

🟢 In one phrase:

Agent OS is a kernel for AI agents. Just as an operating system manages ordinary program-processes, Agent OS manages AI agents.

Agent OS doesn't do inference itself. It relates to the language model (LLM) just as an operating system relates to a processor:

• The LLM is the "CPU." Agent OS doesn't compute answers — it schedules computations on an external provider (DeepSeek, any OpenAI-compatible API, Ollama).
• Agent OS is the "kernel." It decides which of the agents will now get access to the model, how many tokens it will spend, and with which tools.

From this come three key ideas that distinguish Agent OS from a "regular agent" (a script wrapped around a single model):

1. An agent = a process. Each agent is an independent process with its own PID, instructions, context (working memory), set of tools, and token budget.
2. The kernel = order. Agents share a common LLM — the kernel schedules them, limits them, and isolates them from each other.
3. Everything is controllable. Every step (tool call, tokens spent, state) is logged and subject to limits.

1.3 The operating system metaphor

🟢 The whole construction is an analogy to a regular OS kernel. It is the "intuition" for everything else:

If you keep this table in mind, everything that follows reads "by itself."

1.4 Core concepts

🔵 The concepts fall into two groups: the kernel (the basic building blocks of the model — without them you can't understand how anything works) and services on top of the kernel (optional, loaded at startup).

4.1 Kernel — basic building blocks

Let's go through each one.

Template → process → session. Three levels of the same thing:

• Template — a reusable agent recipe: name, instructions, tools, hooks, budget. Lives in config/agents/<name>/agent.yaml.
• Process — a running instance of the template with its own PID, context, and budget bucket.
• Session — a user conversation bound to a process (session_id, user_id).

Agents are not created in advance at startup: the first request to a template creates a process "on the fly" (lazy spawn). Templates are visible in GET /v1/templates, running processes — in GET /v1/agents.

Context (working memory). Limited message history (like RAM). When the max_context_tokens limit is exceeded, the eviction policy kicks in:

• fifo — delete the oldest;
• summary_first — collapse the old ones into a brief summary (default);
• sliding_window — keep only the last N.

Scheduler. A single scheduler decides which ready process runs next. Today it is round_robin with a concurrency limit (kernel.concurrency_limit) — a ceiling on the number of agents simultaneously streaming tokens. When the ceiling is reached, processes wait until one "yields" or blocks.

Budget (token bucket). Each process spends tokens from a bucket:

• refill_per_sec — how many tokens are added per second;
• max_bucket — bucket capacity (how much accumulates while idle);
• max_total — a hard limit for the entire lifetime of the process (after which — death).

Budgets are combined into groups (like cgroups per process tree). Before each turn the kernel checks in order: group → per-user → per-session. If even one layer is exhausted, the turn is rejected, and the user sees the text from the budget_messages.* agent.

Tools. The only way for an agent to interact with the world: network, files, sites, documents. The kernel mediates every call — it checks access, logs, and counts the cost. By configuration level, tools range from built-in (connected simply by name) to declarative (described by configuration) and scripted (custom logic, when the ready-made ones aren't enough).

Hooks. They intercept the agent lifecycle at many points (the full list is in 06-hooks-reference): from a user message and a tool call from tool to inference, token streaming, context compaction, and completion. They can transform, reject/force a rewrite (rework), suppress, or respond themselves without the LLM.

Built-in kinds: faq_cache, inject, escalate, memory, rag, tool_cache, link_check, condense, compact_results, format_guard, loop_guard, guard, pseudonymize, groundedness, circuit_breaker, script_hook.

IPC. Agents communicate via system calls: send/recv (point-to-point), spawn (create a new process), fork (clone itself with inheritance of the budget group), kill, yield.

4.2 Services on top of the kernel

These subsystems are optional and are connected at startup. If one is missing, the corresponding calls respond "not configured," and everything else continues to work.

Triggers — what launches an agent without a human. This is the key difference of the platform: an agent can work fully autonomously. Three mechanisms:

For all triggers, the result goes to a sink: log / webhook / telegram / vk / yandex_messenger / messages_db / email / another agent.

Channels — how agents are communicated with. Unlike triggers (who launched it), a channel answers the question "through what":

• HTTP API (SSE chat) — the primary programmatic interface;
• embeddable web widget — a "Chat with AI" button on a website;
• Telegram, email, webhook — external systems.

A webhook acts as both a channel and a trigger — which is why the two concepts are separated.

Orchestration (workflow). A declarative pipeline (DAG) of agents and tools: steps agent / tool / condition / for_each, with retries, timeouts, and per-step budgets. A workflow has its own triggers (cron/webhook), but a workflow itself is orchestration, not a trigger.

Memory and storage.

• logs/process-<pid>.jsonl — a line-by-line JSONL trace of the process;
• logs/events.db — DuckDB event store (feeds the trace_* tools);
• logs/messages.db — a shared transcript log + FAQ cache + full-text search;
• logs/state.db — state store: scoped key-value (session / user / agent / team);
• logs/teams.db — command registry (membership + grants), if enabled;
• checkpoints — state snapshots for recovery after a failure.

Subagents. A tool or hook can delegate a task to a child agent process and read its final response — for example, subagent_tool.

1.5 Key architectural decisions

⚫ Several decisions that define the character of the platform:

• Rust. The entire kernel is a single statically compiled binary: no runtime and no external dependencies, deployment amounts to copying a file, and safe concurrency keeps dozens of agents running without data races.
• A single async runtime (Tokio). The kernel is the only event loop that schedules all processes; a separate thread is not spun up for each agent.
• Process model. An agent and a workflow are processes in a single registry, with spawn/fork semantics and a process tree.
• Provider abstraction. The kernel does not perform inference but schedules it on a pluggable provider (OpenAI-compatible, DeepSeek, Ollama) — independence from model and vendor.
• Kernel-mediated I/O. Agents never call tools directly: every call is validated, rate-limited, and logged by the kernel.
• Cooperative multitasking. An agent "yields" after each round of inference; optionally — preemption by time quantum.
• Opt-in subsystems. State store, cron, workflow, and message store are connected at startup; if something is missing, the corresponding calls respond "not configured" rather than breaking the kernel.
• Modularity. The platform is assembled from modules — packaging units that contribute routes, tools, hooks, services, and config. The kernel is only the mechanism (processes, scheduler, budgets, LLM), while features (workflow, cron, channels, docs, widget) are modules connected as linked crates or native DLLs. The list of enabled modules is server.yaml → modules.enabled; details — 32-building-a-module.

1.6 System boundaries — what this is NOT

🟢 So as not to confuse Agent OS with neighboring things:

1.7 Where to go next