Olá!

Texto demonstrativo para apresentar este espaço de conteúdo,

Informações

ē.12 · O framework encontrou uma empresa. E depois encontrou outra.

Da pergunta à archē

ē.12 · O framework encontrou uma empresa. E depois encontrou outra.

Carlos Eduardo Tobias

17 de fevereiro de 2026
Parte 12

Quando comecei a perceber que setor não era uma categoria

Uma coisa é desenhar uma empresa abstrata. Outra é colocar uma clínica na frente do sistema. Depois uma pousada. Depois um agronegócio.

Quando a ideia do onboarding começou a ficar mais clara, aconteceu uma consequência natural.

Se eu queria que uma empresa contasse sua história, eu precisava estar preparado para ouvir histórias muito diferentes.

Porque uma coisa é desenhar uma empresa abstrata.

Outra é colocar uma clínica na frente do sistema. Depois uma pousada. Uma agência. Um escritório. Uma indústria. Uma empresa de turismo. Um negócio local. Agronegócio.

E perguntar:

Me explica como você funciona.

Foi aí que setor deixou de ser, para mim, aquele campo sem graça.

o campo setor saúde e isso não explica praticamente nada. o que existe por baixo SETOR NICHO MODELO DE NEGÓCIO produtosserviçospersonas processosregulaçõesdocumentos indicadorestecnologiasconcorrentes doresvocabulárioperguntas e perguntas que só fazem sentido naquele universo.
fig. 01À esquerda, uma palavra num campo de texto. À direita, o que aquela palavra deveria estar apontando — e nada disso cabe num select.

Dizer que uma empresa é de saúde não significa conhecê-la.

Nem dizer hotelaria, educação, varejo, tecnologia, construção, agronegócio.

São classificações úteis.

Mas eu queria descer.

Dentro de um setor existem nichos. Dentro dos nichos existem modelos de negócio.

Existem produtos, serviços, personas, processos, regulações, documentos, indicadores, tecnologias, concorrentes, dores, vocabulários. E perguntas que só fazem sentido naquele universo.

Foi aí que comecei a enxergar uma coisa maior:

Talvez setor também pudesse ser conhecimento estruturado.

01Uma clínica não é uma agência com outros nomes nos campos

Parece óbvio.

Mas muito software vertical funciona quase assim.

Pega uma estrutura genérica. Troca Cliente por Paciente. Produto por Procedimento. Pronto. Sistema para clínicas.

Só que não.

O domínio muda. As relações mudam. As regras mudam. A importância das informações muda.

Uma clínica pode precisar entender:

  • paciente;
  • procedimento;
  • profissional;
  • especialidade;
  • agenda;
  • retorno;
  • prontuário;
  • convênio;
  • consentimento;
  • unidade.

Hotelaria vai perguntar outras coisas.

  • HÓSPEDErealiza → RESERVA
  • RESERVAocupa → ACOMODAÇÃO
  • ACOMODAÇÃOpossui → TARIFA

Agronegócio abre outro universo.

  • Safra.
  • Talhão.
  • Propriedade.
  • Cultura.
  • Insumo.
  • Máquina.
  • Produtor.
  • Clima.
  • Logística.
  • Certificação.

Cada setor traz novas entidades.

Mas principalmente: novas relações.

02E foi aqui que o CORE começou a mostrar por que precisava ser CORE

Porque eu não queria construir archē para clínicas. Outro archē para hotéis. Outro para agência. Outro para agronegócio.

O princípio precisava permanecer.

o núcleo PessoaEmpresaDocumentoObjetivo · KPI clínicapousadaagênciaagronegócio pacienteprontuárioconvênio reservaacomodaçãotarifa campanhacriativobriefing safratalhãoinsumo o núcleo permanece. as bordas crescem.
fig. 02As doze palavras das quatro caixas não existem no centro — e não precisam. O que não pode mudar é o que está dentro do círculo.

Pessoa continua sendo Pessoa. Empresa continua sendo Empresa. Documento continua sendo Documento. Objetivo continua sendo Objetivo. KPI continua sendo KPI.

Mas o contexto expande a ontologia.

A clínica acrescenta aquilo que precisa. A pousada também. A agência também.

