Arquitetura Agêntica Regulada — Fundamentos e Estrutura (V2)

1. O problema

Modelos de linguagem de grande porte — conhecidos pela sigla inglesa LLM — conseguem interpretar situações novas, formular estratégias e adaptar respostas ao contexto. Essa flexibilidade é o que os torna úteis. Ela também cria um problema: em operações relevantes, não basta receber uma resposta plausível. É preciso saber qual tarefa foi atribuída, quais informações poderiam ser usadas, quais limites deveriam ser respeitados e o que caracteriza uma entrega válida.

A Arquitetura Agêntica Regulada — AAR organiza esse tipo de operação.

Seu objetivo não é programar cada passo do raciocínio da LLM. É definir com clareza:

o que deve ser feito;
sobre quais informações a LLM pode operar;
quais limites devem ser observados;
qual resultado precisa ser entregue;
como saber se a operação terminou;
o que pode acontecer em seguida.

A arquitetura não programa o raciocínio da LLM; contrata a capacidade que ela deve exercer.

Neste documento, contrato não significa contrato jurídico. Significa um conjunto explícito de responsabilidades, limites e resultados esperados.

2. A ideia central

A unidade fundamental da AAR é a Unidade Contratual de Capacidade — UCC.

Uma UCC descreve uma tarefa delimitada para uma LLM. Ela informa o objetivo, as entradas permitidas, os controles aplicáveis, as operações esperadas, o resultado devido e as possibilidades de continuidade.

Uma instrução comum pode dizer:

Analise estes documentos.

Uma UCC precisa tornar a responsabilidade mais precisa:

Perguntas do contrato
├─ Qual é o objetivo?
├─ Quais informações podem ser usadas?
├─ Quais limites devem ser respeitados?
├─ O que precisa ser produzido?
└─ Como reconhecer uma conclusão válida?

A LLM continua livre para interpretar e resolver o problema. A arquitetura define a autoridade e as obrigações dessa execução.

3. Estrutura fundamental

A AAR possui três elementos contratuais e um executor:

Estrutura fundamental
├─ 1. Compor: Kernel + Perfil + UCC
├─ 2. Formar: contrato ativo
├─ 3. Executar: LLM
└─ 4. Produzir: resultado e continuidade

Em termos diretos:

Kernel: reúne as regras comuns a toda a arquitetura;
Perfil: reúne as políticas compartilhadas por uma capacidade ou domínio;
UCC: define uma operação específica;
LLM: interpreta o contrato e executa a operação.

A AAR foi concebida para capacidades executadas por LLM. A LLM pode utilizar fontes e ferramentas autorizadas, mas permanece como executora responsável pela operação contratada.

3.1 Kernel

O Kernel estabelece as regras que não devem mudar a cada nova capacidade. Ele fornece um vocabulário comum para responsabilidade, autoridade, execução, resultado e continuidade.

Podem pertencer ao Kernel regras sobre:

prioridade entre instruções;
tratamento de entradas;
validade de resultados;
estados e transições;
publicação e continuidade;
compatibilidade entre componentes.

O Kernel não contém o conhecimento material de cada domínio. Ele define como uma capacidade regulada funciona.

3.2 Perfil

O Perfil reúne regras compartilhadas por um conjunto de operações relacionadas. Ele fica entre o Kernel geral e cada UCC específica.

O Perfil pode definir:

identidade da capacidade maior;
fontes e recursos autorizados;
políticas comuns;
limites compartilhados;
convenções e regras de domínio.

Sua função é evitar que a mesma política precise ser repetida em todas as UCCs.

3.3 UCC

A UCC define uma responsabilidade específica. Ela não é apenas uma pergunta ou instrução: é a descrição estruturada de uma operação e de suas condições de validade.

Em termos simples:

Kernel define as regras gerais. Perfil define a política compartilhada. UCC define o trabalho. LLM executa.

Essas camadas obedecem a uma ordem. Uma camada mais específica pode detalhar ou restringir a anterior, mas não pode eliminar suas regras fundamentais.

