A pilha do agente de IA ganhou mais um andar — e ele é sobre consultar dado. Depois de semanas discutindo como controlar o que o agente vê, o padrão agora é deixar o agente ler o dado espalhado, e ler cada vez mais fontes de uma vez. É um passo certo. Mas vale dizer com todas as letras antes de comemorar: consultar não é integrar, “sem ETL” não é dado reconciliado, e ler não é agir.
1. O que aconteceu: a camada de consulta do agente virou produto
A AWS, com a Stardog, publicou a receita de uma camada semântica que responde perguntas de “customer 360” atravessando Amazon Aurora e Amazon Redshift — sem ETL —, com um agente rodando no Bedrock AgentCore e a mesma camada federando também Athena e outras fontes. Em paralelo, gateways de consulta e governança amadureceram: Snowflake Cortex AI Gateway e padrões de MCP governance passaram a governar o que o agente consulta e a prevenir exfiltração. O padrão da semana é claro: a camada de leitura/consulta do agente virou produto.
Há uma razão de fundo para esse andar surgir agora: o agente que “age” (tema que domina a semana em Salesforce, Google e AWS) depende de ler dado de muitas fontes, e ninguém quer construir um data warehouse novo a cada caso de uso. A camada semântica promete encurtar esse caminho. É uma resposta legítima a uma dor real — desde que se entenda que ela resolve a leitura, e que a escrita governada e o dado reconciliado continuam sendo um projeto à parte.
2. O que ela faz: responder “customer 360” sem ETL
Concretamente, a camada semântica traduz uma pergunta de negócio em consultas federadas sobre várias bases, sem mover o dado para um data warehouse intermediário. O agente pergunta “qual o valor total e o último pedido deste cliente?” e a camada resolve a junção atravessando Aurora, Redshift e Athena, devolvendo uma resposta única. Para quem penava com pipelines de ETL só para responder perguntas cruzadas, é um ganho real de velocidade e de acesso.
Vale situar isso na sequência da semana para não confundir camadas. Há pouco, a conversa era sobre controlar o que o agente enxerga — mascarar, tokenizar, aplicar política de dado. Agora o eixo é o oposto complementar: ampliar o que o agente consulta, e fazê-lo atravessar mais fontes de uma vez. São dois andares diferentes do mesmo prédio: um restringe a leitura, o outro a expande. Nenhum dos dois, porém, desce até o térreo — a integração transacional por onde o agente escreve e o dado reconciliado sobre o qual ele decide. É esse térreo que sustenta o prédio inteiro.
3. Por que é necessária: o agente precisa ler o dado espalhado
Nada disso é supérfluo. Um agente que não enxerga o dado espalhado é inútil — ele precisa ler pedido, cliente, estoque e histórico onde quer que morem para ser minimamente prestativo. A camada de consulta resolve o problema de acesso: derruba a barreira de “esse dado está noutro banco, noutro formato, noutro time”. É condição necessária. Só não é suficiente.
4. O que a camada NÃO faz: reconciliar o número
Uma camada semântica federa a consulta — ela não reconcilia o número que está errado ou dividido em três sistemas. Federar não é ter uma versão única da verdade: se o estoque diverge entre o ERP, o WMS e a plataforma de venda, a camada devolve a divergência com uma cara mais bonita e mais rápida. “Responder atravessando Aurora e Redshift” pressupõe que o valor em cada fonte esteja certo; quando não está, a federação apenas propaga o erro com mais eficiência.
Um exemplo deixa a diferença nítida. Pergunte à camada semântica “quantas unidades do produto X temos disponíveis?” e ela federa a consulta entre o ERP (que diz 40), o WMS (que diz 32 porque processou uma saída) e a plataforma de venda (que diz 35 por causa de um buffer). A camada responde — rápido, sem ETL — mas responde qual número? Sem uma regra de reconciliação que defina a fonte-mestre e a precedência, ela devolve o que a consulta alcançar primeiro, ou uma soma sem sentido. O agente recebe uma resposta confiante sobre um dado que não é confiável. Acesso veloz a um número errado é, muitas vezes, pior do que acesso lento a um número certo.
5. O que “sem ETL” NÃO resolve: a verdade do dado
“Sem ETL” é uma promessa sobre acesso, não sobre verdade. Ela elimina o pipeline de cópia — ótimo para latência e custo — mas não decide qual das fontes é a fonte-mestre, qual regra de precedência vale, nem em que janela cada número é válido. Reconciliação é um problema de governança de dado, não de roteamento de consulta. Tirar o ETL do caminho não torna o dado verdadeiro; só o torna acessível mais rápido.
A assimetria é importante: ler errado gera uma resposta ruim; escrever errado gera um efeito colateral real e às vezes irreversível — um pedido duplicado, uma baixa indevida, um reembolso a mais. Por isso a porta de escrita não pode ser um detalhe deixado para depois. Ela exige contrato explícito, escopo mínimo por operação e idempotência de primeira classe — precisamente o oposto de “deixa o agente consultar tudo e ver no que dá”.
6. O que consultar NÃO é: agir
E aqui está o ponto que a euforia costuma pular: responder pergunta é leitura. Não é a API contratada, idempotente e de menor privilégio por onde o agente escreve e age com segurança — dá baixa no estoque, cria o pedido, dispara o fluxo, emite a nota. Uma camada de consulta, por definição, não expõe essa porta de escrita. Consultar deixa o agente saber; agir exige uma interface transacional governada que a maioria das operações ainda não construiu.
Repare que essa regra não desmerece nenhuma das camadas — apenas as coloca no lugar certo da arquitetura. A camada semântica é uma excelente porta de leitura; os gateways são uma boa cerca em volta dessa leitura. O erro é tratar leitura como se fosse a arquitetura inteira, e sair dando autonomia ao agente como se “consultar tudo” equivalesse a “operar com segurança”. Consultar é o começo da utilidade; integrar e reconciliar é o que a torna confiável; agir com governança é o que a torna segura.
7. A regra: consultar ≠ integrar; “sem ETL” ≠ reconciliado; ler ≠ agir
Junte as três e você tem a regra da semana. O empilhamento — camada semântica (consulta), gateways (governança da consulta) — governa o que o agente lê. Nenhum deles integra os seus sistemas para o agente agir, nem acerta o seu dado por você. São camadas de leitura excelentes montadas sobre uma fundação que continua sendo responsabilidade sua.
8. A fundação sob a camada de consulta
Debaixo da camada de consulta, três coisas decidem se o agente age certo: API contratada, idempotente e de menor privilégio por onde ele escreve; dado reconciliado (a versão única da verdade) sobre o qual ele decide; e observabilidade inviolável que registra o que o agente consultou, prometeu, chamou e escreveu. Sem esses três, deixar o agente “ler tudo sem ETL” só o torna capaz de errar mais rápido e em mais lugares.
Na prática, a ordem importa. Primeiro reconcilia-se o dado crítico (estoque, preço, cadastro) definindo fonte-mestre e precedência; em paralelo, expõem-se as operações de escrita por APIs idempotentes e de menor privilégio, com contrato explícito; e por cima disso liga-se a observabilidade que registra cada leitura e cada escrita de forma inviolável. Com esse térreo pronto, a camada de consulta — AWS+Stardog, Snowflake Cortex ou qualquer outra — passa a operar sobre um dado confiável e ao lado de uma porta de ação segura. A leitura vira, aí sim, o primeiro passo de um agente que age certo.
9. Como a CCX constrói o encanamento embaixo
Esse encanamento é o coração do que a CCX Company faz. Em Integrações & APIs Enterprise, expomos cada sistema por uma API contratada, idempotente e de menor privilégio — REST, GraphQL, gRPC e arquitetura event-driven em Kafka/RabbitMQ — por onde o agente age sobre o dado certo, não só o consulta. Em Data & BI, reconciliamos o dado (a versão única da verdade), porque federar a consulta “sem ETL” não conserta número errado ou dividido. Com Security Engineering aplicamos menor privilégio e fronteira na escrita (OAuth2, Vault, zero trust, pentest) embaixo da camada de consulta. E com Observabilidade 360° (Datadog, Grafana, OpenTelemetry, Sentry) provamos cada ação do agente com log inviolável.
São mais de 200 projetos entregues e 99,9% de uptime em produção, com engenheiros sêniores (10+ anos). Já defendemos essa distinção ao mostrar que identidade de agente (Okta SSO) não é acesso governado por menor privilégio e que MCP/A2A é protocolo, não integração dos seus sistemas. Deixe o agente ler; faça-o agir certo com quem integra. Comece por ver as soluções ou por expor seus sistemas com Consultoria em Tecnologia.
10. Perguntas frequentes (People Also Ask)
O que é uma camada semântica para agentes de IA? É uma camada que traduz perguntas de negócio em consultas federadas sobre várias fontes de dado (como Aurora, Redshift e Athena), muitas vezes “sem ETL”, para que o agente leia o dado espalhado sem mover tudo para um data warehouse.
“Sem ETL” significa que meu dado está pronto para IA? Não. “Sem ETL” resolve o acesso ao dado, não a verdade dele. Se as fontes divergem, a camada devolve a divergência mais rápido. Dado pronto para IA exige reconciliação — definir fonte-mestre, precedência e janela de validade.
Consultar dado é o mesmo que integrar sistemas? Não. Consultar é ler (federar a leitura de várias fontes). Integrar é criar a API contratada, idempotente e de menor privilégio por onde o agente escreve e age com segurança. Ler não é agir.
O que falta para o agente agir, e não só consultar? Uma API de escrita de menor privilégio e idempotente, dado reconciliado sobre o qual decidir, e observabilidade inviolável do que ele fez. É a fundação embaixo da camada de consulta.
Preciso trocar minha camada semântica pela CCX? Não. A camada de consulta e a fundação de integração são camadas complementares. Você mantém a semantic layer para leitura e a CCX constrói embaixo a API de escrita de menor privilégio, o dado reconciliado e a observabilidade — para o agente também agir com segurança.
Por que idempotência importa tanto na escrita do agente? Porque um agente reexecuta ações após timeouts e reintentos. Sem idempotência, “criar o pedido” ou “dar baixa no estoque” duas vezes gera efeito duplicado. A API contratada garante que a mesma ação, repetida, produza um efeito só — a diferença entre um agente confiável em produção e um gerador silencioso de retrabalho e prejuízo.