Category: Tygart Media Editorial

The Pipeline That Outgrew Its Home

It started in a Google Sheet. A simple Apps Script that called Gemini, generated an article, and pushed it to WordPress via the REST API. It worked beautifully — for about three months. Then the volume increased, the content got more complex, the optimization requirements multiplied, and suddenly I was running a production content pipeline inside a spreadsheet.

Google Apps Script has a six-minute execution limit. My pipeline was hitting it on every run. The script would timeout mid-publish, leaving half-written articles in WordPress and orphaned rows in the Sheet. I was spending more time debugging the pipeline than using it.

The migration to Cloud Run was not optional. It was survival.

What the Original Pipeline Did

The Apps Script pipeline was elegantly simple. A Google Sheet held rows of keyword targets, each with a topic, a target site, and a content brief. The script would iterate through rows marked “ready,” call Gemini via the Vertex AI API to generate an article, format it as HTML, add SEO metadata, and publish it to WordPress using the REST API with Application Password authentication.

It also logged results back to the Sheet — post ID, publish date, word count, and status. This gave me a running ledger of every article the pipeline had ever produced. At its peak, the Sheet had over 300 rows spanning eight different WordPress sites.

The problem was not the logic. The logic was sound. The problem was the execution environment. Apps Script was never designed to run content pipelines that make multiple API calls, process large text payloads, and handle error recovery across external services.

The Cloud Run Architecture

The new pipeline runs on Google Cloud Run as a containerized service. It is triggered by a Cloud Scheduler cron job or by manual invocation through the proxy. The container pulls the content queue from Notion (replacing the Google Sheet), generates articles through the Vertex AI API, optimizes them through the SEO/AEO/GEO framework, and publishes through the WordPress proxy.

The key architectural change was moving from synchronous to asynchronous processing. Apps Script runs everything in sequence — one article at a time, blocking on each API call. Cloud Run processes articles in parallel, with independent error handling for each one. If article three fails, articles four through fifteen still publish successfully.

Error recovery was the other major upgrade. Apps Script has no retry logic beyond what you manually code into try-catch blocks. Cloud Run has built-in retry policies, dead letter queues, and structured logging. When something fails, I know exactly what failed, why, and whether it recovered on retry.

The Migration Strategy

I did not do a big-bang migration. I ran both systems in parallel for two weeks. The Apps Script pipeline continued handling three low-volume sites while I migrated the high-volume sites to Cloud Run one at a time. Each migration followed the same pattern: verify credentials on the new system, publish one test article, compare the output to an Apps Script article from the same site, and then switch over.

The parallel period caught three bugs that would have caused data loss in a direct cutover. One was a character encoding issue where Cloud Run’s UTF-8 handling differed from Apps Script’s. Another was a timezone mismatch in the publish timestamps. The third was a subtle difference in how the two systems handled WordPress category IDs.

Every bug was caught because I had a production comparison running side by side. This is the only safe way to migrate a content pipeline: never trust the new system until it proves itself against the old one.

What Changed After Migration

Publishing speed went from 45 minutes for a batch of ten articles to under eight minutes. Error rate dropped from roughly 15 percent (mostly timeouts) to under 2 percent. And the pipeline now handles 18 sites without modification — the same container, the same code, different credential sets pulled from the site registry.

The biggest win was not speed. It was confidence. With Apps Script, every batch run was a gamble. Would it timeout? Would it leave orphaned posts? Would the Sheet get corrupted? With Cloud Run, I trigger the pipeline and walk away. It either succeeds completely or fails cleanly with a detailed error log.

Lessons for Anyone Running Production Pipelines in Spreadsheets

First: if your spreadsheet pipeline takes more than 60 seconds to run, it is already too big for a spreadsheet. Start planning the migration now, not when it breaks.

Second: always run parallel before cutting over. The bugs you catch in parallel mode are the bugs that would have cost you data in production.

Third: structured logging is not optional. When your pipeline publishes to external services, you need to know exactly what happened on every run. Spreadsheet logs are fragile. Cloud logging is permanent and searchable.

Fourth: the migration is an opportunity to fix everything you tolerated in the original system. Do not just port the code. Redesign the architecture for the new environment.

FAQ

How much does Cloud Run cost compared to Apps Script?
Apps Script is free but limited. Cloud Run costs roughly -30 per month at my volume, which is negligible compared to the time saved from fewer failures and faster execution.

Do you still use Google Sheets anywhere in the pipeline?
No. Notion replaced the Sheet as the content queue. The Sheet was a good prototype but a poor production database.

How long did the full migration take?
Three weeks from first Cloud Run deployment to full cutover. The parallel running period was the longest phase.

{
“@context”: “https://schema.org”,
“@type”: “Article”,
“headline”: “From Google Apps Script to Cloud Run: Migrating a Content Pipeline Without Breaking Production”,
“description”: “The real story of migrating a Gemini-to-WordPress publishing pipeline from Google Sheets to GCP Cloud Run without losing a single article.”,
“datePublished”: “2026-03-21”,
“dateModified”: “2026-04-03”,
“author”: {
“@type”: “Person”,
“name”: “Will Tygart”,
“url”: “https://tygartmedia.com/about”
},
“publisher”: {
“@type”: “Organization”,
“name”: “Tygart Media”,
“url”: “https://tygartmedia.com”,
“logo”: {
“@type”: “ImageObject”,
“url”: “https://tygartmedia.com/wp-content/uploads/tygart-media-logo.png”
}
},
“mainEntityOfPage”: {
“@type”: “WebPage”,
“@id”: “https://tygartmedia.com/from-google-apps-script-to-cloud-run-migrating-a-content-pipeline-without-breaking-production/”
}
}

