Why AI never writes to your GoHighLevel account

Agencies are rightly cautious about letting an AI tool near a client's GoHighLevel account. The account carries the client's leads, their phone number, their reputation. A tool that "uses AI to configure GoHighLevel" sounds like it might do something unpredictable in there.

usepicked uses AI heavily and never lets it touch GoHighLevel. This post explains the boundary, because it is the design decision everything else in the product follows from.

The rule

AI in usepicked produces drafts. Drafts are validated, then approved by a person, then compiled into a specification. Provisioning reads the specification and nothing else. There is no code path from a model's output to a GoHighLevel API call, and no GoHighLevel credential is ever part of a prompt.

Concretely, the pipeline for every piece of generated content looks like this:

1. Generate. A task (propose pipeline stages, draft the missed-call reply, configure the Voice AI agent, write the "Our services" article) sends the confirmed business profile to the model and asks for a structured answer.
2. Validate. The answer is checked against a JSON schema for that task. A pipeline with duplicate stage keys, an SMS with an empty body, an agent config with an action we do not support: all rejected. The model gets one retry with the validation errors attached; if that also fails, the item is marked as failed and shown to you as such, never silently accepted.
3. Review. Every valid draft appears in the wizard marked as a draft. You edit it, ask for a rewrite, or approve it. Nothing is approved by default, and regenerating never deletes the earlier revision.
4. Compile. On the Review step, approval compiles all approved items into a versioned Build specification. The compiler is deterministic: the same approved inputs always produce the same specification, and an approved specification cannot be modified afterwards.
5. Provision. The specification drives a series of ordered, retryable steps against a temporary sub-account in our agency. Each step is idempotent and checks for existing state before it writes. A failed API call marks the step as failed and pauses; it never restarts the Build or duplicates anything.

Why the boundary is worth the friction

It would be faster to let the model write straight into the account. We do not, for three reasons.

Accountability. An agency is responsible for what its client's customers receive. A message a person has read and ticked is the agency's message. A message an AI sent on its own is a liability. The review step is not a formality; it is where responsibility changes hands.

Reproducibility. Because provisioning reads only a frozen specification, a Build can be re-provisioned, inspected or audited months later and produce the same account. Every specification version and every status change is recorded with who did it and when.

Blast radius. Website analysis feeds text from an arbitrary site into a model. Web pages can contain instructions aimed at language models. In usepicked that text is wrapped as untrusted data, the extraction task has no tools and no access to anything but the schema it fills in, and the output is a set of proposals you confirm one by one. The worst case is a wrong proposal you delete, not a wrong action in a client's account.

What the model actually sees

The model receives the business profile you confirmed, your edits and rewrite instructions, and, for website analysis, the extracted text of the pages you asked us to read. It does not receive GoHighLevel tokens, payment details or anything from other workspaces. Every call is logged with the task, the model, token counts and cost, and each Build has a spending cap so a runaway regeneration loop cannot become a bill.

What this means for you

You can put a client's Build through usepicked with the same confidence you would give a junior team member who drafts everything and is not allowed to press publish. The drafts are fast, the review is yours, and the account is only ever written from what you approved.