This is part two of Agentic Operating System For Your Business. Part one began with the Chief Agentic Officer Briefing and the question of whether a newsletter could become a real agentic business. This instalment follows one practical role, podcast publishing, until it reaches a very human gate.

The podcast was the easy bit.

We could take one of my articles, turn it into a short audio companion, create the file, prepare the title and description, and add it to a feed.

Then we tried to publish it properly.

That was where the agentic future met an upload button.

In the route we were using, Spotify still required a human to go into its creator interface, select the audio file, complete the episode details, and publish it. We had an RSS feed, but the path we needed still involved code, manual setup, and limits around the way monetisation worked. Spotify has an API, but its public Web API is built mainly around Spotify catalogue data, playback, playlists, libraries, and user-authorised features. It does not expose the creator episode-upload workflow we needed.

So yes, we got it working.

But it made me ask a much bigger question.

Why are so many platforms still designed as though a human clicking through a browser is the only legitimate way to work?

Why I wanted the podcast in the first place

I am not trying to pretend that I sat in a studio and recorded every episode.

I did not.

The ideas are mine. The articles are mine. The audio is created from that work using a synthetic voice, and I want that to be clear.

The reason is very simple: when I go to the gym in the morning, I would often rather listen than read. A three- or four-minute audio version lets me hear the idea, notice where it does not quite land, and think about it while I am moving.

Hopefully, other people will find that useful too.

We will also have a human-led weekly podcast. That is a different thing: a longer conversation, reflection, and discussion. The short audio companion is not replacing that. It is another format for the same thinking.

This is exactly the kind of bounded role I am trying to build while creating an agentic business. Not one enormous agent that does everything. A set of carefully designed workers, each with a purpose, a workflow, authority, boundaries, and a review point.

The platform is not actually closed

Spotify's official creator documentation makes an important distinction.

If Spotify hosts your show, you can upload and publish audio through Spotify for Creators. Once the first episode is published, Spotify creates an RSS feed. If another provider hosts the podcast, you can use its RSS feed to submit or claim the show on Spotify.

So this is not a story about Spotify refusing podcasts or refusing RSS.

It is a story about the operational gap between those human-facing routes and an agent-ready publishing interface.

The public developer interface lets an application authenticate through OAuth and work with defined scopes. That is good. But there is no equivalent public creator scope that says:

  • upload this approved audio file;
  • create a draft episode;
  • add this title, description, artwork, and disclosure;
  • ask the authorised human to approve publication;
  • publish at an agreed time;
  • return an auditable receipt.

That is the missing bit.

Agents look uncomfortably like attackers

I understand why platforms are cautious.

For the last couple of decades, teams have worked hard to stop automated abuse. Bots try pages quickly. They fill in forms. They upload files. They follow links. They repeat actions. They do not behave like a patient human moving a mouse around a screen.

A legitimate agent can have exactly the same technical footprint.

If a platform cannot tell the difference between an authorised agent representing me and a hostile script trying to exploit it, blocking both can look like the safest option.

But that cannot be the final answer.

Making me click the upload button myself is not strong security. It is a speed bump. A malicious person can click a button too. A sophisticated attacker can automate a browser.

The real security question is not, "Was there a human finger on a mouse?"

It is:

  • Who is this?
  • Whom are they representing?
  • What authority have they been given?
  • What exactly are they allowed to do?
  • Which actions require another approval?
  • What evidence and record will remain?
  • How can that authority be revoked?
  • Who is accountable when something goes wrong?

An API would be a start. An agent-ready interface would be better

Come on. At least give us a proper creator API.

An MCP interface could then make that capability easier for agents to discover and use consistently. But an MCP on its own is not the answer either. It still needs a secure service beneath it.

For podcast publishing, I would want that service to support a very small set of explicit permissions:

Permission What the agent may do Human boundary
Read show Read approved show settings, episodes, and publishing requirements. No change authority.
Create draft Upload an approved file and prepare metadata as a draft. Cannot make the episode public.
Request approval Present the audio, metadata, disclosure, and planned date for review. A named person decides.
Publish approved Publish only the exact approved version at the agreed time. Material changes require fresh approval.
Correct or withdraw Prepare a correction or takedown request. High-impact action follows an agreed stop-line.

The platform should also record the identity represented, the authorised account, the agent or application used, the exact version of the file and metadata, the approval, the publication result, and any later correction.

That is not weaker than manual publishing.

Done properly, it is stronger.

You cannot rush an agentic business

This small podcast job reminded me of something important.

People talk about creating an agentic company as though you install a few agents on Monday and have a digital workforce by Friday.

You do not.

Each role has to be thought through properly.

What is the job?

What does good look like?

What information does the worker need?

What can it read?

What can it change?

What must it propose before acting?

What are the guardrails?

What happens when the platform fails, the upload is rejected, the metadata is wrong, or the agent does not know what to do next?

Who is responsible?

That work takes time because it is not merely automation. It is role design, operating design, identity, governance, and accountability.

The next bottleneck is permission

We have reached a slightly odd moment.

The models can write the script. The voice system can produce the audio. The workflow can prepare the metadata. The feed can carry the episode.

Then a human has to appear because the final platform was never designed to recognise delegated agent authority.

That is going to happen across more than podcasting.

Publishing, banking, procurement, social networks, customer systems, government services, and workplace tools will all need a better answer to the same question:

How does an agent prove who it represents, what it is allowed to do, and where human responsibility begins?

The platforms that solve that well will become part of the agentic operating system.

The ones that do not will become manual bottlenecks.

We got the podcast published.

Now I want the publishing route to catch up with the way the work is actually being created.

In this series

This is part two of Agentic Operating System For Your Business, my field notes from building the Chief Agentic Officer Briefing as a real agentic business.

Read part one: Chief Agentic Officer Briefing: Creating An Agentic Business

Sources and notes

This article describes my experience with the publishing route we used. Spotify's available features vary by hosting choice, account, region, eligibility, and product changes. Its official documentation confirms browser/app episode publishing for Spotify-hosted shows, RSS submission and claiming for externally hosted shows, eligibility-based monetisation, OAuth authorisation for the public Web API, and the current public API's catalogue and user-feature focus.