A aplicação não precisa ser a casa dos dados

Um dos efeitos mais interessantes dos agentes de IA talvez não seja apenas produzir mais código. É tornar plausível que uma ferramenta específica seja criada para uma tarefa, adaptada quando a tarefa muda e descartada quando deixa de ser útil.

Se uma tabela resolve o problema hoje e um cronograma for melhor amanhã, por que as duas experiências precisariam pertencer ao mesmo aplicativo? A pergunta parece pequena, mas mexe com uma suposição antiga da computação pessoal: a de que o aplicativo é o lugar onde os dados vivem.

A aplicação virou o lugar onde tudo fica

Imagine que uma pessoa queira acompanhar uma reforma: fornecedores, orçamentos, documentos e prazos. O caminho habitual é procurar um aplicativo que reúna banco de dados, regras, telas e integrações.

No começo, essa organização é conveniente. Há um lugar para cadastrar um fornecedor, anexar um orçamento e acompanhar uma pendência. Com o tempo, porém, o aplicativo passa a ser mais do que uma interface. Ele também guarda os objetos, define o significado dos campos, decide quais operações existem e acumula o histórico do trabalho.

Podemos representar o modelo assim:

Aplicativo
 ├── interface
 ├── regras
 ├── banco de dados
 ├── semântica
 └── histórico

Essa concentração resolve um problema de distribuição: a mesma equipe controla o produto inteiro. Também cria outro problema para o usuário. Se a próxima ferramenta oferecer uma visão melhor, trocar de aplicativo pode exigir exportar dados, migrar formatos ou reconstruir manualmente relações que só existiam dentro do primeiro sistema.

O dado não desaparece necessariamente. Mas parte do seu significado pode desaparecer junto com a aplicação. Uma lista de tarefas exportada como linhas ainda pode perder vínculos com documentos, histórico de mudanças, permissões e regras que determinavam o que cada estado significava.

A inversão

A hipótese que estou investigando começa invertendo essa relação. Em vez de o aplicativo ser a casa permanente dos dados, ele poderia ser uma projeção temporária sobre um ambiente de dados sob controle técnico do usuário. Isso significa poder conceder e revogar autorizações, exportar os objetos com sua semântica e escolher o cliente que os projeta; não é uma afirmação jurídica sobre a propriedade de todos os bytes.

Camada de dados do usuário
 ├── objetos e relações
 ├── schemas e versões
 ├── identidade e permissões
 ├── registro operacional mínimo
 └── exportação e restauração

        ↑                 ↑
        │                 │
   Aplicação A       Aplicação B       CLI       Dashboard

A aplicação continuaria tendo código. Ela poderia conter uma experiência sofisticada, consultas, fluxos de apresentação e integrações com outros serviços. O que não deveria ficar exclusivo dela são os contratos canônicos que dão significado aos objetos e limitam suas operações.

A mesma nota poderia aparecer num editor hoje, numa tabela amanhã e num painel de pendências depois. Essas interfaces seriam clientes diferentes sobre os mesmos objetos, e não três versões incompatíveis da memória do usuário.

Isso não significa construir um banco gigante com uma tabela para cada coisa da vida. A camada poderia ser formada por serviços ou componentes locais, com namespaces, schemas diferentes e limites de acesso. O ponto é lógico: os objetos canônicos e os contratos que lhes dão significado precisam sobreviver ao ciclo de vida de uma interface específica.

O que precisa sobreviver?

“Os dados continuam lá” é uma condição necessária, mas não suficiente. Para uma aplicação ser substituível, pelo menos quatro coisas precisam atravessar a troca de cliente:

identidade: notas, tarefas e documentos precisam manter identificadores estáveis;
relações: vínculos entre objetos não podem depender de referências internas do aplicativo anterior;
semântica: campos, estados, versões e operações precisam ser compreensíveis por outro cliente;
autoridade: permissões e delegações precisam continuar explícitas, revogáveis e independentes da interface.

Exportar uma planilha pode preservar valores. Não necessariamente preserva o objeto que aqueles valores formavam. Um pacote de portabilidade mais completo precisaria carregar também relações, anexos, versões de schema e informação suficiente para que outro cliente soubesse o que pode fazer com o material restaurado.

Há ainda uma extensão importante para sistemas usados com agentes: a persistência do trabalho em andamento. Se um agente está organizando documentos ou atualizando tarefas, os dados finais talvez não sejam suficientes. Intenção, comandos, erros, checkpoints e proveniência podem ser necessários para que outro agente continue a atividade. Essa é uma camada de execução relacionada, não uma propriedade que o primeiro experimento assume como implementada.

Eu prefiro tratar isso como uma camada de execução relacionada, e não esconder tudo sob o nome “data layer”. Dados, autoridade, execução e experiência se apoiam mutuamente, mas têm responsabilidades diferentes. Se juntarmos tudo numa única abstração, corremos o risco de chamar de portabilidade uma dependência ainda maior de um novo runtime.

Aplicação efêmera não quer dizer aplicação descartável

