Essa pergunta mexeu profundamente com o que eu estava construindo.

Porque software empresarial sempre teve algum nível de personalização.

• Você escolhe módulos.
• Cria campos.
• Configura permissões.
• Monta dashboards.
• Define status.
• Instala plugins.
• Contrata alguém para customizar.

Eu fiz isso durante anos.

No WordPress, então, praticamente vivi disso.

Mas não era exatamente isso que eu estava imaginando.

Eu queria que a estrutura descoberta durante a implantação pudesse influenciar a própria forma como o sistema se apresenta e funciona para aquela organização.

Não de maneira irrestrita.

Não uma IA reescrevendo código em produção a cada conversa.

Mas dentro de uma arquitetura governada.

01Foi aí que o DNA deixou de ser apenas uma metáfora bonita

Comecei a pensar que cada tipo de entidade precisava carregar uma definição estrutural.

• propriedadeso que ela guarda
• relações permitidascom o que pode se conectar
• estadospor onde pode passar
• açõeso que dá para fazer com ela
• validaçõeso que não pode acontecer
• permissõesquem pode o quê
• viewscomo aparece
• cardscomo resume
• workflowso que dispara
• regraso que governa

O registro guarda o dado.

O DNA ajuda o sistema a entender como aquele tipo de coisa deve existir.

Essa diferença é enorme.

02Porque uma entidade não é apenas sua tabela

Projeto pode ter nome, descrição, responsável, status e data.

Mas isso não explica Projeto.

• Projeto possui objetivo.
• Etapas.
• Dependências.
• Decisões.
• Documentos.
• Pessoas.
• Tarefas.
• Riscos.
• Metas.
• Histórico.
• Talvez orçamento.
• Talvez cliente.
• Talvez produto.

O DNA começa a descrever esse universo.

03E eu queria que a interface fosse consequência disso

Essa foi uma virada importante.

Normalmente fazemos:

• BANCO
• BACKEND
• TELA PROGRAMADA

Eu comecei a imaginar:

• ENTIDADE
• DNA
• CONTEXTO
• PERMISSÃO
• VIEW

A tela deixa de ser completamente independente da estrutura.

Ela passa a ser uma representação daquela estrutura.

Isso me lembra muito o que eu tentava fazer no Obsidian.

Só que agora com uma interface que eu realmente consigo controlar.

04Uma entidade poderia ter várias views

Isso já estava no princípio desde muito cedo.

Projeto pode aparecer como card, lista, kanban, timeline, grafo, dashboard, calendário ou detalhe.

Não são sete projetos.

É o mesmo projeto.

A lente muda.

A entidade permanece.

Talvez essa seja uma das ideias mais persistentes de toda essa história.

05E cada setor poderia acrescentar uma camada

Voltando à pousada.

Existe um DNA base de Reserva.

Mas hotelaria pode acrescentar:

• hóspede;
• acomodação;
• check-in;
• check-out;
• canal;
• tarifa;
• ocupação;
• política de cancelamento.

• DNA BASE
• DNA SETORIAL
• CONFIGURAÇÃO DA EMPRESA

Não significa três bancos diferentes.

São camadas de contexto.

06E a empresa pode ter suas próprias particularidades

Duas pousadas.

Mesmo setor.

Mesmo nicho.

• Uma possui restaurante.a outra não
• Uma trabalha com eventos.a outra com turismo de experiência
• Uma aceita pets.a outra tem day use
• Uma tem três unidades.a outra tem seis chalés

Então o setor não determina a empresa.

Ele oferece uma base de investigação.

07O sistema começa amplo e vai ficando específico

• UNIVERSAL
• SETOR
• NICHO
• EMPRESA
• CONTEXTO

Quanto mais descemos, mais específica fica a estrutura.

Mas sem perder a origem.

Uma Reserva de hotelaria ainda pode compartilhar princípios com outras reservas.

Uma Pessoa continua Pessoa.

Um Documento continua Documento.

Essa herança conceitual é muito importante para não fragmentar tudo novamente.

08Foi aqui que CPTs voltaram com força

Eu já trabalhava há muito tempo com Custom Post Types no WordPress.

• JetEngine.
• Campos.
• Relações.
• Listings.
• Templates.

Aquilo sempre me interessou porque permitia separar conteúdo de apresentação.

Você criava Imóvel, Profissional, Serviço, Cidade, Evento.

Depois decidia como exibir.

A lógica era boa.

O problema era que eu queria levar isso muito mais longe.

09Eu comecei a pensar no CPT como tipo de entidade

Não apenas tipo de conteúdo.

Isso muda bastante.

Um tipo pode definir:

• schema;
• campos;
• relações;
• validações;
• ações;
• views;
• ícones;
• permissões;
• workflows.

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

