How our AI content workflow works

Our AI content workflow publishes one useful Drop Jaw Studio article at a time. It can research, draft, check the website, run a production build and prepare a release. It cannot skip the editorial rules, invent proof or call an article published until the live page has been verified.

That distinction matters. The interesting part is not that an AI agent can write Markdown. It is how the complete system limits weak decisions, preserves a record and stops when the evidence is not good enough.

This is the practical structure we use behind the scenes. It is not a claim that every business should publish daily, or that our setup can be copied without adapting it. It is an example of turning a broad instruction into a bounded, testable operating process.

We started with the publishing standard, not the tool

The workflow began with an editorial calendar, brand guide, content standard and website schema. Those sources define what a finished article must contain and what it must never claim.

Before drafting, the system has to check:

the current editorial calendar and publication log;
recent Insights articles and any open content branches;
the live services the article can genuinely support;
the required voice, minimum structure and metadata;
the rule against invented clients, quotes, results or first-hand experience;
the current website model for categories, dates, slugs and social images.

This turns “write an article” into a constrained job. The agent is not asked to decide the brand from scratch every morning. It works from maintained source material and has to preserve the existing content model.

That is a useful design principle for any AI agent system: move important business knowledge out of a one-off prompt and into sources that people can review, update and own.

The workflow checks for duplicate work first

Automation can create duplication very efficiently. We therefore make the first operational step a read, not a write.

The workflow fetches the current production branch, checks the local working tree, inspects open pull requests and compares the calendar with published article slugs. It also reads a short run memory containing the last completed article, its live URL and the next planned topic.

That memory is not treated as unquestionable truth. The repository and live calendar are checked again because another person or process may have changed them since the previous run.

If the planned topic is already published or being prepared on another branch, the agent must not create a second version. If the calendar is exhausted, it can select a relevant non-duplicate topic, but it must explain the choice through the site’s real services and audience.

This read-before-write pattern applies well beyond content. Before an agent updates a customer record, campaign, spreadsheet or product feed, it should establish the current state and look for work already in progress.

Research is restricted to evidence we can link

For current facts, the workflow searches for primary sources such as official guidance, regulator material and platform documentation. It does not use a search summary as the final evidence. The actual source page has to support the claim.

We separate three kinds of statement:

Verified fact: a current source directly supports it.
Our interpretation: the practical consequence we draw from that evidence.
Our process: something we can confirm from the way the Drop Jaw Studio system actually works.

That separation keeps the prose useful without making the sources say more than they do. It also makes time-sensitive claims easier to maintain because the article records which sources were checked and when.

Google Search Central’s guidance on generative AI content says automation can help with research and structure, but producing many pages without adding value may breach its scaled content abuse policy. Its recommended focus is accuracy, quality and relevance. For us, that means the publishing frequency is never the quality test. A run should stop if it cannot produce a distinct, useful article.

The draft is built to a fixed content contract

Each article is a Markdown file with required frontmatter: title, description, slug, category, publication date and display order. The website turns that data into the page title, canonical URL, category artwork, article schema, archive listing and sitemap entry.

The written content must also pass a clear checklist:

at least 800 useful words;
the primary topic stated naturally near the start;
three or more descriptive sections;
at least three practical FAQs;
relevant internal links to services and other Insights;
direct links to supporting primary sources;
a plain-English conclusion and sensible next step;
no unsupported numbers, client claims or promises.

The rules are deliberately visible. A vague instruction such as “make it good” is hard to test. A content contract can be checked by people, code and the agent itself.

We also reuse the established category card instead of generating a new image for every post. That keeps the visual system consistent and avoids adding decorative work that does not improve the article.

Build checks catch structural problems before publication

After the draft is written, the workflow runs the same production build used by the live Astro website. A successful build confirms that the frontmatter matches the content schema, the dynamic route can render and the sitemap can be generated.

We then inspect the generated page rather than assuming a successful command means the article is sound. The checks cover:

one article URL with the intended slug;
the correct title and meta description;
canonical and social metadata;
BlogPosting structured data;
the inherited category image;
internal links, external source links and assets;
the Insights index and category archive;
the sitemap entry;
desktop and mobile rendering.