O núcleo permanece.

As bordas crescem.

Essa imagem começou a fazer muito sentido para mim.

03O framework deixou de ser uma lista de módulos

Essa parte é importante porque, no começo, eu estava muito concentrado nas telas.

Qual módulo existe? O que aparece na sidebar? Quais páginas ficam dentro dele? Qual card? Qual formulário?

E foi um trabalho enorme.

Na verdade, esse trabalho foi fundamental.

Porque foi nele que comecei a desmontar uma empresa.

  • Institucional.
  • Administrativo.
  • Estratégia.
  • Comercial.
  • Marketing.
  • Financeiro.
  • Operação.
  • Projetos.
  • Clientes.
  • Pessoas.
  • Tecnologia.
  • Documentos.
  • Indicadores.
  • Governança.

Cada área foi ganhando seus núcleos. Suas perguntas. Seus objetos. Seus processos. Suas relações.

Só que depois aconteceu uma inversão interessante.

Eu percebi que a tela não podia ser o modelo. O modelo precisava gerar a tela.

04Isso mudou completamente minha maneira de pensar interface

Eu vinha de WordPress. Vinha de aplicações tradicionais. Vinha do Obsidian.

E em cada uma dessas experiências havia alguma coisa que eu adorava e alguma coisa que me incomodava.

No Obsidian eu tinha liberdade estrutural. No WordPress eu tinha enorme liberdade de publicação e interface. Nos sistemas tradicionais eu tinha estruturas operacionais mais claras.

Eu queria coisas dos três mundos.

Só que não queria ficar preso a nenhum deles.

Então a pergunta virou:

Se o sistema já sabe o que uma entidade é, por que a interface também não pode saber?

Se uma entidade possui um DNA descrevendo campos, tipos, relações, estados, ações, permissões e views, talvez o próprio sistema possa montar boa parte da experiência.

05Foi aí que os cards começaram a ganhar outro significado

Eu gosto muito de card.

Quem está vendo a interface da archē provavelmente já percebeu isso.

Mas o card não precisava ser apenas design.

Ele podia ser uma representação da entidade.

Cliente

Empresa Alfa
Status
Cliente ativo
Responsável
Marina
Projetos
3
Última interação
Ontem
Meta relacionada
Expansão 2026

Financeiro

Empresa Alfa
Faturamento
Em aberto
Prazo médio
Última cobrança

Mesma entidade.

Outro card. Outro observador. Outro contexto.

A interface começa a materializar aquela filosofia que vinha desde o início.

06E aí veio uma ideia que me deixou particularmente animado

Se a interface é parcialmente gerada pelo DNA... e a IA consegue entender esse DNA... então a própria IA pode ajudar a criar novas estruturas.

Não deveria simplesmente inventar.

Já falei disso.

Mas pode investigar.

"preciso controlar certificados" ???????? que certificadospossuem validadesão obrigatórios para todos dependem do serviçoquem emiteprecisam de arquivo existe renovaçãoo vencimento gera alerta entidade Certificado relações Fornecedor · Organização emissora Documento campos Tipo · Número · Emissão Validade · Status evento Vencimento próximo ação possível Notificar responsável e só depois disso alguém valida.
fig. 03Entre a frase da esquerda e a ficha da direita existem oito perguntas. É isso que separa "a IA criou um formulário" de "a IA participou da modelagem".

Depois alguém valida.

E a estrutura passa a existir.

Isso para mim é muito mais interessante do que "IA cria formulário".

Ela participa da modelagem do problema.

07E aí comecei a pensar em sistemas que se constroem

Essa frase precisa ser usada com cuidado.

Não quero vender ficção.

A archē não acorda de madrugada e decide espontaneamente criar um departamento novo.

Existe arquitetura. Schemas. Governança. Validação. Código. Permissão. Limites.

Mas existe uma diferença enorme entre um sistema em que toda nova necessidade exige começar desenvolvimento do zero e outro em que grande parte da estrutura pode ser descrita, configurada, relacionada e gerada.

Foi isso que comecei a buscar.

  • não sabe
  • investigar
  • modelar
  • gerar
  • validar
  • usar
  • aprender

