Agents

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

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

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

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