Como construir um sistema de outbound com autoaprendizagem no Codex

Tradução para Português (Português)

No início deste ano, Andrej Karpathy (@karpathy) apontou um agente para seu próprio código de treinamento e deixou-o rodar por dois dias. Ele executou 700 experimentos, manteve os 20 que superaram o benchmark e fez o modelo treinar 11% mais rápido. Depois, ele disse algo bastante interessante: qualquer métrica que você possa avaliar de forma barata pode ser entregue a um enxame de agentes.

A taxa de resposta é uma métrica que você pode avaliar de forma barata. Passei algum tempo desde então descobrindo como esse loop se parece quando apontado para outbound.

Minha construção:

O Codex lê os resultados da semana passada, edita os arquivos de pontuação e de jogadas que o sistema de outbound utiliza, executa um teste e abre um pull request. Ele propõe uma alteração no manual com as evidências e a pontuação anexadas, e então aguarda a aprovação humana. O envio e a mesclagem ficam fora do loop.

Eu construí o primeiro loop algumas vezes: sentir o mercado, pontuar a conta, escrever a partir do sinal, verificar a mensagem, registrar o resultado, aprender com a resposta. Este artigo é sobre o segundo loop, aquele que edita o primeiro.

Essa é a construção: GTM como código versionado que melhora a partir do mercado.

O repositório

Comece pela pasta. A estrutura importa porque o Codex só pode melhorar o que consegue ler e 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

O repositório é intencionalmente simples. O config/scoring.yaml contém as regras que determinam quais sinais importam. O prompts/ contém as jogadas que escrevem as mensagens. O memory/outcomes.jsonl armazena o que o mercado fez. O evals/score.py é o portal que decide se uma alteração proposta ajudou. O AGENTS.md é a lei que o Codex lê antes de tocar em qualquer coisa.

Execute a primeira versão offline. Sem CRM, sem enriquecimento, sem sistema de entrega. O loop de melhoria deve provar seu valor em arquivos locais antes de chegar perto de uma máquina de outbound real.

Passo 1. Escreva a lei primeiro

Antes do arquivo de pontuação, antes dos arquivos de prompt, escreva o AGENTS.md. Este é o arquivo que mantém o agente útil e contido.