Build validation is a useful boundary because it turns a draft into a testable website change. The same idea applies to other automations: define an environment where the output can be inspected before it reaches customers or production data.

Branches and previews create a release boundary

Every article is prepared on a dedicated content branch. That isolates the change from unrelated work and makes the proposed release easy to inspect. The branch is pushed, a pull request is created and the changed files are checked before anything is merged into the production branch.

Cloudflare Pages can create a separate preview deployment for a non-production branch and automatically deploy the configured production branch after a merge. Its GitHub integration documentation describes both preview URLs and production-branch deployments.

The important concept is the boundary, not the particular platforms. Drafting and publishing are different permissions. An agent that can prepare a file does not automatically need unrestricted access to every repository, account or website action.

Our daily workflow has standing permission to publish a verified article, but that permission is narrow. It does not include social-media posting, changing unrelated files or ignoring a failed check. If evidence, authentication, the build or deployment is blocked, the correct outcome is a preserved draft and a precise failure report.

Live verification is part of publishing

A merged pull request is not the same as a published article. The production deployment could fail, the custom domain could still serve an earlier build or a route could render differently from the preview.

The workflow therefore checks the production deployment and then loads the canonical article URL. It verifies the HTTP response, rendered content, metadata, schema, images, links, archive listings and sitemap on the live domain.

Only after those checks pass does it update the publication record and mark the topic complete. The record includes the article URL, branch, pull request, merge commit, deployment and checks completed. That makes the result traceable and gives the next run a reliable starting point.

This is one of the least glamorous parts of an AI content workflow and one of the most important. “The tool said it worked” is not evidence that the customer-facing outcome exists.

Guardrails are technical and operational

The National Cyber Security Centre’s current advice on managing the cyber risk of agentic AI recommends matching autonomy to risk, defining red lines, restricting access, monitoring activity and retaining an emergency stop. It also warns against relying on prompts alone.

Our content workflow uses several layers:

written constraints define the permitted task and stop conditions;
filesystem and network permissions limit what can be accessed;
source control records every website change;
the build tests the proposed output;
preview and production deployments separate environments;
live checks confirm the public result;
run memory and publication records support audit and recovery.

None of those controls guarantees a perfect article. Together, they make mistakes easier to detect, limit the effect of a bad decision and create evidence about what actually happened.

If you are designing an automated marketing workflow, start with one repeatable job and ask four questions: what can it read, what can it change, what proves success and when must it stop? Our marketing automation guide for Northern Ireland businesses provides a six-part brief for choosing that first job.

Frequently asked questions

Does AI write every Drop Jaw Studio article automatically?

AI prepares the research, draft and technical release work inside a defined workflow. The system still depends on human-authored brand guidance, editorial standards, service information and publication rules. It must use current evidence, pass the website checks and stop when it cannot verify the result. Automation handles the repeated process; it does not remove editorial accountability.

Why publish through a repository instead of a blog editor?

The repository makes each article a versioned website change. A branch isolates the draft, a pull request shows exactly what changed, the production build tests the complete site and the commit history preserves the record. A conventional content management system can support similar controls, but the important requirement is a reviewable draft, a testable release and a recoverable history.

Could a small business use a simpler AI content workflow?

Yes. A useful first version might only research from approved sources, prepare a draft from a template and hand it to a person for checking. Add direct publishing only when the business has reliable source material, clear permissions, validation and a way to stop or reverse the process. The safest workflow is the smallest one that improves the real job.

What should never be automated in content production?

Do not automate claims that the business cannot substantiate, invented customer proof, legal or regulated assertions without appropriate review, or publication into accounts the workflow does not need. Sensitive judgement and exceptions should have named owners. If a draft cannot be verified or the release checks fail, preserving the work for review is better than forcing publication.

Want to turn one repeated marketing job into a controlled workflow? See how we build AI agent systems in your own accounts →

Sources checked on 27 September 2026: Google Search Central, Cloudflare Pages and the UK National Cyber Security Centre, linked above. This article describes the current Drop Jaw Studio publication workflow; it does not report client results or guarantee publishing or search performance.