How to Plan a Multi-Agent AI Automation for Facebook & Instagram Comments and DMs That Handles Every Edge Case (Free, Self-Hosted Stack)

Key Takeaways

• Meta automation is harder than WhatsApp because you handle two surfaces — public comments and private DMs — across two platforms, where a wrong public reply is a brand-safety incident, not a private mistake.
• A multi-agent design of single-responsibility agents over shared state is what lets you triage real questions from spam and trolls, decide public-reply vs comment-to-DM, moderate, and freeze during a crisis — things one mega-prompt cannot do.
• Give each agent one job: intake/de-dupe, event classification (comment vs DM, FB vs IG), identity (new or in database), context, behaviour/triage, moderation, knowledge, response-strategy, conversation, compliance, logging, and escalation.
• Build it free and self-hosted — n8n, Docker, Ollama, PostgreSQL, Google Sheets/Docs — on top of Meta's official Graph API (free, but needs an app, Page tokens, an IG professional account, webhooks, and permission review).
• Public visibility changes everything: a Moderation agent to hide/report abuse and spam, a Response-Strategy agent to decide when NOT to reply publicly, and an Escalation agent to catch viral negativity are first-class parts of the design.
• Edge cases are the game — duplicate webhooks, comment storms, trolls, edited/deleted comments, the DM window, genuine-question-vs-noise, and public hallucination — because on social a mistake is a screenshot everyone sees.

Why Meta Comments & DMs Break Naive Bots — and Why It's Harder Than WhatsApp

Automating replies on Facebook and Instagram looks like the same problem as a WhatsApp bot — messages come in, the AI replies — but it is meaningfully harder, and the reasons are exactly what a single mega-prompt bot cannot handle. The first difference is that you are dealing with two surfaces at once: public comments that anyone can see, and private DMs (Messenger and Instagram Direct). A reply in a DM is a private conversation; a reply on a public comment is a published statement on your brand's page that competitors, journalists, and every other follower can read and screenshot. The stakes and the correct behaviour differ completely between the two, and a bot that treats a public comment like a private message — replying at length, or worse, replying wrongly — creates a brand-safety incident, not a private mistake. The second difference is that you are on two platforms, Facebook and Instagram, which share Meta's Graph API but differ in mechanics, tone, and audience.

The third and deepest difference is that public comments are full of things that are not customers. A WhatsApp message is almost always a real person with real intent. A comment section contains genuine questions, yes — but also spam (link-droppers, promo bots), trolls and abuse, competitors, praise emojis ('🔥🔥'), one-word noise ('nice'), tags of friends, and, occasionally, a viral negative comment that is the start of a PR crisis. A naive bot that tries to 'reply to every comment' with one prompt will earnestly answer '🔥', argue with a troll in public, reply to spam, and — catastrophically — auto-generate a chirpy AI reply under a viral complaint about your product, turning a bad moment into a screenshotted disaster. It has no concept of moderation (should this comment be hidden or reported rather than answered?), no concept of when to move a conversation from public to private, and no concept of when to shut up and escalate.

There is also an identity wrinkle unique to Meta: the same person appears under different platform-scoped IDs depending on the surface. A commenter's ID on a post is not the same as their messaging ID (PSID/IGSID), and you cannot freely link a public commenter to a DM identity or across Facebook and Instagram without the platform's consent mechanics. So 'is this person new or already in our database?' — the identity question — is more nuanced than a phone-number lookup: it is scoped per surface and platform, and your data model has to respect that. A mega-prompt bot has no data model at all, so it has no memory of anyone and re-meets every commenter as a stranger.

The fix is the same architectural principle as any robust AI system — decompose the bot into small, single-responsibility agents coordinated by an orchestrator over shared state — but the agent roster and the edge cases are shaped by these Meta realities: an agent whose only job is to classify comment-versus-DM and Facebook-versus-Instagram; an agent whose only job is triage (is this a real question, spam, a troll, praise, or a crisis?); an agent whose only job is moderation (hide, delete, report, or leave); an agent whose only job is to decide the response strategy (reply publicly, move to DM, react, or ignore); and an escalation agent tuned to catch public PR risk. This guide is the complete plan for building that, free and self-hosted, on top of Meta's official Graph API — and if you have read our companion guide on multi-agent WhatsApp automation, this is the public-social sibling, sharing the architecture but diverging everywhere public visibility and moderation change the rules.

