Skip to content

Work · AI receptionist / booking agent · Marketing agency · nine clinic builds

White-label agency delivery

The agency sold campaigns faster than it could build the systems

Embedded as the automation build arm of a marketing agency: nine complete GoHighLevel acquisition systems delivered into clinic sub-accounts across two countries in five and a half weeks — nurture workflows, AI receptionists, booking calendars, deposit handling, landing pages, and the owner handbooks the agency handed over.

  • GoHighLevel
  • Conversation AI
  • Voice AI
  • Cloudflare Workers
  • Playwright
  • Role · sole designer & builder
  • 6 min
client builds across 10 sub-accounts, 2 countries
9Scope
workflows built or rebuilt into live accounts
~119Scope
AI agents configured — chat, booking & voice
17Scope
System size
System flow · 10 stages · 40 components reconstructed from the build record

The situation

A marketing agency was selling campaign launches to clinics. Ads went live and leads arrived. The systems meant to receive those leads, book them and follow up were not built at that speed.

I embedded as the agency's automation build arm. Nine complete acquisition systems went into clinic sub-accounts across two countries in five and a half weeks: nurture workflows, AI receptionists, booking calendars, deposit handling, landing pages and owner handbooks.

My job was to make delivery repeatable rather than heroic, and "done" mean something checkable. The recurring failure across inherited accounts was a write that returns success, reads back clean, and does nothing at all.

What was broken

  • Campaigns sold faster than the systems were built, so paid traffic arrived at accounts that could not handle it.
  • Client-visible copy had shipped as marketing messages with no opt-out.
  • Stop-on-response was false on 66 of 70 published workflows, so a lead who replied kept receiving the ladder.
  • Nothing recorded why one client's build differed from another's, so divergence was silent.
  • The only approval gate sat after dozens of agents and a large spend. That is not a conversation, but a receipt.

Constraints

  • Nine clinics across 10 sub-accounts and two countries, each with its own offer, calendar and compliance limits.
  • The systems went into live sub-accounts, so an unfinished automation could reach a real patient. Copy and architecture belonged to the agency and its clients.
  • The underlying platform is never named in anything a client or lead sees, and the end operators are clinic owners rather than builders.

FIG 01 · System Flow

How the system actually runs

Every component below is reconstructed from the project’s own build records. Nothing is added to make it look bigger.

