Cairn

A self-hosted panel where knowledge about a project outlives the agents that work on it. A coordination log, not a runner: agents read the briefing and report results, so you do not explain the same thing to each of them. For teams running several agents on the same code.

TL;DR

Cairn is a self-hosted panel where knowledge about a project outlives the AI agents that work on it. It is a coordination log, not a runner: an agent reads the briefing, does its part and reports the result, so you do not explain the same thing to the next one from scratch. For teams that run several agents on the same code and are done with project memory dying along with the session.

Overview

When several AI agents work on one repo, knowledge about the project has a nasty habit of dying with the session that ended. The first agent learned the hidden dependencies, found out which part of the code is fragile, and worked out how deploys happen here. Then the session goes dark and that knowledge is gone. You explain the same thing to the next agent from the top, and to the one after, and again, until you become the bottleneck for knowledge about your own project.

This is not a compute problem or a model problem. No stronger agent fixes it, because it is a memory-between-sessions problem, not a within-one-session one. Cairn aims at exactly that spot: it holds the briefing and the history of decisions in one place that does not vanish when an agent finishes. The rest of this case study is the story of why it is deliberately a log, not yet another orchestrator.

Knowledge that dies with the session

An agent session is transient by nature. It gathers context, builds its work on it, and then ends and all that context evaporates. With one agent that is no problem: you remember it. With five that enter the same repo one after another or in parallel, each one starts from zero and each rediscovers the same landmines anew. The same fragile migration, the same non-obvious deploy, the same dependency that only blows up in a certain order.

The natural reflex is to write it into the README or paste it into the prompt. Except a README ages fast, and a prompt dies with the chat window. What was needed was a place that grows with the project and outlives individual sessions: something an agent checks for context on the way in and appends what it did on the way out.

Note

Cairn is deliberately not a runner. It does not launch agents, manage their processes or try to be their environment. It is a coordination log: a place an agent checks for context and writes back what it did. That boundary is its whole strength.

A log, not a runner

It would have been easy to turn this into yet another orchestrator that launches agents itself and tries to conduct them. We passed on that on purpose, because runners have a predictable fate: they wire deep into your environment, assume more and more about it, and quickly become a thing that needs maintaining itself. Instead of giving memory, they take time.

A coordination log is the reverse: simple, passive and out of everyone's way. The agent still lives where it usually does, in your terminal or pipeline, does its work in its own environment, and Cairn just gives it memory and a place to report. There is no orchestration magic that works in a demo and falls apart on a real project, because there is no orchestration at all.

What it holds, and what it deliberately does not

Role	Cairn does	Cairn does not
Context	holds the briefing and decision history	does not guess the context for you
Coordination	a per-project log of entries, in order	does not launch or manage agent processes
Hosting	you run it yourself, the data stays yours	does not ship your code to someone else's cloud
Visibility	one place for what is done and open	does not replace your repo or CI

The briefing, work, report loop

At the heart is a per-project coordination log. Instead of keeping knowledge in one agent's head or in one chat session, you write it down once as a briefing, and every next agent starts by reading it. When it finishes, it adds its own entry: what it did, what the state is, what is left open for the next one. The log grows and becomes the project's memory, independent of which session happens to be alive.

Briefing

you set up a project and describe it once: what it is, where the boundaries are, what to watch out for.

Agent reads

every new agent starts from the same context, without you repeating it by hand.

Agent works

it does its task in its own environment, because Cairn neither launches it nor constrains it.

Agent reports

it appends the result to the log: what it changed, what works, what is left.

Next one continues

the following agent reads the briefing plus every report and enters the work with the full picture.

The key is that an entry is not free text but a short structure with a state and a list of what is open for the next one. That keeps the log equally quick to read for a machine and for a human, and the next agent does not have to guess where the previous turn left off.

entry.ts · ts

type LogEntry = {
  project: string;
  agent: string;
  at: string;
  did: string;
  state: 'done' | 'partial' | 'blocked';
  openForNext: string[];
};

function contextFor(project: string): string {
  const brief = readBrief(project);
  const history = readEntries(project);
  return [brief, ...history.map(render)].join(SECTION_BREAK);
}

Scale that grows with the project

The difference only becomes visible over distance. Without shared memory the cost of bringing in each next agent grows, because every time you manually explain an ever longer project history. With Cairn that cost is flat: the first agent and the tenth read the same source, so they enter the work with the same picture, regardless of where in the order they are.

Time to onboard the next agent (illustrative, minutes)

That is the whole difference between a team that scales the number of agents and a team drowning in its own onboarding. Memory that outlives sessions turns knowledge about the project from something you have to reconstruct every time into something that simply is.

1 briefing

written once, read by every agent

1 log per project

memory that outlives sessions

processes launched, because it is not a runner

self-hosted

data and code stay with you

The quiet memory layer

The best tools are not the ones that do the most. They are the ones that do one thing and get out of the way.

A team that runs several agents on the same code stops being the bottleneck for its own knowledge. You write the briefing once, not at every new chat window. The agent that shows up third knows as much as the first, because it reads the same thing. Cairn is not flashy and does not try to be: it is the quiet memory layer that used to be missing between sessions.

➜

Tip

Keep the briefing short and hard: the project boundaries, the fragile bits, the way deploys happen. The rest gets appended by the agents in their reports. A briefing that tries to describe everything ages just as fast as the README it was meant to replace.

Because you run it yourself, neither the code nor the decision history leaves for someone else's cloud. The project's memory stays where the project is: with you. It is an unassuming layer, but once you start running agents in series, it is hard to go back without it.

More projects

More work from the same category - see how we tackle similar challenges.

Platform / Open source

Pharos

Have a similar project?

Get in touch - a quote is free and comes back within an hour.