Último post da série. Depois de 16 textos olhando pra dentro da AI, eu queria fechar com o uso prático. Como essas ferramentas entram no trabalho de infra sem virar bengala. É um post bem opinativo. Estou escrevendo do lugar de quem usa Copilot, Claude e chat com LLM todo dia desde 2023. Tem coisa que acelera muito. Tem coisa que atrapalha. E tem anti-pattern que eu já vi time repetir até cansar. ...
No post anterior, eu desenhei um assistente que consulta runbooks, mantém contexto e chama ferramentas de infraestrutura. A arquitetura fazia sentido, mas ainda tinha um problema: os exemplos eram recortes. Faltavam os arquivos que conectam uma parte à outra. Neste post, parto de uma aplicação que roda localmente sem Azure e levo a mesma vertical slice para Container Apps, Azure OpenAI e Azure AI Search. O código está no repositório agentic-infra-handbook, em labs/personal-assistant. O README do lab também traz um passo a passo independente para executar o projeto localmente e fazer o deploy no Azure, incluindo App Registration, configuração do AZD, callback de autenticação, validação e limpeza dos recursos. ...
Depois de 13 posts sobre os componentes de um sistema de IA, faltava colocá-los para trabalhar juntos. O projeto deste artigo é um assistente pessoal que responde perguntas sobre infraestrutura usando runbooks, documentação interna e ferramentas de monitoramento. O desenho é próximo do que eu usaria numa entrevista de system design ou como ponto de partida para um design doc interno. Os exemplos de código são recortes, não uma aplicação pronta para copiar e colocar em produção. ...
Azure AI Foundry: do zero à produção O que eu cubro quando um cliente pergunta “queremos construir aplicações com IA no Azure, por onde começamos?” TL;DR: Azure AI Foundry é a plataforma unificada para aplicações de IA no Azure. Comece com Standard PAYGO, use Priority Processing de forma seletiva quando latência importa mas o tráfego é variável, e migre a carga base previsível para PTU quando a utilização passar de 60-70%. Use o ptucalc.com (código no GitHub) para modelar custos antes de comprometer. ...
De bombeiro a engenheiro de plataforma: skills customizados para o Azure SRE Agent TL;DR: O Azure SRE Agent é excelente em resposta reativa a incidentes, mas não cobre operações proativas por padrão. Criei um pack open-source com 8 skills customizados que adicionam auditorias de governança, relatórios FinOps, capacity planning, postmortems, e mais. Combinados com Scheduled Investigations, eles movem suas operações de reativas para proativas. Como uma conversa com um cliente que nunca tinha ouvido falar de SRE Agent me levou a criar um pack de skills que transforma o agente de reativo para proativo. ...
Cada vez que um agent precisa acessar um novo data source, alguém escreve uma integração custom. GitHub? Integração custom. Jira? Integração custom. Azure Monitor? Integração custom. Banco de dados? Mais uma. Se isso parece com o problema que REST/HTTP resolveu pra APIs web, você está pensando certo. MCP (Model Context Protocol) é a tentativa de padronizar como AI models e agents se conectam a data sources e ferramentas. O mapa pro profissional de infra Conceito MCP O que faz Equivalente em infra MCP Server Expõe dados/ferramentas via protocolo padrão API server, microserviço MCP Client Consome dados/ferramentas de MCP servers API client, SDK Host Aplicação que roda o client (VS Code, Claude, etc.) Browser, app que consome APIs Tool Função executável via MCP Endpoint REST (POST /action) Resource Dado acessível via MCP Endpoint REST (GET /data) Prompt Template de interação Slash command, prompt salvo, formulário parametrizado Transport Como client e server se comunicam stdio, Streamable HTTP (SSE legado só por compatibilidade) O problema N×M Antes de MCP, cada combinação de (AI application × data source) precisava de código custom. ...
Os quatro posts anteriores construíram agents desenhados por mim, em que eu sei exatamente o que cada tool faz e lembro de cabeça qual flag restringe o quê. Isso funciona até o momento em que outro time, sem ter lido esta série, sobe o próprio agent na mesma plataforma. A partir daí, a pergunta deixa de ser “essa tool é segura?” e passa a ser “como eu sei, no nível organizacional, o que está rodando e com quais permissões?”. É nesse momento que governança deixa de ser boa prática e vira pré-requisito. ...
Um agent sozinho é como aquele microserviço que nasceu pequeno e, de repente, quer resolver tudo. Funciona até certo ponto. Depois vira confusão. Quando a tarefa cresce, especialização ajuda. Se você já migrou de monolito pra microservices, o raciocínio aqui vai soar familiar. As perguntas são quase as mesmas. Como eles se comunicam? Quem coordena? O que acontece quando um falha? Quanto custa essa coordenação? O mapa pro profissional de infra Conceito Multi-Agent O que faz Equivalente em infra Orchestrator Coordena agents, delega tarefas API Gateway, Workflow engine Worker agent Executa tarefas específicas Microserviço Message passing Comunicação entre agents Message queue (Service Bus) Shared state Dados compartilhados entre agents Database, Redis Handoff Transferir contexto entre agents Request forwarding Supervisor Monitora e intervém quando algo falha Kubernetes controller, watchdog Consensus Múltiplos agents concordam numa decisão Raft, quorum Quando usar multi-agent Cenário Single agent Multi-agent Task de 3-5 steps num domínio Ideal Overkill Task que cruza múltiplos domínios (DB + rede + app) Fica confuso Ideal Task onde diferentes partes precisam de tools diferentes Tools demais Separação natural Task onde precisas de “second opinion” Possível (reflection) Mais robusto Task com trabalho paralelizável Limitado Escala melhor Regra prática: se um agent já está carregando tools demais e você precisa explicar o mapa inteiro do mundo pra ele funcionar, provavelmente chegou a hora de quebrar em mais de um. ...
Se agents são controllers (LLM + tools + loop), padrões agentic são os design patterns que esses controllers usam. Assim como em software tradicional você tem Observer, Strategy e Chain of Responsibility, em AI agents também existem padrões que aparecem o tempo todo. Saber reconhecer esses patterns encurta bastante o caminho. Em vez de desenhar tudo do zero a cada caso, você monta a solução com blocos que já provaram valor. ...
Até aqui, a série construiu duas coisas separadas: no post 1, um agent que fala com AKS via aks-mcp para diagnosticar o cluster; nos posts 2 e 3, um watchdog que observa o consumo de TPM no Azure OpenAI e decide o quão urgente um alerta deve ser. Os dois funcionam isoladamente, e isolados já entregam valor. Mas, separados, eles também deixam sem resposta a pergunta mais óbvia de todas: quando o consumo de tokens dispara do nada, a primeira coisa que qualquer SRE pergunta é “alguém fez deploy?”. Hoje essa resposta ainda é manual, alguém olhando o alerta do watchdog em uma aba e o dashboard do AKS em outra. ...