> For the complete documentation index, see [llms.txt](https://docs.zenml.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zenml.io/kitaru/core-concepts/concepts.md).

# Overview

Kitaru's object model is small. Every piece exists to serve one loop: **record → replay → improve**.

* Your production agent leaves [**sessions**](/kitaru/core-concepts/agents-and-sessions.md), recordings of every model call, tool call, and decision, either recorded live by an [adapter](/kitaru/adapters/adapters.md) or [imported](/kitaru/import-your-traces/import-your-traces.md) from the traces you already collect.
* [**Investigations**](/kitaru/core-concepts/investigations.md) are where your judgment enters. Your coding assistant maps the sessions, builds a review worklist, interviews you against the evidence, and pins your answers as **annotations** on exact trace locations. They are the ground truth evaluators are calibrated against and cohorts are justified by.
* [**Replay**](/kitaru/core-concepts/replay.md) re-executes a session against your real code. Unchanged, it reproduces the original and gives you the faithful baseline. Forked with one thing different, such as a model, prompt, or code change, it answers a counterfactual you can trust.
* [**Evaluators**](/kitaru/core-concepts/evaluators.md) evaluate sessions and write evaluations, which are typed, versioned verdicts. Human labels land in the same table.
* [**Cohorts**](/kitaru/core-concepts/cohorts.md) freeze a population of sessions into immutable versions, so results stay comparable.
* [**Experiments**](/kitaru/core-concepts/experiments.md) replay a cohort against a change and evaluate both sides, showing what improved and what regressed before you ship.
* [**Workers**](/kitaru/core-concepts/workers.md) execute all of it in your environment. The server coordinates; your infrastructure runs the code and holds the data.

The short version: traces tell you what happened; Kitaru re-runs it. A trace you can only read is a transcript. A session is a recording your test bench can execute, which is what turns production's past into your test suite.

## How the pieces reference each other

An **agent** is the identity everything attaches to; an **agent version** pins the code, as a run spec a worker can execute. A **session** belongs to an agent and optionally a version. A **cohort version** pins session ids. An **experiment** pins the change: override, tool policy, and evaluators. An **experiment run** pins a cohort version and an agent version, then fans out one **replay** per session. Every replay produces a new session, and **evaluations** land on sessions from either side, which is why comparing a baseline to a fork means reading two sets of rows.

Nothing is recomputed behind your back, and nothing is mutable where it matters. Cohort versions, agent versions, and evaluator versions are frozen at creation, so any number you read can be traced to the code, population, and criteria that produced it.

## Where to start

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Agents &#x26; Sessions</strong></td><td>The identity and the recording.</td><td><a href="/pages/HxcE6J2lKzl3hFUJebqn">/pages/HxcE6J2lKzl3hFUJebqn</a></td></tr><tr><td><strong>Investigations &#x26; Annotations</strong></td><td>The interview: your judgment, pinned to exact evidence.</td><td><a href="/pages/lQJsrF7YukdI9mexUMBN">/pages/lQJsrF7YukdI9mexUMBN</a></td></tr><tr><td><strong>Replay</strong></td><td>Baselines, forks, overrides, and tool policies.</td><td><a href="/pages/q8ejBRbyMBEUPEy2CDmB">/pages/q8ejBRbyMBEUPEy2CDmB</a></td></tr><tr><td><strong>Evaluators &#x26; Evaluations</strong></td><td>Evaluating sessions, human labels, calibration.</td><td><a href="/pages/Z1S2gF2qHRPaojtqKgPx">/pages/Z1S2gF2qHRPaojtqKgPx</a></td></tr><tr><td><strong>Cohorts</strong></td><td>Immutable populations for comparable results.</td><td><a href="/pages/NpZ14Rqa7IcqlrO1wwDh">/pages/NpZ14Rqa7IcqlrO1wwDh</a></td></tr><tr><td><strong>Experiments</strong></td><td>A change, replayed and evaluated at population scale.</td><td><a href="/pages/bJu6Tc6vNBJti75P23Eg">/pages/bJu6Tc6vNBJti75P23Eg</a></td></tr><tr><td><strong>Workers</strong></td><td>Execution in your environment.</td><td><a href="/pages/2uchH0kpn87pgDAO1ol0">/pages/2uchH0kpn87pgDAO1ol0</a></td></tr><tr><td><strong>Under the Hood</strong></td><td>Server, workers, tasks, and blobs: the machinery.</td><td><a href="/pages/kghgTz6zjyaZAOR6CYOw">/pages/kghgTz6zjyaZAOR6CYOw</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.zenml.io/kitaru/core-concepts/concepts.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.