The Recursion That Actually Works

Most people think of AI as a tool you give instructions to. I built a system where the AI writes its own instructions. Not in a theoretical research lab sense. In a production business operations sense. The skill-creator skill is an AI agent whose sole job is to observe what works in real sessions, extract the patterns, and codify them into new skills that other agents can use.

A skill, in my system, is a structured set of instructions that tells an AI agent how to perform a specific task. It includes the trigger conditions, the step-by-step procedure, the quality gates, the error handling, and the expected outputs. Writing a good skill takes deep domain knowledge and careful iteration. It used to take me hours per skill. Now the AI writes them in minutes, and the quality is often better than what I produce manually.

How Skill Self-Creation Works

The process starts with observation. During every working session, the AI tracks which actions it takes, which tools it uses, which decisions require my input, and which outcomes are successful. This creates a session log — a structured record of the entire workflow from start to finish.

After the session, the skill-creator agent analyzes the log. It identifies repeatable patterns: sequences of actions that were performed multiple times with consistent success. It extracts the decision logic: the conditions under which the AI chose one path over another. And it captures the quality gates: the checks that determined whether an output was acceptable.

From this analysis, the agent drafts a new skill. The skill follows a standardized format — YAML frontmatter with metadata, followed by markdown instructions with step-by-step procedures. The agent writes the description that determines when the skill triggers, the instructions that determine how it executes, and the validation criteria that determine whether it succeeded.

The Quality Problem and How We Solved It

Early versions of skill self-creation produced mediocre skills. They captured the surface-level actions but missed the contextual judgment that made the workflow actually work. The agent would write a skill that said “publish to WordPress” but miss the nuance of checking excerpt length, verifying category assignment, or running the SEO optimization pass before publishing.

The fix was adding a refinement loop. After the agent drafts a skill, it runs a simulated execution against a test case. If the simulated execution misses steps that the original session included, the agent revises the skill. This loop runs until the simulated execution matches the original session’s quality within a defined tolerance.

The second fix was adding a description optimization pass. A skill is useless if it never triggers. The agent now analyzes the trigger conditions — the keywords, phrases, and contexts that should activate the skill — and optimizes the description for maximum recall without false positives. This is essentially SEO for AI skills.

Skills That Write Better Skills

The most recursive part of the system is that the skill-creator skill itself was partially written by an earlier version of itself. I wrote the first version manually. That version observed me creating skills by hand, extracted the patterns, and produced a second version that was more comprehensive. The second version then refined itself into the third version, which is what runs in production today.

Each generation captures more nuance. The first version knew to include trigger conditions. The second version learned to include negative triggers — conditions that should explicitly not activate the skill. The third version added variance analysis — testing whether a skill performs consistently across different invocation contexts or only works in the specific scenario where it was created.

This is not artificial general intelligence. It is not sentient. It is a well-designed feedback loop that improves operational documentation through structured iteration. But the output is remarkable: a library of over 80 production skills, many of which were created or significantly refined by the system itself.

What This Means for Business Operations

The traditional way to scale operations is to hire people, train them, and hope they follow the procedures consistently. The skill self-creation model inverts this. The AI observes the best version of a procedure, codifies it perfectly, and then executes it identically every time. No training decay. No interpretation drift. No Monday morning inconsistency.

When I discover a better way to optimize a WordPress post — a new schema type, a better FAQ structure, a more effective interlink pattern — I do it once in a live session. The skill-creator agent watches, extracts the improvement, and updates the relevant skill. From that moment forward, every post optimization across every site includes the improvement. One session, permanent upgrade, portfolio-wide deployment.

The Limits of Self-Creation

The system cannot create skills for tasks it has never observed. It cannot invent new optimization techniques or discover new strategies. It can only codify and refine what it has seen work in practice. The creative direction, the strategic decisions, the judgment calls — those still come from me.

It also cannot evaluate business impact. It knows whether a skill executed correctly, but it does not know whether the output moved a meaningful metric. That evaluation layer requires human judgment and time — traffic data, conversion data, client feedback. The system optimizes execution quality, not business outcomes. The gap between those two things is where human expertise remains irreplaceable.

FAQ

How many skills has the system created autonomously?
Approximately 30 skills were created entirely by the skill-creator agent. Another 50 were human-created but significantly refined by the agent through the optimization loop.

Can the system create skills for any domain?
It can create skills for any domain where it has observed successful sessions. The more sessions it observes in a domain, the better the skills it produces.

What prevents the system from creating bad skills?
The simulated execution loop catches most quality issues. Skills that fail simulation are flagged for human review rather than deployed to production.

{
“@context”: “https://schema.org”,
“@type”: “Article”,
“headline”: “How AI Writes Its Own Instructions: The Self-Creating Skill System That Learns From Every Session”,
“description”: “Inside the skill-creator skill: an AI system that writes, tests, and optimizes its own operational instructions based on real session outcomes.”,
“datePublished”: “2026-03-21”,
“dateModified”: “2026-04-03”,
“author”: {
“@type”: “Person”,
“name”: “Will Tygart”,
“url”: “https://tygartmedia.com/about”
},
“publisher”: {
“@type”: “Organization”,
“name”: “Tygart Media”,
“url”: “https://tygartmedia.com”,
“logo”: {
“@type”: “ImageObject”,
“url”: “https://tygartmedia.com/wp-content/uploads/tygart-media-logo.png”
}
},
“mainEntityOfPage”: {
“@type”: “WebPage”,
“@id”: “https://tygartmedia.com/how-ai-writes-its-own-instructions-the-self-creating-skill-system-that-learns-from-every-session/”
}
}