Building AI agents
for Plan Zinnia.

Adding a category meant
coordinating several systems.

Expanding beyond venues to DJs, hair and makeup, or officiants required more than another marketplace listing.

Each new vendor category touched a Supabase enum, three React form directories, admin approval tables, a Notion tracker, and a QA pass. That was roughly half a day of coordinated work split across engineering, design, and ops.

I first built the Builder and QA agents to collapse that sequence into a single CLI command with automated checks. I then added Health and Upsell agents to monitor the running platform and prepare weekly vendor outreach. The goal was to reduce repeat setup work while keeping the team able to inspect what changed.

Turn a vendor name
into a reviewable scaffold.

A Node CLI composes six specialized steps, with explicit responsibilities and visible fallbacks.

The whole chain can run unattended. The LLM handles a constrained generation task; branch protection, database scaffolding, preview capture, and reporting remain deterministic.

Check what the Builder ships
before a reviewer opens it.

The QA Agent runs automatically with --qa after a Builder run, or independently against any vendor route. Headless Puppeteer loads the integration URL and collects the signals a reviewer needs.

A thin Playwright layer in qa/tests/smoke.spec.ts runs scheduled checks against the public homepage. Builder-triggered audits and scheduled smoke tests write the same record format into a dedicated QA Notion database.

The Builder log and QA findings give ops and admin reviewers a visible trail from the scaffold to its audit results.

Make silent failures
visible to the team.

In September, several systems had quietly broken: Prerender had lapsed for three months, five edge functions had never been deployed to production, and new-message emails had stopped going out.

Nothing was consistently checking the running platform. I built report-platform-health, a Supabase edge function that pg_cron runs daily, to email a structured report to admins and leadership.

The agent only persists its own history record. Database reads go through a Postgres function declared STABLE, which rejects writes within that function.

Prepare the weekly outreach
for an admin to review.

The next operational task was deciding which vendors to nudge and what to say. I built draft-vendor-upsells to do that preparation every Monday.

The agent reads each Inquiry-plan vendor’s own data through upsell_draft_snapshot(): couples who reached out in the last 30 days, upgrade-intent signals, and time since the last nudge. This snapshot function is also declared STABLE.

A week with no drafts produces no email. A failed snapshot still sends an email, so a broken job cannot pass as a quiet week.

Give the model a bounded job
inside an auditable workflow.

I designed the four agents around bounded responsibilities, named integrations, and explicit side effects.

The model generates boilerplate from strong structural references: the enum name, design tokens, and the shape of an existing vendor experience. Git state, migrations, screenshots, and Notion logging sit around that generation step as deterministic operations.

This architecture let me put category setup behind a one-line CLI without the ops team losing visibility into what it produced.

Apply the same boundaries to scheduled operations

Health and Upsell run on pg_cron schedules with service-role credentials. Their database reads use STABLE functions; their only persistent writes are their own history records. Reports and drafts go to people who can act on them.

The database restriction applies inside each read function. The surrounding workflow keeps operational actions with admins: Health surfaces problems, and Upsell prepares messages for a human to send.

Both agents also define what email silence means. Health sends recurring summaries and repeated failure reports. Upsell stays quiet when there are no drafts, but reports a failed snapshot.

Less coordinated setup,
with evidence attached.

• New-vendor-category onboarding moved from roughly half a day of cross-functional work to a single command plus review.
• Every scaffold has visible QA findings before admin review. Builder-triggered audits and scheduled smoke tests use a shared QA record format.
• Deterministic fallbacks help the pipeline continue through API outages, missing keys, or stale design context.
• Platform checks became a scheduled daily report, with a full Monday summary and repeated notifications for unresolved failures.
• Weekly vendor outreach preparation became a Monday inbox item with usage-based drafts, cooldowns, and human control over sending.

The time comparison describes the onboarding workflow. It does not imply a measured end-to-end runtime or remove the need for review. Health and Upsell outcomes describe the operating workflow; no measured revenue uplift or reduction in incidents is claimed.