TL;DR

• The definition: Content engineering is six connected layers: source, knowledge, generation, evaluation, distribution, measurement. Skip one and the loop stops closing.
• The example: AirOps is the clearest packaged version of that loop on the market. Specialist subagents, shared memory, a human review gate, and scoring before anything ships.
• My version: I do not run AirOps. I run the pattern with eight named domain owners and one orchestrator, each with a charter, a schedule, and its own memory.
• The proof: A form on one of my own properties told me it worked and wrote nothing. A content pipeline reported one result while the log said another. The evaluation layer is what caught both.
• The rule: Build the auditor before you scale the writer, and give measurement the authority to change next week’s brief.

Content Engineering Is a System, Not a Post

A content marketer produces content. A content engineer designs the system that produces, evaluates, distributes, and improves it. The difference is job design, and the market has already priced it.

You can see it in the postings. Ahrefs coded 20 US content engineer job descriptions and found that 85% require building an AI content pipeline, 70% want SEO, AEO, or GEO ownership, and 65% ask for prompt engineering. You can see it in the vendors too. Every serious content platform now sells a system rather than a writing assistant, because that is what buyers keep asking for.

The signals converged in 2026. Meta posted content engineer roles across two product lines. Google shipped its first AI Optimization Guide in May and named non-commodity content as the biggest lever. WSJ CMO Today ran the marketing engineer rebrand in October. The title is new. The work is not.

The architecture is consistent, and I have written about the six layers of the content engineering loop before: source, knowledge, generation, evaluation, distribution, measurement. Measurement feeds back into source, which changes what you research, which changes what you write. Most teams own two of those layers and call it a stack. The gap between two layers and six is where the return lives.

What AirOps Shows About the Shape of the Job

AirOps is the clearest example of a content app built for the loop instead of the artifact, which is why I use it as the reference point. You do not need to buy it to learn from it. Read what the product actually does and you can see the job description underneath.

The platform breaks a growth program into goals, calls the right models and tools for each one, and delegates the work to specialist subagents. Agents save what they produce, and memory lets each run build on what the system already found, completed, and learned. Triggers start a run when a competitor moves or a page starts losing ground. Work pauses for review when judgment matters, gets routed to an inbox, and resumes after a reviewer comments on passages, compares versions, or rejects the change.

The company describes the intelligence layer behind the work in numbers: 47 million observed buyer actions, 6 billion citations, 10 million AI search journeys. Vendor figures, so treat them as directional, but they change the input a research step starts from.

Two details matter more than the rest. First, AirOps scores content before it ships, on readability, claim support, information gain, SEO, and AEO. Second, its publishing integrations preserve field mappings, content structure, and item IDs, which is the boring plumbing that makes measurement possible six weeks later. Break the structure on the way out and you have nothing to compare.

Their 2025 State of Content Teams report puts the same gap in numbers. Teams spend 65% of their time on research and ideation, 40% say content creation is the step that slows them down, and 26% of resources go to manual SEO work. Read that list again. Every item on it is a layer the system should be carrying.

What Good Tooling Does Not Fix

Here is the part the product page cannot tell you. A system that reports success is not the same thing as a system that works, and the gap between those two states is where most content operations quietly die.

On one of my own properties this year, a newsletter form returned a success message for two live test submissions and wrote nothing. No contact, no confirmation email, no log line. The page looked correct. The integration looked connected. Anyone watching the screen would have called it done. The only reason I know it was broken is that I stopped trusting the success message and looked for the record it claimed to have created.

A content pipeline fails the same way. In October, a daily report on one of my job feeds said one item had passed the filter. The disposition log said three. Nothing crashed. The view was assembled from a capture snapshot and joined to the verdicts, so anything scored but missing from the snapshot disappeared without a warning. That is a measurement layer lying to the person reading it, which is worse than an outage, because an outage at least announces itself.

A third pipeline had the same shape. 717 of 736 people read as no-signal, not because the engagement was missing but because the write step created the person and skipped the signal. The data had never been recorded, so every downstream view was technically accurate and completely useless.