components
40
components
stages
10
stages
decisions & guards
11
decisions & guards
AI
3
AI
human handoffs
6
human handoffs
platforms
5
platforms
  1. Stage 1, Brief & gates: Resolve the client, find the approved strategy, read the existing account, and refuse to proceed on ambiguity.
    1. Brief & strategy gate (Source, Agency). The approved paid-social strategy for one clinic, plus whatever materials came with it, inventoried before anything else runs — and a hard refusal if no approved strategy exists. Connects to Environment floor when strategy present; Brief & strategy gate when strategy absent → refuse and name what is missing.
    2. Environment floor (Guard, Tooling). A mechanical prerequisite check — config, repo access, dependency clones and their freshness, API reachability, token scopes, a logged-in browser session — where every failure names the human who can grant the fix. Connects to Read-only account capture when all checks pass.
    3. Read-only account capture (Report, CRM (read-only)). Mandatory where a sub-account already exists and no capture is recent: a full read-only sweep of pipelines, fields, values, tags, calendars, users, numbers and AI agents, plus a throttled browser-session capture of workflow JSON the public API does not expose. Connects to Preflight confirmation when capture fresh, or greenfield noted.
    4. Preflight confirmation (Human, Delivery process). A hard gate presenting the client folder, the client name, the strategy found, the capture status, the provisional role roster and a rough agent count. Connects to Client researcher when explicit yes; ICA & brand voice when explicit yes.
  2. Stage 2, Foundation & proposal: Research the business, fix the voice, propose the build shape — and stop cheaply if the shape is wrong.
    1. Client researcher (AI, Agent role). Writes the business-and-offer brief — verified facts and the exact pricing mechanics, with anything unverified written as a fill token rather than an invented fact. Connects to Two-page build proposal when verified facts + tokens.
    2. ICA & brand voice (AI, Agent role). Binding voice rules with explicit wrong-and-right pairs, which every later copy document is held to. Connects to Two-page build proposal when binding voice rules.
    3. Two-page build proposal (Report, Agent role). A deliberately short, plain-English proposal carrying the workflow list with anything added or questioned called out, a set of design questions, and a count of value gaps. Connects to Gate 1: build shape.
    4. Gate 1: build shape (Human, Delivery process). The cheap stop. Design questions must be answered before the registry phase runs, and the human’s decisions are captured verbatim in his own words as the next phase’s input. Connects to Systems architect when questions answered, decisions captured verbatim; Two-page build proposal when workflow cut or shape changed.
  3. Stage 3, Binding registry: One architect writes the naming law the whole build is held to, behind a second human gate.
    1. Systems architect (Workflow, Agent role). Writes the binding registry from the agreed proposal: workflow names and numbers, the stage-to-canonical map, the full field, tag and value set, calendars, payment products, alert ids, and the mechanism policies every workflow and voice agent will build to. Connects to Registry reviewer; Gate 2: naming law when registry + hash.
    2. Registry reviewer (Guard, Agent role). An adversarial review of the registry, including roster completeness against the module checklist, emitting surviving findings with severities. Connects to Gate 2: naming law when surviving findings, quoted in full.
    3. Gate 2: naming law (Human, Delivery process). One message carrying the architect’s summary, the final roster, the doc index, the mechanism policies line by line, the full field-and-tag list in plain English, every surviving finding quoted with its severity, and the validator floor output. Connects to Role fan-out when explicit go; Systems architect when no → capture what to change, re-run.
  4. Stage 4, Spec & design pack: The role roster writes the document pack, with a machine-checkable claims sidecar per document.
    1. Role fan-out (Scheduled job, Orchestration). Parallel module writing across the active roster — pipeline and fields, alerts, calendars and payments, phone and compliance, deliverability, tracking, journey and workflows, nurture copy, conversation AI, voice AI, the onboarding runbook and the go-live checklist. Connects to 13–36 doc pack; Claims sidecar per doc when one sidecar per doc; Fill-token registry when every unknown becomes a token; Dead-agent stop conditions when an agent or checker returned nothing.
    2. 13–36 doc pack (Data store, Repo). A flat, chronologically numbered document set whose count flexes per client, indexed authoritatively by a build overview carrying the index, build order, divergence log, deliverables audit and strategy mapping. Connects to Registry reconciler; Journey & compliance lenses.
    3. Claims sidecar per doc (Data store, Repo). One machine-readable sidecar per document declaring what that document defines and what it references across workflows, tags, fields, alerts, calendars, products and tokens. Connects to Registry reconciler when declared names; Machine validator when declared versus present.
    4. Fill-token registry (Report, Agent role). Every unknown business fact — prices, hours, addresses, policies, links, staff names — is written as a token instead of a guess, and compiled into a cross-document registry plus a sendable client-questions message. Connects to Owner handbook when client answers fill the tokens.
  5. Stage 5, Audit & fix loop: Adversarial lenses plus a machine validator, and a fix loop that proves it actually ran.
    1. Registry reconciler (Guard, Agent role). Cross-checks every document’s names against the registry set and emits scoped fix notes. Connects to Fix loop + liveness when fix notes.
    2. Journey & compliance lenses (Guard, Agent role). Two adversarial readers: one reads the designed journey as a journey and finds where a lead can fall out with nothing catching them; the other reads all client-visible copy against the compliance limits and the binding voice. Connects to Fix loop + liveness when findings.
    3. Machine validator (Guard, Node script). Asserts the design and the exported workflow JSON against hard contracts — stop-on-response on every send, the three-part opportunity-value shape, the backward-move flag on every regressing stage write, finders filtered on pipeline only, a create-then-jump on every not-found branch, a past-anchor branch on every appointment-anchored wait, a decay window longer than the ladder, and the deployment gate. Connects to Fix loop + liveness when failed checks.
    4. Fix loop + liveness (Scheduled job, Orchestration). Findings routed to owner roles and applied, with a mandatory report of dispatched versus applied plus three separate failure buckets — findings a fixer consciously skipped, findings whose document had no owner, and documents whose fixer returned nothing at all. Connects to Dead-agent stop conditions when dead fixers, dead auditors, or unroutable findings; Build to draft when validator passes and the index is complete.
    5. Dead-agent stop conditions (Guard, Orchestration). Non-advisory failure returns that halt the run: an agent returned nothing so its document was never written, a promised document is absent or a stub, or the checker itself died so the set is unverified rather than clean.
  6. Stage 6, Build blueprint: The standard components every clinic build is assembled from, each carrying the live failure that produced it.
    1. 8-stage pipeline (CRM record, CRM). Eight fixed stages identical at every client, each mapped to a canonical funnel step on a shared sort scale. Clients may append stages at the end; they may never rename, reorder or remove. Connects to Systems architect when blueprint constrains the registry.
    2. ~17-workflow set (Workflow, CRM). Fourteen always-on workflows on reserved numbers — intake and chase, reply, booking-started, booked and reminders, reschedule, no-show, cancellation, outcome, review, stale-opportunity, missed call, escalation, treatment progress, buying signal — plus conditional modules at reserved numbers for deposits, external diaries and voice. Connects to Systems architect when blueprint constrains the registry; Build to draft when the numbered set to create.
    3. Removal matrix (Guard, CRM). A contract table of which workflow removes a contact from which, with one standing exception: nothing may remove a contact from the deposit series. Connects to Machine validator when machine-checked.
    4. One-card-per-cycle guard (Guard, CRM). A cycle is one decision to buy: a reschedule, a cancellation and a no-show all happen inside an unfinished cycle and reuse the same card, and only a completed or lost outcome mints a new one with the cycle index incremented. Connects to Machine validator when machine-checked.
    5. AI receptionist + KB (AI, CRM Conversation AI). Always two chat agents, never one — a primary prompt bot that answers, qualifies and hands off, and a booking bot that owns the booking conversation only. Hard requirements: a non-empty knowledge base, non-empty calendar ids on every booking action, cancel and reschedule set at the action rather than the agent, sleep enabled, and a much lower auto-pilot message cap than the platform default. Connects to Availability-shown tag when flow bot required; Build to draft when agents built to the contract.
    6. Availability-shown tag (Trigger, CRM). An add-tag step placed immediately BEFORE the flow bot’s booking node, writing the booking-started signal deterministically by graph position rather than by model judgement. Connects to 8-stage pipeline when writes the booking-started signal.
    7. Calendar & deposit modules (Payment, CRM + payment processor). Calendar hours, buffers and rules set from the client’s own answers, and an optional deposit module — link send and chase, a paid handler, and a guard that releases a held slot never paid for. Connects to Build to draft when conditional modules per client; Go-live checklist when long-lead dependencies open on day one.
    8. Touch ceiling + hygiene (Guard, CRM). A per-contact cap across all workflows, enforced by a shared counter field checked before every send — the number is a client-level knob, having one is not — plus two estate-wide, mechanically checkable hygiene flags. Connects to Machine validator when machine-checked.
  7. Stage 7, Build to draft: Create everything into the live sub-account, unpublished, behind an explicit mutation gate.
    1. Build to draft (Scheduled job, CRM (gated writes)). A conductor drives a creation engine one workflow at a time from the registry and the journey doc, resolving every prerequisite before the gate, marking anything missing as blocked, ordering creation by dependency, and cross-wiring workflow-to-workflow references in a second pass. Connects to Mutation gate when before any write.
    2. Mutation gate (Human, Delivery process). An explicit yes naming the target location and the exact numbered workflow list before any write happens, one location per session. Connects to Never publish when yes, naming location and list.
    3. Never publish (Guard, Delivery process). Every build runs without the publish flag, ever. A human reviews each draft in the builder and publishes it there. Connects to Read-back & verify pass when draft created.
  8. Stage 8, Verification: Read every write back from the live account and treat "the API returned success" as unproven.
    1. Read-back & verify pass (Report, CRM (read-only)). Each draft is verified read-only immediately after creation with a per-workflow outcome table logged, then a full verify pass compares the live account against its design docs and a harvest mode pulls live ids back into the client manifest. Connects to Authored-not-deployed gate; Owner handbook when live account matches design.
    2. Authored-not-deployed gate (Guard, Node script). A single validator assertion: published, and the trigger file non-empty. Connects to Build to draft when authored but not deployed.
  9. Stage 9, Handover & go-live: Owner handbook, gated checklist, the human publish click, and an honest post-launch runbook.
    1. Owner handbook (Report, Deliverable). A self-contained plain-language system guide, rendered as one reviewable page, written for a clinic owner who did not build the thing. Connects to Go-live checklist.
    2. Go-live checklist (Report, Deliverable). An instantiated multi-section checklist with owners, dates and gated-by markers on anything waiting on a dependency, opening with a day-one critical path of long-lead items that cook while you build. Connects to Human publish when every gated line cleared.
    3. Human publish (Human, CRM UI). The publish click that takes each verified draft live. Connects to Read-back & verify pass when re-verify the published state; Post-launch runbook.
    4. Post-launch runbook (Report, Deliverable). An instantiated onboarding runbook in which every step carries exactly one honest label — data-only, manual-code-today with a named owner and required credentials, or blocked on a linked refactor. Connects to Baseline retro.
  10. Stage 10, Cross-client ledger: Promote every divergence and every fault into the shared baseline, so the next build starts one fault wiser.
    1. Baseline retro (Human, Delivery process). The final go-live step: review the divergence log, promote repeated divergences to baseline defaults or retire stale ones, and record the change in the changelog. Connects to Cross-client failure ledger when promote what recurred.
    2. Cross-client failure ledger (Data store, Repo). The shared versioned baseline itself — the contracts, the removal matrix, the build rules, the hygiene flags and the validator checks, each carrying the named live failure that produced it. Connects to ~17-workflow set when the next build starts from the updated baseline; Machine validator when a new fault becomes a new check.
    3. Weekly diagnosis engine (Report, Read-only analysis). A read-only commercial diagnostic over one live sub-account: derive the account map, review every workflow and agent whole, then read the account as a journey, as one system and as one message stream, before grouping root causes into a ranked backlog. Connects to Cross-client failure ledger when findings feed the backlog.
