Tem uma diferença enorme entre testar inteligência artificial e construir uma aplicação de inteligência artificial.
Testar IA é fácil. Você abre um playground, escolhe um modelo, escreve um prompt, melhora a resposta e mostra uma demo bonita. Construir uma aplicação de IA de verdade é outra conversa. Aí entram identidade, segurança, dados, governança, custo, observabilidade, integração, ciclo de vida e, principalmente, responsabilidade sobre o resultado.
Foi por isso que o posicionamento da Microsoft na Build 2025 chamou minha atenção. Quando a Microsoft apresenta o Azure AI Foundry como uma AI App and Agent Factory, ela não está apenas anunciando mais recursos. Ela está tentando organizar um novo modelo de desenvolvimento: sair da IA como experimento isolado e entrar na IA como plataforma de construção de software. Naquele anúncio, a Microsoft reforçou que agentes mais avançados precisam de modelos de ponta, ferramentas integradas e governança embutida, e apresentou um conjunto de inovações para transformar o Foundry em uma base mais completa para aplicações e agentes de IA.
Esse é o ponto central: o Foundry começa a fazer sentido quando você para de olhar para ele como “lugar para testar modelo” e começa a olhar como uma fábrica de aplicações inteligentes.
O problema não é criar uma demo. O problema é sustentar produção.
O mercado está cheio de demos de IA. Algumas impressionam nos primeiros cinco minutos. Poucas sobrevivem ao primeiro contato com produção.
E o motivo é simples: uma aplicação de IA real não depende apenas da qualidade do modelo. Ela depende do sistema em volta do modelo.
O modelo precisa de contexto.
O contexto precisa de fonte confiável.
A fonte precisa de permissão.
A resposta precisa ser avaliada.
A ação precisa ser rastreada.
O custo precisa ser controlado.
O comportamento precisa ser monitorado.
A falha precisa ser explicável.
Quando falta essa camada, a IA vira uma caixa-preta bonita. Responde bem quando tudo dá certo, mas ninguém sabe explicar quando dá errado.
A proposta do Azure AI Foundry, especialmente depois da Build 2025, é justamente atacar essa fragmentação. A plataforma passa a se posicionar como um ambiente para conectar desenvolvimento, modelos, agentes, ferramentas, observabilidade e governança em uma experiência mais unificada.
Para mim, esse é o movimento mais importante: a Microsoft está tentando transformar IA em disciplina de engenharia.
O que significa uma “AI App and Agent Factory”?
O termo “factory” é importante. Uma fábrica não existe para produzir uma peça artesanal uma única vez. Uma fábrica existe para repetir processo com qualidade, controle e escala.
Quando aplico essa ideia para IA, uma AI App and Agent Factory precisa responder algumas perguntas:
Como eu escolho o modelo certo?
Como eu conecto dados de forma segura?
Como eu crio agentes com ferramentas bem delimitadas?
Como eu avalio se a resposta está correta?
Como eu observo o comportamento em produção?
Como eu publico, versiono e melhoro essa aplicação?
Como eu garanto governança sem matar a velocidade?
Se a plataforma não ajuda nessas perguntas, ela é só mais um playground.
Na Build 2025, além do posicionamento de Foundry como fábrica de apps e agentes, a Microsoft também marcou um ponto importante: o Azure AI Foundry Agent Service entrou em disponibilidade geral. Junto com essa GA, vieram recursos como extensão do Foundry para Visual Studio Code, connected agents, tracing de agentes e acionamento por Azure Logic Apps.
Isso muda o patamar da conversa. Um serviço em GA passa uma mensagem diferente de um preview interessante. Ele começa a entrar no radar de arquitetura corporativa.
Minha leitura: agente precisa ser tratado como microserviço inteligente
Um erro comum é pensar em agente como uma pessoa digital. Eu prefiro pensar em agente como um microserviço inteligente com capacidade de raciocínio, acesso a ferramentas e limites bem definidos.
Essa leitura é mais técnica e menos fantasiosa.
Um microserviço tradicional recebe uma entrada, executa uma lógica e devolve uma saída. Um agente recebe uma intenção, interpreta a solicitação, pode consultar dados, escolher ferramentas, executar etapas e gerar uma resposta ou ação. A diferença é que parte da lógica não está escrita em código determinístico, mas em comportamento guiado por modelo, instruções, ferramentas e contexto.
Isso aumenta poder, mas também aumenta risco.
Por isso, o desenho de um agente precisa ter os mesmos cuidados de arquitetura que qualquer componente sério: responsabilidade clara, contrato, limite de permissão, observabilidade, rastreabilidade e estratégia de falha.
O próprio Agent Service reforça essa direção ao se posicionar como uma plataforma gerenciada para criar, publicar, escalar, rastrear e monitorar agentes, cuidando de runtime, identidade, observabilidade e segurança corporativa.
Ou seja: não estamos falando de prompt solto. Estamos falando de componente de software.
A arquitetura base que eu usaria em um projeto sério
Se eu fosse desenhar uma aplicação de IA corporativa usando Azure AI Foundry em maio de 2025, eu começaria com uma arquitetura simples, mas disciplinada.
A primeira camada seria a camada de experiência. Pode ser um portal interno, uma aplicação web, um chatbot corporativo, uma interface no Teams ou um fluxo acionado por evento. Essa camada não deveria concentrar inteligência demais. Ela é a porta de entrada.
A segunda camada seria a camada de orquestração. Aqui entra a lógica do agente ou do workflow. É onde o sistema entende a intenção, decide se precisa buscar informação, chama ferramentas e define o próximo passo.
A terceira camada seria a camada de modelos. Nem tudo precisa usar o modelo mais caro ou mais poderoso. Um projeto sério precisa diferenciar tarefas simples de tarefas complexas. Classificação, extração, sumarização, raciocínio e geração podem exigir modelos diferentes.
A quarta camada seria a camada de dados e grounding. Aqui entram bases documentais, Azure AI Search, arquivos, bancos de dados, APIs internas e fontes confiáveis. Essa camada é crítica porque a IA precisa responder com base em evidência, não em improviso.
A quinta camada seria a camada de ferramentas. Ferramenta é o que permite ao agente fazer algo além de responder texto. Pode ser abrir um chamado, consultar status, disparar um e-mail, executar uma função, chamar uma API ou acionar um processo.
A sexta camada seria a camada de observabilidade e avaliação. Sem tracing e evaluation, você não tem aplicação de IA. Você tem opinião sobre a qualidade da aplicação. E opinião não sustenta produção.
A sétima camada seria a camada de governança. Identidade, RBAC, políticas, auditoria, classificação de dados, limites de ação, revisão humana e segurança precisam estar no desenho desde o começo.
Essa arquitetura não é complexa por vaidade. Ela é necessária porque IA em produção falha de formas diferentes de software tradicional.
Um tutorial prático: desenhando um agente de atendimento interno
Vamos imaginar uma empresa que quer criar um agente interno para responder dúvidas sobre políticas, produtos e processos. Parece simples. Mas, se for mal desenhado, esse agente pode inventar política, responder com dado antigo ou acessar informação que não deveria.
Eu começaria com uma pergunta básica:
Qual problema esse agente resolve?
Não aceitaria uma resposta genérica como “ajudar os colaboradores”. Eu escreveria algo mais claro:
O agente deve responder dúvidas internas sobre políticas comerciais, consultar documentos aprovados, orientar próximos passos e escalar para revisão humana quando a pergunta envolver exceções, valores, contratos ou decisões sensíveis.
Essa frase já define muito.
Ela define o público.
Define o tipo de conhecimento.
Define o limite de ação.
Define quando escalar.
Depois eu separaria o agente em componentes.
Modelo: responsável por interpretar a pergunta e gerar a resposta.
Instruções: definem papel, limite, tom e regras de comportamento.
Fonte de dados: documentos internos aprovados.
Ferramenta de busca: mecanismo para recuperar informação relevante.
Ferramentas de ação: somente se necessário, como abrir chamado ou registrar solicitação.
Avaliação: conjunto de perguntas de teste e critérios de qualidade.
Tracing: rastreamento de chamadas, ferramentas e decisões.
Governança: acesso baseado em identidade e permissões.
Essa decomposição impede que o projeto vire “um prompt grande com esperança”.
Exemplo de instrução inicial para o agente
Uma instrução inicial para esse agente poderia ser algo assim:
Você é um agente interno especializado em políticas comerciais e processos da empresa.
Seu objetivo é ajudar colaboradores a encontrar respostas confiáveis com base nas fontes aprovadas.
Sempre que responder, use apenas informações encontradas nas fontes disponíveis.
Se não encontrar evidência suficiente, diga claramente que não há informação confiável para responder.
Não invente políticas, preços, prazos ou exceções.
Quando a pergunta envolver contrato, valor comercial, exceção de aprovação, risco jurídico ou decisão sensível, recomende validação com a área responsável.
Responda de forma objetiva, profissional e com próximos passos claros.Essa instrução ainda não é a aplicação. Ela é só uma parte do desenho.
A aplicação começa a ficar séria quando essa instrução está conectada a dados confiáveis, ferramentas bem delimitadas, tracing, avaliação e governança.
Onde entram os connected agents
Um dos recursos anunciados com a GA do Agent Service foi o conceito de connected agents, permitindo que agentes específicos por tarefa interajam com um agente principal, sem depender necessariamente de orquestradores externos.
Isso é muito relevante, mas também perigoso se for usado cedo demais.
Eu não começaria um projeto criando cinco agentes. Primeiro eu criaria um agente principal simples. Depois, conforme a complexidade crescesse, separaria responsabilidades.
Por exemplo:
Um agente principal entende a solicitação do usuário.
Um agente especialista consulta documentos de política.
Outro agente especialista avalia elegibilidade de processo.
Outro agente prepara uma resposta ou minuta.
O agente principal consolida e responde.
Isso faz sentido quando há especialização real. Não faz sentido criar multiagente só porque parece avançado.
A pergunta correta é: a separação de agentes reduz complexidade ou só cria teatro arquitetural?
Se reduzir complexidade, vale. Se for só para parecer moderno, é ruído.
O papel do tracing: sem rastreio, não existe confiança
Outro recurso importante da GA foi o tracing de agentes, que permite depurar e monitorar threads para enxergar entradas e saídas dos componentes envolvidos em uma execução.
Esse é um dos pontos mais importantes da arquitetura.
Quando um usuário diz “a IA respondeu errado”, você precisa investigar. O erro veio do modelo? Da pergunta ambígua? Da busca? Da fonte antiga? Da ferramenta? Da instrução? Da falta de contexto?
Sem tracing, você só tem a resposta final. Com tracing, você começa a entender o caminho.
E isso muda a maturidade do projeto. Porque uma aplicação de IA precisa de ciclo de melhoria. Você observa, encontra falhas, ajusta instruções, corrige fontes, melhora ferramentas, troca modelo ou muda fluxo.
Sem esse ciclo, o agente fica congelado no primeiro erro.
Logic Apps: quando o agente deixa de ser passivo
Outro ponto interessante anunciado em maio foi a possibilidade de acionar agentes usando Azure Logic Apps, por exemplo quando chega um novo e-mail ou um novo ticket de cliente.
Isso muda a natureza da aplicação.
Um agente em uma interface de chat é reativo: alguém pergunta, ele responde.
Um agente acionado por evento começa a entrar em processos reais: chegou ticket, analisa; chegou e-mail, classifica; chegou solicitação, orienta; surgiu alerta, inicia triagem.
Esse tipo de arquitetura é poderoso, mas exige mais cuidado.
Quando um agente é acionado automaticamente, você precisa definir:
Quais eventos disparam o agente?
Qual é o limite da resposta automática?
Quando precisa de aprovação humana?
O que pode ser registrado?
O que pode ser enviado?
Como auditar a execução?
Como evitar loop ou ação indevida?
Automação com IA não pode ser tratada como “deixa o agente resolver”. Precisa ter fronteira.
O que eu colocaria como mínimo para produção
Para um primeiro projeto sério com Azure AI Foundry, eu não levaria nada para produção sem estes elementos:
1. Caso de uso limitado
Nada de agente universal. Escolha uma tarefa específica.
2. Fontes confiáveis
O agente precisa saber de onde vem a resposta.
3. Instruções claras
Papel, limite, recusa e escalonamento precisam estar definidos.
4. Ferramentas mínimas
Dê ao agente só o que ele precisa para cumprir a tarefa.
5. Tracing habilitado
Sem rastreio, você não consegue investigar erro.
6. Avaliação contínua
Crie perguntas de teste e critérios de qualidade.
7. Revisão humana para casos críticos
Autonomia não significa ausência de controle.
8. Governança de identidade e acesso
O agente não deve acessar tudo. Deve acessar o necessário.
Esse é o básico. Não é burocracia. É engenharia.
O erro mais comum: começar pelo modelo
Muita gente começa perguntando: “qual modelo eu uso?”
Essa não é a primeira pergunta.
A primeira pergunta é: “qual tarefa eu estou tentando resolver?”
A segunda é: “qual risco existe se a IA errar?”
A terceira é: “quais fontes são confiáveis?”
A quarta é: “quais ações podem ser automatizadas?”
Só depois vem a escolha do modelo.
Modelo é importante, mas modelo não salva arquitetura ruim.
Uma aplicação mal desenhada com modelo excelente continua sendo uma aplicação mal desenhada. E uma aplicação bem desenhada pode usar modelos diferentes para tarefas diferentes, equilibrando custo, latência, qualidade e risco.
Como isso muda o papel do desenvolvedor e do arquiteto
O desenvolvedor que trabalha com IA precisa parar de pensar só em endpoint e começar a pensar em comportamento.
O arquiteto precisa parar de pensar só em recurso Azure e começar a pensar em ciclo de decisão.
O time de negócio precisa parar de pedir “um chatbot” e começar a descrever processo, exceções, critérios e limites.
Essa é a virada. IA não é só uma nova API. IA muda a forma como desenhamos interação, automação e decisão dentro do software.
Por isso a ideia de AI App and Agent Factory é relevante. Ela aponta para um futuro em que empresas não vão construir um agente isolado. Elas vão precisar de um processo recorrente para construir, publicar, observar e evoluir vários agentes e aplicações inteligentes.
Minha leitura sobre a Build 2025
Na minha leitura, a Build 2025 deixou claro que a Microsoft quer transformar o Azure AI Foundry em uma camada central da estratégia de IA aplicada. Não apenas para consumir modelos, mas para construir aplicações e agentes com ferramentas, governança e operação.
E a GA do Agent Service reforça essa leitura. Quando um serviço de agentes entra em disponibilidade geral e já vem com extensão para VS Code, connected agents, tracing e integração com Logic Apps, a mensagem é clara: agentes estão saindo da fase de demonstração e entrando na fase de engenharia.
Isso não significa que todo projeto precisa de agente. Mas significa que, quando fizer sentido usar agente, a discussão precisa ser muito mais madura.
Conclusão
O Azure AI Foundry como AI App and Agent Factory representa uma mudança importante na forma de construir IA no Azure.
A pergunta deixa de ser “como eu chamo um modelo?” e passa a ser “como eu desenho um sistema inteligente, seguro, observável e útil?”
Essa mudança é fundamental.
Porque empresas não precisam de mais demos. Empresas precisam de aplicações que resolvam problemas reais, com rastreabilidade, governança e capacidade de evolução.
Para mim, esse é o valor do Foundry nesse momento: ele começa a organizar a criação de aplicações de IA como uma fábrica, não como um experimento solto.
E uma fábrica boa não depende só de matéria-prima. Depende de processo.
No caso da IA, a matéria-prima é o modelo. O processo é a arquitetura.
Seja o primeiro a comentar