Essa pergunta começou a aparecer cada vez mais.

Não porque eu estivesse tentando construir uma IA superautônoma.

Na verdade, foi quase o contrário.

Quanto mais capacidade eu colocava no sistema, mais eu percebia que a palavra autonomia era perigosa quando usada de maneira vaga.

• Pode pesquisar.
• Pode analisar.
• Pode escrever.
• Pode criar estrutura.
• Pode alterar uma entidade.
• Pode iniciar um workflow.
• Pode enviar uma mensagem.
• Pode publicar.
• Pode mexer num preço.
• Pode alterar um contrato.
• Pode tomar uma decisão financeira.

Todas essas coisas são "ações".

Mas definitivamente não deveriam ter o mesmo nível de liberdade.

Então comecei a pensar:

Autonomia para quê?

Essa pergunta mudou bastante coisa.

01Porque não existe "agente autônomo" de forma absoluta

Pelo menos não da maneira que eu queria construir.

Dizer:

• agente_autonomo: true

me parecia quase irresponsável.

• Autônomo para ler?talvez
• Autônomo para pesquisar?provavelmente
• Autônomo para criar um rascunho?tudo bem
• Autônomo para publicar?depende
• Autônomo para movimentar dinheiro?calma
• Autônomo para excluir dados?talvez nunca

Então a autonomia começou a sair do agente e ir para a ação dentro de um contexto.

Isso ficou muito mais interessante.

02A pergunta certa começou a ser outra

Não:

Este agente é autônomo?

Mas:

Esta ação pode acontecer sem autorização neste contexto?

Parece uma mudança pequena.

Mas não é.

Porque agora entram:

• risco;
• valor;
• responsabilidade;
• tipo de entidade;
• regra;
• papel;
• histórico;
• impacto;
• reversibilidade.

Uma mesma ação pode ser automática num contexto e exigir aprovação em outro.

03Um exemplo simples

Imagine desconto comercial.

Até 5%: pode ser permitido automaticamente para determinado papel.

De 5% a 10%: talvez precise de aprovação do gestor.

Acima de 10%: talvez exija Financeiro ou direção.

Então não existe um campo dizendo simplesmente que pode dar desconto.

Existe alguma coisa muito mais parecida com uma regra que conhece o contexto.

04E isso me fez rever a ideia de agente inteligente

Porque inteligência não deveria ser medida apenas por:

Quantas coisas ele consegue fazer?

Talvez uma inteligência melhor saiba também:

Quando não deve fazer.

Isso me interessa muito.

Um agente percebe que consegue executar uma ação.

Mas também percebe:

• Não possuo autoridade.
• A informação está incompleta.
• Esta decisão é irreversível.
• Existe conflito entre duas regras.
• Preciso perguntar.

Isso, para mim, é muito mais inteligente do que agir o tempo inteiro.

05Foi aí que os gates ganharam um significado maior

Eu já vinha pensando em gates dentro de FLOW.

Mas eles começaram a representar uma filosofia operacional.

O fluxo anda.

Até determinado ponto.

Então pergunta:

• Tenho informação suficiente?
• Risco aceitável?
• Autoridade suficiente?
• Evidência validada?
• Humano precisa participar?

Se sim, continua.

Se não, para.

Essa distinção me parece importante.

06Eu comecei a gostar menos da expressão "human in the loop"

Não porque esteja errada.

Mas às vezes ela parece colocar o humano como se fosse um obstáculo dentro de um processo que idealmente deveria ser totalmente automático.

Eu não quero necessariamente isso.

Em alguns casos, o humano é exatamente quem possui a responsabilidade.

A máquina prepara.

Organiza.

Pesquisa.

Resume.

Calcula.

Sugere.

E então alguém decide.

Não porque a IA "não conseguiu".

Mas porque aquela decisão deve continuar pertencendo a alguém.

Essa diferença é enorme.

07Responsabilidade não pode ser terceirizada para personalidade

Imagine:

Athena decidiu.

Não.

