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

Um painel de comutação faz exatamente aquilo para o qual foi cabeado: você aciona o interruptor e recebe a mesma resposta fixa, sempre. Peça para ele lidar com qualquer coisa fora daquele circuito e ele não consegue, porque não lida com variações, apenas com fiação.

Um operador é diferente. Dê a ele um pedido, como "me conecte com a recepção", e ele descobre como fazer: qual linha usar, o que fazer se estiver ocupada, o que fazer se o próprio pedido for ambíguo. Ele não apenas transmite o sinal; ele o interpreta e age a partir dele.

Os Maven Apps são operadores, não painéis de comutação. Quando começamos a construir o framework que sustenta nossa infraestrutura de Apps, fizemos uma aposta deliberada: não construir mais uma camada de integração. Construir uma plataforma de aplicações de verdade, em que os agentes de IA sejam cidadãos de primeira classe.

Hoje, temos milhares de apps no nosso framework. Sim, isso inclui apps para grandes sistemas de terceiros como Salesforce, Zendesk e Notion. Mas também inclui centenas de apps personalizados rodando em produção, em agentes ativos.

Por que integrações básicas não bastam

Pergunte a 10 fornecedores o que "integra com Salesforce" significa no produto deles e você vai ouvir 10 respostas diferentes, porque um sistema como Salesforce, Zendesk ou Front nunca é uma coisa só. Ele pode ser:

• Um lugar aonde seu agente precisa ir para encontrar informações (uma base de conhecimento, um histórico de casos)
• Um lugar aonde seu agente precisa ir para executar ações (criar um ticket, atualizar um registro, emitir um reembolso)
• Uma superfície em que seu agente precisa aparecer (um copiloto de assistência dentro do console em que sua equipe de suporte já trabalha)

Uma "integração com Salesforce" que só conhece artigos não é o mesmo produto que uma que também consegue abrir um caso, e também não é o mesmo produto que uma que pode ficar dentro do console do agente como copiloto. Muitas vezes, tudo isso é agrupado sob uma única palavra de marketing, e você só descobre 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 você precisa não esteja na lista e, a essa altura, você já se comprometeu. Não queríamos que os Maven Apps funcionassem assim, então construímos o framework em torno da pergunta real que está sendo feita (conhecimento, capacidade ou canal), e não em torno de um "conector" genérico.

Maven Apps: mais do que integrações

Os Maven Apps podem assumir muitas formas, mas a maioria se baseia em alguns padrões comuns. Alguns exemplos do que os apps podem fazer:

• Apps de conhecimento leem e indexam conteúdo de um sistema externo para que o agente possa responder com base nele: somente leitura, com versionamento e tags por público.
• Apps de capacidade permitem que o agente realmente faça algo nesse sistema: uma chamada de API real, encadeada em um fluxo de várias etapas (consultar o pedido, verificar a política de devolução, emitir o reembolso, confirmar com o cliente), tudo dentro de uma única conversa. Enquanto um caixa eletrônico executa uma transação roteirizada a partir de um menu fixo, um app de capacidade se comporta mais como um gerente de banco pessoal: recebe um resultado desejado, não um item de menu, e faz o que for preciso para chegar lá, inclusive lidar com exceções.
• Apps de canal colocam o agente onde seus clientes ou sua equipe de suporte já estão: um widget incorporado, uma ligação telefônica, uma caixa de entrada ou um painel de copiloto dentro do console que seus agentes usam todos os dias.

Um app pronto do nosso diretório geralmente pode ser instalado em minutos. Quando o sistema de um cliente não está no catálogo, é o mesmo framework, com o mesmo SDK, os mesmos lifecycle hooks e o mesmo modelo de segurança, que um desenvolvedor usa para criar um app personalizado.

Não existe uma versão "enterprise" separada do framework que só nossos engenheiros usam; o App Studio, nossa plataforma de desenvolvimento de apps, roda exatamente na mesma arquitetura. É TypeScript de verdade, um SDK de verdade (@mavenagi/mavenagi) e um pipeline de deploy de verdade, não uma linguagem de script proprietária que você precisa aprender só por nossa causa.

Se você já trabalhou com MCP, um Maven App oferece uma ideia parecida, totalmente gerenciada. Um servidor MCP padrão ainda exige que você o suba, registre, mantenha funcionando e escale por conta própria. Um Maven App está mais próximo de um endpoint MCP com registro e escalonamento automáticos, sem nada dessa infraestrutura sob sua responsabilidade: você escreve a lógica, e o endpoint, a autenticação e a hospedagem ficam por nossa conta.

Como os Apps são projetados para ser poderosos

Um Maven App é uma aplicação serverless que roda dentro de um ambiente seguro e isolado e se comunica com a plataforma Maven por meio de um SDK definido. Na prática:

É multi-tenant. Um único app é construído uma vez e instalado muitas vezes, em diferentes organizações e agentes. Cada instalação recebe seu próprio contexto delimitado (seu próprio ID de organização, ID de agente e configuração de runtime), mas compartilha o mesmo código subjacente. Isso significa que, quando lançamos uma melhoria no app do Salesforce, todos os clientes que o usam se beneficiam, e ninguém fica preso a uma versão desatualizada e feita à mão da "sua" integração.

É isolado, não um remendo. Cada app roda como uma função própria em um ambiente seguro, separado do backend principal da Maven e dos apps de outros clientes. Sua lógica personalizada nunca roda dentro de um monólito compartilhado ao lado da lógica de outra empresa. As conexões com seus sistemas de registro podem usar VPN, VPC peering, OIDC ou HTTPS simples com allowlist de IPs: a escolha é sua, não nossa.

