Custom Client Requests → Reliable Production Agents

The integrator job has one recurring shape. The client emails: “we want the AI to do X for our specific situation.” X is always slightly different. The temptation is always the same: open a new Python project and write it from scratch.

I stopped doing that two engagements ago. Here’s the workflow now.

The problem with one-off builds

A bespoke build is fine the first time. By the third client request you’re maintaining three subtly different codebases, none of which talk to each other, and any change in an upstream API breaks all three at once.

The pattern that works is to never start from a blank file. Start from a skill that’s 80% there, fork it, customize the last 20%, ship.

A real example: proposals

Most of my agency-shaped clients write proposals manually. Each one is a four-to-six hour drag. Copy the last proposal, swap names, find a relevant case study, customize the timeline, format in Docs or InDesign, export to PDF, send.

The skill version (Proposal Builder) inverts the work:

1. The client uploads their proposal template once. Branding, sections, placeholders.
2. They drop in their case studies as forkable content (titles, verticals, results in their own language).
3. They set their pricing structure.
4. For every new proposal: a one-line briefing in, full draft out.

Total review time per proposal afterwards is short. The integrator (me) doesn’t write a single line of bespoke code per client.

The template + briefing pattern

This generalises. Every “custom client request” I’ve shipped follows the same three-step shape:

Step 1: Capture the client’s existing work as a template. Their proposal style, their report format, their email cadence. Whatever they’re already doing manually, capture it once.

Step 2: Capture the variation surface. What changes per case? Client name, scope, industry, pricing tier. That’s the briefing.

Step 3: Have the skill assemble, never invent. The AI selects sections, fills placeholders, picks matching case studies. It does not generate facts the client will sign their name to.

That last point is the load-bearing one. The minute the AI is generating numbers or claims the client hasn’t pre-approved, the integrator owns those claims. That’s a liability, not a feature.

What the install looks like

pipx install wiserecipes
wiserecipes install proposal-builder

Then:

proposal-builder generate \
  --template="my-client-template" \
  --briefing="SaaS company, paid media management, multi-month engagement, mid-budget" \
  --client="acme-saas"

Output is a draft. Review pass takes a fraction of the original.

The mistake I keep seeing other integrators make

They productise too early. They take a request from one client, build it as a fully bespoke service, and try to sell that service to ten more clients. By client three they’re customising for free.

The skill-based approach inverts the economics. Each client gets a fork of an existing skill, not a brand new build. The skill itself stays under version control upstream, which means improvements one client funds also benefit the others.

The integrator’s leverage isn’t writing more code per engagement. It’s writing less.

When to actually go custom

I do still build from scratch occasionally. The rule of thumb:

• If three skills get within 80% of the request, fork the closest one
• If nothing in the catalog is closer than 50%, write it from scratch as a new skill (and add it to the catalog so the next client has it)
• If the request is regulated, audit-sensitive, or moves money, scope it carefully and probably don’t do it on a fixed-price contract

That last category is the one where integrators get burned. AI generating regulated communications is a category of work where “ship a draft, review fast” doesn’t apply. Different game, different pricing.

Install

pipx install wiserecipes
wiserecipes install proposal-builder

Available on the Operator tier ($100/mo).

---

Proposal Builder is one of the skills I use to ship custom client requests as production-ready automations. Catalog at /library.