Interactive demoMock API
Music Analysis Chat
A roster workspace built to answer one question: when an agent replies about music data, what should come back instead of a paragraph? Six artifact types, four surfaces, and a mock API that always returns the same shapes.
It runs in the browser with no key and no backend. Ask it about saves, social, creators or outreach and it answers from a fixture.
What an answer should look like
A roster workspace for a label, built to rehearse rich agent output in a domain I already know well.
In simple terms
A workspace for a record label, built out of interviews rather than out of an idea.
I sat with people at a label about what actually goes wrong when they try to put AI into their daily work. The pattern was consistent: the tools answer in paragraphs, and the job is not made of paragraphs. The questions are narrow and they repeat. How did this release convert. Who is posting with the sound. Who should we send the brief to. Each of those has a known answer type, and prose is the wrong shape for all of them, which is exactly what a chat box hands you by default.
The other half of what they told me is that nobody trusts an answer they cannot check. A number in a sentence is a claim; the same number in a table you can sort, next to the rows it came from, is evidence.
So this is not a chatbot that knows about music. It is an argument about response shape: for a question with a known answer type, the agent should return the artifact that answers it, and the sentence should be the caption on that artifact rather than the answer itself.
The impact. It reframes what an agent gives back as something you act on and can verify, rather than something you read and have to trust, which is the difference between a demo that impresses a label and a tool that survives contact with their week.
Why it exists
I spent years around music data: save rates, playlist adds, which clip is driving which conversion. The questions people actually ask of it are narrow and repetitive. How did this release convert. Who is posting with the sound. Who should we send the brief to. None of those are answered well by a paragraph of prose, which is what a chat interface gives you by default.
So this is not a chatbot with music trivia in it. It is an argument about response shape: for a question with a known answer type, the agent should return the artifact that answers it, and the prose should be the caption rather than the payload.
The rule the fixture enforces
Every reply is a short piece of text plus an ordered list of blocks, and the block types are a closed set. A question about conversion returns stats and a chart. A question about social returns stats, embeds, and a next-step row. A question about creators returns a roster with engagement and price on every card.
Because the set is closed, the surface can be built once and trusted. Nothing has to parse markdown at render time and guess whether a table was meant; the agent picked a type, and the type has a component.
The artifacts
Six block types, rendered here by the same components the demo uses, holding the same payloads the fixture returns. These are the real thing, not pictures of it.
statschartcomparisoncreatorsemailsocialFour surfaces, one set of blocks
Chat is where a question gets asked, but it is a bad place to keep an answer. So the same blocks compose into three other surfaces: an analytics view over the whole roster, an artist view per act, and a projects view where a campaign collects the artifacts it produced. A long answer also opens in a side panel with its full body, its table, and its own follow-up row, so a deep dive stops competing with the thread it came out of.
Artists can be pulled into a question with an @ mention, which is the whole context model: the thing being asked about is named, not inferred.
Why the API is a fixture
Nothing behind it is real. The API is one function that matches keywords in the question and returns a hand-written payload after a short delay. That is the point: the work here is the response contract and the surface that renders it, and a real model would only add a source of variance to a thing being judged on its shape.
It also means the demo has no key, no backend and no rate limit, so it still runs exactly as built.
What I would keep
The closed block set, and the rule that prose captions an artifact rather than carrying the answer. Both survived into how I build agent surfaces now: name the answer types first, build a component per type, and let the model choose among them instead of formatting freehand.
The demo is still here and still runs. It is filed under the write-up rather than beside it because the interesting part is not that a chat window works: it is the list of things the agent is allowed to hand back.
Open the demo