Hey everyone! Just go a message from my client saying that he closed a deal (he organizes events) for a major client of his, using a proposal that was 100% AI generated, using an ICM system I've created.
How the system works (TL;DR) - see the images with the input and the ouptut.
It's not a prompt, it's a workspace the client's team operates every day. Messages and a voice note go in; an on-brand HTML proposal comes out, and a PDF when it closes. Two human gates: one on the content, one on the rendered PDF. The AI assists, the human decides.
Three rules do most of the work:
1. The AI never invents. Every sentence traces back to a message or to the operator's dictation. Missing something → it asks. Data that arrived with nowhere to go → it also asks, never decides silently.
2. The AI never sets a price. Values come from the operator, always.
3. Nothing reaches the end client without explicit human approval.
And the part I like most: when a proposal closes, the system asks about every correction the operator made: "was that just this one, or is it a rule from now on?" If it's a rule, it proposes the edit to the rules file. The next proposal is born better.
---
The longer version, for whoever wants the mechanics
The shape is a pipeline that empties into a record library. Each proposal is one run; each finished run becomes a record the next run can learn from.
Inputs. The operator drops in everything that actually arrived: forwarded client messages, supplier quotes, a voice note with their own instructions. No inputs, no assembly. First question before building anything: is there an existing proposal to use as a base, or should I search the archive for similar events?
Assembly. The AI loads only what this step needs — proposal anatomy, brand voice, design rules, hard constraints and builds the HTML in the company's identity. Photos come from a catalog with provenance, never from a search; real photos of the company's own events come first, and a reference image is always labeled as one. If a photo's commercial attribute doesn't match the item being sold, it doesn't go in. What it hands back isn't just a draft, it's a draft plus a list of what's missing, so the operator knows which supplier to chase.
Gates and negotiation. The operator reviews content, photos and values. Then a second gate on the rendered PDF (approving the words is not the same as approving the layout). Each round of client feedback raises the version number, and old versions stay as a record of what was actually sent.
The reuse unit is the block, not the slide. This was the most important design decision. The team used to build proposals by pasting slides from old decks. If the system reused blocks by supplier name, it would eventually describe the wrong show with the right name, the right photo and the right bio — the most dangerous failure mode there is, because nothing about it looks wrong. So the bank stores one line per product, not per supplier.
There is a house pricing formula, and the system may propose it but it always asks, and never applies it silently. Same principle everywhere: the constraints are the product. This is where 60/30/10 lives
Two file names, on purpose. Inside the studio the artifact is draft → FINAL, which is what the gates enforce. The file that circulates carries the house's own naming convention which we didn't invent, we measured it from 1,208 real decks the team had built by hand over the years.
That's the whole philosophy: the conventions were extracted from how the business already works, not imposed on it. Configure the factory, not the product.