Depois de chegar até aqui, uma coisa começou a ficar quase óbvia.

Se eu quero compreender:

• a empresa;
• o setor;
• o nicho;
• os produtos;
• os clientes;
• as pessoas;
• os processos;
• as metas;
• as dores;
• as regras;
• as relações;

eu preciso começar de algum lugar.

E normalmente software começa assim:

• Nome da empresa.
• CNPJ.
• Número de funcionários.
• Segmento.
• Telefone.
• Próximo.

Eu não queria isso.

Não porque esses dados não sejam importantes.

São.

01Então o onboarding começou a mudar completamente de significado

Eu comecei a imaginar a primeira entrada na archē quase como uma entrevista.

Não uma entrevista de emprego.

Nem aquele chatbot irritante que tenta transformar qualquer resposta em lead.

Uma investigação.

A primeira pergunta poderia ser absurdamente simples:

Me conte sobre sua empresa.

E deixa falar.

Sem cinquenta campos na frente.

A pessoa pode dizer:

• a pessoaTenho uma empresa pequena de arquitetura. Somos seis pessoas. Fazemos principalmente projetos residenciais de alto padrão. A maior parte dos clientes chega por indicação. Estamos tentando crescer, mas eu continuo centralizando quase tudo.

Olha a quantidade de coisas escondidas nessa frase.

02Para um formulário, isso é texto

Para a archē, isso pode começar a ser estrutura.

Mas atenção.

Nem tudo que a IA extraiu é fato.

A pessoa disse que centraliza quase tudo.

Eu transformei isso em hipótese de dependência do fundador.

São coisas diferentes.

Então o sistema precisa saber distinguir.

Isso ficou importantíssimo.

03A conversa produz fatos e hipóteses ao mesmo tempo

Agora podemos perguntar:

Quando você diz "a maior parte", estamos falando de quanto aproximadamente?

A resposta melhora a entidade.

Essa é a conversa que eu quero.

04Foi aí que Leteia começou a encontrar um papel muito bonito

Eu já vinha criando personagens.

Mas alguns começaram a ganhar funções realmente estruturais.

Leteia poderia ser a responsável pela descoberta inicial.

Não a dona da verdade.

A entrevistadora.

Aquela que pergunta, escuta, organiza, percebe que alguma coisa ficou incompleta — e continua.

• LeteiaVocê falou bastante sobre crescimento, mas ainda não entendi o que crescimento significa para você.

Essa é uma pergunta excelente.

Porque "quero crescer" não é objetivo suficiente.

• Crescer o quê?
• Receita?
• Lucro?
• Equipe?
• Número de clientes?
• Ticket?
• Cobertura geográfica?
• Liberdade do fundador?

Talvez a pessoa diga:

• a pessoaNa verdade eu não quero aumentar muito a equipe. Quero ganhar mais sem precisar participar de tudo.

Pronto.

A empresa acabou de mudar diante do sistema.

O objetivo não era simplesmente crescimento.

05E essa pergunta muda tudo que vem depois

Porque agora não faz sentido recomendar imediatamente mais leads, mais campanhas, mais vendedores.

Talvez isso piore o problema.

Se a operação depende do fundador, colocar mais demanda dentro dela pode simplesmente aumentar o caos.

Esse é exatamente o tipo de coisa que eu quero que ON consiga perceber.

Isso é contexto.

06Métis poderia entrar procurando aquilo que não está evidente

Eu gosto da ideia de separar essas funções.

Leteia conduz.

Métis observa padrões, contradições e lacunas.

A pessoa diz que seu maior problema é Marketing.

Mas durante a conversa descobrimos:

• há muitos leads;
• a conversão é razoável;
• o gargalo acontece na elaboração da proposta;
• o fundador precisa aprovar todas;
• algumas demoram quatro dias.

• MétisExiste uma possível divergência entre o problema declarado e os sinais encontrados.

Não "você está errado".

Mas "vale investigar".

Isso é muito mais interessante.

07E Athena não precisa fazer tudo

Essa foi uma mudança importante na minha forma de pensar agentes.

No começo existe a tentação de criar Athena, a superinteligência que sabe tudo e coordena tudo.

Bonito.

Até você construir.

Depois vira um monstro.

Eu prefiro Athena como uma camada de coordenação e validação.

Ela recebe:

• o que foi descoberto;
• o que foi inferido;
• quais entidades foram propostas;
• quais relações surgiram;
• quais lacunas permanecem;
• quais especialistas podem ser úteis.

E pergunta:

• Isso é suficiente para avançar?
• Precisamos confirmar alguma coisa?
• Existe conflito?

Agora ela tem responsabilidade clara.

