Before getting into the details of the system we built, Ryan deserves a great deal of credit. As the system architect, he developed the process while I worked closely alongside him. He was thorough in planning and resourceful whenever the system ran into trouble. I would hate for this article to leave the impression that this was a one-person project. It wasn’t! Ryan’s contribution was essential to the project. Working beside him taught me a tremendous amount about designing better systems that can handle problems when they inevitably happen.
With credit given where credit is due, let’s dive in.
Project: Using AI orchestration to digitally publish
A client came to me and my partner hoping to cut his company’s content production time by 50%. I told him I confidently believed we could do better than that.
His company generated insurance leads across the United States. He wanted 5,000 unique articles, with one article built around each of 5,000 U.S. cities. Writing that much content through a traditional production process could have kept a team busy for years. Our system completed the production run in 13 hours. I estimate that the system reduced the client’s content production time by about 99%.
Those numbers tell only part of the story. My team spent several months planning and building the system before we ran it. The hard cost was $273.84, which covered the tools we used to build out the AI orchestration system we used to generate all these articles. However, this insanely low cost does not include our labor to create the system. The same is true of the time we spent testing and reviewing the work.
This actually provides a strong point to consider in the AI vs. Human debate. AI orchestration did not remove the need for us humans in the process. Instead, it moved much of the human capital to the beginning of the process. To truly have quality in the final run depended largely on the human interactions made before the first article entered WordPress.
What the AI revolution changes is the human workflow process. Contrary to popular belief, it does not eliminate it. Just as the Industrial Revolution allowed manufacturers to produce more with fewer workers, AI is bringing comparable gains in productivity to today’s workflows. Commercial-grade digital publishing that once depended on ten people or more can now be managed by a single person. That level of efficiency is remarkable.
Now, the greatest human investment happens much earlier, when the workflow is designed. It is decisions made at that stage that determine the long-term value AI can create for the business.
What AI orchestration meant in this project
AI orchestration is the practice of connecting several tools so each one performs a defined part of a larger process. In our system, a spreadsheet served as the control layer. Make.com moved each row through the workflow. DataForSEO supplied search and location data. OpenAI used that information to generate the content. WordPress received the finished article.
The system also needed a way to track each article as it moved through production. Each row began with a queued status. It changed after completion or when an article needed review. A failed row received its own status. This made the spreadsheet a record of what had happened. When an article failed, the team could see where it stopped and send it through the process again.
This AI system gave us the ability to move much faster. However, we still had to figure out how the work should flow for that speed to even matter.
The struggles with the content development
Our first task was to decide what made one city page substantially different from another. Changing a city name inside the same article would have been easy. It also would have produced weak pages with little local value.
One of the harder parts of this project was making each article genuinely local. We wanted someone reading an article to feel like it had been written with their area in mind and not by a machine. The system first had to learn what was happening locally and what people there were talking about. We then gave it enough freedom to work those details into the article where they belonged.
Another hurdle is that AI writing has a very recognizable voice. Some of the AI’s habits are extremely obvious—yes, I’m talking about you, em dash! I have spent an embarrassing amount of time trying to get AI to stop sounding like AI. Its original training runs deep, and I still cannot remove it completely. I would say I am about 80% there, which was good enough for this project.
I created a writing framework that governed how the system produced each article. Interestingly, as it generated more articles, it began treating some of those requirements more like suggestions. Even then, the framework kept the writing much closer to the voice we wanted than the model would have produced on its own.
We also planned the site structure before building the workflow. We defined the categories and URL pattern. We tested how WordPress handled primary categories and permalinks. These early decisions affected every page that followed. At 5,000 pages, small mistakes do not stay small. A problem in the structure could spread everywhere and take a lot of work to fix.
Building around real data
One really important question was where the local information would come from. We found that much of it was already available through free databases. From there, DataForSEO gave us access to search information that helped us understand what mattered in each location.
Using search volume gave us a good sense of which topics had demand. However, what really helped were the search results themselves, which gave us much more material that could feed directly into the articles. It was also helpful to gain access to local business records that provided us with details from the area, making the content more relevant. For version two, I think I will add in answers to the questions from AlsoAsked so the system can draw from what people are curious about.
We fed all of that information into the system before the writing began. The model was instructed to work only from the material we supplied. This gave it a stronger factual foundation and less reason to hallucinate. All of these data points helped each article feel connected to the community it covered.
Preparing WordPress for automation
Before connecting the automation to WordPress, we set up a separate user account for it. The connection used an Application Password, so the system never needed anyone’s personal administrator credentials.
We began by testing the process with only a few posts. We created them manually and then ran content through the system to check where everything ended up. This helped find some problems with the URLs and mismatched article fields.
The website itself also had to be ready for the volume. Publishing thousands of posts creates a lot of database activity, and phase two of our project (not shared in this article) will bring thousands of media files into the process as well. We had to make sure our hosting could keep up with the system once it started running at full speed. Surprisingly, our shared DreamHost server handled the workload quite well. That was one assumption I did not expect to be validated.
Google Sheets as the control center
We used Google Sheets to store the location data and track the status of every article. Apps Script then sent rows through the workflow in manageable batches. This kept each run within Make.com’s time limits and prevented connected services from exceeding their rate limits.
After each row was processed, the system updated its status. Successful rows showed that the article had reached WordPress. Any failed row remained visible so we could investigate it. This record became especially important once thousands of rows were moving through the system. At that scale, we needed a reliable way to know what had happened to every article.
Running the articles in batches helped us improve the process as we went. We could stop and review a small group before turning it back on. Any issues we found (and we did find some) allowed us to address them in the prompt before the next batch began.
Planning failure into the workflow
As just mentioned, we hit snags. A failed request was one thing we knew would happen eventually. In my time developing complex applications, I’ve never had a system work perfectly on the first run. This project proved to be no different. We found that WordPress would occasionally reject something we sent it. Fortunately, we had planned for those problems to be expected parts of the workflow.
When a request failed, the system made another attempt. If the issue continued, it recorded the problematic article and alerted us when necessary. This made it easy to find articles that never completed the process and see exactly where they had stopped.
None of this work is visible when someone reads the finished article. However, its value becomes clear when the system is processing thousands of articles. At that volume, a 1% failure rate can create 50 problems that someone still has to locate and resolve.
The 13-hour run was the beginning of the work
Once the system had passed its pilot, we could release the articles in paced batches. We watched the failure rate and the size of the review queue. Search performance would later show which locations and topics earned attention.
Search Console and GA4 can track each batch through tags tied to the location or topic. This gives the company a way to learn which parts of the project produced value. Those findings can guide future content decisions.
The system also needs a maintenance path. Local information changes. A prompt may create a factual problem that appears across many posts. The company needs a way to identify affected articles and send corrected information back through the workflow. A scheduled freshness review can find pages that have become outdated.
Large-scale publishing creates an ongoing responsibility. The automation must support revision as readily as it supports creation.
What I gained from the project
The most impressive number from this project may be 13 hours, but that result came from decisions made months before production even began. We established what every page needed to do. We built the data around genuine local information, and we created a process for tracking errors and reviewing the work.
One of my biggest takeaways from this project was that scale magnifies every decision made along the way. A well-designed prompt can produce thousands of well-written posts. One flawed assumption can just as quickly spread across thousands of pages before anyone catches it. A fully autonomous AI system can quickly become a nightmare when nobody is watching to catch mistakes. That is why handing the keys of the kingdom over to AI is a dangerous approach.
Human involvement needs to remain part of the process. We bring the critical thinking required to recognize problems early, especially when checkpoints are built into the workflow. Ultimately, people must decide what the AI system values and set the standard for work done well.
There is a bot algorithm risk that comes with publishing 5,000 location pages. Pages with limited value can begin to look like thin automated content or doorway pages. Before committing to a project this large, each page needs to provide a clear reason for someone to visit it.
The client came to us hoping to cut the workload in half. With our system finished, the publishing process now takes 99% less time. This project shows what AI orchestration can accomplish when the process begins with a clear strategy. AI can carry that strategy through thousands of tasks at remarkable speed. Once thousands of decisions can be carried out in hours, the thinking behind them matters more than ever.
Three aspects of the project I would improve
1. Running content creation in rounds
Our system required AI to do everything at once, which definitely sped things up. I think it would be more helpful to divide the writing into several rounds. The first round could determine what the article should cover. The next could produce the draft. A separate AI instance would then compare the draft against the previously collected information and requirements. The review would determine whether the article is ready to move on. Articles that need more work would be sent back with instructions that guide the next rewrite.
Multiple rounds obviously eat up tokens and cost more, but they also give several chances to catch a bad article before it is ever published. I truly think it would be beneficial to have AI concentrate on one job at a time instead of expecting one prompt to handle the entire process.
2. Seeing beyond the written content
The body of an article is only one part of a finished page. The workflow should also prepare the meta title and description. With this project, the client had an in-house plugin that handled this automatically. However, I’ve found that most off-the-shelf plugins don’t do this well. When a page needs schema markup, the system that I outlined can easily generate the appropriate fields and send them through the WordPress REST API to the site’s SEO plugin.
Another thing our client didn’t want the system to do was internal linking. Again, he had his own solution, but internal links should definitely enter the process. A location page can connect to related pages that share a category or nearby region. The workflow needs to know which articles have already been published so it can create links that lead to live pages. These elements help each article function as part of the site rather than as an isolated block of text.
3. Adding additional page elements
Our 13-hour production run created text articles. However, our system did not create original images or videos for those pages.
From my work with Entity SEO, original visual content is a necessary part of the page. Text alone leaves the work incomplete. Google may state that well-written text is enough, but our testing has led me to a different conclusion. Each page that you want to be found in the search and AI results needs to include at least one original image or video.
AI-generated images and embedded videos have worked well in our testing. I wouldn’t have image generation as part of this system. A new orchestration dedicated to this process makes the most sense. It could create location-specific images for each page and upload it through WordPress with the proper metadata.
In my opinion, the 5,000 articles are still unfinished until you deploy an image orchestration system. The current system has proven that localized text can be produced quickly and at remarkably low cost. However, each page still needs visual content that strengthens its connection to the location and helps algorithms understand what makes that page relevant.