What Glenn McDonald's Data Alchemy Taught Our Analytics Agent

You cannot hire Glenn McDonald onto your data team. He spent over a decade at a major music-streaming company as their 'Data Alchemist' - a job title that, true story, started as a self-deprecating joke and ended up as a real role in the HR system. He built Every Noise at Once, the map of thousands of musical genres that became the canonical example of what it looks like when someone can both write the algorithm and judge whether its output actually means anything. He named the genre 'Escape Room.' He named 'Alt Z.' Then he got laid off, like everyone eventually does, and the institutional knowledge of how he did it mostly walked out the door with him.

That is the problem with great data practitioners. The valuable part is not the SQL. It is the judgment - the accumulated instinct for when a tidy cluster is a real category versus an artifact of one backfill job. That instinct usually lives in exactly one person's head, and when that person leaves, your team relearns it the slow way.

You cannot hire that judgment, but you can learn from it - because McDonald has written about how he works, at length, in public. So we read the essays and interviews where he explains his method, and built an analytics skill around the principles. This post is about what we learned, and why it is not a one-off - it is how we have built hundreds of skills.

What Is Actually Worth Learning

It is tempting to copy the surface - the witty genre names, the rainbow visualization. That is the illustration, not the method. The method is something McDonald has written about directly, on his own blog, in his own unpretentious words. Four ideas do the real work.

The technical-plus-cultural edge. In a profile at Imbue, McDonald described his advantage as a rare pairing: the technical ability to write and tweak the algorithm, and the cultural ability to listen to the result and say whether it was close or far off. Curators who knew the music could not tune the model; ML engineers who could tune the model could not hear when it was wrong. He held both, and that is why he moved faster than teams twice his size. Most analytics tooling assumes you have one half or the other. The interesting skill is the one that insists on both.

The computer is a data knife. On his blog he writes that he has been cutting up data with computers since the late 1980s, and the ergonomics have been uniformly poor the whole time. Spreadsheets are a bagel-cutter - fine for a narrow set of foods. Most database software is an industrial bread-slicing machine, not a knife. His point: shape the tool to the exact cut you are making, instead of forcing every question through the same generic apparatus. He cared about this enough to build his own query language, DACTAL, because - his words - he feels certain nobody finds SQL charming.

Cluster, then listen. His genre method was not 'run k-means, ship the labels.' His tools surfaced unlabeled clusters with data evidence that they belonged together - usually artists sharing the same listeners. But, he is emphatic, you had to actually play the music to decide whether it was a real genre, because sometimes a cluster was just every artist from one movie soundtrack. The validation step - pulling the actual members and inspecting them before you believe the grouping - is the part everyone skips and the part that separates a real finding from a confident-sounding mistake.

Count right, and demonstrate rather than illustrate. Two of his lines have become something of an ethic for us. The first: 'If your data systems can't count right, you shouldn't be trusted to run them.' The second, on how to argue with data: it should be supported by demonstration, not illustration - give people the reproducible query so they can re-run it and reach shared understanding, instead of a chart they have to take on faith. And on AI tools specifically, his advice is to use them 'curiously, actively, skeptically,' to insist they explain themselves, and to 'distrust anything they present to you as magic.'

How a Method Becomes a Skill

There is now a clean way to do this kind of distillation. The open-source project Mimeo, from K-Dense AI, has a memorable framing: turn a body of public expertise into a SKILL.md. It runs a pipeline that finds an expert's essays, talks, and interviews, extracts the principles and frameworks and anti-patterns, verifies the quotes against the original sources, and runs an adversarial critique pass before emitting a skill file. It is a structured answer to a real question: how do you turn a body of public thinking into something an agent can actually use?

We took that approach and pointed it at McDonald's primary sources - his blog (furialog), the in-depth Q&A where he explains the genre method, the Imbue profile. The non-negotiable rule was provenance: every principle in the skill traces to something he actually published, with the quote verified against the source. No paraphrase-drift, no invented method, and the skill is named for the method (data-alchemy-exploration), not the person. (There are, for the record, a few 'data alchemy' copycats floating around. We sourced only the real one.)