Reage a eventos reais, não a agendamentos de polling. Em vez de um job de sincronização noturno, um app pode implementar hooks de eventos chamados triggers: uma conversa foi criada, chegou um feedback, uma base de conhecimento foi atualizada, e a plataforma notifica o app no momento em que o evento acontece. Esse modelo é diferente das ferramentas de automação que você talvez já conheça. Um trigger da Maven é passivo: a própria plataforma fica atenta às mudanças de estado e as envia a qualquer app interessado, sem acoplamento entre o app que causou o evento e o app que reage a ele. Na prática, isso significa que um app de resposta por e-mail e um app de sincronização com Salesforce completamente separado podem reagir de forma independente ao mesmo evento de "conversa atualizada", cada um fazendo sua parte, sem que um saiba da existência do outro.

É o mesmo mecanismo de coordenação usado por uma colônia de formigas. Nenhuma formiga planeja o comportamento da colônia, e nenhuma envia mensagens diretamente a outra; uma formiga altera algo no ambiente compartilhado (uma trilha de feromônio) e todas as outras reagem a essa mudança de forma independente, cada uma seguindo sua própria regra simples. A inteligência da colônia (rotas de coleta otimizadas, distribuição de carga e até decisões coletivas, como mudar o ninho de lugar) surge daí, sem coordenador central e sem que nenhuma formiga conheça o plano. Os Maven Apps se coordenam da mesma forma: um evento muda o estado compartilhado, e cada app interessado reage por conta própria.

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

• preInstall: valida credenciais e configurações antes que qualquer coisa entre no ar. Se sua chave de API estiver errada, a instalação falha de forma clara aqui, em vez de falhar silenciosamente 3 semanas depois.
• postInstall: registra as ações do app e provisiona os recursos necessários assim que a instalação é concluída.
• executeAction: executa o trabalho que o agente solicita, disponibilizado aos clientes como uma capacidade: consultar um pedido, criar um caso, emitir um reembolso, verificar o saldo de uma conta.

A maioria das integrações é um interruptor de luz: ligado ou desligado, nada no meio. As nossas seguem um ciclo de vida completo de instalação, validação, execução e desativação, mais parecido com uma rotina que lê o contexto e se adapta (verifica o que está aberto, confirma o que é seguro e então age) do que com um interruptor de 2 estados. É exatamente a disciplina que se espera de um software de produção, porque é exatamente isso que ele é.

Apps vs. integrações

Uma integração típica responde a uma pergunta restrita, geralmente "os dados conseguem ir de A para B?", e trata isso como a linha de chegada. Um Maven App foi feito para responder a uma pergunta mais difícil e mais útil: um agente de IA consegue saber com confiabilidade o que é verdade nos seus sistemas neste momento, e é possível confiar nele para agir em seu nome quando necessário?

A maioria das plataformas corporativas oferece alguma versão de "crie o seu se não tivermos pronto". O que elas geralmente não contam é que criar o seu significa operar seu próprio servidor, cuidar do seu próprio escalonamento e da sua própria revisão de segurança, na sua própria infraestrutura. Isso transforma uma simples lacuna no catálogo de conectores em uma decisão de contratação: você consegue orçamento para engenharia e infraestrutura ou fica limitado ao que já vem pronto? Com os Maven Apps, nossos clientes não são obrigados a escolher a opção menos ruim. Um app personalizado criado por você ou pelo seu desenvolvedor roda na nossa infraestrutura, com o mesmo monitoramento, escalonamento e postura de segurança de todos os apps prontos do nosso diretório. Você escreve o código; nós o executamos.

É também por isso que a arquitetura insiste em coisas com as quais um simples webhook nunca precisa se preocupar:

• Respostas estruturadas e com tamanho limitado. Cada ação executada por um app retorna uma resposta clara e dados estruturados sobre os quais o agente pode raciocinar, e não um bloco bruto e ilimitado que ele precisa decifrar.
• Autenticação mútua e assinada. A plataforma assina cada requisição enviada a um app para que ele possa verificar que é mesmo a Maven chamando, e o app se autentica de volta na plataforma com suas próprias credenciais. Nenhum dos lados precisa confiar apenas na rede.
• Configuração validada antes de chegar à produção. Como o preInstall é executado antes de o app entrar no ar, uma credencial inválida ou uma configuração ausente é detectada na 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 os apps são aplicações completas, eles podem manter estado real: um cache, uma contagem de requisições, um pequeno banco de dados, e não apenas uma requisição e uma resposta sem estado. É isso que permite, por exemplo, monitorar se a taxa de resolução de um domínio específico caiu mais de 10% nas últimas 24 horas e acionar sua equipe quando isso acontecer. Uma simples chamada de API não guarda esse tipo de memória. Uma aplicação real guarda, assim como uma colônia de formigas guarda a memória de onde está a comida, mesmo que nenhuma formiga sozinha saiba.
• Dados sensíveis longe do modelo. Algumas etapas não deveriam passar por uma IA. Quando um cliente está pronto para comprar o que está no carrinho, o agente aciona o checkout do app, e o app coleta os dados de pagamento e pessoais diretamente do cliente por meio de sua própria interface segura. O agente orquestra o fluxo, mas números de cartão e outras informações sensíveis nunca entram na conversa com a IA.
• Uma base de código, todos os clientes, raio de impacto isolado. Com o multi-tenancy, 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 afete a de outro.

O que isso significa para você

Se você está avaliando a Maven, a conclusão prática é esta: quando dizemos que um agente pode responder a uma pergunta e agir a partir dela, queremos dizer que há uma aplicação real por trás dessa ação, versionada, autenticada, isolada e construída no mesmo framework, tenha ela saído da nossa equipe ou da sua. Essa é a diferença entre um agente que sabe falar sobre seus sistemas e um que está de fato conectado a eles.

Criamos os Maven Apps porque acreditamos que é isso que "integração" deveria ter significado desde o início.