0/18

The agency hands over an approved ads strategy for a clinic that already has a half-used CRM sub-account.

Read this system as text

  1. Stage 01

    Brief & gates

    Resolve the client, find the approved strategy, read the existing account, and refuse to proceed on ambiguity.

    • Brief & strategy gate · Source · Agency — The approved paid-social strategy for one clinic, plus whatever materials came with it, inventoried before anything else runs — and a hard refusal if no approved strategy exists. → Environment floor (strategy present), Brief & strategy gate (strategy absent → refuse and name what is missing)
    • Environment floor · Guard · Tooling — A mechanical prerequisite check — config, repo access, dependency clones and their freshness, API reachability, token scopes, a logged-in browser session — where every failure names the human who can grant the fix. → Read-only account capture (all checks pass)
    • Read-only account capture · Report · CRM (read-only) — Mandatory where a sub-account already exists and no capture is recent: a full read-only sweep of pipelines, fields, values, tags, calendars, users, numbers and AI agents, plus a throttled browser-session capture of workflow JSON the public API does not expose. → Preflight confirmation (capture fresh, or greenfield noted)
    • Preflight confirmation · Human · Delivery process — A hard gate presenting the client folder, the client name, the strategy found, the capture status, the provisional role roster and a rough agent count. → Client researcher (explicit yes), ICA & brand voice (explicit yes)

  2. Stage 02

    Foundation & proposal

    Research the business, fix the voice, propose the build shape — and stop cheaply if the shape is wrong.

    • Client researcher · AI · Agent role — Writes the business-and-offer brief — verified facts and the exact pricing mechanics, with anything unverified written as a fill token rather than an invented fact. → Two-page build proposal (verified facts + tokens)
    • ICA & brand voice · AI · Agent role — Binding voice rules with explicit wrong-and-right pairs, which every later copy document is held to. → Two-page build proposal (binding voice rules)
    • Two-page build proposal · Report · Agent role — A deliberately short, plain-English proposal carrying the workflow list with anything added or questioned called out, a set of design questions, and a count of value gaps. → Gate 1: build shape
    • Gate 1: build shape · Human · Delivery process — The cheap stop. Design questions must be answered before the registry phase runs, and the human’s decisions are captured verbatim in his own words as the next phase’s input. → Systems architect (questions answered, decisions captured verbatim), Two-page build proposal (workflow cut or shape changed)

  3. Stage 03

    Binding registry

    One architect writes the naming law the whole build is held to, behind a second human gate.

    • Systems architect · Workflow · Agent role — Writes the binding registry from the agreed proposal: workflow names and numbers, the stage-to-canonical map, the full field, tag and value set, calendars, payment products, alert ids, and the mechanism policies every workflow and voice agent will build to. → Registry reviewer, Gate 2: naming law (registry + hash)
    • Registry reviewer · Guard · Agent role — An adversarial review of the registry, including roster completeness against the module checklist, emitting surviving findings with severities. → Gate 2: naming law (surviving findings, quoted in full)
    • Gate 2: naming law · Human · Delivery process — One message carrying the architect’s summary, the final roster, the doc index, the mechanism policies line by line, the full field-and-tag list in plain English, every surviving finding quoted with its severity, and the validator floor output. → Role fan-out (explicit go), Systems architect (no → capture what to change, re-run)

  4. Stage 04

    Spec & design pack

    The role roster writes the document pack, with a machine-checkable claims sidecar per document.

    • Role fan-out · Scheduled job · Orchestration — Parallel module writing across the active roster — pipeline and fields, alerts, calendars and payments, phone and compliance, deliverability, tracking, journey and workflows, nurture copy, conversation AI, voice AI, the onboarding runbook and the go-live checklist. → 13–36 doc pack, Claims sidecar per doc (one sidecar per doc), Fill-token registry (every unknown becomes a token), Dead-agent stop conditions (an agent or checker returned nothing)
    • 13–36 doc pack · Data store · Repo — A flat, chronologically numbered document set whose count flexes per client, indexed authoritatively by a build overview carrying the index, build order, divergence log, deliverables audit and strategy mapping. → Registry reconciler, Journey & compliance lenses
    • Claims sidecar per doc · Data store · Repo — One machine-readable sidecar per document declaring what that document defines and what it references across workflows, tags, fields, alerts, calendars, products and tokens. → Registry reconciler (declared names), Machine validator (declared versus present)
    • Fill-token registry · Report · Agent role — Every unknown business fact — prices, hours, addresses, policies, links, staff names — is written as a token instead of a guess, and compiled into a cross-document registry plus a sendable client-questions message. → Owner handbook (client answers fill the tokens)

  5. Stage 05

    Audit & fix loop

    Adversarial lenses plus a machine validator, and a fix loop that proves it actually ran.

    • Registry reconciler · Guard · Agent role — Cross-checks every document’s names against the registry set and emits scoped fix notes. → Fix loop + liveness (fix notes)
    • Journey & compliance lenses · Guard · Agent role — Two adversarial readers: one reads the designed journey as a journey and finds where a lead can fall out with nothing catching them; the other reads all client-visible copy against the compliance limits and the binding voice. → Fix loop + liveness (findings)
    • Machine validator · Guard · Node script — Asserts the design and the exported workflow JSON against hard contracts — stop-on-response on every send, the three-part opportunity-value shape, the backward-move flag on every regressing stage write, finders filtered on pipeline only, a create-then-jump on every not-found branch, a past-anchor branch on every appointment-anchored wait, a decay window longer than the ladder, and the deployment gate. → Fix loop + liveness (failed checks)
    • Fix loop + liveness · Scheduled job · Orchestration — Findings routed to owner roles and applied, with a mandatory report of dispatched versus applied plus three separate failure buckets — findings a fixer consciously skipped, findings whose document had no owner, and documents whose fixer returned nothing at all. → Dead-agent stop conditions (dead fixers, dead auditors, or unroutable findings), Build to draft (validator passes and the index is complete)
    • Dead-agent stop conditions · Guard · Orchestration — Non-advisory failure returns that halt the run: an agent returned nothing so its document was never written, a promised document is absent or a stub, or the checker itself died so the set is unverified rather than clean.

  6. Stage 06

    Build blueprint

    The standard components every clinic build is assembled from, each carrying the live failure that produced it.

    • 8-stage pipeline · CRM record · CRM — Eight fixed stages identical at every client, each mapped to a canonical funnel step on a shared sort scale. Clients may append stages at the end; they may never rename, reorder or remove. → Systems architect (blueprint constrains the registry)
    • ~17-workflow set · Workflow · CRM — Fourteen always-on workflows on reserved numbers — intake and chase, reply, booking-started, booked and reminders, reschedule, no-show, cancellation, outcome, review, stale-opportunity, missed call, escalation, treatment progress, buying signal — plus conditional modules at reserved numbers for deposits, external diaries and voice. → Systems architect (blueprint constrains the registry), Build to draft (the numbered set to create)
    • Removal matrix · Guard · CRM — A contract table of which workflow removes a contact from which, with one standing exception: nothing may remove a contact from the deposit series. → Machine validator (machine-checked)
    • One-card-per-cycle guard · Guard · CRM — A cycle is one decision to buy: a reschedule, a cancellation and a no-show all happen inside an unfinished cycle and reuse the same card, and only a completed or lost outcome mints a new one with the cycle index incremented. → Machine validator (machine-checked)
    • AI receptionist + KB · AI · CRM Conversation AI — Always two chat agents, never one — a primary prompt bot that answers, qualifies and hands off, and a booking bot that owns the booking conversation only. Hard requirements: a non-empty knowledge base, non-empty calendar ids on every booking action, cancel and reschedule set at the action rather than the agent, sleep enabled, and a much lower auto-pilot message cap than the platform default. → Availability-shown tag (flow bot required), Build to draft (agents built to the contract)
    • Availability-shown tag · Trigger · CRM — An add-tag step placed immediately BEFORE the flow bot’s booking node, writing the booking-started signal deterministically by graph position rather than by model judgement. → 8-stage pipeline (writes the booking-started signal)
    • Calendar & deposit modules · Payment · CRM + payment processor — Calendar hours, buffers and rules set from the client’s own answers, and an optional deposit module — link send and chase, a paid handler, and a guard that releases a held slot never paid for. → Build to draft (conditional modules per client), Go-live checklist (long-lead dependencies open on day one)
    • Touch ceiling + hygiene · Guard · CRM — A per-contact cap across all workflows, enforced by a shared counter field checked before every send — the number is a client-level knob, having one is not — plus two estate-wide, mechanically checkable hygiene flags. → Machine validator (machine-checked)

  7. Stage 07

    Build to draft

    Create everything into the live sub-account, unpublished, behind an explicit mutation gate.

    • Build to draft · Scheduled job · CRM (gated writes) — A conductor drives a creation engine one workflow at a time from the registry and the journey doc, resolving every prerequisite before the gate, marking anything missing as blocked, ordering creation by dependency, and cross-wiring workflow-to-workflow references in a second pass. → Mutation gate (before any write)
    • Mutation gate · Human · Delivery process — An explicit yes naming the target location and the exact numbered workflow list before any write happens, one location per session. → Never publish (yes, naming location and list)
    • Never publish · Guard · Delivery process — Every build runs without the publish flag, ever. A human reviews each draft in the builder and publishes it there. → Read-back & verify pass (draft created)

  8. Stage 08

    Verification

    Read every write back from the live account and treat "the API returned success" as unproven.

    • Read-back & verify pass · Report · CRM (read-only) — Each draft is verified read-only immediately after creation with a per-workflow outcome table logged, then a full verify pass compares the live account against its design docs and a harvest mode pulls live ids back into the client manifest. → Authored-not-deployed gate, Owner handbook (live account matches design)
    • Authored-not-deployed gate · Guard · Node script — A single validator assertion: published, and the trigger file non-empty. → Build to draft (authored but not deployed)

  9. Stage 09

    Handover & go-live

    Owner handbook, gated checklist, the human publish click, and an honest post-launch runbook.

    • Owner handbook · Report · Deliverable — A self-contained plain-language system guide, rendered as one reviewable page, written for a clinic owner who did not build the thing. → Go-live checklist
    • Go-live checklist · Report · Deliverable — An instantiated multi-section checklist with owners, dates and gated-by markers on anything waiting on a dependency, opening with a day-one critical path of long-lead items that cook while you build. → Human publish (every gated line cleared)
    • Human publish · Human · CRM UI — The publish click that takes each verified draft live. → Read-back & verify pass (re-verify the published state), Post-launch runbook
    • Post-launch runbook · Report · Deliverable — An instantiated onboarding runbook in which every step carries exactly one honest label — data-only, manual-code-today with a named owner and required credentials, or blocked on a linked refactor. → Baseline retro

  10. Stage 10

    Cross-client ledger

    Promote every divergence and every fault into the shared baseline, so the next build starts one fault wiser.

    • Baseline retro · Human · Delivery process — The final go-live step: review the divergence log, promote repeated divergences to baseline defaults or retire stale ones, and record the change in the changelog. → Cross-client failure ledger (promote what recurred)
    • Cross-client failure ledger · Data store · Repo — The shared versioned baseline itself — the contracts, the removal matrix, the build rules, the hygiene flags and the validator checks, each carrying the named live failure that produced it. → ~17-workflow set (the next build starts from the updated baseline), Machine validator (a new fault becomes a new check)
    • Weekly diagnosis engine · Report · Read-only analysis — A read-only commercial diagnostic over one live sub-account: derive the account map, review every workflow and agent whole, then read the account as a journey, as one system and as one message stream, before grouping root causes into a ranked backlog. → Cross-client failure ledger (findings feed the backlog)

