From article to podcast without a microphone

We wanted to know one thing: can an article become a conversation without a human sitting at a microphone?

The answer is yes. But the interesting part isn’t the sound — it’s what needs to be in place before the sound, and what we learned along the way about our own system for producing our Podcast Experiment.

The chain has five links, and only one of them is a human

1. The text is written and lives in the CMS. Not in the code, not in a document on a laptop. Every article is a real document in our CMS, with fields you can search in and edit without a deployment. It sounds like a detail. It’s the prerequisite for everything else: if the machine can’t find the text, it can’t use it.

2. Publishing triggers a message. The moment a page is published, the CMS sends a signal — signed, so the recipient can see it comes from us. We deliberately made this an opt-in per site: broberg.ai has it enabled, other sites don’t inherit it automatically.

3. The page lands in our knowledge base. Twenty seconds later, the finished page — not the raw text, but the page as a reader sees it — is fetched, stripped of human content, and uploaded to Trail, our shared memory. The wait isn’t wasted time: an article import publishes in batches, and the page must be fetched after the content is finalized. A system that fetches too early saves something half-finished.

4. The podcast engine creates a script. It reads the article and rewrites it into a conversation between two hosts. Here lies the house’s most important design choice: the script is a document, not an intermediate result. A script that goes straight into the studio is an episode no one has read. As a document, it can be opened, edited, and approved — and it’s also the subtitles, it’s searchable, and it can be read by someone who doesn’t want to listen.

5. Then it becomes sound. Two voices, one track, one file.

The one human link

Step four ends with an approval, and it’s not a formality. Recording is the only action in the entire system that costs real money every time it’s used — about five kroner per episode. That’s why the lock is on the server, not in the browser: a checkbox in a user interface is an agreement, a lock in the code is a rule. If you try to record a script no one has approved, you get a no and an explanation.

For the same reason, an editor can edit and approve scripts, but cannot press record. That’s a separate permission. Someone who can edit a text isn’t automatically someone who can spend the house’s money.

And if you edit the text afterward, the approval is automatically revoked. Not something you have to remember — that’s what turns the rule into a lock rather than an intention.

The hosts live in the CMS, not in the code

Aidan explains. Airina asks on behalf of the listener. How they do it — how cheerful, how interrupting, whether they’re allowed to laugh — is stored as plain text in the CMS. We can change the tone of the entire series by editing three fields, without deploying new code.

It turned out to be more than a convenience. The first version of the podcast was correct and a bit dull. We rewrote the three fields, asked for laughter where there was something to laugh about, and got a conversation where they interrupt each other. Same article, same voices, same price. Only the tone was new.

What the chain learned about us

Here’s where it gets honest.

When the entire process was run for the first time — from article to published episode — we found five errors that 1,625 automated tests had never caught. All the tests were green the whole way.

Two of them are worth knowing, because they share a pattern:

• The audio provider wasn’t even connected. The recording could never have worked — not even with a valid key. It wouldn’t have been discovered until someone pressed the button.
• The file’s address pointed to nothing. The sound was made, paid for, saved to disk, and the cost was recorded. Everything looked finished. And the one field a listener actually needs gave a 404.

It’s the same error pattern both times, and it’s the one we’re most aware of in everything we build: the green direction is the silent direction. A system missing something, and a system that’s in order, look the same from the outside. That’s why we run the chain end-to-end instead of just testing the parts individually. The parts were in order. The chain wasn’t.

What it costs

A five-and-a-half-minute episode costs about five kroner in audio — roughly one krone per minute. The script costs fractions of a øre. The price can be read before you press record, not after, and the system also saves what it actually cost, so the question can be answered a month later.

There’s a checklist before the studio: is there a script, are both voices selected, does the provider respond, and is the text approved? One of the items is worth highlighting, because it says something about how we build: if no one has enabled the voices yet, the item counts as not in order. A check that silently passes because no one asked is worse than no check at all — it looks green.

So what is this, really?

It’s an experiment, and we say it out loud. The podcast exists to show what AI and automation can be used for when real demands are set: real content, traceability back to the source, a price you can see in advance, and a human saying yes before the money is spent.

But the content isn’t an exercise. It’s our own products, our own customers, and our own opinions. The hosts are AI agents, and they don’t invent anything to make it sound good.

The first episode is about what you’ve just read.