Come costruire un sistema di outbound auto-migliorante su Codex

All'inizio di quest'anno, Andrej Karpathy (@karpathy) ha puntato un agente sul suo stesso codice di training e lo ha lasciato eseguire per due giorni. Ha lanciato 700 esperimenti, ha tenuto i 20 che hanno superato il benchmark e ha reso l'addestramento del modello più veloce dell'11%. Poi ha detto qualcosa di molto interessante: qualsiasi metrica che puoi valutare a basso costo può essere affidata a uno sciame di agenti.

Il tasso di risposta è una metrica che puoi valutare a basso costo. Da allora ho passato un po' di tempo a capire come sia quel ciclo applicato all'outbound.

La mia build:

Codex legge i risultati della settimana precedente, modifica i file di scoring e play eseguiti dal sistema di outbound, lancia un test e apre una pull request. Propone una modifica al playbook con le prove e il punteggio allegati, quindi aspetta l'approvazione umana. L'invio e l'unione rimangono fuori dal ciclo.

Ho costruito il primo ciclo alcune volte: percepire il mercato, valutare l'account, scrivere dal segnale, controllare il messaggio, registrare il risultato, imparare dalla risposta. Questo articolo parla del secondo ciclo, quello che modifica il primo.

Questa è la build: GTM come codice versionato che migliora grazie al mercato.

Il repository

Inizia con la cartella. La struttura è importante perché Codex può migliorare solo ciò che può leggere e modificare.

1codex-self-improving-outbound/
2  AGENTS.md
3  README.md
4  config/
5    scoring.yaml
6    plays.yaml
7  prompts/
8    improve_scoring.md
9    improve_prompt.md
10    pr_summary.md
11  memory/
12    outcomes.jsonl
13  evals/
14    fixtures.yaml
15    score.py
16  scripts/
17    append_outcome.py
18    run_codex_step.sh
19    propose_improvement.py
20    open_pr.sh
21    weekly_tune.sh
22  examples/
23    outcomes.sample.jsonl
24    weekly-pr.md

Il repository è volutamente semplice. config/scoring.yaml contiene le regole che decidono quali segnali contano. prompts/ contiene i play che scrivono i messaggi. memory/outcomes.jsonl contiene ciò che ha fatto il mercato. evals/score.py è il gate che dice se una modifica proposta ha aiutato. AGENTS.md è la legge che Codex legge prima di toccare qualsiasi cosa.

Esegui la prima versione offline. Nessun CRM, nessun arricchimento, nessun sistema di delivery. Il ciclo di miglioramento deve dimostrarsi sui file locali prima di avvicinarsi a un vero sistema di outbound.

Step 1. Scrivi prima la legge

Prima del file di scoring, prima dei file dei prompt, scrivi AGENTS.md. Questo è il file che mantiene l'agente utile e contenuto.

