Agente de Triagem

Papel e código

Triagem inicia a sessão, identifica a frente de atendimento e distingue pedido de serviço, dúvida e demanda que exige humano. Seu builder é build_triagem_system_prompt() em src/core/agents/triagem/system_prompt.py; o consumidor é AgentInvokerImpl._build_system_prompt(). O caso de uso seleciona AgentName.TRIAGEM quando a sessão está em TRIAGE.

O agente não consulta status de análises, não grava contatos e não escolhe livremente um pipeline comercial. Ele retorna informação ao dispatch_triagem() de src/core/application/action_mapping.py.

Input e contexto

Input	Origem e uso
agent_name	Identidade configurada
instance	gogenetic ou goyou; calibra texto e frente
business_hours	Calculado com horário efetivo; permite continuar fora de expediente sem prometer retorno
cliente_conhecido, cliente_nome	recognized_name ou nome cadastrado na sessão
strategic_companies	Override operacional; fallback empacotado no prompt
available_packages	Catálogo compacto da KB dinâmica
injected_packages	Tuplas ID/conteúdo recuperadas pela sessão
Histórico	Somente mensagens INBOUND/OUTBOUND da sessão, sem outbound superseded

Na abertura para cliente novo o prompt pede nome e empresa, aceitando pessoa física. Se o usuário já informou um dado, deve perguntar somente o que falta. A introdução deve identificar atendimento automatizado e possibilidade de humano. Esses dados de abertura não são automaticamente transferidos por qualquer código: s=1 da Triagem não faz merge cadastral; o histórico permite recuperá-los depois.

Classificação e ações

Segmentos aceitos são AGRO, HUMANO, PESQUISA, ANIMAL; intents são servico, duvida, reclamacao, cancelamento, status, humano. O código s=2 exige strings válidas para ambos.

Código	Saída do dispatcher
1	Responde e fica em TRIAGE
2 com servico	Guarda segmento/intenção, passa para QUALIFYING e chama Qualificação no mesmo turno; texto da Triagem não é enviado
2 com outro intent	Guarda segmento/intenção e permanece TRIAGE
3	HANDOFF_PENDING; default pedido_cliente, preserva contexto opcional válido
4	OUT_OF_SCOPE; exige out_of_scope_service e registra demanda
5	Dúvida respondida, permanece TRIAGE
97 / 98 / 99	Confirma assunto / troca confirmada / busca contexto

O prompt determina que reclamação, cancelamento, status e pedido de humano usem s=3; o dispatcher não força handoff se o modelo devolver esses intents junto com s=2. Esta diferença entre instrução e validação deve ser considerada em regressões.

Critérios de handoff e conhecimento

O prompt instrui handoff para empresa estratégica, reclamação, cancelamento, pós-venda, recusa de texto, pedido explícito ou incerteza. empresa_detectada é preservada em qualification_data; segmento e intenção válidos alimentam resumo/roteamento. Motivo desconhecido usa o default do agente, sem lançar erro.

Todos os packages ativos podem ser solicitados, sem ACL por agente. Os mais associados à recepção são COMPANY_INFO, PORTFOLIO_OVERVIEW, PORTFOLIO_EXCLUSIONS e GOGENETIC_YOU; isso é orientação de uso, não restrição de código. Antes de afirmar exclusão, preço ou fato técnico, o prompt pede buscar contexto ou encaminhar em caso de incerteza.

Exemplos sintéticos

Entrada do usuário: “Estou em um laboratório de pesquisa e preciso avaliar uma amostra.” Uma resposta intermediária possível:

{"s":2,"segment":"PESQUISA","intent":"servico"}Vou entender os detalhes da análise.

O Orchestrator guarda classificação e chama Qualificação; apenas a resposta final do encadeamento chega ao cliente.

{"s":3,"intent":"humano","handoff_reason":"pedido_cliente"}Vou encaminhar sua solicitação à equipe.

Este segundo exemplo encaminha sem exigir cadastro completo. O motivo aparece no resumo e a sessão permanece aguardando operador.

Exemplo inválido:

{"s":2,"segment":"COMERCIAL","intent":"servico"}Certo.

O JSON passa pelo parser, mas COMERCIAL não é Segment; o dispatcher lança erro de aplicação, mapeado pelo caso de uso para handoff de contrato. Não se cria um novo segmento a partir de texto livre.

Testes e como alterar

Fontes: tests/unit/agents/test_system_prompts.py, tests/unit/agents/test_invoker.py, tests/unit/application/test_action_mapping.py e test_process_message_use_case.py (test_triagem_s2_servico_chains_to_qualificacao, test_early_handoff_persists_routing_context, test_triagem_s4_registers_demand_and_terminates). As fixtures TC-07-out-of-portfolio.json, TC-08-empresa-grande-handoff.json e TC-14-reclamacao.json documentam cenários; não reutilize dados pessoais delas em novos exemplos.

Para mudar critérios de roteamento, revise prompt e validação juntos. Para ajustar empresas estratégicas, confira configuração operacional antes de modificar o fallback estático. Para um novo segmento, atualize enum, campos, UI, roteamento humano, CRM e testes. Veja ações, packages e handoff.