Platforms · GoHighLevel · Conversation AI · Voice AI · Cloudflare Workers · Playwright

What I built

Gates before agents, not after them

Nothing runs without an approved strategy for that clinic; a missing one is refused by name rather than generated. An environment floor checks config, repo access, API reachability and token scopes, and every failure names the human who can grant the fix. Where a sub-account exists, a read-only capture of pipelines, fields, tags, calendars and workflow JSON runs first, because you cannot design against an account you have not read.

The first real gate is a short, plain-English build proposal: the workflow list, the design questions, a count of value gaps. Cutting a workflow the client will never action is free there and expensive later. A live failure sits behind it: nobody had asked how far apart a treatment course's sessions were, so a placeholder went into a live timer and the build carried on.

One naming law, written once

A systems architect then writes a binding registry: workflow names and numbers, the stage-to-canonical map, the full field, tag and value set, calendars, payment products, alert ids and mechanism policies. Names are load-bearing, because every later document must spell them the registry's way. A second gate shows the human that field-and-tag list in plain English alongside every surviving review finding. The list had always existed before the fan-out; the earlier process never showed it, so nobody read it until the build was finished.

Roles then write the pack in parallel, 13 to 36 documents depending on the client, each with a machine-readable sidecar declaring what it defines and references, so cross-document consistency is checkable rather than a reading exercise. Every unknown business fact is a fill token rather than a guess, because a guessed fact survives the pipeline and lands in live copy.

