I built a marketing AI operating system for a 60-person team. The most valuable thing in it is the part that refuses to write.

Punti chiave

1. Data / fonte. 12 agosto 2026, LinkedIn Pulse, newsletter Growth Marketing Fit, ~2.500 parole. Sistema costruito in Claude per un team marketing di ~60 persone.
2. Framing chiave. « I thought I was building a content machine. I was building a trust machine, and I didn't know it, so I spent my initial effort in exactly the wrong place. » ### Vietare il « pass » nudo Un verificatore è un sistema a mondo chiuso: può pronunciarsi solo su ciò che gli è stato fornito. Di fronte a un'affermazione che nessuna delle sue fonti copre, non trova contraddizioni e restituisce un verdetto favorevole indistinguibile da un controllo reale. La correzione è un vincolo di formato: | Il rapporto deve dichiarare | Perché | |---|---| | Quante affermazioni sono state controllate | denominatore: senza di esso, un « OK » non significa nulla | | Quante sono state effettivamente ricondotte a una fonte | è il vero tasso di copertura, sempre più basso | | Quali cadevano fuori dalla sua giurisdizione | altrimenti il giudice va oltre il suo mandato e il silenzio su altre affermazioni passa per accordo | | Quali non sono possedute da nessuna fonte nel sistema | è il vero registro dei rischi dell'organizzazione | « I can't verify this » deve essere un risultato di prima classe, sullo stesso piano di « pass » e « fail ». L'anti-pattern simmetrico è più pericoloso dell'assenza totale di controllo: « a good review that's worthless is far worse than no review, because it launders the output » — qualcuno a valle vede reviewed: pass e smette di controllare. Rimando incrociato a [[willison-fable-judgement-delegation-subagents-2026-07-03]]. ### Il controllo che la verifica per singolo asset non può produrre Due asset della stessa campagna possono essere ciascuno individualmente corretto, ciascuno riconducibile a una fonte reale, ciascuno convalidato — e comunque contraddirsi a vicenda. Verificare rispetto al livello di verità e verificare gli asset l'uno contro l'altro sono due controlli diversi; il primo non può produrre il secondo. La diagnosi dell'autore: « if you run multi-asset campaigns and only verify one asset at a time, you have this bug right now. » Trasposizione fuori dal marketing: una PR che tocca tre file, un insieme di spec generate in batch, un documento e il suo codice prodotti insieme. La coerenza incrociata è un controllo a livello di bundle, mai una somma di controlli unitari. ### Il livello di verità Fallimento raccontato: i fatti di prodotto vivevano dentro la skill che scriveva gli articoli, poi lo stesso fatto doveva esistere nella skill email, nella battlecard, nella pagina web. « Within a few weeks I had four slightly different versions of our launch date in four different files, and the drift was invisible because each file was individually plausible. » Regola: « a document that states facts and a document that produces content are two different documents, with two different owners », ciascuno versionato e datato. A nulla che produce contenuto è permesso contenere un fatto — deve richiederlo. Beneficio: un fatto cambia, lo si cambia una volta sola, tutte le 35 skill sono corrette il giorno dopo; un'affermazione viene contestata, c'è un solo posto dove guardare. Perché nessuno lo costruisce: « You cannot demo a truth layer. You can only demo what it prevents, which is nothing visible. » Esercizio proposto: aprire gli ultimi cinque asset prodotti, evidenziare ogni affermazione fattuale, indicare per ciascuna l'unico documento che la possiede — « the ones you can't assign an owner to are your real risk register. » Estende [[vasilopoulos-codified-context-infrastructure-ai-agents-2026-02-24]]. ### Due lezioni sulle skill 1. Il contratto di output deve essere paranoico riguardo all'ambiguità. Per settimane, la skill « blog post » ha scritto descrizioni di articoli — intestazioni di sezione seguite da una frase che spiegava cosa avrebbe coperto la sezione, « every single time » — e ha superato ogni revisione, perché la struttura era impeccabile. Causa: una riga ambigua nel template (« the post, under the flavour's own section headers »), letta ragionevolmente come una richiesta di scaletta. Dettaglio organizzativo più importante del bug: nessuno l'ha segnalato, « people assume the tool is right and they're using it wrong. » 2. Il compito più importante di una skill è descrivere a cosa non serve. Superate circa trenta skill, il problema smette di essere la qualità e diventa il routing: due skill che gestiscono entrambe plausibilmente « write me something for sales » si contendono ogni richiesta, e il vincitore arbitrario produce il formato sbagliato. Metà di ogni descrizione è diventata un confine esplicito. Confronto con [[shihipar-claude-code-lessons-building-skills-2026-06-03]]. ### Dal prompt all'idraulica Le regole di voce vietavano i trattini lunghi, ogni prompt lo diceva, i tester continuavano a trovarne per settimane: « I kept repeating the rule louder, which is a probabilistic fix to a problem whose deterministic solution was right there. » Correzione: un'unica funzione lato output che li rimuove. Euristica generalizzabile: « if you catch yourself repeating an instruction, that's the signal to pull it out of the prompt and put it in the plumbing », con il suo corollario — « asking nicely is not a control. » ### Il fallimento silenzioso Una costante destinata a contenere un carattere marcatore invisibile era stata svuotata a stringa vuota. Nessun diff visibile, nessun errore. A valle, una fase di pulizia ha iniziato a intercettare ogni cifra in ogni prompt e a rimuoverla: « 7.1% across 6,000+ orgs, 2500 words » raggiungeva il modello come « .% across ,+ orgs, words ». Ogni statistica, data, conteggio parole e numero di sezione silenziosamente rimossi, per un numero imprecisato di release. Era questa la vera ragione per cui le cifre citate risultavano sempre sbagliate — « and I'd spent weeks blaming the model's tendency to make up numbers. It was making them up because I'd deleted them. » Principio: « Traditional software crashes when it breaks. These systems keep going, confidently, at reduced quality, and produce something that looks correct. » Due correzioni: testare la pipeline, non solo l'output — un test la cui unica funzione è verificare che i numeri sopravvivano a un round trip attraverso l'assemblaggio del prompt; e ricordare che la validazione ha le stesse lacune del sistema — un campo limitato a 500 caratteri è rimasto a 688 per due release perché lo script controllava ogni altro limite tranne quello. Regola diagnostica: prima di accusare un modello di aver inventato un numero, verificare che il numero lo abbia effettivamente raggiunto. ### Livello 4, distribuzione interna « This is where most internal AI projects die quietly. Not from technical failure. From being technically excellent and used by four people. » L'autore aveva costruito prima per sé — un plugin che richiedeva dimestichezza con la riga di comando, il che descriveva sei persone su sessanta. Correzione: lo stesso sistema costruito due volte, stessa conoscenza e stessi controlli, due punti d'accesso — un plugin per chi costruisce, un'applicazione browser per tutti gli altri (catalogo, tre campi, una bozza con i suoi controlli accanto come pulsanti). Il punto più fine della sezione: l'adozione segue la fiducia, non la capacità. Lo strumento ha guadagnato uso quando l'output ha iniziato ad ammettere ciò di cui non era sicuro — « A draft that flags "this customer example is illustrative, find a real one before publishing" gets used. A draft that confidently presents a made-up customer example gets used once, embarrasses someone, and the tool dies by word of mouth. » ### Insegnare al sistema a rifiutare L'ultimo pezzo adatta un asset per un altro segmento di mercato e conosce il segmento che l'azienda ha deciso di non perseguire: richiesto per quel segmento, rifiuta e spiega perché. « Same principle as the coverage statement. A system that can only say yes will confidently hand you the wrong thing forever, and you won't be able to tell "this is right" from "this was the only answer available." » Il rifiuto e l'ammissione di ignoranza sono la stessa primitiva: la capacità del sistema di delimitare il proprio dominio di competenza. ### Le tre incertezze lasciate aperte 1. Livello di verità integrato o recuperato in tempo reale? « Embedded copies go stale without anyone noticing. Live fetches are slow and break when someone renames a folder. » L'autore usa un mix e dice che non è una scelta ragionata. 2. Il costo della verifica regge ancora? Un asset completamente verificato costa « several times » una bozza grezza: ne vale la pena per il lavoro rivolto al pubblico, probabilmente no per un riepilogo interno, « and the line between the two is blurrier than my system claims. » Variabile di governance da strumentare per prima: un livello di verifica legato alla criticità dell'asset. 3. Quanto di tutto ciò sopravvive alle prossime due generazioni di modelli? La sua scommessa, presentata come tale: il livello di verità e la disciplina di copertura sopravvivono, perché « solve an organizational problem of provenance and ownership that would exist even with a perfect model. » ### Il piano « se inizi lunedì » 1. Scrivere i dieci fatti che il team ripete più spesso, con un proprietario e una data per ciascuno — versione zero del livello di verità, « it takes an afternoon. » 2. Prendere il proprio prompt migliore ed estrarne ogni fatto in quel documento; far sì che il prompt li richieda. 3. Costruire una fase di verifica che gira in una sessione nuova, vede solo la bozza e le fonti, e deve dichiarare cosa non ha potuto controllare. 4. Individuare ciò che continua a essere ripetuto nei prompt e spostarlo nel codice. 5. Mostrarlo a una persona non tecnica e osservarla usarlo senza aiuto. Test di base da eseguire prima di tutto: far passare un asset già pubblicato attraverso il controllo in una sessione completamente nuova, senza altro contesto che la bozza e le fonti. « What comes back is your real quality baseline. It's usually humbling. Mine was. »