Então uma necessidade nova pode começar como "precisamos controlar Certificados".

O sistema investiga.

• Certificado já existe?
• Existe algo equivalente?
• É Documento? É um subtipo de Documento?
• Precisa de entidade própria?
• Possui validade?
• Está relacionado a Pessoa, Empresa, Equipamento ou Regulação?

De repente "criar um CPT" vira uma decisão de modelagem.

10E isso pode ser assistido por IA

Aqui eu comecei a enxergar uma coisa realmente poderosa.

A pessoa descreveu a realidade.

O sistema ajudou a transformar em modelo.

11Mas eu não quero que a IA crie tudo imediatamente

Essa diferença é essencial.

Ela pode propor.

Mostrar.

Explicar.

Talvez até construir uma preview.

Mas existe governança.

Porque criar estrutura ruim também é fácil.

E com IA fica ainda mais fácil criar estrutura ruim muito rapidamente.

• NECESSIDADE
• ANÁLISE
• BUSCA POR EQUIVALÊNCIA
• PROPOSTA
• VALIDAÇÃO
• PREVIEW
• APROVAÇÃO
• PUBLICAÇÃO

Essa sequência protege o sistema.

12A busca por equivalência é talvez a parte mais importante

Antes de criar: isso já existe?

• alguém pede fornecedorjá existe Empresa com papel Fornecedor
• alguém pede responsável_financeirotalvez seja relação Pessoa–Empresa
• alguém pede data_ultima_alteracaojá existe no histórico de eventos

Essa inteligência arquitetural pode impedir uma quantidade absurda de lixo estrutural.

13Porque customização sem governança destrói sistemas

Eu já vi isso demais.

• telefone
• telefone_2
• telefone_novo
• whatsapp
• whatsapp_cliente
• celular
• telefone_celular

E ninguém sabe qual usar.

Ou:

• Cliente
• Clientes
• Cadastro Cliente
• Contato Cliente
• Pessoa Cliente

Tudo representando pedaços da mesma coisa.

Eu quero que Athena seja quase chata nessa hora.

• AthenaEspere. Antes de criar, vamos entender se isso já existe.

Isso economiza anos de bagunça futura.

14E o DNA pode carregar a origem da customização

Isso também ficou importante.

Um campo existe por quê?

• origemveio do CORE
• origemsetor_hotelaria
• origemorganização_X
• origemintroduzido por um módulo
• origemtrazido por uma integração

Agora consigo saber o que é padrão e o que é particular.

Isso facilita atualização, migração, auditoria — e até aprendizado setorial.

15Porque uma customização repetida pode revelar um padrão

Imagine que dez pousadas diferentes pedem algo parecido.

ON pode perceber que a estrutura está se repetindo.

LAB investiga.

Talvez aquilo não seja mais uma customização.

Talvez deva virar parte do DNA setorial.

Essa é uma das coisas que mais me interessam.

16E o caminho contrário também existe

Algo que achávamos universal pode não ser.

Talvez um campo esteja presente em todas as implementações iniciais.

Depois percebemos que só faz sentido para determinado nicho.

Então ele desce de camada.

Isso é importante porque não será.

17A interface também pode se adaptar

Não apenas os dados.

• vive de agendatalvez Agenda mereça destaque
• vive de projetos longosProjetos pode ser central
• é varejoProduto, Pedido e Estoque dominam

Por que todas deveriam receber exatamente a mesma sidebar?

Não deveriam.

18Mas existe uma diferença entre adaptável e imprevisível

Eu não quero que segunda-feira o Financeiro esteja do lado esquerdo e terça-feira desapareça porque a IA "otimizou a experiência".

Isso seria insuportável.

A adaptação precisa ser governada.

Sugestões podem ser dinâmicas.

A estrutura principal precisa preservar estabilidade.

19O sistema pode sugerir

• Você utiliza Projetos diariamente. Deseja fixá-lo na navegação principal?

Ótimo.

Não simplesmente mudar escondido.

Essa pequena diferença preserva agência humana.

De novo, o observador.

20E o design system entra aqui de um jeito que eu gosto muito

Porque eu já vinha construindo tokens.

• Cores.
• Tipografia.
• Espaçamento.
• Cards.
• Fundos.
• Sidebar.
• Topbar.
• Estados.
• Componentes.

Então uma nova view não precisa nascer visualmente do zero.

Ela utiliza a linguagem existente.

• ESTRUTURA
• COMPONENTES
• TOKENS
• VIEW

Isso significa que IA pode ajudar a compor interfaces sem inventar um produto visual novo toda vez.

Ela trabalha dentro de limites.

Exatamente como deveria acontecer com dados.

21O mesmo princípio serve para código

Isso ficou ainda mais evidente com Codex e ferramentas de engenharia.

