O fim da era dos apps? A tela não morre, ela vira o lugar onde você aprova

Este texto foi rascunhado por um agente. Ele leu a transcrição de um vídeo, escreveu, desenhou a capa e mandou para revisão. Ficou parado numa tela do Blogs, numa fila chamada "Em revisão", até eu ler, discordar de metade, pedir para refazer e só então clicar em publicar.

Guarde essa cena, porque ela é o ponto que o vídeo deixa de fora.

O vídeo é "The end of the app era: What comes next?", do Nate B Jones. É uma boa análise, e eu concordo com o diagnóstico. Mas ele fala do lugar de quem compra software numa empresa grande, e eu opero do lugar oposto: sozinho, com agentes fazendo boa parte do trabalho todos os dias. Daqui, algumas conclusões dele mudam de sinal.

O que o vídeo diz, em um minuto

O agente passou a fazer a parte do trabalho que fazia você abrir um aplicativo: achar e organizar informação. Com isso, o valor de cada software fica exposto, e ele propõe olhar tudo em três camadas: dados (quem guarda a informação que não existe em outro lugar), fluxo (quem executa com regra o que não pode errar, como folha de pagamento) e agente (quem faz o trabalho com o seu contexto).

O exemplo central é uma recrutadora que deixou de abrir a ferramenta de recrutamento porque o agente monta a lista de candidatos direto dos dados. A ferramenta perdeu valor, o fornecedor de dados não, e o agente, depois de meses aprendendo os critérios dela, virou a peça mais difícil de trocar. O outro exemplo é a DoorDash, que aceita que você nunca mais abra o aplicativo dela, desde que o pedido feito pelo seu assistente continue passando por ela.

Até aqui, concordo. Agora, onde eu não concordo e o que eu acho que falta.

Primeiro: a tela não morre, ela muda de função

O título do vídeo fala em fim da era dos apps. O que eu vejo é outra coisa: a tela deixa de ser o lugar onde você faz e passa a ser o lugar onde você aprova.

No meu dia, quase nada é feito por mim dentro de uma tela. Mas eu abro telas o tempo todo: para ler o rascunho que o agente deixou, aprovar o e-mail que ele quer mandar, conferir o que ele mudou. O Assistant, que é um dos produtos da linha Agents, pede aprovação antes de enviar, pagar, apagar ou publicar. O Blogs deixa um agente escrever e mandar para revisão, mas quem publica é uma pessoa. Essas telas não ficaram menos importantes. Ficaram mais.

A consequência prática: o software que vai perder não é "o que tem interface". É o que tem a interface errada, desenhada para alguém que faz tudo à mão. O que vai ganhar é o que redesenha a tela como uma fila de decisões: o que o agente fez, o que espera você, o que mudou desde ontem.

Segundo: falta uma camada, a de quem responde

Dados, fluxo e agente explicam o que um software entrega. Não explicam por que uma empresa confia nele. Para isso existe uma quarta camada, que o vídeo só toca de passagem, quando diz que a Salesforce e a Microsoft querem ser o "painel de controle" dos agentes: quem pode fazer o quê, quem aprovou e onde fica o registro.

Eu trataria isso como camada própria, não como estratégia de fornecedor. Quando um agente pode mandar e-mail em seu nome, mexer no seu DNS ou mudar o orçamento de um anúncio, a primeira pergunta deixa de ser "ele faz bem?" e passa a ser "quem responde quando ele erra?". O produto que responde bem a isso, com permissão por tipo de ação, aprovação no meio e um histórico que diz quem decidiu, é o que entra na empresa. O que não responde fica no teste.

Terceiro: ficar preso ao agente é uma escolha

Esta é a parte em que eu mais discordo. O vídeo trata como inevitável que o agente que você treinou vire uma prisão, e a recomendação dele é conversar com o seu gestor antes que alguém troque o fornecedor de IA. É um bom conselho para o sintoma. A causa é outra: o que você ensinou ficou guardado dentro de um fornecedor.

Não precisa ser assim. O que faz o meu agente trabalhar do meu jeito são três coisas, e nenhuma delas mora no fornecedor do modelo:

• As regras ficam em arquivos de texto que o agente lê no começo de cada sessão: como eu escrevo, o que nunca fazer, como cada projeto funciona.