• O que isso significa juridicamente?
• Operacionalmente?
• Quem autorizou Athena a decidir?
• Com quais regras?
• Sobre qual tipo de assunto?
• Qual modelo estava rodando?
• Qual versão?
• Que dados utilizou?

Esse tipo de frase começa a ficar perigoso muito rápido.

Então eu precisava conseguir separar:

• AGENTEfez uma análise
• DECISÃOfoi tomada por alguém ou por uma regra autorizada
• WORKFLOWexecutou
• SISTEMAregistrou

Essa separação parece burocrática até o dia em que alguma coisa dá errado.

Aí ela vira ouro.

08Foi aí que auditoria entrou definitivamente no projeto

Não como fiscalização.

Como memória de responsabilidade.

• Quem fez?
• O quê?
• Quando?
• Por quê?
• Com base em quê?
• Qual era o estado anterior?
• Qual ficou depois?
• Quem aprovou?

Isso vale para humano.

• Vale para agente.
• Vale para workflow.
• Vale para integração.
• Vale para sistema externo.

Eu queria conseguir abrir uma alteração importante e enxergar a história dela.

09Uma mudança precisa carregar sua origem

Imagine:

• PREÇOR$ 1.000 → R$ 850

• Quem alterou — um vendedor, um workflow, uma promoção, um agente, uma integração?
• Qual regra permitiu?
• Por qual motivo?
• Por quanto tempo?

Isso não pode ser apenas um campo dizendo a hora em que alguma coisa foi atualizada.

A mudança tem contexto.

De novo:

• evento.
• relação.
• histórico.
• governança.

As mesmas coisas voltam.

10E autonomia começou a depender também de reversibilidade

Essa ideia eu gosto muito.

Nem toda ação de alto impacto é igualmente perigosa.

Criar um rascunho é altamente reversível.

Enviar um e-mail já é menos.

Publicar conteúdo é reversível, mas deixa rastros.

Excluir definitivamente uma entidade pode ser muito mais delicado.

Movimentar dinheiro pode ser irreversível em determinadas situações.

Então comecei a pensar que o sistema deveria levar em conta o quão fácil é desfazer.

• AÇÃO
• IMPACTO
• RISCO
• REVERSIBILIDADE
• AUTORIDADE NECESSÁRIA

Isso permite uma autonomia muito mais inteligente.

11E também existe custo

Às vezes o risco é baixo, mas o custo é alto.

Imagine convocar quinze agentes, pesquisar a web inteira, consultar cinco bases e rodar três modelos caros para responder:

Qual é o telefone deste fornecedor?

Não.

A melhor arquitetura talvez use a menor capacidade necessária.

Isso começou a virar uma espécie de princípio para mim:

Parece contraintuitivo numa época em que todo mundo quer colocar o maior modelo em tudo.

Mas faz sentido.

• se regra resolveuse regra.
• se busca resolveuse busca.
• se uma skill resolveuse skill.
• se precisa raciocinaraí sim chame mais inteligência.

12Isso começou a mudar Athena também

Athena não precisa convocar o Panteon inteiro.

Precisa encontrar uma boa composição.

Talvez um agente.

Uma skill.

Um workflow.

Ou nenhum agente.

Essa última opção é importante.

Às vezes não precisamos de IA.

Esse sistema também precisava saber disso.

13E comecei a imaginar níveis de atuação

Algo como:

• NÍVEL 0observar
• NÍVEL 1sugerir
• NÍVEL 2criar rascunho
• NÍVEL 3executar ação reversível
• NÍVEL 4executar mediante regra
• NÍVEL 5executar mediante aprovação
• NÍVEL 6ação restrita

Não necessariamente com essa escala fixa.

Mas a ideia é útil.

14Isso começou a dar outra função para o papel

Pessoa tem papel.

Agente também pode ter papel.

Papel define parte da responsabilidade.

Responsabilidade define parte da autoridade.

Então:

• AGENTE
• assumePAPEL
• possuiRESPONSABILIDADES
• permiteAÇÕES
• condicionada_porREGRAS

Agora conseguimos construir algo mais sério.