Adversarial lenses, a validator, and a fix loop that proves it ran

Two lenses read the pack: one reads the designed journey as a journey and finds where a lead falls out with nothing catching them, the other reads all client-visible copy against the compliance limits and the binding voice. A machine validator then asserts the design and the exported workflow JSON against hard contracts: stop-on-response on every send, the backward-move flag on every regressing stage write, a past-anchor branch on every anchored wait. Every check has a live failure behind it.

Findings are routed to owner roles and applied through a single revision pass, which replaced a multi-round loop that only re-entered on a surviving blocker and so let two important findings through. The pass reports dispatched versus applied plus three failure buckets: findings a fixer skipped, findings whose document had no owner, and documents whose fixer returned nothing. An audit that did not run and one that found nothing produce the same empty list.

Build to draft, publish by human

A conductor drives creation one workflow at a time from the registry, marking anything missing as blocked and cross-wiring references in a second pass. Writing sits behind a mutation gate naming the target location and the exact workflow list, because writing into the wrong sub-account is the one mistake that cannot be undone quietly.

The publish flag is never set. A human reviews each draft and publishes it in the builder, and that click is the mutation-approval gate for the whole system. One validator assertion catches the opposite: published, with a non-empty trigger file. Without it, a build whose workflows are all empty-trigger drafts passes.

