# What cairn is


cairn is continuity for agents. It is a durable task graph an agent plans into and resumes from: tasks joined by typed edges, freeform observations attached as the work happens, and handoffs that carry a session forward. An agent is sharp for the length of one session, and then the context resets. The plan, the half-finished step, the reason the last decision went the way it did — all of it lived in the conversation, so when the conversation ends, it is gone. cairn keeps that plan outside the conversation. After a reset, the agent reloads it from the graph instead of reconstructing it from a transcript.

## What "continuity" means here

Continuity is the property that work survives the boundary between sessions. Without it, an agent that loses its context redoes finished steps, or stalls to ask you where things stand. cairn gives the agent somewhere durable to put the plan, and a way to read it back.

The plan is a graph the agent queries, not a markdown file it re-reads top to bottom. A single `task_bootstrap` call returns the current task's state, its neighbors, its open handoffs, and recent observations. From there the agent asks the graph real questions — which phases are ready to start, what depends on a given task, what has gone stale — rather than scrolling old chat. The plan lives where a context reset cannot reach it, and the graph answers in the same terms the agent used to write it.

Three nouns carry the continuity. A **task** is a node, addressed by a date-prefixed slug like `2026-06-20-ship-the-thing`, holding status, description, edges, and metadata. An **observation** is the cheapest write — a freeform note appended to a task as the work happens, the heartbeat of a session. A **handoff** is a resumable summary written for whoever picks up next, its summary load-bearing. See [Tasks, observations, and handoffs](/cairn/concepts/tasks-observations-handoffs) for how each one behaves.

## Why a cairn

A cairn is a pile of stones raised to mark a route across ground that holds no path of its own — a ridge, a snowfield, a stretch of moor where one direction looks like the next. A walker adds a stone and goes on. The pile stays, and shows whoever comes after which way the route ran. The word is Scottish Gaelic, *càrn*, a heap of stones.

The tool keeps that habit. Each session leaves a little more on the graph and moves on, and the next one reads the stones instead of guessing the way. The stone outlasts the walker who set it, and the graph outlasts the session that wrote it.

## A continuity subsystem, shipped as an extension

cairn began as the continuity subsystem inside kli, the agent runtime it was built for, and it ships as exactly the kind of extension kli exists to host. kli is a host for agent extensions; cairn is the one that handles memory across sessions. Run inside kli, cairn is at its fullest. The agent gets the tools, and the host adds three things on top: slash commands for steering by hand, per-turn folding of the current task's live state into the model's view, and folding of your observations and handoffs into the summary when a long conversation is compacted. That is why kli is the fuller home for cairn. See [Reads, writes, and capabilities](/cairn/concepts/reads-writes-and-capabilities) for how the host enforces the boundary between what an agent can read and what it can change.

## Works with any MCP client

cairn does not require you to adopt kli as your main agent. Pointed at a serving process, an MCP client — Claude Code, Claude Desktop, Cursor — sees cairn's fourteen tools as MCP tools, with its workflow prompts and the `cairn-method` skill exposed as MCP prompts and readable resources. Capability gating carries over the wire, so the read / write / observe split still holds. What does not travel is the part kli provides as the host: the slash commands, context injection, and compaction folding named above stay behind. A plain MCP client still gets a complete, useful surface.

One command — `kli mcp-serve cairn` — serves the extension to anything that speaks the Model Context Protocol. The command, its client configuration, and the exposed surface are documented in [mcp-serve](/cairn/cli/mcp-serve).

## The recursive loop

These docs are written to be read by a machine mid-task as readily as by a person at a desk. So the pages lead with what a thing *is*, keep their anchors stable, and quote tool names and return strings verbatim — an agent cannot paraphrase a wrong string into a working call. These pages were themselves produced by an agent dogfooding the [cairn-method](/cairn/concepts/the-cairn-method), the same bootstrap, observe, and handoff loop that keeps any plan across resets.

## Where cairn earns its weight, and where it does not

cairn pays off when work spans more sessions than a single context holds, when a plan has phases and dependencies worth tracking, or when more than one session might touch the same work and needs to see the others. It is a poor fit for a one-shot task you will finish in the session you start it, or a single-agent flow short enough to keep entirely in context. For those, the graph is overhead — a plain note to yourself wins. cairn tracks what you are doing without prescribing how you do it, which means the judgment of when to reach for it stays yours.

## Related

- [The task graph](/cairn/concepts/the-task-graph) — the two stores and the typed-edge model underneath everything here
- [Tasks, observations, and handoffs](/cairn/concepts/tasks-observations-handoffs) — the three nouns and how each write behaves
- [The cairn-method](/cairn/concepts/the-cairn-method) — the working loop and the disciplines that wrap it
- [Events, projection, and reconcile](/cairn/concepts/events-projection-and-reconcile) — why a write survives a rebuild
- [Install cairn](/cairn/get-started/install-cairn) — bake it into kli or serve it to another client
- [Your first cairn session](/cairn/get-started/your-first-cairn-session) — the bootstrap, observe, handoff loop made concrete