Cómo construir un sistema de outbound automejorable en Codex

A principios de este año, Andrej Karpathy (@karpathy) apuntó un agente a su propio código de entrenamiento y lo dejó ejecutar durante dos días. Corrió 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 de forma barata se la puedes pasar a un enjambre de agentes.

La tasa de respuesta es una métrica que puedes evaluar de forma barata. He dedicado tiempo desde entonces a averiguar cómo se ve ese bucle aplicado 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, corre una prueba y abre un pull request. Propone un cambio en el manual de jugadas con la evidencia y la puntuación adjunta, y 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, escribir a partir de la señal, revisar el mensaje, registrar el resultado, aprender de la respuesta. Este artículo trata sobre el segundo bucle, el que edita al primero.

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

El repositorio

Empieza con la carpeta. La estructura 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 intencionadamente simple. config/scoring.yaml contiene las reglas que deciden qué señales importan. prompts/ contiene las jugadas que escriben los mensajes. memory/outcomes.jsonl guarda 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 nada.

Ejecuta la primera versión sin conexión. Sin CRM, sin enriquecimiento, sin sistema de entrega. El bucle de mejora debe demostrarse 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 prompts, 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 envíes mensajes.
7- Nunca raspes ni enriquezcas a personas reales.
8- Nunca auto-fusiones.
9- Edita solo archivos en este repositorio.
10- Cambia un concepto a la vez.
11- Cita resultados de `memory/outcomes.jsonl` para cada cambio propuesto.
12- Mejora `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- motivo de cada cambio
23- puntuación anterior
24- puntuación posterior
25- resumen del pull request

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

Cómo se ve algo bueno. Puedes leer la ley antes de aprobar un PR y saber exactamente lo que Codex tenía permitido hacer.

Dónde se rompe. La ley se convierte en un documento de cumplimiento. Si AGENTS.md necesita un índice, ya es demasiado grande. Mantenla operativa.

Paso 2. Traslada el criterio a la configuración

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

Traslada el criterio a un archivo.

1señales:
2  comparación_con_competencia:
3    peso: 8
4    razón: "el comprador está comparando alternativas"
5  visita_página_de_implementación:
6    peso: 6
7    razón: "el comprador está verificando si esto se puede instalar"
8  republicación_de_trabajo:
9    peso: 5
10    razón: "el puesto sigue abierto y es urgente"
11  evento_de_financiación:
12    peso: 5
13    razón: "el presupuesto o mandato puede haber cambiado"
14  descarga_genérica:
15    peso: 1
16    razón: "interés en el contenido, intención de compra débil"
17
18umbrales:
19  borrador: 6
20  revisión_humana: 10
21
22señales_negativas:
23  investigación_estudiantil: -8
24  propuesta_de_vendedor: -6
25  competidor: -10

Este archivo comienza como una hipótesis visible. Si una descarga genérica debe 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 criterio de ventas en una refactorización de ingeniería.

Cómo se ve algo bueno. El archivo es lo suficientemente pequeño como para discutirlo. Cinco señales es una buena primera versión.

Dónde se rompe. 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 sobreajuste. Empieza con poco y deja que los resultados te digan dónde debe ir 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 reason es el punto clave. no_reply no te dice casi nada. intención solo de contenido le dice a la siguiente ejecución que esta señal quizás no merezca 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 el efecto compuesto. Un dashboard puede decirte que una campaña está baja. Un registro de resultados limpio puede decirle a Codex qué señal, jugada o frase debe cambiar antes de la siguiente ejecución.

Cómo se ve algo bueno. 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 calidad y qué favorito interno ignoró el mercado.

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

Paso 4. Construye la puerta de evaluación

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

Crea evals/fixtures.yaml:

1casos:
2  - cuenta: Northwind Finance
3    señales: [competitor_comparison, implementation_page_visit]
4    esperado: human_review
5    nota: "dos señales fuertes en una cuenta"
6
7  - cuenta: Bluepeak Studio
8    señales: [generic_download]
9    esperado: ignore
10    nota: "intención solo de contenido"
11
12  - cuenta: KiteOps
13    señales: [implementation_page_visit]
14    esperado: draft
15    nota: "la intención de implementación debería superar el umbral de borrador"
16
17  - cuenta: Atlas Recruiting
18    señales: [job_repost, student_research]
19    esperado: ignore
20    nota: "el marcador de mala calidad 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. Añade las penalizaciones de señales negativas.
83. Enruta la cuenta:
9   - score >= thresholds.human_review => human_review
10   - score >= thresholds.draft => draft
11   - en otro caso => ignore
124. Compara la ruta con lo esperado.
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 afilada 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 detectarlo en una prueba que después de un mes de cuentas perdidas.

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

Dónde se rompe. El fixture solo incluye aciertos obvios. Entonces cada cambio imprudente pasa. Pon casos difíciles en la puerta: intención débil, mala calidad, 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. El motivo 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 anterior
21- puntuación posterior
22- si el cambio debería convertirse en un PR
23
24No edites prompts.
25No añadas 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 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?

El segundo pase 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 algo bueno. El diff propuesto es aburrido y trazable: una línea cambiada, una razón respaldada por resultados adjunta, una evaluación mejorada.

Dónde se rompe. Codex cambia tres pesos y dos prompts 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 prompt 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 comienza a sonar familiar. Una pregunta que genera respuestas en un segmento es ignorada en otro. Una frase que se siente afilada internamente es castigada por el mercado. Trata la mejora de prompts como un carril separado para que Codex no mezcle puntuación y redacción en el mismo PR.

Crea config/plays.yaml:

1jugadas:
2  nota_de_migración:
3    archivo_prompt: prompts/plays/nota_de_migración.md
4    usar_cuando:
5      - comparación_con_competencia
6    líneas_prohibidas:
7      - "pensé que esto podría ser relevante"
8      - "pregunta rápida"
9
10  ángulo_de_implementación:
11    archivo_prompt: prompts/plays/ángulo_de_implementación.md
12    usar_cuando:
13      - visita_página_de_implementación
14    líneas_prohibidas:
15      - "echando un vistazo a nuestra solución"
16      - "me encantaría charlar"

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 prompt de 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 no_reply o bad_fit
14- cualquier frase que debería estar prohibida
15
16Haz una pequeña edición en el prompt de esa jugada.
17
18Reglas:
19- No cambies la puntuación.
20- No crees una nueva jugada.
21- No añadas un nuevo canal.
22- Cita filas de resultados.
23- Escribe la instrucción anterior y posterior.
24
25Luego ejecuta la evaluación de copia si existe.
26Si no existe 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 del prompt, pero debe marcar el PR para revisión en lugar de pretender que la edición está probada.

Cómo se ve algo bueno. Codex dice: "Esta frase apareció en siete resultados de no respuesta, así que la añadí a líneas prohibidas", o "las respuestas positivas citaron el detalle de implementación en la primera oración, así que ajusté la jugada para exigir eso".

Dónde se rompe. El mejorador reescribe toda la voz porque un mensaje obtuvo una respuesta. Las ediciones de prompts deben ser más pequeñas de lo que tu instinto te dice.

Paso 7. Envía 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 anterior.
74. Puntuación posterior.
85. Archivos modificados.
96. Riesgo.
107. Qué debe verificar el revisor humano.
11
12Mantenlo breve.
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 debe leerse como si lo hubiera escrito un compañero de equipo:

1Cambiado:
2- Se elevó visita_página_de_implementación 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 enrutaba esta cuenta a ignorar.
7
8Antes:
9- eval score 0.75
10
11Después:
12- eval score 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 algo bueno. Un PR a la semana, diff pequeño, razón clara, evaluación aprobada.

Dónde se rompe. 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 pase 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 a mano. Lee cada diff. Observa lo que Codex intenta cambiar cuando la muestra es pequeña. Una vez que las propuestas se vuelvan aburridas, ponlo en un horario.

Cómo se ve algo bueno. Un PR semanal aparece con la evidencia, el diff y el resultado de la evaluación. Tú fusionas, editas o lo cierras.

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

La versión de clonar y ejecutar

El repositorio debe venir con 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 demo sin conexión demuestra los contratos de archivos. La ejecución de Codex demuestra el bucle de edición. Después de eso, reemplaza los resultados de muestra con los tuyos, renombra las señales, añade tus jugadas y construye un fixture que refleje las cuentas que desearías que el sistema hubiera enrutado de manera diferente.

No empieces conectando la entrega. Empieza demostrando 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 ensamblas tú mismo, max es el agente que usas directamente. Detecta movimientos en el mercado, decide a quién contactar y por qué ahora, redacta la prospección 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é.