# Lifeloop Product Thesis
## Status
Strategic orientation note
## Date
2026-05-07
## Thesis
Lifeloop is not merely an extraction from CCD. Lifeloop is the productization of
one larger realization:
> AI harness lifecycle is a reusable substrate.
Every serious harness has a lifecycle: session start, frame or prompt assembly,
context pressure, compaction, tool phases, turn end, closeout, interruption,
and recovery. Today those lifecycle moments are exposed through incompatible
hooks, logs, launchers, wrappers, callback shapes, and telemetry conventions.
That mismatch is why useful automation keeps getting rebuilt for each runtime.
Lifeloop's opportunity is to normalize those lifecycle moments once and expose
them as a stable control plane for clients. The immediate client is CCD, but
CCD is not the point. CCD is one strong proof that lifecycle normalization has
value.
The split into CCD, Lifeloop, Reforge-family clients, Fixity, and RLM is an
implementation consequence. The strategic decision is larger: once Lifeloop
exists as a standalone harness lifecycle abstraction, a whole class of products
can be built without re-learning every harness's quirks.
## The Realization
CCD gained leverage because it touched harness lifecycle hooks. That access
made continuity ceremonies possible, but it also pulled unrelated features into
CCD:
- harness adapters
- hook installation
- runtime telemetry readers
- lifecycle extension dispatch
- memory and recall experiments
- native runtime memory bridges
- Fixity-like portability signals
- automatic ceremony triggers
Those features did not enter CCD because they were all continuity. They entered
CCD because CCD was the codebase with lifecycle reach.
The product lesson is not "split the repo." The product lesson is:
> Lifecycle reach should be its own product boundary.
When lifecycle reach is owned by Lifeloop, clients can stay honest:
- CCD can focus on continuity.
- RLM can focus on recursive inference augmentation.
- Reforge-family clients can focus on memory and learning.
- Fixity can focus on portable constraints and repeated-signal capture.
- Experimental clients can test new runtime behaviors without contaminating
CCD.
## What Lifeloop Is
Lifeloop is the provider-neutral lifecycle abstraction for AI harnesses.
It owns:
- harness identity, aliases, and adapter manifests
- lifecycle event vocabulary
- hook timing normalization
- integration modes such as native hook, launcher wrapper, manual skill,
telemetry-only, and reference adapter
- capability negotiation
- lifecycle receipts
- payload placement and delivery metadata
- lifecycle-relevant telemetry such as context pressure and recent activity
- failure classes and retry posture for lifecycle operations
- extension hosting as a dispatch mechanism
It does not own:
- continuity
- memory
- recursive inference
- prompts as product semantics
- tool abstraction
- skills
- model selection
- a universal IDE
- a user-facing replacement for existing harnesses
The boundary is intentionally narrow. Lifeloop knows when and how lifecycle
events happen. Clients decide what those events mean.
## Why This Is Bigger Than CCD
### Focused CCD
CCD becomes a cleaner product because Lifeloop exists.
CCD's durable promise is portable continuity: preserving the line of work
across sessions, context resets, runtime switches, and machine changes. That
does not require CCD to own harness hooks, telemetry readers, runtime memory,
or lifecycle extension dispatch.
With Lifeloop, CCD can expose continuity callbacks and stay useful in two
modes:
- manual continuity ledger without Lifeloop
- automatic continuity ceremonies with Lifeloop
That makes CCD smaller and stronger rather than making it a worse version of a
memory product, runtime platform, or IDE.
### RLM
RLM needs lifecycle normalization but not CCD continuity.
Recursive inference augmentation wants to open and close frames, correlate
nested calls, observe budget pressure, and persist receipts around recursive
work. Those needs align with Lifeloop's lifecycle model. They do not require
handoff, radar, thread capsules, memory promotion, or CCD1.
This is why RLM is the important second-client pressure: it proves Lifeloop is
not just a CCD refactor.
### Reforge-Family Clients
Memory and learning should be lifecycle-aware, but not continuity-owned.
Harness-native memory, recall providers, transcript-derived candidates,
promotion, compaction, and learning loops can all benefit from normalized
lifecycle events. They should not live inside CCD simply because CCD previously
had the hooks.
Reforge-family clients can consume Lifeloop receipts and CCD curl exports when
useful, but they own their own memory state and policy. This keeps memory
experimentation free to evolve without forcing CCD to become a memory platform.
### Fixity And Small Clients
Fixity-like behavior is another example of lifecycle reach creating a useful
client that does not belong in CCD kernel.
Repeated dead ends, reinforced constraints, and stable observations may be
worth carrying forward. That is adjacent to continuity and memory, but it is
not identical to either. As a Lifeloop client, Fixity can observe lifecycle
events and publish its own artifacts without becoming a CCD kernel feature.
The same pattern applies to thread-sync publisher, telemetry experiments,
approval observers, cost accounting, workflow adapters, or future research
clients.
### Experimentation
Lifeloop gives experiments a stable place to attach.
Without Lifeloop, experiments must choose between:
- forking each harness integration
- becoming a CCD feature
- building a private wrapper around one runtime
With Lifeloop, experiments can target lifecycle events and capability
manifests. That makes it cheaper to test ideas across harnesses and easier to
discard failed experiments without leaving stale concepts in CCD.
## Product Architecture
The target architecture is a lifecycle-centered client ecosystem:
```text
harnesses
Claude / Codex / Gemini / Hermes / OpenClaw / OpenCode
|
v
Lifeloop
lifecycle events, receipts, capabilities, payload delivery
|
+------------+-------------+-------------+
| | | |
CCD RLM Reforge Fixity
continuity recursion memory family constraints
```
The important shape is not the number of repositories. The important shape is
that product semantics sit above Lifeloop and communicate through public
protocols.
## Strategic Rules
- If it normalizes harness lifecycle, it belongs in Lifeloop.
- If it preserves work continuity, it belongs in CCD.
- If it learns, remembers, recalls, extracts, promotes, or compacts, it belongs
in the Reforge family or another memory client.
- If it augments recursive inference, it belongs in RLM or an RLM-adjacent
client.
- If it exists only because CCD had hooks, it should be extracted or deleted.
- If a concept is demoted in prose but remains load-bearing in code, it has not
been removed.
- Compatibility shims are acceptable only as tombstones, not as hidden old
implementations.
- Lifeloop hosts extension dispatch; client extensions live outside Lifeloop
core.
- CCD capsules carry continuity by default. Memory and learning artifacts are
explicit client attachments, not kernel payloads.
## Live-ASAP Strategy
The first live milestone should prove the Lifeloop opportunity, not complete
every extracted product.
1. Lock the callback protocol.
2. Stand up Lifeloop as a standalone lifecycle substrate.
3. Slim CCD enough that Lifeloop drives continuity through public callbacks.
4. Extract one small non-CCD lifecycle client, such as thread-sync publisher, to
prove clients can live outside CCD and Lifeloop core.
5. Let RLM begin against Lifeloop's stable public lifecycle contract.
6. Build Reforge-family clients independently from the monolith-freeze memory
code.
This sequence makes Lifeloop useful quickly. Reforge, Fixity, and RLM then
become proof of the same platform opportunity rather than blockers for it.
## Why The Split Still Matters
The split matters because it prevents the opportunity from collapsing back into
a monolith.
If Lifeloop stays inside CCD, RLM and Reforge either import CCD or rebuild their
own lifecycle normalizers. If memory stays inside CCD, CCD remains a hidden
memory product. If Fixity stays inside CCD, extension behavior remains
kernel-shaped. If callback protocol stays implicit, every client guesses.
The split is not the headline, but it is the enforcement mechanism. It turns
the strategic realization into product boundaries that code, tests, docs, and
future agents can respect.
## Success Shape
The desired outcome is not "CCD was split into repos." The desired outcome is:
- Lifeloop becomes the stable way to target AI harness lifecycle.
- CCD becomes a focused continuity ledger.
- RLM can start without depending on CCD.
- Memory and learning can evolve in Reforge-family clients.
- Small lifecycle clients can be created, tested, and discarded without CCD
absorbing them.
- New harnesses become easier to support because clients target Lifeloop
instead of each harness separately.