Do playground à produção em uma tarde

Passo 0 — escolha a decisão certa

Bons primeiros candidatos são decisões que você já toma mal ou manualmente: uma regex de roteamento escrita à mão, um humano relendo a mesma política, uma flag "por favor revisar" que ninguém revisa. Maus candidatos são decisões em que errar é caro e imensurável — deixe essas com roteiro fechado para um humano por ora, com a decisão tipada como filtro de primeira passada.

Escreva o state como os dados que você já tem: o texto do ticket, o payload do formulário, a tool call prestes a ser executada. Não pré-resuma — a leitura é tarefa do modelo.

Hora 1 — rode dez exemplos reais no playground

O playground roda o modelo real, de graça, no navegador. Cole exemplos do seu backlog — tickets reais, não hipotéticos — até dez deles saírem como um colega cuidadoso decidiria.

• Respostas descalibradas? Aperte os criteria com um wording concreto de true/false.
• Casos ambíguos recebendo respostas confiantes? Seus criteria são grossos demais — adicione um nível à escala.
• Falta contexto? Coloque o fato que falta no state em vez de torcer para o modelo sabê-lo.

Hora 2 — copie o JSON para uma chamada com chave

O JSON que você vê no playground é o JSON que seu servidor deve enviar. Exatamente três coisas mudam na produção: o cabeçalho Authorization, o caminho do endpoint (/api/v1/systemone em vez do endpoint de navegador do playground), e a quota (planos gratuitos rodam 20 requests por minuto; o Starter começa em 120/min). Upgrades de plano aumentam concorrência e requisições por minuto — 3 concorrentes no Starter, 10 no Pro.

async function decide(state, questions) {
  const resp = await fetch("https://jevai.website/api/v1/systemone", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.JEV_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ state, questions }),
  });
  if (resp.status === 429 || resp.status === 502 || resp.status === 529) {
    // exponential backoff here — never retry 401/402/422
  }
  return resp.json();
}

Hora 3 — threshold, flag, deploy

Decida o que um número significa antes de conectá-lo: abaixo de 0.8 de confiança, envie o item a uma pessoa em vez de decidir. Entre no ar atrás de uma feature flag que envia, digamos, 5% do tráfego de produção para a decisão tipada no primeiro dia, e registre o request_id junto com a sua decisão antiga para poder comparar as duas.

• Registre request_id, o valor de score ou noul, e a ação que sua política tomou.
• Defina um timeout que tolere cold starts ocasionais (a primeira chamada depois de um período ocioso pode levar ~3 s; o restante se concentra em 400–600 ms).
• Configure alerta para 402 (créditos baixos) — é a única falha que um loop de retry não resolve.

Falhas comuns do primeiro dia e suas correções

• Respostas inconsistentes em casos parecidos — as descrições dos criteria são vagas ou contraditórias. Reescreva-as como linhas de política.
• 429s durante picos — o plano gratuito permite 20 req/min. Passe para o Starter (120/min, 3 concorrentes) ou enfileire seus picos no lado do cliente.
• Tudo roteia para a opção do topo — os textos dos criteria penderam para o mesmo lado. Equilibre-os.
• Um crédito cobrado onde você esperava cobrança por pergunta — a cobrança é por token de entrada com mínimo de 1 crédito por requisição, então agrupar perguntas é mais barato que separar. Veja o post de créditos para a matemática.

Escolha o threshold pelos dados, não pelo instinto

Depois de a flag rodar a 5% por um dia, a distribuição é sua. Anote em uma planilha a banda de baixa confiança (tudo abaixo de 0.8, entre 0.8 e 0.9, e acima de 0.9) e você normalmente encontrará decisões bimodais — um monte claro de respostas confiantes e uma cauda de reticentes em 0.5–0.7. É nessa cauda que a revisão humana acontece. Depois, mova o threshold para onde a sua fila consegue absorver revisão; em uma caixa de entrada compartilhada, uma taxa de revisão de 15% pode estourar o orçamento, e a ação certa é apertar os criteria — não aceitar 15% em silêncio.

Escalonamento quando você não tem certeza

• Confiança abaixo do threshold — envie a um humano com o state e a distribuição completa anexados.
• Requisição falhou (429/502/529 após retries) — volte para o caminho legado, não para pular a decisão. Uma decisão ausente é um bug, não um risco.
• Chaves de respostas ausentes no mapa answers — trate como falha e registre. (Não deveria acontecer; o schema garante uma resposta por nome de pergunta.)

Padrões de wording que movem a precisão

• Criteria como linhas de política, não sinônimos: "true: Explicitamente sensível a tempo ou crítico para o negócio; false: Nenhuma urgência expressa" supera "true: urgent; false: not urgent". O modelo lê os criteria, então escreva-os para uma pessoa de confiança temporária que nunca viu o seu produto.
• Nomeie os campos que você referencia: "`proposed_tool_call` corresponde ao que `user_request` pediu?" dá ao modelo base para ancorar o julgamento; "Isso é suspeito?" o faz adivinhar.
• Uma decisão por pergunta: não pergunte "isso é urgente E devo acionar alguém E não é duplicado?" — a resposta a uma pergunta composta é ininterpretável.
• Escalas com linha vermelha: quando a ação muda a partir de um nível, nomeie esse nível nos criteria das perguntas relacionadas em vez de torcer para o score sozinho codificá-lo.