• As habilidades ficam em arquivos também, uma por tarefa repetida.

• A memória fica num espaço do Brain, o produto de memória da linha Agents, com um endereço MCP que qualquer cliente compatível lê.

Se amanhã eu trocar de modelo, perco o costume, não o conhecimento. O teste que eu proponho é simples: se o seu fornecedor de IA mudasse na sexta, você trabalharia normalmente na segunda? Se a resposta é não, o problema não é o fornecedor. É onde você guardou o que ensinou.

Quarto: para quem trabalha sozinho, a conclusão se inverte

O vídeo fala com quem compra software para centenas de pessoas e precisa negociar com fornecedores. Para quem trabalha sozinho ou num time enxuto, o exemplo mais importante do vídeo é o que passa mais rápido: o escritório de recrutamento de duas pessoas que, em vez de comprar mais uma ferramenta pronta, pagou só pelo dado e montou o próprio fluxo em cima, com uma habilidade para o Claude.

Esse é o caminho que eu sigo. Construir um fluxo em cima de dados ficou barato, e a ferramenta pronta que só junta dados e mostra numa tela deixou de valer o que custa. Para a empresa grande, a pergunta do vídeo é "qual fornecedor eu escolho?". Para quem trabalha sozinho, é "o que eu ainda preciso comprar, se o agente monta o resto?". Na maioria das vezes, a resposta é: o dado e a execução que não pode errar. O resto se constrói.

Quinto: a vitrine passou a ser o texto que a máquina lê

O vídeo diz que estar ao alcance de um agente, por MCP ou API, é o mínimo para ser considerado, e não o motivo para continuar sendo pago. Concordo, e iria além: quando quem escolhe é um agente, ser entendido do jeito certo vira o diferencial.

Um agente que entende mal o seu produto não manda ninguém, ou pior, promete o que você não tem. Por isso cada produto meu publica um llms.txt, um texto para máquinas que diz o que existe, o que não existe e o que não se pode afirmar. É a página de vendas que ninguém vê, e que cada vez mais decide quem é recomendado.

Uma ressalva sobre o próprio vídeo

Vale ler o vídeo como hipótese, não como prova. Os casos são histórias anonimizadas, sem números. E os anúncios de empresas que ele cita, como o modelo da Salesforce ainda em piloto e o agente da Microsoft em prévia, mostram para onde essas empresas querem ir, não para onde os clientes já foram. O quadro das três camadas é útil exatamente por isso: ajuda a pensar sem depender de quem tem razão sobre o futuro.

O que eu faria nesta semana

1. Liste os aplicativos que você paga e não abriu no último mês. Para cada um, pergunte se ele guarda um dado que só ele tem ou executa algo que não pode errar. Se não faz nenhum dos dois, é o primeiro a sair.

2. Tire as suas instruções de dentro do chat. Escreva num arquivo como você quer que o agente trabalhe, e faça ele ler esse arquivo.

3. Olhe as telas que você mais abre e veja se elas servem para aprovar trabalho de outro. As que não servem vão incomodar cada vez mais.

4. Se você vende software, leia o que um agente lê sobre o seu produto. Se não existe nada escrito para ele, ele está adivinhando.

Perguntas frequentes

Então os aplicativos vão acabar?

Não. A parte de achar e arrumar informação sai da tela e vai para o agente. A parte de aprovar, conferir e responder pela ação fica, e ganha peso. Morre a tela feita só para trabalho manual.

Como eu guardo o que ensinei ao agente fora do fornecedor?

Escreva as regras em arquivos de texto, transforme tarefas repetidas em habilidades e guarde a memória num lugar que qualquer cliente MCP consiga ler. Assim, trocar de modelo muda o motor, não o que ele sabe sobre você.

O que é essa camada de quem responde?

É o conjunto de permissão, aprovação e registro: quem pode fazer o quê, o que pede confirmação de uma pessoa e onde fica o histórico de cada decisão. É ela que faz alguém confiar a um agente uma ação que não tem volta.

Fontes

• The end of the app era: What comes next?, Nate B Jones, AI News & Strategy Daily (YouTube)

• Brain, a memória dos agentes (llms.txt)

• Assistant, bots que pedem aprovação (llms.txt)