Se agents são os novos apps, algo tem que ser o novo OS

Entregue a um desenvolvedor uma CPU crua e peça que ele lance um processador de texto até sexta-feira. Sem arquivos, sem janelas, sem proteção de memória, sem jeito de falar com o disco, só um conjunto de instruções e um clock. Ele vai passar os primeiros seis meses não escrevendo o processador de texto. Vai passá-los construindo a camada que já deveria ter existido: um jeito de armazenar um documento, um jeito de desenhar na tela, um jeito de impedir um programa de rabiscar por cima de outro. Ele vai, em outras palavras, acidentalmente escrever um sistema operacional antes de chegar a escrever o app.

É mais ou menos onde todo mundo construindo com AI agents está parado agora. Temos a CPU. Estamos fingindo que ela é o computador.

Apps precisam de um OS por baixo, e uma API de modelo não é um OS mais do que uma CPU é o Windows.

A categoria que todo mundo está repetindo

Há uma frase que você ouve em toda conferência agora: agents são os novos apps. É uma boa frase, e achamos que está correta. Uma década atrás você construía uma empresa amarrando apps SaaS, um para email, um para o CRM, um para faturamento. A próxima década você vai construí-la compondo agents: um que cuida do inbound, um que persegue cobranças, um que observa os números e sinaliza a anomalia.

Mas as pessoas repetindo a frase ficam parando uma camada cedo demais. Elas tratam “agent” como a pilha inteira, como se um app fosse a única coisa que um computador precisa. Não é, e nunca foi.

Um app não é um computador. É o andar de cima de um. Todo mundo está lançando andares de cima e se apoiando no ar.

Apps não rodam no nada. Eles rodam num sistema operacional do qual ninguém fala precisamente porque ele funciona, ele os agenda, lembra seu estado, deixa-os alcançar o hardware, e os impede de corromper um ao outro. Tire essa camada e um “app” é só uma ideia esperta sem lugar para se apoiar. Então se agents são de fato os novos apps, a pergunta mais importante é a que ninguém está correndo para responder: qual é o novo OS?

A resposta ingênua: o modelo é o OS

Aqui está a resposta que a maioria dos times alcança primeiro, porque ela está bem ali. O modelo é tão capaz, ele raciocina, escreve código, chama ferramentas, que parece a plataforma inteira. Então você liga seu agent direto a uma API de modelo, dá a ele um system prompt, entrega umas ferramentas, e lança. O modelo é o cérebro. O cérebro é o computador. O que mais você precisa?

Para uma demo, nada. Para uma empresa de verdade, quase tudo.

Uma API de modelo é uma CPU. Uma extraordinária, mas uma CPU. Ela faz exatamente uma coisa, brilhantemente e sem estado: você entrega tokens, ela te entrega tokens de volta, e então te esquece completamente. Ela não tem memória da última conversa. Não tem clock, então não consegue decidir fazer nada na terça. Não tem ideia de quais ferramentas existem na sua empresa ou quais delas este agent específico tem permissão de tocar. Ela não consegue dizer se o agent agindo neste segundo pertence a você ou à empresa do outro lado da rua cujos dados nunca, jamais, podem cruzar para os seus.

Imagine o que acontece quando você constrói a empresa direto na CPU. Cada agent reinventa memória do zero, mal, no próprio prompt. Cada agent reaprende quais ferramentas existem sendo informado de novo, toda única vez. Ninguém agenda nada, então o sistema inteiro volta a esperar um humano cutucá-lo. E no dia em que você tem dois clientes, você descobre que o modelo nunca teve um conceito de de quem é este agent, essa fronteira sempre ia ser o seu trabalho, e você não a tinha construído.

Isso não é uma feature faltante. É um andar faltante do prédio. O modelo te deu compute cru e a ilusão de uma plataforma, e o gap entre os dois é exatamente o sistema operacional que ninguém escreveu.

O que o OS de fato tem que prover

