Deliverables · 2026-08-25
You asked what an agency is actually delivering when they call a build finished. I read all 31 agency-os skills to answer it properly, and two of them changed how I think the product should be built. The catalog was already there. We have not been using it as one.
There is already an answer sitting in the plugin, and it is better than anything I would have invented.
client-delivery-engine ends every engagement with a handoff document: what was built, how to maintain it, what ongoing support costs. Alongside it, a scope document, a milestone tracker with measurable criteria, and GHL configuration guides.
The definition
A build is done when the agency can hand their client a document that says what was built, prove every line of it against the live account, and the client can run it without them.
Three conditions, all checkable. Not "the workflows are made." Every item in the handoff doc is a claim, and the OS verifies each one before it prints. That is our done-rule, pointed at the client instead of at us, and it is the single most sellable artifact in the product.
This matters commercially more than technically. The handoff document is what the agency shows to justify the invoice, what the client keeps, and what they read when they wonder whether to renew. Today most agencies produce it by hand, badly, or not at all. We can generate it from the build record for free, because we already hold every ID we created and every verification we ran.
The seven stages currently end at "go-live sign-off", which is an internal event. They should end at "handoff pack delivered", which is a client-facing one. Same work, one more step, and it converts a build into a renewal conversation.
You asked whether these are simple builds or the tiered-branch monsters like Riverhead. Both, and the answer has to be explicit or every sales conversation restarts from zero. These are also the module bundles and the price ladder.
Most agencies call this "done" and most do it badly. It is where the silent failures get born.
Everything above, plus the parts that actually generate the client's leads. This is the tier we should design the product around.
The Riverhead shape. Deep branching, multiple entry points, real segmentation. Doable today, and the tier where our order-enforcement and ID verification are worth the most, because this is where hand-built accounts break.
A VA cannot decide scope. Pick a tier at intake and the whole queue is determined — which modules run, in what order, what the handoff pack contains, what "verified" means. It turns an open-ended build into a finite checklist, which is the only way a non-expert finishes one.
Read this morning. Three buckets: what becomes a sellable module, what we point at our own business, and what does not belong in this product.
| Skill | Ships to the client as | Tier |
|---|---|---|
| conversation-ai-architect | Chat widget, qualification bot, booking bot, voice adaptation | 2–3 |
| funnel-architect | Funnel, landing pages, email/SMS sequences, CRM wiring | 2 |
| interactive-lead-magnet | Quiz, calculator, scorecard, audit tool | 2 |
| frontend-design | The actual page design, so it isn't generic | 2 |
| sales-conversion-engine | Pipeline, speed-to-lead, qualification, follow-up | 1–2 |
| client-delivery-engine | The handoff pack itself | 1 |
| meta-lead-system | Lead form campaign + GHL automations | 2 |
| meta-ads-copywriter | The ad copy inside it | 2 |
| legendary-copywriters | Copy for every asset above | 1–3 |
| client-retention | Churn scoring, save flows, win-back | 3 |
| referrals | Referral and affiliate program | 3 |
| content-system-architect | 30-day content system | 3 |
| blog-writer | SEO articles | 3 |
| programmatic-seo | Pages at scale from a dataset | 3 |
| keyword-research | The plan the two above run on | 3 |
| creative-director | Image and video direction for the assets | 2–3 |
| vsl-architect | VSL script when the funnel needs video | 3 |
| Skill | What it produces for us | When |
|---|---|---|
| ideal-customer-avatar | The solopreneur agency owner, properly profiled. Paul and Dane are the sample. | Now |
| offer-architect | Our tiers, pricing and guarantee. Settles the $1.5–3k install question. | Now |
| vsl-architect | The VSL script off "two builds a month to six". | After the pitch is locked |
| legendary-copywriters | Site copy, emails, the sales page. | After the VSL |
| brand-dna | Voice, so everything sounds like you and not like a tool. | Now |
| agency-sales-system | Our own outbound to the founding cohort. | Before cohort |
| critique | Pressure-tests any of the above before it ships. | Every time |
auto-editor, video-repurposer, content-repurposer, social-caption-writer, video-prompt-builder, heygen — these serve the agency's own content marketing, not a client account build. Useful to you personally; not a module in this product. dream is internal memory hygiene.
These skills produce specifications and copy. Turning a funnel spec into a live GHL funnel is our 242 tools doing the work. The skill is the brain, the tools are the hands, and the gap between them is where the build actually lives. Do not let the catalog make this sound finished — it maps the destination, not the road.
You asked how to link and integrate different modules. The plugin answered it and I nearly designed a worse version from scratch.
Every agency-os skill declares typed schema inputs and outputs. conversation-ai-architect consumes ica-output, offer-output, funnel-output and meta-lead-output. That is a dependency graph, machine-readable, already written.
Design decision
Adopt the schema contract wholesale. Don't invent our own.
Our module contract gets three fields from the architecture page (connectors, writes, verification) bolted onto agency-os's existing schema in / schema out. That gives us dependency ordering for free, tells the queue what can run next, and means a VA is never asked "what should we do first" — the graph knows.
You flagged the switching between the MCP connection and the API-plus-extension path. It is the sharpest UX risk in the whole product and it deserves a hard rule.
We have three routes to GoHighLevel, and they are not equal:
| Route | Covers | Fragility |
|---|---|---|
| MCP tools | The overwhelming majority. Customer's own Private Integration token. | Stable |
| Direct API | Where the MCP surface has a gap. | Same token |
| Browser / Workflow Builder | What no API exposes. Needs a real login. | Assume it breaks |
The rule
The operator never learns which route ran. Ever.
A VA cannot be asked to understand "this bit needs the extension." The queue says build the nurture sequence; the OS picks the route. The only time the route surfaces is when a human action is genuinely required — a login, a consent — and then it is a task in the queue with a picture and a sentence, not an error.
Two consequences worth accepting now:
You're right that we've never written this. We have been selling remote team access as a benefit while leaving the hard part undocumented. That is a promise with no instructions behind it.
If the answer is Option B from the positioning page — the agency runs one instance and VAs open a URL — then the setup guide is not documentation, it is the first module. Nobody reaches value without it.
| Step | What the agency owner actually does |
|---|---|
| 1 · Pick the box | A spare Mac or PC that stays on, or a small cloud VM. Plain recommendations with real prices, not "provision infrastructure". |
| 2 · Install once | One command or one installer. Claude, the OS, the connectors. This should be a script we ship, not a page they follow. |
| 3 · Connect the accounts | Their GHL token, their recorder, their Stripe. Entered once, on their box, never leaving it. |
| 4 · Give it a door | A URL their team can reach. Their own domain if they want it. This is the part that needs to be genuinely easy or the whole promise dies here. |
| 5 · Add the team | Named people, each with what they may approve. A VA can run a build and cannot approve a plan. |
| 6 · Prove it | The VA opens the URL from their own laptop, on another continent, and completes one real task. That is the install verified, in our own house style. |
Roles. "A VA can run but not approve" does not exist today. The approve gate is currently anyone-who-clicks. Multi-person use makes roles a v1 requirement, not a later one.
Remote access without a security hole. Telling a non-technical owner to expose a machine to the internet is how people get hurt. This needs a safe default we ship and support, and it is the piece I would most want reviewed adversarially before a single customer follows it.
Revised from the architecture page now that the catalog exists. Same principle: the risky refactor early, the sales instrument before the cohort, nothing built on sand.
| # | Step | Why here |
|---|---|---|
| 0 | Lock the pitch and the tiers | Everything downstream is scoped by them. Days, and mostly your decision rather than my keyboard. |
| 1 | Module contract = agency-os schema in/out + connectors + writes + verification | Adopting an existing graph instead of inventing one. Unblocks ordering and the queue. |
| 2 | Tier 1 end to end, verified, with the handoff pack | One complete sellable outcome beats five half-modules. This is the demo and the proof. |
| 3 | Queue → Task → Proof interface + roles | Rebuilt around the VA. Roles land here because the team machine needs them. |
| 4 | Team machine: installer, door, guide | The promise Dane is waiting on. Security review before anyone follows it. |
| 5 | Connector spine, GHL refactored behind it | Load-bearing, no user-visible change, and the insurance against GHL. |
| 6 | Recorder connector — call becomes the brief | Biggest cut to hours-per-build. Proves the spine. Clinic-OS inherits it. |
| 7 | Tier 2 modules, in revenue order | Bot, funnel, lead magnet, reactivation. Each one a saleable line item. |
| 8 | Daily brief, then founding cohort | The retainer product, then the people who pay for it. |
You listed 31 skills to run. I'd run 7 of them, on our own business, and treat the other 17 as a build roadmap rather than something to execute now. Running blog-writer or content-system-architect today generates a content plan for a customer who does not exist yet. The seven that pay off immediately are avatar, offer, brand voice, VSL, copy, sales system and critique — and offer-architect is the one I'd start with, because it settles the pricing questions still open on the architecture page.