Domain Knowledge as Infrastructure
A documentação de software deixará progressivamente de ser apenas uma interface de leitura para humanos e se tornará uma camada estruturada de conhecimento utilizada por agentes de IA especializados em domínios.
Durante décadas, construímos software seguindo um modelo relativamente previsível: criamos sistemas, APIs, bibliotecas, plataformas, produtos internos e ferramentas operacionais e, depois, para permitir que outras pessoas consigam entendê-los e utilizá-los, produzimos documentação — README, wikis, runbooks, ADRs, FAQs, diagramas, Swagger, tutoriais. Páginas e mais páginas descrevendo regras, exceções, comandos, comportamentos, integrações e decisões arquiteturais.
Esse modelo funcionou por muito tempo. Mas existe um problema cada vez mais evidente: os sistemas estão ficando maiores, as arquiteturas mais distribuídas, as dependências mais numerosas — e a quantidade de conhecimento necessária para compreender um domínio cresce mais rápido do que nossa capacidade humana de navegar por ele.
Hoje, uma pergunta aparentemente simples como:
Como habilito a transferência de dados de um shard para outro usando a CLI?
pode exigir a consulta de múltiplas fontes: talvez a resposta esteja em uma documentação, em um ADR, em um runbook, em um comentário de Pull Request, em um ticket antigo, em uma conversa no Slack — ou talvez esteja apenas na memória de alguém que participou da implementação original (em alguns cenários não faz mais parte da empresa).
Nesse cenário, acredito que existe uma transformação maior começando a acontecer. E ela não é simplesmente usar IA para pesquisar documentação. A mudança é mais profunda: estamos caminhando para um cenário no qual o conhecimento dos sistemas será tratado como infraestrutura. Chamo essa ideia de Domain Knowledge as Infrastructure.
O problema não é apenas falta de documentação
Em grandes organizações, conhecimento raramente está completamente ausente. Na maioria das vezes, ele está fragmentado. Considere um único produto corporativo — seu conhecimento pode estar distribuído entre:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
GitHub
Confluence
READMEs
Swagger / OpenAPI
Runbooks
Jira
Slack
Postmortems
ADRs
Dashboards
Logs
Configurações
Código-fonte
Feature flags
Change records
Service catalogs
Cada fonte contém uma parte da verdade, mas dificilmente existe uma representação única, consistente e continuamente atualizada do domínio. Hoje somos nós, humanos, que fazemos essa integração: buscamos, filtramos, interpretamos, comparamos, tentamos identificar conteúdo desatualizado, descobrimos dependências, conectamos decisões passadas ao comportamento atual e então tomamos uma decisão.
Esse processo funciona principalmente porque existem pessoas com grande conhecimento acumulado sobre determinados contextos — os chamados Domain Experts. Mas existe algo importante sobre um bom Domain Expert: ele não necessariamente decorou cada página de documentação. O que ele possui é algo mais poderoso — um modelo mental do domínio. Ele sabe quais informações são importantes, quais exceções observar, onde procurar, quais sistemas se relacionam e quando uma mudança aparentemente pequena pode causar consequências grandes.
O problema é que mesmo o melhor Domain Expert possui limites. Nenhum ser humano consegue lembrar e correlacionar instantaneamente milhares de documentos, dependências, incidentes, métricas, mudanças e regras. É justamente aqui que a IA começa a mudar a equação.
Do acesso à documentação para o acesso ao conhecimento
Imagine novamente a pergunta sobre a transferência de dados entre shards. No modelo tradicional, um engenheiro procura uma documentação, interpreta os passos e executa a operação. No modelo que imagino, ele simplesmente faz a pergunta — mas existe uma diferença importante: o agente não deveria apenas procurar uma frase parecida em uma página. Um verdadeiro agente especializado deveria compreender o significado da operação, as regras do domínio, a versão atual da plataforma, as permissões necessárias, o estado atual do ambiente, as políticas de produção, as dependências envolvidas, os riscos conhecidos e o procedimento de rollback.
A resposta poderia ser algo como:
Para transferir dados entre os shards A e B utilize:
shardctl transfer --from shard-a --to shard-bEntretanto, no ambiente atual essa operação exige
replicationFactor >= 3. O shard A está atualmente com fator de replicação 2. Além disso, operações em produção exigem a permissãoshard.admine aprovação operacional. Recomendo aumentar primeiro o fator de replicação e validar o estado dos consumidores downstream antes da transferência.
Observe o que aconteceu: o agente combinou documentação, estado operacional, configuração, políticas, permissões e dependências. Isso não é mais apenas busca. É raciocínio sobre um domínio.
O surgimento do AI Domain Expert
Um agente corporativo especializado em um determinado contexto poderia atuar como um AI Domain Expert — não no sentido de substituir imediatamente especialistas humanos, mas no sentido de ampliar sua capacidade.
Um Domain Expert humano possui julgamento, experiência, contexto histórico, intuição, conhecimento tácito e compreensão política e organizacional. Um agente possui outras vantagens: velocidade, capacidade de recuperação, correlação em grande escala, disponibilidade constante e capacidade de cruzar múltiplas fontes rapidamente.
Enquanto uma pessoa pode lembrar “acho que tivemos um problema semelhante alguns meses atrás”, o agente pode localizar imediatamente o incidente exato, a versão em que ocorreu e a causa raiz. A melhor interpretação, portanto, talvez não seja AI replacing Domain Experts, mas sim AI amplifying Domain Experts — ou ainda, AI as organizational domain memory.
Domain Knowledge as Infrastructure
A tese central é que o conhecimento de um produto não deveria ser tratado apenas como documentação passiva. Ele deveria ser tratado como um ativo operacional — assim como fizemos com infraestrutura.
Durante muito tempo, infraestrutura era configurada manualmente. Depois surgiu Infrastructure as Code, e infraestrutura passou a ser versionada, revisada, testada, automatizada, reproduzível e auditável. Acredito que algo semelhante acontecerá com conhecimento:
O conhecimento de um domínio deve ser estruturado, versionado, validado, observável e continuamente atualizado, para ser consumido tanto por pessoas quanto por agentes de IA.
Nesse modelo, documentação deixa de ser apenas uma coleção de páginas. Ela passa a ser uma das representações de uma infraestrutura de conhecimento maior.
Knowledge as Code
Uma consequência natural dessa visão é tratar parte do conhecimento de forma declarativa:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
knowledge/
│
├── operations/
│ └── shard-transfer.yaml
│
├── architecture/
│ └── shard-model.yaml
│
├── policies/
│ └── production-change.yaml
│
├── troubleshooting/
│ └── replication-errors.yaml
│
├── permissions/
│ └── shard-admin.yaml
│
└── dependencies/
└── topology.yaml
Uma operação poderia ser representada assim:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
operation: transfer-shard
description:
Transfer data ownership between shards.
requirements:
replication_factor:
minimum: 3
permissions:
- shard.admin
command:
shardctl transfer
--from ${source}
--to ${destination}
production:
approval_required: true
risks:
- temporary_latency_increase
rollback:
command:
shardctl transfer --rollback
Esse conteúdo ainda pode ser transformado em uma página agradável para leitura humana, mas também pode ser interpretado por máquinas. Estamos migrando de human-readable documentation para agent-consumable knowledge.
Documentação continua existindo
É importante deixar claro que essa visão não pressupõe o fim da documentação — mas seu papel muda. Hoje pensamos “criamos documentação para que pessoas encontrem informações”. No futuro podemos pensar “mantemos conhecimento estruturado e criamos diferentes interfaces para consumi-lo”: uma página, uma CLI, uma IDE, um chatbot, um agente operacional — todos consumindo uma mesma base de conhecimento confiável. Documentação passa a ser uma view do conhecimento, e não necessariamente sua única fonte.
O verdadeiro problema: Knowledge Drift
Software muda constantemente. Imagine que hoje uma CLI possui o comando shardctl migrate e, na próxima release, ele é substituído por shardctl transfer. O código mudou, os testes mudaram, a release foi concluída — mas uma documentação antiga continua dizendo shardctl migrate. Temos agora duas realidades diferentes:
1
2
3
System State
≠
Knowledge State
Esse fenômeno pode ser chamado de Knowledge Drift: a divergência entre o comportamento real do produto e o conhecimento disponível sobre ele. Hoje isso já é um problema. Com agentes, ele se torna ainda mais importante, porque uma documentação incorreta pode confundir uma pessoa, mas um agente incorreto pode fornecer uma resposta errada com extrema velocidade e confiança. Quanto maior a automação, maior precisa ser a qualidade do conhecimento.
Knowledge CI/CD
Por isso acredito que conhecimento deverá começar a fazer parte do próprio lifecycle de desenvolvimento:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Developer changes code
│
▼
Pull Request
│
├── Build
├── Tests
├── Security
├── Architecture validation
│
└── Knowledge validation
│
▼
Knowledge update
│
▼
Knowledge Base
│
▼
Domain Agents
Se uma API mudou, o conhecimento relacionado deve ser atualizado. Se uma política mudou, os agentes precisam refletir essa mudança. Se uma configuração se tornou inválida, exemplos antigos precisam ser detectados. Se um incidente revelou uma nova condição de falha, esse aprendizado deve retornar ao domínio. Esse processo poderia ser entendido como Knowledge CI/CD: assim como código passa por pipelines antes de chegar à produção, conhecimento também passaria.
Conhecimento como parte do Definition of Done
Essa mudança exige também uma transformação cultural. Hoje é comum ouvir “depois atualizamos o README” — em um ambiente orientado a Domain Knowledge as Infrastructure, essa frase representa risco operacional. Conhecimento precisa possuir ownership, versioning, lifecycle, validação, observabilidade, controle de acesso, provenance e confiança. Atualizar conhecimento deixa de ser um trabalho administrativo e passa a ser parte da engenharia do produto.
Medindo conhecimento
Se conhecimento passa a ser infraestrutura, talvez precisemos começar a medi-lo:
- Knowledge Coverage — quanto do comportamento do produto está representado na base de conhecimento?
- Knowledge Freshness — quanto desse conhecimento foi validado recentemente?
- Knowledge Drift — qual parcela está divergente do estado atual do produto?
- Knowledge Confidence — qual o nível de confiabilidade de determinada afirmação?
- Knowledge Provenance — qual é a origem de determinada regra?
- Agent Answer Accuracy — qual porcentagem das respostas produzidas pelos agentes é validada como correta?
Essas métricas podem parecer incomuns hoje, mas talvez sejam tão naturais no futuro quanto code coverage ou SLO.
O verdadeiro gargalo talvez não seja o modelo
Quando empresas discutem IA, muitas vezes começam pela pergunta “qual LLM devemos utilizar?” — GPT, Claude, Gemini, modelo próprio. Essa discussão é relevante, mas acredito que existe uma pergunta anterior: qual é a qualidade do conhecimento que esse modelo receberá?
Mesmo um modelo extremamente poderoso terá dificuldades com uma base contraditória, incompleta, desatualizada, sem ownership, sem contexto e sem versionamento. Por isso, uma hipótese importante dessa tese é:
A vantagem competitiva de agentes corporativos pode depender mais da qualidade da infraestrutura de conhecimento da empresa do que do modelo utilizado.
Modelos tendem a se tornar cada vez mais acessíveis. O conhecimento específico de uma organização, não.
Da recuperação de conhecimento para tomada de decisão
Até aqui, Domain Knowledge as Infrastructure poderia ser interpretado como uma maneira melhor de responder perguntas técnicas. Mas acredito que esse seja apenas o primeiro nível de valor. A transformação mais importante começa quando o agente deixa de responder apenas “como isso funciona?” e passa a ajudar a responder “o que provavelmente acontecerá se fizermos isso?”. Estamos saindo de Knowledge Retrieval para Decision Intelligence — e é aqui que o conceito se torna muito mais estratégico.
Um AI Domain Expert participando de uma CAB
Considere um processo comum em grandes empresas: uma mudança relevante precisa entrar em produção, existe uma GMUD, existe uma reunião de CAB (Change Advisory Board), e arquitetos, engenheiros, gestores e representantes de diferentes sistemas discutem os riscos antes da aprovação. Normalmente surgem perguntas como: qual serviço será alterado? Existe indisponibilidade prevista? Existe rollback? Quem consome esse serviço? Existe algum fluxo de negócio crítico envolvido?
Essas perguntas são importantes, mas existe uma limitação inevitável: a qualidade da análise depende da quantidade de contexto disponível na sala. Uma pessoa conhece determinada aplicação, outra conhece o fluxo de negócio, outra conhece uma dependência específica — mas arquiteturas modernas podem conter centenas ou milhares de relacionamentos, e a capacidade humana de correlacionar todas essas conexões em uma reunião é limitada.
Pre-approval intelligence para mudanças
Imagine uma GMUD que aumenta o timeout do Customer Profile API de 2s para 5s. À primeira vista, uma mudança pequena. Um agente com conhecimento do domínio poderia cruzar essa informação com serviços upstream e downstream, cadeias de timeout, políticas de retry, circuit breakers, tráfego, SLOs, incidentes recentes, deployments e jornadas de negócio críticas — e descobrir que o Payment API, que consome esse serviço, possui timeout de 3 segundos, o que pode aumentar cancelamentos em condições de degradação, e que uma política de retry pode amplificar o tráfego, com um padrão semelhante já observado em um incidente anterior.
Um problema que dificilmente seria visível através da simples leitura da GMUD passa a ser explicitado antes do deploy. O agente não precisa decidir pela CAB — ele aumenta a qualidade das evidências disponíveis para quem decide.
De Change Management baseado em opinião para baseado em dados
Grande parte dos processos de mudança ainda depende de avaliação humana declarativa: alguém classifica uma mudança como LOW, MEDIUM ou HIGH — mas quais evidências sustentam essa classificação? Domain Knowledge as Infrastructure poderia permitir uma análise baseada em escopo da mudança, grafo de dependências, criticidade, incidentes históricos, histórico de deployments, error budgets, SLOs, tráfego, capacidade de rollback e mudanças correlacionadas recentes.
Assim, começamos a migrar de Opinion-Based Change Management para Data-Driven Change Management. A CAB deixa de depender apenas da memória coletiva dos participantes e passa a utilizar a memória operacional acumulada da organização.
Knowledge Graph operacional
Para viabilizar esse tipo de análise, conhecimento não pode ser tratado apenas como texto — precisamos compreender relações, como um serviço que chama outro serviço, consome um tópico, escreve em um banco de dados e suporta uma capability de negócio. Esse tipo de relação transforma a base de conhecimento em um grafo operacional, capaz de conectar uma GMUD ao serviço alterado, seus consumidores upstream e downstream, a plataforma, os fluxos de negócio, os SLOs e, por fim, a análise de risco.
Esse grafo é especialmente valioso porque muitos problemas em sistemas distribuídos não existem dentro de um único serviço — eles emergem das relações entre componentes.
Do Domain Expert para o Domain Operator
Se o agente possui conhecimento suficiente sobre arquitetura e acesso controlado ao estado operacional, ele pode ir além de responder perguntas. Considere um incidente: um engenheiro pergunta por que o shard 7 está apresentando latência alta. O agente poderia investigar métricas, logs, deployments, configurações, commits recentes, feature flags, incidentes históricos e topologia — e responder que a degradação começou minutos após um deployment específico, que a nova estratégia de roteamento aumentou consultas cross-shard, que a configuração atual é semelhante à de um incidente anterior, e que existe rollback disponível para a versão anterior.
O agente deixou de ser apenas uma interface documental. Ele se tornou um investigador. O próximo passo poderia ser gerar um plano de rollback e, depois, executá-lo após aprovação. Essa progressão pode ser representada assim:
1
2
3
4
5
6
7
8
9
10
11
Documentation
↓
Search
↓
AI Assistant
↓
Domain Expert
↓
Decision Support
↓
Domain Operator
Uma evolução possível
Podemos organizar essa maturidade em níveis:
- Documentation — pessoas procuram e interpretam conhecimento.
- Searchable Documentation — a descoberta melhora, mas a interpretação continua humana.
- AI-Assisted Documentation — o modelo responde com base nas páginas existentes.
- AI Domain Expert — o agente compreende regras, relações e contexto operacional.
- Decision Intelligence — o agente cruza conhecimento e dados para apoiar decisões.
- Domain Operator — o agente investiga, propõe ações e eventualmente executa operações sob políticas e controles.
O valor também aparece no planejamento
Existe outro cenário onde essa infraestrutura pode produzir impacto significativo: planejamento estratégico e OKRs. Imagine um OKR como “reduzir em 30% o tempo necessário para onboarding de novos clientes”. Esse objetivo parece claro do ponto de vista de negócio, mas transformá-lo em engenharia exige responder diversas perguntas — quais capabilities, domains, boundaries e serviços participam desse fluxo, onde está a maior latência, quais falhas geram abandono, quais times possuem esses sistemas, quais iniciativas já existem, onde existem duplicações e quais oportunidades possuem melhor relação esforço versus impacto.
Hoje esse trabalho é realizado através da combinação do conhecimento de várias pessoas — Product Managers, Tech Leads, arquitetos, engenheiros, analistas de dados, Domain Experts — cada um com uma parte do contexto.
Do OKR para o Domain
Um Domain Knowledge Agent poderia mapear o caminho entre OKR, jornada de negócio, business capabilities, bounded contexts, serviços, métricas e constraints. Por exemplo, ao mapear “reduce onboarding time by 30%” até o Customer Onboarding e suas boundaries de Identity, Credit e Account, o agente poderia identificar que 42% do tempo médio de onboarding está concentrado na boundary de Identity Verification, que 67% desse tempo está associado a Document Validation, e então apontar oportunidades técnicas concretas: paralelizar verificações hoje sequenciais, remover uma consulta redundante e reutilizar dados já presentes no contexto de onboarding em vez de consultar novamente um provider externo.
Um objetivo de negócio começou a produzir oportunidades de engenharia.
Opportunity Discovery
Esse é um uso particularmente poderoso: o agente não precisa apenas responder perguntas, ele pode procurar sinais — alta latência combinada com alto custo, incidentes repetidos, capability duplicada e alto esforço de engenharia — e identificar, por exemplo, que quatro serviços distintos implementam a mesma validação de endereço, ou que uma parcela relevante dos incidentes de uma capability tem a mesma origem. Nesse ponto, conhecimento passa a gerar Opportunity Discovery, e arquitetura começa a se conectar diretamente com estratégia.
Uma possível cadeia entre estratégia e engenharia
Podemos pensar em uma estrutura assim:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Business Objective
│
▼
OKR
│
▼
Business Capability
│
▼
Bounded Context
│
▼
Services
│
▼
Constraints / Problems
│
▼
Opportunities
│
▼
Initiatives
│
▼
Engineering Backlog
Esse encadeamento é importante porque um dos grandes problemas das organizações é justamente a distância entre estratégia e execução. Muitas vezes existe um OKR em um documento, uma arquitetura em outro, métricas em dashboards e histórias no backlog — mas as relações entre esses elementos não estão explicitamente representadas. Domain Knowledge as Infrastructure pode ajudar a conectar essas camadas.
Do conhecimento para o backlog
Imagine que uma oportunidade tenha sido identificada — paralelizar a verificação de identidade. O sistema poderia mapear essa oportunidade para uma iniciativa e ajudar a elaborar um backlog inicial, com épicos, histórias (como desacoplar Document Validation da criação de cliente, implementar verificação assíncrona, adicionar eventos de status e observabilidade) e dependências claras com outras plataformas. Aqui entramos em uma extensão da tese.
Agile Driven AI
Se Domain Knowledge as Infrastructure tenta responder “o que sabemos sobre nosso domínio?”, podemos imaginar outra capacidade orientada à pergunta “como transformamos conhecimento, estratégia e evidências em trabalho organizado?”. Chamo essa extensão de Agile Driven AI.
Um agente voltado para backlog não deveria simplesmente escrever histórias bonitas — isso seria apenas geração de texto. O agente deveria compreender OKRs, domain knowledge, dependências, arquitetura, ownership dos times, histórico de entrega, constraints, métricas e prioridades, e então ajudar a transformar estratégia em execução.
O agente de backlog
Um verdadeiro agente de backlog poderia apoiar perguntas como: qual initiative melhor contribui para esse KR? Quais serviços precisam mudar? Quais dependências precisam ser resolvidas antes? Quais itens podem ser paralelizados? Quais histórias já existentes estão relacionadas a esse objetivo? Quais riscos técnicos podem impedir a entrega? Quais oportunidades possuem maior impacto?
Isso muda a natureza do backlog: ele deixa de ser apenas um conjunto de tickets e passa a ser uma representação operacional das decisões tomadas sobre o domínio.
O Closed Knowledge Loop
Hoje, muitas organizações possuem ciclos desconectados: planejamento acontece em um lugar, desenvolvimento em outro, deploy em outro, operação em outro, incidentes em outro, documentação em outro. As informações circulam principalmente através de pessoas. Mas Domain Knowledge as Infrastructure pode criar um Closed Knowledge Loop:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
┌─────────────────────────┐
│ │
▼ │
PLAN │
│ │
▼ │
DEVELOP │
│ │
▼ │
DEPLOY │
│ │
▼ │
OPERATE │
│ │
▼ │
OBSERVE │
│ │
▼ │
LEARN ──────────────────────┘
Cada etapa produz conhecimento: planejamento produz hipóteses, arquitetura produz decisões, desenvolvimento produz implementações, deploys produzem mudanças, operação produz comportamento real, observabilidade produz evidência, incidentes produzem aprendizado e retrospectivas produzem decisões. Tudo isso pode retornar à infraestrutura de conhecimento, e o próximo agente começa a trabalhar com um domínio mais rico do que o anterior.
Da memória organizacional para inteligência organizacional
Inicialmente, Domain Knowledge as Infrastructure pode parecer apenas uma maneira melhor de preservar conhecimento. Mas existe uma evolução possível — de Documentation para Knowledge Retrieval, Organizational Memory, Domain Reasoning, Decision Support, Opportunity Discovery, Planning Intelligence e Operational Intelligence.
Nesse estágio, estamos deixando de construir apenas uma memória organizacional. Estamos começando a construir uma Organizational Intelligence Layer — não porque uma IA magicamente conhece toda a empresa, mas porque existe uma infraestrutura capaz de conectar dados e conhecimento que antes permaneciam isolados.
O valor não está apenas em responder mais rápido
É tentador medir esse tipo de iniciativa apenas através de produtividade — quantos minutos economizamos procurando documentação, quantas perguntas deixaram de ser direcionadas ao time. Essas métricas são úteis, mas acredito que o maior valor está em outro ponto:
Aumentar a qualidade das decisões através da capacidade de correlacionar uma quantidade de contexto que dificilmente um ser humano conseguiria analisar sozinho.
Isso pode ser aplicado em CAB, GMUD, architecture reviews, incident response, risk assessment, capacity planning, OKR planning, opportunity discovery, backlog prioritization, modernização e estratégia técnica. O agente deixa de ser apenas uma interface entre pessoas e documentação. Ele passa a ser uma interface entre conhecimento e decisão.
Principais desafios
Naturalmente, essa visão traz desafios significativos.
1. Source of Truth
Qual sistema representa a verdade quando duas fontes divergem? Código? Runbook? Documentação? CMDB? Service catalog? Um agente precisa conhecer não apenas a informação, mas sua autoridade.
2. Provenance
Toda afirmação importante deveria conseguir responder “de onde veio essa informação?”. Sem provenance, confiança diminui rapidamente.
3. Ownership
Quem é responsável por determinada parte do conhecimento? Conhecimento sem owner inevitavelmente envelhece.
4. Freshness
Quando essa informação foi validada pela última vez? Freshness precisa ser uma propriedade do conhecimento.
5. Segurança
Nem todo conhecimento deve ser acessível para todos. O agente precisa respeitar RBAC, ABAC, classificação de dados, permissões por ambiente e segregação de funções.
6. Ações perigosas
Existe uma diferença enorme entre “como faço rollback?” e “faça rollback”. Quanto mais o agente evolui para Domain Operator, maior a necessidade de approval gates, policies, guardrails, auditabilidade, least privilege e human-in-the-loop.
7. Conhecimento implícito
Talvez o problema mais difícil: muito do que uma organização sabe nunca foi formalizado. Está na experiência das pessoas, nos chamados “todo mundo sabe que…”. Esse conhecimento precisa ser descoberto e estruturado.
8. Contradições
Domínios reais possuem ambiguidades — duas equipes podem acreditar em regras diferentes. Um bom sistema de conhecimento não pode simplesmente esconder a contradição; ele precisa torná-la visível.
9. Qualidade da inferência
Correlacionar serviços não significa necessariamente provar causalidade. Um agente precisa saber diferenciar fato, inferência, hipótese e recomendação. Essa distinção será fundamental em decisões importantes.
Uma possível arquitetura de referência
Podemos imaginar Domain Knowledge as Infrastructure como várias camadas:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
┌──────────────────────────────────────────┐
│ Consumers │
│ │
│ Humans | IDE | CLI | Agents | Systems │
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Domain Intelligence │
│ │
│ Retrieval | Reasoning | Planning │
│ Risk Analysis | Recommendations │
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Knowledge Graph │
│ │
│ Services | Domains | APIs | Policies │
│ Dependencies | Capabilities | Owners │
│ Incidents | Objectives | Metrics │
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Knowledge Pipeline │
│ │
│ Ingest | Normalize | Validate | Version │
│ Correlate | Classify | Enrich │
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Sources │
│ │
│ Git | Docs | APIs | Jira | Observability │
│ CMDB | Runbooks | ADRs | Incidents │
└──────────────────────────────────────────┘
Essa arquitetura evidencia algo importante: o LLM é apenas uma parte da solução. Provavelmente nem sequer será a parte mais difícil.
O paradoxo da IA corporativa
Existe um paradoxo interessante acontecendo. Empresas querem agentes cada vez mais inteligentes, mas muitas ainda possuem conhecimento extremamente desorganizado. Queremos que a IA compreenda nossas organizações, mas às vezes nossas próprias organizações não possuem uma representação clara de como funcionam. Queremos agentes capazes de decidir, mas não conseguimos dizer claramente quais fontes são confiáveis. Queremos automação, mas parte relevante das regras continua apenas na memória das pessoas.
Quanto mais inteligentes os agentes se tornam, mais evidente fica um problema antigo: a organização sabe estruturar aquilo que sabe? Talvez essa seja uma das perguntas mais importantes da próxima geração de plataformas corporativas.
Uma nova camada da arquitetura
Hoje, quando desenhamos plataformas, pensamos naturalmente em compute, network, storage, security, observability e data. Talvez seja necessário começar a adicionar knowledge — não como documentação complementar, mas como parte explícita da arquitetura. Porque pessoas precisam entender sistemas, e cada vez mais máquinas também precisarão entendê-los.
A mudança de mentalidade
Hoje a documentação frequentemente segue este fluxo: software → documentation → human search → interpretation → action. Domain Knowledge as Infrastructure propõe algo diferente: software, arquitetura, runtime, políticas, histórico e contexto de negócio convergem para domain knowledge, que alimenta domain intelligence, consumida tanto por humanos quanto por agentes, resultando em decisões.
Essa é uma mudança de interface, mas também uma mudança de arquitetura e, principalmente, uma mudança de como enxergamos conhecimento.
Uma provocação
Hoje, diante de um problema importante, normalmente perguntamos “quem conhece melhor esse sistema?”. Talvez no futuro a pergunta seja “o que a organização inteira sabe sobre esse problema?”.
Nenhuma pessoa conhece todas as aplicações. Nenhum arquiteto conhece todas as dependências. Nenhum Product Manager conhece todas as oportunidades. Nenhum engenheiro lembra de todos os incidentes. Nenhum gestor consegue observar simultaneamente todas as relações entre tecnologia, estratégia e negócio. Mas uma infraestrutura de conhecimento pode começar a conectar essas partes — e talvez esse seja o maior potencial de Domain Knowledge as Infrastructure. Não construir uma IA que saiba tudo, mas construir uma organização capaz de utilizar melhor tudo aquilo que já sabe.
Conclusão
Talvez o futuro da documentação não seja criar páginas melhores. Talvez a mudança real seja transformar conhecimento em infraestrutura — infraestrutura que possui versioning, ownership, validation, lifecycle, observability, security, provenance e automation.
Esse conhecimento poderá ser utilizado para explicar sistemas, investigar incidentes, antecipar riscos de mudanças, apoiar CABs, conectar upstream e downstream, encontrar oportunidades técnicas, cruzar arquitetura com OKRs, orientar iniciativas, ajudar na construção de backlog e, eventualmente, operar sistemas.
Podemos começar chamando isso de Domain Knowledge as Infrastructure. Mas talvez, no longo prazo, estejamos falando de algo ainda maior: uma camada capaz de conectar o conhecimento acumulado de uma organização às decisões que ela precisa tomar.
E, se isso acontecer, a pergunta que define a próxima geração de experiência de software talvez não seja “onde está a documentação?”. Pode ser simplesmente:
O que sabemos sobre isso — e o que esse conhecimento nos diz que devemos fazer a seguir?
Este artigo deixa em aberto três conceitos que podem virar publicações: Knowledge CI/CD, AI Domain Expert / Domain > Operator e Agile Driven AI.
Espero ter tempo para continuar progredindo com a pesquisa…
Dedico este artigo à minha filha Lunna… O sorriso dela é meu combustível.