Cómo construir un sistema de outbound auto-mejorable en Codex

A principios de este año, Andrej Karpathy (@karpathy) apuntó un agente a su propio código de entrenamiento y lo dejó funcionar durante dos días. Ejecutó 700 experimentos, mantuvo los 20 que superaron el benchmark e hizo que el modelo entrenara un 11% más rápido. Luego dijo algo bastante interesante: cualquier métrica que puedas evaluar a bajo costo se le puede asignar a un enjambre de agentes.

La tasa de respuesta es una métrica que puedes evaluar a bajo costo. He pasado un tiempo desde entonces averiguando cómo se ve ese bucle apuntado a la prospección saliente.

Mi construcción:

Codex lee los resultados de la semana pasada, edita los archivos de puntuación y jugadas que ejecuta el sistema de prospección saliente, ejecuta una prueba y abre un pull request. Propone un cambio al manual con la evidencia y la puntuación adjunta, luego espera a que un humano lo apruebe. El envío y la fusión quedan fuera del bucle.

He construido el primer bucle varias veces: detectar el mercado, puntuar la cuenta, redactar a partir de la señal, verificar el mensaje, registrar el resultado, aprender de la respuesta. Este artículo trata sobre el segundo bucle, el que edita el primero.

Esa es la construcción: GTM como código versionado que mejora a partir del mercado.

El repositorio

Empieza con la carpeta. La forma importa porque Codex solo puede mejorar lo que puede leer y editar.

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

El repositorio es intencionalmente simple. config/scoring.yaml contiene las reglas que deciden qué señales importan. prompts/ contiene las jugadas que redactan los mensajes. memory/outcomes.jsonl contiene lo que hizo el mercado. evals/score.py es la puerta que determina si un cambio propuesto ayudó. AGENTS.md es la ley que Codex lee antes de tocar cualquier cosa.

Ejecuta la primera versión sin conexión. Sin CRM, sin enriquecimiento, sin sistema de entrega. El bucle de mejora debe probarse en archivos locales antes de acercarse a una máquina de prospección saliente real.

Paso 1. Escribe la ley primero

Antes del archivo de puntuación, antes de los archivos de indicaciones, escribe AGENTS.md. Este es el archivo que mantiene al agente útil y contenido.

