Spotify’s AI Bet: What Makes an Agent Choose a Service?

By Lazar Milicevic · Published October 25, 2026 · 8 min read

You tried an AI assistant, got a useful answer, and still copied the result into three other tools. Spotify's latest strategy gives us a clean way to look at that gap, because it describes a world where software, not a person, picks which service finishes the job. Here's what Spotify actually said, what's verified, and the one check you can apply to your own operations today.

What Spotify said, and what it didn't

Spotify's co-CEO Gustav Söderström told investors that growth in AI agents should be a tailwind rather than a headwind, and that Spotify wants to be the media service people use from any agent. That's the news, per TechCrunch's report on the Q3 2026 earnings call.

His reasoning is worth reading closely. Agents are good at chores people want to hand off. Entertainment is the opposite: nobody asks an agent to "summarize a song." So the agent's job in music isn't to replace listening. It's to be the route to the right service.

Two things this does not establish:

• No adoption numbers. Söderström described "really good adoption" inside agents, but no figures for users, requests, or share of listening came with it. Treat it as management's claim, not a result.
• No selection criteria. Spotify has said it wants to be the service agents turn to. It has not published what makes an agent pick one service over another. Anything I say about that below is my inference from how the integrations are built, and I'll label it that way.

For context, the same call reported 788 million monthly active users and nearly €5 billion (about $5.6 billion) in revenue. That's the scale behind the bet, not evidence the bet has paid off.

How the integration is actually built

The interesting part for builders isn't the strategy. It's the plumbing, and it's public.

Spotify's integration with Claude launched on April 23, 2026. Free and Premium Spotify users can use it, and it's available globally to Free, Pro and Max Claude users on web, mobile and desktop. Premium users can describe a mood and get a tailored playlist, and Claude supports Spotify Connect so you can see where music is playing and switch devices.

Anthropic's connector listing is marked "Anthropic verified" and exposes a short, named list of tools:

create_playlist
get_currently_playing
search
add_to_library
fetch_tracks
Remove_from_library

That's six verbs. Not a sprawling API surface, just the actions an assistant needs to finish a music request. Spotify also integrates with ChatGPT and, per its own Form 6-K filing, with Meta's Muse, where listeners can ask their agent to play music, save songs to their Library, build personalized playlists, and find books and podcasts.

The ChatGPT side runs on OpenAI's Apps SDK, which is built on the Model Context Protocol (MCP). Spotify was among the initial partners, alongside Booking.com, Canva, Coursera, Expedia, Figma and Zillow.

Spotify also draws a clear division of labor. The partner assistant sends the request. Spotify processes it with its own systems and picks the audio. Per TokenPost's report, Spotify does not give partner agents access to listener data. And in Spotify's own words, it doesn't share its audio content with Anthropic for training, and users can disconnect at any time.

That boundary is the pattern to notice: the agent asks, the service decides and keeps its data.

What an agent can read: the tool definition

Here's where my inference starts, grounded in the spec. In MCP, an agent decides what a service can do by reading machine-readable tool definitions. Per the MCP specification, a tool has:

• a unique name
• an optional title
• a human-readable description
• an inputSchema (JSON Schema for the parameters)
• an optional outputSchema
• optional annotations

A minimal definition looks like this (illustrative, not Spotify's actual schema):

{
  "name": "create_crm_lead",
  "title": "Create CRM lead",
  "description": "Creates a lead record from a quote request. Returns the new record ID.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "email_id": { "type": "string" },
      "service": { "type": "string" },
      "contact_email": { "type": "string" }
    },
    "required": ["email_id", "service", "contact_email"]
  },
  "outputSchema": {
    "type": "object",
    "properties": { "record_id": { "type": "string" } },
    "required": ["record_id"]
  }
}

Notice the outputSchema. It's optional in the spec, but it's the field that lets a service promise what comes back. My read, and it is only a read: a service whose tools are clearly named, narrowly scoped, and honest about their outputs is easier for any agent to use correctly than one that isn't. Nobody has published a ranking algorithm, so don't treat this as a selection formula.

One more spec detail matters for trust: clients must treat tool annotations as untrusted unless they come from trusted servers. A tool saying "I'm read-only" is a claim, not a guarantee.

Who gets chosen, and who decides

