Roadmap com 12 passos – Loops, Graphs, Evals, Context, Harness (Full-Course)
Engenheiro de Agentes de IA em 2026: roteiro de 12 etapas – Loops, Gráficos, Avaliações, Contexto, Aproveitamento (Curso Completo)
Este é o roteiro completo de 12 etapas pelos sete pilares que realmente determinam se um agente funciona: contexto, ferramentas, memória, loops, grafos, harness, avaliações – cada um com o fluxo de trabalho Claude que comprova sua eficácia.
Os modelos de vanguarda passaram de 30% para mais de 80% de aprovação no SWE-bench Verified em apenas um ano. Os agentes de codificação apresentaram melhorias drásticas e mensuráveis.
Entretanto, apenas 17% dos executivos afirmam ter adotado totalmente agentes de IA em suas empresas.
Os agentes falham porque o contexto fica sobrecarregado. Porque os loops nunca convergem. Porque ninguém consegue medir se a mudança da semana passada trouxe alguma melhoria. A demonstração funciona na sua máquina. Produção é outra história.
Este é o roteiro de 12 etapas através dos sete pilares que separam os dois – cada um com seus próprios modos de falha, seu próprio fluxo de trabalho Claude e sua própria maneira de eliminar silenciosamente seu agente se você o ignorar.
Eis a reformulação que torna o resto coerente. Não se trata de sete habilidades separadas. É uma habilidade em sete projeções.
- Um contexto inadequado interrompe o ciclo.
- Um loop sem avaliações nunca converge para algo em que você possa confiar.
- Um gráfico sem avaliações dimensiona seu erro em vez de sua taxa de transferência.
- A memória sem um sistema de retenção evapora no instante em que a sessão termina.
- Ferramentas sem gerenciamento de contexto inundam a janela antes mesmo do trabalho começar.
Isso significa que não há uma maneira útil de aprendê-los isoladamente – mas existe uma ordem de dependência , que segue a seguinte ordem: fundamentos em primeiro lugar, execução em segundo e confiabilidade por último. É assim que esses doze passos estão organizados.
01. Contexto – leia o que realmente carrega
A abordagem de Karpathy é a correta: o modelo é a CPU, a janela de contexto é a RAM. A engenharia de contexto é a arte de preencher essa RAM com exatamente o que a próxima etapa precisa – nada mais.
O número que redefine tudo: no Código Claude, aproximadamente 7.850 tokens são carregados antes mesmo de você digitar um único caractere – prompt do sistema, memória automática, descrições de habilidades, CLAUDE.md, informações do ambiente, nomes de ferramentas do MCP.
Seu prompt real está em torno de 45. Todo mundo otimiza o de 45 e nunca abre o de 7.850.
O comando /context exibe a sua análise detalhada por categoria, informa quais arquivos de memória foram carregados e indica qual chamada de ferramenta consumiu a maior quantidade de tokens.
Observe dois números: arquivos em memória (um arquivo pesado significa um CLAUDE.md com excesso de dados) e espaço livre . Combine isso com o comando `/memory` para ver os arquivos exatos em uso.
02. Contexto – recorte e depois sobreponha em camadas
A Anthropic removeu mais de 80% dos prompts do sistema do Claude Code para a 5ª geração e não detectou nenhuma perda em suas avaliações de codificação.
A maior parte do contexto não está errada – trata-se de um guia escrito para um modelo mais fraco que agora custa apenas fichas e força Claude a resolver contradições antes de poder começar.
Duas regras tornam o corte seguro:
- Apague em blocos, não em linhas — uma única frase fica perdida no ruído de fundo das suas avaliações e não te diz nada. E transforme absolutos em princípios: em vez de “nunca escreva comentários com várias linhas”, diga escreva um código que seja legível como o código ao redor — combine a densidade de comentários, a nomenclatura e o estilo. A regra dá uma resposta fixa, o princípio dá ao Claude uma maneira de encontrar a resposta certa lendo seu repositório.
- O que sobrevive vai para uma árvore, não para um pergaminho. A orientação de Anthropic é um número rígido: mantenha o projeto CLAUDE.md com menos de 200 linhas , contendo apenas as pegadinhas que Claude não consegue inferir.
Todo o resto se torna uma habilidade (a descrição é carregada na inicialização, o corpo na invocação) ou uma regra com escopo de caminho (carregada somente quando um arquivo correspondente é lido).
Python
# payments-api
Subscription billing and invoicing for the web app.
## Gotchas
// Non-obvious. Claude cannot infer these by reading the repo.
- All shared types live in `src/types.ts` — one monolithic file.
- `Money` is integer cents, never a float.
- Webhook retries must stay idempotent — provider replays for 72h.
- `db/legacy/` is frozen. Read it, never edit it.
## Deeper guides
- Verification → `.claude/skills/verify/`
- Releases → `.claude/skills/deploy/`
// NOT here: directory tree, framework, test runner, language
// version. Claude reads those from the repo itself.03. Ferramentas e MCP – o que o agente pode alcançar
As ferramentas são a forma como um agente interage com o mundo, e suas descrições são o contexto – o que faz delas a articulação entre o que o agente pode fazer e o que ele pode se dar ao luxo de saber.
O conselho antigo era ensinar as ferramentas com exemplos.
Isso invertido: com os modelos atuais, os exemplos restringem Claude ao espaço de exploração que descrevem. Em vez disso, projete parâmetros expressivos.
Uma enumeração de status com os valores pendente | em andamento | concluído ensina todo um ciclo de vida sem um único exemplo – o tipo é a documentação.
A Anthropic alcançou o estado da arte no SWE-bench, verificado em parte por meio de refinamentos precisos nas descrições das ferramentas , e não por alterações no modelo.
E adiar o despejo de dados é melhor. O Claude Code carrega apenas os nomes das ferramentas MCP – cerca de 120 tokens – buscando os esquemas sob demanda por meio da pesquisa de ferramentas.
Aplicar a recuperação de informações às descrições das ferramentas, em vez de carregá-las todas, melhora a precisão da seleção em aproximadamente três vezes.
Isso faz da descrição a superfície de descoberta: diga quando a ferramenta se aplica, não apenas o que ela faz. Uma ferramenta que Claude não consegue encontrar é uma ferramenta que você não enviou.
Python
@mcp.tool()
def find_stalled_shipments(hours: int = 24) -> list[dict]:
"""Shipments with no scan event in N hours.
Use when ops asks what is stuck, or before an escalation review."""
return query(STALLED_SQL, hours)
@mcp.tool()
def reroute(shipment_id: str, hub: str, reason: str) -> dict:
"""Reroute a shipment. Writes an audit row — compliance
requires a reason on every manual intervention."""
return post_with_audit(shipment_id, hub, reason)
# "Use when..." is the discovery surface for tool search.
# `reason: str` is required, so the audit trail cannot be skipped.
# The type enforces what a paragraph of instructions would only ask for.04. Memória – o que sobrevive à janela
Toda tarefa longa eventualmente ultrapassa uma única janela.
O que acontece nesse limite é uma decisão de projeto que a maioria das pessoas nunca toma – elas deixam a compactação automática adivinhar e depois se perguntam por que o agente se esqueceu de uma restrição definida uma hora antes.
A mecânica é específica e vale a pena memorizar. O arquivo CLAUDE.md na raiz do projeto e a memória automática são reinjetados do disco.
Mas as regras definidas por caminhos e os arquivos CLAUDE.md aninhados ficam armazenados no histórico de mensagens – eles são resumidos e não retornam até que um arquivo correspondente seja lido novamente.
Os corpos de habilidades invocadas retornam, limitados a 5 mil por habilidade e 25 mil no total , os mais antigos são descartados primeiro e truncados a partir do final – portanto, qualquer coisa crítica deve estar no topo de um arquivo SKILL.md.
A solução mais confiável é a mais antiga da computação: escrever em um arquivo.
Um arquivo de plano, um registro de progresso, anota as reescritas do agente à medida que avança. Ele persiste sem ocupar a janela e sobrevive à compactação porque reside no disco.
Comprima deliberadamente também – o comando /compact foca no bug de autenticação, mantendo o que você escolheu, e o comando /clear é muito subutilizado quando a próxima tarefa não depende das últimas vinte mensagens.
05. Loops – quando parar
Um ciclo de agente consiste em agir → observar → decidir → repetir. Todo o problema de engenharia reside nessa última etapa: como o sistema sabe que terminou?
Deixado por conta própria, um modelo responde mal em duas direções: declarando vitória em um trabalho incompleto ou indefinidamente trabalhando em algo que já foi feito três iterações atrás.
Nenhuma das duas é resolvida por uma sugestão melhor, porque ambas são estruturais. A condição de parada pertence a um código que está fora do alcance do modelo. Para trabalhos com escopo limitado, isso se traduz em um ponto de teste ou uma verificação de esquema.
Para a descoberta de tamanho desconhecido, o padrão convergente é o de repetição até secar: continue até que K rodadas consecutivas não revelem nada de novo.
Um detalhe faz toda a diferença, e quase todo mundo erra na primeira tentativa: a remoção de duplicatas é feita com base em tudo o que foi visto, e não apenas nos resultados confirmados.
Caso contrário, as descobertas rejeitadas reaparecem a cada rodada, o ciclo nunca se esgota e você construiu uma máquina que compensa eternamente ao redescobrir os mesmos becos sem saída.
Python
const seen = new Set(); const confirmed = []; let dry = 0;
while (dry < 2) { // stop after 2 empty rounds
const found = await runFinders();
const fresh = found.filter((b) => !seen.has(key(b)));
if (!fresh.length) { dry++; continue; }
dry = 0;
fresh.forEach((b) => seen.add(key(b)));
// ^ dedupe against SEEN, not against confirmed.
// Backwards, and this loop never terminates.
confirmed.push(...(await verify(fresh)));
}06. Loops – quem verifica a resposta
Um ciclo convergente ainda converge para aquilo em que o modelo acreditava. A solução é um verificador – algo externo ao julgamento do próprio modelo, cuja única função é tentar refutar a descoberta.
Se sobreviver, passa. Caso contrário, nunca chega à resposta.
Três modelos que vale a pena ter à mão:
- Verificação adversarial: para cada descoberta, crie N céticos independentes instigados a refutá-la; mantenha-a apenas se a maioria sobreviver.
- Verificação com perspectivas diversas: atribua a cada verificador uma lente distinta – correção, segurança, reprodutibilidade – porque a diversidade detecta modos de falha que N verificações idênticas jamais detectariam.
- Painel de jurados: gerar N tentativas de diferentes ângulos, pontuar com jurados paralelos, sintetizar a partir da vencedora, incorporando o melhor das demais finalistas.
Python
› For each finding, spawn three verifiers - correctness, security, reproducibility. Accept only what survives two of three.
● 6 findings → 18 verifier agents, running in parallel
✓ missing auth on /invoices/:id 3/3 — accepted ✓ race in webhook retry 2/3 — accepted
● "unsafe regex in validator" 0/3 — killed
● "N+1 query in dashboard" 1/3 — killed 2 of 6 findings were confident and wrong. The loop caught them, not your reviewer, and not your users.Observe para onde isso aponta. Um verificador é uma avaliação executada em linha — a mesma disciplina da Camada III, aplicada por resultado em vez de por versão. Equipes que criam bons verificadores acham a etapa 11 muito mais fácil, porque já definiram o que significa “bom”.
07. Gráficos – o que funciona em paralelo
A maioria das pessoas escreve sobre agentes como uma linha reta – passo um, passo dois, passo três, cada um esperando educadamente pelo anterior. Então elas percebem que metade desses passos nunca precisou esperar.
Um nó é uma unidade de trabalho; uma aresta significa que esta saída alimenta aquela entrada. Se não houver cruzamento de dados, não há aresta – e a espera é puro desperdício.
O formato mais utilizado é o diamante : expanda para ganhar amplitude, reduza com código simples, sintetize com um único agente.
A etapa de redução merece destaque porque é onde o dinheiro vaza – o achatamento e a desduplicação são feitos com flatMap e Set, não com um agente.
As vantagens são gratuitas. Invista seus agentes em bom senso, não em infraestrutura.
O potencial é realmente enorme. Os fluxos de trabalho dinâmicos do Claude Code coordenam até 1.000 subagentes paralelos em uma única execução, e a orquestração não consome nenhum token de modelo, pois se trata de um script, não de uma conversa.
Python
› Run a workflow to audit every route under src/routes/ for missing
auth. One agent per route file, verify each finding before reporting. ●
Claude wrote an orchestration script · launching… ✓ Scope 1/1 ✓ Fan-
out 18/18 one agent per file ◯ Verify 11/18 3-vote skeptics per finding
○ Synthesize 0/1 your session stays responsive — the fleet runs in the
backgroundEssa arquitetura foi o que permitiu a uma equipe portar cerca de 960.000 linhas do runtime do Bun de Zig para Rust em seis dias , com 99,8% do conjunto de testes ainda sendo aprovado.
08. Gráficos – o que a forma lhe custa
A topologia não é apenas cosmética – é o fator mais importante que você tem para controlar tanto a latência quanto os gastos, e duas escolhas são as que mais influenciam.
Primeiro, parallel() versus pipeline(). Uma barreira parallel() faz com que tudo espere pelo nó mais lento antes que o próximo estágio comece.
A função pipeline() transmite cada item por todos os estágios de forma independente – o item A pode estar no estágio 3 enquanto o item B ainda está no estágio 1.
Use o pipeline por padrão. Recorra a uma barreira somente quando uma etapa realmente precisar de todos os resultados anteriores de uma só vez, como em uma desduplicação entre conjuntos. “Parecia mais limpo” não é uma justificativa válida; a latência da barreira é tempo real, mensurável e desperdiçado.
Em segundo lugar, o modelo em camadas por nó. Cada subagente herda o seu modelo de sessão, a menos que o script o substitua; portanto, uma execução grande é faturada inteiramente na sua camada superior por padrão.
Nós delimitados e repetitivos – extrair este campo, classificar este bilhete – pertencem a um modelo mais econômico; o nó de junção, onde o julgamento realmente acontece, permanece com alta prioridade.
Cem nós de distribuição baratos alimentando uma síntese de alto nível custam uma fração do mesmo trabalho executado em modo convencional, com a mesma qualidade final.
09. Harness – sobrevivendo à morte da sessão
A perspectiva antropológica define o problema perfeitamente: uma tarefa longa é um projeto de software com uma equipe de engenheiros trabalhando em turnos, onde cada novo engenheiro chega sem nenhuma lembrança do turno anterior.
A compactação por si só não resolve o problema. Mesmo um modelo de fronteira que percorre janelas de contexto em “construir um clone de” claude.ai “fica aquém – e falha de duas maneiras específicas e repetíveis.”
Primeiro, o agente tenta executar o aplicativo de uma só vez , fica sem contexto no meio da implementação e deixa a próxima sessão com um recurso incompleto e não documentado que precisa ser analisado por meio de engenharia reversa.
Em segundo lugar, mais tarde no projeto, um agente olha ao redor, vê progresso real e declara o trabalho concluído.
Ambos são definidos antes do início de qualquer codificação, por um agente inicializador que é executado uma única vez e constrói o ambiente: um
que inicia o servidor de desenvolvimento, um registro de progresso, um commit inicial no Git e uma lista de recursos em JSON – mais de 200 entradas para o claude.ai clone, cada um marcado como reprovado.
Python
{
“category”: “functional”,
“description”: “New chat button creates a fresh conversation”,
“steps”: [
“Navigate to main interface”,
“Click the ‘New Chat’ button”,
“Verify a new conversation is created”,
“Check that chat area shows welcome state”
],
“passes”: false
}
// 200+ of these, all starting false. Agents may ONLY flip `passes`.
// “It is unacceptable to remove or edit tests” — deliberately strong
// wording, because a model that CAN edit the spec WILL edit the spec.
Um detalhe que vale a pena copiar sem hesitar: eles escolheram JSON em vez de Markdown para essa lista, porque os modelos têm uma probabilidade comprovadamente menor de reescrever JSON de forma inadequada.
10. Harness – um incremento por sessão
Com o ambiente estruturado, cada sessão de programação recebe um contrato: familiarizar-se com o sistema, escolher exatamente uma funcionalidade, verificá-la como um usuário faria e deixar o repositório limpo.
“Limpo” significa o que significa em uma equipe de verdade: sem bugs graves, código organizado e um próximo engenheiro que possa começar a trabalhar sem ter que limpar a bagunça de outra pessoa.
O ritual de orientação é mecânico e salva tokens a cada vez: senha, ler o arquivo de progresso, ler o log do git, ler a lista de recursos, executar.
E teste se as funções básicas ainda funcionam antes de mexer em qualquer coisa.
Essa última verificação é mais importante do que parece – sem ela, um agente que inicia uma nova funcionalidade em um aplicativo com problemas só agrava a situação.
E sobre marcar as coisas como concluídas: a tendência de Claude é finalizar uma alteração, executar alguns testes unitários e considerá-la terminada sem nunca verificar o recurso de ponta a ponta.
Python
[Assistant] Getting my bearings on the current state. [Tool] bash —
pwd [Tool] read — claude-progress.txt [Tool] read — feature_list.json
[Tool] bash — git log --oneline -20 [Tool] bash — ./init.sh start the dev
server [Assistant] Verifying fundamentals before touching anything… ✓
core chat, theme switching, conversation loading all pass [Assistant]
Picking the highest-priority failing feature. no guessing. no
archaeology. the previous shift left notes.Dê a ele ferramentas de teste reais e exija que a verificação seja feita como um usuário humano faria – automação do navegador, cliques reais.
Esse único requisito melhorou drasticamente o desempenho nos experimentos da Anthropic, detectando erros invisíveis apenas pelo código.
11. Avaliações – um número, não uma impressão
O ponto crucial é sempre a mesma frase: os usuários relatam que o agente fica pior após as alterações, e a equipe não tem como verificar isso, a não ser por tentativa e erro.
Sem avaliações (evals), a depuração é reativa: espera-se por reclamações, reproduz-se manualmente, corrige-se e espera-se que nada mais tenha regredido. Não é possível distinguir uma regressão real de ruído.
Comece com algo menor do que você imagina. As equipes costumam adiar o processo porque acham que precisam de centenas de tarefas; começar com 20 a 50 tarefas baseadas em fracassos reais é um ótimo começo , pois mudanças feitas logo no início têm um grande impacto.
Extraia-as dos testes que você já realiza manualmente, do seu sistema de rastreamento de bugs e da sua fila de suporte. Elabore-as de forma que dois especialistas no domínio cheguem independentemente à mesma conclusão – a ambiguidade em uma tarefa se torna ruído na métrica.
E construa conjuntos equilibrados : teste onde um comportamento deve ser acionado e onde não deve, ou você estará otimizando um agente que busca por tudo.
Combine três tipos de classificadores de forma deliberada.
- Baseado em código – rápido, barato, objetivo; use sempre que possível.
- Baseado em modelos – rubricas para nuances, calibradas com base em dados humanos, idealmente com um juiz independente por dimensão, em vez de um único juiz pontuando tudo.
- Humano – o padrão ouro, usado com parcimônia para calibrar os demais.
E avalie o que o agente produziu, não o caminho que ele percorreu : verificar uma sequência exata de chamadas de ferramentas é frágil, porque os agentes frequentemente encontram abordagens válidas que você não previu.
Python
task:
id: "fix-auth-bypass_1"
desc: "Fix authentication bypass when password field is empty"
graders:
- type: deterministic_tests # fast, objective, reproducible
required: [test_empty_pw_rejected.py]
- type: llm_rubric # nuance tests can't capture
rubric: prompts/code_quality.md
- type: static_analysis
commands: [ruff, mypy, bandit]
- type: state_check # the OUTCOME, not the claim
expect: { security_logs: { event_type: "auth_blocked" } }
tracked_metrics:
- type: transcript
metrics: [n_turns, n_toolcalls, n_total_tokens]
# The agent says "fixed". The state_check decides whether it was.
# Grade outcomes, not announcements.12. Avaliações – mantendo os números honestos
Um conjunto de testes que ninguém lê é um número em que ninguém deve confiar. Você não saberá como seus avaliadores funcionam até ler as transcrições de vários testes – quando uma tarefa falha, a transcrição informa se o agente cometeu um erro genuíno ou se o avaliador rejeitou uma solução válida.
Os fracassos devem parecer justos : o que deu errado e porquê deve ser óbvio.
Duas armadilhas fazem com que bons agentes pareçam maus.
- Uma taxa de aprovação de 0% em várias tentativas geralmente significa uma tarefa com defeito, não um agente incapaz. O Opus 4.5 inicialmente obteve 42% no CORE-Bench – então um pesquisador descobriu uma avaliação rígida que rejeitava “96,12” quando esperava “96,124991…”, especificações ambíguas e tarefas irreproduzíveis. Após as correções: 95%.
- A armadilha oposta é a saturação – uma avaliação a 100% rastreia regressões, mas não oferece nenhuma perspectiva de melhoria, e os ganhos reais de capacidade começam a aparecer como ruído.
Em seguida, considere duas métricas separadas. `pass@k` representa a probabilidade de pelo menos um sucesso em k tentativas – ela aumenta com k. `pass^k` representa a probabilidade de todos os k sucessos – ela cai rapidamente. Com 75% de sucesso por tentativa, a probabilidade de três tentativas serem todas bem-sucedidas é de apenas ~42%.
Use pass@k quando um sucesso for suficiente; use pass^k para qualquer interação com o cliente , onde os usuários esperam que funcione sempre.
› Run the suite against the new model and compare to baseline. ● 47
tasks × 3 trials · 141 runs · parallel capability suite pass@1 61% → 74%
+13 regression suite pass@1 99% → 99% held consistency pass^3
52% → 68% +16 ● 2 regressions: refund_partial, escalation_tone →
transcripts written to ./eval-results/failures/ the upgrade decision
took an afternoon, not three weeksPor fim, torne isso uma rotina. Integre o conjunto de ferramentas à integração contínua para que seja executado a cada alteração e a cada atualização de modelo.
É isso que transforma o lançamento de um novo modelo, que antes exigia semanas de testes manuais, em um único dia de execução do seu conjunto de testes e leitura das diferenças – e é a vantagem cumulativa que as equipes sem avaliações nunca conseguem alcançar.
7 tarefas para executar com Claude – uma por pilar
- Abra a janela que você nunca olhou. Meça primeiro, depois corte. Um número alto de arquivos de memória significa um CLAUDE.md sobrecarregado – diagnosticado com um comando, corrigido em uma tarde. › /contexto e depois /doutor
- Analise as descrições das suas ferramentas. Cada descrição deve indicar quando a ferramenta se aplica , e não apenas o que ela faz. Essa frase é o ponto de partida para a descoberta – sem ela, uma ferramenta conectada é uma que o Claude nunca seleciona. › Revise todas as descrições de ferramentas neste servidor MCP. Adicione uma frase “usar quando” a cada uma e restrinja os tipos de parâmetros.
- Mova o estado para o sistema de arquivos. Faça com que o Claude mantenha um arquivo de plano que ele reescreve conforme trabalha. Ele sobrevive à compactação porque reside no disco — e tarefas longas param de perder o fio no meio do processo. › Antes de começar, escreva o plano em plan.md e atualize-o após cada etapa. Releia-o sempre que retomar a execução.
- Adicione um verificador ao seu loop. Escolha qualquer tarefa em que Claude decida por si só que está concluída. Adicione uma verificação externa e observe com que frequência a primeira resposta não resiste a três verificadores céticos. › Após cada correção, inicie três verificadores: correção, segurança e reprodutibilidade. Aceite apenas o que resistir a dois dos três.
- Transforme uma tarefa linear em uma ramificação. Encontre uma tarefa em que você percorra arquivos ou fontes sequencialmente. Um agente por item, executando simultaneamente , e depois uma mesclagem. A diferença no tempo real é toda a lição. › Execute um fluxo de trabalho para auditar todas as rotas em src/routes/. Um agente por arquivo, verifique cada descoberta e, em seguida, sintetize.
- Crie a estrutura básica de um projeto com múltiplas sessões. Antes de uma compilação longa, peça ao Claude para escrever o arquivo init.sh , um log de progresso e uma lista de recursos em JSON com tudo marcado como falha. › Atue como um agente inicializador: escreva os arquivos init.sh , claude-progress.txt e feature_list.json, abrangendo todos os requisitos, com todos os passes definidos como falsos.
- Transforme os bugs da semana passada em um conjunto de tarefas. Abra seu sistema de rastreamento de bugs e converta falhas reais em 20 tarefas com critérios de aprovação claros. Esse conjunto de tarefas vale mais do que qualquer framework que você possa adotar neste trimestre. › Aqui estão 20 falhas reais. Escreva cada uma como uma tarefa de avaliação com avaliadores determinísticos sempre que possível e uma rubrica quando não for.
Conclusão:
Qualquer um consegue fazer uma demonstração funcionar. O trabalho está em tudo o que vem depois disso.
Os modelos continuam a melhorar no seu próprio ritmo, e essa melhoria é gratuita – acontece independentemente de você ter feito algo ou não. O que não é gratuito é o sistema que envolve o modelo.
- Contexto enxuto. Ferramentas que um agente pode realmente escolher.
- Memória que sobrevive à janela. Loops que convergem e são verificados.
- Gráficos que se expandem em vez de se enfileirarem. Um mecanismo que permite que a próxima sessão continue a anterior. E um número que indica se houve alguma melhora.
A maioria das pessoas continuará esperando por um modelo bom o suficiente para não precisar de nada disso.
Aqueles que desenvolverem os doze passos irão implementar agentes que funcionarão nos dias em que o modelo estiver com problemas – o que, em produção, é a única confiabilidade que realmente importa.
