Context resets
The next session starts by rediscovering intent instead of continuing the highest-value open unit.
Repository control for long-running agent work
Give every agent the context, work graph, and proof to continue.
LoopCode first understands the repository, forms explicit domain hypotheses, and researches only the bounded discipline the work needs. It keeps goals, decisions, constraints, active work, dependencies, and verification in the repository—so Codex, Claude Code, or another compatible host can resume from evidence instead of reconstructing a conversation.
Private beta · local-first, host-owned, readable in Git
01CanonicalRepository files stay authoritative.
02BoundedEvery material unit declares its limits.
03InspectableGraphs, receipts, and checks are visible.
04PortableHosts execute; the contract travels.
01 — The missing layer
The repository has the code. It needs a reliable account of the work around it.
A coding agent can read thousands of files and still miss why a decision was made, what another session already tried, which constraint is non-negotiable, or what must pass before a change is accepted.
Handoffs lose judgment
Current code survives, but rejected options, risks, ownership, and recovery paths disappear.
“Done” is hard to inspect
A plausible answer can look complete even when no independent check proves the outcome.
The product in one sentence
Make consequential agent work resumable, inspectable, and verifiable.
02 — The operating loop
One bounded pass. A better starting point next time.
LoopCode is a repository contract and evidence layer, not another model or hidden daemon. It tells the host what must be understood, researched, declared, executed, checked, and left behind.
Orient
Read the bound goals, day plan, newest operations-log leg, queue, and current evidence. Repository documents are authority; conversation history is context.
Plan
Write the unit down before it runs: owner, capability, acceptance, side-effect class, recovery, and evidence it must leave.
Graph
Dependencies, worktree fences, and independent verification become inspectable nodes. The host decides which seat actually launches.
Verify
Deterministic gates and named reviewers decide acceptance. A returned answer is not proof; a receipt records what was checked and what remains.
A bounded return looks like this
Nothing mysterious has to happen between “work” and “ready.”
The host owns worker launch, credentials, sandboxing, scheduling, billing, and production authority. LoopCode records the proposal, the observed effect, the verifier, and the residual.
$ loopcode drive .
"doctor": "CONTROL_PLANE_HEALTHY",
"next": "domain-pack.schema",
"authority": "host-owned",
"status": "ready-for-host-execution",
"receipt": "LIFECYCLE-…".loopcode/binding.json keeps the repository's own documents canonical. loopcode roster discovers launchable seats and loopcode dispatch-plan recommends a route; neither command launches a worker.
When the repository is unfamiliar
Census → hypotheses → bounded research → overlay → verified graph.
The overlay records sources, freshness, rules, roles, risks, gates, recovery, privacy, and unknowns. If the domain or authority is unclear, LoopCode stops safely and asks instead of guessing.
03 — The proof layer
A completion claim should have an anatomy.
LoopCode keeps the state, action, verifier, limitations, and responsibility that make work inspectable after the model context is gone.
State
Goal, queue row, graph node, owner, capability snapshot, and stable idempotency key.
Action
Command or tool call, side-effect class, artifact reference, and retry or rollback history.
Acceptance
Deterministic check, source-linked claim, named reviewer, or an explicit not-verified result.
Receipt anatomy
Ownerroot / verifier
Side effectrepository write
Evidencetests + diff + source
Residualnamed, not hidden
INSPECTABLE
BY DESIGN
BY DESIGN
04 — The change in practice
From “what was I doing?” to “here is the next verified move.”
LoopCode adds a small, structured collection of Markdown files, graph state, and receipts to the repository. People can read them, hosts can project them, and a new session can continue from them.
Conversation is the only handoff.
Intent, attempted work, decisions, and proof are spread across context windows and must be reconstructed.
The repository carries the handoff.
Goals, queue state, dependencies, evidence, recovery, and the next action remain versioned beside the code.
05 — Domain packs
Specific where the work is specific. Portable where it should be.
A domain pack is a versioned operating contract around a bounded job—not a prompt bundle or a claim that LoopCode knows an entire profession. The core keeps identity, graph, receipts, and evidence portable; the domain declares its state, tools, policies, fixtures, validators, roles, recovery, privacy, and source limits.
Supported proof domain
Software delivery
Repository goals, queue rows, worktree fences, tests, release checks, review, and Git evidence.
repo → graph → patch → tests → receiptAdaptive kernel
Repository discovery
LoopCode observes the monorepo, keeps competing domain hypotheses visible, researches declared sources, and compiles the smallest removable overlay.
census → sources → overlay → refreshResearch direction
Science, data, and regulated work
Provenance, source authority, approvals, privacy, recovery, and expert review stay explicit. No professional or compliance authority is implied.
claim → evidence → review → boundaryPortable contract
Check the shape before you trust the story.
loopcode pack-validate checks a manifest, its declared references, and the authority boundary without contacting a model provider.
{
"kind": "domain-pack",
"id": "software-delivery",
"fixtures": "fixtures/",
"validators": "validators/",
"evidence": ["artifact", "verifier", "limitations"]
}Healthcare, finance, legal, science, browser, robotics, and other vertical examples remain research directions until their fixtures, validators, approvals, recovery semantics, and privacy rules are verified.
06 — The operator view
See what is next, what is blocked, and what proves it.
loopcode dashboard --open rebuilds a light, read-only projection from bound documents, workflow receipts, host capabilities, and adaptive-domain evidence. Overview, Queue, Workflow, Programs, Evidence, Hosts, Domains, and Settings make the next decision easier to see; canonical truth stays in the files.
Queue
Now, Ready, Waiting, Blocked, and Parked work with ownership, dependencies, evidence, and recovery.
Workflow
Text-first dependencies, fences, why-next reasoning, acceptance, proof, blockers, and recovery.
Evidence + Domains
Receipts, source freshness, host capabilities, domain hypotheses, and explicit unknowns.
07 — Boundaries
Portable contracts. Host-owned authority.
LoopCode is not a new model and does not replace Codex or Claude Code. It keeps repository memory and evidence legible while the host retains the authority that must remain close to the user.
LoopCode keeps
- Canonical goals, decisions, queue state, and graph identity
- Evidence references, receipts, deterministic gates, and recovery notes
- Portable Agent Skills/MCP boundaries and removable domain overlays
The host keeps
- Models, providers, credentials, sandbox, network, device, and browser access
- Scheduling, billing, worker launch, approval, and production authority
- Consent and any external or billable action
Local and readableCanonical memory is ordinary Markdown in the repository, not a hidden remote database.
Evidence before “done”Jev is disabled by default and shadow-only; a provider cannot change routing, safety, acceptance, or completion.
Domain authority stays human-ownedLoopCode can research and structure a bounded discipline; it cannot certify, advise, diagnose, regulate, or silently authorize it.
08 — Open conventions
Use the ecosystem at the edges. Keep the contract legible.
LoopCode adopts open conventions when they improve portability, while keeping authority and proof explicit.
Agent Skills
Progressive instructions and resources that do not grant credentials or permission.
MCP
Host-managed typed tools and context; the host still owns consent, authorization, and transport.
JSON Schema + gates
Portable shapes and deterministic checks keep acceptance inspectable when optional advisers fail.
09 — Availability
LoopCode is in private beta.
The current package is verified across the available Codex and Claude Code surfaces. Public installation stays gated until the distribution repository, license, release channel, and onboarding path are ready for people outside the development team.
Current status
Private source · verified package · public release in preparationClaude Code
claude plugin marketplace add peppty-dev/LoopCodePlugin
claude plugin install loopcode@loopcode-pluginsCodex (development checkout)
codex plugin marketplace add /absolute/path/to/LoopCodePluginAccess currently requires permission to the private repository. Host permissions, credentials, scheduling, billing, and production actions remain host-owned.
View the development repositoryQuestions
The short version.
Is LoopCode another coding agent?
No. The host remains the coding agent. LoopCode gives it durable repository context, operating rules, verification gates, and receipts.
Does it upload my repository?
The current core has no network dependency and canonical memory stays in local Markdown. Future analytics, if any, must be separately opt-in and privacy-scoped.
Does it make every task complicated?
No. Small reversible work stays lightweight. Deeper graph and evidence paths are for consequential, cross-system, uncertain, repeated-failure, or hard-to-reverse work.
What is a domain pack?
A versioned contract for a bounded domain job: ontology, source authorities, tools, policy, fixtures, validators, human responsibility, recovery, metrics, and privacy. It is not a prompt bundle or automatic compliance certification.
Does LoopCode depend on Jev?
No. Jev is disabled by default and shadow-only if explicitly evaluated. A provider outage or disagreement cannot change deterministic routing, safety, acceptance, or completion.