Showing Posts From

Mcp

Agentic MLOps: como A2A e MCP estão substituindo DAGs do Airflow por equipes de agentes

Agentic MLOps: como A2A e MCP estão substituindo DAGs do Airflow por equipes de agentes

Se você já manteve um pipeline de ML em produção com Airflow, sabe o que é acordar às 3h da manhã porque uma DAG de retraining falhou no step 14 de 23. O log diz Task failed: validation_step_3. Qual validation? De qual modelo? Com quais dados? Boa sorte. O artigo da InfoQ publicado em março de 2026 — "Architecting Agentic MLOps with A2A and MCP" — propõe algo que venho testando nos últimos meses: trocar DAGs rígidos por equipes de agentes que se comunicam via protocolos padronizados. Não é hype. É uma mudança de arquitetura com trade-offs reais que vale a pena entender. O problema com DAGs de MLOps Pipelines tradicionais de ML — Airflow, Prefect, Dagster — tratam MLOps como uma sequência linear: ingestão → feature engineering → treino → validação → deploy → monitoramento. Cada step é um nó no grafo. A lógica de decisão ("o modelo passou no threshold?", "precisa de rollback?") vira um emaranhado de BranchPythonOperator e XComs que ninguém quer debugar. O problema não é o Airflow. É que ML pipelines não são lineares. Validação pode exigir retreino com dados diferentes. Deploy pode precisar de canary progressivo com rollback automático. Monitoramento pode detectar drift e disparar retraining sem esperar o schedule. Tentar expressar isso como um DAG estático é como tentar desenhar um fluxograma para uma conversa — funciona no PowerPoint, quebra na realidade. A2A + MCP: os dois protocolos que habilitam a mudança Antes de entrar na arquitetura, vale alinhar os protocolos. Já cobri MCP em detalhe no post anterior, mas o resumo rápido:MCP (Model Context Protocol, Anthropic): protocolo de conexão entre agentes e ferramentas externas. O agente declara o que precisa, o MCP server expõe as capabilities. Pense nele como a interface entre o agente e o mundo — registries de modelo, buckets S3, APIs de monitoramento, o que for.A2A (Agent-to-Agent, Google): protocolo de comunicação entre agentes. Diferente do MCP que conecta agente→ferramenta, o A2A conecta agente→agente. Cada agente publica um Agent Card declarando suas capabilities, aceita Tasks via JSON-RPC, e pode negociar formatos de resposta. É o que permite que um Validation Agent peça ao Training Agent para retreinar com parâmetros específicos sem hardcodar essa lógica.A convergência dos dois é o que torna Agentic MLOps viável. MCP para acessar infraestrutura, A2A para coordenar decisões entre agentes. A arquitetura em camadas O paper da InfoQ propõe três agentes core: Orchestrator Agent O cérebro do pipeline. Recebe o trigger (schedule, webhook, drift alert) e decide o plano de execução. Diferente de uma DAG, o plano é dinâmico — o orchestrator avalia o contexto (qual modelo, qual dataset, qual o estado do último deploy) e monta a sequência em runtime. Validation Agent Responsável por qualidade do modelo. Roda suítes de teste, verifica drift de dados, compara métricas com baselines. O ponto-chave: via A2A, ele pode rejeitar um modelo e pedir retreino com instruções específicas ("accuracy caiu 3pp no segmento X, retreinar com oversampling desse segmento"). Em uma DAG, isso seria um loop com estado compartilhado que ninguém quer manter. Deployment Agent Gerencia canary, blue-green, rollback. Conecta via MCP ao Kubernetes, ao registry de modelos, ao Prometheus. Se o canary falha, comunica via A2A ao Orchestrator que decide o próximo passo — rollback, retreino, ou escalar para um humano. Hands-on: esqueleto de um pipeline agêntico Para materializar a ideia, montei um esqueleto usando CrewAI (que já suporta A2A e MCP nativamente desde a v0.8) com MCP servers para acessar MLflow e Kubernetes: # agentic_mlops_crew.yaml agents: orchestrator: role: "ML Pipeline Orchestrator" goal: "Coordinate model retraining and deployment" tools: - mcp_server: "mlflow-registry" # MCP: acessa model registry - mcp_server: "s3-datasets" # MCP: acessa datasets a2a_capabilities: - "plan_execution" - "escalation" validator: role: "Model Quality Gate" goal: "Validate model performance against baselines" tools: - mcp_server: "mlflow-registry" - mcp_server: "evidently-monitoring" # MCP: drift detection a2a_capabilities: - "validation_report" - "retrain_request" deployer: role: "Model Deployment Manager" goal: "Safe progressive rollout with automatic rollback" tools: - mcp_server: "k8s-serving" # MCP: KServe/Seldon - mcp_server: "prometheus-metrics" a2a_capabilities: - "canary_status" - "rollback_trigger"O fluxo em pseudo-código: # orchestrator recebe trigger trigger = await orchestrator.receive_task(event)# monta plano dinâmico baseado no contexto plan = orchestrator.plan( model=trigger.model_id, reason=trigger.reason, # "scheduled" | "drift_detected" | "manual" last_deployment=await mlflow.get_latest(trigger.model_id) )# treina e envia para validação via A2A model_artifact = await orchestrator.execute_training(plan) validation = await validator.validate( # A2A call model=model_artifact, baseline=plan.baseline_metrics, required_segments=plan.critical_segments )if validation.status == "REJECTED": # validator pode pedir retreino com instruções específicas plan = orchestrator.replan(validation.feedback) # loop controlado pelo orchestrator, não por uma DAG elif validation.status == "APPROVED": deployment = await deployer.canary_deploy( # A2A call model=model_artifact, traffic_pct=10, monitor_minutes=30 )A diferença fundamental: a lógica de decisão vive nos agentes, não no grafo. Quando o validator rejeita um modelo, ele não apenas retorna False — ele retorna contexto ("accuracy no segmento enterprise caiu 4pp, dataset de treino tem 12% menos amostras desse segmento vs. mês passado"). O orchestrator usa esse contexto para replanejar. Trade-offs reais: quando NÃO migrar Seria desonesto vender isso como solução universal. Aqui estão os trade-offs que encontrei:Aspecto DAG tradicional Agentic MLOpsLatência de decisão Milissegundos (if/else) Segundos (LLM inference por decisão)Custo Compute do step Compute + tokens de LLM por agenteDebuggability Log linear, fácil de rastrear Traces distribuídos, precisa de observabilidade sériaDeterminismo 100% reproduzível Decisões do LLM podem variar entre runsComplexidade inicial Alta (DAG), mas conhecida Alta (agentes), e poucos dominamO custo de LLM inference em cada decisão é real. Em um pipeline que roda 50 vezes por dia, cada chamada ao orchestrator com contexto de 4K tokens custa. Fiz a conta para um cenário com 3 agentes, 8 chamadas LLM por run, usando Claude Sonnet: **$2.40/dia** vs. zero de compute decisório no Airflow. Para pipelines de alta frequência, isso escala. E o determinismo é a objeção mais séria. Se o Validation Agent aprova um modelo na segunda-feira e rejeita o mesmo modelo na terça com os mesmos dados, você tem um problema de auditoria. A mitigação que funciona: usar LLMs com temperature 0 para decisões binárias e logar o chain-of-thought completo como artefato de compliance. Quando faz sentido migrar Na minha experiência, Agentic MLOps compensa quando:Seu pipeline tem lógica de decisão complexa — múltiplos caminhos de retreino, rollback condicional, validação por segmento Você já tem MCP servers para sua infra (MLflow, K8s, monitoramento) — montar isso do zero é um projeto separado A frequência do pipeline é baixa/média — diário ou semanal, não a cada 5 minutos Você precisa de feedback loops que hoje são manuais — o Validation Agent substitui aquele Slack alert que um engenheiro olha (ou não) antes de aprovar o deploySe seu pipeline é treino → valida threshold → deploy sem ramificações, Airflow resolve. Não complique. O que vem pela frente O paper da InfoQ menciona Agent Registries — um catálogo onde agentes de MLOps publicam suas capabilities via A2A e podem ser compostos dinamicamente. Imagine um marketplace interno onde o time de ML publica um "Feature Quality Agent" e o time de infra publica um "Cost Optimization Agent", e o orchestrator compõe os dois no mesmo pipeline sem ninguém escrever glue code. Ainda está cedo. A maioria das empresas não tem nem MCP servers para a infra de ML, muito menos agentes A2A em produção. Mas a direção é clara: MLOps vai de orquestração imperativa para coordenação declarativa. De DAGs para equipes. Se você já tem MCP rodando e está pensando no próximo passo, o repo de referência da InfoQ é um bom ponto de partida. E se você ainda está no Airflow com 47 BranchPythonOperators aninhados — bom, pelo menos agora sabe que existe alternativa.

