Agent Relay mantém o código local — o raciocínio ainda roda na nuvem

No anúncio oficial de 4 de setembro de 2026, a Coder apresentou o Agent Relay, com a SpaceXAI como parceira de lançamento e o Cursor Cloud Agents como primeira integração. O comunicado da Coder delimita a arquitetura: as ferramentas executam em workspaces controlados pelo cliente, enquanto o Cursor mantém o loop do agente, a inferência e o planejamento; a oferta está em prévia privada.
A data exige uma ressalva: uma cobertura independente da TNW foi publicada em 2 de setembro, dois dias antes da data exibida no anúncio oficial, mas confirma o mesmo produto, a mesma divisão arquitetural e o status de prévia privada. Portanto, 4 de setembro é a data do anúncio oficial usada nesta matéria, não necessariamente o primeiro dia em que a informação circulou.
A execução muda para o ambiente do cliente

O Agent Relay desloca a execução das ferramentas, não o agente inteiro. Cada sessão recebe um workspace Coder autogerenciado, que pode operar na nuvem da organização, em uma VPC ou em infraestrutura local. Nesse ambiente, um worker do Cursor acessa o checkout do repositório, edita arquivos, executa comandos, compila o projeto, roda testes e alcança serviços internos permitidos.
O fluxo começa com uma solicitação encaminhada a um pool de workers associado à organização. O Relay provisiona um workspace a partir do modelo definido pela equipe de plataforma, inicia nele o worker e o conecta à sessão externa do Cursor. Encerrada a tarefa, o ambiente efêmero pode ser desfeito.
Esse desenho mantém sob administração da empresa a imagem do workspace, as dependências, a capacidade computacional, as credenciais locais e os recursos de rede disponíveis. Também aproxima a execução de repositórios privados, registries internos ou hardware especializado. É uma aplicação específica da execução em infraestrutura própria, acrescida do provisionamento e dos controles da Coder.
O raciocínio permanece no Cursor
A fronteira termina antes da camada que decide o que fazer. O Cursor continua responsável por orquestrar a sessão, manter o ciclo do agente, realizar a inferência do modelo e planejar os próximos passos. O worker recebe chamadas de ferramentas pela conexão externa, executa as ações no workspace e devolve os resultados necessários para que o agente prossiga.
Por isso, “manter o código local” descreve a localização do checkout e da execução, mas não significa isolamento total de dados. O repositório completo, o cache de compilação e as credenciais restritas à máquina permanecem no ambiente do cliente; trechos de arquivos e resultados das ferramentas podem ser enviados ao serviço externo como contexto. A solução é híbrida, não uma instalação integral do Cursor ou do modelo dentro da empresa.
Quais dados ainda podem deixar a rede

A documentação de máquinas autogerenciadas do Cursor lista o conteúdo que o worker pode transmitir durante uma execução: trechos de arquivos necessários ao agente, saída do terminal, diffs, capturas de tela, resultados de servidores MCP locais e metadados de roteamento. Se o compartilhamento da área de trabalho estiver habilitado, essa transmissão também pode incluir a sessão visual do agente.
Capturas, vídeos e referências de logs podem ser enviados ao armazenamento administrado pelo Cursor para aparecer em pull requests e no painel. O upload desses artefatos pode ser bloqueado por uma regra de saída específica, mas isso não interrompe o tráfego da sessão: chamadas de ferramentas e seus resultados continuam circulando para sustentar o loop do agente.
Essa separação importa para organizações sujeitas a regras de residência, sigilo ou rastreabilidade. Hospedar o workspace responde onde ficam o checkout, as credenciais locais e os processos executados, mas a análise de conformidade ainda precisa abranger prompts, contexto selecionado, respostas do modelo, saídas de ferramentas e artefatos. A relação com o provedor externo não desaparece porque a computação das ferramentas mudou de lugar.
Políticas e auditoria acompanham cada sessão

Os workspaces do Agent Relay são isolados, efêmeros e associados a uma tarefa. A equipe de plataforma define no modelo do ambiente quais recursos, fontes de dados e destinos de rede ficam disponíveis. Uma tentativa de alcançar um recurso não autorizado pode, assim, ser bloqueada pela infraestrutura, sem depender apenas de o modelo recusar a ação.
Cada execução também pode gerar um registro que correlaciona o usuário e a sessão do Cursor ao workspace da Coder. O histórico inclui o que o agente acessou, executou, alterou e foi impedido de fazer. Isso cria uma trilha operacional para investigações e relatórios, embora não coloque a conversa com o modelo sob o mesmo perímetro.
- No ambiente do cliente: checkout completo, arquivos de trabalho, comandos, testes, serviços internos autorizados e credenciais mantidas na máquina.
- No serviço externo: orquestração, inferência, planejamento e o contexto ou resultado transmitido pelo worker.
- Sob política da empresa: imagem do workspace, permissões, recursos, destinos de rede e ciclo de vida do ambiente.
- Na trilha de auditoria: associação entre usuário, sessão e workspace, além das ações realizadas ou bloqueadas.
A disponibilidade continua restrita
O Agent Relay para Cursor ainda não está em disponibilidade geral. A oferta permanece em acesso antecipado e prévia fechada com clientes selecionados e parceiros de desenvolvimento. Não há cronograma público de abertura nem preço específico divulgado.
O que está confirmado é a separação entre o local da execução e o local do raciocínio: a empresa administra o workspace, os acessos e as regras de saída, enquanto o Cursor continua processando o agente na nuvem. Os pontos ainda em aberto são a ampliação da prévia, as condições comerciais definitivas e a extensão do Relay a outras integrações.
Leia também:
Assine nossa newsletter
Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.