Case Study — Multi-Agent System Design
ContentOps Squad: orchestrating 10 AI specialists for a one-person social media operation
A multi-agent system that replaced the always-on manual grind of running social media solo — trend research, content drafting, comment triage, reporting, pricing intelligence — with a single conversational entry point.
Problem
One operator, a dozen full-time jobs
The brand this was built for runs its entire social presence with no dedicated team — one person doing trend research, content drafting, comment moderation, competitor tracking, and performance reporting, all at once, every day.
None of that work is optional, and none of it is occasional — it's the daily floor every account needs just to stay alive, before anything strategic gets attempted. The question wasn't "can AI write a caption," it was: can a system absorb the repetitive, always-on parts of this job well enough that the operator's limited hours go to judgment calls instead of manual data pulls.
Design constraint that shaped everything downstream: no team to delegate to, and no budget for one. Every agent had to replace a real recurring task a human would otherwise have to do themselves — not assist a team that already had headcount.
Architecture
One orchestrator, ten specialists, one shared brain
A single entry point routes every request to the right station — or several, in parallel — while a shared knowledge base keeps judgment consistent across all ten.
%%{init: {'theme':'base', 'themeVariables': {
'background':'#14161c','primaryColor':'#22262f','primaryTextColor':'#ecedf1',
'primaryBorderColor':'#3a3f4c','lineColor':'#5b6270','secondaryColor':'#1b1e26',
'tertiaryColor':'#1b1e26','fontFamily':'ui-monospace, Consolas, monospace','fontSize':'13px',
'clusterBkg':'#1b1e26','clusterBorder':'#2b2f3a','edgeLabelBackground':'#14161c'
}}}%%
flowchart TB
T["'let's cook ...' request"] --> HC{{"Head Chef — orchestrator"}}
SC(["Sous Chef — strategic peer\n(campaign planning)"]) -. hands off paid execution .-> HC
subgraph RESEARCH["Research stations"]
direction LR
TS["Trend Scout"]
NS["News Scout"]
CoS["Competitor Scout"]
CmS["Community Scout"]
end
subgraph PRODUCE["Production & ops stations"]
direction LR
CD["Content Drafter"]
CT["Comment Triage"]
OR["Ops Reporter"]
TK["Timekeeper"]
end
subgraph GROWTH["Growth stations"]
direction LR
GM["Growth Marketer"]
PS["Price Scout"]
end
HC --> RESEARCH
HC --> PRODUCE
HC --> GROWTH
TS -->|"digest feeds"| CD
NS -->|"digest feeds"| CD
KB[("Shared knowledge base\ncompany · audience · patterns")]
KB --- RESEARCH
KB --- PRODUCE
KB --- GROWTH
OR -->|"performance data"| KB
CD --> APPROVE{{"Human approval"}}
APPROVE --> POST["schedule & post\n(mechanical layer)"]
classDef station fill:#22262f,stroke:#3a3f4c,color:#ecedf1;
classDef hub fill:#e8873a,stroke:#e8873a,color:#1b120a,font-weight:bold;
classDef kb fill:#1b1e26,stroke:#e8873a,color:#e8873a,stroke-dasharray: 3 3;
class TS,NS,CoS,CmS,CD,CT,OR,TK,GM,PS,POST station;
class HC,APPROVE hub;
class KB kb;
Rendered live — orchestrator + 10 stations + strategic peer agent + shared knowledge base + mechanical posting layer.
Request Flow
What happens between a request and a result
- 01
Receive
A natural-language request comes in via a fixed wake phrase — no need to remember exact agent names or commands.
- 02
Decompose & route
Works out which station(s) the request maps to, using a routing table of request signals — never guesses silently when a request doesn't clearly match one.
- 03
Sequence
Independent subtasks run in parallel in a single dispatch; known dependencies (content drafting needs a fresh trend digest) run in order automatically.
- 04
Delegate
Each station reads the shared knowledge base — brand context, audience behavior, proven content patterns — before producing anything, so judgment stays consistent across all ten.
- 05
Aggregate
Results merge into one coherent response. Anything needing a human call — an urgent complaint, a credential about to expire — gets surfaced explicitly, not buried.
- 06
Learn
The reporting station critically analyzes why content performed, not just what the numbers were, and writes validated findings back into the shared knowledge base — every future run starts a little smarter than the last.
The Stations
Ten specialists, one job each
01 · RESEARCH
Trend Scout
Daily platform-split trend digest, with a hard rule against reporting stale trends as current — a publish date isn't the same as when a trend actually peaked.
02 · RESEARCH
News Scout
Same-day industry news digest ranked by urgency, flagging genuine scoops vs. playing catch-up to established outlets.
03 · PRODUCE
Content Drafter
Captions and scripts in a voice calibrated against real performance data, not a guessed house style.
04 · PRODUCE
Comment Triage
Sorts a comment/DM backlog into spam, question, complaint, praise — drafts replies, flags what needs a human, even on weekends.
05 · OPS
Ops Reporter
Pulls live metrics, computes engagement rate, and explains why content performed — the source of the system's learning loop.
06 · OPS
Timekeeper
Tracks every deadline and nudges the right party. Deliberately does nothing else — no planning, no drafting, no approving.
07 · RESEARCH
Competitor Scout
Reviews a curated shortlist of competitors already winning at social — what's actually working, not a full market audit.
08 · RESEARCH
Community Scout
Reads unstructured peer-to-peer discourse for signal the algorithm and the competitors both miss. Observation only — never posts, comments, or votes.
09 · GROWTH
Growth Marketer
Owns paid media and CRM/lifecycle — a genuinely different discipline from organic content, kept as its own station rather than diluting two others.
10 · GROWTH
Price Scout
Same-SKU pricing comparison against competitors — flags suspiciously-low pricing as a trust risk, not just a win.
Engineering Decisions
Judgment calls that shaped the system
Caught a namespace collision before it became a credential leak
Making the system's agents live on a shared machine surfaced skill directories with names identical to another already-installed project's — one holding real API credentials and webhook URLs. Installing over them risked either silent config failure or, worse, this system's reporting reading someone else's live credentials. Renamed every colliding path, updated every cross-reference, and verified zero collisions with a real install run — not just an assertion.
Audited portability instead of assuming it
Asked whether the system could run on a different machine. Found every agent hardcoded an absolute output path and the install script had zero collision protection. Fixed both, and explicitly documented the handful of things that genuinely can't be automated away — API credentials, browser login sessions — rather than pretending a path fix solved everything.
Added a new station only after ruling out duplication
Before building community listening, checked it against two existing research stations. It wasn't redundant: one reads algorithmic virality, one reads curated competitor accounts, neither reads how the audience actually talks to itself. One of the brand's strongest differentiators had already been found by accident, buried in unrelated research, before this station existed to look for signal like it on purpose.
Kept tracking scope deliberately minimal
Rather than building a full analytics stack for a solo operation, shipped tracking on exactly the two placements that carry a clickable link, and left every other format explicitly labeled engagement-only. The highest-value open question didn't need heavier infrastructure to answer.
Capabilities
What this required, in general terms
Building something like this?
I design and build multi-agent AI systems end to end — orchestration, prompt engineering, and the un-glamorous plumbing that makes them reliable.
Case study by Marvel Sutantio · brand names and internal identifiers genericized for confidentiality · architecture, decisions, and system logic unmodified.