MCP cruza 97 milhões de installs: o protocolo da Anthropic que virou a infraestrutura invisível dos agentes

MCP cruza 97 milhões de installs: o protocolo da Anthropic que virou a infraestrutura invisível dos agentes

Em 25 de março de 2026, o Model Context Protocol atingiu 97 milhões de downloads mensais do SDK. No lançamento, em novembro de 2024, eram 2 milhões. Isso é um crescimento de 4.750% em dezesseis meses — a curva de adoção mais rápida de qualquer padrão de infraestrutura de IA na história. Se você está construindo agentes e ainda não integrou MCP, este artigo é um alerta. De protocolo obscuro a infraestrutura de facto Quando a Anthropic lançou o MCP no final de 2024, a reação do mercado foi morna. Mais um protocolo? Mais um padrão aberto que uma empresa cria para servir seus próprios interesses? A desconfiança era compreensível — o histórico de "padrões abertos" controlados por big techs não é exatamente inspirador. O ponto de inflexão veio quando a OpenAI anunciou, em 2025, que adotaria o MCP como padrão de integração para seus agentes. Quando o criador do GPT decide usar o protocolo do concorrente em vez de construir o próprio, o mercado percebe que algo diferente está acontecendo. Google seguiu com o Gemini. Frameworks de agentes como LangChain, CrewAI e AutoGen integraram MCP em suas stacks. Em menos de um ano, a pergunta deixou de ser "vamos suportar MCP?" e virou "qual servidor MCP a gente conecta primeiro?" Hoje são mais de 5.800 servidores MCP — entre comunitários e enterprise — cobrindo bancos de dados, CRMs, provedores de nuvem, ferramentas de produtividade, plataformas de desenvolvimento, e-commerce e analytics. Todo grande provedor de IA suporta o protocolo. Claude, GPT-5.4, Gemini, todos falam MCP. O que o MCP resolve (e por que isso importa mais do que parece) A explicação mais simples: MCP é para agentes de IA o que USB-C é para dispositivos. Um conector universal que padroniza como agentes se conectam a ferramentas e fontes de dados externas. Antes do MCP, cada integração era custom. Quer que seu agente acesse o Salesforce? Escreva um conector. PostgreSQL? Outro conector. Google Calendar? Mais um. Cada combinação de modelo + ferramenta exigia implementação específica. Para uma startup construindo um agente que precisa acessar dez ferramentas, isso significava dez integrações distintas, cada uma com sua autenticação, formato de dados e tratamento de erros. O MCP padroniza tudo isso. Um servidor MCP para o Salesforce funciona com qualquer cliente MCP — seja ele rodando Claude, GPT ou um modelo open-source. O agente não precisa saber como cada ferramenta funciona internamente. Ele fala MCP, o servidor traduz. Um paper recente no arxiv (2603.13417) — "Bridging Protocol and Production: Design Patterns for Deploying AI Agents with MCP" — documenta os padrões de design que estão emergindo. Não é mais teoria. Empresas estão deployando agentes em produção usando MCP como camada de integração padrão. As dores de crescimento de um protocolo que cresceu rápido demais Crescer 4.750% em dezesseis meses tem consequências. O roadmap de 2026 do MCP, detalhado pela The New Stack, aborda problemas reais que surgiram com a adoção em escala. Autenticação e autorização. Quando o MCP era usado por desenvolvedores em ambientes locais, auth era um detalhe. Com servidores enterprise conectando agentes a sistemas críticos — ERP, bancos de dados financeiros, plataformas de compliance — a camada de segurança precisa ser robusta. O roadmap promete um framework de autenticação padronizado, mas por enquanto cada implementação resolve isso de forma diferente. Streaming e estado. Agentes em produção precisam manter contexto entre chamadas e lidar com operações de longa duração. O protocolo original foi desenhado para interações request-response simples. Adaptar isso para fluxos complexos — onde um agente monitora um pipeline de dados em tempo real, por exemplo — exige extensões que ainda estão sendo definidas. Governança de servidores. Com 5.800+ servidores, a qualidade varia enormemente. Alguns são mantidos por enterprises com SLA. Outros são projetos de fim de semana de um desenvolvedor que pode abandonar o repo amanhã. Para empresas que dependem de um servidor MCP em produção, a questão de quem mantém e garante a estabilidade é real. São dores legítimas. Mas são dores de crescimento, não de design. O protocolo funciona. O desafio agora é fazê-lo funcionar em escala enterprise com as garantias que produção exige. O elefante na sala: Anthropic controla o protocolo Não dá para analisar o MCP sem discutir quem o controla. A Anthropic criou o protocolo, mantém o repositório principal e define o roadmap. Sim, é open-source. Sim, qualquer um pode contribuir. Mas a governança é da Anthropic. Isso é ao mesmo tempo uma força e um risco. Força porque garante coerência de design e velocidade de evolução — não há comitê de 47 empresas discutindo a cor do bikeshed. Risco porque a Anthropic é uma empresa com interesses comerciais. Se em algum momento o protocolo evoluir de uma forma que favorece o ecossistema Claude em detrimento de outros, a neutralidade desmorona. Até agora, a Anthropic jogou o jogo certo. Manter o protocolo aberto o suficiente para que a OpenAI adotasse foi um movimento estratégico brilhante. Quando seu maior concorrente usa sua infraestrutura, você não precisa vencer a guerra dos modelos para controlar o ecossistema. É a mesma lógica que fez o Android dominar mobile. Google não precisava que todo mundo usasse Pixel. Precisava que todo mundo usasse Android. A Anthropic não precisa que todo mundo use Claude. Precisa que todo mundo use MCP. O que isso significa para startups brasileiras Aqui é onde a análise fica prática. O ecossistema brasileiro de agentes de IA está crescendo rápido. BNDES lançou fundo de R$1 bilhão para IA, aceleradoras estão financiando startups de agentes verticais, empresas como Stone, Nubank e iFood estão construindo capacidade interna de agentes. Se essas startups e times internos estão construindo agentes sem MCP, estão criando silos. Cada integração custom é dívida técnica. Cada conector proprietário é uma barreira para interoperabilidade. Quando um cliente pergunta "seu agente se integra com nosso CRM?" e a resposta é "precisamos de 3 semanas para construir o conector", o concorrente que responde "sim, via MCP" vence. A recomendação é direta: se você está construindo agentes no Brasil, MCP não é opcional. É a camada de integração que o ecossistema global padronizou. Ignorar isso é o equivalente a construir um app mobile que não roda em Android. Tecnicamente possível. Comercialmente suicida. Para quem quer ir além de consumir o protocolo, há oportunidade em contribuir. O ecossistema de servidores MCP ainda tem gaps significativos para ferramentas e plataformas populares no Brasil — Totvs, RD Station, Pipefy, Conta Azul. Construir e manter servidores MCP para o stack brasileiro é uma forma de gerar valor e posicionar-se no ecossistema global. O ponto que importa 97 milhões de installs não é uma métrica de vaidade. É a prova de que o ecossistema de agentes convergiu para um padrão de integração. Não é perfeito — o roadmap de 2026 mostra que há problemas reais a resolver. Não é neutro — a Anthropic controla a direção. Mas é o padrão. E em infraestrutura, o padrão vence o melhor. A Anthropic fez algo que nenhum outro player de IA conseguiu: criou a camada de interoperabilidade que todos usam. Não vendendo modelos. Vendendo o protocolo que conecta modelos ao mundo. E quem controla a conexão, controla o ecossistema.