One shared ledger of failures

The versioned baseline holds the contracts, the removal matrix, the build rules and the validator checks, each carrying the named live failure that produced it: not-found branches that dead-ended on every workflow of one account, backward stage moves that silently no-op because the flag defaults false, a reactivation layer present in three accounts and working in none. A fault found on one account becomes a standing check on every later one, which is what makes the ninth build cheaper than the first.

Edge cases and failure handling

  • An agent dies mid-write and the dependent writer runs against nothing. Stop conditions halt the run, and the answer to a dead checker is to rerun it, never to assume it passed.
  • A client needs something the blueprint does not cover. The build diverges and the divergence is logged with a one-line reason, then promoted to baseline or retired at the retro. Core contracts are not divergeable, even by strategy.
  • The diary lives in an external system. The blueprint drops the reminder and reschedule workflows and names a substitute inheriting their guards and removal rows, because removing a workflow removes jobs that do not disappear.
  • A build finishes but the client cannot go live. It sits in draft rather than publishing into an unready account.

How I verified it

Nothing was called done on the strength of the builder view or a successful API response. Each draft is verified read-only after creation with a per-workflow outcome table logged, then a full verify pass compares the live account against its design documents. It re-runs at go-live once the human has published, so the published state is verified rather than the draft.

The go-live checklist carries owners, dates and gated-by markers, opening with the long-lead items that cook while you build: registration bundles gate all messaging, an authenticated domain gates all email, a payment processor gates the deposit workflows. Later sections verify every pipeline transition, and per workflow the trigger, copy, waits, tags, fields and exits.

