I've spent a lot of my career inside content operations that were too big to run on a spreadsheet and good intentions. At Healthline, I worked with a 300-person editorial team across five websites. At People Inc., I worked with a 400-person content organization and a 15-person growth team across more than 30 domains.

These teams produced thousands of pieces a month and refreshed far more than they published. Moving a draft from an idea to something worth reading involved strategy, research, editing, distribution, approvals, and somebody making sure the damn thing actually got published. That's the work I'm looking at when I evaluate AirOps.

Does it make that work better? And is it worth what it takes to run it?

This review draws on my three months of hands-on use through March 2026. I updated the pricing references and edited the article in September 2026; this is not a new product test. Screenshots show the version I used in March.

My recommendation is conditional. AirOps makes sense for a content team that wants a shared production platform and has someone responsible for building and maintaining its workflows. I have a harder time recommending it to a small team that's already comfortable building its own tools.

I tend to think about this as two different ways of organizing a team. A builder team works directly in tools like Cursor or Claude Code, keeps its context and instructions in shared repositories, and improves the system as it uses it. That gives people room to make the software fit their work. It also makes the team responsible for maintenance, access, failures, and training. A weekend prototype doesn't settle any of those questions.

A platform team wants a smaller group to handle that complexity so the rest of the organization can use established workflows. If you've got dozens of content producers, you probably don't want every writer maintaining their own automation. AirOps gives that team a common place to work, with more of the surrounding infrastructure already built.

You can use both approaches in one organization. The useful question is where your team's workflows should live and who will own them after the initial setup.

The comparison that makes the most sense to me is Airtable for AI-assisted content production. I've used Airtable to move work between strategy, editorial, distribution, and production teams. AirOps puts more of the drafting and enrichment work inside that process.

Before you automate production, you still need answers to four questions:

A production workflow depends on those decisions. If your content strategy is weak, automation can help you produce weak content faster. I go into the upstream decisions in the content strategy and opportunity-sizing walkthrough.

Once you've made them, a piece can move through a brief, research, drafting, editorial review, distribution preparation, CMS production, and approval. At a large publisher, different people own those stages. The handoffs matter as much as the first draft.

That's why I care about workflow software. I want to know whether a researcher can pass useful evidence to a writer, whether an editor can enforce the standards, and whether the approved version gets to the right place. Generating another paragraph is the easy part.

The Brand Kit and Knowledge Base were the strongest parts of AirOps in my testing. They gave me a structured place to put the information a generic prompt usually leaves out: the company, its products, the audience, the voice, and the standards for each kind of content.

The Brand Kit went beyond a tone-of-voice paragraph. It covered product lines, audience differences, content formats, regional variations, and visual guidelines. I preferred that structure to Jasper's approach when I tested them. It made the context easier to organize, though somebody still had to supply accurate, useful material.

I also liked the Grid. Work moves from left to right across columns, with each step adding something to the original source: a keyword, a brief, an existing draft. If you've run production in Airtable, it feels familiar. And if you've built automations in Braze, Iterable, or Zapier, the workflow editor gives you recognizable pieces to work with.

Familiarity helps, but it doesn't make the implementation automatic. The interface was easy enough for me to understand; deciding what every step should do took more work. Coming from an environment where I could describe a change to a coding agent, clicking through that configuration felt slow.

For a team that doesn't want every contributor designing their own prompts, the payoff is consistency. You can build the context into a workflow once, improve it centrally, and let people use it without having to reconstruct the setup each time.

The integrations and ways to call a workflow were another strength. During my review, I could see how AirOps could fit into an existing stack: bringing in research and source material, running an established process, and moving the output toward a CMS. That matters more to me than how many standalone features appear on a pricing page.

I liked AirOps's MCP integration because it made the workflows accessible from compatible tools outside the main interface. That's useful when some people prefer a coding environment and others want the platform UI. Check the current documentation for the client and integration you actually plan to use.

The live cohorts, courses, and embedded help also reflected how much there was to learn. I'd make time for that education in an implementation plan rather than assuming a few onboarding videos will cover it.

Workflow sharing is where the platform model becomes convincing. A small operations group can maintain the process while a much larger group uses it. I've seen that division of responsibility work in Braze and Iterable. AirOps felt familiar in that respect.

I used several time estimates in the first version of this review, and they described different jobs. Learning the basics can take weeks. Configuring a useful production process can take months. Getting a large team to change how it works is a separate adoption effort. Those are planning judgments from my experience, not measured AirOps implementation benchmarks.

In March, I found the built-in search visibility and research features less compelling than the production system. That assessment needs a fresh test before I'd apply it to the current product. AirOps now lists broader answer-engine coverage on Pro than on Solo, so the old blanket dismissal doesn't hold up as a current feature comparison.

Before buying, map the integrations against your actual workflow. Which research subscriptions will you keep? Which publishing tools will you still need? Who will review the output and maintain the automations? Price those alongside the platform. Don't assume a new content tool makes the rest of the stack disappear.

My main frustration during the test was the amount of manual configuration. Once a workflow was established, it could do useful work. Getting there felt tedious compared with how I prefer to build. That may matter less to an operations team that already owns a library of shared automations.

Pricing checked September 7, 2026: AirOps's current pricing page lists Solo, Pro, and Enterprise, with task allowances and capabilities that vary by plan. It doesn't publish the fixed monthly subscription prices used in the original article. Its FAQ also retains some older plan names. Get a current quote for your workload, including task usage, overages, required integrations, and support. The old $3,000-per-month headline should not be treated as a current price.

I build systems in coding tools, so of course I'm going to compare AirOps with that option. A shared repository and an agent can be a good fit when the people doing the work know how to maintain them.

But saying you can build an equivalent system for the cost of API calls leaves out most of the cost. Someone needs to own the code, connect the data, handle errors, manage access, and keep the system useful when the business changes. If that person is you, their time still counts.

This reminds me of the platform decisions I've seen in paid media. A capable operator can do a lot in the native tools. An additional platform has to earn its place by making the work easier to manage across people and accounts. Buying the platform doesn't remove the need for a capable operator.

The same applies here. AirOps is easier to justify when you already have an operations lead who understands the production process and needs a way to make it available to more people. It's harder to justify as a substitute for that expertise.

Pick one recurring workflow that matters to the business. Run it through AirOps and through the best alternative your team could realistically maintain. Use the same source material, output requirements, and editorial standard in both.

Track the setup time separately from the time spent running each piece. Then record editing time, failures, review effort, and the cost of the surrounding tools. A cheaper first draft isn't much of a saving if an editor has to rebuild it.

Ask somebody other than the person who built the workflow to use it. Can they tell what to put in, recognize a bad result, and get help when it fails? That's the part a polished demo won't answer for you.

For a large content operation with an owner for the platform, AirOps deserves a serious trial. I liked its context system, Grid, workflow sharing, and integrations. Those are useful things to have when many people need to work through the same process.

For a smaller team that's already comfortable building and maintaining its own workflows, I'd test the narrower option first. I wouldn't buy a whole production platform because I needed a better writing prompt.

The decision comes down to the work your team can sustain. Try one real workflow, put an editor's time into the calculation, and see which approach produces something you'd actually publish. That's a much better test than counting features.

Related: how to make AI-assisted marketing work feel like your team made it.

I’m Hanna Huffman. Marketer in the Loop is my weekly letter about doing good marketing work as AI changes how we do it. Expect useful ideas, people worth knowing, and things I’m figuring out in my own work.

Published by MultiplAI Growth Partners.