Jota Oliveira
Voltar ao blog

Automação

Em automação, concluir uma etapa não é confirmar a entrega

Ilustração tátil em papel de uma balança comparando um mecanismo que concluiu uma etapa com uma pessoa recebendo um envelope e uma marca física de confirmação, distinguindo execução de entrega verificada.

O que a automação fez e o que alguém recebeu

Uma automação pode informar que concluiu uma etapa e, ainda assim, não ter entregue o que uma pessoa precisava no destino. Um arquivo pode ter sido enviado sem aparecer para quem deveria acessá-lo. Uma solicitação pode ter sido aceita sem produzir o registro esperado. Uma página pode ter sido criada sem estar disponível publicamente.

Essa diferença fica mais importante à medida que agentes passam a trabalhar por mais tempo, com arquivos, ferramentas e resultados intermediários. Ao apresentar a Agents API, a OpenAI descreve uma infraestrutura para agentes que gerenciam contexto, usam ferramentas e produzem artefatos ao longo do trabalho. Isso ajuda a executar atividades persistentes, mas não transforma automaticamente a resposta de uma ferramenta em prova de que o efeito externo aconteceu.

Para quem desenha um fluxo, a pergunta útil não é apenas “a ação retornou sucesso?”. É “qual estado, fora da automação, precisa existir para que a entrega seja considerada real?”. A resposta deve ser observável: a pessoa consegue abrir o arquivo, a mensagem aparece no canal correto, o registro foi gravado ou a página responde publicamente.

Quatro estados que evitam falsas confirmações

  1. Executado: a automação enviou o comando ou terminou sua parte da tarefa.
  2. Aguardando confirmação: ainda é necessário observar o destino ou receber uma resposta independente.
  3. Confirmado: a evidência esperada foi encontrada e registrada.
  4. Desconhecido ou com falha: a resposta não prova o resultado, ou a verificação mostrou que ele não existe.

Essa separação evita dois problemas comuns. O primeiro é celebrar uma entrega cedo demais. O segundo é repetir automaticamente uma ação que talvez tenha funcionado parcialmente, criando duplicidade ou escondendo a causa do erro.

Na prática, vale definir a evidência de confirmação antes de ligar o fluxo. Quando for possível, use uma leitura independente do destino. Quando não for, registre a limitação, preserve o identificador da tentativa e encaminhe uma revisão humana com uma pergunta concreta. Em vez de “deu errado”, a pessoa recebe algo que pode investigar: “a ação foi aceita, mas o arquivo ainda não está disponível no local combinado”.

Para equipes que começam a usar agentes, essa é uma mudança de critério importante. A infraestrutura pode manter contexto, executar código e organizar artefatos. A responsabilidade pelo resultado, porém, continua pedindo um desenho claro de estados, evidências e exceções. É assim que uma automação deixa de apenas rodar e passa a ser confiável para quem depende dela.

Essa ideia complementa um agente de dados que carrega permissão e evidência junto da tarefa e a necessidade de contexto que permanece em agentes de longa duração.

Próximo passo

Use esta distinção na próxima revisão de um fluxo automatizado.

Ler a fonte

Continue a leitura

Duas mãos de papel passam uma pequena montagem modular teal sobre uma base amarela de inspeção, com uma peça coral separada ao lado.

Agentes de código: defina o que precisa ser revisado

Antes de delegar código a um agente, combine o comportamento esperado, os limites da mudança e a evidência que permitirá revisar a entrega.

Ler artigo
Documento de papel com um espaço quadrado vazio repousa em um suporte de teste amarelo, ao lado da peça teal que falta e de documentos completos.

Agentes de IA: teste dados incompletos antes de automatizar

Ao testar agentes de IA, inclua pedidos com dados incompletos e confira se a automação pede a informação que falta antes de agir.

Ler artigo