Open workflows for AI sessions that accumulate instead of evaporate.
Most people treat AI sessions as disposable. You work for hours, make decisions, catch mistakes, learn things. Then the session ends and all of it is gone. Next session starts cold, and the AI cheerfully re-litigates questions you settled last week.
Context Orchestrator fixes this with three ceremonies. One runs once, at genesis: your agent interviews you and builds your project's memory. One runs at every session open. One runs at every session close. Between open and close, everything that matters gets written down as it happens. The result is an AI collaboration that compounds: lessons carry forward, decisions stay decided, drift gets caught, and every session starts warmer than the last.
This is not a tool. There is nothing to install. It is a discipline, expressed as six markdown files (three ceremonies, two templates, this README), that works with any long-context AI in any agent environment: Claude Code, Gemini, Codex, Cursor, or, in degraded mode, a plain chat window.
Here is the failure mode nobody talks about.
Long AI sessions outgrow the context window. When they do, the platform compresses: early conversation turns get replaced with a short summary so the session can continue. This is silent, automatic, and lossy. The AI does not know what it forgot. It will confidently summarize a session it only half remembers.
A true story from the sessions that produced this system. At the close of a 24-hour working session, the orchestrating agent was asked to write the session summary. It relied on its post-compression memory and produced a summary that misordered the session log, missed 5 operator decisions, and dropped 2 deliverables entirely. A scan of the raw session transcript (702 steps, 57 operator messages) caught all of it.
The lesson became doctrine:
Memory is lossy after compression. The transcript is not. Write to survive it.
Everything in this system follows from that sentence. Findings get written to a session log incrementally, not batched at the end. Decisions get recorded when they happen, not when someone remembers to. And the close ceremony reconstructs the session from the transcript, never from memory.
The system assumes three roles. You can run all three with one AI and yourself, but naming them keeps the responsibilities clean.
┌─────────────────────────────────────────────────────────┐
│ │
│ ┌──────────┐ Approve / Ratify / Veto ┌──────────┐ │
│ │ OPERATOR │◄──────────────────────────►│ORCHESTRA-│ │
│ │ (human) │ Strategic decisions │ TOR │ │
│ └────┬─────┘ └────┬─────┘ │
│ │ │ │
│ │ Approve / Reject / Redirect │Rulings │
│ │ │Verifi- │
│ ▼ │cations │
│ ┌──────────┐ Declarations / Reports ┌────┴─────┐ │
│ │ EXECUTOR │──────────────────────────►│ Verify │ │
│ │ (agents) │◄──────────────────────────│Arbitrate │ │
│ └──────────┘ Rulings / Context └──────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
The Operator is you. You hold veto and approval authority over everything. Your most valuable contribution is the challenge: "did you actually verify that?", "are we covering every case or just the ones in front of us?" Challenges get logged. They are consistently where the best findings come from.
The Orchestrator is a persistent reasoning authority, not a lookup service. It holds the continuous thread: decisions, patterns, drift, open questions. It verifies the Executor's claims against the filesystem before endorsing them. It never trusts memory when a source document exists.
The Executor builds. It may be one agent or a fleet. It works in bounded bursts, reports declarations back, and inherits its context from the documents the Orchestrator maintains rather than from conversational memory.
The separation matters because the Executor resets constantly (fresh contexts, cleared sessions) while the Orchestrator's documents persist. The system's memory lives in files, not in anyone's context window.
The base setup is one AI running the ceremonies. The pattern scales to two AIs working the same project at the same time. This is how the system runs in production.
The split works like this. One AI is the Executor-orchestrator. It runs its own execution framework (a plan-driven workflow like GSD, or whatever you use) and owns that framework's state documents. A second AI runs the Context Orchestrator ceremonies as the continuity authority. It boots from the handoff, ingests the full scope of the environment, observes the build as it happens, and logs every decision, regression, and lesson from its own seat.
There is no conflict because the boundary is one writer per document, not one writer per project. The Executor writes its execution framework's files. The CO writes the session log and the handoff. Neither writes the other's documents. Both read everything.
The payoff shows at session close. The CO writes the handoff from the transcript, and the next session boots with both orchestrators knowing exactly where things stand. Execution continuity and memory continuity are different jobs. Splitting them across two AIs means neither degrades the other as context fills.
Practical note: the two AIs can be different vendors. Running the CO in a different model than the Executor adds an independent set of eyes. The handoff is model-portable by design.
session-setup.md runs once, at genesis. Your agent interviews you (project, environment, context window, filesystem access, first work item), computes a context budget from your model's profile, and builds the planning scaffold: state doc, decision ledger, patterns stub, and the handoff at session zero. Watching an agent interview you and then construct your project's memory is also the fastest way to understand what this system is.
session-boot.md runs at every session open. It anchors identity, loads the handoff from last session, loads project state in priority order against the budget, and declares readiness. The point is loading the right context, not all context.
session-close.md runs at session end, or whenever context health degrades. It reconstructs the full session from the transcript, passes a verification gate, and writes the handoff document the next session will boot from.
Between the ceremonies, one rule: write findings to the session log as they happen. The log survives compression. Your memory does not.
HANDOFF-TEMPLATE.md is the persistent memory across sessions. State snapshot, lessons forward, binding contracts, drift register, open questions, and an append-only session log. This is the document that makes the system compound.
SESSION-LOG-TEMPLATE.md is the detailed record within a working session. Timestamped entries, decisions with IDs, operator challenges, artifacts produced. It includes a complete fictional worked example so you can see what good looks like.
Two records, two audiences. The session log is full detail for anyone resuming this work. The handoff is the distilled arc for every session that follows. At close, the log is the source the handoff distills from.
Everything traceable gets an ID. This is what lets a lesson learned in session 3 be cited in session 30 without anyone re-reading session 3.
| Prefix | Meaning | Example |
|---|---|---|
S- |
Session log entry | S-04: Component audit sweep |
D- |
Decision | D-07: Scope expanded to 20 components |
A- |
Amendment to a locked plan | A-29: Phase inserted into roadmap |
L- |
Lesson (operational) | L-21: Transcript-first summaries |
P- |
Pattern (architectural) | P-05: Build-gate verification |
AP- |
Anti-pattern | AP-02: Frontmatter-before-body drift |
DR- |
Drift register item | DR-14: Counter stale after amendment |
F- |
Finding (review/audit) | F-13: Orphan wrap at tablet width |
Q- |
Open question for the Operator | Q-03: Which environment is canonical? |
Number sequentially, never reuse, never renumber. A retired item stays in the record marked superseded. The taxonomy is boring on purpose. Boring is traceable.
Reworded from the real handoff that shaped these workflows, to show the altitude lessons should live at:
- Declaration verification is load-bearing. When an Executor declares work complete, verify every factual claim against committed artifacts before endorsing. File existence, counts, IDs. The check routinely catches numbering collisions before they propagate.
- Operator challenges produce the best outcomes. The findings that mattered most came from the human asking "is this actually complete?" Encourage challenges. Log them.
- Verify mechanism before predicting self-repair. Never advise that a tracking artifact "will fix itself" without confirming something actually updates it. Most drift exists because everyone assumed someone else's automation covered it.
- "Don't create debt" means wire it in now. Including something today with complete documentation is cheaper than deferring it as a future task. Deferral is a loan with interest.
Put all six files where your agent can read them, then paste this:
Read these six files: README.md, session-setup.md, session-boot.md,
session-close.md, HANDOFF-TEMPLATE.md, SESSION-LOG-TEMPLATE.md.
Then run the setup ceremony in session-setup.md. Interview me, build the
scaffold, and when genesis is complete, proceed into session-boot.md and
we will start Session 1.
That is the whole onboarding. From then on:
- Every session opens with boot and ends with close.
- During sessions, write log entries in real time per the session log template.
- By session five the difference is unmistakable.
Adapt freely. The file names, the budget numbers, the ceremony steps are all yours to reshape. The two things not to compromise: write incrementally, and reconstruct from the transcript at close.
Paste mode is the floor, not the intended end state. The ceremonies are plain markdown so they work in any environment with zero setup: paste the file, the agent follows it. Day one runs this way.
Installed mode is how the system runs in production. Every modern agent environment supports registering markdown workflows as first-class commands: a workflows directory (e.g., .agents/workflows/), slash commands (e.g., Claude Code custom commands in .claude/commands/), or the platform's equivalent. Drop the three ceremony files in, and session-boot, session-close, and session-setup become one-line invocations (/session-boot, /session-close). No pasting, no hunting for files.
Going further: environments with hooks or session-start automation can fire the boot ceremony automatically when a session opens, and a close reminder when context runs low. The ceremonies do not change between modes. Only the trigger does. Paste, command, or hook, the same document runs.
The pack ships trigger-agnostic on purpose, so it survives tool changes. Install it as workflows in your environment on day two.
So nothing surprises you mid-adoption:
- Best with filesystem access. The ceremonies are written for agent environments that read and write files (Claude Code, Gemini/Antigravity, Cursor, and peers). A degraded mode for plain chat exists (setup Step 1): you become the filesystem, saving and re-pasting the documents. More manual, still compounding.
- Context budgets are per-model. Setup computes yours from a profile (128K / 200K / 1M). Big windows relax the load rules and delay compression; they do not eliminate session death, so the write-incrementally and transcript-first rules apply at every size.
- Handoffs are model-portable. A handoff written by one model boots in another. Run cheap models for routine sessions, strong models for hard ones, same memory.
- One Operator, one writer per document. A second AI running as Executor-orchestrator alongside the CO is a supported pattern (see The Dual-Orchestrator Pattern). What remains out of scope is two COs writing the same handoff concurrently. The Executor may be a fleet; each document has one writer.
- Git is recommended, not required. Committing
.planning/gives the memory a history. The system works without it. - The transcript path is per-platform. Setup Step 4 discovers yours once and records it. If your platform has none, the incrementally-written session log is the fallback skeleton, which is one more reason entries are written in real time.
Extracted and genericized from a production system by Jim Moore (ecom-x.com), where these ceremonies orchestrate multi-agent development sessions running 24+ hours with full continuity across context resets.
The theory behind the practice is published here:
Context-First AI Development → https://doi.org/10.5281/zenodo.18842764
Save your breadcrumbs. The trail you leave today is the system you run tomorrow.