Zealous AI Operations Platform.

Running a multi-client AI automation agency at scale creates a paradox: the better you get at building automation for clients, the more manual work you create for yourself. By mid-2025, managing seven active clients meant tracking blog publishing queues, monitoring voice agent uptime, reviewing GSC rank movements, checking backlink opportunities, and coordinating content production — across seven completely separate systems, each with its own logins, APIs, and data formats.

The operational overhead was growing faster than revenue. Every new client added another set of dashboards to monitor, another set of crons to maintain, another set of Sanity projects to manage. The tooling was fragmented: scripts lived in a local seo-ops/ directory, the dashboard was a separate Next.js project, and client configs were YAML files on a laptop.

The fundamental problem wasn't any single workflow — it was the absence of a unified system. Without one, every new client meant more complexity, not more leverage.

The Zealous AI Operations Platform is a private Next.js 16 App Router dashboard deployed on Vercel, backed by Neon Postgres (serverless PostgreSQL), and connected to every tool in the stack via API.

The architecture has three layers:

**The Skills Layer** — 48 discrete automation skills, each mapped to a specific operation: blog autopublish, E-E-A-T quality gating, GSC strike-distance keyword pulls, Sanity content patching, backlink gap analysis via linkgap.io, voice agent configuration via Retell, social posting via GoHighLevel, and more. Skills are versioned, logged, and auditable. Any skill can be triggered manually from the dashboard or scheduled via cron.

**The Clients Layer** — Each of the 7 clients has a dedicated cockpit page aggregating their skill activity, open incidents, press releases, backlink opportunities, content queue, and rank alerts. Client data lives in Neon Postgres, not YAML files. The schema was designed for isolation: no client can see another's data, and the operator role sees operational status without financial or strategic detail.

**The Operator Layer** — A role-based access system with three tiers: admin (Frank), operator (Jo, the VA), and viewer. The operator role has a purpose-built queue at /ops showing assigned tasks, open incidents, skill health, and quick-action buttons. She never sees API keys, financial data, or strategic plans. Every action she takes is logged to an audit trail.

Six industry-specific AI voice agents are deployed across client sites — dental clinics, physiotherapy clinics, restaurants, law firms, real estate agents, and salons. Each agent is powered by Retell AI and configured with the client's specific services, pricing, FAQs, booking workflow, and call transfer rules.

The agents answer inbound calls 24/7, handle appointment booking, answer service questions, and transfer to staff when needed. They speak both English and Mandarin, which matters significantly for Vancouver's multilingual business community.

Each voice agent has a dedicated landing page on the client's website optimized for local search intent — "AI voice agent for dental clinics Vancouver" — following the Compact Keywords framework. These pages rank for bottom-of-funnel queries where the searcher already knows they want an AI voice solution and is looking for a provider.

The technical integration is a webhook chain: inbound call → Retell processes speech → Claude generates response using the client's knowledge base → Retell speaks the response → action (book appointment, transfer, end call) is logged to the CRM.

The blog autopublish engine runs 2× per week per client. It pulls strike-distance keywords from Google Search Console (positions 6–25 with 10+ monthly impressions), generates a research brief using DataForSEO's SERP data and People Also Ask, drafts a 800–1200 word post following the E-E-A-T framework, runs it through a quality gate (checking for banned AI phrases, word count, image requirements, FAQ schema, and statistic citations), and publishes to Sanity CMS if it passes.

The quality gate is the most important part. It checks 12 conditions before allowing publication: minimum word count, presence of a TLDR, at least one FAQ with proper JSON-LD schema, an inline statistic with a source citation, no use of 34 banned AI filler words, author attribution set to the correct person (not "Organization"), and dateModified set in the Article schema.

Posts that fail the gate are logged as incidents and routed to the operator queue for manual review. Posts that pass publish automatically, trigger a GSC reindex request, and sync to the FY-CONTENT-ENGINE Airtable base for video production queuing.

Since deployment, the system has published over 200 blog posts across 7 client sites. Organic traffic across the portfolio has grown consistently month-over-month without any manual content work.

The next evolution of the platform is an API layer that allows clients to programmatically interact with their automation stack. Rather than building separate integrations for each client's internal tools, the platform exposes a versioned REST API at /api/v1/ authenticated via bearer token.

Each client gets an API key from their dashboard cockpit. The key is scoped to their client_id and rate-limited to 100 requests per hour. Current endpoints include: POST /api/v1/skills/run (trigger any skill on demand), GET /api/v1/clients/me/reports/seo (pull current rank tracking data), GET /api/v1/clients/me/content (list published blog posts with performance data), and POST /api/v1/voice-agents/calls (retrieve call logs for the client's voice agent).

This makes the platform extensible. A dental clinic can pull their voice agent call logs into their own EMR system. A real estate agency can trigger a new BOFU landing page build from their CRM when they enter a new market. The automation stack becomes infrastructure, not just a service.