Not the Content AI Makes: the Company AI Runs

That AI writes music and makes video is no longer news. Anyone in the industry has tried it and has a rough sense of where it works and where it stops. So a piece that opens with "AI makes content" gives you no reason to keep reading.

The change quietly underway is somewhere else. AI has started doing company work, not content. Entering release metadata, uploading to each platform, pulling together royalty data, catching pirated uploads. The tasks that actually fill an agency staffer's day. In global tech this year, the money and talent are flowing here too, to what people call agents, rather than to generative models.

Yet the entertainment industry still sees this shift only through a content lens. It asks "will AI replace creative work" endlessly but rarely asks "can we hand AI our operations." Even though an agency's day is filled more with operations than with creation. So this report is about that.

An agent is not a chatbot

First, the term. An agent is not a chatbot that answers questions. Give it a goal and it works through a multi-step job, handling tools directly: a browser, files, spreadsheets, external platform APIs. Tell it "take this single's release info, format it to each platform's spec, and post it," and it opens the file, checks the spec, fills the form, and reports back when something breaks.

A chatbot is fine if the answer is good, but an agent only has value when the work actually gets done. And for work to get done, a smart model is not enough. This is where demos and real operations diverge, which we come back to later.

What you can hand off

Split agency work along two questions and a picture appears. How often does the task repeat? Can it be judged by rules you can write down, or does it need relationships and feel?

The first thing you can hand off is repetitive, rule-bound work. Release-metadata entry and checking, per-platform uploads and distribution, royalty aggregation and reconciliation, piracy monitoring, gathering covers and reaction videos. These already have rules. Platform specs exist; royalty formats exist. People have done them until now not because judgment was hard but because there was nowhere to hand them.

Next is repetitive work with light judgment mixed in. First-pass fan-inquiry triage, first-pass community moderation, first-pass demo and application screening, social performance reporting. All four carry "first pass." The agent doesn't finish them; it sorts what a person needs to see from what they don't, pushing human time toward the calls that need it.

Some work clearly should not be handed off. Artist relationships, final casting calls, creative direction, crisis response. Here the basis for judgment is relationship and context, not rules, and above all, a mistake can't be undone. It's off-limits not because an agent can't do it but because accountability doesn't hold.

Framed this way, the question changes. Instead of "will AI replace A&R," ask "can it take back the three hours A&R spends on screening." Adopting agents is less about replacing people than about moving their time.

Taking the stack apart

The agent stack has three layers. The model that reads the situation and decides the next move; the orchestration that breaks a big job into steps, manages the order, and retries on failure; and the tool connections that actually operate systems. Driving a browser, calling an API, reading and writing files is that last layer.

Build one and you learn something fast. The model is what stands out in a demo, but the two lower layers decide real operations. It's easy enough for the model to judge "this release info goes in this form." The hard part is actually connecting to the system that holds the form, filtering out artwork that fails the spec, retrying sensibly when the server doesn't respond, and, when it still fails, reporting to a person exactly how far it got and where it stuck. Most of the operating cost comes from here.

There's one decision that matters most in the design: where to put human approval. Let the agent handle reversible work on its own, and always put human approval in front of the irreversible, meaning outbound publishing, payments, or replies that go to fans. Too many approval points and automation is pointless; too few and accidents happen. Whether an agent rollout succeeds or fails usually turns on this approval design, not on model choice.

Where to borrow the model and where to run the agent

From here it's technical choices. Start with what you must decide: where to get the model that does the judging, where to run the agent itself, and how to connect to company systems.

Model. The options split between using a frontier model like Claude or GPT through an API, and running an open-source model on your own GPUs. The bottom line: for a small agency the default is the API. Agent work has to judge its way through many steps on its own, so a small drop in model intelligence and it loses the thread mid-task, and models small enough to run locally don't yet hit that reliability. Add the cost of buying and managing GPUs and, at small scale, the API bill is far cheaper. The exception is high-volume repetition. For work that's simple to judge but large in quantity, like scanning thousands of comments or videos, a small cheap model is enough, so a two-tier setup is common in practice: judgment on the frontier API, bulk filtering on the low-cost model.

Where it runs. The agent itself, meaning where the orchestration and tool connections live, is a separate choice from the model. Broadly it splits into self-hosting on a personal PC, a cloud server, and a managed service someone else runs.

People often ask whether they can use the much-discussed OpenClaw-type self-hosted agent, the kind you keep resident on your machine and drive over a messenger, for company work. As a personal productivity tool it's excellent. For work that stays on your side even when it goes wrong, like research, scraping, and drafting, it's already good. Company work is another matter. This category is a personal-assistant design where one process holds broad permissions, so to attach it to work that touches royalty data and artist accounts you have to build permission separation and audit logs yourself. A company capable of that reinforcement is better off putting it on the cloud properly in the first place.

Self-hosting's weak spot doesn't only come from something grand like security. At one company running an agent on an office Mac mini, a staffer tidying up their desk moved the box and pulled the plug, and the chatbot and agent died wholesale. You can't run company work on a system whose failure mode is "power cord unplugged."

So the default for company work is a cloud server. The agent on the cloud, every action logged, account permissions split by task. The approval gate above rides on top of this. A team with no developers at all is safer piloting with a built-in agent inside a collaboration tool they already use, or a managed service, and moving to their own setup only after the work is proven.