08E isso mudou a maneira como eu enxergava produto

Porque talvez uma solução vertical não precise nascer como um software independente.

Pode nascer como um pacote de conhecimento e estrutura sobre o CORE.

Hotelaria poderia trazer:

  • entidades;
  • relações;
  • campos;
  • KPIs;
  • workflows;
  • skills;
  • perguntas;
  • documentos;
  • conhecimento;
  • design;
  • views.

Agronegócio, outro pacote. Clínicas, outro. Arquitetura, outro.

O núcleo continua compartilhado.

Agora começamos a ter algo muito mais interessante do que simplesmente "templates".

Começamos a ter modelos de domínio.

09E eu queria que esses modelos conhecessem o mercado

Foi aí que minha cabeça foi longe.

Porque se vamos estudar Hotelaria para modelar uma empresa de hotelaria, por que parar na operação?

Quero conhecer o setor.

  • mercado;
  • concorrentes;
  • tendências;
  • tecnologias;
  • regulamentação;
  • certificações;
  • associações;
  • eventos;
  • fontes;
  • indicadores.

E principalmente: pessoas.

Quem são as referências daquele universo? Quem pesquisa? Quem escreve? Quem criou conceitos importantes? Quem está construindo coisas interessantes?

De novo, o Panteon começou a conversar com outra coisa.

10Porque referência também é entidade

Essa ideia me parece óbvia hoje.

Mas ela abre uma porta gigantesca.

Imagine que estou pesquisando gestão. Encontro Peter Drucker.

Por que ele deveria existir apenas como texto dentro de um artigo?

Ele pode ser uma entidade — relacionada a obras, conceitos, organizações, artigos, setores, ideias e outras pessoas.

Amanhã um artigo cita Drucker. Não precisamos criar outro Drucker. Relacionamos.

Depois um agente usa uma obra dele como fonte. Relacionamos.

Um curso fala daquele conceito. Relacionamos.

Uma empresa aplica uma metodologia relacionada. Relacionamos.

E o grafo cresce.

11Foi aí que percebi que conteúdo também precisava entrar nessa história

Até então eu estava pensando muito em operação.

Mas eu também construo sites. Conteúdo. Marketing. SEO. Campanhas.

E comecei a perceber: um artigo também é uma entidade.

Isso parece pequeno.

Mas abre outra coisa inteira.

autortesefontes ARTIGO cita Peter Drucker não criamos outro Drucker relacionamos CARROSSELVÍDEOSHORTNEWSLETTER PODCASTINFOGRÁFICOCAMPANHA todos continuam relacionados à origem
fig. 04Sete formatos saindo de uma linha só. A chave é a chave da direita: nenhum deles vira órfão depois de publicado.

Um artigo possui autor, tema, pergunta, tese, fontes, pessoas citadas, conceitos, setores, produtos, campanhas, imagens, vídeos, publicações e resultados.

Ele pode gerar outras coisas.

E todos continuam relacionados à origem.

O conteúdo deixa de ser uma página morta depois de publicada.

Vira parte do conhecimento.

12E foi aí que o LAB começou a crescer de novo

Porque o LAB não precisava ser apenas o lugar onde construímos aquilo que falta no software.

Podia ser também onde pesquisamos, documentamos, experimentamos, publicamos, conectamos referências, estudamos setores e produzimos conhecimento.

Uma descoberta feita durante a implantação de uma empresa pode gerar conhecimento.

Esse conhecimento pode gerar artigo. O artigo pode encontrar uma referência. A referência pode entrar no grafo. Pode enriquecer uma skill. Pode melhorar uma pergunta do onboarding. Pode ajudar outra empresa daquele setor.

Olha o ciclo:

  • EMPRESA
  • PROBLEMA REAL
  • PESQUISA
  • CONHECIMENTO
  • MODELO
  • FRAMEWORK
  • CONTEÚDO
  • NOVA EMPRESA

Isso começou a ficar muito bonito para mim.

Porque a archē poderia aprender trabalhando.

13E comecei a pensar no conhecimento como ativo

Uma agência normalmente entrega. Site. Campanha. Automação. Sistema. Projeto.

Terminou.

Próximo cliente.

