A social media agent for agencies works best when you treat it like a junior account manager: one per client, with its own scope, its own voice rules and its own connected accounts. Creator OS supports that model directly. Each API key is pinned to a single workspace, which means one set of socials, and an agent holding one workspace’s key cannot post to another. That one constraint is the difference between a clean agency setup and a mess where three clients get each other’s captions.
Agency AI agent setup (one workspace per client)
+----------------+ +----------------+
| Workspace: A | | Workspace: B |
| cos_live_A... | | cos_live_B... |
| IG, TT, YT, X | | IG, LI, FB |
| brand: voice A | | brand: voice B |
+--------+-------+ +--------+-------+
| |
agent A (Claude) agent B (Claude)
posts, replies, posts, replies,
weekly report weekly report
| |
+----------+-----------+
|
Creator OS MCP or CLI
https://mcp.creatoros.ca/mcp
Why One Agent per Client Beats One Agent for Everything
A single agent that serves your whole roster has to hold every client’s credentials, voice guide and posting rules in one context. That fails in two directions. First, voice: an Instagram caption for a fitness client and a LinkedIn post for a B2B client come out of the same memory, and the model averages them into something generic. Second, blast radius: one mistaken publish hits every brand at once, because the agent’s token can reach every account.
Creator OS makes the split at the workspace level. A REST API key (cos_live_...) is pinned to one workspace, which is one set of socials. An agent holding that key cannot post to another workspace. If you run a Claude connector instead of a key, you sign in and pick the workspace during setup, and you can choose read only or read & write. Read-only connections only see read tools, and the API refuses writes from them. That gives you a clean read-only agent for reporting and a separate read & write agent for publishing.
The practical version: ten clients, ten workspaces, ten keys, ten agents. Each agent has a small context, a short system prompt and no access it should not have. If you want the longer argument for this shape, the AI agent for agencies post covers it.
What a Social Media Agent Actually Does for an Agency
An agent on Creator OS is not a chatbot that drafts captions. Through the hosted MCP server, it gets a defined tool surface: create_post, update_post, list_posts, get_post_analytics, get_daily_metrics, get_best_time_to_post, get_follower_stats, list_comments, reply_to_comment, list_conversations, send_message, create_automation, links_create, links_stats, and more.
Those tools cover the daily work: publish, schedule, reply, read numbers. The platform rules still apply. If your Instagram client wants a custom Reel cover, that comes through the cover settings. If a TikTok post needs the Creator Inbox flow, you send it as a draft. If a network in a post is not connected, it comes back in missing_platforms and the rest still go out. An agent that understands this is useful. An agent that assumes every platform behaves the same will fail at the first TikTok publish.
There is also a set of prebuilt Claude Code skills: post-everywhere, post-shortform, post-longform, post-threads, schedule-posts, respond-to-comments, respond-to-dms, automations, analytics, ads, skool, blog. You install them with npx @creatoros/cli@latest init and refresh with creatoros sync, which writes updates as .new files instead of overwriting anything you edited. See the agent skills post for how to bend those to client workflows.
Comment replies work on Instagram, Facebook, X, Threads, YouTube and LinkedIn. DMs work on Instagram, Facebook and X. Keyword-based comment-to-DM funnels work on Instagram and Facebook. TikTok comments are not replyable through the API, which matters when you promise a client a reply SLA. Set that expectation per client, not per agency.
How to Spin Up a Dedicated Agent for Each Client
Here is the whole onboarding for one new client, end to end.
- Create a workspace for the client in Creator OS and connect its accounts.
- Generate an API key for that workspace only.
- Add the MCP server to your AI app with that key. For Claude Code the command is:
claude mcp add --transport http creatoros https://mcp.creatoros.ca/mcp --header "Authorization: Bearer cos_live_..." - Write a short client brief file: brand voice, banned words, hashtag rules, approval chain, posting windows.
- Run one supervised week: the agent drafts, you approve each item.
Step 3 works across the AI apps you already use. Claude takes the connector through Settings > Connectors. ChatGPT takes the same URL as a connector in developer mode. Cursor, Windsurf and VS Code take an mcpServers entry with type http and the Authorization header. Nothing to install for the hosted server. Setup details live at the MCP docs.
If you would rather skip MCP for a scripted workflow, the CLI covers the same ground from a terminal:
creatoros auth:check
creatoros accounts:list
creatoros posts:create --text "Launch day: doors open at 9am." \
--platforms instagram,threads --media "https://cdn.example.com/launch.jpg" \
--scheduledAt 2026-03-04T14:00:00Z --timezone America/Toronto
creatoros validate:post-length --text "Launch day: doors open at 9am."
creatoros posts:list --status scheduledRun creatoros auth:check first. It tells you which workspace the key points at, so you never publish into the wrong client’s calendar. The CLI docs list every command and flag.
If you prefer an open-source harness instead of wiring this yourself, Social Agents is available at github.com/kevinbadi/social-agents. It interviews you about the brand, then posts, replies to comments and DMs, runs automations and reports, with a local dashboard. Start it with npm start creatoros social-agents. Bring your own model: a logged-in Claude Code session, an ANTHROPIC_API_KEY, or any Anthropic-compatible API. In an agency that becomes one harness run per client workspace. Kevin walks through these builds on the KevBuildsApps YouTube channel, and the launch video shows the starting point.
Keeping Brand Voice and Approvals Separate
Voice lives in the agent’s system prompt and brief file, not in the model. Two habits keep it from drifting:
- Put each client’s voice rules in its own file and paste only that file into that agent’s context. Never let one agent read another client’s brief.
- Keep the approval gate in the tool call, not in your head. Creator OS supports
drafton posts,--draftin the CLI, so the agent can schedule without publishing, and a human releases it.
Destructive tools such as deleting a post, deleting a comment, disconnecting an account or deleting an ad are marked so the AI app asks before running. That is a useful default for junior staff and for any agent you have not fully audited. Pair it with a dry run on anything paid: creatoros ads:create takes --validateOnly, budgets are confirmed, and ads are created paused for review. Every create can be dry-run, which is how you let an agent touch a client’s ad budget without holding your breath.
Scaling From 3 Clients to 30 Without New Hires
The reason per-client agents scale is that onboarding becomes a template, not a project. Once one client runs cleanly, the second client is a copy of the brief with new voice rules, a new workspace and a new key. Nothing in your architecture changes.
On Creator OS, the plan structure follows the same shape. The Creator plan is $19.99/month or $59.99/year with up to 8 connected accounts: 7 socials plus Skool. Agency plans cover 5 sets of socials (up to 40 connected accounts) for $49/month or $399/year, and 10 sets (up to 80 accounts) for $99/month or $599/year. YouTube network plans are 5 channels for $19.99/month and 10 channels for $29.99/month. API keys, the MCP server, the CLI and the agent skills are included in every plan, so adding an agent does not add a line item.
Compare that against what you bill for coordination time. The scaling question is not “can the agent post,” it is “can I hand a new account to the same workflow I already trust.” A per-client workspace makes that answer yes. The social media management for agencies post covers the account structure in more depth.
Reporting: One Dashboard, Every Client’s Numbers
Reporting is where shared agents fall apart. If one agent reads metrics for five clients, someone eventually sends Client A’s engagement numbers to Client B.
With one agent per workspace, each agent only sees its own numbers. Per-post analytics, daily account metrics, follower stats and best time to post are all pulled through the same tool names: get_post_analytics, get_daily_metrics, get_follower_stats, get_best_time_to_post. Short links created with links_create carry click stats through links_stats, which gives you a clean traffic number for a client that does not live inside a platform dashboard. For a closer look at wiring those numbers into a client-facing report, see the analytics API post.
A monthly report loop that works: ask each client’s agent for the last 30 days of daily metrics, per-post top performers and follower trend, then have it write the summary in that client’s tone. Same template, thirty different outputs, zero cross-contamination.
Common Mistakes When Agencies Share One Agent
- One key for every client. Keys are workspace-scoped on purpose. Sharing one defeats the boundary and means a prompt injection in a comment thread could reach every account you manage.
- One voice prompt with client names as variables. It averages. Voice guides need their own file and their own agent.
- Skipping the read-only tier. A reporting-only agent should be read only. The API refuses writes from read-only connections, so the mistake becomes impossible rather than merely discouraged.
- Letting the agent publish without drafts. Use drafts until the agent has a track record on that specific client.
- Assuming every platform replies the same way. TikTok comment replies are not supported. LinkedIn does not do DMs. Instagram captions have no clickable links, so first-comment link handling matters.
- Promising response times you cannot automate. All DMs land in one inbox, which is a good place to work from. It still needs a human for the hard ones. The one inbox post shows the workflow.
Pricing and Time Savings You Can Show Clients
Do not sell “AI” to a client. Sell the pieces they can see. A per-client agent produces: scheduled posts that go out on time, comment replies within the window you agreed, a monthly report with the same sections every month, and a short-link click number that maps to their site. On the Creator OS side those cost $19.99/month for a single-client setup, or $49/month for an agency tier covering 5 sets of socials. The ads add-on is $19.99/month on any plan with no percentage of ad spend, and ad spend is billed by each network to the client’s own ad account.
That last detail is the one clients ask about. You are not marking up media spend and you are not holding their card. It also means the invoice conversation is simpler.
Get Started With Creator OS
Pick your smallest client. Create a workspace, connect the accounts, generate a key, add the MCP server, and run one supervised week. If you want the scripted route instead, install the CLI with npx @creatoros/cli@latest init and use creatoros posts:create --draft for the first batch.
The Creator plan is $19.99/month or $59.99/year for up to 8 connected accounts, and agency tiers start at $49/month for 5 sets of socials. Start at creatoros.ca/sign-up, and keep the docs open while you wire your first agent.