O agente saiu do chat
e entrou no
caminho crítico

A interface que mudou

Até agora, a imagem mais comum de um agente começava com uma pessoa abrindo uma conversa. O usuário escolhia o momento, escrevia a instrução, via a resposta e decidia o próximo passo. Mesmo quando o agente usava ferramentas, o início permanecia visível e humano.

A documentação da Workspace Agents API muda essa sequência. Um sistema externo pode enviar um evento para um agente publicado por meio de uma chamada HTTP. Um e-mail recebido, um ticket criado, uma alteração de banco, um alerta de monitoramento ou uma etapa de workflow pode iniciar o trabalho sem que alguém abra a interface.

O endpoint é direto: POST https://api.chatgpt.com/v1/workspace_agents/{id}/trigger. O corpo exige uma entrada textual e pode incluir uma conversation_key, identificador definido pelo chamador para continuar a mesma conversa em eventos relacionados. A API coloca o evento em uma fila durável e responde com 202 Accepted e um link para a conversa.

Tecnicamente, isso é uma API de gatilho, não um webhook de saída. Um webhook de outro sistema pode chamá-la, mas o ChatGPT não está enviando o resultado de volta para aquele webhook. A diferença importa porque evita prometer uma integração que a interface ainda não oferece.

O agente deixou de esperar na tela. Ele agora pode ocupar o caminho crítico entre um evento e uma decisão operacional.

API de gatilho não é resultado assíncrono

O código 202 Accepted significa que o servidor aceitou a solicitação para processamento. Não significa que o agente concluiu a tarefa, que uma ferramenta foi executada ou que o resultado está correto. A própria documentação informa que a resposta do agente ainda não pode ser recuperada pela API.

Existe um modo beta de acompanhar o estado da execução. Com o cabeçalho OpenAI-Beta: workspace_agent_runs=v1, a resposta inclui um identificador de run. O chamador pode consultar estados como queued, in_progress, suspended, completed e failed.

Mesmo completed precisa ser lido com cuidado. Ele confirma que a execução do agente terminou. Não confirma que a consequência desejada aconteceu em outro sistema, que os dados de entrada eram confiáveis ou que uma decisão humana necessária foi aprovada.

Uma arquitetura que recebe 202 e atualiza um ticket como resolvido está confundindo aceitação com conclusão. Uma arquitetura que recebe completed e presume que a recomendação é verdadeira está confundindo execução com validação.

O chamador pode ser válido e o conteúdo hostil

A autenticação usa um Workspace Agent access token. Administradores precisam habilitar os agentes e permitir tokens pessoais. A credencial é limitada às operações da Workspace Agents API, o que reduz o escopo em relação a reutilizar uma chave mais ampla.

Esse token responde a uma pergunta: qual sistema está autorizado a iniciar este agente? Ele não responde se o conteúdo enviado merece confiança.

Um serviço de e-mail pode estar corretamente autenticado e encaminhar uma mensagem maliciosa. Um sistema de tickets pode ser legítimo e conter texto produzido por um cliente tentando manipular instruções. Um evento de CRM pode carregar uma observação copiada de uma página externa. A origem técnica do payload e a confiabilidade semântica do conteúdo são propriedades diferentes.

Esse é o ponto em que prompt injection deixa de ser apenas um problema de chatbot. Quando um evento inicia um agente, texto não confiável pode tentar alterar objetivo, ferramentas, destino ou critérios de aprovação antes que uma pessoa veja o caso.

O gatilho precisa ser tratado como uma fronteira. Antes de chamar o agente, uma camada determinística deveria validar esquema, tamanho, origem, tipo de evento, classificação de dados e escopo permitido. Dentro do agente, o payload precisa aparecer como evidência não confiável, nunca como política do sistema.

A conversa também é uma fronteira

A conversation_key permite manter continuidade. Isso é útil quando vários eventos pertencem ao mesmo caso, cliente ou processo. O sistema pode acrescentar um novo ticket à conversa anterior em vez de reiniciar o contexto.

O mesmo recurso pode misturar casos que deveriam permanecer separados. Se a chave for ampla demais, eventos de clientes diferentes podem compartilhar histórico. Se for reutilizada depois que um caso terminou, uma decisão antiga pode reaparecer como contexto de um novo problema. Se o valor for controlado por entrada externa, alguém pode tentar escolher a conversa à qual será conectado.

A chave não deveria ser um endereço de e-mail bruto, título de ticket ou identificador fornecido pelo usuário. Ela precisa ser derivada por uma camada confiável, ter escopo explícito, política de expiração e correspondência com as permissões do caso.