Ordem de especialização
├─ 1. Kernel — regras gerais
├─ 2. Perfil — especializa o Kernel
├─ 3. UCC — especializa o Perfil
└─ 4. LLM — executa o contrato

4. Anatomia de uma UCC

Toda UCC deve responder a seis perguntas:

UCC — Unidade Contratual de Capacidade
├─ Identidade — qual é a operação e qual é seu objetivo?
├─ Escopo — quais informações e recursos podem ser usados?
├─ Regulação — quais regras e limites devem ser observados?
├─ Execução — o que precisa ser feito?
├─ Resultado — o que deve existir ao final?
└─ Continuidade — o que acontece depois?

Identidade torna a unidade reconhecível. Define seu nome, seu objetivo e a responsabilidade que lhe pertence.

Escopo delimita as entradas, fontes, resultados anteriores, orientações e ferramentas que podem ser utilizados. Uma informação disponível no ambiente não está automaticamente autorizada.

Regulação reúne controles, proibições, critérios e condições de conclusão ou bloqueio. Ela impede que liberdade cognitiva se transforme em autoridade irrestrita.

Execução descreve as operações e transformações necessárias. Deve ser clara o suficiente para delimitar o trabalho, sem converter o raciocínio da LLM em uma sequência rígida de microinstruções.

Resultado define o conteúdo obrigatório, os critérios de completude, as evidências necessárias e a forma de apresentação.

Continuidade informa se a operação terminou, deve aguardar, está bloqueada, precisa retornar a uma etapa anterior ou permite iniciar outra UCC.

4.1 Representação modular da UCC

Uma UCC pode ser representada concretamente como um módulo. O módulo organiza o contrato da operação e torna visível a relação entre regras, entradas, ações, entregas e continuidade.

Kernel
└─ perfil da família
   └─ módulo
      ├─ controles do módulo
      ├─ entradas e views da rota ativa
      ├─ núcleos de entrega, em ordem
      │  ├─ objetivo local
      │  ├─ ações materiais
      │  ├─ controles locais
      │  └─ entregas, em ordem
      │     ├─ contrato de conteúdo
      │     └─ renderização
      └─ fechamento e próximo passo

Nesse esquema:

família é um conjunto de operações que compartilham finalidade e Perfil;
rota ativa é o caminho de execução aplicável à situação atual;
views são resultados publicados por operações anteriores e autorizados como entrada;
núcleo de entrega reúne objetivo, ações, controles e entregas de uma parte coerente do trabalho;
fechamento registra o resultado da operação e a continuidade permitida.

O módulo não é uma unidade diferente da UCC. É a forma estruturada pela qual a UCC pode ser declarada e executada.

5. Princípios arquiteturais

5.1 Liberdade de raciocínio

A LLM pode interpretar o problema, escolher uma estratégia, aprofundar aspectos relevantes e formular o resultado. A UCC regula a operação, não a cadeia interna de raciocínio.

5.2 Responsabilidade delimitada

Cada UCC possui uma responsabilidade própria. Ela não deve assumir silenciosamente o trabalho de outra unidade apenas porque a LLM seria capaz de realizá-lo.

5.3 Autoridade explícita

Ser capaz de fazer algo não significa estar autorizado a fazê-lo.

capacidade da LLM não equivale a autoridade da operação

A autoridade decorre do Kernel, do Perfil e da UCC aplicáveis.

5.4 Resultado contratado

Uma resposta só encerra a operação quando satisfaz o resultado exigido.

resposta produzida não equivale a operação concluída

5.5 Continuidade explícita

O encerramento deve indicar um estado compreensível pela arquitetura. A continuidade não pode depender apenas de uma interpretação informal do texto produzido.

6. Fronteira entre autonomia e contrato

Dentro do contrato, a LLM pode:

interpretar o problema;
escolher uma estratégia compatível;
aprofundar aspectos relevantes;
reconciliar informações autorizadas;
formular conclusões e adaptar a linguagem;
usar ferramentas permitidas.