1# Reglas de prospección saliente auto-mejorable
2
3Mejoras un sistema de prospección saliente a partir de los resultados.
4
5Reglas estrictas:
6- Nunca enviar mensajes.
7- Nunca raspar o enriquecer personas reales.
8- Nunca auto-fusionar.
9- Editar solo archivos en este repositorio.
10- Cambiar un concepto a la vez.
11- Citar resultados de memory/outcomes.jsonl para cada cambio propuesto.
12- Mejorar evals/score.py antes de que un cambio pueda convertirse en un PR.
13- Si la evaluación no mejora, revierte tu edición y detente.
14
15Ediciones permitidas:
16- config/scoring.yaml
17- config/plays.yaml
18- prompts/*.md
19
20Salida requerida:
21- archivos modificados
22- razón para cada cambio
23- puntuación antes
24- puntuación después
25- resumen del pull request

La ley tiene un trabajo: reducir el alcance. Sin ella, Codex intentará ayudar expandiendo el ámbito. Agregará más datos, tocará más archivos, llamará más herramientas o automatizará un paso que debería permanecer bajo control humano. Aquí el trabajo es más pequeño: leer los resultados, proponer un cambio de archivo, demostrar que ayudó y luego esperar.

Cómo se ve cuando funciona bien. Puedes leer la ley antes de aprobar un PR y saber exactamente qué se le permitió hacer a Codex.

Dónde falla. La ley se convierte en un documento de cumplimiento. Si AGENTS.md necesita una tabla de contenido, ya es demasiado grande. Mantenlo operativo.

Paso 2. Mueve el juicio a la configuración

La mayor parte del juicio en la prospección saliente vive en la cabeza de alguien. Luego el equipo compra software y espera que el software mejore una decisión que no puede ver.

Mueve el juicio a un archivo.

1signals:
2  competitor_comparison:
3    weight: 8
4    reason: "el comprador está comparando alternativas"
5  implementation_page_visit:
6    weight: 6
7    reason: "el comprador está verificando si esto se puede instalar"
8  job_repost:
9    weight: 5
10    reason: "el puesto sigue abierto y es urgente"
11  funding_event:
12    weight: 5
13    reason: "el presupuesto o mandato puede haber cambiado"
14  generic_download:
15    weight: 1
16    reason: "interés en contenido, intención de compra débil"
17
18thresholds:
19  draft: 6
20  human_review: 10
21
22negative_signals:
23  student_research: -8
24  vendor_pitch: -6
25  competitor: -10

Este archivo comienza como una hipótesis visible. Si una descarga genérica debería contar como cero, el equipo puede señalar la línea exacta y cambiarla. Si una visita a la página de implementación es una señal más fuerte de lo que pensabas, Codex puede proponer el diff y mostrar las filas de resultados que lo justifican.

No entierres esta lógica en una función de Python. Si la regla es visible, el equipo puede revisarla, discutirla y mejorarla sin convertir un juicio de ventas en una refactorización de ingeniería.

Cómo se ve cuando funciona bien. El archivo es lo suficientemente pequeño para discutirlo. Cinco señales son una buena primera versión.

Dónde falla. El archivo de puntuación se convierte en un cajón de sastre. Veinte señales, seis umbrales y reglas de excepción para cada caso límite harán que el mejorador se sobreajuste. Empieza con poco y deja que los resultados te digan dónde va el siguiente control.

Paso 3. Escribe los resultados como memoria

El archivo más importante es memory/outcomes.jsonl.

Una línea por contacto, escrita cuando se conoce el resultado:

1{"date":"2026-07-01","account":"Northwind Finance","signal":"competitor_comparison","play":"migration_note","score":8,"outcome":"reply","reason":"solicitó notas de migración"}
2{"date":"2026-07-01","account":"Bluepeak Studio","signal":"generic_download","play":"resource_followup","score":1,"outcome":"no_reply","reason":"intención solo de contenido"}
3{"date":"2026-07-02","account":"KiteOps","signal":"implementation_page_visit","play":"implementation_angle","score":6,"outcome":"reply","reason":"preguntó sobre el cronograma de implementación"}
4{"date":"2026-07-02","account":"Atlas Recruiting","signal":"job_repost","play":"hiring_angle","score":5,"outcome":"bad_fit","reason":"solicitud de investigación estudiantil"}

El campo de razón es el punto central. "no_reply" te dice casi nada. "intención solo de contenido" le dice a la siguiente ejecución que esta señal podría no merecer un borrador. "bad_fit" es útil solo cuando la razón explica por qué. "preguntó sobre el cronograma de implementación" es el tipo de detalle que puede cambiar un peso.

Construye el validador antes de construir el mejorador:

1Construye scripts/append_outcome.py.
2
3Acepta:
4- date
5- account
6- signal
7- play
8- score
9- outcome: reply | meeting | no_reply | bad_fit | bounced
10- reason
11
12Rechaza:
13- campos faltantes
14- resultados desconocidos
15- razón vacía
16- fechas futuras
17
18Agrega filas válidas a memory/outcomes.jsonl.
19Imprime la fila agregada.

Aquí es donde comienza la acumulación. Un panel de control puede decirte que una campaña está baja. Un registro de resultados limpio puede decirle a Codex qué señal, jugada o frase debería cambiar antes de la siguiente ejecución.

Cómo se ve cuando funciona bien. Después de una semana, un extraño puede leer el archivo y decir qué señales generaron respuestas, qué jugadas crearon conversaciones de mala adaptación y qué favorito interno ignoró el mercado.

Dónde falla. El equipo completa los resultados el viernes de memoria. Los aciertos sobreviven, las razones de mala adaptación se difuminan y el sistema aprende de ficción. Escribe la fila cuando el resultado se materialice.

Paso 4. Construye la puerta de evaluación

Antes de que Codex edite algo, necesita una prueba que no pueda explicar.

Crea evals/fixtures.yaml:

1cases:
2  - account: Northwind Finance
3    signals: [competitor_comparison, implementation_page_visit]
4    expected: human_review
5    note: "dos señales fuertes en una cuenta"
6
7  - account: Bluepeak Studio
8    signals: [generic_download]
9    expected: ignore
10    note: "intención solo de contenido"
11
12  - account: KiteOps
13    signals: [implementation_page_visit]
14    expected: draft
15    note: "la intención de implementación debería superar el umbral de borrador"
16
17  - account: Atlas Recruiting
18    signals: [job_repost, student_research]
19    expected: ignore
20    note: "el marcador de mala adaptación cancela la señal"

Luego crea evals/score.py:

1Construye evals/score.py.
2
3Lee config/scoring.yaml y evals/fixtures.yaml.
4
5Para cada caso:
61. Suma los pesos de cada señal.
72. Agrega las penalizaciones de señales negativas.
83. Clasifica la cuenta:
9   - score >= thresholds.human_review => human_review
10   - score >= thresholds.draft => draft
11   - de lo contrario => ignore
124. Compara la clasificación con la esperada.
13
14Imprime cada predicción.
15Imprime la precisión final como score=0.00 a score=1.00.
16Sale con 0 solo cuando la precisión es 1.00.

La primera puerta debe ser lo suficientemente pequeña para entenderla y lo suficientemente precisa para detectar un error real. En mi primera ejecución, la línea base falló 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

Eso fue bueno. El sistema tenía la intención de implementación por debajo del umbral de borrador, por lo que ignoró una cuenta que el fixture decía que merecía un mensaje. Mejor detectar eso en una prueba que después de un mes de cuentas perdidas.

Cómo se ve cuando funciona bien. Un comando da un número, y cada caso fallido es fácil de inspeccionar.

Dónde falla. El fixture solo incluye aciertos obvios. Entonces cada cambio imprudente pasa. Pon casos difíciles en la puerta: intención débil, mala adaptación, sin respuesta, señales obsoletas y las cuentas que desearías que el sistema hubiera saltado.

Paso 5. Deja que Codex proponga un cambio de puntuación

Ahora Codex puede editar.

Crea prompts/improve_scoring.md:

1Mejoras el sistema de puntuación de prospección saliente.
2
3Lee:
4- AGENTS.md
5- config/scoring.yaml
6- memory/outcomes.jsonl
7- evals/fixtures.yaml
8
9Tu trabajo:
101. Encuentra una regla de puntuación que debería cambiar.
112. La razón debe citar memory/outcomes.jsonl.
123. Cambia solo config/scoring.yaml.
134. Ejecuta python3 evals/score.py.
145. Si la puntuación mejora, mantén el cambio.
156. Si la puntuación se mantiene igual o baja, revierte tu cambio y detente.
16
17Salida:
18- la línea exacta cambiada
19- las filas de resultados que lo causaron
20- puntuación antes
21- puntuación después
22- si el cambio debería convertirse en un PR
23
24No edites indicaciones.
25No agregues nuevas señales.
26No toques la entrega.

Ejecútalo a través del envoltorio del repositorio:

1scripts/run_codex_step.sh improve_scoring

La primera versión de mi mejorador cometió un error útil. Persiguió la señal de respuesta que se veía más limpia. "competitor_comparison" tenía la tasa de respuesta más fuerte en el pequeño registro de resultados, por lo que el mejorador quería aumentar ese peso. La evaluación se mantuvo en 0.75, por lo que el cambio fue rechazado.

Eso es exactamente por qué existe la puerta. Un sistema más débil habría aceptado la historia porque sonaba razonable. Este hizo una mejor pregunta: ¿el cambio solucionó el error conocido?

La segunda pasada encontró la edición más pequeña que ayudó:

1- implementation_page_visit: 4
2+ implementation_page_visit: 6

La evaluación pasó:

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

Ese es el momento en que el bucle se vuelve útil. Cambió una regla, por una razón, y demostró el cambio contra un fixture.

Cómo se ve cuando funciona bien. El diff propuesto es aburrido y rastreable: una línea cambiada, una razón respaldada por resultados adjunta, una evaluación mejorada.

Dónde falla. Codex cambia tres pesos y dos indicaciones a la vez. Ahora nadie puede decir qué cambio ayudó. Mantén la ley estricta: un concepto por propuesta.

Paso 6. Mejora los archivos de indicaciones por separado

La puntuación es solo la mitad del sistema. Las plantillas de mensajes también se degradan.

Una línea que funcionó el mes pasado empieza a sonar familiar. Una pregunta que genera respuestas en un segmento es ignorada en otro. Una frase que se siente aguda internamente es castigada por el mercado. Trata la mejora de indicaciones como un carril separado para que Codex no mezcle puntuación y texto en el mismo PR.

Crea config/plays.yaml:

1plays:
2  migration_note:
3    prompt_file: prompts/plays/migration_note.md
4    use_when:
5      - competitor_comparison
6    banned_lines:
7      - "pensé que esto podría ser relevante"
8      - "pregunta rápida"
9
10  implementation_angle:
11    prompt_file: prompts/plays/implementation_angle.md
12    use_when:
13      - implementation_page_visit
14    banned_lines:
15      - "revisando nuestra solución"
16      - "me encantaría conversar"

Luego crea prompts/improve_prompt.md:

1Mejoras una jugada de prospección saliente.
2
3Lee:
4- AGENTS.md
5- config/plays.yaml
6- memory/outcomes.jsonl
7- el archivo de indicaciones para la jugada elegida
8
9Elige una jugada con al menos 10 resultados.
10
11Encuentra:
12- líneas o estructuras que aparecen en resultados positivos
13- líneas o estructuras que aparecen en resultados de no_reply o bad_fit
14- cualquier frase que debería prohibirse
15
16Haz una pequeña edición en la indicación de esa jugada.
17
18Reglas:
19- No cambies la puntuación.
20- No crees una nueva jugada.
21- No agregues un nuevo canal.
22- Cita filas de resultados.
23- Escribe la instrucción antes y después.
24
25Luego ejecuta la evaluación de copia si existe.
26Si no existe una evaluación de copia, abre el PR como review_required.

Algunas mejoras se pueden puntuar automáticamente. Otras aún necesitan criterio. Si no hay una evaluación de copia, Codex puede proponer la edición de la indicación, pero debe marcar el PR para revisión en lugar de fingir que la edición está probada.

Cómo se ve cuando funciona bien. Codex dice: "Esta frase apareció en siete resultados de no_reply, así que la agregué a banned_lines", o "las respuestas positivas citaron el detalle de implementación en la primera oración, así que ajusté la jugada para requerir eso".

Dónde falla. El mejorador reescribe toda la voz porque un mensaje obtuvo una respuesta. Las ediciones de indicaciones deben ser más pequeñas que tu instinto.

Paso 7. Entrega los cambios como pull requests

Esta es la capa de control. Codex edita archivos, ejecuta la evaluación y escribe el resumen del PR. Un humano revisa y fusiona.

Crea prompts/pr_summary.md:

1Escribe un resumen de pull request para esta mejora de prospección saliente.
2
3Incluye:
41. Qué cambió.
52. Por qué cambió, citando filas de resultados.
63. Puntuación antes.
74. Puntuación después.
85. Archivos cambiados.
96. Riesgo.
107. Qué debe verificar el revisor humano.
11
12Mantenlo corto.
13No afirmes que el cambio está en vivo.

Crea scripts/open_pr.sh:

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

El PR debería leerse como si lo hubiera escrito un compañero de equipo:

1Cambiado:
2- Se elevó implementation_page_visit de 4 a 6.
3
4Por qué:
5- KiteOps tenía intención de página de implementación y respondió con el cronograma de implementación.
6- La puntuación anterior clasificaba esta cuenta como ignorada.
7
8Antes:
9- puntuación de evaluación 0.75
10
11Después:
12- puntuación de evaluación 1.00
13
14Verificación del revisor:
15- Asegúrate de que la intención de implementación sea lo suficientemente específica.
16- Mantén las descargas genéricas bajas.
17- Fusiona solo si esto coincide con el criterio de ventas real.

Ese es el sistema de seguridad. Codex hace el trabajo tedioso. El operador mantiene el estándar.

Cómo se ve cuando funciona bien. Un PR a la semana, diff pequeño, razón clara, evaluación que pasa.

Dónde falla. Alguien le da permiso a Codex para fusionar porque la revisión se siente como fricción. Ese minuto separa un sistema que mejora de un sistema que se desvía.

Paso 8. Ponlo en una cadencia

No ejecutes esto después de cada respuesta. Así es como un sistema se sobreajusta a una cuenta ruidosa.

Deja que ocurra la semana, deja que los resultados se acumulen, luego ajusta.

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

Luego cron:

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

Si usas GitHub Actions, mantén la misma forma:

1name: weekly-outbound-tune
2
3on:
4  schedule:
5    - cron: "0 8 * * 1"
6  workflow_dispatch:
7
8jobs:
9  tune:
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

Ejecuta los primeros dos ajustes manualmente. Lee cada diff. Observa qué intenta cambiar Codex cuando la muestra es pequeña. Una vez que las propuestas sean aburridas, ponlo en un horario.

Cómo se ve cuando funciona bien. Un PR semanal aparece con la evidencia, el diff y el resultado de la evaluación. Lo fusionas, editas o cierras.

Dónde falla. El trabajo se ejecuta, nadie revisa y los PRs se acumulan. Un sistema auto-mejorable todavía tiene un hábito humano: leer el diff.

La versión de clonar y ejecutar

El repositorio debería incluir cuatro comandos:

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

Primera ejecución esperada:

1score=0.75
2changed config/scoring.yaml
3implementation_page_visit: 4 -> 6
4score=1.00
5open PR for human review

La demostración sin conexión prueba los contratos de archivo. La ejecución de Codex prueba el bucle de edición. Después de eso, reemplaza los resultados de muestra con los tuyos, renombra las señales, agrega tus jugadas y construye un fixture que refleje las cuentas que desearías que el sistema hubiera clasificado de manera diferente.

No empieces conectando la entrega. Empieza probando el bucle de mejora.

La versión completa: max

Este repositorio es la capa manual. Funciona desde archivos, señales públicas y tu plan de Codex. Enseña la forma porque cada regla está expuesta.

yourmax.ai es el mismo sistema con las costuras ocultas.

En lugar de un repositorio que conectas tú mismo, max es el agente que usas directamente. Detecta movimiento en el mercado, decide quién merece ser contactado y por qué ahora, redacta el alcance a través de correo electrónico y LinkedIn para tu aprobación, y sigue mejorando a partir de los resultados.

El repositorio muestra la capa de autoajuste que la mayoría de los equipos nunca construyen: los resultados se convierten en cambios de reglas propuestos, los cambios de reglas propuestos pasan por una puerta, y la fusión humana decide qué se vuelve realidad. max toma esa misma lógica operativa y la ejecuta como un sistema gestionado.

Si quieres el repositorio completo, puedes avisarme y te lo enviaré.