If agents mediate requests, you'd want to know whether the choice is for sale. Anthropic addresses this directly. When two connectors could help with a request, Claude shows both, ranked by what's most useful to the user, and Anthropic says there are no paid placements or sponsored answers.

That's Anthropic's stated policy, which is as far as the evidence goes. It means "most useful to the user" is the stated ranking principle. For a service, usefulness is partly a product question and partly an integration question: can the agent complete the task and tell the user what happened?

Spotify's batch-mates tell the same story. It was one of 15 everyday-life connectors Anthropic shipped on April 23, 2026, alongside Audible, Uber, Instacart and Booking.com. In ChatGPT, users can summon apps by name, and ChatGPT can also suggest apps when they could help. So there are two routes to being used: being asked for by name, and being the obvious fit when the user hasn't named anything.

Söderström made a related point that's easy to miss. Agents will help people subscribe to the best music service, and Spotify, he said, never bets on users forgetting their subscription, so it should be the last one they cancel (Music Ally). If an agent can also cancel, loyalty gets tested continuously. That's a pressure small-business software will feel too.

The check that matters for your business: a completion receipt

Now the part you can use. Your problem usually isn't a shortage of apps. It's the handoff between Gmail, your CRM, accounting, and chat. Spotify's integration works partly because a request ends in something checkable: a playlist exists, a song is in your Library, music is playing on a device.

Your operations need the same property. Take an illustrative quote workflow (not a Spotify feature, not a client result): a prospect emails a request, an agent identifies the service they need, and the system prepares a CRM record and a reply for review.

Three different things happen there, and you should be able to see each one:

1. The model suggested a classification and drafted text.
2. The integration created a record.
3. A person approved the outgoing quote.

Now the failure case. The CRM write returns no record identifier. Did it fail? Did it succeed before the connection dropped? If the agent just retries, you get two leads and two follow-up sequences. A polished chat transcript won't tell you which.

The fix is a completion receipt, defined before you build anything:

And the rule that makes it work: check before you repeat.

def create_lead_once(email_id, payload, crm):
    # Look up by the source email first. This is the idempotency key.
    existing = crm.find_by_external_id(email_id)
    if existing:
        return {"status": "already_done", "record_id": existing.id}

    result = crm.create(external_id=email_id, **payload)
    if not result.get("id"):
        # No receipt. Do not retry; flag for a human.
        return {"status": "unconfirmed", "record_id": None}

    return {"status": "created", "record_id": result["id"]}

The pattern is simple: tag every write with the source email's ID, look up that ID before writing, and treat a missing record ID as "unknown," not "failed." That one lookup is what prevents the duplicate-lead problem.

If your CRM can't search by an external ID, that's your first finding. It tells you the integration can't safely be retried, which tells you how much autonomy to give it.

How to roll this out without over-trusting it

Pick one handoff you repeat every day and write its receipt on paper first. You don't need another platform to define what "finished" looks like. Then ask whoever builds your automation one question: can the system produce this receipt, including a clear failure state?

If the answer is no, narrow version one:

• Let the agent prepare the draft and drop it in a review queue.
• Add the CRM write only once you can confirm success and block duplicates.
• Add auto-send last, if ever, and only for low-stakes message types.

Scope the permissions to match. Spotify's connector exposes six named tools, not the whole platform. Do the same with your own agents: give each one the minimum verbs it needs, and keep the destructive ones (delete, remove, cancel) behind approval. Note that the Spotify list includes a remove action. Even a consumer music connector has one verb you'd want to watch.

My take: Spotify is asking a commercially important question. If agents increasingly mediate requests, being easy for those agents to use could become a distribution advantage. That's an inference from the strategy, not a proven outcome. The immediate lesson for you is smaller and more concrete: before paying for an agent that promises to handle everything, choose one task and define the proof that it finished.

Where bizflowai.io fits

I build AI automations at bizflowai.io, and this gap between Gmail, CRM, invoicing and chat is the kind of problem I work on. The approach I'd recommend, and the one I try to follow when scoping a workflow, is to define the receipt table early: review queues for drafts, writes tagged with a source ID so retries don't create duplicates, and an explicit failure state when a system doesn't confirm an action. Treat that as a recommended pattern for any builder, not a checklist of features you'll find in a particular product.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.