Showing Posts From

A2a

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.