How to build an AI content team from scratch
The useful part is the handoff. A researcher should produce evidence the script writer can use. A fact-checker should point to the exact line that needs changing. The editing guide should tell your editor what goes on screen for every sentence, and the scheduler should post the approved version everywhere without you copying captions around. Five impressive role names won’t help if the work gets lost between them.
This is the same shape as the content system I run: every script lives in one Notion database, research agents check the claims, a voice log keeps the writing sounding like me, and Blotato schedules the finished videos. The folder names below are suggestions, so adapt them to your own tools. You keep creative direction, filming, the edit and final approval.
part 01
Start with one content project
You need Claude Code installed and authenticated with suitable product access, plus a project folder you can edit. Model usage counts toward the access route you use. Web research and connected apps depend on configured tools and permissions. Creating a role does not automatically give it access to your browser, Notion or paid research services.
For your first run, choose a topic you understand well enough to judge. Our worked example is a short carousel explaining how to organise a weekly work summary. The evidence should come from the actual product documentation and your supplied examples, not an invented story about your results.
Save a short audience description, three pieces of writing you have approved and the source documents or URLs. Remove private information you don’t want used in the project. These inputs matter more than making the team elaborate.
part 02
Set up a shared starting point
Use CLAUDE.md for short project instructions: who the content is for, how to find the voice examples, what claims need evidence and what requires approval. Keep detailed material in separate files and tell Claude when to open it. The memory documentation explains how project instructions work.
Here is a suggested layout, not a built-in requirement:
content-project/
CLAUDE.md
audience.md
voice-examples.md
voice-log.md
approved-sources/
drafts/
reviews/
visuals/
Use /agents in Claude Code to create focused project roles, following the official subagent guide. Give each role a clear description and only the tools it needs. The main conversation can coordinate these handoffs; you do not need a separate autonomous team feature to run this process.
voice-log.md with a one-line rule, like “say ‘here’s how’, never ‘furthermore’”. Point the script writer at it. After a few weeks it knows your edits better than any style description could.part 03
1. The researcher returns claim-level evidence
The researcher receives the topic and the audience question. Its output should connect each proposed claim to a source, an exact supporting section and any limitation. That gives the writer something more useful than a list of links.
For the weekly-summary example, it might verify which product can read the supplied files and which parts require a connector. Ask it to distinguish documented capability from your proposed way of using it. If it cannot access a source, that should remain visibly unverified.
Request an evidence file containing the claim, URL, supporting detail, access date and caveat. Prefer original documentation for product mechanics. Keep quotations short and use paraphrases for the draft.
The handoff passes when you can select any factual claim and find the supporting material without searching again.
For every script I run three researchers at once, each with a different job: one checks how the tool or feature actually works, one looks for a stat or source worth using, and one looks for anything that might be out of date. Running them in parallel is faster, and each one goes deeper than a single do-everything researcher.
part 04
2. The script writer returns a script your editor can film
Give the script writer a fixed format, so every script arrives ready to film instead of as a loose draft:
- An on-screen title. The text that shows in the first seconds, written so a silent viewer knows what the video is about.
- Three hook options. Each one uses a different angle, like a question, a surprising result or a relatable situation, so you pick the strongest on the day.
- The full script with a word count. Around 150 to 170 words lands close to 60 seconds, so the word count tells you if it will run long before you film.
- A caption with the keyword first. The comment keyword goes on the first line, and it must match what the video says.
The writer receives your audience notes, the voice log and the evidence file. It must not invent a time-saving figure or put a fictional personal story in your mouth. I keep every script as a row in one Notion database with a status column, so my editors always know what’s ready to shoot and nothing lives in a random doc.
Ask the writer to mark factual claims with their source in the working draft. Those references carry straight into the editing guide later.
part 05
3. The fact-checker gives specific corrections
Send the draft and original sources to a separate reviewer. Ask it to identify the exact line, what is wrong or unsupported, and a proposed correction that keeps the useful point.
A separate context can reduce the influence of the writer’s earlier reasoning, but it does not make the reviewer infallible. For claims that matter, check the evidence yourself. Anthropic’s Building Effective Agents describes a writer/reviewer pattern; the five-role arrangement here is our practical application.
For the weekly-summary carousel, test whether the instructions actually produce the promised output with a small sample. A source can confirm a feature exists while the draft still gives the reader an incomplete procedure.
Send corrections back to the writer, then check the changed lines. Set a limited revision cycle so agents don’t keep rewriting a draft without a clear reason.
part 06
4. The visual researcher turns the script into an editing guide
Instead of a separate list of visuals, ask this role for the script copied line by line, with the visual cue and the proof link directly under each line. Your editor then knows exactly what goes on screen for every sentence and where to grab the screenshot.
"Blotato can schedule one video to nine platforms."
[SCREEN: Blotato MCP setup page, crop the "What You Get" list]
proof: help.blotato.com/api/mcpAsk for one dominant visual per line and a crop that stays readable at phone size. A tiny full-page screenshot proves a page exists, but teaches very little. Include an original diagram only when it explains something more clearly than a screenshot, and label invented practice data as an example.
The role can suggest layouts, while you or your editor make the final creative decisions. It should flag access or reuse limits instead of treating every image online as free stock.
part 07
5. The scheduler posts the approved version everywhere
Once you approve the final video, the scheduler rewrites the caption for each platform and schedules it. The adaptation matters: a searchable title for YouTube Shorts, a casual caption for TikTok, a clear professional one for LinkedIn. It works only from the version you approved, and it must not strengthen “can help” into a guaranteed result.
For the posting itself, connect Blotato’s MCP server to Claude Code. From a single prompt, Claude can post to your connected accounts, schedule posts to your content calendar, and view or reschedule what’s queued. Blotato supports Instagram, Facebook, TikTok, YouTube, LinkedIn, X, Threads, Pinterest and Bluesky, with plans from $29 a month and a 7-day free trial (pricing).
Start on approval: schedule one post to a single platform, check it landed the way you expected, then let the scheduler queue the rest.
part 08
Paste this to create the first working setup
Use this in Claude Code inside your content folder. The prompt asks it to build the files and run a supervised first piece.
Set up a small content workflow in this project using five focused roles: researcher, script writer, fact-checker, visual researcher and scheduler. Inspect the existing files first and preserve my work.
Audience: [paste who you help].
Topic and useful outcome: [paste one topic and what the viewer should be able to do].
Voice examples: [file paths or pasted approved writing].
Sources: [URLs or file paths].
Output: one short-form video script plus an editing guide and platform captions.
Create concise project instructions and role definitions using current Claude Code subagent documentation. Create a voice-log.md file for before-and-after edits and tell the script writer to read it. Ask before overwriting an existing file. Give roles only the tools needed for their jobs. Use the main conversation to coordinate handoffs.
Researcher: run three focused passes (how it works, a stat or source worth using, anything out of date) and return claims linked to primary evidence, scope and anything unverified.
Script writer: return an on-screen title, three hook options, the full script with a word count aiming for about 60 seconds, and a caption with the lowercase comment keyword on the first line. No invented personal experience, statistics or testimonials.
Fact-checker: identify exact lines needing correction. Every number must have an openable source that proves that line; cut or rewrite anything unverified. Review the corrected version once.
Visual researcher: return the script line by line with the visual cue and proof link under each line, including exact capture areas. Label invented practice data as examples.
Scheduler: work only from the version I approve. Write a caption for each platform I use, with the comment keyword on Instagram only and a soft call to action elsewhere. If the Blotato MCP server is connected, prepare the scheduled posts but do not schedule anything until I say yes.
Create the files, then run research and drafting for the first piece. Stop with the script, evidence, review findings and editing guide ready for my inspection. Do not publish, send messages or invent a guide URL. Report which sources and procedures you actually checked.
part 09
Inspect the first handoff before expanding
Open the evidence file and choose three claims at random. Follow their links. Then read the draft aloud and compare it with your approved writing. Then hand one editing guide line to someone who hasn’t seen the project and check whether they can find the right asset. Finally, schedule one post to a single platform and confirm it landed correctly.
If the evidence is weak, tighten the researcher’s output. If the writing feels generic, add better voice examples and a specific audience situation. If the editing guide is vague, require exact capture areas. Fix the role responsible for the problem rather than adding another agent.
Your first action is to choose one topic and supply three voice examples. The setup is working when one piece reaches review with traceable claims, a script you could film today, a usable editing guide and captions ready to schedule. You can then save the procedures that actually helped and reuse them for the next piece.