Case Study 01: Building an Agency-Preserving Content Engine

The Problem with Efficient Automation

When organizations adopt AI-assisted content workflows, the initial conversation is almost always about speed. How many articles per week? What is the cost per word? How quickly can the pipeline scale? These are legitimate questions. They are also the wrong questions to ask first.

Efficiency is a property of a process in isolation. Agency preservation is a property of the relationship between a process and the humans it affects. A content pipeline that produces 200 articles per week at low cost is efficient. Whether it produces 200 articles that reflect genuine editorial judgment - that have been shaped by human expertise, checked against human values, and filtered through human accountability - is a different question entirely.

TechNudges was built to think carefully about this distinction. As a publication focused on behavioral science and AI policy, we could not in good conscience operate an editorial pipeline that violated the principles we write about. So when we designed our AI-assisted content engine, we started not with the question of how to automate efficiently, but with the question of how to automate without supplanting the editorial agency that gives the publication its integrity.

This case study documents what we built, why we made the design choices we did, and what we believe those choices reveal about the broader challenge of agency-preserving automation.

The Pipeline Architecture

The TechNudges content engine is a human-AI collaboration system, not an autonomous publication machine. The distinction matters because it determines where accountability sits - and accountability is the dimension of the Agency Spectrum where most content automation systems fail most badly.

The pipeline has four stages:

Stage 1: Brief generation. A human editor defines the topic, the analytical frame, the target category (The Lab or Intelligence), and the specific claim the piece should make. The AI Synthesis Agent works from this brief. The brief is not optional - the pipeline refuses to run without it.

Stage 2: AI-assisted drafting. The Synthesis Agent produces a structured draft: MDX-formatted content with the correct frontmatter fields, TLDR bullets, and structural blocks. The draft is marked with an [AI DRAFT] marker in the body. This marker is load-bearing: the build system will reject any file that contains [AI DRAFT] without the draft: true frontmatter flag.

Stage 3: Validation gate. Before any content is committed to GitHub, it must pass through a Cloudflare Worker validation layer. The Worker runs 12 checks - structural, semantic, and policy-level - and returns either an approval token or a structured list of failures. No approval token means no commit.

Stage 4: Human editorial review. The editor receives the validation output alongside the draft. The AI DRAFT marker is removed only after the editor has reviewed the content, corrected any issues, and affirmed that the piece represents TechNudges editorial standards. The approval token is logged in the commit message as an auditable record that the content passed the validation gate.

The Validation Gate in Practice

The validation gate is a Cloudflare Worker deployed at the edge. It receives a POST request containing the post’s slug, category, frontmatter fields, and MDX body. It runs 12 checks and returns either a pass with an HMAC-signed approval token, or a failure with structured error objects for each failed check.

The 12 checks are designed to enforce three categories of constraint:

Structural integrity - slug format, valid category, non-empty title and author, ISO date string for publication date. These checks prevent malformed content from reaching the CMS.

Editorial standards - description length between 50 and 160 characters, tags array with 1–10 items, TL;DR with exactly 3 items each under 30 words, word count meeting the minimum threshold for the category (600 for Lab Notes, 1,000 for Intelligence Reports, 800 for Blueprints). These checks enforce the publication’s editorial conventions without requiring a human to verify each one manually.

Policy compliance - absence of the [AI DRAFT] marker in non-draft content, and a whitelist check on custom MDX component tags. Only the four registered component types (nudge, callout, strategicNudge, tldrBlock) are permitted. Any other JSX-style component tag in the MDX body triggers a validation failure.

The approval token uses HMAC-SHA256 with a shared secret stored as a Cloudflare Worker secret (never in the repository). The token encodes the slug, category, and a Unix timestamp. This means tokens expire naturally - a token generated before a post was materially revised cannot be used to commit the revised version without re-running the validation gate.

What This Design Reveals

Building the validation gate surfaced a set of tensions that we believe are general - not specific to content automation, but present in any system that attempts to combine AI assistance with human accountability.

The tension between completeness and correctness. The validation gate can check that the TL;DR has exactly three items. It cannot check that those items accurately summarise the post. Automated validation captures structural correctness. Semantic correctness requires human judgment. This is not a failure of the system - it is a principled division of labour. The gate handles what can be automated; the editor handles what cannot.

The tension between friction and flow. Every validation check is a potential point of failure. A post that fails the word count check requires human intervention to fix. Under deadline pressure, the temptation is to relax the check rather than fix the post. We chose not to relax the checks because the checks exist precisely for the moments when deadline pressure is highest - when the temptation to cut corners is strongest, the gates need to be hardest to bypass.

The tension between auditability and privacy. The commit message approval token creates an auditable record of which content passed the validation gate. It does not record who reviewed the draft, what changes were made, or what the AI originally produced. Auditability of the automated layer is compatible with privacy of the human editorial process. We chose this boundary deliberately - the gate validates the content, not the editor.

The tension between automation and agency. The validation gate is itself an automated system. By the logic of the Agency Spectrum, it occupies a position on the spectrum in relation to the editors who use it. We designed it to sit at Automate, not Autonomise: it makes decisions about content structure and policy compliance, not about editorial judgment. The editor can override any check by marking a post as draft, addressing the failure manually, and re-submitting. The gate has no power to approve content - only to block content that fails its checks.

Lessons for Agency-Preserving Automation

We offer these observations not as universal prescriptions, but as findings from a specific design process that took the Agency Spectrum seriously as an engineering constraint.

Make constraints technical, not conventional. Conventions are advisory. Technical constraints are structural. If a constraint matters - if violating it would undermine the integrity of the system - encode it in the system’s architecture, not in a style guide.

Design for audit, not just for operation. The approval token in the commit message is not operationally necessary - the gate runs whether or not the token is logged. It exists because we want a future editor, or a future regulator, to be able to establish that a specific piece of content passed the validation gate at a specific time. Build the audit trail into the system from the start.

Separate the automated from the human, clearly. The [AI DRAFT] marker is crude but effective. It makes the boundary between AI-generated and human-reviewed content visible at the file level. Any system that blurs this boundary - that allows AI-generated content to be committed without a visible human review step - is making a claim about human accountability that the system’s architecture cannot support.

Score your own systems. We applied the Agency Spectrum to the content engine itself before building it. The scoring exercise surfaced the validation gate as a necessary design element - without it, the pipeline would sit at Autonomise on the accountability dimension. If you are building automated systems and have not assessed your own pipeline against the frameworks you apply to external systems, do that assessment before deployment.

The content engine is not finished. No system designed to evolve with its users ever is. But its foundations are built on the principle that automation should serve human agency, not substitute for it - and that this principle needs to be encoded in the architecture, not just stated in the editorial charter.

Read the Agency Spectrum Framework v1 blueprint for the full scoring protocol used to assess systems like this one.