Cole a thread como texto no state; a sumarização de anexos acontece antes da chamada. Uma thread de 20 e-mails ainda fica bem abaixo do teto de tokens.

A intenção "other" pega o spam?

Em parte — a maioria do spam pontua other com urgência baixa, onde um filtro mais rápido pode descartá-lo. Phishing merece um classificador de segurança, não este: o custo de uma direção errada aqui é humano.

Cada equipe pode ajustar as próprias filas?

A choice de intent é uma decisão única compartilhada — mantenha o wording dos criteria sob posse do dono da caixa compartilhada, para que "sales" não signifique, silenciosamente, algo diferente para cada equipe.

Caso de uso

Triagem de e-mails e leads

Separe o e-mail que entra em billing, suporte ou vendas e marque o que é para hoje.

O problema

Caixas de entrada compartilhadas viram um monte. Renovações esperam atrás de perguntas de funcionalidade.

O que seu código faz com a resposta

Roteie pela intenção. Tudo que for marcado como urgente passa na frente do backlog.

Lendo a caixa de entrada em uma chamada

O e-mail (assunto e corpo como um único state) decide para onde ele vai: intent (choice entre billing, support, sales, other) e urgent (isto deve ser respondido hoje). O e-mail de exemplo — uma renovação bloqueada porque o financeiro nunca recebeu a INV-2041, reenvio pedido para hoje — pontua intent=billing e urgent alto, que é exatamente o e-mail que não pode esperar atrás de perguntas de funcionalidade em uma caixa compartilhada.

A regra das filas

Roteie pela intent, com cada fila mantendo o próprio SLA; qualquer coisa urgente passa na frente do backlog. Mais uma regra se paga: e-mail cuja probabilidade de intent está disputada entre duas filas vai para as duas, em vez de para a mais alta. A cerca de 400 tokens por e-mail, triar dez mil e-mails custa alguns dólares em créditos.

Pitfalls específicos de triagem de caixa de entrada

A falha comum é o contexto de resposta perdido: um "re:" chega com a cadeia anterior removida, e a intent lê sobre nada. Cole a thread no state. Também — se os SLAs de duas equipes diferem (suporte responde em horas, vendas no mesmo dia), intent e urgent precisam, cada um, do seu próprio caminho, senão "urgente" desprioriza silenciosamente metade do e-mail de vendas.

O formato da requisição

Esta é a requisição completa que o playground envia para este preset — o mesmo JSON que o seu servidor envia para /v1/systemone com uma chave Bearer.

curl

curl https://jevai.website/api/v1/systemone \
  -H "Authorization: Bearer $JEV_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "state": "Subject: Re: invoice INV-2041\nHi, we never received INV-2041 and finance is blocking our renewal until this is sorted. Can someone resend it today?",
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What is the sender asking for?",
      "criteria": {
        "billing": "Invoice, payment or refund",
        "support": "Product help",
        "sales": "Pricing or a new deal",
        "other": "Something else"
      }
    },
    "urgent": {
      "type": "noul",
      "instructions": "Should this be answered today?"
    }
  }
}'

FAQ sobre este caso de uso

E anexos e threads?: Cole a thread como texto no state; a sumarização de anexos acontece antes da chamada. Uma thread de 20 e-mails ainda fica bem abaixo do teto de tokens.
A intenção "other" pega o spam?: Em parte — a maioria do spam pontua other com urgência baixa, onde um filtro mais rápido pode descartá-lo. Phishing merece um classificador de segurança, não este: o custo de uma direção errada aqui é humano.
Cada equipe pode ajustar as próprias filas?: A choice de intent é uma decisão única compartilhada — mantenha o wording dos criteria sob posse do dono da caixa compartilhada, para que "sales" não signifique, silenciosamente, algo diferente para cada equipe.

Rodar no playground