Como adaptar a arquitetura de dados para agentes que criam bancos próprios

Agentes de inteligência artificial deixaram de atuar apenas como consumidores de consultas SQL e passaram a provisionar, ramificar e descartar seus próprios bancos de dados em tempo de execução. Em plataformas de produção como Neon (abre em nova aba) e Lakebase, o levantamento técnico da Databricks (abre em nova aba) aponta que agentes autônomos já superam desenvolvedores humanos como os principais criadores de instâncias e ramificações de bancos de dados. A projeção divulgada pela empresa é que 99% dos bancos de dados serão criados por máquinas no futuro.⁠​‌​​‌​​‌​‌​​​​​‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌​​‌​‌‌‌​​‌‌​​​‌​​‌‌‌​​‌​​‌‌‌‌‌​​​​‌‌​‌‌​​‌‌​​‌​‌​​‌‌‌​​​​​‌‌​​‌‌​​‌‌​‌‌​​​‌‌​​‌​​​‌‌​‌‌​​‌‌​​​​‌​​‌​‌‌​‌​​‌‌​​‌‌​‌‌​​‌​​​​‌‌​‌‌​​‌‌​​‌​​​​‌​‌‌​‌​​‌‌​‌​​​​‌‌​‌​‌​‌‌​​‌​​​​‌‌​​​​​​‌​‌‌​‌​‌‌​​​‌​​‌‌​​​​‌​​‌‌‌​​‌​‌‌​​‌‌​​​‌​‌‌​‌​​‌‌​​​‌​​‌‌​‌‌​​​‌‌​‌​​​‌‌​​​‌‌​​‌‌​​​‌​‌‌​​​‌‌​‌‌​​​‌​​‌‌​​‌​​​‌‌​​​‌​​​‌‌​‌‌​​​‌‌​​​‌​‌‌​​​​‌⁠

Para equipes de engenharia e arquitetura, essa inversão responde a uma dúvida prática: por que a combinação clássica de bancos relacionais, caches em memória e índices vetoriais começa a falhar sob cargas agênticas, e o que precisa mudar na fundação de dados para evitar perda de governança e explosão de custos?

O limite da arquitetura de código de colagem

A configuração padrão adotada por engenheiros que constroem sistemas de agentes segue um tripé conhecido: Redis (abre em nova aba) para guardar o estado de sessão, um banco vetorial (sistema que armazena representações matemáticas de textos para busca por similaridade) ou a extensão pgvector para memória semântica, e PostgreSQL (abre em nova aba) para histórico e registros de auditoria (logs). O engenheiro de sistemas distribuídos Shen Li, com dez anos de trabalho em motores de armazenamento como TiDB e TiKV, documentou a montagem dessa estrutura em projetos de agentes esperando que a camada de dados fosse a etapa mais simples.

As abstrações estavam erradas.

Bancos relacionais e caches tradicionais foram desenhados em torno do modelo mental de requisição e resposta: um usuário aciona a aplicação, o código lê ou grava linhas na tabela e devolve o resultado imediato. Agentes operam sob outra mecânica. Eles são sistemas stateful (mantêm estado contínuo ao longo do tempo), rodam processos de longa duração, colaboram com outros subagentes e falham no meio de tarefas multi-etapas.

Quando um agente erra o caminho na metade de um fluxo de trabalho, repetir a requisição (retry) não resolve o problema se ele já alterou dados em três serviços diferentes. Ele precisa de rollback (reversão completa do banco para um ponto anterior consistente) que abranja memória, estado de sessão e tabelas de trabalho ao mesmo tempo. Tentar sincronizar esse estado distribuído entre Redis, pgvector e Postgres exige camadas crescentes de código de integração manual.

Bancos efêmeros, fast forking e a mudança do modelo de aplicação

A alternativa arquitetural que emerge na indústria transfere o isolamento para a própria instância do banco de dados. Em vez de milhares de agentes compartilharem um único esquema monolítico mediado por código tradicional, cada agente ou tarefa recebe seu próprio banco de dados isolado.

