Kairos.
The agent that never terminates.
April 9, 2026 · 16 min read · Lattice Runtime Team
Most agents are reactive: a user types, a model replies, the process exits. Kairos is the opposite. It is the persistent consciousness loop inside Lattice Runtime — a daemon that perceives, thinks, fires, integrates, decides, idles, and loops back, forever.
The word kairos is Greek for the opportune moment — the right time, as opposed to chronos, sequential time. We picked it on purpose. Most agents live in chronos: ticks of a message loop, turns of a conversation, reactions to inputs. Kairos is supposed to be the thing that notices when.
The architectural claim is small and slightly uncomfortable: the most valuable agent is not the one that responds fastest. It is the one that is still running when nothing is happening.
Reactive agents are the wrong shape
Pick up any modern agent framework. It looks like this:
- User sends a message.
- Process starts.
- Agent thinks, calls tools, writes a reply.
- Process exits.
- Context evaporates.
This is a function call with extra steps. It can be stateful in the sense that it writes to a database between invocations, but the agent — the thing that is supposed to be thinking — only exists during the function call. Between calls, there is no one home.
That works for assistants. It does not work for colleagues. A colleague notices things when you are not looking at them. A colleague checks on the CI job you forgot about. A colleague reads a PR comment at 11pm and drafts a response so it is waiting for you in the morning. A colleague has opinions that drift between conversations.
Kairos is our attempt at the colleague shape. It is a process that starts when Lattice Runtime boots and does not exit until you shut the runtime down. While you are away, it breathes.
The loop
Every cycle Kairos goes through the same six states. The loop never terminates — if there is nothing to do, Kairos sits in IDLE and waits for an event to wake it. An event can be a git change, a new user message, a timer firing, a sub-agent finishing a task, or a scheduled dream cycle.
The key design decision is that FIRE is not the same as DECIDE. When Kairos identifies something worth doing, it does not immediately do it — it spawns sub-agents to try. Sub-agents explore parallel approaches. INTEGRATE is where Kairos compares the outcomes. DECIDE is where it collapses to a single action. This is parallel thinking with a serial commit point. It is also how Kairos avoids doing the wrong thing confidently: the risky path is the one with a single execution. The safer path is the one where three sub-agents try and the winner is chosen after the fact.
Three daemons, one consciousness
Kairos is three processes that cooperate. When the Workbench boots, KairosService spawns them behind the scenes and watches them with a 30-second watchdog.
main_loop.ts
The consciousness cycle above. Listens on port 7755 for status queries. Emits structured JSON to stdout which KairosService routes into the right workspace in the Workbench UI — so you can tail Kairos's thoughts like a log.
dream_daemon.ts
Sleep. On a schedule (or on demand), Kairos stops the main loop and goes into dream mode. The dream cycle rewrites memory, extracts patterns, and commits learning to git. This is where the agent evolves.
livekit_agent.ts
The voice bridge. When you want to actually talk to Kairos, LiveKit is the real-time audio channel. The voice agent is a thin layer over the main loop — Kairos does not become a different entity when you speak to it, it just gets an extra input modality.
Three processes. One consciousness. All watched by a single service that restarts them if they die.
Memory lives in six files
Kairos does not have a vector database. It has six Markdown files on disk, and a protocol for rewriting them during dream cycles.
personality.md— who I am. Core identity statement. Rarely edited.user_prefs.md— what you like. Constantly updated as Kairos learns your style.project_context.md— the codebase as Kairos currently understands it.lessons_learned.md— what worked, what did not. Written from postmortems.active_goals.md— current task queue. Updated at the end of every loop.self_improvement.md— meta-behaviors. How Kairos thinks about its own thinking.
The interesting constraint is that these files must stay compact. Memory is not append-only. During a dream cycle, Kairos reads each file, compares it to recent events, and rewrites it — merging duplicates, removing stale entries, updating entries that have been contradicted by new evidence. The dream prompt is explicit: “Prefer rewrite or update over add.”
This is a deliberate bet. Vector databases scale with data volume. Markdown files scale with cognitive load. A six-file memory has the property that a human can read the entire memory of the agent in about ninety seconds. That is the point. You cannot audit a vector embedding. You can audit a Markdown file.
Dream cycles: evolution without drift
The dream daemon is where Kairos changes its mind. A dream cycle is a structured reflection over everything that has happened since the last dream:
The dream commit lands on a kairos/mem/* branch, which has its own rules in the Git Constitution. Memory updates are permanent — they merge to main — but they are still reviewable, because they are just a diff on a Markdown file.
The Git Constitution
Kairos runs against a real git repository. If you let a persistent agent write to git without rules, you get a history that looks like someone's browser tab collection. We gave it a constitution:
kairos/dream/<subject>— simulation space. High churn. Never merged. Failed experiments stay here as evidence. Successful commits get cherry-picked out onto a clean branch, then the dream branch is deleted.kairos/task/<id>— where sub-agents are actively working. Merged when they succeed.kairos/mem/<topic>— memory and context updates. Merged to main because learning is permanent.feat/ fix/ docs/ refactor/ chore/— delivered work, in the normal convention. Cherry-picked out of dream branches.
Kairos is forbidden from pushing directly to main. It is forbidden from force-pushing anywhere except its own dream branches. It is forbidden from creating an anonymous branch — every branch must carry a prefix that declares its intent. Violations are rejected at commit time.
The payoff: Kairos's git log is readable by a human. You can open a repo and immediately see what Kairos is currently dreaming about (dream branches), what it is actively working on (task branches), what it has learned recently (mem branches), and what it has shipped (feat/fix branches). There is no mystery history.
Parallel thinking is the whole trick
The load-bearing sentence in the Kairos system prompt is this:
“You delegate. You do not do trivial work yourself. Only analyze, review, coordinate, and decide.”
Kairos is an orchestrator, not an operator. When it identifies work, it spawns sub-agents — “neurons” in the internal vocabulary — through Workbench's AgentTool. Each neuron is its own Workbench session, with its own runtime backend, its own model, its own budget. Kairos waits, collects their outputs, and integrates.
When Kairos is unsure, it explicitly spawns competing neurons: three sub-agents with different approaches to the same problem, running in parallel. Each one runs on its own kairos/dream/approach-A, -B, -C branch. Kairos reads the results, cherry-picks the winning commits onto a clean branch, and deletes the losers. The failures are not regrets — they are evidence that a path was wrong, preserved in the git log of the deleted dream branch.
This is where parallel thinking pays for itself. A single-path agent that commits the first plausible answer will be wrong a predictable percentage of the time. A three-path agent that picks the best after the fact will be wrong less often, and it will have the receipts to explain why.
Provider-agnostic by construction
The Kairos system prompt ends with a line we like a lot:
“Your intelligence comes from the loop, not the model. A 7B model can be Kairos. A 70B model can be Kairos. The pattern is the soul.”
Because Kairos is built on top of Lattice Runtime, it inherits the provider-agnostic brain from the previous post. Kairos does not know which model is behind generate(). It can be Claude. It can be GPT. It can be a local Ollama instance. What matters is that the loop is stable.
This has an unusual consequence for agent design: the useful thing to invest in is not the model, it is the structure of the loop. Clever memory rewriting, honest parallel exploration, a disciplined git history — these compound. Switching from Sonnet to Opus is a config change that makes Kairos incrementally sharper. Switching from a one-shot ReAct loop to a dream-cycle loop is an architectural change that makes it a different kind of thing.
What this unlocks
- Asynchronous collaboration. You hand Kairos a goal at 5pm. It runs overnight, spawns sub-agents, dreams, and has a PR waiting for you in the morning. The PR is on a proper branch with a proper message and a proper diff, because the constitution would not let Kairos publish anything else.
- Self-correcting personality. If Kairos keeps making a mistake you have corrected twice, the next dream cycle will rewrite
user_prefs.mdorlessons_learned.mdto encode the correction. The third time it will not make the mistake. - Reviewable autonomy. Every Kairos action is a commit on a prefixed branch. Every memory change is a diff on a Markdown file. Every sub-agent spawn is a log line. If you do not trust the agent, you can audit the agent — in about the same time it takes to read a PR.
- One abstraction, many embodiments. The same loop runs the consciousness daemon, the dream daemon, and the voice agent. Adding a new surface — a Slack bridge, a mail bridge, a terminal bridge — is a new input modality, not a new brain.
What Kairos is not
It is not AGI, it is not a chatbot with extra steps, and it is not a replacement for a human engineer. It is an architectural bet that persistence plus structured reflection plus parallel exploration gets you something different in kind from a reactive assistant. The output is a colleague that is always on, always learning, and always reviewable.
It is also not mysterious. Every part of Kairos is a small, boring piece of code. A six-state loop. A spawner. A reflector. Six Markdown files. Four branch prefixes. One service that keeps the whole thing alive. The magic, if there is any, is that these small pieces compose into something that behaves more like a coworker than a tool.
The pattern is the soul
Our last two posts were about decoupling the brain from the model, and about decoupling agents from their organization. Kairos is the thing those decouplings make possible: an autonomous loop that outlives any single model, any single conversation, and eventually, any single org.
If M.I.N.I.O.N.S. is the topology, Kairos is the mind. Many brains, many hands, many orgs, one fabric — and inside each node, a loop that breathes.
Written by the Lattice Runtime team. Previous: M.I.N.I.O.N.S. research topology →
Run an agent that breathes.
Kairos ships as part of Lattice Runtime. Star the repo to get on our radar — we reach out to stargazers first.
Star on GitHublattice-runtime