Posts

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. ...

Seu agent de diagnóstico vai bem numa interação. Aí o mesmo alerta volta na semana seguinte e ele zera a memória. Não lembra que já investigou. Não lembra que a causa raiz era aquele cronjob que explode memória toda quarta às 3h da manhã. Agent sem memória é como engenheiro que perde o caderno toda segunda. Sabe trabalhar. Só reaprende as mesmas coisas o tempo todo. O mapa pro profissional de infra Conceito de Memória O que faz Equivalente em infra Short-term memory Contexto da conversa atual Buffer de request (dados in-flight) Long-term memory Informações que persistem entre sessões Database, persistent storage Episodic memory Lembranças de interações passadas Logs, audit trail Semantic memory Conhecimento geral acumulado Knowledge base, wiki Working memory O que está “ativo” na cabeça do agent Cache, working set State Configuração atual do agent Estado do pod, configmap Consistency Garantia de que memória é correta Consistency model do banco Por que memória é difícil em agents LLMs são stateless. Cada request é independente. O modelo não “lembra” nada entre chamadas. Toda memória é simulada via contexto. ...

No post anterior, eu destrinchei como agents funcionam: LLM, tools e loop. Agora a conversa muda de nível. O problema não é fazer um demo de 5 minutos. É projetar um agent que aguente produção, rode 24/7 e não precise de babá. Continua sendo design de sistema, com as perguntas de sempre: quais são os requisitos, quais os failure modes, como escala e como monitora? As 5 decisões de design Projetar um agent normalmente vira 5 decisões: ...

Meu Watch Later tinha 302 vídeos. Tutoriais de Azure, receita de panqueca japonesa, debates teológicos, vídeo de hamster escapando de labirinto. Tudo junto, tudo misturado, completamente inútil como lista. Eu nunca ia assistir aquilo daquele jeito. Ninguém assiste. O Watch Later do YouTube é onde vídeo vai pra morrer. Resolvi limpar a bagunça inteira sem instalar extensão, sem dar permissão pra app de terceiro, sem arrastar vídeo por vídeo. Só JavaScript no console do navegador e uma IA pra categorizar. ...

Terça-feira, 14h. Seu colega mostra um demo: ele pede pro “agent” verificar o status de 5 servidores, identificar qual tem mais CPU usage, e criar um ticket pra investigação. O agent faz tudo sozinho. Sem scripts. Sem runbooks. Seu primeiro pensamento: “Isso é só um LLM chamando APIs, certo?” Sim. E não. O conceito é simples. A parte trabalhosa é fazer isso funcionar com segurança e previsibilidade em produção. É aí que mora a engenharia de verdade. ...

No post anterior, o watchdog de quota do Azure OpenAI era um script com if pct_of_tpm > 0.8: alert. Funciona, mas carrega um problema que qualquer pessoa que já configurou alerta de monitoramento conhece de cor: threshold fixo não entende contexto. Um batch job que sempre consome 90% de TPM por 10 minutos no fechamento do mês e depois volta ao normal é, para o script, o mesmo evento que algum agent solto no ambiente entrando em loop e queimando tokens sem parar. Os dois cruzam o mesmo threshold; só um deles merece acordar alguém. ...

Na Parte 1, montamos a base do Internal Developer Platform: Dev Center, templates Bicep para provisionamento self-service e AKS como runtime compartilhado com multi-tenancy. Aqui entram as camadas que deixam a plataforma segura, observável e governada. tl;dr: Governança com Azure Policy, observabilidade com App Insights + Grafana, e segurança com Workload Identity e Entra ID. Sem essas camadas, o IDP vira self-service sem controle. Governança: Azure Policy como guardrail A plataforma precisa garantir que, independente do que o desenvolvedor faça dentro do seu namespace ou resource group, certos padrões sejam mantidos. Azure Policy é a ferramenta para isso. ...