Então vamos construir o andar faltante de propósito. O movimento útil é pegar as quatro coisas que um sistema operacional de verdade faz por um app de verdade e perguntar, claramente, o que cada uma se torna quando o app é um agent. O mapeamento é quase suspeitosamente limpo.

Um modelo de processo: agents são processos, não prompts

Num computador, o OS não roda um programa por vez e o esquece no momento em que ele fecha. Ele roda muitos, os isola, reinicia os que crasham, e mantém um registro do que cada um fez. Um processo é uma coisa de primeira classe com um ciclo de vida, não um one-shot.

O agent ingênuo é o oposto: uma única chamada, disparada e esquecida. Ele roda uma vez, retorna texto, e não deixa nenhum traço que alguém consiga auditar depois. Isso é bom para um chatbot e inútil para uma empresa, porque uma empresa precisa saber o que agiu, quando, em nome de quem, e o que tocou. Um agent OS trata cada agent como um processo de verdade, algo que você consegue iniciar, supervisionar, observar ao vivo, repetir quando dá errado, e responsabilizar. A unidade de trabalho para de ser um prompt e vira uma coisa rodando com um histórico.

Gerenciamento de memória: um cérebro, não um prompt maior

O conserto ingênuo para “o modelo esquece” é enfiar mais no prompt. Mais histórico, mais contexto, mais do ontem colado no topo. Funciona até não funcionar, o que é logo, a janela enche, o custo sobe, e o modelo ainda não consegue lembrar de nada que você não tenha carregado manualmente nesta exata chamada.

Isso não é memória. Isso é uma pessoa relendo o diário inteiro em voz alta antes de cada frase.

Um OS de verdade gerencia memória para que um programa não comece do zero toda vez. O equivalente do agent é uma camada de memória que o OS é dono, não o prompt: estado durável que lembra que o cliente disse sim a esta proposta, que a renovação aterrissa mês que vem, que este agent já tentou aquela abordagem e ela falhou. O modelo permanece sem estado, isso é bom, CPUs também são sem estado. O lembrar desce um andar, para a camada construída para segurá-lo.

Drivers: um registro de ferramentas, não mil integrações

Um driver é o truque mais esperto num sistema operacional: o seu programa diz “imprima”, e simplesmente funciona, mesmo que o programa nunca tenha ouvido falar da sua impressora específica. O OS faz a ponte uma vez, para todo mundo.

Sem essa camada, cada agent re-resolve acesso a ferramentas à mão. Este agent recebe o calendário ligado de um jeito, aquele agent o recebe ligado de outro, e quando a API do calendário muda você vai consertar em catorze lugares. É o inferno-de-integração que consumiu a última era do software, silenciosamente renascido um agent por vez. A resposta do OS é um único registro de ferramentas e a permissão de usá-las, o agent diz “leia o inbox” ou “poste no canal”, e a camada por baixo cuida de qual ferramenta, quais credenciais, qual conta, se este agent está sequer autorizado. Escreva a ponte uma vez. Todo agent a atravessa.

Isolamento: a fronteira de tenant que o modelo nunca teve

Esta é a primitiva que as pessoas pulam, e é a que acaba com empresas. Um OS de verdade impede um processo de ler a memória privada de outro, essa fronteira é a razão pela qual você consegue rodar programas não-confiáveis lado a lado e dormir à noite.

Uma API de modelo não tem tal conceito. Ela não consegue te dizer que o agent rodando neste segundo pertence a um cliente e os dados que ele está prestes a ler pertencem a outro. Se você não construiu aquela parede, não há parede. E “adicionamos multi-tenancy depois” é a frase que precede a brecha, porque não é uma feature que você polvilha por cima, é a fundação sobre a qual a casa inteira se apoia. O OS tem que impor, no andar abaixo de cada agent, que os agents de um cliente nunca conseguem ver o mundo de outro cliente. Não por convenção. Por construção.

Por que “só use o framework” também não é o OS

Há uma segunda resposta ingênua que vale levar a sério, porque é mais esperta que a primeira. Tudo bem, você diz, eu não vou construir sobre o modelo cru, vou pegar um agent framework. Esse é o OS.