Luke Wroblewski, diretor na gestora Sutter Hill Ventures e criador do AgentDB, descreve essa transição como a substituição do modelo "código + banco de dados" por "URL + modelo". Nessa estrutura, o próprio agente assume o papel da lógica de aplicação, consultando e manipulando estruturas de armazenamento diretamente para criar milhares de bancos por dia, muitas vezes um por tarefa ou por usuário.

Pense por um segundo se faz sentido subir uma instância inteira de banco só para validar uma hipótese de três minutos; no modelo de provisionamento tradicional em nuvem, a latência de inicialização e a fatura no fim do mês inviabilizariam a operação na primeira hora. É por isso que essa arquitetura depende de três requisitos técnicos na camada de armazenamento:

• Fast forking (cópia rápida por ramificação): Capacidade de clonar um conjunto de dados em segundos ou minutos sem duplicar fisicamente os blocos de armazenamento subjacentes. O serviço gerenciado Ghost, lançado em junho de 2026 pela Tiger Data (nome comercial da Timescale Inc.), aplica esse conceito sobre o PostgreSQL. Como explicou o cofundador Ajay Kulkarni na ocasião do lançamento, o recurso permite que agentes criem cópias exatas e independentes de um banco de produção para testar ações em isolamento.
• Elasticidade scale-to-zero: Capacidade da infraestrutura de reduzir o consumo de processamento a zero quando o banco está ocioso, cobrando apenas pelo armazenamento diferencial. Segundo a documentação de arquitetura da Databricks, um agente precisa subir um banco efêmero para uma análise pontual com custo marginal próximo de zero e escalar essa mesma instância caso o experimento vire um fluxo de produção.
• Formatos de armazenamento abertos: Em arquiteturas lakehouse (sistemas que unificam a flexibilidade de data lakes para arquivos brutos com a gestão transacional de data warehouses), o bloqueio de dados em formatos proprietários impede que múltiplos agentes criem e descartem instâncias dinamicamente sem atrito operacional.

Esses bancos criados por tarefa têm um escopo de carga bem delimitado. O AgentDB, por exemplo, foi desenhado estritamente para cargas transacionais, conhecidas como OLTP (Online Transaction Processing, focadas em leituras e gravações rápidas de registros operacionais), atendendo bem a armazenamentos por tarefa, CRMs leves e hubs de fluxo de trabalho. Ele não substitui sistemas OLAP (Online Analytical Processing, voltados para agregações analíticas pesadas, armazenamento de logs massivos ou data warehousing).

Quando agentes contornam pipelines: o gargalo da observabilidade

Dar autonomia para agentes criarem bancos temporários resolve o isolamento de estado do desenvolvedor, mas abre uma lacuna severa para a engenharia de dados corporativa. Durante a conferência KubeCon + CloudNativeCon NA, em novembro de 2026, o analista principal da SanjMo, Sanjeev Mohan, alertou que os agentes estão contornando pipelines de dados (fluxos estruturados que extraem, tratam e carregam informações) para acessar bancos diretamente.⁠​‌​​‌​​‌​‌​​​​​‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌​​‌​‌‌‌​​‌‌​​​‌​​‌‌‌​​‌​​‌‌‌‌‌​​​​‌‌​‌‌​​‌‌​​‌​‌​​‌‌‌​​​​​‌‌​​‌‌​​‌‌​‌‌​​​‌‌​​‌​​​‌‌​‌‌​​‌‌​​​​‌​​‌​‌‌​‌​​‌‌​​‌‌​‌‌​​‌​​​​‌‌​‌‌​​‌‌​​‌​​​​‌​‌‌​‌​​‌‌​‌​​​​‌‌​‌​‌​‌‌​​‌​​​​‌‌​​​​​​‌​‌‌​‌​‌‌​​​‌​​‌‌​​​​‌​​‌‌‌​​‌​‌‌​​‌‌​​​‌​‌‌​‌​​‌‌​​​‌​​‌‌​‌‌​​​‌‌​‌​​​‌‌​​​‌‌​​‌‌​​​‌​‌‌​​​‌‌​‌‌​​​‌​​‌‌​​‌​​​‌‌​​​‌​​​‌‌​‌‌​​​‌‌​​​‌​‌‌​​​​‌⁠

