I Gave an AI Worker a YouTube Channel. Then I Tried to Leave.

There is a strange moment in content creation when you finish making something — and realize you’re nowhere near finished.

The video is done.
Great.
Now upload it.

Write the title. Write the description. Add the thumbnail. Captions. Playlist. Publishing settings. Schedule it.

Then come back later and make sure everything actually worked.

At some point I found myself asking a wonderfully boring question:

What if “finished making the video” actually meant finished?

Finish the video.
Put it in the right place.
Walk away.

That’s what started this experiment.

But somewhere between giving an AI worker its own Google identity, fencing OAuth credentials on my computer, uploading a five-second test video, and building a second worker whose only job is to check whether the first one actually did what it said it did… I realized I was testing something else too.

Where does an AI worker actually live?

It started with a book

I’ve been working on a content-production suite called The Quiet Scribe, built by The Quiet AI.

A nonfiction book has been my model for what I think of as the “ultimate content.”

Not because a book is necessarily the ultimate format, but because making one properly requires almost everything.

Research. Writing. Editing. Organization. Design. Voice. Fact-checking.

And then, once the book exists, it naturally begins producing other things. Articles. Posts. Videos. A website. Marketing material. Far more than just “writing a book.”

That made it an interesting problem to build around. So The Quiet Scribe grew into a suite of specialized workers designed to help with different parts of that production process.

Eventually, the suite started making videos. Which created another problem.

Someone still had to upload them.

So I gave the Scribe a YouTube channel

My first thought wasn’t particularly profound. The Quiet Scribe is making videos. Give it its own YouTube channel. Then automate the upload.

I started researching how other people were approaching this, and quickly discovered there’s already a lot of really interesting work happening around YouTube automation. People are using Claude Code to build publishing workflows. Developers have built MCP servers that give models access to YouTube operations. There are upload agents, content pipelines and systems connecting AI-generated metadata to the YouTube API.

David Quintanilla at Zapier, for example, documented using Claude Code to build a self-service YouTube uploader after years of personally handling upload requests. There are open-source YouTube MCP projects exposing uploads, metadata, thumbnails, playlists and analytics directly to AI systems. Some projects go much further and attempt to automate large portions of the entire YouTube production pipeline.

So this wasn’t a case of nobody has figured out how to let AI upload to YouTube. They have. There is good work here, and quite a lot I could learn from.

But as I looked through the different approaches, I became interested in doing something slightly differently.

I didn’t want to send the worker away

The videos were already sitting on my computer. The context that created them was there. The rules were there. The other workers were there. Why move the operational system somewhere else just so it could eventually come back and deal with those files?

I wanted the worker to live locally, where the content already lives.

The videos stay on the computer. The operating context stays there. The rules, state, briefs and receipts stay there. Credentials are fenced locally. The system only reaches outward when it actually needs YouTube or Gmail.

That gave me an important distinction: local environment doesn’t necessarily mean local model.

Claude can still provide the reasoning. But Claude doesn’t have to be the environment. VS Code isn’t the worker either. It’s simply one way of giving a capable model access to that environment. The persistent part is sitting there on disk.

And that’s when this stopped being only a YouTube experiment for me.

Before it could have hands, it needed an identity

There was another problem. Whose YouTube channel is the worker operating? Whose Gmail? Whose credentials?

A lot of convenient AI integrations inherit the identity of whoever connected them. That’s fine if the AI is acting as you. But The Quiet Scribe isn’t me. It’s a brand.

If I wanted to see whether a worker could actually manage part of that brand’s operation, I didn’t want it borrowing my identity to do it.

So The Quiet Scribe got its own Google identity. Its own Gmail. Its own YouTube channel. The channel became a Brand Account. It got its own Google Cloud project. Its own OAuth authorization. And its live credentials are fenced locally rather than sitting in the project folder.

None of this is particularly sexy. That’s partly the point. The eventual experience should feel simple because the boring infrastructure underneath it has been handled properly.

Before building the worker, I tried to kill it

This became one of the rules of the experiment: find the cheapest question that could prove the whole idea wrong, and ask it first.

There was no point spending days building an elegant publishing worker if some Google or YouTube restriction was going to make the intended experience impossible. So I started knocking down the questions.

Could the Scribe authenticate independently? Could it authorize the correct Brand Account rather than accidentally publishing to my personal channel? Could its credentials persist locally? Could it access the channel features we’d eventually need? Did the channel identity survive conversion to a Brand Account? Yes, on every count.

Then came the one I was particularly interested in.

Would YouTube actually let it publish publicly?

There are API compliance restrictions that can affect whether uploads from certain projects can be made public. If our test got forced to private, the project wouldn’t necessarily fail. But the experience would change.

Instead of finish the video, put it down, walk away, we might have finish the video, the Scribe prepares everything, you make the final publishing click. Still useful — but different.

So rather than architect around an assumption, I made a five-second throwaway video. Nothing valuable. Nothing that mattered. Just the cheapest object I could use to ask YouTube the question.

The API request explicitly asked for: PUBLIC. And I sent it.

The cheapest question

The API request explicitly asked for PUBLIC. It landed on the channel. Public there too.

✓ Public.

