> ## Documentation Index
> Fetch the complete documentation index at: https://qitor.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Why QitOS Keeps a Single Kernel

> Why examples, benchmarks, and production-style agents in QitOS all run on the same AgentModule + Engine kernel.

One of the strongest QitOS opinions is also one of the simplest:

**a run should have one execution kernel (the core AgentModule + Engine execution loop).**

In practice, that means:

* `AgentModule` defines policy
* `Engine` owns execution
* parsers, toolsets, critics (modules that evaluate each step and can trigger retries or stops), memory, and tracing attach to that runtime

We avoid introducing a hidden second loop for planning, benchmarking, or domain-specific workflows.

## Why this matters

When frameworks introduce multiple implicit runtimes, three things usually happen:

1. examples become hard to compare with production agents
2. benchmark logic drifts away from day-to-day agent logic
3. traces stop telling a coherent story

QitOS avoids all three.

If a benchmark run, a Claude Code-style agent, and a security audit agent all use the same kernel, then:

* traces remain comparable
* debugging techniques transfer
* prompt and parser experiments are easier to reason about
* long-running behavior stays inspectable instead of turning into framework glue

## Where specialization belongs

QitOS does support specialization, but specialization should live in the right places:

* state design
* prompt policy
* parser (a component that converts raw model output into a typed Decision) and protocol (the output format the model is asked to follow) choice
* tool composition
* `reduce()` (a function that folds the current observation and decision into the next state) semantics

This is why a domain-specific audit agent can still be an ordinary QitOS agent.

## What this means for users

If you're building on QitOS, the default question should not be:

> Do I need a second orchestrator?

It should usually be:

> Can I express this through state, prompt, parser, tools, history, or memory on top of the same kernel?

That constraint makes the system easier to learn, easier to test, and easier to reproduce.

## Continue reading

* [Introduction](/introduction)
* [Engine](/concepts/engine)
* [Tutorials](/tutorials)