A LLM não pode:

redefinir a responsabilidade da UCC;
ampliar o escopo autorizado;
ignorar um controle aplicável;
considerar cumprida uma obrigação pendente;
criar um estado não previsto;
assumir indevidamente a responsabilidade de outra UCC.

A síntese dessa fronteira é:

Liberdade cognitiva dentro de autoridade contratual.

7. Ciclo de execução

Uma execução percorre funções reconhecíveis:

Ciclo de execução
├─ 1. Carregar o contrato
├─ 2. Identificar a UCC ativa
├─ 3. Resolver o escopo autorizado
├─ 4. Verificar controles
├─ 5. Executar a operação
├─ 6. Formar o resultado
├─ 7. Validar o resultado
└─ 8. Publicar e definir a continuidade

Se uma condição necessária não for satisfeita, a arquitetura deve produzir um estado correspondente, como espera, bloqueio ou retorno. Ela não deve apresentar como concluída uma operação incompleta.

Esse ciclo descreve funções mínimas. Ele não exige que a LLM siga uma única ordem interna de raciocínio.

7.1 AAR como máquina abstrata de execução

O ciclo permite formular a AAR como uma máquina abstrata de execução. A expressão não designa um equipamento ou programa específico. Ela indica que a arquitetura define entradas, funções de controle, resultados e mudanças de estado sem determinar o raciocínio interno da LLM.

Máquina abstrata de execução
├─ 1. Receber: contrato + estado atual
├─ 2. Preparar: operação
├─ 3. Executar: cognição pela LLM
├─ 4. Formar: resultado candidato
├─ 5. Validar: contrato
└─ 6. Produzir: resultado publicado + novo estado

No desdobramento algorítmico da arquitetura, a execução cognitiva fica entre duas camadas de controle:

Execução da UCC
├─ 1. Aplicar: controle algorítmico anterior
├─ 2. Executar: operação livre pela LLM
└─ 3. Aplicar: controle algorítmico posterior

O controle anterior prepara o contrato, resolve o escopo e verifica as condições iniciais. O controle posterior verifica o resultado, determina sua validade e define a continuidade. A LLM permanece como executora da capacidade.

A AAR é uma máquina de estados contratuais cujo operador cognitivo é uma LLM.

7.2 Três funções algorítmicas

A execução completa pode ser decomposta em três funções:

Compor o contrato: combinar Kernel, Perfil e UCC segundo sua ordem de autoridade.
Executar a UCC: fornecer contrato e escopo à LLM e validar o resultado produzido.
Resolver a continuidade: transformar resultado e estado atual em publicação, retorno, espera, bloqueio ou encerramento.

Execução completa
├─ 1. Compor: Kernel + Perfil + UCC
├─ 2. Formar: contrato ativo
├─ 3. Executar: LLM
├─ 4. Produzir: resultado candidato
└─ 5. Resolver: validação e continuidade

Algumas verificações podem ser objetivas: presença de entradas, compatibilidade, fontes autorizadas, componentes obrigatórios, estados permitidos e forma de publicação. A correção material, a suficiência das evidências e a qualidade da análise exigem critérios de domínio e podem depender de avaliação adicional por LLM ou decisão humana.

O Apêndice apresenta o algoritmo conceitual completo.

8. Composição de capacidades

Uma UCC pode representar uma operação completa ou integrar uma capacidade maior. Quando várias UCCs são combinadas, cada uma preserva sua responsabilidade.

Composição do Perfil
├─ UCC 1
│  └─ produz: Resultado 1
├─ UCC 2
│  └─ produz: Resultado 2
└─ UCC 3
   └─ produz: Resultado 3

Regra de continuidade
└─ cada resultado autoriza outra UCC ou o encerramento

O resultado de uma UCC pode tornar-se entrada autorizada de outra. Essa passagem deve ser definida pela arquitetura; não deve depender de contexto presumido.

A composição permite dividir uma capacidade complexa em responsabilidades menores sem tentar dividir o raciocínio interno de cada operação.