What comes out is not a personality cosplay. It is a procedure. The skill we shipped, data-alchemy-exploration, runs in our analytics agent and reads, in part, like this:

• •Frame the question twice - once technically (what to compute) and once in domain terms (what a believable answer looks like in the real world). Write down what would make the result trustworthy before running anything.
• •Shape the sharpest tool for this cut. Ask the exact question; do not reach for boilerplate that answers a different one. The computer is a data knife.
• •Surface candidates from the data's own evidence - cluster by the dimension the data itself implies (shared upstream source, shared consumers, co-occurrence), not by a label you assumed.
• •Play the music. Pull the actual member rows of each cluster and inspect them before you believe it. A tight cluster can be one backfill, one source system, one soundtrack.
• •Count right. Reconcile the headline number against its parts. If it will not add up, stop - and hand off to the quality agent to find out why.
• •Name it only when it is real, and deliver the reproducible query alongside the finding. Demonstrate, don't illustrate.

The decision points are where the judgment lives. If inspecting the examples shows a cluster has no domain coherence - it is just one nightly import job - the skill discards it instead of inventing a story about a 'domain' that does not exist. If the headline number will not reconcile with its components, it routes to our quality agent before reporting anything. If the metric itself is contested, it gets a canonical definition from our context-and-catalog agent first, because you cannot validate a pattern against a number nobody agrees on. That is McDonald's method, made executable and composable with the rest of the swarm.

Why a Skill, Not a Clever Prompt

You could paste a description of McDonald's method into a chat window. It would help a little, and then it would evaporate at the end of the session. A skill is durable in a way a prompt is not: it has explicit triggers, so the agent reaches for it on the right kind of question; it is wired to specific tools, so 'play the music' means actually pulling rows, not hand-waving; and it declares its handoffs, so when the numbers do not count right, the work moves to the agent that can fix that. It is version-controlled, reviewable, and it composes. A prompt is a suggestion. A skill is part of the machine.

One of More Than 400

Here is the part that matters for anyone evaluating Data Workers: this is not a clever one-off. The McDonald skill is one of more than 400 skills we have authored across 20 specialized agents - covering connectors, catalog and context, cost, governance, incidents, analytics, migration, ML, observability, orchestration, pipelines, quality, schema, search, streaming, and usage intelligence. Some are built from first principles. Some, like this one, are distilled from the public work of the best practitioners in the field. All of them are version-controlled, validated against the tools they call, and ready for an agent to run.

The reason we build this way is the same reason McDonald's method is worth learning from at all. The hard, durable value in data work is not any single query - it is the accumulated judgment about which queries to trust. Most of that judgment is trapped in individual heads and lost on every reorg. A skill library is a bet that you can capture a published method, name it, verify it, and hand it to an agent that does not quit, forget, or get laid off. We do not think we have solved data engineering. We think we have found a good way to keep its best instincts from leaking out the door.

And in the spirit of demonstrate-don't-illustrate: the skill is real, it validates, and it ships inside our analytics agent. If you want to see it cut, that is the right way to judge it - not from this page, but from the result.

Explore the agents and skills: dataworkers.io/docs

The distillation approach we drew on: github.com/K-Dense-AI/mimeo

Glenn McDonald's own writing, worth reading directly: furia.com

A note on this post: This is independent commentary and homage. It distills publicly available writing and talks by Glenn McDonald to illustrate a working method, and every quote is drawn from and verified against the primary sources linked above. The skill it describes is named for the method, not the person, and contains no marketing claims attributed to him. Data Workers is not affiliated with, sponsored by, or endorsed by Glenn McDonald. If you are Glenn McDonald and would like anything adjusted or removed, email hello@dataworkers.io and we will respond promptly.