A palavra “efêmera” pode sugerir código improvisado ou uma interface que não merece manutenção. Não é esse o sentido. Neste texto, quando falo em aplicação A ou B, estou me referindo à projeção ou ao cliente e ao código privado que os acompanha. O runtime e os contratos compartilhados ficam fora dessa remoção.

Uma aplicação pode durar anos e ainda ser efêmera em relação ao ambiente se a continuidade dos objetos não depender exclusivamente dela. O que importa é a dependência, não a idade do software.

Uma definição operacional seria:

Uma aplicação A — entendida aqui como uma projeção ou cliente — é substituível por uma aplicação B quando a remoção de A não elimina os objetos persistentes, sua interpretação semântica mínima ou uma autoridade que deveria ter sido revogada, e B consegue continuar as operações permitidas dentro dos contratos declarados.

Essa definição também mostra por que compartilhar um banco não basta. Dois clientes podem ler a mesma tabela e interpretar seus registros de maneira diferente. A substituição exige um contrato semântico comum: identificadores, relações, invariantes, versões e operações que possam ser descobertos e validados por mais de um cliente.

Isso não significa que um contrato se execute sozinho. Outro cliente ainda precisa de um runtime e de um interpretador compatíveis. A proposta muda a dependência de lugar: do código privado de A para contratos compartilháveis e um runtime que possa ser instalado e versionado independentemente da projeção.

O agente propõe; a camada autoriza

Os agentes tornam mais fácil imaginar uma aplicação montada para uma tarefa específica. Um agente poderia descobrir objetos autorizados, sugerir um schema, compor uma consulta e produzir uma descrição de interface. Um cliente confiável renderizaria essa descrição. As capabilities mencionadas aqui são permissões limitadas por recurso e operação; não são concedidas pelo simples fato de o agente ter produzido código ou texto.

Mas gerar código ou uma tela não deveria conceder autoridade sobre os dados. O fluxo precisa manter uma fronteira explícita:

intenção do usuário
        ↓
agente propõe schema, consulta, comando ou interface
        ↓
camada de identidade e capacidades valida a operação
        ↓
cliente renderiza e executa o que foi autorizado
        ↓
runtime registra a admissão; estado e resposta mostram o desfecho

Essa distinção é importante porque um registro local não é automaticamente um efeito no mundo. Escrever status = enviado não prova que um documento foi enviado. O sistema precisa distinguir a intenção, o comando autorizado, a execução e o efeito observado. No escopo inicial, o runtime registra a admissão da chamada; o estado persistido e a resposta mostram o desfecho. Esse registro operacional não é uma auditoria completa e pode não ser completo durante uma falha.

A interface também não deveria ser o lugar onde a autorização fica escondida. Se a tela gerada pelo agente puder alterar a política, conceder novas permissões ou apagar o registro operacional que a política precisa proteger, a camada de dados deixou de ser a autoridade. Ela virou apenas um banco acessado por código com privilégios excessivos.

A ideia não começa do zero

Essa arquitetura combina perguntas que já aparecem em linhagens diferentes.

O DBOS explora o que muda quando o estado operacional e os serviços de um sistema podem ser persistidos e consultados sobre um banco de dados. O movimento local-first dá linguagem para discutir disponibilidade, longevidade e controle dos dados pelo usuário. O projeto Solid separa aplicações de espaços de dados pessoais e torna identidade e acesso problemas explícitos. A literatura de malleable software investiga ferramentas que podem ser moldadas durante o uso, em vez de permanecerem completamente fechadas.

Cada uma dessas linhas ilumina uma parte do problema. Nenhuma delas, isoladamente, demonstra que um cliente pode ser criado e removido sem perda de continuidade. A pergunta desta pesquisa está justamente na composição: que contratos mínimos permitem que dados, semântica e autoridade sobrevivam enquanto as experiências mudam?

A pergunta que dá para testar

A primeira versão dessa pergunta não precisa começar com sincronização entre dispositivos, colaboração entre usuários ou efeitos externos. Um experimento local e sintético já pode testar a propriedade central:

a aplicação A cria notas e tarefas relacionadas;
suas capacidades são revogadas;
a projeção de A é removida;
a aplicação B recebe uma concessão própria;
B descobre os mesmos objetos e continua uma operação autorizada;
o ambiente é exportado e restaurado em outro diretório.

Isso não provaria que toda aplicação pode ser construída dessa maneira. Mostraria algo mais limitado: dentro de um domínio e de contratos definidos, a remoção de uma interface não precisa equivaler à remoção da memória que ela projetava.

A pesquisa começa por essa propriedade porque ela é observável. Em vez de perguntar se agentes vão substituir todos os aplicativos, podemos perguntar se uma aplicação específica ainda é necessária para que os objetos do usuário continuem existindo e fazendo sentido.

Se o cenário falhar, ele revelará um limite claro da proposta naquele domínio e na configuração avaliada. Se funcionar, ainda será preciso medir o custo: validação, descoberta, autorização, exportação, evolução dos schemas e operação de um ambiente comum podem formar um novo monólito, apenas com outro nome.

A próxima parte da série detalha os contratos que precisam existir entre essa camada, os agentes e os clientes: o que é dado, o que é comando, o que é capacidade e o que significa preservar semântica durante uma troca de aplicação.