What changed

Nine systems were delivered in five and a half weeks: five live or published, three built to draft, one a complete design pack. Around 119 workflows were built or rebuilt into live accounts, and 17 AI agents configured across chat, booking and voice.

The agency has a delivery path: strategy gate, proposal gate, naming law, spec pack, adversarial audit, draft build, read-back, human publish.

Six owner handbooks went out with the builds, alongside a post-launch runbook in which every step carries one honest label: data-only, manual today with a named owner, or blocked on a linked refactor. It refuses to present a manual step as if it were automated.

Before / after

  • Before
  • ✕ Campaigns sold faster than the systems behind them were built
  • ✕ "Finished" builds with steps that saved cleanly and did nothing
  • ✕ The agency’s own flagship workflow carried 14 defects
  • ✕ No handover docs a clinic owner could actually operate from
  • After
  • ✓ A repeatable delivery path: spec pack → approval → draft build → audit → human publish
  • ✓ ~119 workflows built or rebuilt across nine accounts
  • ✓ Every fault found became a standing check on the next build
  • ✓ Owner handbooks and go-live checklists with every delivery

ScopeFigures on this page describe what was built, covered or verified — not a measured lift.

Related systems

Have something close to this? Book a call. I’ll tell you if I’ve already built it.

One Manila business day to reply. All client work is under NDA; what you see here is redrawn architecture with real metrics.

Book