It landed on The Quiet Scribe’s channel. Correct Google identity. Correct Brand Account. Correct video. Public.

And then, importantly, I checked YouTube Studio. I didn’t want the API response telling me everything had worked. I wanted YouTube itself telling me what actually existed. Public there too.

Then I deleted the five-second video. It was absolutely terrible content. And one of the more satisfying uploads I’ve made. Because now I knew the rest of the experiment was worth building.

Giving it hands is the easy part

Here’s where the architecture started becoming more interesting. I could simply tell Claude: upload this video to YouTube. And give it enough tools to figure out the rest.

But I don’t actually want that.

The intelligent part should do the things that require intelligence. It should understand the content. The brand. The audience. The voice. The purpose of the video. The series it belongs to. The publishing methodology.

From that, it can create a publishing brief. The brief can say: this is the title, this is the description, use this thumbnail, these are the captions, this is the playlist, this is the audience declaration, publish at this time, use these settings.

Then something much less exciting should happen. The uploader reads the brief and does what it’s told. It validates the files. Uploads the video. Applies the metadata. Writes down what happened. That’s it.

The uploader doesn’t need to decide. It needs to execute.

That distinction is becoming important to the way I think about these systems. Because now I can potentially change the reasoning model without changing the uploader. I can change the uploader without changing the methodology. I can change how YouTube is accessed without changing the operating context that knows what should happen. The pieces aren’t pretending to be intelligent when they don’t need to be.

I also don’t trust “Upload successful”

This may be my favorite part of the build. An API returning success does not mean the job succeeded. It means an API call succeeded. Those aren’t the same thing.

Did the video finish processing? Did the requested privacy setting actually stick? Did the thumbnail arrive? Did the captions attach? Did it enter the correct playlist? Did YouTube place a restriction on it? Did what we intended become what actually exists?

So the uploader doesn’t get to grade its own homework. I’m building a separate verifier. It comes back later. It reads the original publishing brief. It reads the receipt from the upload. Then it looks at YouTube. And compares them.

Intent versus reality.

If everything matches, great. If it doesn’t, I don’t want something went wrong. I want thumbnail missing. Or requested PUBLIC, actual state PRIVATE. Or captions weren’t attached.

That’s a subtle difference, but I think it’s an important one. Anyone can make the upload happen. I’m interested in whether I can make the result trustworthy enough that I don’t have to keep checking it myself.

Which brings me to leaving

The final experience I’m trying to create should hide almost everything I’ve just described. Nobody making a video wakes up excited about OAuth scopes. Nobody wants a beautifully engineered refresh-token strategy. Nobody is hoping to spend their afternoon thinking about API calls, receipts, Brand Account authorization and independent verification.

The reason for doing all of that work is to make the human experience almost stupidly simple: finish the video, put it in the right place, walk away.

The Quiet Scribe can work on creating the content. The Quiet AI can work on removing the machinery that still stands between “the content is finished” and “the content is out in the world.” If we’re doing that properly, the user should experience less technology, not more. Which means eventually I have to remove myself from the test.

And that’s where I started questioning the word “agent”

While building all this, something started bothering me. What part of this system is actually the agent? Because Claude doesn’t have to persist.

The context does. The methodology does. The state does. The tools do.

The credentials persist. The queue persists. The briefs persist. The receipts persist. The history of what happened persists.

A capable model can enter that environment when intelligence is required, understand the role, perform the work, use the tools and leave. Another capable model could theoretically enter that same environment later.

So where does the worker live? In Claude? In the Python? In the folders? In the methodology? In the combination? And YouTube has accidentally turned into a wonderful test environment for that question — because there is nowhere for the AI to hide behind a convincing response. The correct video either appears on the correct channel in the correct state… or it doesn’t.

Now I’m trying to leave

That’s where the experiment is today. The identity works. The credentials work. The correct Brand Account works. The first API upload worked. The requested public state worked.

Now I’m building the next layers: publishing brief → uploader → receipt → independent verifier → reporter.

And then comes the test I’ve actually been working toward. One real video. Finished. Put it into the queue. Close the laptop. Walk away. Later, check the phone.

Is the video there? Is it public? Is the metadata correct? Did the thumbnail, captions and playlist arrive? Did the verifier independently confirm what happened? Did The Quiet Scribe report back?

And, most importantly: did I have to manage any of it?

That’s the experiment. Not whether AI can upload something to YouTube. We already know it can. I’m trying to find out whether the system can become reliable enough that uploading to YouTube effectively disappears from the experience of making content.

If the unattended test works, I’ll publish exactly what happened. If it fails, I’ll publish that too.

And once we’ve tried hard enough to break the local worker ourselves, The Quiet AI plans to release the build so other people can experiment with it — and, hopefully, find all the things we missed. The capability will also become part of the larger Quiet Scribe workflow.

Because ultimately, I don’t particularly care whether we decide to call this an agent, an ICM worker, an automation, or a slightly over-engineered collection of folders and Python scripts.

I’m interested in the moment when someone finishes making something, puts it down and realizes: oh, I’m actually finished. And maybe in figuring out where the thing that made that possible actually lives.

Or maybe I just have too much time on my hands.