Craig McLuckie, da Stacklok, considera que os agentes de programação não devem continuar vinculados ao dispositivo e ao processo interativo do desenvolvedor, e apresenta o projeto de código aberto Mecatl como um modelo de arquitetura distribuída que separa o loop do agente dos clientes, ambientes de execução, ferramentas e serviços de suporte.
O valor dos agentes de programação já não está limitado a uma interface de conversa que responde a perguntas. Sua adoção prática passou a depender de ferramentas capazes, de um repositório e de um sistema de arquivos compartilhados, de subagentes e de habilidades que preservam o que o sistema aprende com trabalhos anteriores. Segundo Craig McLuckie, da Stacklok, o próximo passo é transferir esses recursos do computador do desenvolvedor para serviços de longa execução e interfaces usadas por pessoas que talvez nem sequer abram um terminal.
O problema é que a maioria das estruturas atuais para operar agentes foi projetada em torno de um modelo de desktop: um único usuário, um único dispositivo, um sistema de arquivos local e um processo interativo que reúne simultaneamente a interface de usuário, o loop do agente, o isolamento, o armazenamento de credenciais, a hospedagem das ferramentas e o banco de dados da sessão. Esse modelo é adequado para o desenvolvedor individual, mas se torna menos apropriado quando a organização precisa executar centenas de sessões, impor políticas precisas às ferramentas, retomar uma sessão após a falha de um nó ou alternar entre dispositivos diferentes.
Separar o loop do agente do restante do sistema
McLuckie propõe construir o que chama de «cinto operacional nativo da nuvem» como uma aplicação distribuída desde o início, em vez de simplesmente colocar uma estrutura de desktop dentro de um contêiner. O contêiner pode mudar o local de execução do processo, mas não desfaz a dependência mútua entre seus componentes. Na Stacklok, a estrutura de código aberto Mecatl foi disponibilizada para esse fim.
No Mecatl, o núcleo assume o loop do agente, incluindo inferência, distribuição das chamadas de ferramentas, permissões, hooks e emissão de eventos. Os demais elementos se conectam a ele por meio de interfaces claras:
- Clientes finais e APIs, entre eles uma TUI chamada mecatui, interfaces gRPC e HTTP/SSE e um SDK em TypeScript.
- Ambientes de execução, espaços de trabalho e executores de comandos nos quais o agente realiza suas tarefas.
- Um ecossistema de ferramentas que inclui ferramentas integradas, serviços MCP por HTTP com streaming, habilidades e integrações específicas de aplicações.
- Serviços de suporte para gerenciar provedores de modelos, estado das sessões, registro de eventos, identidade e coordenação.
O que muda na prática?
Essa separação torna o loop do agente um componente que pode ser versionado, implantado e monitorado como qualquer outro serviço. Ele pode ser executado em um terminal, como um serviço ou no Kubernetes sem substituir o próprio loop. No guia mecak8s, os workers podem ser substituídos durante a execução, enquanto as sessões persistentes permanecem disponíveis durante a implantação de uma nova versão.
O estado da sessão e o registro de eventos são armazenados em armazenamento persistente dentro de um modelo de coordenação que utiliza um único gravador. Se o worker falhar, um worker substituto poderá continuar a partir do último limite de turno salvo. Isso, porém, não equivale a uma transação distribuída: o processo em andamento no momento da falha não é retomado, e o trabalho realizado depois do último salvamento bem-sucedido pode ser perdido. Por isso, o projeto descreve essa capacidade como continuidade em nível de turnos, e não como uma garantia de uma transação distribuída completa.
O catálogo explícito também permite restringir as ferramentas, habilidades e integrações autorizadas, com limites de permissões, auditoria e ambiente de execução. Como o cliente não possui o sistema de arquivos, as credenciais nem o estado da sessão, o próprio loop pode atender a um terminal, um serviço remoto, uma aplicação incorporada ou uma implantação no Kubernetes, além de conectar uma interface web, uma integração com o Slack e um editor colaborativo à mesma sessão.
Questões ainda não resolvidas
A fonte enfatiza que o Mecatl ainda está em uma fase inicial e que o «cinto nativo da nuvem» é mais uma direção arquitetural do que uma especificação completa. Uma das principais questões é determinar a identidade da entidade que chama um sistema externo: o usuário, o agente, a sessão ou um subagente multinível? O projeto propõe um domínio de confiança SPIFFE próprio, com a codificação de toda a cadeia de delegação em um JWT para que os sistemas receptores possam tomar decisões com base na cadeia de identidades.
O projeto também estuda caminhos para ferramentas que vão além do MCP, permitindo que uma ferramenta como um analisador de PDF trabalhe diretamente no sistema de arquivos, em vez de passar todas as suas entradas e saídas por uma janela de contexto do modelo. Surge também a ideia de «prova de contexto», isto é, emitir, assinar, atribuir, distribuir e submeter a políticas o contexto empacotado, como qualquer artefato em uma cadeia de fornecimento de software.
Leitura editorial: a importância da proposta não está no lançamento de uma nova interface, mas na redefinição do agente como um serviço gerenciável, em vez de um processo pessoal de longa duração. No entanto, a fonte distingue claramente o que funciona atualmente no Mecatl do que ainda está em fase de projeto, e a continuidade atual não impede a perda do trabalho em andamento nem resolve ainda o modelo de identidade ou a transferência direta de dados entre ferramentas. Por isso, a adoção desse modelo exige uma avaliação prática do ambiente de implantação, dos limites de permissões e das garantias de dados antes que ele seja considerado um substituto pronto para todas as estruturas locais de agentes.