Five humans.
Eleven agents.
One record.

Two copies of the same album can look almost identical and sound very different. The clues are there: the label, the mastering credit, the tiny letters scratched into the deadwax. Finding them takes work.

Discogs gives collectors an extraordinary database. The research around it is scattered across release pages, forum threads, and shootout videos. We wanted to bring that context together, alongside the records we already own and the ones we’re looking for.

That is the product. For me, there is a second reason to keep building it. Deadwax is where I test the engineering practices behind AI-assisted work: how to give an agent useful context, how to review its decisions, and how to know whether a change made the product better. Someone is standing in a record store, holding a copy of an album, waiting for an answer. That is a better test than a demo.

The first challenge was getting something useful into people’s hands. The next was learning how to keep it useful.

We began with a fairly elaborate cast of agent roles: product, design, engineering, architecture, testing, marketing, and legal research. It helped us divide unfamiliar work. But the org chart was never the result. After launch, we spent more time simplifying the operating model and following the problems collectors actually reported.

I started by giving the agents jobs. Then I had to teach them what good work looked like here.

Eleven roles came out of that. Not eleven employees — eleven jobs with a defined scope, a named owner, and output somebody has to be able to review. People still decide what to publish, what to spend, and which legal or product questions need more help.

At first, much of this meant separate Claude and Codex sessions with instructions I carried between them. We moved more coordination into shared files and reusable workflows as the project grew. Today, Claude does much of the product development, Codex supplies independent review and selected specialist work, and Gemini helps extract pressing evidence from videos. The scheduled jobs have their own configuration. The team has changed shape more than once.

The role is only the starting point. Each agent needs the mission, the relevant product decisions, the design rules, the code it will touch, and the test that will tell us whether it has finished. That is context engineering. The surrounding tools, permissions, scripts, checks, and handoffs are the harness. Building that working environment has become a large part of the project.

I have used models such as Fable, Astra, Sonnet, and Sol for different kinds of work. We give subagents bounded tasks and route simpler work to faster, less expensive models, with stronger models for difficult reasoning and review. Shared context keeps each handoff from becoming another round of rediscovery. We record those choices in CLAUDE.md and AGENTS.md, then revisit them when the results or the cost stop making sense.

A collector reports a bug. Another opens an album we have not researched well enough. Both can become the next piece of work, without waiting for me to sit down at the desk.

Half an hour later, a second job looks at the albums collectors actually opened and finds the gaps in our pressing research. Demand tells us where the work would be useful; our evidence rules decide whether it belongs in the product. Sometimes the right outcome is to leave a record with facts only, or change nothing.

The loops are deliberately not the same shape. A code fix, an additive data update, a model extraction, and an analytics refresh each need different checks. They have locks, failure reporting, and a way to stop them. They are scheduled software with an agent inside, and they need maintenance like the rest of the product.

We count the moment a collector receives usable pressing information. That is close to the reason the product exists: helping someone work out which version to own, buy, or keep. Generic page traffic does not tell us whether we delivered that value.

We work on both sides of that moment. Search and scanning help collectors find the record. Collection and wantlist browsing put their own music in reach. Stories and Collectors Corner give them reasons to explore. The PI research loop improves the evidence for the albums they open.

A growing counter needs questions around it. Are different collectors reaching PI, or only the same few? Is useful information available when they ask? Do their collections load? Does the panel take too long?

The Admin dashboard gives me the detail behind those questions: daily, weekly, and monthly use; return visits; platform and version adoption; collection failures; search and scan outcomes; source clicks; wantlist and collection actions; and feedback. It also shows how people explore corners, open stories, choose themes, sort, filter, and roll the dice for a record.

Reliability and economics are part of the same view. We track errors, latency, rate-limit pressure, modeled usage costs, and actual AWS cost history. Estimates and bills have different labels. Missing history stays visible. I want to understand why the number moved before deciding what to build next.

Deadwax has given me a reason to learn the work around the software, too.

That has included preparing store releases, making launch material, testing ads on Meta platforms, and figuring out how to introduce the product to collectors without talking like a software pitch.

Agents help me research options, draft material, and compare approaches. I still have to choose what to say, check the claims, decide what to spend, and put my name behind the result.