Inspiration

We didn't want to build a caption generator with an agent label on it. Small businesses don't need more AI-flavored content — they need the actual judgment a marketing hire would bring: what to post this week, why, and to whom. PostGlider Autonomous exists because that judgment can be made by AI, continuously, unattended, for a real business — not simulated for a demo.

What it does

PostGlider Autonomous runs a real small business's marketing department without requiring a human writing the content, choosing the mix, or scheduling the post. A Google Flash powered Orchestrator agent gathers every real signal available for the business — current offers, real competitor virality, its own best-performing past posts, staff specialties, live weather, Google reviews, branded equipment — and hands it, unfiltered, to a Marketing Agent with no database access of its own. That agent decides, with real written reasoning, which signal is the most powerful thing to put in front of this business's audience this week, and which pillar of the 3Ps (Promote, Provide, or Personalize) it belongs to. Specialist writing agents then draft the actual post. Every post carries a machine-readable trace back to the exact real signal that justified it — a real judgment pipeline, not a human-authored template being filled in, and tracks provenance, including costs, raising our customer's production limits when our costs drop.

We wrote a custom WordPress plugin that syncs Media Vault images to a real, searchable, AI-tagged gallery of the business's own work (hundreds of photos, real facet search by tag/author/date) and a real WordPress SSO integration — positioning the product as the operational backbone of a content and marketing agency, not just a solo tool. See it here.

How we built it

Blood, Sweat, Tears, and Claude Code. Every line of this codebase was built through Claude Code — full architectural collaboration, not autocomplete: diagnosing a Vertex AI quota-contention bug live against production traffic, redesigning an agent's data pipeline after a real customer's account exposed a starvation bug, running a real multi-model shootout (six Gemini configs plus DeepSeek) against a captured production prompt to decide which vendor should route a specific agent, and shipping the result the same night. Gemini 3.1 Pro is the system's own architect for harder design decisions; Claude Code builds, tests, and deploys; Gemini 2.5/3.6 Flash runs in production, making real content decisions for real businesses continuously.

We also applied the same build-vs-buy judgment to our own stack: subscription billing for a real WooCommerce/WordPress storefront is a solved problem elsewhere, so we bought WPSubscription.co (a lifetime license, ~$69) and wired its real events into our own database via a webhook (via another plugin purchased on a Lifetime Deal, Bit Integrations), rather than reinventing commodity billing infrastructure. The only custom code we wrote there were fixes for a small SSO bridge, SupaWP, so a customer never sees a second login screen — every other engineering hour went into the actual product differentiator: the agent swarm.

Challenges we ran into

All of them, we think...we're over 150K LoC, and afraid to count. The meta-repo has 5 or so subrepos.

The clearest one: the Marketing Agent was under-producing content, and the fix wasn't a scolding prompt — it was discovering that seven real, already-collected data sources were sitting in the database, fetched every batch, and never once reaching the one agent whose job was to decide with them. Wiring those in, end to end, took one evening, verified against the real production code path.

We also found and fixed a real, live bug the same way: a SQL function's RETURNS TABLE gaining an id column collided with PL/pgSQL's implicit variable scoping, silently breaking two candidate- consumption RPCs mid-batch — caught by actively monitoring live production logs during a real run, not by assumption, and fixed and verified live within the hour.

## Accomplishments that we're proud of

A real customer's real account (Stay True Tattoo) runs on this system continuously — bugs are found because a real account hit a real data gap live, and the fix ships to production the same session it's diagnosed, not in a staging environment. The system now reliably produces full 9-post weekly batches with real, individually-justified reasoning per post, and self-corrects: in one real run, it caught and regenerated two of its own picks for being too similar to each other, twice, before finalizing — unattended.

What we learned

That the biggest reliability wins came from architecture, not prompting — giving the Marketing Agent real database-backed IDs instead of fragile positional array indices, giving it visibility into what's already in the batch so it stops duplicating itself, and building real fallback tiers into image generation instead of letting one provider's failure become a missing photo. And that capital-efficient judgment — buying commodity infrastructure instead of building it — is as real an engineering skill as writing the agent logic itself.

What's next for PostGlider Autonomous

Go to market...late, but still as a leader. Extending the same real-signal, real-reasoning architecture to more of the weekly judgment loop, and to more real businesses beyond the first ones already running on it.

Built With

  • bit-integrations
  • claude-code
  • deepseek
  • google-business-profile
  • google-cloud-build
  • google-cloud-run
  • google-cloud-scheduler
  • google-gemini-2.5-flash
  • google-gemini-3.1-pro
  • google-places
  • google-vertex-ai
  • n8n
  • next.js
  • openai
  • outscraper
  • playwright
  • postgresql
  • react
  • supabase
  • tailwind-css
  • typescript
  • woocommerce
  • wordpress
  • wpsubscription.co
Share this project:

Updates