No company, no API

The engagement agent on my SMM Factory pilot does two things while the owner is cutting hair: leaves conversational comments on in-niche Instagram posts, and replies to incoming DMs. Haiku writes them, the orchestrator rate-limits them, Playwright drives the browser session that posts them. No approval loop — this is the one path in the system where no human sits in the middle.

That whole stack is wrong by design. The right stack is Instagram Graph API through Meta Business Suite, with instagram_manage_comments and instagram_manage_messages write-scopes gated behind App Review. The reason I'm shipping on Playwright instead comes down to one gate: Meta Business Verification requires a registered legal entity, and I was running this as a solo pilot without one.

This post is about what that gate actually costs when you can't clear it.

What App Review wants

The public documentation makes App Review sound like a code review with a privacy policy attached. It isn't. For any Advanced Access scope — which includes anything that writes to another user's account — you have to pass Business Verification first. Business Verification wants:

• A registered legal entity with a verifiable address.
• A DUNS number, or a local-equivalent registration document (incorporation papers, VAT registration, trade license).
• Supporting documents on file — a utility bill or bank statement in the business's name, matched against government registries Meta cross-references.
• A privacy policy on a live production domain. Vercel preview URLs don't count.
• An explainer video of the exact user flow, demonstrating the scope's use case.

For an incorporated company this is a two-hour admin task. For a solo developer running a two-month pilot it's the entire deliverable, inverted. The gate wasn't built to filter me out specifically — it exists because this is Meta's single most-abused surface, and a business-entity check is a cheap way to make scaled spam uneconomic. By-design is the right word for it.

Also: there is no sandbox for write-scopes. Standard Access gives you read-only testing against your own account. The moment you want to write to a client's inbox or feed, you need Advanced Access, and that path starts at Business Verification. You can't ship a demo, show it to someone, and then fix the paperwork. The shipping step is the paperwork.

What I shipped instead

A Playwright session with a long-lived IG cookie, driven by two agents:

• The publisher uses the cookie to post content on Mondays after a Slack approval.
• The engagement agent uses the same cookie to comment on target feeds daily and reply to DMs inline.

Comment landed · heart + thank-you from author

Started a back-and-forth with the owner

Haiku generates the text. The orchestrator rate-limits by account and respects an interval floor between actions on the same thread. Everything is logged to Supabase, so if an action pattern starts tripping IG's spam heuristics, the ledger can tell me exactly when the pattern shifted.

This works. It also has three real costs:

The cookie rotates. When IG issues a new session cookie I have to re-authenticate by hand. In the content pipeline logs you'll see this as login_required on the trends endpoint — same mechanism, different scope. The publisher gets a weekly rotation; engagement has a higher ambient failure rate because the surface is busier.

It's outside Terms of Service. IG's TOS doesn't distinguish a Playwright session using your own cookie from a scraper mimicking your account. If the pattern trips rate-limit or spam heuristics, the account gets paused. The right move at that point is to apologize to the client and take the pause — not to look clever.

It won't scale past a handful of clients. Session cookies are per-account. Ten barbershops means ten cookies, ten weekly re-auth cycles, ten rate-limit windows to coordinate. The architecture is linear-cost in client count; the Graph API path would be constant-cost in the orchestrator and linear only in client API quotas.

What the metrics lie about

The results table on the pilot's case study has one line that reads cleaner than it should:

0 IG violations · 2-month pilot

That's a true number. It's also entirely a function of running under rate limits with one client. Scale the same architecture to five clients and the number goes up. Ship under the Graph API with proper scopes and the metric stops existing — compliance is the baseline, not an achievement.

Any time you see a safety metric reported on a cookie-driven system, read it as a statement about pacing, not architecture.

Should you ship this way?

Comes down to one question: are you running a pilot or building the product?

Pilot. One client, two-month window, an honest conversation with the owner about where the automation touches their account. Playwright + cookie is defensible. You're testing whether the system is worth the paperwork before you buy the paperwork.

Product. Any plural number of clients, any plan to open a seat on a demo page. Register the entity, pass Business Verification, go through App Review. The paperwork isn't the cost of the API — it's the cost of writing to someone else's account at scale, and it's load-bearing on the whole product's story.

The failure mode is running a pilot's architecture past the pilot. The cookie that worked for one barbershop in a two-month window is the exact wrong substrate for anything after that.

What I'd do differently

Register the entity on day one, not day sixty. The entity doesn't gate the architecture — I'd still have shipped the orchestrator, the Haiku stratification, the Slack approval, the knowledge-markdown system. What it gates is which API the production version runs against, and that question wants an answer before the pipeline is load-bearing on a workaround.

The pilot proved the system can run at cost. The thing it didn't prove — because the paperwork wasn't done — is whether the system could run at scale legally. Those are two different questions, and I conflated them for most of the pilot.

The clean API wasn't a lie. It was a filter, pointed exactly at builders like me, working exactly as designed.