Both failures have the same root. The system was asked whether it succeeded, and it said yes. Neither had been built to prove it. That is the argument for the evaluation layer in one sentence: a claim of success is not evidence of work.

AirOps understands this better than most, which is why scoring before publish is a first-class feature rather than an add-on. But no tool installs the habit for you. Somebody has to decide a green check is not the finish line.

My Version: Eight Owners, One Orchestrator

I do not run AirOps. I run the pattern, with named agents, each accountable for one domain. Eight owners plus one orchestrator, each with a charter that names its lane, a schedule it runs without me, and a persistent session so context accumulates instead of resetting.

Here is how that maps to the six layers. Notice that one owner covers three adjacent layers, and that is deliberate.

Quill holds three layers because knowledge, generation, and evaluation share the same context. Split those across three agents and you get three versions of the brand voice and a weekly argument about which one wins. Simon stays separate because research has to stay read-only on its sources, and the agent whose job is to know things should never be the one allowed to change them. Distribution runs as machinery because it needs no judgment at all. That is the design: split where the context differs, consolidate where it does not.

Why One Assistant Tops Out

Everyone starts in a single chat window, and it works well enough to be seductive. You paste a brief, you get a draft, you paste edits, you get another draft. The problem is everything around the quality: no memory that survives the session, no defined output, no gate, no measurement, and no way to run the same process tomorrow without you in the middle of it.

There is a second, quieter failure. A single thread collapses two jobs that must stay separate. The same context that writes the draft also grades the draft. Ask any editor who has worked with writers: the person who wrote it is the worst person to approve it. Self-grading removes the one control you were relying on.

That is the ceiling. Not model quality. Architecture.

What I Actually Think Most Teams Get Wrong

They buy generation because generation demos well, then wonder why output went up and trust went down. I have run this loop on my own properties long enough to say the ordering is backwards. Marketing ops stalls in the same place every time, and it is never the writing step.

My own nightly system is built on that belief. It ingests, synthesizes, verifies, publishes, and reconciles on a schedule, and the verification step is the one I refuse to remove. The same principle produced the LinkedIn Algorithm Report, where 2,279 posts from 246 creators had to be measured before a single claim got published. Measurement first, volume second. Reverse that order and you end up with a library nobody can defend in a board meeting.

Here is the part I will argue about with almost anyone. Most content teams don’t have a writing problem, they have an approval problem. There’s no shared definition of what a finished piece is, so every piece gets negotiated from scratch and the bottleneck moves to whoever cares most. An output contract per owner fixes that. Quill knows what the standards audit will check. The audit knows what it is allowed to kill. Once those two things are written down, throughput stops depending on heroics.

The second thing teams get wrong is org design. They add a manager agent above the workers, and two managers end up watching the same work. That is the failure mode I described in my deployment playbook for AI agents in B2B marketing. Add owners, not managers. Every name on the roster is a boundary.

The Audit I Would Run First

Before you build anything, find out which layer is already broken. This takes about an hour and it will change what you build first.

Whatever the audit finds, build in the same order. Write the output contracts first: one page per layer, what goes in, what comes out, what makes it unacceptable. Then the knowledge layer and the auditor, before the writer. Put the human gate where the risk is, meaning anything with a claim, a number, or a customer reference, and let the rest run. Publish through WordPress so structure survives. Then give measurement the authority to change next week’s brief, because a dashboard that changes nothing is not a loop.

The Loop Is the Job

Content engineering is the decision to run content as infrastructure: six layers, named owners, one shared memory, a gate where judgment matters, and a measurement trail that tells you what to do next. AirOps is one good expression of the pattern, and the pattern outlives any vendor, because the vendor will change and the architecture will not.

If you take one thing from this, take the ordering. Source, knowledge, then evaluation, then generation. The teams that build in that order ship less content and win more of the searches that matter. The teams that build the other way get very good at producing things nobody can defend.

Book a strategy call →