The Architecture: Two Surfaces, Two Platforms, One Agent Pipeline

The architecture keeps the same three layers that make any multi-agent system reliable — an orchestrator that conducts, specialist agents that each do one job, and shared state they coordinate through — but it is organized around the fact that a single pipeline must handle four kinds of inbound event across two platforms. The four event kinds are: a public comment (on a Facebook post or an Instagram post/reel), a private message (Messenger or Instagram Direct), a mention or tag (someone @-mentions your page, or an Instagram story mention), and a reaction or edit/delete (a like, or a comment being edited or removed). The orchestrator — an n8n workflow — receives all of these through Meta's webhook, and its first real job is not to reply but to figure out what kind of event this is and route it, because a public comment and a private DM travel very different paths through the agents.

The specialist agents are the players, each with one narrow job, and the roster is larger than the WhatsApp one precisely because public social adds responsibilities: classification (comment vs DM, FB vs IG), triage (real vs spam vs troll vs noise), moderation (hide/report), and response strategy (public vs private). Some agents are pure logic (the identity lookup is a database query; de-duplication is an idempotency check); some are small classification LLM calls (triage, behaviour, moderation decisions); one is the heavier conversation model that composes replies — and critically, that conversation agent operates in two modes, public-comment mode (short, on-brand, aware that the whole world reads it) and DM mode (fuller, more conversational). Keeping each agent narrow is what lets you tune the public-reply behaviour independently from the DM behaviour, and the moderation behaviour independently from the conversation behaviour — impossible in a single prompt.

The shared state lives in PostgreSQL, and it must model the Meta realities: contacts keyed by platform-scoped ID (with the honest limitation that a comment identity and a DM identity for the 'same' human may be separate rows until the platform links them), the objects being commented on (posts, ads, reels), comment threads, message threads, per-thread state (is a human handling this? is the DM 24-hour window open?), moderation actions taken, behaviour profiles, and logs. Because comments are public and moderation actions (hiding, deleting) are consequential and visible, the state must also record every moderation decision and every public reply as an auditable action — on public social, you need to be able to answer 'why did our page hide that comment?' precisely. The orchestrator sequences the agents; the shared state is how they coordinate; and the whole design maps onto the free stack exactly as the WhatsApp system does: n8n for orchestration, agents as sub-workflows and LLM calls, Postgres for state, Google Sheets/Docs as human-editable views. Plan the state model first, the agents second, the orchestration third — and design the public-vs-private fork into all three from the start.

The Free, Self-Hosted Stack — and Meta's Graph API Reality

The brain and orchestration are free and self-hostable with the same five components as any multi-agent automation, and understanding each component's job — plus the honest realities of Meta's API — is part of planning. n8n is the orchestrator: it receives Meta's webhook, runs the agent pipeline, calls the Graph API to post replies or moderate, and reads/writes the database. Docker runs n8n, PostgreSQL, and Ollama together from one compose file on a cheap host. Ollama runs open-weight LLMs locally and free for the many small agent calls — classifying comment-vs-noise, triaging sentiment, deciding moderation — where a small model is fast and sufficient, with a larger model (local or hosted) for composing public and DM replies where quality and brand tone matter more. PostgreSQL is the shared state: contacts, objects, threads, moderation actions, behaviour, and logs. Google Sheets is a human-facing view (a queue of escalated comments, a leads tab, a moderation log a human reviews) and Google Docs is the editable knowledge base and the brand-voice/response-policy guide that the conversation and moderation agents read.

The honest reality is that the channel — Meta itself — is where 'free' comes with real setup and constraints, more so than WhatsApp. You interact with Facebook and Instagram through Meta's official Graph API (and the Messenger Platform and Instagram Messaging APIs), which are free to use but require genuine setup: a Meta developer account and app; a Facebook Page and, for Instagram, an Instagram professional (business or creator) account linked to that Page; Page access tokens with the right scopes; webhook subscriptions for the events you want (feed/comments, messages, mentions); and — importantly — Meta App Review to obtain the permissions needed for messaging and comment management in production, because the sensitive permissions (managing comments, sending messages) are gated behind review. There is no compliant unofficial shortcut: automating a personal account or scraping violates Meta's terms and gets accounts restricted or banned, so the official Graph API is the only responsible foundation, and the free stack is the intelligence layer on top of it.

