Defina regras organizacionais de forma central e aplique em todo o seu ecossistema de agentes.
Um requisito de conformidade não deveria exigir implementações separadas para cada departamento e tecnologia. Quando a mesma regra é reescrita em cada time, ela deixa de ser uma regra e vira várias versões dela, e a auditoria precisa conferir todas.
Regras que impedem um agente de expor credenciais, segredos ou dados de outro tenant.
Quais agentes podem falar com quais sistemas, em qual ambiente e sob qual identidade.
Quais modelos são permitidos por caso de uso, com limites de custo e de contexto.
Quais ferramentas cada agente pode chamar, e quais exigem confirmação humana antes da execução.
Como dados pessoais e regulados são mascarados, retidos e registrados.
Requisitos setoriais como regra executável, escrita a partir da planilha do compliance, com uma citação legal por regra.
Quando a execução para e espera uma pessoa, e quantas pessoas precisam aprovar.
Políticas internas que valem para toda a frota, independentemente de quem construiu o agente.
Aplique políticas entre agentes sem reconstruir cada implementação individualmente. Quando um agente tenta chamar uma ferramenta, buscar um dado ou usar um modelo, a chamada passa pela regra da organização antes de sair: se a regra bloqueia, ela não sai; se exige aprovação, a execução para e espera uma pessoa; se permite, segue, e o registro fica.
Política aplicada na fronteira, em vez de desculpada depois: tetos de gasto, quatro olhos em ações sensíveis e kill-switch por tenant.
A política decide se uma chamada pode sair. A regra de negócio decide o que o agente faz com o caso: quanto oferecer, quem aprova, qual faixa se aplica. Ela sai do prompt e vai para um motor de regras, em quatro passos.
Tabelas de decisão escritas por quem é dono da regra.
Canônica e versionada, com agregação e quantificadores.
O motor de regras é um adaptador, substituível por contrato, e não um lock-in.
O agente chama a regra pela linguagem, e um id de decisão cai na trilha.