AI Content Lab: an automated content engine for a marketing agency

Agencies live or die on producing content that lands. The work that decides whether it lands happens before anyone writes a word, and it’s the least enjoyable part of the job.

Content gap analysis. Genuinely valuable, genuinely tedious. Read what your competitors are publishing, note the topics they’re covering, hold that up against your own keyword list, and find the holes. Done properly for a handful of competitors it’s most of a day. Done properly every month, for every client, it’s somebody’s job.

Competitor FAQs. Your competitors are ranking for questions you haven’t answered. Finding them means going through their pages pulling out FAQ blocks, and then the answers still have to be written.

And then the content itself. A topic needs researching, the research needs organising somewhere the team can find it again, and the output needs writing differently for each platform — LinkedIn doesn’t want the voice Facebook wants.

None of this is difficult. All of it is repetitive, and all of it was being done by people who could have been doing better work. That’s the classic shape of a job worth automating.

The constraint that mattered more than any of it

The client was clear about the infrastructure, and it shaped every decision that followed: it had to run in their Make.com organisation, on their Google Drive, using their API keys.

Which sounds like a procurement detail and isn’t. It meant no bespoke application to log into, no dashboard for anyone to learn, no dependency on us once the work was finished. The inputs and outputs had to be spreadsheets, because spreadsheets are what the team already had open.

We could have built something more elegant on our own stack. It would have been worse. A brilliant automation nobody adopts is worth less than a plain one that lives exactly where the work already happens — and an agency that can’t open the thing up and change it themselves is an agency renting its own process back from a supplier.

So the brief we actually worked to was: do all of the above, using nothing they weren’t already paying for, and hand it over so completely that they’d never need to ring us about it again.

Everything was built where it would live: their Make.com organisation, a shared Drive folder, their own API keys. We worked in their setup from the first module rather than building ours and migrating it, which sounds like extra friction and removes an entire category of handover problem.

Workflow one — keyword gaps

A spreadsheet of seed topics and a spreadsheet of competitor URLs go in.

Make watches the sheet for new or updated rows, so adding a topic is the trigger — no button, no schedule to remember. It then reads the competitor pages, pulling headlines, meta titles, descriptions and body copy, and compares what they’re covering against the internal keyword list. What’s missing gets appended to a fresh sheet, and the team gets an email summarising the opportunities.

The team’s experience of it is: type a topic into a spreadsheet, come back to a list of gaps.

Workflow two — the questions competitors already answer

The screenshot below is this one, and it’s the reason it gets the most space here: what sounds like a one-line brief — “pull the FAQs off our competitors” — came out as roughly fifty steps across four branches.

Given a topic or a URL, it finds the leading competitors, reads each page, extracts the questions they’re answering, and writes them into a sheet with drafted answers alongside.

The parts that took the thinking:

FAQs aren’t marked up as FAQs. Some sites use accordions, some use headings, some just have a run of question-shaped paragraphs. So the scrape grabs all the page text, parses it down, and hands it to a model to identify which of it is a question and answer pair. No selector would have survived three competitors, let alone the next three.

Batching, because API limits are real. Extracted questions go through a repeater and an array aggregator in bundles of eight rather than one enormous request. That’s the difference between a scenario that works on a small test and one that still works when a competitor has a sixty-question help centre.

Translation and de-duplication in the same pass. The client works across languages, so the questions are normalised and translated as they’re consolidated — which also collapses the near-identical phrasings you get when three competitors are answering the same thing. Mining a competitor’s German FAQ for English content, or the reverse, stops being a separate job.

It files its own paperwork. The scenario creates the output spreadsheet, adds the sheets it needs, moves the file into the right Drive folder and updates the input sheet to record what it did. Unique keys and counters mean re-running it doesn’t produce duplicates — unglamorous, and the difference between something the team trusts and something they check by hand every time.

Answers come out as drafts rather than finished copy, deliberately. This is the agency’s public voice on a client’s behalf; the automation’s job is to remove the blank page, not to have the last word.

Workflow three — research in, posts out

The most involved of the three, and the one that behaves most like an agent.

1. Gather sources — relevant URLs from search, YouTube and articles on the topic.
2. Research pass — Perplexity summarises each source and pulls out the salient points, the audience reaction, and supporting data.
3. Write it down properly — the research is organised into a Google Doc: summary, audience insights, data points. This step earns its place. It gives the team something citable, reusable and reviewable, rather than research that exists only as a hidden intermediate value inside an automation.
4. Route to specialists — a router splits the research to separate GPT agents, one per platform, each with its own prompt and brief. The LinkedIn agent writes for clarity, logical flow and a professional register; the Facebook agent writes the same substance casually.
5. Publish — the finished posts go out to the connected channels.
6. Watch what happened — engagement comes back in, so the prompts can be tuned against what actually performed rather than what read well on the day.

The pattern worth stealing is step four. One research pass, many outputs. The expensive part of content is understanding the topic, and that gets done once — then each platform is a cheap specialist with a different brief over the same material. Adding Instagram or a newsletter later is another branch off the router, not another workflow.

It’s the same instinct as the JSON templating in the care governance build: do the hard part once, and make the variations configuration.

No pretence about the first week

We told the client up front to expect a bit of support in the opening week, because however carefully you test, it isn’t until other people use a thing that you find where the pitfalls are. Budgeting for that honestly is part of the job — an automation handed over with a flourish and no aftercare is one that quietly stops being used the first time it surprises somebody.

The research grind that used to be somebody’s week is now a spreadsheet that fills itself in. Add a topic, and the gaps come back. Point it at a competitor, and the questions they rank for arrive with draft answers attached. Give it a subject, and a researched brief lands in Drive with platform-ready posts behind it.

What the team actually does now is the part they’re good at: judgement. Choosing which gaps are worth chasing, sharpening a draft answer, deciding a post isn’t quite right. The typing, reading and comparing happens without them.

Handed over, not hosted

This is the part we’re most pleased with, and it’s the least glamorous.

Every scenario runs in the client’s own Make.com organisation, writing to their own Drive, authenticated with their own keys. We offered to host it — that’s the easier sale, and it’s recurring revenue — and it was the wrong answer for them. So they own the lot. They can open any scenario, see every module, change a prompt, add a competitor, or take it somewhere else entirely without asking us.

An agency whose content process only works while a supplier keeps the lights on hasn’t bought a capability, it’s renting one. This way, if we vanished tomorrow the thing keeps running.

And nothing new to learn

Make.com, Excel, Google Drive, and AI models behind an API. Every one of those was already part of their day. There’s no Content Lab app, no admin panel, no seat licences and no onboarding session — the interface is a spreadsheet, deliberately.

That’s usually the honest answer for an operational automation, and it’s rarely the one a supplier volunteers, because building the shiny dashboard is more billable than admitting the sheet is better.

Why we’re showing you this one

The other two case studies here are big builds — a governance platform across fifty care homes, a consumer product with billing on it. This one is the opposite end of the same trade, and it’s the one most businesses actually need first.

Three days’ work. Existing tools. A tedious weekly job that now does itself. No platform migration, no change programme, no rewiring how anybody works.

If there’s a repetitive research-and-writing job eating your team’s week, this is roughly what fixing it looks like — and the honest first question is usually whether the tools you’re already paying for will do it. Often they will.