Two more Meta-specific constraints shape the build. First, messaging (DMs) is governed by a 24-hour window like WhatsApp: you can freely reply to a user within 24 hours of their last message, and outside it you are limited to specific message tags or the human-agent handover mechanism (which grants a longer window when a human is involved) — so the compliance agent must track this per DM thread. Second, comment management and messaging are rate-limited by the Graph API, which matters enormously during a viral post when thousands of comments arrive at once; the system must queue and prioritize rather than hammer the API. The table below summarizes the stack and the Meta channel realities, so you plan around them rather than discovering them in production.

The Agent Roster — Every Agent and the One Job It Owns

This is the core of the plan: the roster of single-responsibility agents, expanded for public social. Each owns one job describable in a sentence, and the orchestrator runs the subset each event needs. The front of the pipeline is about receiving and understanding what came in. The Intake agent's only job is to receive Meta's webhook, normalize the payload into an internal event object (platform, surface, object ID, thread ID, author's scoped ID, content, timestamp, event type), and de-duplicate it against processed event IDs — because Meta, like any webhook provider, can deliver events more than once, and moderating or replying twice is both embarrassing and, for moderation, potentially destructive. The Event Classifier agent's only job is to determine what kind of event this is and route it: public comment or private DM? Facebook or Instagram? a new comment, an edit, a delete, a mention, or a reaction? This classification forks the entire downstream pipeline, because the public and private paths diverge immediately.

The next agents establish identity and context, with Meta's scoped-identity nuance. The Validation / Identity agent's only job is to look up the author's platform-scoped ID in the database and decide whether this is a new contact or one already in your database, creating or loading the record — while respecting that a commenter ID and a DM ID may be distinct and that cross-surface linking only happens through the platform's consented mechanisms. The Context agent's only job is, for a known contact, to recall prior interactions — have they commented before, do we have an open DM thread, are they a repeat positive commenter or a repeat complainer — and produce a compact context summary. Then comes the agent that public social makes essential: the Behaviour / Triage agent, whose only job is to classify the comment or message into the category that determines everything — genuine question, sales lead, complaint, praise, spam, troll/abuse, competitor, or low-value noise — along with sentiment and language. This triage is the single most important classification in the whole system, because on a public comment the right action is often not to reply at all, and you cannot decide that without knowing what the comment is.

The middle agents decide what to do and prepare the response. The Moderation / Brand-safety agent's only job — for comments — is to decide whether the comment should be hidden, deleted, reported, or left, based on the triage: spam and clear abuse get hidden or reported, borderline cases get flagged for human review, genuine comments are left for a reply. This is a public-social-specific agent with real consequences, so it errs toward flagging for humans on anything ambiguous rather than auto-deleting. The Knowledge / RAG agent's only job is to retrieve the right information to answer a genuine question, grounding replies in your actual product/FAQ content (kept in Google Docs). The Response-Strategy agent's only job is to decide the response mode: reply publicly (short, helpful), reply publicly and move to a DM (the comment-to-DM pattern, for anything needing detail, personal data, or a sales conversation), send a private reply to the comment (Meta allows one private reply to a commenter), react/like only, or do nothing. This agent encodes the crucial public-social judgment of when and where to respond, which a mega-prompt bot lacks entirely.

The back of the pipeline composes, checks, acts, and records. The Conversation agent's only job is to compose the reply in the mode the strategy agent chose — a short, on-brand public comment reply, or a fuller DM reply — grounded in the retrieved knowledge and context; because everything it needs was prepared upstream, its prompt is clean and mode-specific. The Compliance / Guardrail agent's only job is to check that the action is allowed and safe before it happens: for DMs, is the 24-hour window open or is a message tag / human-agent handover required; for public replies, does the drafted reply meet brand and policy guardrails and avoid prohibited claims; for moderation, is the action within policy. The Logging / Records agent's only job is to write everything to Postgres — the event, every agent decision, the reply or moderation action taken, and any records (a new lead, a logged complaint) — and to the Google Sheet humans watch. The Escalation agent's only job is to detect when a human must take over — a viral negative comment or a surge of negativity (a PR event), a sensitive public complaint, a high-value lead, low confidence, or an explicit request — and to route it to a person while pausing autonomous replies on that thread. And the Follow-up agent's only job is to schedule re-engagement (e.g., following up in a DM after a comment-to-DM handoff) within the rules. The table below is the roster reference.

The Data Model — Postgres for Public and Private State

The data model must represent both surfaces and the public-social realities, and designing it well is most of designing the system. At minimum you need: a contacts table keyed by platform-scoped ID (platform, id_type — comment author vs messaging PSID/IGSID — plus name if available, status, and any linkage the platform has confirmed), acknowledging that the 'same person' may exist as more than one row until consented linking occurs. An objects table for the things being engaged with — posts, reels, ads (dark posts) — so you know what a comment is about, whether it is on an ad, and can attach post-level context and post-level moderation policy. A comments table logging every comment and reply with its comment ID, parent, author, content, timestamp, the triage/moderation decision, and any reply posted. A messages table for DM threads, mirroring the WhatsApp model, with per-thread state including the 24-hour window's last-inbound timestamp.

Public social adds tables the WhatsApp system does not need. A moderation_actions table records every hide/delete/report/flag with the reason and the agent (or human) who decided it — because moderation is consequential and visible, and you must be able to justify every action taken on your public page. A processed_events (idempotency) table records handled event IDs so duplicate webhooks do not cause double replies or double moderation. A behaviour_profiles table accumulates what you know about a contact across their interactions (repeat commenter, sentiment history, is-a-known-troll, is-a-lead). And an escalations / crisis table tracks flagged threads and any detected surge in negativity, which is how the system recognizes a developing PR event rather than treating each angry comment in isolation. This last point is important and unique to public social: a single negative comment is routine, but a rapid cluster of negative comments on one post is a signal that must aggregate across events — so the state has to support that aggregation.

The transactional guarantees Postgres provides matter here as they do everywhere agents share state, but public social adds a specific reason: moderation actions must not race or double-fire. If a comment storm triggers overlapping processing of the same comment, you could hide it twice or hide-then-reply incoherently; per-object/per-comment locking and idempotency prevent that. Google Sheets, as always, is the human-friendly projection — a moderation review queue where a person can approve borderline hides, an escalations queue for PR-sensitive threads, and a leads tab for comment-to-DM conversions — synced from Postgres, which remains the system of record. When you design your schema, drive it from the questions the agents ask: 'is this author known?' (contacts), 'what is this comment about?' (objects), 'have we seen this event?' (processed_events), 'what did we decide and do?' (comments/moderation_actions/logs), 'is this thread escalated?' (escalations), 'is a negativity surge building?' (aggregate over comments/escalations). If every agent's read and write maps to this schema, the agents stay simple and the public-social behaviour stays auditable.

The Event Lifecycle — Following a Comment and a DM Through the Agents

The clearest way to see the system work is to follow two events — a public comment and a DM — through the pipeline, which is also how you should test any design. First, a public comment: someone comments 'Does this come in blue? And how much?' on your Instagram product reel. Meta posts the webhook to n8n. The Intake agent normalizes it and checks the idempotency table — new, so it proceeds. The Event Classifier identifies it: Instagram, public comment, new comment on a product reel. The Validation agent looks up the commenter's scoped ID: a returning commenter who has engaged before. The Context agent recalls prior interactions. The Behaviour/Triage agent classifies it: genuine product question with buying intent, positive sentiment, English — a real lead, not noise. Because it is a genuine comment (not spam or abuse), the Moderation agent leaves it up. The Response-Strategy agent decides: this needs specific info (colour, price) and has buying intent, so reply publicly with a brief helpful answer and move the detail to a DM — the comment-to-DM pattern.

The Knowledge agent retrieves the colour options and price; the Conversation agent composes two things in the right modes: a short public reply ('Yes — it comes in blue! Sending you the details in your DMs 💙') and a fuller DM with the options, price, and a link. The Compliance agent checks each: the public reply meets brand guardrails; the DM is a business-initiated message to someone who just engaged publicly — here the system uses the allowed private-reply-to-comment mechanism (or, if a DM thread exists within the window, replies there), respecting Meta's messaging rules. The replies go out via the Graph API. The Logging agent records the comment, the triage and strategy decisions, both replies, and creates a lead record, projecting it to the Sheet the social/sales team watches. The Follow-up agent schedules a gentle DM follow-up if the lead goes quiet. If the triage had instead flagged the comment as spam, the Moderation agent would have hidden it and the pipeline would have stopped — no reply. If it had been abusive, hidden/reported and logged. If it had been '🔥', the Response-Strategy agent would choose react/ignore, not a reply.

Now a DM: someone messages your Facebook Page 'my order hasn't arrived and it's been two weeks, this is ridiculous.' Intake de-dupes; the Event Classifier routes it as a Facebook private message; Validation finds the contact; Context recalls their order-related history; the Behaviour/Triage agent classifies it as a complaint with negative, urgent sentiment. This is where the paths differ from a happy question: the Escalation agent's rules fire on a strongly negative complaint about a concrete failure (undelivered order) — this is sensitive and better handled, or at least verified, by a human, so the system may either compose an empathetic holding reply and escalate to a person, or route straight to a human, pausing autonomous replies on the thread. The Compliance agent confirms the DM window is open (they just messaged). The Logging agent records the complaint and the escalation. Nothing about this gets a breezy auto-generated 'thanks for reaching out!' — because the triage and escalation agents recognized it as the kind of message where a wrong autonomous reply does damage. That discrimination — routine question handled autonomously, sensitive complaint escalated, spam moderated, noise ignored — is the entire point of the multi-agent design, and it is invisible to a mega-prompt.

How to Properly Plan It — the Methodology

Planning a Meta comment-and-DM automation follows the same disciplined order as any multi-agent system, with public-social concerns designed in from step one. Step one is to enumerate the real event types and desired outcomes across both surfaces: genuine product questions (comment and DM), leads, complaints, praise, spam, trolls/abuse, competitor comments, mentions, and the crisis case of viral negativity — for each, what should happen (reply publicly, move to DM, moderate, ignore, escalate). This inventory is your requirements and it must explicitly include the 'do not reply' and 'moderate' and 'escalate' outcomes, because on public social those are as important as the reply outcomes, and a plan that only lists 'answer questions' will build a bot that answers trolls and spam. Step two is to design the state model from those requirements — including the public-social tables (objects, moderation_actions, escalations) — so every question the agents ask has an answer.

Step three is to decompose into agents by single responsibility, writing each agent's contract (input → output) before building it, and being deliberate about the public-social agents that have no WhatsApp equivalent: the Event Classifier (comment vs DM), the Triage agent (real vs spam vs troll vs noise), the Moderation agent (hide/report), and the Response-Strategy agent (public vs private vs ignore). Step four is to design the orchestration flow with the public and private branches explicit, and with early-exit paths for spam (moderate and stop), noise (ignore), and escalation (hand to human, stop autonomous replies). Step five — the one that matters most on public social — is to plan the edge cases and the moderation and escalation policy explicitly and conservatively, because the cost of an error is public. Step six is observability and testing: log every agent decision and moderation action (you must be able to audit why the page did anything publicly), and test with replayed real comment threads including storms, trolls, and edited/deleted comments. Only then do you write the actual reply prompts (public mode and DM mode), which stay short because the other agents did the work.

A specific planning discipline for public social is to write the response and moderation policy as an explicit document (a Google Doc the agents read and humans own) rather than burying it in prompts: what categories of comment get a public reply, which get moved to DM, which get hidden, which get reported, which get escalated, and what the brand voice is for public replies. This policy document becomes both the specification the agents implement and the thing a human can edit without touching code — and on public social, where the rules of engagement are a brand and even legal matter, having them written down and owned by a human is essential. The meta-point of the methodology is the same as always — the prompt is the last and smallest step, and the value is in the requirements, state, agents, flow, and edge cases — but on Meta the moderation and escalation policy and the public-vs-private strategy are elevated to first-class planning artifacts, because getting them wrong happens in public. If you want help designing this — the architecture, the agent roster, the moderation/escalation policy, and the edge-case plan — for your Facebook and Instagram presence, that is exactly the kind of automation and RevOps work our team does.

Handling Every Edge Case — Where Public Social Bots Die

Edge cases are where naive social bots die publicly, and on Meta the edge cases are both more numerous and more consequential than on WhatsApp because they happen where everyone can see. Start with delivery and volume. Duplicate webhooks: Meta can deliver an event more than once, so the Intake agent de-duplicates on event ID — doubly important here because a duplicate could double-moderate (hide something twice) or double-reply publicly. Comment storms on a viral post: a post can suddenly attract thousands of comments, which will blow through Graph API rate limits and overwhelm any per-comment processing; handle it by queuing all comments, prioritizing by triage (answer genuine questions and catch complaints first, batch-moderate obvious spam, ignore noise), and rate-limiting your API calls so you stay within Meta's limits rather than getting throttled or blocked. A viral post is exactly when your automation is most visible and most stressed, so it must degrade gracefully — prioritize and queue, never hammer.

Then the content-and-safety cases that define public social. Trolls and abuse: the Triage and Moderation agents identify hateful, harassing, or abusive comments and hide or report them per policy rather than engaging — you never argue with a troll from the brand account, because that is the screenshot that goes viral. Spam: link-droppers and promo bots get hidden/deleted, not replied to. Competitor comments: identified and left alone or handled per a defined policy, never taken as bait. Genuine-question-versus-noise: the Triage agent must distinguish a real question deserving a reply from '🔥', 'nice', or a tag of a friend — replying to noise is both wasteful and off-putting, so the Response-Strategy agent chooses react-or-ignore for low-value engagement rather than generating a reply to everything. The viral negative comment / PR crisis: this is the most dangerous case — a single strongly negative comment, or a rapid surge of negativity on one post, must trigger the Escalation agent to freeze autonomous replies on that object and alert a human immediately, because the one thing that turns a complaint into a crisis is a tone-deaf automated reply under it. The system aggregates negativity per object (using the escalations/behaviour state) precisely to catch this early.

Then the platform-mechanics cases. Edited and deleted comments: Meta sends webhooks for edits and deletes, and the system must handle them — never reply to a comment that has been deleted (check it still exists before acting), and re-evaluate an edited comment rather than acting on stale content. The 24-hour DM window and message tags: for DMs, the Compliance agent tracks the last-inbound time per thread and only sends freely within 24 hours; outside it, it uses an allowed message tag or the human-agent handover window, or holds — sending outside the rules gets messaging access restricted. Private-reply-to-comment limits: Meta allows a private reply to a comment only once and within a window, so the Response-Strategy and Compliance agents must respect that mechanic rather than assuming a DM can always be opened from a comment. Instagram-versus-Facebook quirks: the two platforms differ in messaging rules, comment mechanics, and available actions, so the Event Classifier's platform branch matters and the agents apply per-platform rules. Identity across surfaces: because a commenter and a DM sender are scoped separately, the system must not assume it can link them without the platform's consent mechanism, and should degrade gracefully (treat as a new contact on that surface) rather than guess.

Finally the intelligence-and-infrastructure cases, elevated by public visibility. Public-facing hallucination: a wrong private DM is bad; a wrong public reply is a screenshot, so the guardrails on public replies are stricter — ground every public answer in retrieved knowledge, screen outbound public replies hard for any invented fact, price, or promise, and bias strongly toward moving anything uncertain to a DM or escalating rather than stating it publicly. Ambiguous intent: when triage is unsure, prefer a safe public holding reply that moves to DM, or escalate, over a confident public guess. Impersonation and fake accounts: be cautious about acting on identity claims in comments/DMs and never take sensitive action (sharing account info) based on an unverified public identity. Tool and API failures: retries with backoff and graceful fallback (a human queue) so a Graph API hiccup does not leave comments unhandled or produce errors, and rate-limit awareness throughout. The table maps the major edge cases to their handling — and the through-line is that on public social, 'when in doubt, do not post publicly — moderate, move to DM, or escalate' is the safe default the whole design encodes.

Guardrails, Moderation Policy, and Meta Compliance

On public social, guardrails and policy are not a safety afterthought — they are the product, because everything the automation does is visible and attributable to your brand. The Meta platform rules come first and are non-negotiable: obtain the right permissions through App Review, respect the messaging window and message tags for DMs, follow the human-agent handover rules, do not spam, and comply with Meta's content and automation policies — because violations get your messaging access or your app restricted, which can silence your channel. Build these into the Compliance agent as hard preconditions on every send and every moderation action, and treat maintaining your standing with Meta as protecting a critical asset.

The moderation and response policy is the second pillar, and it is unique to public social. You must decide, in advance and in writing (the policy Doc the agents read and humans own), the rules of public engagement: which comment categories get a public reply, which get moved to DM, which get hidden, which get reported, which get escalated, and — crucially — the brand voice and the hard 'never' list for public replies (never argue, never make binding commitments publicly, never share personal data in a public reply, never post about regulated topics publicly, never take the bait from trolls or competitors). The Moderation agent implements the hide/report side of this policy and, importantly, errs toward flagging ambiguous cases for human review rather than auto-deleting — because wrongly hiding a legitimate customer's comment is itself a brand-safety problem (people notice and screenshot censorship). The guardrail principle for public replies is stricter than for DMs: the bar to post something publicly and autonomously is high, and the safe default for anything uncertain, sensitive, or high-stakes is to move it private or escalate.

Human oversight and transparency round out safety. The Escalation agent is the guardrail that keeps the system from acting autonomously in the situations that most need judgment — PR-sensitive threads, surges of negativity, sensitive complaints, high-value opportunities — handing them to a human with the bot paused on that thread so it does not talk over the person. A human-review queue (surfaced in Google Sheets) for borderline moderation and escalations keeps people in the loop on the consequential calls. And transparency matters: be honest that an account uses automation with humans available, handle the personal data you collect (from DMs especially) responsibly, and keep an auditable log of moderation actions and public replies so you can always answer why your page did something. A self-hosted stack helps on privacy — DM content can stay on your infrastructure with local models — but the discipline of an explicit, human-owned moderation policy and conservative public-reply guardrails is what actually keeps an autonomous social presence safe, because on public social the mistakes are permanent, screenshotted, and attributed to you.

Cost, Scaling, and the Build Sequence

The free self-hosted stack runs a real Meta automation, and the economics differ from WhatsApp in an important way: there is generally no per-message platform fee for organic comment replies and standard messaging the way WhatsApp charges for business-initiated conversations — the Graph API is free to use within its rate limits and policies. So the cost is mostly your infrastructure (a cheap VPS running n8n, Postgres, and Ollama) and, optionally, hosted-LLM calls if you use a stronger model for public replies where brand tone matters most. The intelligence scales furthest on free — local models handle the enormous volume of triage and moderation classification that a busy comment section generates at no per-item cost — and the mature pattern is again hybrid: local models for the many cheap classification/triage/moderation calls, and a stronger model (local or hosted) only for composing the public and DM replies where quality is worth it. Where you will feel scale is Graph API rate limits during viral moments and the compute for local inference at high comment volume, both handled by queuing, prioritization, and adding resources to the piece that strains.

The build sequence mirrors the planning order. First, stand up the infrastructure with Docker (n8n, Postgres, Ollama), pull your models, and create the schema — contacts, objects, comments, messages, moderation_actions, processed_events, behaviour_profiles, escalations, logs. Second, connect the channel: create the Meta app, link the Facebook Page and Instagram professional account, obtain tokens, subscribe to the webhooks (feed/comments, messages, mentions), and — plan for this early because it takes time — go through App Review for the permissions you need. Build the Intake agent first and verify that a real comment and a real DM reach your database before building any intelligence. Third, build the agents one at a time in pipeline order against their contracts: Event Classifier, Validation, Context, Behaviour/Triage, Moderation, Knowledge, Response-Strategy, Conversation (public and DM modes), Compliance, Logging, Escalation, Follow-up. Fourth, wire the orchestration with the public and private branches and the early-exits (spam→moderate→stop, noise→ignore, escalation→human). Fifth, test the edge cases deliberately using your edge-case table — duplicate events, a simulated comment storm, trolls and spam, edited/deleted comments, DM-window expiry, and especially a simulated negativity surge to verify the crisis freeze works. Sixth, add observability (the moderation queue and escalations in Sheets, agent-decision logs) and pilot on a low-risk post or account before going wide.

The single most important discipline, even more than on WhatsApp, is conservatism on the public surface: it is far better for the automation to under-reply publicly (moving things to DM, escalating, staying silent on noise) than to over-reply and post something wrong where everyone sees it. Start the automation in a limited mode — perhaps handling DMs autonomously but only triaging and moderating comments while a human approves public replies from the queue — and expand its autonomy on the public surface only as you build confidence from the logs. The multi-agent design makes this graduated rollout natural, because the Response-Strategy and Escalation agents are exactly the control points where you set how autonomous the public behaviour is, and you can tighten or loosen them without touching the rest. Keep the agents separate, keep the moderation and response policy explicit and human-owned, keep Postgres as the source of truth and the audit trail, and you will have a Meta automation you can actually trust on your public brand presence — which is the whole point, because on Facebook and Instagram the mistakes are public. If you want a partner to design and build this for your Facebook and Instagram presence — the architecture, the agent roster, the moderation and escalation policy, and the free-to-scaled stack — that is exactly the kind of automation and RevOps engineering our team does.