1# Regras de Outbound Auto-Melhorável
2
3Você melhora um sistema de outbound a partir de resultados.
4
5Regras rígidas:
6- Nunca envie mensagens.
7- Nunca raspe ou enriqueça pessoas reais.
8- Nunca faça auto-merge.
9- Edite apenas arquivos neste repositório.
10- Altere um conceito por vez.
11- Cite resultados do memory/outcomes.jsonl para cada alteração proposta.
12- Melhore o evals/score.py antes que uma alteração possa se tornar um PR.
13- Se a avaliação não melhorar, reverta sua edição e pare.
14
15Edições permitidas:
16- config/scoring.yaml
17- config/plays.yaml
18- prompts/*.md
19
20Saída necessária:
21- arquivos alterados
22- motivo para cada alteração
23- pontuação anterior
24- pontuação posterior
25- resumo do pull request

A lei tem um trabalho: restringir o trabalho. Sem ela, o Codex tentará ajudar expandindo o escopo. Ele adicionará mais dados, tocará em mais arquivos, chamará mais ferramentas ou automatizará uma etapa que deveria permanecer sob controle humano. Aqui o trabalho é menor: ler resultados, propor uma alteração de arquivo, provar que ajudou e depois esperar.

Como é quando funciona bem. Você pode ler a lei antes de aprovar um PR e saber exatamente o que o Codex tinha permissão para fazer.

Onde quebra. A lei se torna um documento de conformidade. Se o AGENTS.md precisar de um índice, já está grande demais. Mantenha-o operacional.

Passo 2. Transfira o julgamento para a configuração

A maior parte do julgamento de outbound vive na cabeça de alguém. Então a equipe compra um software e espera que ele melhore uma decisão que não consegue ver.

Transfira o julgamento para um arquivo.

1sinais:
2  comparacao_concorrente:
3    peso: 8
4    motivo: "comprador está comparando alternativas"
5  visita_pagina_implementacao:
6    peso: 6
7    motivo: "comprador está verificando se isso pode ser instalado"
8  republicacao_vaga:
9    peso: 5
10    motivo: "vaga ainda está aberta e urgente"
11  evento_financiamento:
12    peso: 5
13    motivo: "orçamento ou mandato pode ter mudado"
14  download_generico:
15    peso: 1
16    motivo: "interesse em conteúdo, intenção de compra fraca"
17
18limiares:
19  rascunho: 6
20  revisao_humana: 10
21
22sinais_negativos:
23  pesquisa_estudante: -8
24  apresentacao_fornecedor: -6
25  concorrente: -10

Este arquivo começa como uma hipótese visível. Se um download genérico deve contar como zero, a equipe pode apontar para a linha exata e alterá-la. Se uma visita à página de implementação for um sinal mais forte do que você pensava, o Codex pode propor o diff e mostrar as linhas de resultado que o justificam.

Não enterre essa lógica em uma função Python. Se a regra estiver visível, a equipe pode revisá-la, discutir e melhorá-la sem transformar um julgamento de vendas em uma refatoração de engenharia.

Como é quando funciona bem. O arquivo é pequeno o suficiente para ser debatido. Cinco sinais é uma boa primeira versão.

Onde quebra. O arquivo de pontuação se torna uma gaveta de bagunças. Vinte sinais, seis limiares e regras de exceção para cada caso extremo farão o melhorador se ajustar excessivamente. Comece estreito e deixe os resultados lhe dizerem onde o próximo botão pertence.

Passo 3. Escreva os resultados como memória

O arquivo mais importante é o memory/outcomes.jsonl.

Uma linha por contato, escrita quando o resultado é conhecido:

1{"date":"2026-07-01","account":"Northwind Finance","signal":"comparacao_concorrente","play":"nota_migracao","score":8,"outcome":"resposta","reason":"pediu notas de migração"}
2{"date":"2026-07-01","account":"Bluepeak Studio","signal":"download_generico","play":"acompanhamento_recurso","score":1,"outcome":"sem_resposta","reason":"intenção apenas de conteúdo"}
3{"date":"2026-07-02","account":"KiteOps","signal":"visita_pagina_implementacao","play":"angulo_implementacao","score":6,"outcome":"resposta","reason":"perguntou sobre cronograma de implementação"}
4{"date":"2026-07-02","account":"Atlas Recruiting","signal":"republicacao_vaga","play":"angulo_contratacao","score":5,"outcome":"ma_adequacao","reason":"solicitação de pesquisa de estudante"}

O campo "reason" é o ponto central. "sem_resposta" não diz quase nada. "intenção apenas de conteúdo" informa à próxima execução que este sinal pode não merecer um rascunho. "ma_adequacao" só é útil quando o motivo explica o porquê. "perguntou sobre cronograma de implementação" é o tipo de detalhe que pode alterar um peso.

Construa o validador antes de construir o melhorador:

1Construa scripts/append_outcome.py.
2
3Ele aceita:
4- data
5- conta
6- sinal
7- jogada
8- pontuação
9- resultado: resposta | reuniao | sem_resposta | ma_adequacao | devolvido
10- motivo
11
12Ele rejeita:
13- campos ausentes
14- resultados desconhecidos
15- motivo vazio
16- datas no futuro
17
18Anexa linhas válidas a memory/outcomes.jsonl.
19Imprime a linha anexada.

É aqui que a capitalização começa. Um dashboard pode dizer que uma campanha caiu. Um registro de resultados limpo pode dizer ao Codex qual sinal, jogada ou frase deve mudar antes da próxima execução.

Como é quando funciona bem. Depois de uma semana, um estranho pode ler o arquivo e dizer quais sinais geraram respostas, quais jogadas geraram conversas de má adequação e qual favorito interno o mercado ignorou.

Onde quebra. A equipe preenche os resultados na sexta-feira de memória. Os acertos sobrevivem, os motivos de má adequação se confundem e o sistema aprende com ficção. Escreva a linha quando o resultado chegar.

Passo 4. Construa o portal de avaliação

Antes de o Codex editar qualquer coisa, ele precisa de um teste que não possa explicar.

Crie evals/fixtures.yaml:

1casos:
2  - conta: Northwind Finance
3    sinais: [comparacao_concorrente, visita_pagina_implementacao]
4    esperado: revisao_humana
5    nota: "dois sinais fortes em uma conta"
6
7  - conta: Bluepeak Studio
8    sinais: [download_generico]
9    esperado: ignorar
10    nota: "intenção apenas de conteúdo"
11
12  - conta: KiteOps
13    sinais: [visita_pagina_implementacao]
14    esperado: rascunho
15    nota: "intenção de implementação deve ultrapassar o limiar de rascunho"
16
17  - conta: Atlas Recruiting
18    sinais: [republicacao_vaga, pesquisa_estudante]
19    esperado: ignorar
20    nota: "marcador de má adequação cancela o sinal"

Depois crie evals/score.py:

1Construa evals/score.py.
2
3Leia config/scoring.yaml e evals/fixtures.yaml.
4
5Para cada caso:
61. Some os pesos de cada sinal.
72. Adicione penalidades de sinais negativos.
83. Direcione a conta:
9   - pontuação >= limiares.revisao_humana => revisao_humana
10   - pontuação >= limiares.rascunho => rascunho
11   - caso contrário => ignorar
124. Compare o direcionamento com o esperado.
13
14Imprima cada previsão.
15Imprima a precisão final como score=0.00 a score=1.00.
16Saia com 0 apenas quando a precisão for 1.00.

O primeiro portal deve ser pequeno o suficiente para entender e afiado o suficiente para capturar um erro real. Na minha primeira execução, a linha de base falhou em um caso:

1Northwind Finance: previsto=revisao_humana esperado=revisao_humana
2Bluepeak Studio: previsto=ignorar esperado=ignorar
3KiteOps: previsto=ignorar esperado=rascunho
4Atlas Recruiting: previsto=ignorar esperado=ignorar
5score=0.75

Isso foi bom. O sistema tinha a intenção de implementação abaixo do limiar de rascunho, então ignorou uma conta que o fixture dizia merecer uma mensagem. Melhor pegar isso em um teste do que depois de um mês de contas perdidas.

Como é quando funciona bem. Um comando dá um número, e cada caso com falha é fácil de inspecionar.

Onde quebra. O fixture inclui apenas acertos óbvios. Então toda alteração imprudente passa. Coloque casos feios no portal: intenção fraca, má adequação, sem resposta, sinais desatualizados e as contas que você gostaria que o sistema tivesse pulado.

Passo 5. Deixe o Codex propor uma alteração de pontuação

Agora o Codex pode editar.

Crie prompts/improve_scoring.md:

1Você melhora o sistema de pontuação de outbound.
2
3Leia:
4- AGENTS.md
5- config/scoring.yaml
6- memory/outcomes.jsonl
7- evals/fixtures.yaml
8
9Seu trabalho:
101. Encontre uma regra de pontuação que deve mudar.
112. O motivo deve citar memory/outcomes.jsonl.
123. Altere apenas config/scoring.yaml.
134. Execute python3 evals/score.py.
145. Se a pontuação melhorar, mantenha a alteração.
156. Se a pontuação ficar estável ou cair, reverta sua alteração e pare.
16
17Saída:
18- a linha exata alterada
19- as linhas de resultado que a causaram
20- pontuação anterior
21- pontuação posterior
22- se a alteração deve se tornar um PR
23
24Não edite prompts.
25Não adicione novos sinais.
26Não toque na entrega.

Execute através do wrapper do repositório:

1scripts/run_codex_step.sh improve_scoring

A primeira versão do meu melhorador cometeu um erro útil. Ele perseguiu o sinal de resposta mais limpo. A comparação_concorrente tinha a taxa de resposta mais forte no pequeno registro de resultados, então o melhorador queria aumentar esse peso. A avaliação permaneceu em 0,75, então a alteração foi rejeitada.

É exatamente por isso que o portal existe. Um sistema mais fraco teria aceitado a história porque parecia razoável. Este fez uma pergunta melhor: a alteração corrigiu o erro conhecido?

A segunda passagem encontrou a menor edição que ajudou:

1- visita_pagina_implementacao: 4
2+ visita_pagina_implementacao: 6

A avaliação passou:

1Northwind Finance: previsto=revisao_humana esperado=revisao_humana
2Bluepeak Studio: previsto=ignorar esperado=ignorar
3KiteOps: previsto=rascunho esperado=rascunho
4Atlas Recruiting: previsto=ignorar esperado=ignorar
5score=1.00

Esse é o momento em que o loop se torna útil. Ele alterou uma regra, por um motivo, e provou a alteração contra um fixture.

Como é quando funciona bem. O diff proposto é chato e rastreável: uma linha alterada, um motivo baseado em resultado anexado, uma avaliação melhorada.

Onde quebra. O Codex altera três pesos e dois prompts de uma vez. Agora ninguém pode dizer qual alteração ajudou. Mantenha a lei estrita: um conceito por proposta.

Passo 6. Melhore os arquivos de prompt separadamente

A pontuação é apenas metade do sistema. Os modelos de mensagem também se desgastam.

Uma linha que funcionava no mês passado começa a parecer familiar. Uma pergunta que gera respostas em um segmento é ignorada em outro. Uma frase que parece afiada internamente é punida pelo mercado. Trate a melhoria de prompt como uma faixa separada para que o Codex não misture pontuação e texto no mesmo PR.

Crie config/plays.yaml:

1jogadas:
2  nota_migracao:
3    arquivo_prompt: prompts/plays/nota_migracao.md
4    usar_quando:
5      - comparacao_concorrente
6    linhas_proibidas:
7      - "pensei que isso poderia ser relevante"
8      - "pergunta rápida"
9
10  angulo_implementacao:
11    arquivo_prompt: prompts/plays/angulo_implementacao.md
12    usar_quando:
13      - visita_pagina_implementacao
14    linhas_proibidas:
15      - "conferindo nossa solução"
16      - "adoraria conversar"

Depois crie prompts/improve_prompt.md:

1Você melhora uma jogada de outbound.
2
3Leia:
4- AGENTS.md
5- config/plays.yaml
6- memory/outcomes.jsonl
7- o arquivo de prompt da jogada escolhida
8
9Escolha uma jogada com pelo menos 10 resultados.
10
11Encontre:
12- linhas ou estruturas que aparecem em resultados positivos
13- linhas ou estruturas que aparecem em resultados sem_resposta ou ma_adequacao
14- qualquer frase que deva ser proibida
15
16Faça uma pequena edição no prompt dessa jogada.
17
18Regras:
19- Não altere a pontuação.
20- Não crie uma nova jogada.
21- Não adicione um novo canal.
22- Cite linhas de resultado.
23- Escreva a instrução anterior e posterior.
24
25Depois execute a avaliação de texto se existir.
26Se não existir avaliação de texto, abra o PR como review_required.

Algumas melhorias podem ser pontuadas automaticamente. Outras ainda precisam de bom gosto. Se não houver avaliação de texto, o Codex pode propor a edição do prompt, mas deve marcar o PR para revisão em vez de fingir que a edição está comprovada.

Como é quando funciona bem. O Codex diz: "Esta frase apareceu em sete resultados sem resposta, então a adicionei a linhas_proibidas", ou "respostas positivas citaram o detalhe de implementação na primeira frase, então apertei a jogada para exigir isso."

Onde quebra. O melhorador reescreve toda a voz porque uma mensagem recebeu uma resposta. Edições de prompt devem ser menores do que seu instinto.

Passo 7. Envie alterações como pull requests

Esta é a camada de controle. O Codex edita arquivos, executa a avaliação e escreve o resumo do PR. Um humano revisa e mescla.

Crie prompts/pr_summary.md:

1Escreva um resumo de pull request para esta melhoria de outbound.
2
3Inclua:
41. O que mudou.
52. Por que mudou, citando linhas de resultado.
63. Pontuação anterior.
74. Pontuação posterior.
85. Arquivos alterados.
96. Risco.
107. O que o revisor humano deve verificar.
11
12Mantenha curto.
13Não afirme que a alteração está ativa.

Crie scripts/open_pr.sh:

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

O PR deve parecer que um colega de equipe o escreveu:

1Alterado:
2- Aumentou visita_pagina_implementacao de 4 para 6.
3
4Por quê:
5- A KiteOps tinha intenção de página de implementação e respondeu com cronograma de implementação.
6- A pontuação anterior direcionava esta conta para ignorar.
7
8Antes:
9- pontuação da avaliação 0.75
10
11Depois:
12- pontuação da avaliação 1.00
13
14Verificação do revisor:
15- Certifique-se de que a intenção de implementação seja específica o suficiente.
16- Mantenha downloads genéricos baixos.
17- Mescle apenas se isso corresponder ao julgamento real de vendas.

Esse é o sistema de segurança. O Codex faz o trabalho tedioso. O operador mantém o padrão.

Como é quando funciona bem. Um PR por semana, diff pequeno, motivo claro, avaliação aprovada.

Onde quebra. Alguém dá permissão ao Codex para mesclar porque a revisão parece um atrito. Esse minuto separa um sistema que melhora de um sistema que deriva.

Passo 8. Coloque em uma cadência

Não execute isso após cada resposta. É assim que um sistema se ajusta excessivamente a uma conta barulhenta.

Deixe a semana acontecer, deixe os resultados se acumularem, depois ajuste.

Crie 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

Depois cron:

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

Se você usar GitHub Actions, mantenha a mesma estrutura:

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

Execute os dois primeiros ajustes manualmente. Leia cada diff. Observe o que o Codex tenta alterar quando a amostra é pequena. Quando as propostas se tornarem chatas, coloque em um cronograma.

Como é quando funciona bem. Um PR semanal aparece com as evidências, o diff e o resultado da avaliação. Você mescla, edita ou fecha.

Onde quebra. O trabalho é executado, ninguém revisa e os PRs se acumulam. Um sistema auto-melhorável ainda tem um hábito humano: ler o diff.

A versão clone-e-execute

O repositório deve vir com quatro comandos:

1git clone <repositorio>
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

Primeira execução esperada:

1score=0.75
2alterado config/scoring.yaml
3visita_pagina_implementacao: 4 -> 6
4score=1.00
5abrir PR para revisão humana

A demonstração offline prova os contratos de arquivo. A execução do Codex prova o loop de edição. Depois disso, substitua os resultados de amostra pelos seus próprios, renomeie os sinais, adicione suas jogadas e construa um fixture que reflita as contas que você gostaria que o sistema tivesse direcionado de forma diferente.

Não comece conectando a entrega. Comece provando o loop de melhoria.

A versão completa: max

Este repositório é a camada manual. Ele executa a partir de arquivos, sinais públicos e seu plano Codex. Ele ensina a estrutura porque cada regra está exposta.

yourmax.ai é o mesmo sistema com as costuras ocultas.

Em vez de um repositório que você conecta por conta própria, max é o agente que você usa diretamente. Ele detecta movimentos no mercado, decide quem vale a pena contatar e por que agora, elabora a divulgação por e-mail e LinkedIn para sua aprovação e continua melhorando a partir dos resultados.

O repositório mostra a camada de auto-ajuste que a maioria das equipes nunca constrói: resultados se tornam alterações de regras propostas, alterações de regras propostas passam por um portal, e a mesclagem humana decide o que se torna ativo. max pega essa mesma lógica operacional e a executa como um sistema gerenciado.

Se você quiser o repositório completo, pode me avisar e eu o enviarei para você.