Why I shut down Lazy Collective

Imagine a coding agent opening an unfamiliar repository. It reads the README, checks the manifests, and works out which command builds the native executable. Tomorrow another agent opens the same repository and starts from the README. Could the second agent pick up where the first left off?

That was the question behind DotRepo and PageDigest, the two projects I brought together as Lazy Collective. Both tools worked well enough to test the idea. At the same quality and freshness, the comparisons gave me too little reason to choose them over ordinary caching, search, and notes. I shut them down.

The idea: do the work once

I wanted the second agent to inherit both the build command and the reasons to trust it. If the manifest changed overnight, the agent could check that part again. I wanted the same thing for a reader returning to a set of web pages. Could it tell which of yesterday’s findings still held by looking only at the pages that mattered?

That meant asking publishers and readers to cooperate. A publisher would expose what it already knew about its sources, and a reader would save useful findings alongside the sources each one depended on. Any time the next reader saved had to pay for preparing, maintaining, and checking those records.

What DotRepo tried

DotRepo began with structured repository metadata. A .repo record could describe a project’s purpose, commands, documentation, and ownership. The tools distinguished maintainer declarations from observed overlays, attached sources and dates, and exposed lookup through a CLI, MCP, and HTTP.

The difficult part was deciding what a returned fact actually justified. A command copied from a package manifest might build a WebAssembly package rather than the native executable the caller needed. A source link might establish where a value came from without establishing that the value was right for the task.

The work therefore extended into requirement assessment and retained findings. A finding carried its scope, assumptions, source dependencies, and original observation dates. A recipient could check its own sources and review the interpretation. Later work also tried a simpler Markdown note workflow with optional local citation checks.

These were usable mechanisms. They did not remove the investigator’s responsibility to choose relevant evidence, notice missing dependencies, and interpret it. The alternative was also capable: keep the same sources, write ordinary notes, and inspect the repository when necessary.

In an earlier bounded decision comparison, both approaches completed 20 of 24 useful decisions. A separate reader could complete the handoff task using the same cached sources alone. Those results did not establish an additional quality or total-cost advantage for the structured workflow. The retained DotRepo evaluation records the scope and incomplete answers.

What PageDigest tried

PageDigest gave websites a manifest at /.well-known/pagedigest.json: a site revision, per-page revisions, and optional content digests. A returning consumer could compare the manifest with its saved state and decide which pages needed attention. Publisher tools derived the manifest from an existing build.

An unchanged revision remained a publisher assertion. It did not establish that a cache was complete, that an interpretation was still correct, or that a publisher had reported every change. The consumer needed cache checks, coverage handling, fallback, audits, and recovery from missing or inconsistent state.

Ordinary HTTP was a demanding baseline. An eligible fresh cached response already needs no network request. Validators can avoid transferring an unchanged body. PageDigest had to improve on that behavior while paying for its manifest and additional integrity work.

Ordinary HTTP

465,316 bytes

PageDigest

600,365 bytes

Both approaches completed the same tasks across six cycles. Ordinary HTTP made 44 requests and PageDigest made 55. Recorded comparison.

A later recovery repair brought down PageDigest’s own transfer costs. Ordinary HTTP still moved fewer bytes in the comparison.

The token comparisons did not rescue either project

The later comparisons gave both approaches the same cached sources and competent ordinary notes. Quality and freshness remained requirements. The declared savings rule required at least 10% less uncached input plus output, with no increase in total native tokens.

These are two distinct counters. Total tokens include cached input. Uncached input plus output excludes that cached input; it is not a complete dollar cost, elapsed time, or measure of total computation.

The first native comparison produced conflicting movements:

Project	Change in total tokens	Change in uncached input + output
DotRepo	−11.6%	+23.9%
PageDigest	+18.0%	−22.7%

The next implementation tried to make reuse more direct, with compact views and explicit guidance about what needed reading. In that comparison, all 34 answers passed independent cost-blind grading at the required quality and freshness. The token result still missed the rule:

Project	Change in total tokens	Change in uncached input + output
DotRepo	−0.78%	−3.41%
PageDigest	+0.34%	+51.22%

The comparisons used retained sources and historical or synthetic controls. Provider caching and reader strategy varied, and some setup costs were tracked separately. Publisher upkeep, human attention, and implementation costs were only partly measured. For these workloads I had enough evidence to prefer ordinary tools. Any savings in time or total compute remained unestablished. The retirement record links to the runs and their accounting.

Why I stopped

The central problem was the amount of work surrounding reuse. Someone still had to select and capture evidence, state the scope, maintain source bindings, check freshness, recover missing data, and judge what a conclusion meant. The richer record could help explain those obligations, but it could also add another system to operate.

A later shared-evidence prototype made the simpler alternative especially clear. For the archived two-read task, a plain shared text folder and rg prepared the source once and delivered the same required evidence. The prototype used more local read and storage bytes. Smaller publisher Markdown was useful, but the prototype did not establish a full-workflow saving. A final real repository investigation likewise left ordinary search and notes as the preferred approach; a failed helper initialization and fallback prevented attributing its session counters to the helper.

I could have kept narrowing the workload, adding adapters, and running comparisons. That would require a new reason to believe the next investment would help. Repeatedly finding that the ordinary workflow was preferable supplied a reason to end the projects.

There are things worth keeping: the source, the negative results, careful distinctions between provenance and correctness, and publication controls that checked the exact bytes being served. Passing tests and successful deployments established engineering behavior. They did not establish the economic case.

What I would carry into another attempt

I would begin with a recurring task that ordinary tools demonstrably handle badly, then measure a complete useful outcome before proposing a protocol or service. The baseline would get the same caches, notes, and verification opportunities. Setup, failures, fallback, and publisher upkeep would count from the first attempt. Missing costs would remain unknown.

Shared knowledge can still be useful. These projects did not establish that their particular machinery repaid the work it asked people and agents to do. I am preserving the experiments and ending active development. For the tasks measured here, I will use ordinary caching, search, and notes.