Acceptance contract first
Read-only discovery, a contract compiler, an independent critic, and criterion-to-check coverage lock a content-addressed contract before mutation. Ambiguous or unsupported work can pause explicitly.
OPEN-SOURCE · AUTONOMOUS DELIVERY · VERIFIED RECEIPTS
Loop.
A coding goal, a checked change, and evidence to review.
Loop compiles a bounded goal into a locked acceptance contract, executes and repairs the work, and checks it on fresh snapshots. Product Sessions preserve successive revisions and their evidence before guarded Apply or Undo.
Latest published release: v0.1.0. Implementation details reflect main at commit 65a8161, reviewed October 19, 2026. The dated repository evaluation below is a separate development snapshot, not a v0.2 release announcement.
HOW IT WORKS
A bounded path from request to evidence.
- 01
Contract
Translate the request into explicit acceptance criteria, required artifacts, authority limits, and checks before execution begins.
- 02
Execute
Plan, use tools, inspect failures, and repair the implementation inside a bounded runtime rather than stopping at generated code.
- 03
Verify
Run declared checks independently against fresh snapshots so completion cannot be self-certified by the same working context.
- 04
Deliver
Return reviewable artifacts or a Git change set with hashes, events, check results, and enough evidence to replay the decision.
DESIGN
The product is the contract.
The interface is useful because it exposes what happened, where confidence comes from, and where the system stops—not because an agent produced a confident paragraph.
Recoverable background work
Redis Streams workers use visibility leases, stale-message recovery, bounded retries, dead-letter handling, and compare-and-update task claims. Failed work remains inspectable.
Independent verification
Checks rerun outside the implementation context against fresh snapshots, reducing the chance that contaminated state produces a false pass.
Replayable Receipts
A hash-linked event ledger preserves inputs, outputs, check results, and delivery state for later inspection and replay.
Versioned product feedback
Product Sessions distinguish implementation fixes from product decisions, preserve cumulative isolated revisions, and allow Apply only from the latest revision. Receipts and guarded Undo keep the handoff reviewable.
Local to orchestrated
Capability checks constrain tools, filesystem scope, and egress. Docker and Kubernetes provide command boundaries; inline mode remains an explicitly reduced-isolation development path.
QUICK START
Inspect the real thing.
The keyless deterministic demo exercises the contract, execution, verification, delivery, and Receipt path without requiring a model-provider account.
TERMINALRESEARCH RELEASE · v0.1.0
$ git clone https://github.com/chriswu727/loop-agent.git
$ cd loop-agent
$ make demoVERIFIABLE SCOPE
- 20 / 21
- deliverable attempts solved
- 3 / 3
- contradictions safely deferred
- 0
- false acceptances observed
- 24
- total repository attempts
Recorded July 22, 2026: eight small repositories, three repeats, one DeepSeek model, and macOS inline execution. One UI attempt paused unnecessarily after contract compilation failed; it remains in the frozen result. A later regression covers a recovery path, but does not change this score. This does not establish cross-model reliability or isolated Docker/Kubernetes performance.
HONEST BOUNDARIES
What this does not prove.
- 01Loop v0.1.0 is a research release, not a claim of production mileage across arbitrary repositories or organizations.
- 02The deterministic demo proves the delivery protocol; it does not measure the quality of every model, prompt, or provider-backed workload.
- 03The inline demo profile intentionally trades isolation for approachability and is not the right boundary for untrusted commands.
- 04Provider-backed tasks need workload-specific evaluation, cost limits, and human review before they are trusted with consequential delivery.
- 05Use the container or Kubernetes execution profiles when the command surface or artifact boundary requires stronger isolation.
FAQ
Before you try it.
Is Loop another coding chat interface?
No. It is a bounded delivery runtime: it formalizes acceptance, executes work, independently verifies the result, and returns evidence alongside the implementation.
Can Loop demonstrate its workflow without an API key?
Yes. The deterministic make demo path exercises the full contract-to-Receipt lifecycle without a model provider. Real provider-backed workloads are a separate evaluation surface.
Does a Receipt prove the software is correct?
No. It proves what contract and checks ran, against which artifacts, and what they returned. The strength of the conclusion still depends on the quality of the acceptance criteria and checks.
Is Loop ready for unattended production changes?
Not as a blanket claim. v0.1.0 is a research release. Consequential use should add workload-specific evaluation, strong isolation, bounded authority, and human review.
OPEN SOURCE