YYLO: Bounded AI Coding Orchestration + Git Memory

I built YYLO because agentic coding tends to fail where engineering teams care most: traceability, reviewability, and repeatability. When an AI agent runs without constraints, it’s hard to answer basic questions—what was the bounded outcome, what changed, which attempt passed validation, and why that acceptance decision was made.

YYLO is split into two open-source tools so responsibilities are clear. YYLO Ledger is a Git-native task and Record store that keeps canonical task state in repository files and preserves an opt-in hash-chained history over time. YYLO CLI is a TypeScript orchestrator that runs coding agents while replacing unbounded loops with iteration limits, session continuity, observable commands, and validation evidence.

The goal is practical: coordinate coding agents from engineering intent through validated code while preserving the task, session, review, and evaluation evidence that explains what happened. I wanted something that doesn’t replace Git or your repository workflow—it coordinates execution and makes the work inspectable.

In other words, YYLO treats “memory” as engineering memory. It links intent, decisions, attempts, validated code, and (eventually) real-world outcomes. That’s why the system is designed to keep evidence receipts, commit-linked completion, and integrity checks as first-class artifacts.

YYLO also fits teams that don’t want a single monolith. You can use Ledger or CLI independently, or combine them for Ralph-style loops with guardrails: bounded iterations, dependency-aware tasks, and auditable software delivery. The modular workflow is meant to be adopted incrementally in existing repos.

Most agent workflows fail at the handoff between “AI produced code” and “engineering accepted code.” Even if the agent outputs a patch, you still need durable answers to: What was the intended bounded outcome? Which constraints and dependencies were applied? Which validation steps were run? And what evidence supports acceptance?

Unbounded agent loops create another failure mode: the agent keeps trying until it feels done, not until it meets a defined acceptance policy. That makes it difficult to compare attempts, reason about regressions, and keep review sessions grounded in the same criteria every time.

Finally, many agent systems don’t respect Git as the source of truth for change. If the agent edits files in-place without isolation, it becomes harder to separate “agent work-in-progress” from “reviewable change.” Without isolation and guarded delivery, merges can become less deterministic and less explainable.

YYLO is designed around these pain points: it coordinates agent execution while preserving provenance, it validates results with evidence receipts, and it records what happened so future work can reuse the same intent and acceptance logic rather than re-deriving it from scratch.

YYLO coordinates coding agents from engineering intent through validated code while preserving the task, session, review, and evaluation evidence that explains what happened. It does this by separating task truth from execution orchestration.

YYLO Ledger focuses on task and Record management in a Git-native way. Canonical task state stays in reviewable repository files so your team can review intent, blockers, and responses like any other change. Opt-in hash-chained history preserves progress over time, while a disposable SQLite cache speeds up queries without becoming the source of truth.

YYLO CLI focuses on execution control. It routes work to an agent, preserves the agent’s worktree and session provenance, and replaces unbounded agent loops with iteration limits. It supports reusable command or YAML workflows, observable commands, and validation evidence. In configured repositories, it can isolate work in exact-base Git worktrees and protect integration with guarded merge operations.

Together, the system creates a durable chain from: (1) intent, (2) bounded agent attempts, (3) validation evidence receipts, (4) recorded outcomes tied to commits, and (5) merge outcomes that are reviewable and auditable. That’s the core idea: controlled orchestration plus engineering memory.