À medida que o sistema cresce, surgem perguntas adicionais:

qual resultado está vigente;
qual UCC pode consumi-lo;
quando a próxima operação pode começar;
o que fazer diante de bloqueio ou resultado inválido;
quando uma operação anterior precisa ser refeita.

Novos mecanismos arquiteturais devem surgir para responder a necessidades como essas, não apenas para aumentar o nível de formalização.

9. Arquitetura e domínio

A arquitetura define a forma da capacidade. O domínio fornece seu conteúdo.

A arquitetura:

delimita responsabilidades;
distribui autoridade;
organiza execução e continuidade;
define como validar resultados.

O domínio:

define quais operações são necessárias;
fornece conhecimentos e fontes;
estabelece critérios materiais;
determina quais resultados são úteis.

AAR
└─ estrutura compartilhada
   ├─ Domínio A
   │  └─ Perfil A
   │     └─ UCCs A
   ├─ Domínio B
   │  └─ Perfil B
   │     └─ UCCs B
   └─ Domínio C
      └─ Perfil C
         └─ UCCs C

Engenharia, pesquisa, compliance, operações, finanças, compras e atendimento podem exigir conhecimentos e resultados muito diferentes. A hipótese da AAR é que essas diferenças podem ser expressas por Perfis e UCCs próprios sem alterar seus princípios fundamentais.

Teste de generalidade

Um novo domínio pode ser representado por um novo Perfil e novas UCCs sem alterar as regras comuns do Kernel?

10. Como a arquitetura cria confiança

Regular não significa decidir tudo antecipadamente. Significa tornar observáveis os elementos que permitem compreender e avaliar uma operação.

Uma execução regulada deve permitir identificar:

qual UCC estava ativa;
quais regras e políticas eram aplicáveis;
quais entradas estavam autorizadas;
quais controles foram considerados;
qual resultado foi produzido;
por que a operação foi concluída, bloqueada ou devolvida;
qual continuidade foi habilitada.

Essa visibilidade favorece:

modularidade: capacidades complexas podem ser divididas em responsabilidades claras;
rastreabilidade: torna-se possível relacionar operação, contrato e resultado;
isolamento: uma UCC não corrige nem absorve silenciosamente outra;
liberdade cognitiva: a LLM pode lidar com situações não enumeradas;
controle explícito: autoridade, limites e continuidade permanecem claros;
especialização: domínios diferentes usam a mesma base com políticas próprias;
evolução: componentes podem mudar sem reconstruir todo o sistema.

O registro da execução deve abranger contratos, eventos e resultados. Ele não exige exposição da cadeia interna de raciocínio da LLM.

11. Simplicidade e maturidade

A arquitetura deve conter o menor conjunto de conceitos necessário para produzir autonomia útil, responsabilidade delimitada, resultados verificáveis e continuidade governável.

Uma nova estrutura só deve ser introduzida quando representar uma função distinta que não possa ser expressa pelos elementos existentes.

A maturidade da AAR pode ser avaliada por perguntas simples:

Cada UCC possui responsabilidade reconhecível?
Escopo e autoridade estão explícitos?
Um resultado incompleto pode ser identificado?
O encerramento produz um estado claro?
UCCs podem ser combinadas sem responsabilidade oculta?
Domínios diferentes cabem na mesma arquitetura?
Uma mudança de política compartilhada pode ser feita sem repetir regras em todas as unidades?

Quanto mais consistentemente essas perguntas puderem ser respondidas, maior será a evidência de que a arquitetura é geral, compreensível e governável.

12. Síntese

A Arquitetura Agêntica Regulada organiza capacidades executadas por LLM mediante contratos explícitos.

O Kernel fornece as regras comuns. O Perfil reúne a política compartilhada. A UCC define uma operação. A LLM interpreta o contrato, executa a capacidade e produz um resultado com continuidade identificável.

Em sua formulação algorítmica, a AAR prepara e valida as condições da operação sem programar o raciocínio usado pela LLM para resolvê-la.