Connection. What really trips up entertainment automation is not the model but systems without APIs. Distributor admins, royalty portals, and many fan communities are web screens with no API. An agent attaches to these by operating a browser like a human, which is slower than an API call and breaks when the screen changes. So automate the systems that have APIs first, and for the browser-only ones, build a way to notice when they break. Tool-connection standards are converging on MCP, so if you're building new now, aligning to MCP makes it easier to switch later.

Data. Start by settling whether unreleased tracks, artist personal data, and royalty records may leave through an external model API. Major vendors offer, by contract, terms that keep your input out of model training, so check and use them; the common hole is elsewhere. Staff uploading royalty files to personal chatbot accounts to summarize is already happening all over. Not opening a proper channel through a company account and API is itself a security hole. The same goes for the accounts you give the agent. Don't hand over a human's account; make a separate one scoped to just the task's range, and keep a record of what it did.

Know what doesn't work first

If you've read this far and want to adopt right away, look at what doesn't work first. This is really the most important part of the piece.

One, agents fail confidently. The dangerous kind is the quiet error, not the loud one. One wrong composer name, one wrong split percentage, and no one notices at input. It blows up months later at royalty time. So automation without a verification step is debt, not efficiency. You're only done when you've built a way to re-check what the agent did by another method.

Two, work facing fans directly is still too early. From a fan's side, they aren't talking to a support rep, they're talking to "our artist's company." One off-tone reply is a brand incident, not a CS slip, and it gets screenshotted and passed around. In fan-facing work, what an agent can do is triage and drafts, not replies.

Three, exceptions eat all the time. Even if 80% of the work is automated, if human time all goes into handling the remaining 20% of exceptions, total time doesn't drop. This is the most underrated part of agent design. Not doing the job well, but handing off what it can't do well. A system that can't pass along exactly how far it tried and where it stuck ends up making a person re-check everything from the start.

Four, rights information lives outside documents. A lot of entertainment work runs through rights checks, and that information isn't only in contracts and systems. It's in custom, in verbal agreements, in someone's memory. An agent only knows what's documented. To automate rights-bound work you first have to document the rights, and honestly, at many companies that's the real bottleneck.

Five, platforms don't welcome agents. Instagram or TikTok, social platforms detect automated operation and penalize accounts. Testing posting automation and getting an account blocked really does happen. For an agency, the official account is the channel where they meet fans, so a suspension is a heavier incident than a data one. Recovery is impossible or slow. It is, literally, something you can't undo. So automate publishing only when the platform has opened an official API path, and run browser-posting experiments only on an account fully separated from the main one.

In short, whether an agent rollout succeeds turns on work design, not model performance. And work design can only be done by someone who knows the work.

Small agencies before the majors

The received wisdom was that automation pays off more the larger the organization. Agents flip that.

Majors are already divided up and digitized. There's a separate royalty team and a separate release owner. Drop an agent in and what you save is part of one department's payroll. It matters, but the structure doesn't change.

Korean small agencies are different. One person does marketing and royalties and support and release. In that structure, what an agent does isn't headcount reduction. It lifts a few of the tasks one person was carrying alone. When someone who did five jobs gets to focus on two, that's less cost-cutting than a change in org structure, because the same headcount can now run more artists and more releases. The effect lands hardest where the hands are tightest.

The problem is small agencies have no one to design this. A major can hire a team and bring it in house; a small agency can't. The general-purpose AI talent the industry is training will keep growing, but designers who know the entertainment domain, meaning rights structures and fan culture and platform habits, won't grow at that pace. Tools get common while design stays scarce. For a while this gap is the bottleneck, and flipped around, it's the opening for whoever moves first.

What to settle before adopting

If you're weighing adoption, approach it in this order.

First, pick one task. Work where a mistake ends in rework, not an incident; work that repeats weekly or more; work whose rules are documented well enough to hand a new hire as a manual. It has to satisfy all three. If no such task exists, documenting the work comes before adopting an agent.

Don't set the success metric as "how many people were cut." A rollout that starts that way dies against organizational resistance. Look instead at how many hours in a person's week moved from what to what. From screening to artist communication, from data entry to campaign planning. The time that moved is the result.

A pilot of three months is enough. Hand one task to the agent, log every action, and measure the share that comes back to a person. If that share is trending down, push the approval point one step later; if it isn't, that task isn't ready yet.

For budget, set the structure before the number. Cost splits into the design work of first breaking down the task and wiring up systems, the monthly model usage fee, and the human time to watch the agent and handle exceptions. The most underestimated of these is the last. The model fee is easy to predict, scaling with volume, while human time on exceptions swings several-fold with design quality. Concrete numbers vary by task, so there's no point writing them here; instead keep one ceiling in mind. If the pilot's total cost exceeds what it would cost to just keep having people do the task, you picked the wrong task or the design is wrong.

Whether to build in house or outsource depends on the nature of the work. If it's tied to your own proprietary process, it's worth building in house; if it's industry-common work, taking the design from outside and running it in house is faster. Either way, it fails if someone who knows the work doesn't take part in the design. There's no exception to that.

If you're taking the design from outside, you need an eye for choosing. Instead of asking for a demo, ask for failure stories. The one that answers "what doesn't work" with a concrete incident right away is the one that has actually run operations. Ask to see the approval gates and the action logs on screen. If there's nothing to show, it's a demo system. Finally, ask how they guard the points you can't undo, like social accounts or royalties. A vendor without solid answers to those three questions isn't one to sign with.

If generative AI was a technology that changed content, the agent is one that changes how a company runs. Which is why this decision belongs to leadership, not the creative team. The company that moves first won't just save cost; it will be first to hold a structure that runs more artists on the same headcount.