Só que durante aquele trabalho ela aprendeu uma quantidade enorme de coisas.

E quase sempre esse conhecimento evapora.

Fica na cabeça de alguém. Numa pasta. Num WhatsApp. Num documento esquecido.

Eu não queria mais isso.

  • Se pesquisamos um setor, preservar.
  • Se descobrimos uma regra, preservar.
  • Se encontramos uma referência, preservar.
  • Se uma hipótese falhou, preservar.
  • Se um processo funcionou, preservar.
  • Se uma empresa nos ensinou algo novo, preservar.

Não para copiar uma empresa para outra.

Isso seria absurdo.

Mas para aumentar a capacidade do sistema de fazer perguntas melhores na próxima vez.

Essa diferença é fundamental.

14Talvez esse seja o verdadeiro aprendizado do sistema

Não:

A IA se treinou sozinha e agora sabe tudo.

Isso é uma frase ótima para vender ficção.

O que eu quero é mais concreto.

A archē encontra uma realidade. Identifica algo que ainda não conhece. Pesquisa. Estrutura. Valida. Relaciona. Preserva.

Na próxima vez que encontrar algo parecido, existe mais contexto disponível.

Isso é aprendizado institucional.

Uma empresa também deveria conseguir fazer isso consigo mesma.

E aqui voltamos novamente à memória.

Porque uma organização que não preserva aquilo que aprende está condenada a pagar várias vezes pela mesma aula.

15Foi quando percebi que o LAB podia ser público

Isso também começou a mudar minha ideia do site.

Eu não queria apenas Home, Produto, Serviços, Sobre, Contato.

Aquilo parecia uma agência.

E eu já não estava construindo exatamente uma agência.

Eu queria abrir parte desse processo.

Mostrar o que estamos pesquisando. O que estamos pensando. Os setores. As referências. As perguntas. Os experimentos. As coisas que deram certo.

Talvez até aquilo que deu errado.

O LAB poderia ser uma janela pública para o conhecimento que está crescendo por trás do sistema.

Não apenas blog.

Mas: explore o que estamos aprendendo.

Essa diferença explica muito do que estou construindo agora.

16E existe uma consequência comercial enorme

Se o conhecimento está estruturado em entidades, ele não precisa existir somente em um site.

  • Uma cidade pode alimentar um portal regional.
  • Uma pessoa pode alimentar um site de referências.
  • Um setor pode alimentar uma solução vertical.
  • Um artigo pode aparecer no LAB.
  • Um conceito pode aparecer em documentação.

A entidade continua sendo a mesma.

A publicação é que muda.

Essa ideia é praticamente a mesma descoberta que fiz lá atrás com os módulos.

Só que agora aplicada ao conteúdo.

Antes: Comercial e Financeiro podem observar a mesma empresa.

Agora: Dois sites podem publicar perspectivas diferentes sobre a mesma entidade.

A arquitetura começou a se repetir.

Quando isso acontece, normalmente presto atenção.

Talvez tenhamos encontrado um princípio.

17E aí comecei a enxergar a archē de outra forma

Não apenas como um software.

Também não apenas como um framework.

Começou a parecer um ecossistema em que algumas coisas desempenham papéis diferentes.

Eu ainda precisava organizar tudo isso melhor.

Mas pela primeira vez comecei a enxergar que aqueles nomes não eram simplesmente produtos colocados lado a lado.

Eram diferentes respostas para diferentes perguntas.

COREONFLOWMELAB o que existee como estárelacionado? o que issosignifica nestecontexto? o que acontecequando algomuda? quem estáobservando? o que fazemosquando aindanão sabemos? archē o princípio cinco respostas para cinco perguntas diferentes.
fig. 05Não são cinco produtos lado a lado. São cinco perguntas — e a caixa de baixo é a única coisa que explica por que elas pertencem ao mesmo sistema.

E quando coloquei dessa maneira, apareceu uma pergunta que talvez seja inevitável:

Se cada parte responde a uma pergunta diferente, o que conecta todas elas?

A resposta me levou novamente para onde essa história tinha começado.

Não para uma tecnologia.

Não para uma tela.

Não para uma IA.

Para o princípio.

archē

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.