Não apenas "este agente pode acessar banco".

Mas:

• Pode ler quais entidades?
• Pode alterar quais propriedades?
• Em quais estados?
• Dentro de qual workflow?
• Com qual limite?

Isso é governança operacional.

15E aí comecei a enxergar uma coisa curiosa

A arquitetura de agentes começou a parecer bastante com arquitetura organizacional.

• Papel.
• Responsabilidade.
• Autoridade.
• Processo.
• Escalonamento.
• Governança.

Não porque agentes são pessoas.

Mas porque o problema de coordenar capacidades possui algumas semelhanças.

E empresas já passaram séculos tentando resolver isso.

Talvez não precisemos reinventar absolutamente tudo só porque agora uma das partes é IA.

16Hierarquia também começou a ganhar outro significado

Eu não queria uma hierarquia simplesmente porque empresas têm hierarquia.

Mas precisava de escalonamento.

Um agente encontra um problema.

Não tem autoridade.

Chama outro? Humano? Athena? Um workflow específico?

Então hierarquia poderia ser:

Isso é bem mais útil.

17E isso acabou se conectando com risco empresarial

• Jurídico.
• Financeiro.
• Privacidade.
• Segurança.
• Marca.
• Operação.

Nem todo domínio pode ter as mesmas regras de autonomia.

Criar uma ideia de conteúdo é uma coisa.

Assinar contrato, outra.

Então o próprio tipo de entidade e módulo pode influenciar a governança.

• COREprecisa conhecer o que existe.
• FLOWprecisa saber o que está mudando.
• OSprecisa saber quem está executando.
• ONpode interpretar.

Governança atravessa tudo.

18Foi aí que percebi que governança não poderia ser um módulo isolado

Ela pode ter núcleo próprio.

Documentação.

Políticas.

Regras.

Mas, conceitualmente, precisava atravessar o sistema.

• Quem pode visualizar?
• Quem pode editar?
• Quem pode aprovar?
• Quem pode executar?
• Quem pode criar uma nova estrutura?
• Quem pode ativar uma skill?
• Quem pode publicar um workflow?
• Quem pode alterar o DNA?

Se a resposta estiver escondida em cada pedaço de código, o sistema nunca vai ser realmente governável.

19Uma regra também pode ser entidade

Essa descoberta foi natural.

• nomeAprovação de desconto
• condiçãodesconto acima de 10%
• aplica_aOportunidade
• exigeAprovação Financeira
• vigênciaperíodo em que vale
• versãoqual redação está no ar

imagem pendente placa · governanca-regra captura de tela · largura total · proporção 16:10

Agora a regra pode mudar.

Ter histórico.

Ter responsável.

Ser referenciada.

Ser auditada.

E FLOW consegue operar sobre ela.

Isso é muito mais poderoso do que escrever dezenas de condicionais invisíveis no código.

20E aí entra uma coisa que sempre me incomodou em software empresarial

Muita regra de negócio só existe na cabeça de quem programou.

Ou enterrada no código.

Por que o sistema não deixa fazer isso?

"Porque não deixa."

Não.

Eu quero conseguir chegar à regra.

Ver.

Entender.

• Quem definiu?
• Qual motivo?
• Ainda vale?

Isso transforma regra em parte da memória institucional.

21O mesmo vale para exceções

Uma regra pode dizer:

Exige três cotações.

Ótimo.

Mas existe fornecedor exclusivo.

Então a exceção precisa existir.

Não como gambiarra.

Como decisão governada.

• REGRA3 cotações
• EXCEÇÃOfornecedor exclusivo
• JUSTIFICATIVApor que abriu-se mão da regra
• APROVADORquem assumiu
• VALIDADEaté quando vale

Agora o sistema sabe que houve exceção.

E, se isso acontece cinquenta vezes, talvez ON pergunte:

Essa exceção ainda é exceção?

Pergunta maravilhosa.

22Governança começa a produzir aprendizado

Isso eu gosto muito.

Uma regra foi criada.

Muitas exceções aparecem.