Não é, e a razão vale ser precisa. Um framework é uma biblioteca que você chama. Um sistema operacional é uma coisa sobre a qual você roda. A diferença soa acadêmica até você senti-la: uma biblioteca te ajuda a escrever um agent bem, no seu processo, na sua máquina. Ela não agenda cem agents numa frota, não é dona da memória durável que eles compartilham, não impõe a fronteira entre os seus clientes, e não continua rodando quando o seu código não está. Um framework é um conjunto muito bom de ferramentas elétricas. Não é o prédio que elas são usadas para construir.

Você consegue distinguir os dois por um teste simples. Quando você fecha o seu laptop, ele para? Uma biblioteca para, ela só existia dentro do seu programa em execução. Um sistema operacional continua, porque ser sempre-ligado é o ponto inteiro. Essa é a linha entre uma ferramenta que você pega e uma plataforma sobre a qual você se apoia.

Apps precisam de um OS por baixo, e uma API de modelo não é um OS mais do que uma CPU é o Windows.

Uma nota de campo sobre o andar que não estava lá

Aqui está um modo de falha que todo time construindo sobre agents encontra, geralmente perto do segundo cliente de verdade.

A primeira versão funciona lindamente. Um agent, um usuário, ligado direto ao modelo, fazendo algo genuinamente útil. Ela faz uma demo tão boa que todo mundo esquece que está se apoiando no ar. Aí você adiciona o segundo cliente, e as perguntas começam a chegar todas de uma vez, as perguntas que um sistema operacional teria respondido antes de você jamais perguntar. Qual agent está rodando agora, e para quem? Onde a memória dele vive para que sobreviva a um restart? Quando a ferramenta de calendário muda, quantos lugares quebram? O que impede o agent do cliente A de jamais tocar os dados do cliente B? Nenhuma dessas é uma pergunta de agent. Todas são perguntas de OS, e sempre iam vencer.

A lição não é que a versão inicial estava errada. É que o sistema operacional é a parte que você não vê até estar faltando, e quando está faltando, você está construindo-o sob pressão, em produção, com clientes assistindo. O movimento disciplinado é construir o andar primeiro, de propósito, enquanto é barato. O modelo é a CPU que você aluga. O OS é a coisa que você de fato tem que ser dono.

A virada: o OS libera a parte que só você consegue fazer

Aqui está para o que tudo isto de fato serve, e não é a arquitetura.

Quando não há sistema operacional por baixo dos seus agents, você é o sistema operacional. Você é quem rastreia qual agent fez o quê. Você é a memória, segurando na sua cabeça o contexto que o modelo fica esquecendo. Você é a camada de integração, ligando cada ferramenta à mão. Você é a fronteira, a última linha de defesa garantindo que nada cruze onde não deveria. É a mesma armadilha em que o founder sempre esteve, só que um nível acima na pilha, e é a coisa menos alavancada na qual uma pessoa afiada consegue gastar um dia.

Construa o OS direito e todos os quatro desses trabalhos saem de você e descem um andar. O que sobra é a parte que nenhum scheduler, nenhuma camada de memória, nenhum registro consegue fazer: decidir quais agents valem ser construídos, para o que eles devem servir, o que “bom” significa para as pessoas que você serve. Esse é o trabalho para o qual um sistema operacional sempre foi feito para te liberar, ele roda o que tem que rodar para que você possa pensar sobre o que vale a pena rodar afinal. O primeiro OS fez isso pelos seus arquivos. O próximo faz pelos agents que agora fazem o trabalho.

---

É isso que estamos construindo na Apollo Space: o sistema operacional por baixo dos agents, para que você possa desenhar o que a empresa faz em vez de ser a coisa que a segura junta. Se agents são os novos apps, alguém tem que construir o andar sobre o qual eles se apoiam. Preferimos que seja uma fundação que você consiga ver do que a que você só nota quando ela se foi.