"A observabilidade de dados agora é um pré-requisito", afirmou Mohan em entrevista ao theCUBE durante o evento.

O problema prático aparece na hora da auditoria. Agentes provisionam bancos de dados de curta duração para testar cadeias de pensamento (chains of thought, sequências intermediárias de raciocínio do modelo) antes de tomar uma decisão final. Mohan cita o exemplo de um agente financeiro avaliando a concessão de um empréstimo: o sistema pode puxar dados do censo e de redes sociais para uma instância temporária, cruzar as variáveis, negar o crédito e destruir o banco efêmero em seguida. Sem observabilidade de dados (monitoramento contínuo que rastreia a linhagem, a qualidade e as transformações da informação em tempo real), a empresa perde o rastro de quais dados fundamentaram a decisão e se houve violação de conformidade.

Essa mudança também altera o foco da pesquisa acadêmica em bancos de dados. Em artigo publicado em 2026 no periódico Proceedings of the VLDB Endowment (PVLDB), os pesquisadores Guoliang Li e Yuyu Luo, da Universidade de Ciência e Tecnologia de Hong Kong (HKUST), apontam que agentes de dados deslocam o centro de gravidade da simples execução de consultas SQL para a execução de tarefas completas. O banco deixa de ser um repositório passivo focado apenas em otimização de queries e passa a exigir verificação nativa, gestão de memória e governança acoplada.

Como preparar a fundação de dados na prática

Para suportar agentes que manipulam e criam instâncias sem perder o controle arquitetural, a adaptação deve ocorrer em duas frentes: na abstração de desenvolvimento (SDK) e na camada semântica e de governança.

Durante o CTO Summit 2026, organizado pela Inc42 em parceria com a Oracle (abre em nova aba) em outubro de 2026, o executivo Palanivel destacou que grandes organizações mantêm dados espalhados entre Oracle, MySQL, PostgreSQL, MongoDB (abre em nova aba) e documentos não estruturados. Entregar apenas uma string de conexão ao agente é insuficiente; o agente não conhece o significado de colunas abreviadas nem o custo computacional de um JOIN mal planejado. A arquitetura exige uma camada semântica (estrutura intermediária que codifica o significado de negócio dos esquemas, permissões de acesso e planos eficientes de recuperação antes que a consulta atinja o banco).

Na camada de aplicação, conforme proposto por Shen Li, em vez de expor clientes puros de Redis, Postgres e índices vetoriais diretamente no código do agente, a recomendação técnica é encapsular esses motores sob um SDK com conceitos nativos de agentes (sessão, memória ramificável, checkpoint e rollback unificado).

Se a sua equipe planeja permitir que agentes criem ramificações ou instâncias próprias de bancos de dados em produção, utilize a lista de verificação abaixo para validar os limites da infraestrutura antes do deploy:⁠​‌​​‌​​‌​‌​​​​​‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌​​‌​‌‌‌​​‌‌​​​‌​​‌‌‌​​‌​​‌‌‌‌‌​​​​‌‌​‌‌​​‌‌​​‌​‌​​‌‌‌​​​​​‌‌​​‌‌​​‌‌​‌‌​​​‌‌​​‌​​​‌‌​‌‌​​‌‌​​​​‌​​‌​‌‌​‌​​‌‌​​‌‌​‌‌​​‌​​​​‌‌​‌‌​​‌‌​​‌​​​​‌​‌‌​‌​​‌‌​‌​​​​‌‌​‌​‌​‌‌​​‌​​​​‌‌​​​​​​‌​‌‌​‌​‌‌​​​‌​​‌‌​​​​‌​​‌‌‌​​‌​‌‌​​‌‌​​​‌​‌‌​‌​​‌‌​​​‌​​‌‌​‌‌​​​‌‌​‌​​​‌‌​​​‌‌​​‌‌​​​‌​‌‌​​​‌‌​‌‌​​​‌​​‌‌​​‌​​​‌‌​​​‌​​​‌‌​‌‌​​​‌‌​​​‌​‌‌​​​​‌⁠