Se o agente conhece componentes oficiais, schemas, paths, padrões, dependências e regras, ele consegue construir muito melhor.

A construção muda completamente.

Contexto novamente.

22E eu comecei a perceber que talvez o prompt estivesse ficando menos importante

Isso é meio engraçado vindo de alguém que passou anos escrevendo prompt.

Prompt continua importante.

Mas, quando o sistema possui contexto estruturado, eu não preciso colocar tudo dentro de uma instrução gigantesca.

O agente pode receber referências.

O prompt diz o que queremos fazer.

O sistema fornece o mundo onde aquilo está acontecendo.

Essa diferença é gigantesca.

23Talvez esse seja um dos maiores saltos entre chatbot e agente

Um chatbot recebe conversa.

Um agente operacional precisa receber:

• contexto;
• capacidade;
• limite;
• memória;
• objetivo;
• e saber onde registrar o resultado.

Sem isso, temos uma conversa sofisticada.

Não uma peça de sistema.

24Foi aí que o conceito de contexto começou a ficar quase tão importante quanto entidade

• entidadeO que é isso?
• relaçãoComo isso se conecta?
• eventoO que aconteceu?
• objetivoPara onde queremos ir?
• contextoO que dessas coisas importa agora?

Essa última pergunta é essencial.

Uma empresa pode ter milhões de entidades.

Não podemos entregar tudo ao modelo.

Nem ao usuário.

Precisamos selecionar.

25Contexto também é redução

Isso parece contraditório.

Eu passei meses tentando guardar mais informação.

Agora precisava aprender a não mostrar tudo.

Mas é exatamente isso.

Memória não significa carregar o passado inteiro a cada pergunta.

Significa conseguir recuperar aquilo que importa.

26E a interface funciona da mesma maneira

• O sistema pode ser enorme.a pessoa não vê tudo
• O framework pode ter dezenas de módulos.a empresa usa alguns
• Uma entidade pode ter cem relações.uma view mostra cinco

Não estamos escondendo realidade.

Estamos escolhendo uma lente.

Mais uma vez, o observador.

27Foi quando eu percebi que a personalização mais importante talvez não fosse visual

Isso é outra coisa.

28E isso conecta ME e CORE de uma maneira inesperada

Duas pessoas da mesma empresa podem observar a mesma entidade de formas diferentes.

É o mesmo Projeto.

Views diferentes.

A entidade permanece.

O observador muda.

A interface responde.

Agora archēME começa a ter implicações até dentro da empresa.

29E então a pergunta inicial ficou maior

Eu tinha começado perguntando se o software poderia aprender a forma da empresa.

Mas talvez fosse:

Essa segunda parte é essencial.

Porque um sistema que aceita qualquer estrutura vira bagunça.

A archē precisa ter princípios.

• Ontologia.
• Governança.
• Componentes.
• Schemas.
• Regras.
• Limites.

O cliente traz realidade.

O framework oferece estrutura.

Os dois negociam.

Isso é implantação.

30E talvez seja justamente aí que esteja a diferença entre produto e projeto sob medida

Eu não quero construir um software completamente novo para cada empresa.

Também não quero empurrar o mesmo software rígido para todas.

Quero uma terceira coisa.

• Um núcleo compartilhado.
• Extensível.
• Contextual.
• Governado.

E quando alguma necessidade ultrapassar aquilo que o framework consegue fazer?

Aí entra a forja.

• LABinvestiga
• OSconstrói
• COREincorpora quando fizer sentido
• FLOWcoloca em movimento
• ONobserva o resultado

O ciclo volta.

Foi aí que comecei a entender melhor o que significava dizer "traga sua empresa".

Não é apenas um CTA bonito.

É quase uma metodologia.

• Traga a realidade.
• Vamos modelar.
• Comparar com aquilo que já sabemos.
• Descobrir o que falta.
• Usar o que existe.
• Construir o que realmente precisa existir.
• E talvez rejeitar algumas coisas também.

Porque personalização não pode significar "o cliente pediu, faça".

Às vezes a resposta correta é: não deveríamos criar isso.

E explicar por quê.

31Quanto mais eu pensava assim, menos a archē parecia um SaaS tradicional

• Mas também não era uma software house.
• Nem agência.
• Nem consultoria pura.
• Nem ERP.
• Nem plataforma de automação.

Ela usava pedaços de todas essas coisas.

E isso criava outro problema.

Um problema que eu estava começando a enfrentar justamente agora, no início de julho.

Se eu não consigo colocar a archē confortavelmente dentro de uma categoria conhecida...

como eu vou vender isso?

Porque o mercado precisa entender alguma coisa antes de decidir experimentar.

E talvez eu estivesse cometendo um erro típico de quem constrói: tentando explicar o que a tecnologia é.

Quando talvez devesse começar por algo muito mais simples.

---

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.