Observe
Record facts, constraints, and discoveries.
A durable provenance layer for agent work
Context is temporary.
ldgr is not.
ldgr is a durable provenance layer with a command-line interface designed for agents.
Agents use it to create persistent observations, artifacts, validations, decisions, and work items. These records form a structured project history.
This history gives agents the structure and evidence they need to solve complex problems. It helps them resume interrupted work. It rebuilds relevant context across long-running tasks.
01ObserveLog important information
02scheduleSchedule work items
03Validateldgr status
05DecideChoose the next step
04recordProvenance written
fresh instanceRelevant history
Context
Context gets stale.
Refresh it in one command.
Long tasks outgrow a single context window. ldgr stores the project history outside the model.
The agent retrieves the records it needs. It receives a focused briefing without replaying the entire conversation.
Refresh context →ldgr contextfocused briefing
$ ldgr context
state: running
work_items: pending=53 running=8 held=8 done=530
next: telemetry-100-core-state-instrumentation [P0]
ready: yes
next_dependencies: satisfied
blocked_by: none
unblocks: telemetry-270-end-to-end-smoke
queue: P0=24 P1=29
programs: adapter-ux=6 telemetry-sequences=21
Core loop
Work items become contracts.
ldgr enforces completion.
Break complex work into atomic items. Define the expected result. Add dependencies. Set the validation rules.
ldgr schedules each ready item. A fresh agent receives a narrow context. The item remains open until its completion contract passes.
Schedule
Order work by dependency. Run only ready items.
Validate
Test the result against its completion contract.
Record
Store the outcome, evidence, and artifacts.
Rehydrate
Load the context required for the next item.
Decide
Close the item or schedule the next action.
$ ldgr loop runInstallation
Your agents already use the terminal.
Add one command.
Install ldgr beside your existing tools.
Keep your current agent. Keep your current editor. Keep your current CI system. Keep your current repository.
No new control plane. No platform migration. No hosted dependency.
curl -fsSL https://raw.githubusercontent.com/hydra-dynamix/ldgr-core/main/scripts/install.sh | shAdapters
Give it a repository.
Find what you missed.
Adapters give agents focused commands for a specific system.
They inspect the source directly. They return evidence-backed observations and work items. ldgr stores the results in the same project history.
View adapters →finding 01evidence-backed
The public API changed.
The runtime graph did not.
The adapter compared the declared interface with the runtime dependency graph. It found the mismatch. It recorded the affected files as evidence.
Boundary
Keep your stack.
Add durable project history.
ldgr does not replace the systems that already run your work. It gives those systems one persistent record.
Not a harness
Use your current agent harness. ldgr stores the work and evidence.
Not a multi-agent orchestrator
Your runtime launches agents. ldgr schedules the work they receive.
Not a plan or scratchpad
Plans disappear with context. ldgr records survive the session.
Not an MCP server
Agents use the command-line interface directly.
Not an IDE
Keep your existing editor and development tools.
Not a hosted service
Run ldgr with your project. Keep control of the history.
Not a human-centric UI
The command-line interface serves agents first. Human interfaces read from the same ledger.
Systems
One project history.
Focused tools for each workflow.
Adapter ecosystem
Complex work needs focused tools.
Add the right adapter.
Adapters give agents domain-specific commands. They keep specialized logic outside the core.
Each adapter writes to the same project history.
Stop re-briefing your agents.
Give each agent the project history it needs. Keep work moving across sessions.