Maven Apps: os seus agentes precisam de operadores, não de painéis de interruptores

Um painel de comutação faz exatamente aquilo para que foi ligado: aciona-se o interruptor e obtém-se a mesma resposta fixa, sempre. Peça-lhe que trate de algo fora desse circuito e não consegue, porque não lida com variações, apenas com cablagem.

Um operador é diferente. Dê-lhe um pedido — ligue-me à receção — e ele descobre como: que linha usar, o que fazer se estiver ocupada, o que fazer se o próprio pedido for ambíguo. Não se limita a transmitir o sinal; interpreta-o e age em conformidade.

As Maven Apps são operadores, não painéis de comutação. Quando nos sentámos para construir a framework que suporta a nossa infraestrutura de Apps, fizemos uma aposta deliberada: não construir mais uma camada de integração. Construir uma verdadeira plataforma de aplicações e fazer dos agentes de IA cidadãos de primeira classe nessa plataforma.

Hoje, temos milhares de apps na nossa framework. Sim, inclui apps para os principais sistemas de terceiros, como Salesforce, Zendesk e Notion. Mas inclui também centenas de apps personalizadas em produção, a funcionar em agentes ativos.

Porque é que as integrações básicas ficam aquém

Pergunte a dez fornecedores o que significa «integra com o Salesforce» para o seu produto e obterá dez respostas diferentes, porque um sistema como o Salesforce, o Zendesk ou o Front nunca é uma só coisa. Pode ser:

• Um local onde o seu agente precisa de ir buscar informação (uma base de conhecimento, um histórico de casos)
• Um local onde o seu agente precisa de ir para executar ações (criar um pedido, atualizar um registo, emitir um reembolso)
• Uma superfície onde o seu agente precisa de estar presente (um copiloto de apoio ao agente dentro da consola onde a sua equipa de suporte já trabalha)

Uma «integração com o Salesforce» que só conhece artigos não é o mesmo produto que uma que também consegue registar um caso, e não é o mesmo produto que uma que pode estar dentro da consola do agente como copiloto. Estas capacidades são muitas vezes agrupadas sob a mesma palavra de marketing, cabendo-lhe a si descobrir as lacunas durante a implementação.

É o problema da máquina de venda automática: um menu fixo que funciona exatamente como anunciado até que aquilo de que precisa não esteja na lista — e, nessa altura, já se comprometeu. Não queríamos que as Maven Apps funcionassem assim, por isso construímos a framework em torno da pergunta que realmente está a ser feita (conhecimento, capacidade ou canal) e não em torno de um «conector» genérico.

Maven Apps: mais do que integrações

As Maven Apps podem assumir muitas formas, mas a maioria assenta em alguns padrões comuns. Alguns exemplos do que as apps podem fazer:

• Apps de conhecimento leem e indexam conteúdo de um sistema externo para que o agente possa responder com base nele: apenas de leitura, com controlo de versões e com etiquetas por público-alvo.
• Apps de capacidade permitem que o agente faça efetivamente algo nesse sistema: uma verdadeira chamada à API, encadeada num fluxo de trabalho de vários passos (consultar a encomenda, verificar a política de devoluções, emitir o reembolso, confirmá-lo ao cliente), tudo numa única conversa. Enquanto um multibanco executa uma transação pré-definida a partir de um menu fixo, uma app de capacidade comporta-se mais como um gestor de conta: recebe um resultado pretendido, não uma opção de menu, e faz o que for preciso para lá chegar, incluindo tratar a exceção.
• Apps de canal colocam o agente onde os seus clientes ou a sua equipa de suporte já estão: um widget incorporado, uma chamada telefónica, uma caixa de entrada ou um painel de copiloto dentro da consola que os seus agentes usam todos os dias.

Uma app pré-construída do nosso diretório pode normalmente ser instalada em minutos. Quando o sistema de um cliente não está no catálogo, é a mesma framework — o mesmo SDK, os mesmos lifecycle hooks, o mesmo modelo de segurança — que um programador utiliza para construir uma app personalizada.