1# Regole per l'Outbound Auto-Migliorante
2
3Migliori un sistema di outbound a partire dai risultati.
4
5Regole ferree:
6- Non inviare mai messaggi.
7- Non fare scraping o arricchire mai persone reali.
8- Non fare mai auto-merge.
9- Modifica solo i file in questo repository.
10- Cambia un concetto alla volta.
11- Cita i risultati da memory/outcomes.jsonl per ogni modifica proposta.
12- Migliora evals/score.py prima che una modifica possa diventare una PR.
13- Se la valutazione non migliora, annulla la tua modifica e fermati.
14
15Modifiche consentite:
16- config/scoring.yaml
17- config/plays.yaml
18- prompts/*.md
19
20Output richiesto:
21- file modificati
22- motivo per ogni modifica
23- punteggio prima
24- punteggio dopo
25- riepilogo della pull request

La legge ha un solo compito: restringere il lavoro. Senza di essa, Codex cercherà di aiutare ampliando l'ambito. Aggiungerà più dati, toccherà più file, chiamerà più strumenti o automatizzerà un passaggio che dovrebbe rimanere sotto il controllo umano. Qui il lavoro è più piccolo: leggere i risultati, proporre una modifica a un file, dimostrare che ha aiutato, poi aspettare.

Come si presenta un buon risultato. Puoi leggere la legge prima di approvare una PR e sapere esattamente cosa a Codex era permesso fare.

Dove si rompe. La legge diventa un documento di conformità. Se AGENTS.md ha bisogno di un indice, è già troppo grande. Mantienila operativa.

Step 2. Sposta il giudizio nella configurazione

La maggior parte del giudizio nell'outbound vive nella testa di qualcuno. Poi il team compra un software e si aspetta che il software migliori una decisione che non può vedere.

Sposta il giudizio in un file.

1segnali:
2  competitor_comparison:
3    peso: 8
4    motivo: "l'acquirente sta confrontando alternative"
5  implementation_page_visit:
6    peso: 6
7    motivo: "l'acquirente sta verificando se può essere installato"
8  job_repost:
9    peso: 5
10    motivo: "la posizione è ancora aperta e urgente"
11  funding_event:
12    peso: 5
13    motivo: "il budget o il mandato potrebbero essere cambiati"
14  generic_download:
15    peso: 1
16    motivo: "interesse per i contenuti, scarsa intenzione d'acquisto"
17
18soglie:
19  bozza: 6
20  revisione_umana: 10
21
22segnali_negativi:
23  student_research: -8
24  vendor_pitch: -6
25  competitor: -10

Questo file inizia come un'ipotesi visibile. Se un download generico dovesse valere zero, il team può puntare alla riga esatta e cambiarla. Se una visita a una pagina di implementazione è un segnale più forte di quanto pensassi, Codex può proporre il diff e mostrare le righe di risultato che lo giustificano.

Non seppellire questa logica in una funzione Python. Se la regola è visibile, il team può revisionarla, discuterla e migliorarla senza trasformare un giudizio di vendita in un refactoring di ingegneria.

Come si presenta un buon risultato. Il file è abbastanza piccolo da poter essere discusso. Cinque segnali sono una buona prima versione.

Dove si rompe. Il file di scoring diventa un cassetto dei rifiuti. Venti segnali, sei soglie e regole di eccezione per ogni caso limite faranno sì che il miglioratore si adatti eccessivamente. Inizia in modo ristretto e lascia che i risultati ti dicano dove va posizionata la prossima manopola.

Step 3. Scrivi i risultati come memoria

Il file più importante è memory/outcomes.jsonl.

Una riga per contatto, scritta quando il risultato è noto:

1{"date":"2026-07-01","account":"Northwind Finance","signal":"competitor_comparison","play":"migration_note","score":8,"outcome":"reply","reason":"ha chiesto le note di migrazione"}
2{"date":"2026-07-01","account":"Bluepeak Studio","signal":"generic_download","play":"resource_followup","score":1,"outcome":"no_reply","reason":"intenzione solo di contenuti"}
3{"date":"2026-07-02","account":"KiteOps","signal":"implementation_page_visit","play":"implementation_angle","score":6,"outcome":"reply","reason":"ha chiesto informazioni sulla tempistica di implementazione"}
4{"date":"2026-07-02","account":"Atlas Recruiting","signal":"job_repost","play":"hiring_angle","score":5,"outcome":"bad_fit","reason":"richiesta di ricerca studentesca"}

Il campo reason è il punto centrale. no_reply non ti dice quasi nulla. content-only intent dice all'esecuzione successiva che questo segnale potrebbe non meritare una bozza. bad_fit è utile solo quando il motivo spiega il perché. asked about implementation timeline è il tipo di dettaglio che può cambiare un peso.

Costruisci il validatore prima di costruire il miglioratore:

1Costruisci scripts/append_outcome.py.
2
3Accetta:
4- date
5- account
6- signal
7- play
8- score
9- outcome: reply | meeting | no_reply | bad_fit | bounced
10- reason
11
12Rifiuta:
13- campi mancanti
14- outcome sconosciuti
15- reason vuoto
16- date future
17
18Aggiungi righe valide a memory/outcomes.jsonl.
19Stampa la riga aggiunta.

È qui che inizia il compounding. Una dashboard può dirti che una campagna è in calo. Un registro dei risultati pulito può dire a Codex quale segnale, play o frase dovrebbe cambiare prima dell'esecuzione successiva.

Come si presenta un buon risultato. Dopo una settimana, un estraneo può leggere il file e capire quali segnali hanno generato risposte, quali play hanno generato conversazioni di cattivo adattamento e quale preferito interno il mercato ha ignorato.

Dove si rompe. Il team inserisce i risultati di venerdì a memoria. I successi sopravvivono, le ragioni dei cattivi adattamenti si offuscano e il sistema impara dalla finzione. Scrivi la riga quando il risultato arriva.

Step 4. Costruisci il gate di valutazione

Prima che Codex modifichi qualcosa, ha bisogno di un test a cui non possa sottrarsi.

Crea evals/fixtures.yaml:

1casi:
2  - account: Northwind Finance
3    segnali: [competitor_comparison, implementation_page_visit]
4    atteso: revisione_umana
5    nota: "due segnali forti su un account"
6
7  - account: Bluepeak Studio
8    segnali: [generic_download]
9    atteso: ignora
10    nota: "intenzione solo di contenuti"
11
12  - account: KiteOps
13    segnali: [implementation_page_visit]
14    atteso: bozza
15    nota: "l'intenzione di implementazione dovrebbe superare la soglia bozza"
16
17  - account: Atlas Recruiting
18    segnali: [job_repost, student_research]
19    atteso: ignora
20    nota: "il marcatore di cattivo adattamento annulla il segnale"

Poi crea evals/score.py:

1Costruisci evals/score.py.
2
3Leggi config/scoring.yaml e evals/fixtures.yaml.
4
5Per ogni caso:
61. Somma i pesi per ogni segnale.
72. Aggiungi le penalità dei segnali negativi.
83. Instrada l'account:
9   - score >= soglie.revisione_umana => revisione_umana
10   - score >= soglie.bozza => bozza
11   - altrimenti => ignora
124. Confronta il percorso con l'atteso.
13
14Stampa ogni previsione.
15Stampa la precisione finale come score=0.00 a score=1.00.
16Esci con 0 solo quando la precisione è 1.00.

Il primo gate dovrebbe essere abbastanza piccolo da essere compreso e abbastanza preciso da cogliere un vero errore. Nella mia prima esecuzione, la baseline ha fallito un caso:

1Northwind Finance: predicted=human_review expected=human_review
2Bluepeak Studio: predicted=ignore expected=ignore
3KiteOps: predicted=ignore expected=draft
4Atlas Recruiting: predicted=ignore expected=ignore
5score=0.75

È stato positivo. Il sistema aveva l'intenzione di implementazione al di sotto della soglia bozza, quindi ha ignorato un account che il fixture diceva meritare un messaggio. Meglio cogliere questo in un test che dopo un mese di account persi.

Come si presenta un buon risultato. Un comando dà un numero, e ogni caso fallito è facile da ispezionare.

Dove si rompe. Il fixture include solo vittorie ovvie. Poi ogni modifica sconsiderata passa. Metti casi brutti nel gate: intenzione debole, cattivo adattamento, nessuna risposta, segnali obsoleti e gli account che avresti voluto che il sistema avesse saltato.

Step 5. Lascia che Codex proponga una modifica allo scoring

Ora Codex può modificare.

Crea prompts/improve_scoring.md:

1Migliori il sistema di scoring dell'outbound.
2
3Leggi:
4- AGENTS.md
5- config/scoring.yaml
6- memory/outcomes.jsonl
7- evals/fixtures.yaml
8
9Il tuo compito:
101. Trova una regola di scoring che dovrebbe cambiare.
112. Il motivo deve citare memory/outcomes.jsonl.
123. Cambia solo config/scoring.yaml.
134. Esegui python3 evals/score.py.
145. Se il punteggio migliora, mantieni la modifica.
156. Se il punteggio rimane uguale o diminuisce, annulla la tua modifica e fermati.
16
17Output:
18- la riga esatta modificata
19- le righe di risultato che l'hanno causata
20- punteggio prima
21- punteggio dopo
22- se la modifica dovrebbe diventare una PR
23
24Non modificare i prompt.
25Non aggiungere nuovi segnali.
26Non toccare la delivery.

Eseguilo attraverso il wrapper del repository:

1scripts/run_codex_step.sh improve_scoring

La prima versione del mio miglioratore ha fatto un errore utile. Ha inseguito il segnale di risposta più pulito. competitor_comparison aveva il tasso di risposta più forte nel piccolo registro dei risultati, quindi il miglioratore voleva aumentare quel peso. La valutazione è rimasta a 0.75, quindi la modifica è stata respinta.

Questo è esattamente il motivo per cui il gate esiste. Un sistema più debole avrebbe accettato la storia perché sembrava ragionevole. Questo ha fatto una domanda migliore: la modifica ha risolto l'errore noto?

Il secondo passaggio ha trovato la modifica più piccola che ha aiutato:

1- implementation_page_visit: 4
2+ implementation_page_visit: 6

La valutazione è passata:

1Northwind Finance: predicted=human_review expected=human_review
2Bluepeak Studio: predicted=ignore expected=ignore
3KiteOps: predicted=draft expected=draft
4Atlas Recruiting: predicted=ignore expected=ignore
5score=1.00

Questo è il momento in cui il ciclo diventa utile. Ha cambiato una regola, per una ragione, e ha dimostrato la modifica contro un fixture.

Come si presenta un buon risultato. Il diff proposto è noioso e tracciabile: una riga modificata, una ragione supportata dai risultati allegata, una valutazione migliorata.

Dove si rompe. Codex cambia tre pesi e due prompt contemporaneamente. Ora nessuno può dire quale modifica abbia aiutato. Mantieni la legge severa: un concetto per proposta.

Step 6. Migliora i file dei prompt separatamente

Lo scoring è solo metà del sistema. Anche i template dei messaggi decadono.

Una riga che funzionava il mese scorso inizia a suonare familiare. Una domanda che ottiene risposte in un segmento viene ignorata in un altro. Una frase che sembra incisiva internamente viene punita dal mercato. Tratta il miglioramento dei prompt come un binario separato in modo che Codex non mescoli scoring e copy nella stessa PR.

Crea config/plays.yaml:

1plays:
2  migration_note:
3    prompt_file: prompts/plays/migration_note.md
4    usa_quando:
5      - competitor_comparison
6    righe_vietate:
7      - "pensavo potesse essere rilevante"
8      - "una domanda veloce"
9
10  implementation_angle:
11    prompt_file: prompts/plays/implementation_angle.md
12    usa_quando:
13      - implementation_page_visit
14    righe_vietate:
15      - "dai un'occhiata alla nostra soluzione"
16      - "mi piacerebbe fare due chiacchiere"

Poi crea prompts/improve_prompt.md:

1Migliori un play di outbound.
2
3Leggi:
4- AGENTS.md
5- config/plays.yaml
6- memory/outcomes.jsonl
7- il file del prompt per il play scelto
8
9Scegli un play con almeno 10 risultati.
10
11Trova:
12- righe o strutture che appaiono in risultati positivi
13- righe o strutture che appaiono in risultati no_reply o bad_fit
14- qualsiasi frase che dovrebbe essere vietata
15
16Fai una piccola modifica al prompt di quel play.
17
18Regole:
19- Non modificare lo scoring.
20- Non creare un nuovo play.
21- Non aggiungere un nuovo canale.
22- Cita le righe di risultato.
23- Scrivi l'istruzione prima e dopo.
24
25Quindi esegui la valutazione della copia se presente.
26Se non esiste una valutazione della copia, apri la PR come review_required.

Alcuni miglioramenti possono essere valutati automaticamente. Altri hanno ancora bisogno di gusto. Se non c'è una valutazione della copia, Codex può proporre la modifica al prompt, ma dovrebbe contrassegnare la PR per la revisione invece di fingere che la modifica sia provata.

Come si presenta un buon risultato. Codex dice: "Questa frase è apparsa in sette risultati no_reply, quindi l'ho aggiunta a righe_vietate", o "le risposte positive citavano il dettaglio di implementazione nella prima frase, quindi ho ristretto il play per richiederlo."

Dove si rompe. Il miglioratore riscrive l'intera voce perché un messaggio ha ottenuto una risposta. Le modifiche ai prompt dovrebbero essere più piccole del tuo istinto.

Step 7. Invia le modifiche come pull request

Questo è il livello di controllo. Codex modifica i file, esegue la valutazione e scrive il riepilogo della PR. Un umano revisiona e unisce.

Crea prompts/pr_summary.md:

1Scrivi un riepilogo della pull request per questo miglioramento dell'outbound.
2
3Includi:
41. Cosa è cambiato.
52. Perché è cambiato, citando le righe di risultato.
63. Punteggio prima.
74. Punteggio dopo.
85. File modificati.
96. Rischio.
107. Cosa dovrebbe controllare il revisore umano.
11
12Mantienilo breve.
13Non affermare che la modifica è attiva.

Crea scripts/open_pr.sh:

1#!/usr/bin/env bash
2set -euo pipefail
3
4branch="codex/ottimizzazione-settimanale-$(date +%Y-%m-%d)"
5
6git checkout -b "$branch"
7git add config prompts evals memory
8git commit -m "Ottimizzazione outbound settimanale Codex"
9
10body="$(cat outputs/pr-summary.md)"
11
12python3 scripts/create_pr.py \
13  "$branch" \
14  "Ottimizzazione outbound settimanale Codex" \
15  "$body"

La PR dovrebbe sembrare scritta da un compagno di squadra:

1Modificato:
2- Aumentato implementation_page_visit da 4 a 6.
3
4Perché:
5- KiteOps aveva intenzione di implementazione e ha risposto con i tempi di implementazione.
6- Il punteggio precedente instradava questo account verso ignora.
7
8Prima:
9- punteggio valutazione 0.75
10
11Dopo:
12- punteggio valutazione 1.00
13
14Controllo revisore:
15- Assicurati che l'intenzione di implementazione sia sufficientemente specifica.
16- Mantieni bassi i download generici.
17- Unisci solo se corrisponde al giudizio di vendita effettivo.

Questo è il sistema di sicurezza. Codex fa il lavoro noioso. L'operatore mantiene lo standard.

Come si presenta un buon risultato. Una PR a settimana, diff piccolo, motivo chiaro, valutazione superata.

Dove si rompe. Qualcuno dà a Codex il permesso di fare merge perché la revisione sembra un attrito. Quel minuto separa un sistema che migliora da un sistema che deriva.

Step 8. Mettilo su una cadenza

Non eseguirlo dopo ogni risposta. È così che un sistema si adatta eccessivamente a un singolo account rumoroso.

Lascia che la settimana accada, lascia che i risultati si accumulino, poi ottimizza.

Crea scripts/weekly_tune.sh:

1#!/usr/bin/env bash
2set -euo pipefail
3
4cd "$(dirname "$0")/.."
5
6python3 evals/score.py || true
7scripts/run_codex_step.sh improve_scoring
8python3 evals/score.py
9scripts/run_codex_step.sh pr_summary > outputs/pr-summary.md
10scripts/open_pr.sh

Poi cron:

10 8 * * LUN cd ~/codex-self-improving-outbound && scripts/weekly_tune.sh

Se usi GitHub Actions, mantieni la stessa struttura:

1name: ottimizzazione-outbound-settimanale
2
3on:
4  schedule:
5    - cron: "0 8 * * 1"
6  workflow_dispatch:
7
8jobs:
9  ottimizza:
10    runs-on: ubuntu-latest
11    steps:
12      - uses: actions/checkout@v4
13      - uses: actions/setup-python@v5
14        with:
15          python-version: "3.11"
16      - run: pip install -r requirements.txt
17      - run: python3 evals/score.py || true
18      - run: scripts/weekly_tune.sh

Esegui le prime due ottimizzazioni a mano. Leggi ogni diff. Osserva cosa Codex cerca di cambiare quando il campione è esiguo. Una volta che le proposte sono noiose, mettilo su un programma.

Come si presenta un buon risultato. Una PR settimanale appare con le prove, il diff e il risultato della valutazione. Unisci, modifichi o la chiudi.

Dove si rompe. Il job viene eseguito, nessuno revisiona e le PR si accumulano. Un sistema auto-migliorante ha ancora un'abitudine umana: leggere il diff.

La versione clone-and-run

Il repository dovrebbe essere fornito con quattro comandi:

1git clone <repo>
2cd codex-self-improving-outbound
3python3 -m venv .venv
4source .venv/bin/activate
5pip install -r requirements.txt
6python3 evals/score.py
7python3 scripts/propose_improvement.py

Prima esecuzione prevista:

1score=0.75
2modificato config/scoring.yaml
3implementation_page_visit: 4 -> 6
4score=1.00
5apri PR per revisione umana

La demo offline prova i contratti dei file. L'esecuzione di Codex prova il ciclo di modifica. Dopodiché, sostituisci i risultati di esempio con i tuoi, rinomina i segnali, aggiungi i tuoi play e costruisci un fixture che rifletta gli account che avresti voluto che il sistema avesse instradato diversamente.

Non iniziare collegando la delivery. Inizia dimostrando il ciclo di miglioramento.

La versione completa: max

Questo repository è il livello manuale. Funziona da file, segnali pubblici e il tuo piano Codex. Insegna la struttura perché ogni regola è esposta.

yourmax.ai è lo stesso sistema con le cuciture nascoste.

Invece di un repository che colleghi da solo, max è l'agente che usi direttamente. Rileva i movimenti nel mercato, decide chi vale la pena contattare e perché ora, prepara l'outreach via email e LinkedIn per la tua approvazione e continua a migliorare dai risultati.

Il repository mostra il livello di auto-ottimizzazione che la maggior parte dei team non costruisce mai: i risultati diventano modifiche alle regole proposte, le modifiche alle regole proposte passano attraverso un gate e la fusione umana decide cosa diventa attivo. max prende la stessa logica operativa e la esegue come un sistema gestito.

Se vuoi il repository completo, fammelo sapere e te lo invierò.