Radio automation with human approval: what agents should—and should not—put on air

Automation is already part of internet radio. A scheduler starts a programme at the right time. AutoDJ fills an empty hour. A stream monitor notices that a live source has gone away. None of that requires a language model.

AI agents change a different part of the workflow: they can turn an operator’s intent into structured work. An operator can describe a two-hour soul programme, ask for a clean transition into a live show, or request an explanation of tomorrow’s schedule gaps. The agent can inspect state, assemble a proposal and explain its choices.

The dangerous leap is treating “can prepare” as “may publish.”

A capable radio agent should be easy to ask, constrained in what it can see, explicit about what it changed and unable to put consequential work on air silently.

That is the operating model behind SGNL Desk’s phrase AI-native, human controlled.

Divide the workflow by consequence

Approval design becomes clearer when actions are grouped by their effect rather than by the screen on which they appear.

Inspection should be easy

Read-only work is generally the safest place for an agent to begin:

inspect current and upcoming programming;
identify schedule gaps or overlapping programmes;
find media using titles, artists, tags or duration;
explain why AutoDJ is not ready;
review live-source and listener-delivery health;
compare the current plan with published product limits;
summarise recent operational events.

Inspection still needs permission boundaries. A presenter should not gain access to another organisation merely because an assistant can call a tool. The server remains responsible for deciding which workspace, stations and resources the signed-in identity may see.

Preparation should create a reviewable draft

The next class of work changes data without changing the station’s public output:

draft a playlist;
prepare a programme slot;
suggest rotations or separation rules;
assemble a migration checklist;
write a station description;
propose changes to a weekly schedule.

The output should be visible as a draft with the agent’s assumptions attached. “Created 18 playlist items” is less useful than “Prepared an 18-track draft for Friday 18:00, excluded explicit tracks and kept the same artist at least 60 minutes apart.”

A reviewer needs enough context to decide whether the result matches the brief.

Publication deserves a deliberate decision

Publishing a schedule changes what listeners will hear. Other actions can be even more consequential:

deleting media;
replacing a live source;
rotating connection credentials;
changing billing;
inviting or removing team members;
transferring ownership;
deleting a station or workspace.

These actions should require the appropriate authenticated role and a clear operator-controlled step. The confirmation should name the effect, target and timing. A vague “Are you sure?” is not sufficient when the real action is “Publish 14 programme changes to Soulfinity Radio beginning Monday.”

Approval is more than a confirmation dialog

A trustworthy approval flow has four parts.

1. The proposal is specific

The review surface should identify:

the station and workspace;
every object that will change;
the current value and proposed value;
when the change takes effect;
whether the action is reversible;
any unresolved warning.

An agent should not hide a partial result behind confident language. If three requested tracks are missing, the draft should say so before publication.

2. The server checks authority again

Agent tools are an interface, not a security boundary. When an approved action reaches the server, the server must re-check the current identity, role, workspace membership and object scope.

This matters because state can change between preparation and approval. A team member may have lost a role. A programme may have been edited by somebody else. A subscription may no longer allow the requested capacity. The final write cannot rely on permission data cached when the draft began.

3. The result is attributable

An audit record should distinguish:

who asked for the work;
which agent or client prepared it;
who approved it;
what the server accepted;
when it happened;
whether it was later reversed.

This is not only for investigations. Attribution helps a team understand how the station is being operated and which repeated tasks may deserve a better workflow.

4. Recovery is designed before publication

Schedules should have versions. Credentials should be rotatable. Drafts should not overwrite the last working state without a recovery path.

Some actions cannot be meaningfully undone. Permanent deletion is the obvious example. Those actions deserve stronger authentication, a narrower role and more explicit language than an ordinary publish step.

Browser agents and remote agents need the same policy

WebMCP and server MCP solve different access problems.

A browser agent can use declared tools on an open SGNL page instead of guessing which button to press. A remote assistant can use an authenticated MCP connection without keeping the marketing site or Desk open. The interfaces differ, but they should not invent separate permission models.

Both should rely on the same:

organisation and station boundaries;
roles;
draft and publication states;
confirmation rules;
audit events;
server-side validation.

The browser API must not widen a role. The remote MCP token must not become a master key. A tool name such as publish_schedule is only a structured request; the server still decides whether that request is allowed.

A practical first automation

Start with one workflow that is frequent, reviewable and recoverable.

For example:

Ask the agent to inspect next week’s schedule.
Have it identify empty periods and programmes missing enough media.
Let it draft fixes without publishing.
Review the affected hours and the media-selection assumptions.
Publish through the normal approval path.
Verify the resulting schedule and retain the previous version.

This teaches the team how an agent communicates uncertainty before higher-risk tools are introduced.

The standard should be boring confidence

The best agent-assisted radio workflow is not impressive because it moves quickly. It is impressive because operators always know what is about to happen.

Inspection can be conversational. Preparation can be fast. Publication should be deliberate. Permissions should remain server-side, and the audit trail should make the work understandable after the fact.

That is how an assistant becomes part of the desk without becoming the person in charge of the station.