Também é necessário decidir quando continuar e quando começar de novo. Persistência ajuda a reduzir repetição, mas amplia a superfície de contaminação. Um incidente, uma investigação jurídica e uma tarefa financeira podem exigir contextos isolados mesmo quando pertencem à mesma organização.

Repetição segura não é repetição invisível

Sistemas assíncronos falham. A conexão pode cair depois que o servidor aceitou o evento e antes que o cliente receba a resposta. Sem proteção, o cliente tenta novamente e cria duas execuções.

A API aceita o cabeçalho Idempotency-Key. Ao repetir o mesmo evento com a mesma chave, o chamador recebe o resultado de aceitação original em vez de inserir outro trabalho na fila. Isso evita duplicação no ponto de entrada.

Ainda assim, idempotência precisa continuar depois do gatilho. Se o agente chama uma ferramenta que cria um pedido, envia uma mensagem ou altera um registro, essa ferramenta também precisa reconhecer a identidade do evento. Caso contrário, uma única execução retomada após suspensão pode repetir a consequência.

Uma chave de idempotência não deveria ser aleatória a cada tentativa. Ela deve ser derivada da identidade estável do evento e reutilizada apenas para aquele evento. Reutilizar a mesma chave para eventos diferentes pode suprimir trabalho legítimo. Trocar a chave numa simples retentativa pode duplicar trabalho.

A autoridade precisa existir fora do prompt

É comum definir limites com frases como “não envie nada sem confirmação” ou “peça aprovação antes de alterar dados”. Essas instruções são úteis, mas não deveriam ser a única barreira entre o agente e uma ação material.

Se uma ferramenta aceita exclusão, pagamento, alteração de acesso ou comunicação externa, o controle precisa existir na própria ferramenta ou numa camada de política. Escopo de token, permissões mínimas, allowlists, limites de valor, aprovação humana e logs precisam ser aplicados fora da geração linguística.

O agente pode recomendar. A infraestrutura decide o que ele está autorizado a executar. Em tarefas de alto impacto, a saída deveria ser um plano ou artefato pendente, não a ação final.

Isso também melhora a operação. Uma aprovação registrada pode mostrar quem autorizou, qual versão do conteúdo foi vista, quais ferramentas seriam usadas e qual evento iniciou o fluxo. Sem esse registro, “o prompt dizia para pedir permissão” não é uma trilha de auditoria.

Como adotar sem começar pelo poder de execução

O caminho mais seguro é aumentar autoridade em etapas. Primeiro, o agente classifica eventos. Depois resume. Em seguida recomenda. Então prepara um rascunho ou uma mudança reversível. Só depois de medir erros e construir controles passa a executar ações delimitadas.

A progressão pode ser descrita assim: classificar, resumir, recomendar, preparar, aprovar, executar. Cada verbo adiciona uma consequência e exige uma evidência diferente.

Classificação precisa de métricas de erro. Resumo precisa de atribuição a fontes. Recomendação precisa de contraponto e limite. Preparação precisa de diff. Aprovação precisa de identidade humana. Execução precisa de idempotência, autorização e reversão.

O contrato operacional de um agente publicado

Publicar um agente que pode ser acordado por eventos exige um contrato mais concreto do que uma descrição de comportamento. É preciso definir quais eventos são aceitos, quais campos entram, quais fontes são confiáveis, quais ferramentas existem e quais dados podem sair.

O contrato também deve registrar como a conversation_key é construída, qual chave de idempotência representa o evento, quanto tempo uma execução pode durar, o que significa suspended, quando uma pessoa precisa assumir e como um token é revogado.

Depois vêm as consequências: que saídas permanecem como rascunho, quais ações são reversíveis, quais exigem dupla aprovação e onde os logs ficam. Um agente sem esse contrato não é autônomo. É apenas difícil de auditar.

O caminho crítico começa na entrada

O lançamento não transforma todo agente em sistema de produção. A API ainda tem limites importantes, incluindo a impossibilidade atual de recuperar a resposta do agente diretamente. Ela também depende de um agente publicado, de configuração administrativa e de tokens que precisam ser protegidos e revogados quando necessário.

Mas a mudança de arquitetura já aconteceu. O evento pode iniciar trabalho. Isso desloca o momento mais importante da governança.

Antes, a pergunta era o que o agente faria depois que alguém abriu o chat. Agora, a pergunta começa antes: qual evento tem permissão para iniciar qual agente, com quais dados, ferramentas e consequências?

Quando essa resposta fica apenas dentro do prompt, o agente entrou no caminho crítico sem que a autoridade estivesse pronta.