A Microsoft tornou Routines no Foundry Agent Service geralmente disponível, transformando parte da infraestrutura normalmente construída à volta de agentes numa capacidade gerida da plataforma. Um Routine pode iniciar um agente uma vez numa data futura, repetidamente segundo um horário ou quando chega um evento externo. O trigger, a ação do agente, as ligações, a identidade escolhida e o histórico de execução ficam reunidos no mesmo projeto Foundry.
À primeira vista, parece apenas agendamento. A mudança mais importante é arquitetural. Um agente autónomo útil precisa de mais do que um modelo e ferramentas: é necessário detetar quando surge trabalho, autenticar no sistema certo, entregar o evento ao agente e conservar um registo do que aconteceu. O Foundry passa a assumir uma parte significativa dessa camada operacional.
Três modos de trigger cobrem os padrões principais
A versão GA suporta timer, execução recorrente e triggers baseados em eventos. Um timer executa o agente uma única vez no futuro. Um Routine recorrente serve para relatórios diários, verificações periódicas ou monitorização operacional. Um trigger por evento reage a alterações num sistema ligado.
A Microsoft indica como integrações iniciais eventos de issues do GitHub e novas mensagens em canais do Microsoft Teams. O Foundry recebe o evento através da ligação configurada, envia o payload ao agente e regista a execução. O agente pode então raciocinar sobre o evento, usar as suas ferramentas e agir sem esperar que alguém abra primeiro uma conversa.
Isto reduz a diferença entre um agente que sabe executar uma tarefa e um agente realmente automatizado dentro de um processo. Saber classificar uma issue não é suficiente; alguém tem de observar o GitHub, autenticar, transportar o evento e registar o resultado. Routines integra essa maquinaria com a configuração do agente.
A identidade passa a fazer parte da automação
O detalhe mais consequente é a identidade. Segundo a Microsoft, os Routines podem executar o agente e as suas ferramentas com a identidade do criador do Routine ou com a identidade própria do agente.
A identidade do criador mantém o acesso delegado dessa pessoa e é adequada quando as ferramentas usam OAuth do utilizador. A identidade do agente permite que a automação funcione como entidade independente com permissões configuradas no Microsoft Entra.
A diferença define que dados uma automação pode ler e que ações pode executar sem intervenção humana. Dois Routines que usam o mesmo modelo podem, por isso, exigir fronteiras de acesso completamente diferentes.
Para as equipas de engenharia, a identidade deve ser desenhada juntamente com o trigger e a ação. Um relatório diário pode necessitar de leitura alargada mas não de escrita. Um agente que reage a um incidente pode precisar apenas de um conjunto estreito de permissões de escrita, aprovações explícitas e registo completo de cada ação.
O reminder tool acrescenta continuidade
O anúncio descreve também o reminder tool, ainda em preview, para Hosted Agents que precisam de continuar trabalho mais tarde. Um agente pode iniciar uma tarefa demorada, agendar um lembrete e ser novamente executado na mesma conversation para verificar se a tarefa terminou.
Isto é diferente de um schedule externo. Um Routine decide quando o ambiente deve iniciar o agente; um reminder permite que o próprio agente reconheça que o trabalho ainda não terminou e organize uma continuação posterior. Em conjunto, estes mecanismos suportam cenários como esperar por um export, acompanhar um deployment ou retomar trabalho após uma aprovação.
Para automação com estado, esta capacidade pode evitar a criação de um serviço de polling e de uma camada separada para guardar contexto.
Análise Aipolix: o scheduler está a entrar no control plane do agente
A principal implicação é que as plataformas de agentes estão a absorver infraestrutura que antes ficava fora do runtime. Agendamento, receção de eventos, identidade, ligações e histórico de execução convergem numa superfície de controlo gerida.
Esta consolidação pode simplificar sistemas de produção porque existem menos componentes independentes para instalar e monitorizar. Também pode tornar a governance mais clara: é possível analisar o que acorda o agente, com que identidade trabalha e que execuções ocorreram.
Mas simplificar a arquitetura não elimina questões de fiabilidade. O anúncio afirma que o Foundry coloca as invocações em queue e regista os resultados, mas não define ali todas as garantias de entrega ou regras de retry. Antes de usar um Routine para operações irreversíveis — apagar dados, alterar acessos ou executar operações financeiras — as equipas devem confirmar como a configuração real lida com eventos duplicados, retries, falhas parciais e replay.
Esta é a fronteira operacional menos visível. Um modelo pode escolher a ação correta e ainda assim provocar um mau resultado se o mesmo evento for entregue duas vezes ou se uma tool call tiver sucesso antes de o run ser repetido. Ferramentas idempotentes, privilégio mínimo e aprovações explícitas continuam a ser responsabilidades da aplicação.
Porque é que GA importa
Routines já existia em preview. A novidade material não é, por isso, a capacidade de agendar um agente, mas a passagem desta camada de automação para disponibilidade geral destinada a utilização em produção.
Para organizações que já usam Foundry Agent Service, isto pode eliminar uma categoria de glue code. Em vez de cada agente precisar de scheduler, recetor de webhooks, queue e armazenamento de histórico separados, a equipa pode começar com um Routine gerido e acrescentar infraestrutura própria apenas quando necessita de garantias ou controlos adicionais.
A direção mais ampla é clara: as plataformas empresariais de agentes estão a passar de «alojar um modelo com ferramentas» para «operar um ator de software de longa duração». Quando triggers, identidade e continuação passam a ser componentes do runtime, a qualidade do sistema depende tanto dos controlos operacionais como do modelo que raciocina no seu interior.