08O onboarding começa a funcionar como um pequeno conselho

• Leteiainvestiga
• Métisprocura padrões e lacunas
• Athenavalida e coordena
• Panteonentra quando alguma especialidade é necessária

Eu gosto disso.

Porque não precisamos colocar vinte agentes conversando para parecer sofisticado.

09E o setor entra silenciosamente na entrevista

A pessoa diz que tem uma pousada.

O sistema relaciona a empresa ao setor.

Agora existe conhecimento setorial disponível.

Não para presumir.

Para investigar.

• LeteiaVocês trabalham com tarifa única ou ela muda conforme período, dia da semana ou ocupação?
• a pessoaSegunda a quinta é um preço. Sexta a domingo outro. Feriados têm tabela própria.

Essa pergunta não surgiu magicamente.

Ela veio do contexto setorial.

Pronto.

Novas entidades e regras começaram a aparecer.

• TARIFA varia_porPERÍODO
• PERÍODOdias úteis · fim de semana · feriados

Isso pode terminar virando configuração real do produto.

A conversa está começando a modelar software.

10Essa parte me fascina

Porque o onboarding pode deixar de ser algo que fazemos antes de usar o sistema.

Ele já é uso do sistema.

A pessoa está falando sobre a empresa.

Enquanto isso, estamos construindo:

• entidades;
• relações;
• objetivos;
• hipóteses;
• regras;
• lacunas;
• perguntas;
• contexto.

Quando termina a entrevista inicial, eu não quero apenas "cadastro concluído com sucesso".

Quero alguma coisa parecida com:

Isto é o que entendemos até agora.

E mostrar.

11Um primeiro mapa da empresa

Alguns nós sólidos.

Confirmados.

Alguns pontilhados.

Hipóteses.

Alguns vazios.

Ainda precisamos entender.

12E eu quero que a pessoa possa corrigir a IA

Isso é essencial.

• Não. Nosso principal cliente não é esse.corrige
• Esse processo não funciona assim.corrige
• Essa pessoa não é responsável por isso.corrige

Ótimo.

A correção não é fracasso da IA.

É parte da construção do contexto.

Talvez inclusive seja registrada:

• HIPÓTESE INICIAL
• corrigida_porOBSERVADOR
• NOVO ENTENDIMENTO

Agora o sistema aprendeu sobre aquela empresa.

13E talvez esse seja um dos momentos mais importantes do onboarding

• AthenaAntes de continuar, quero confirmar se entendi sua empresa corretamente.

Isso muda a relação.

Em vez de fingir certeza, pede validação.

A pessoa olha para o mapa.

Ajusta.

Confirma.

Só depois avançamos.

14A entrevista também pode medir confiança

Algumas informações foram declaradas diretamente.

Outras foram inferidas.

Outras vieram de pesquisa externa.

Outras ainda são hipóteses.

Então o mapa pode carregar proveniência.

• RECEITAinformado pelo responsável
• CONCORRENTEpesquisa pública
• DORentrevista
• HIPÓTESEinferência do ON · aguardando validação

Agora o sistema não apenas sabe.

15E então podemos pesquisar a empresa

Com autorização e fontes legítimas.

• Site.
• Produtos públicos.
• Redes.
• Documentação fornecida.
• Informações públicas.
• Mercado.
• Concorrentes.
• Reviews.
• Setor.

A entrevista não precisa perguntar tudo que pode ser descoberto de maneira confiável.

Isso também é respeito pelo tempo da pessoa.

16O sistema chega preparado para a segunda conversa

Isso eu acho forte.

Primeira entrevista: descoberta.

Depois: pesquisa, estruturação, análise.

Na próxima entrada:

• AthenaNa nossa última conversa você disse que reduzir sua participação operacional era prioridade.
• e continuaAnalisei a estrutura que você compartilhou e encontrei três pontos que parecem depender diretamente de você.
• e entãoQuero validar isso antes de sugerir qualquer coisa.

Agora existe continuidade.

Não estamos começando outro chat.

Temos memória.

17Isso muda completamente a sensação de inteligência

Porque a IA não parece inteligente apenas porque escreve bonito.

Parece inteligente porque:

• lembra o que importa;
• relaciona;
• percebe lacunas;
• não pergunta novamente o que já sabe;
• distingue fato de hipótese;
• reconhece quando precisa confirmar.

Isso é muito mais próximo da experiência que eu quero.

18E aí o onboarding começa a encontrar os departamentos do CORE

Conforme a empresa vai sendo compreendida, algumas estruturas começam a aparecer.

• Comercial.
• Financeiro.
• Marketing.
• Administrativo.
• Operação.
• Projetos.
• Pessoas.
• Jurídico.
• Tecnologia.
• Clientes.

