Agentic merchant onboarding

Context

Standing up a new merchant on the platform — its business, brands, branches, users, menus, and integrations — was a documented, multi-hour, multi-procedure exercise performed by a human onboarding specialist. Every field in the intake form mapped to a known request body; every step had a fixed dependency order. There was almost no judgment in the work and yet it consumed specialist hours and queued merchants behind it. The task was a deterministic pipeline being treated as bespoke labour.

Design

• A new agent type built on the platform's internal agent runtime but operationally separated from the live merchant-facing agents. The execution model differs in kind — long-running, multi-step, idempotent, and resumable — and therefore warrants a distinct runtime profile.
• An ingest worker that validates form payloads, normalises data (phone formatting, geocoding, image hosting), writes a durable task row, and queues execution. Validation is prior to enqueue; failed payloads never enter the run plane.
• A run model with explicit checkpointing, so a partially completed onboarding can resume from its last successful step rather than restarting from zero. This is the property that makes the system tolerable at scale.
• Status reporting back to the originating channel — a messaging notification, a database row, or a chat reply — so a human operator can remain informed without monitoring the run.

Outcome

A deterministic data pipeline is now treated as one. Specialist time is preserved for the edge cases that warrant it, and merchants no longer queue behind work that the system can complete on its own.

Stack

Cloudflare Workers + D1 + Queues (ingest plane) · custom agent runtime (execution plane) · internal administrative APIs.