MCP em produção — 97M downloads, design patterns do arxiv, e o que ainda quebra

MCP em produção — 97M downloads, design patterns do arxiv, e o que ainda quebra

Em novembro de 2024, quando a Anthropic lançou o Model Context Protocol, os SDKs tinham 2 milhões de downloads mensais e a maioria das pessoas nem sabia o que era. Eu lembro de olhar a spec e pensar "isso é interessante, mas quem vai adotar?". Dezesseis meses depois, são 97 milhões de downloads mensais e eu preciso admitir que estava errado. MCP virou o protocolo padrão de conexão entre LLMs e ferramentas externas. Claude, GPT-5.4, Gemini — todos suportam. São 5.800+ servers no ecossistema. 4.750% de crescimento. E agora saiu um paper no arxiv que finalmente documenta o que funciona e o que não funciona quando você tenta colocar isso em produção. O paper: arxiv 2603.13417 O paper "Bridging Protocol and Production: Design Patterns for Deploying AI Agents with MCP" é exatamente o tipo de documento que faltava. Não é um paper teórico sobre a beleza do protocolo — é um catálogo de design patterns extraídos de deploys reais de agentes usando MCP. Os patterns que mais me interessaram: 1. Gateway Pattern Em vez de cada agente se conectar diretamente a N MCP servers, você coloca um gateway na frente que gerencia conexões, auth e rate limiting. Parece óbvio, mas 90% dos tutoriais mostram conexão direta. Em produção com 10+ servers, sem gateway você vai ter um pesadelo de configuração e debug. 2. Tool Composition Pattern Combinar ferramentas de múltiplos MCP servers em uma única chamada do agente. O paper mostra que a melhor abordagem é composição declarativa — o agente declara o que precisa, e o orquestrador resolve quais servers chamar. Tentativas de composição imperativa (o agente decidindo a sequência de chamadas) são frágeis e difíceis de debugar. 3. Fallback Chain Pattern Quando um MCP server não responde, ter uma cadeia de fallback com servers alternativos. O paper documenta três estratégias: retry simples, fallback para server alternativo, e degradação graceful (retornar resultado parcial). Na prática, já implementei a terceira e é a que menos frustra o usuário final. 4. Context Window Management O pattern mais técnico e mais útil. MCP servers podem retornar quantidades enormes de contexto — um server de database pode devolver milhares de linhas. O paper propõe um context budget por tool call, onde o orquestrador limita o output de cada server para caber no context window do modelo. Sem isso, um server guloso come o contexto inteiro e o agente perde acesso às outras ferramentas. Hands-on: criando um MCP server Chega de teoria. Vamos montar um MCP server básico que expõe uma API de busca para um agente. TypeScript (SDK oficial) npm install @modelcontextprotocol/sdkimport { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { z } from "zod";const server = new McpServer({ name: "search-server", version: "1.0.0", });// Registra uma tool que o agente pode chamar server.tool( "search_docs", "Busca na documentação interna", { query: z.string().describe("Termo de busca"), limit: z.number().default(5).describe("Máximo de resultados"), }, async ({ query, limit }) => { // Aqui vai sua lógica real — Elasticsearch, pgvector, whatever const results = await searchIndex(query, limit); return { content: [ { type: "text", text: JSON.stringify(results, null, 2), }, ], }; } );const transport = new StdioServerTransport(); await server.connect(transport);Python (SDK via PyPI) pip install mcpfrom mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import TextContent, Toolserver = Server("search-server")@server.tool() async def search_docs(query: str, limit: int = 5) -> list[TextContent]: """Busca na documentação interna.""" results = await search_index(query, limit) return [TextContent(type="text", text=str(results))]async def main(): async with stdio_server() as (read, write): await server.run(read, write, server.create_initialization_options())if __name__ == "__main__": import asyncio asyncio.run(main())Ambos os SDKs usam stdio como transport padrão — o client spawna o server como processo filho e se comunica via stdin/stdout. Isso é simples para desenvolvimento, mas em produção você vai querer HTTP/SSE (Server-Sent Events), que ambos os SDKs já suportam. Conectando no Claude Desktop (teste rápido) Edite o claude_desktop_config.json: { "mcpServers": { "search-docs": { "command": "node", "args": ["./dist/server.js"] } } }Reinicie o Claude Desktop e a tool search_docs aparece disponível. O agente pode invocá-la naturalmente durante a conversa. O que ainda quebra em produção Aqui é onde eu troco o chapéu de entusiasta pelo de engenheiro cansado. MCP em produção tem problemas reais que o hype esconde. Auth cross-server O maior gap. Cada MCP server gerencia sua própria autenticação. Se você tem 15 servers, o usuário precisa autenticar em cada um separadamente. Não existe um padrão de SSO ou token federation nativo no protocolo. O blog da WorkOS documenta bem esse problema e propõe soluções, mas nenhuma é oficial ainda. Na prática, o que eu faço é injetar tokens via variáveis de ambiente no momento do spawn do server. Funciona, mas é um hack — e não escala para cenários onde o token precisa ser refreshed durante a sessão. Session state MCP sessions são stateless por padrão. Se o server crashar e reiniciar, todo o contexto acumulado se perde. O paper do arxiv propõe um State Checkpoint Pattern, mas ninguém implementou isso nos SDKs oficiais ainda. Se seu agente depende de estado acumulado ao longo de uma conversa (e a maioria depende), você precisa implementar persistência por conta própria. Streaming O suporte a streaming de respostas longas é inconsistente entre implementações. O SDK TypeScript lida bem com SSE, mas o SDK Python tem edge cases com backpressure que podem causar memory leaks em sessões longas. Já perdi horas debugando isso. Observabilidade Não existe um padrão de tracing entre client e servers MCP. Se uma cadeia de 5 tool calls falha, boa sorte descobrindo onde foi. Eu adaptei OpenTelemetry manualmente nos meus servers, mas deveria ser built-in. Roadmap 2026: o que vem por aí O The New Stack publicou o roadmap que a comunidade está trabalhando. Os pontos mais relevantes:Auth padronizado: OAuth 2.1 como padrão de autenticação para MCP servers. Finalmente. Streamable HTTP transport: substituição do SSE por um transport mais robusto para produção. Registry protocol: um padrão para discovery de MCP servers — tipo um DNS para ferramentas de agentes. Elicitation: capacidade do server pedir informação adicional ao usuário via o client, sem interromper o fluxo do agente.Se o auth padronizado e o registry saírem no Q2 como prometido, MCP vira um protocolo enterprise-ready de verdade. Até lá, prepare-se para escrever bastante glue code. Veredito MCP não é mais experimental. 97 milhões de downloads mensais e suporte universal dos providers transformaram o protocolo em padrão de facto. O paper arxiv 2603.13417 é leitura obrigatória para quem está deployando agentes — os design patterns economizam semanas de tentativa e erro. Mas "padrão de facto" não significa "maduro". Auth, state e observabilidade são problemas reais que você vai enfrentar. O roadmap promete resolver boa parte disso em 2026, e a velocidade da comunidade (de 2M para 97M downloads em 16 meses) me dá alguma confiança. Se você ainda não tem MCP servers no seu stack de agentes, comece com o Gateway Pattern e um server simples como o exemplo acima. Mantenha o escopo pequeno, instrumente tudo, e prepare-se para reescrever o auth quando o padrão OAuth 2.1 sair. Paper: arxiv.org/abs/2603.13417. SDK TypeScript: @modelcontextprotocol/sdk. SDK Python: mcp no PyPI. Vai lá, monta um server, quebra em produção, e me conta o que deu errado.