AAR em operação
├─ 1. Aplicar: Kernel
├─ 2. Especializar: Perfil
├─ 3. Delimitar: UCC
├─ 4. Executar: LLM
├─ 5. Produzir: Resultado
└─ 6. Definir: Continuidade

A inteligência permanece livre para resolver o problema; a arquitetura determina o contrato sob o qual essa capacidade pode operar.

Apêndice — Algoritmo conceitual de execução

O algoritmo abaixo expressa as funções mínimas de uma execução regulada. Ele não define uma implementação única nem transforma a LLM em executor determinístico.

ALGORITMO EXECUTAR_UCC

ENTRADAS
- Kernel
- Perfil
- UCC
- estado atual
- fontes, resultados e ferramentas disponíveis

1. COMPOR O CONTRATO
   1.1 carregar Kernel, Perfil e UCC
   1.2 verificar sua compatibilidade
   1.3 aplicar a ordem de autoridade
   1.4 formar o contrato ativo

2. RESOLVER O ESCOPO
   2.1 identificar a rota ativa
   2.2 selecionar somente entradas autorizadas
   2.3 carregar resultados anteriores permitidos
   2.4 disponibilizar ferramentas autorizadas

3. VERIFICAR AS CONDIÇÕES INICIAIS
   3.1 avaliar controles do módulo
   3.2 identificar impedimentos
   3.3 se houver impedimento:
       - produzir o estado correspondente
       - registrar a causa
       - encerrar sem publicar resultado inválido

4. EXECUTAR A CAPACIDADE
   4.1 apresentar contrato e escopo à LLM
   4.2 percorrer os núcleos de entrega na ordem
   4.3 permitir liberdade de raciocínio dentro do contrato
   4.4 formar o resultado candidato

5. VALIDAR O RESULTADO
   5.1 conferir entregas obrigatórias
   5.2 verificar critérios de completude
   5.3 verificar controles locais e gerais
   5.4 validar conteúdo e forma de publicação

6. TRATAR RESULTADO INVÁLIDO
   6.1 identificar a obrigação não satisfeita
   6.2 aplicar somente uma resposta prevista:
       - nova tentativa limitada
       - aguardar informação
       - bloquear
       - retornar a outra UCC
       - solicitar decisão humana

7. PUBLICAR RESULTADO VÁLIDO
   7.1 registrar o resultado
   7.2 atribuir identidade e revisão
   7.3 impedir alteração silenciosa

8. DEFINIR A CONTINUIDADE
   8.1 determinar o estado resultante
   8.2 identificar a próxima transição permitida
   8.3 habilitar a UCC seguinte, retornar ou encerrar

9. REGISTRAR A EXECUÇÃO
   9.1 registrar o contrato aplicado
   9.2 registrar as entradas utilizadas
   9.3 registrar os controles avaliados
   9.4 registrar o resultado publicado
   9.5 registrar o estado e a continuidade

SAÍDAS
- resultado publicado ou estado sem publicação
- novo estado
- próxima transição permitida
- registro da execução

Em forma compacta:

EXECUTAR_UCC(Kernel, Perfil, UCC, Estado):

    Contrato ← compor(Kernel, Perfil, UCC)

    se Contrato for incompatível:
        retornar CONFIGURACAO_INVALIDA

    Escopo ← resolver_entradas_autorizadas(Contrato, Estado)

    Condição ← avaliar_controles_iniciais(Contrato, Escopo)

    se Condição impedir execução:
        retornar estado_correspondente(Condição)

    Candidato ← LLM.executar(Contrato, Escopo)

    Validação ← validar(Candidato, Contrato)

    se Validação falhar:
        retornar tratar_falha(Validação, Contrato)

    Resultado ← publicar(Candidato)

    NovoEstado ← resolver_continuidade(
        Contrato,
        Resultado,
        Estado
    )

    registrar_execução(
        Contrato,
        Escopo,
        Resultado,
        NovoEstado
    )

    retornar Resultado, NovoEstado