Mas eu não quero ativar tudo porque existe no framework.

Uma empresa de duas pessoas talvez não precise enxergar quinze departamentos na sidebar.

Isso seria absurdo.

19Ativação deveria seguir contexto

O CORE pode possuir um framework enorme por baixo.

Mas a empresa vê aquilo que faz sentido.

20E os módulos podem nascer progressivamente

• Talvez a empresa comece com Clientes, Projetos, Financeiro e Objetivos.
• Depois descobrimos uma necessidade de contratação. Ativamos Pessoas.
• Surge operação de contratos. Jurídico ganha relevância.
• Começa conteúdo. Marketing cresce.

O sistema pode acompanhar maturidade.

Não precisa aparecer inteiro no primeiro dia.

21Só que então surgiu uma pergunta técnica inevitável

Se cada empresa pode precisar de campos, relações, cards, views, processos, regras e módulos diferentes, como construir isso sem criar um sistema diferente para cada cliente?

Essa pergunta era enorme.

Porque existem dois extremos ruins.

Eu precisava de alguma coisa no meio.

22E foi aí que o DNA começou a ficar realmente importante

Eu já usava essa ideia.

Mas ela começou a ganhar um papel arquitetural muito maior.

Uma entidade possui um tipo.

Mas aquele tipo pode possuir uma definição.

• Quais campos?
• Quais relações?
• Quais validações?
• Quais views?
• Quais ações?
• Quais estados?
• Quais permissões?
• Quais componentes?

Em outras palavras: como essa entidade deve se comportar dentro daquele contexto?

Isso é o DNA.

23Imagine Cliente

Uma empresa simples talvez precise de nome, telefone, email, status e responsável.

Uma clínica pode precisar de outra estrutura.

Uma empresa B2B, outra.

Uma pousada, outra.

Mas eu não quero criar três códigos completamente diferentes para Cliente.

Quero um núcleo compartilhado e extensões contextuais.

24E o agente poderia ajudar a criar essas extensões

Essa parte parecia quase ficção quando comecei a imaginar.

Hoje já não parece tanto.

Durante a implantação descobrimos que uma empresa precisa controlar alguma coisa.

O sistema verifica.

• Existe campo equivalente?
• Existe entidade melhor?
• Existe relação já modelada?

Não?

Então um agente pode propor uma extensão.

Não sair criando qualquer campo automaticamente.

Propor.

• nometipo_reserva
• entidadeReserva
• tiposelect
• opçõesdireta · OTA · agência · corporativa
• origemidentificado durante onboarding
• justificativanecessário para segmentação operacional

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

• AGENTE PROPÕE
• ATHENA VALIDA
• HUMANO CONFIRMA
• A ESTRUTURA ENTRA

Isso é muito diferente de hardcode.

25E se não for um campo?

Essa pergunta é ainda melhor.

A pessoa pede:

Quero adicionar o fornecedor dessa reserva.

Talvez a resposta não seja criar um campo chamado fornecedor_reserva.

Talvez Fornecedor já seja entidade.

Então fazemos relação.

• RESERVA
• originada_porPARCEIRO

Esse é exatamente o tipo de decisão que eu quero que a arquitetura proteja.

Porque é muito fácil transformar qualquer necessidade em coluna.

E depois terminar com tabelas de 180 campos que ninguém entende.

26A IA pode ajudar a proteger a ontologia

A pessoa pede um campo.

ON pergunta:

Isso é realmente uma propriedade desta entidade ou estamos descobrindo outra entidade?

Essa pergunta parece pequena.

Mas é o tipo de coisa que mantém o sistema saudável.

Agora a IA não está apenas gerando formulário.

Está ajudando a modelar.

27E isso me levou diretamente à próxima fase

Porque, se o sistema consegue descobrir estruturas durante uma conversa e consegue combinar:

• DNA base;
• DNA setorial;
• DNA organizacional;
• relações;
• views;
• cards;
• regras;
• workflows;

talvez eu não precise mais pensar em software empresarial como uma coisa completamente fixa.

Não significa que cada usuário vai pedir um botão roxo e a IA vai reprogramar produção ao vivo.

Isso seria uma péssima ideia.

Significa algo muito mais controlado.

A estrutura pode se adaptar dentro de limites governados.

E essa ideia virou uma das partes que mais me entusiasmaram em todo o projeto.

Porque durante décadas fizemos algo muito estranho.

Compramos software.

Depois mudamos a empresa para caber nele.

Talvez agora seja possível inverter uma parte dessa relação.

Não construir qualquer coisa para qualquer pessoa.

Mas criar uma arquitetura suficientemente estruturada para perguntar:

---

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.