orquestrador/docs/architecture/admin-model-runtime-separation.md

Separacao Entre Modelo Do Atendimento E Modelo De Geracao De Tools

Objetivo

Definir a fronteira entre o runtime de modelo usado no atendimento ao cliente e o runtime de modelo usado para gerar e validar novas tools.

Esta etapa consolida uma regra importante da arquitetura: os dois perfis de modelo nao podem compartilhar configuracao nem ciclo de publicacao.

Decisao

O sistema passa a tratar esses runtimes como perfis independentes.

Perfis:

1. atendimento_runtime_profile
2. tool_generation_runtime_profile

A separacao formal fica em shared/contracts/model_runtime_separation.py.

Regras obrigatorias

1. Configuracoes distintas

Cada runtime possui sua propria config_key.

Portanto:

• o atendimento usa atendimento_runtime_profile
• a geracao de tools usa tool_generation_runtime_profile
• uma mudanca de configuracao nunca reutiliza a mesma chave para os dois contextos

2. Catalogos com alvo separado

Os modelos homologados precisam carregar o alvo funcional correto.

Portanto:

• modelos homologados para atendimento entram sob runtime_target = atendimento
• modelos homologados para geracao entram sob runtime_target = tool_generation
• um modelo pode existir nos dois catalogos, mas a selecao continua independente

3. Publicacao independente

Os dois runtimes possuem publicacao independente.

Consequencia pratica:

• publicar uma mudanca no atendimento nao publica a geracao de tools
• publicar uma mudanca na geracao de tools nao muda o bot que responde ao cliente
• cada perfil pode ter sua propria auditoria e versao ativa

4. Rollback independente

Cada runtime precisa poder voltar ao estado anterior sem afetar o outro.

Consequencia pratica:

• rollback do atendimento nao mexe no runtime de geracao
• rollback da geracao nao mexe no atendimento em producao

5. Sem propagacao implicita

Nao e permitido que uma alteracao em um runtime seja espelhada automaticamente no outro.

Isso impede:

• trocar o modelo do bot e, por efeito colateral, trocar o modelo de geracao
• usar defaults compartilhados para empurrar mudancas silenciosas nos dois fluxos
• misturar SLO, custo e risco do atendimento com o pipeline de tools

Responsabilidade por runtime

Atendimento

• alvo funcional: responder ao cliente final
• servico consumidor: product
• impacto direto: experiencia do atendimento e fluxo conversacional

Geracao de tools

• alvo funcional: gerar e validar novas tools
• servico consumidor: admin
• impacto direto: pipeline de governanca, geracao e validacao

Consequencias positivas

• protege o atendimento de experimentos de geracao de codigo
• permite escolher modelos diferentes para custo, latencia e qualidade em cada fluxo
• simplifica auditoria e rollback de configuracao
• prepara as futuras telas e rotas de configuracao do sistema sem ambiguidade