Talvez a regra esteja errada.

Talvez o processo tenha mudado.

Talvez o setor funcione diferente.

A governança também pode evoluir.

Não precisa virar pedra.

23E isso me levou a uma ideia meio desconfortável

• A IA pode ajudar a escrever regras.
• Pode ajudar a detectar conflito.
• Pode sugerir uma exceção.
• Pode mostrar impacto.

Mas provavelmente não deveria ser dona da governança.

Pelo menos não sozinha.

Porque governança é também decisão sobre valores.

• Risco aceitável.
• Responsabilidade.
• Prioridade.
• Aquilo que uma organização considera permitido.

Isso não é apenas inferência.

24E aí a filosofia apareceu novamente

Eu tinha começado com perguntas sobre o que existe.

• ontologiao que existe?
• epistemologiacomo sabemos?
• movimentoo que muda?
• éticao que deve ser permitido?

Essa última é outra classe de pergunta.

Não é ontologia.

Não é epistemologia.

Começa a tocar ética e política organizacional.

• Quem pode fazer?
• Quem decide?
• Quem responde pelas consequências?

A inteligência artificial não elimina essas questões.

Talvez torne todas elas ainda mais importantes.

25Isso começou a mudar até minha forma de pensar o Panteon

Porque ali também havia autoridade simbólica.

Colocar um nome histórico numa interface cria uma sensação de autoridade.

Sócrates disse.

Einstein disse.

Sun Tzu disse.

Cuidado.

Um agente inspirado neles não é aquela pessoa.

E aquela pessoa também poderia estar errada.

Então eu queria uma postura visual e textual que preservasse isso.

Ou, quando houver fonte: segundo determinada obra ou referência.

Isso muda a relação com autoridade.

26Porque o nome de alguém nunca deve substituir a evidência

Isso acabou virando quase uma regra editorial.

E vale para o Referências.

Vale para o LAB.

Vale para o Panteon.

Vale para os artigos.

• Quem disse?
• Onde?
• Em qual contexto?
• Isso foi realmente dito?
• Ou é uma frase de internet atribuída à pessoa?

Esse tipo de coisa começou a importar muito para mim.

Porque se vamos construir uma biblioteca gigantesca de referências, ela precisa ser séria.

27E talvez essa seja a ponte para uma parte enorme do projeto

O conhecimento.

Até agora eu vinha falando de memória da empresa.

• Conhecimento dos agentes.
• Documentação.
• Fontes.
• Panteon.
• Setores.
• Artigos.
• Referências.

Mas tudo isso começou a formar uma coisa maior.

Uma base de conhecimento que não pertencia apenas a um agente.

Nem apenas a uma empresa.

Uma camada onde pessoas, obras, conceitos, lugares, tecnologias, setores, documentos, ideias e fontes podiam ser relacionadas.

Aquela ideia que antes aparecia no Obsidian começou a voltar numa escala completamente diferente.

E aí eu comecei a imaginar:

E se o LAB não fosse apenas onde publicamos conteúdo? E se fosse uma das portas públicas para todo esse conhecimento?

Um artigo cita uma pessoa.

Essa pessoa possui obras.

Uma obra possui conceitos.

Um conceito aparece em outros artigos.

Um setor utiliza determinado conceito.

Um agente tem aquela obra na sua base.

Uma empresa está estudando aquele setor.

Tudo relacionado.

E aquela velha ideia de um site chamado Referências começou a fazer muito mais sentido.

Porque talvez conhecimento também precisasse deixar de morar em páginas isoladas.

Talvez uma referência pudesse ser entidade.

• Uma obra.
• Um conceito.
• Uma cidade.
• Uma tecnologia.
• Uma descoberta.
• Uma fonte.

E se isso fosse verdade, então o próximo passo da archē não seria simplesmente guardar mais informação.

Seria começar a construir uma coisa muito mais ambiciosa:

---

Esta série acompanha as perguntas, tecnologias, erros e ideias que foram transformando a archē de uma estrutura de organização em um sistema de contexto.