---
title: "Substrate Without a Consumer"
canonical: https://dxdev.com/blog/2026-05-10_substrate-without-consumer/
datePublished: 2026-05-10
---
I built 6,134 enrichment sidecars for my multi-agent system and realized absolutely nothing was reading them.

I spent around a sum of Haiku API credits over 11 hours to process my conversation archive. The data was structured, tagged, and sitting on my hard drive. It was completely useless.

## The missing wire

The problem was a missing wire. I had built a massive producer but neglected the consumer. The sidecars were meant to feed into a daily calendar view that aggregates my cross-agent activity. But the script generating those day-files was still counting raw session manifests instead of reading the enriched index. The data was there. The surface I actually look at every day was blind to it.

This is the substrate without a consumer trap. It is easy to get caught up in building the foundation. You tell yourself that once the data is clean and the infrastructure is solid, the value will naturally follow. It does not. Infrastructure has no inherent value. Value only exists at the point of consumption.

The trap is especially easy to fall into when you are working with AI agents. The agents are fast. You can spin up a batch job, push a prompt file, and come back to thousands of processed records in the time it takes to make coffee. The speed creates the illusion that you are making progress. But speed applied in the wrong direction is not progress. It is just faster waste.

## The fix was 40 lines of Python

When I audited the system, the fix was almost embarrassingly small. The index already existed. The day-file generator already had a placeholder block for cross-agent data. The missing piece was about 40 lines of Python to load the index, group the entries by provider, and render a simple table. A zero-cost, one-afternoon task.

But because I had not built it, the entire enrichment run was dead weight. The data existed. The surface existed. The wire between them did not.

I stopped the enrichment runs as soon as I saw that nothing was reading the output. There is no point in processing the rest of the corpus until that 40-line wire is in place. The constraint is not data or API quota. The constraint is my own attention and the surfaces I use to make decisions.

## Pair the producer and consumer in the same week

The lesson is about sequencing. Never build a producer in one quarter and plan the consumer for the next. They need to be paired in the same week. If you cannot build the consumer yet, do not build the producer.

The reason this trap is so easy to fall into is that building the producer feels like progress. You are processing data, generating output, filling directories with structured files. It looks like work. But if nothing is reading those files, you have built a very expensive buffer.

The correct sequence is the reverse. Build the consumer surface first, even if it is fed by mock data. Get the view working. Confirm that the data it would display is actually useful to you. Only then build the pipeline to populate it. This forces you to prove the value before you pay the cost of the infrastructure.

This principle applies beyond AI pipelines. Any time you are building a data store, a processing layer, or an enrichment system, ask yourself: what is the first surface that will read this? If you cannot name it, you are not ready to build the producer.

## The 40-line wire is the product

Going forward, I am changing how I sequence these projects. The consumer surface has to exist first. Not as a placeholder comment in a script. As a working view, even if the data is fake.

The 6,134 sidecars are sitting there. The index is clean. The day-file generator has the placeholder. The 40-line wire is the only thing between a sum of dead weight and a working feature.

That is the project. Not the enrichment pipeline. The wire.