A Zoho está a transformar o Catalyst 3.0 numa plataforma onde os agentes de programação podem atuar diretamente sobre a infraestrutura cloud, em vez de se limitarem a gerar código. A nova versão acrescenta um servidor MCP ativo, competências específicas para agentes, uma interface de linha de comandos não interativa e integrações com Claude, Cursor, Codex e Gemini. A mudança relevante está na passagem da assistência ao desenvolvimento para a execução efetiva dentro da plataforma.
Quando um agente pode criar tabelas, configurar autenticação ou fazer uma implementação, o problema deixa de ser apenas a correção do código. É necessário saber com que identidade atua, que permissões recebeu, que ferramentas chamou e se uma alteração problemática pode ser reconstituída ou revertida. O Catalyst 3.0 aproxima estes controlos do próprio percurso de execução do agente.
Os agentes passam a atuar sobre recursos cloud
Segundo a Zoho, o servidor MCP do Catalyst permite que agentes compatíveis comuniquem diretamente com a infraestrutura e executem operações de configuração e implementação. O repositório oficial do plugin para Cursor mostra a mesma abordagem: inclui competências para serviços específicos, contexto do projeto e acesso a operações sobre bases de dados, cache e armazenamento.
É um modelo diferente daquele em que o agente altera apenas o repositório e uma cadeia de CI/CD separada conserva o controlo da produção. Aqui, a interface do agente chega aos recursos da plataforma. Isso pode reduzir o trabalho intermédio entre a geração de código e as operações cloud, mas também aumenta o impacto potencial de uma decisão errada do agente.
Identidade e permissões tornam-se parte da arquitetura
A Zoho descreve um modelo em que o agente inicia sessão com o seu próprio conjunto configurável de permissões. Em modo não interativo, os comandos destrutivos ficam desativados. Esta separação é importante porque um agente que trabalha sem supervisão direta não deve herdar automaticamente todos os privilégios do programador que iniciou a tarefa.
Na prática, a identidade do agente deve ser tratada como uma conta de serviço. As equipas devem aplicar o princípio do menor privilégio, separar permissões de desenvolvimento e produção e manter alterações sensíveis sujeitas a aprovação humana ou a controlos adicionais da cadeia de entrega. MCP deixa assim de ser apenas uma camada de interoperabilidade e passa também a fazer parte da fronteira de autorização.
A rastreabilidade passa a ser requisito operacional
O Catalyst 3.0 reúne registos da aplicação, da plataforma e das chamadas de ferramentas MCP. A Zoho afirma ainda que as alterações posteriores ao lançamento ficam versionadas, podem ser atribuídas e podem ser revertidas. Em caso de incidente, estas informações permitem tentar reconstruir que agente chamou determinada ferramenta e que mudança resultou dessa ação.
Isto não prova que todas as ações de um agente sejam seguras. Porém, torna o percurso de execução auditável, uma condição necessária para diagnóstico, governação e resposta a incidentes. Para responsáveis de engenharia, a comparação entre plataformas preparadas para agentes deve incluir a qualidade dos controlos de identidade, permissões, registo e reversão, e não apenas a lista de modelos suportados.
Os números de desempenho continuam a ser dados do fornecedor
A Zoho apresenta testes próprios nos quais a utilização das competências de agente e do contexto MCP leva os modelos avaliados a taxas de conclusão de tarefas entre 90 e 95%. Estes resultados não foram validados por uma avaliação independente e devem ser tratados como afirmações do fornecedor.
As funcionalidades entregues são mais fáceis de confirmar. A página do produto documenta o servidor MCP, as permissões configuráveis, os registos de chamadas de ferramentas e o versionamento das alterações, enquanto o repositório oficial expõe a integração com Cursor e as competências próprias dos serviços Catalyst. Uma equipa pode, por isso, avaliar a arquitetura de execução sem aceitar automaticamente os números apresentados.
A decisão maior é onde fica a autoridade do agente
O Catalyst 3.0 mostra uma mudança mais ampla na engenharia de software com agentes: os fornecedores de infraestrutura começam a abrir operações reais aos agentes de programação e, ao mesmo tempo, precisam de incorporar mecanismos que limitem esse poder.
As equipas podem manter a autoridade do agente num ambiente de orquestração externo, que acede ao cloud através de mecanismos tradicionais de automatização, ou adotar uma interface nativa da plataforma, na qual permissões e registos de execução estão integrados com a própria infraestrutura. A segunda opção pode simplificar a execução, mas também aumenta a dependência do modelo de controlo do fornecedor. A portabilidade do processo do agente deve, por isso, ser avaliada separadamente da portabilidade da aplicação.