Não existe um nível «enterprise-grade» separado da framework, usado apenas pelos nossos engenheiros; o App Studio, a nossa plataforma de desenvolvimento de apps, assenta exatamente na mesma arquitetura. É TypeScript a sério, um SDK a sério (@mavenagi/mavenagi) e um pipeline de implementação a sério, não uma linguagem de scripting proprietária que tem de aprender só para nós.

Se já desenvolveu com MCP, uma Maven App oferece uma ideia semelhante, totalmente gerida. Um servidor MCP padrão continua a implicar que tem de o configurar, registar, manter em funcionamento e escalar por conta própria. Uma Maven App está mais próxima de um endpoint MCP que se regista e escala automaticamente, sem nenhuma dessa infraestrutura a seu cargo: escreve a lógica, e o endpoint, a autenticação e o alojamento ficam por nossa conta.

Como as Apps são concebidas para serem poderosas

Uma Maven App é uma aplicação serverless que é executada num ambiente seguro e isolado e comunica com a plataforma Maven através de um SDK definido. Em concreto:

É multi-tenant. Uma única app é construída uma vez e instalada muitas vezes, em diferentes organizações e agentes. Cada instalação tem o seu próprio contexto delimitado (o seu próprio ID de organização, ID de agente e configuração de runtime), mas partilha o mesmo código subjacente. Isto significa que, quando lançamos uma melhoria na app do Salesforce, todos os clientes que a utilizam beneficiam, e ninguém fica preso a uma versão desatualizada e feita à medida da «sua» integração.

É isolada, não um acrescento. Cada app é executada como uma função própria num ambiente seguro, separada do backend central da Maven e das apps de outros clientes. A sua lógica personalizada nunca corre dentro de um monólito partilhado ao lado da de outra pessoa. As ligações aos seus sistemas de registo podem ser feitas por VPN, VPC peering, OIDC ou HTTPS simples com lista de IPs permitidos — a escolha é sua, não nossa.

Reage a eventos reais, não a agendamentos de polling. Em vez de uma tarefa de sincronização noturna, uma app pode implementar event hooks chamados triggers: foi criada uma conversa, chegou feedback, uma base de conhecimento foi atualizada — e a plataforma notifica a app no momento em que o evento acontece. Este modelo é diferente das ferramentas de automação que talvez já conheça. Um trigger da Maven é passivo: é a própria plataforma que está à escuta de alterações de estado e as envia a qualquer app interessada, sem acoplamento entre a app que causou o evento e a app que reage a ele. Na prática, isto significa que uma app de resposta a emails e uma app de sincronização com o Salesforce totalmente separada podem reagir de forma independente ao mesmo evento «conversa atualizada», cada uma a fazer a sua parte, sem que nenhuma saiba que a outra existe.

É o mesmo mecanismo de coordenação que uma colónia de formigas utiliza. Nenhuma formiga planeia sozinha o comportamento da colónia, e nenhuma envia mensagens diretamente a outra; uma formiga altera algo no ambiente partilhado (um rasto de feromonas) e todas as outras reagem a essa alteração de forma independente, cada uma seguindo a sua própria regra simples. A inteligência ao nível da colónia (rotas de procura de alimento otimizadas, distribuição de carga, até decisões coletivas como mudar o ninho de sítio) emerge daí, sem coordenador central e sem que nenhuma formiga conheça o plano. As Maven Apps coordenam-se da mesma forma: um evento altera o estado partilhado e cada app interessada reage por si.

Tem um ciclo de vida real. Cada app implementa um pequeno conjunto de lifecycle hooks:

• preInstall: valida credenciais e configuração antes de qualquer coisa entrar em produção. Se a sua chave de API estiver errada, a instalação falha aqui de forma clara, em vez de falhar silenciosamente três semanas depois.
• postInstall: regista as ações da app e aprovisiona os recursos de que precisa assim que a instalação é concluída com êxito.
• executeAction: executa o trabalho que o agente pede, disponibilizado aos clientes como uma capacidade: consultar uma encomenda, criar um caso, emitir um reembolso, verificar o saldo de uma conta.

A maioria das integrações é um interruptor de luz: ligado ou desligado, sem nada pelo meio. As nossas cumprem um ciclo de vida completo de instalação, validação, execução e desmontagem, mais próximo de uma rotina que lê o contexto e se adapta (verificar o que está em aberto, confirmar o que é seguro e só depois agir) do que de um interruptor com dois estados. É exatamente a disciplina que se espera de um software de produção, porque é exatamente isso que é.

Apps vs. integrações

Uma integração típica responde a uma pergunta restrita — normalmente «os dados conseguem ir de A para B?» — e trata isso como a meta. Uma Maven App é construída para responder a uma pergunta mais difícil e mais útil: consegue um agente de IA saber, de forma fiável, o que é verdade nos seus sistemas neste momento, e pode confiar-se nele para agir em seu nome quando for necessário?

A maioria das plataformas empresariais oferece uma versão de «construa o seu, se não o tivermos de origem». O que normalmente não dizem é que construir o seu implica gerir o seu próprio servidor, a sua própria escalabilidade, a sua própria revisão de segurança, na sua própria infraestrutura. Isso transforma uma simples lacuna no catálogo de conectores numa decisão de recursos humanos: consegue orçamento para engenharia e infraestrutura, ou fica limitado ao que já existe pré-construído? Com as Maven Apps, os nossos clientes não são obrigados a escolher a opção menos má. Uma app personalizada criada por si ou pelo seu programador corre na nossa infraestrutura, com a mesma monitorização, escalabilidade e postura de segurança de todas as apps pré-construídas do nosso diretório. Escreve o código; nós executamo-lo.

É também por isso que a arquitetura exige aspetos com que um simples webhook nunca tem de se preocupar:

• Respostas estruturadas e de tamanho limitado. Cada ação executada por uma app devolve uma resposta clara e dados estruturados sobre os quais o agente pode raciocinar, e não um bloco bruto e ilimitado que tem de tentar adivinhar.
• Autenticação assinada e mútua. A plataforma assina cada chamada enviada a uma app para que esta possa verificar que é realmente a Maven a chamar, e a app autentica-se junto da plataforma com as suas próprias credenciais. Nenhum dos lados tem de confiar apenas na rede.
• Configuração validada antes de chegar à produção. Como o preInstall é executado antes de uma app entrar em produção, uma credencial inválida ou uma definição em falta é detetada no momento da instalação, e não na primeira vez que um cliente depende dela.
• Infraestrutura real por baixo, não apenas uma chamada de função. Como as apps são aplicações completas, podem manter estado real: uma cache, um contador de utilização, uma pequena base de dados, e não apenas um pedido e uma resposta sem estado. É isso que permite, por exemplo, acompanhar se a taxa de resolução de um domínio específico caiu mais de 10 % nas últimas 24 horas e alertar a sua equipa quando isso acontece. Uma simples chamada à API não consegue guardar esse tipo de memória. Uma aplicação real consegue, da mesma forma que uma colónia de formigas guarda a memória de onde está a comida, mesmo que nenhuma formiga individual o faça.
• Manter os dados sensíveis longe do modelo. Alguns passos nem sequer devem passar por uma IA. Quando um cliente está pronto para comprar o que tem no carrinho, o agente aciona o checkout da app, e a app recolhe os dados de pagamento e pessoais diretamente junto do cliente, através da sua própria interface segura. O agente orquestra o fluxo, mas os números de cartão e outras informações sensíveis nunca entram na conversa com a IA.
• Uma única base de código, todos os clientes, impacto isolado. O multi-tenancy significa que as correções e melhorias são lançadas uma vez e chegam a todos, enquanto o isolamento garante que a lógica personalizada de um cliente nunca pode afetar a de outro.

O que significa para si

Se está a avaliar a Maven, a conclusão prática é esta: quando dizemos que um agente consegue responder a uma pergunta e agir sobre ela, queremos dizer que existe uma aplicação real por trás dessa ação — com controlo de versões, autenticada, isolada e construída sobre a mesma framework, quer tenha sido lançada pela nossa equipa, quer pela sua. É essa a diferença entre um agente que consegue falar sobre os seus sistemas e um que está realmente ligado a eles.

Construímos as Maven Apps porque acreditamos que era isto que «integração» deveria ter significado desde o início.