Tutoriales, comparativas y patrones de diseño para construir agentes autónomos que se autofinancian, llaman a 345+ modelos y orquestan MCP Tools.
Un operador que puede responder 'qué hizo mi agente el martes a las 14:23 y fue correcto' tiene un negocio. Un operador que no puede va a perder su primer cliente pagante y va a pasar la segunda semana del mes averiguando por qué. Este post es la receta práctica de evaluación y observabilidad que todavía no escribimos — las cuatro categorías de métricas (correctitud, costo, latencia, drift), la suite de eval chica y rápida que cada operador debería lanzar antes de su primer usuario pagante, el stack de observabilidad de producción que hace al drift detectable, la disciplina de versionado de prompts que vuelve la regresión del martes el rollback del miércoles, y el patrón de canary deployment que captura los problemas antes de que alcancen toda la flota. Cerramos con cómo Agent Builder lanza defaults sensatos para cada capa de este stack y qué le queda al operador hacer por sí mismo.
La mayoría de los escritos públicos sobre sistemas de agentes asumen un único agente autónomo. La mayoría de los despliegues en producción más allá del primer mes no se ven así — se ven como flotas de agentes cooperando con distintas especializaciones, distintos tiers de modelo, distintos radios de explosión, y un operador real coordinándolos a través de un dashboard. Este post cataloga los cuatro patrones de orquestación que vemos sobrevivir el contacto con producción: supervisor-worker (un planificador, muchos workers paralelos), peer-to-peer mesh (los agentes se descubren entre sí vía A2A y negocian el trabajo), jerárquico en árbol (supervisor-worker recursivo para tareas demasiado grandes para un solo nivel), y swarm (muchos agentes homogéneos con balanceo de carga estocástico). Para cada uno cubrimos el caso de uso al que se ajusta, la matemática de costos y latencia, los modos de falla, y cómo Agent Builder lo implementa. Cerramos con los tres anti-patrones que vimos romper más flotas — mesh completo, liderazgo en anillo, agregación ciega — y un árbol de decisión que lleva al operador desde 'tengo un agente' hasta 'tengo la forma correcta para treinta'.
Un agente autónomo es una pieza de software con una tarjeta de crédito, una agenda, un inbox, y la confianza de su principal. Cada una de esas affordances es una superficie de ataque. Este post es el documento de threat-model que shippeamos internamente y que cualquier operador de agentes debería estar leyendo antes de ir a producción: los ocho vectores de ataque vivos (prompt injection directa, injection indirecta vía output de tool, tool poisoning, rug pulls de supply-chain en servers MCP, agent hijacking, agentes de phishing polimórficos, malware con timing de facturas, granjas de identidades sintéticas), los cuatro ataques sofisticados que entran en línea en los próximos dieciocho meses (social engineering de largo plazo apuntando al agente, sleeper agents con payload diferido, lavado de reputación cross-agente, forja de mandates AP2), la respuesta honesta sobre si los agentes están listos para algo de eso (no, mayormente), la economía criminal que va a deployar esta superficie de ataque en volumen (fraud-as-a-service, romance scams a escala, dust laundering, KYC falso a velocidad industrial), y las defensas prácticas que un operador puede implementar hoy. Este es el documento que nos hubiera gustado que alguien nos pasara antes de deployar nuestro primer agente que tocó plata real.
El EU AI Act entró en vigor el 1 de agosto de 2024 con la mayoría de sus disposiciones implementándose por fases. La fase que más le importa a cualquier operador corriendo agentes — los sistemas high-risk del Annex III — empieza a aplicarse el 2 de agosto de 2026. Este post es la versión de la ley que nos hubiera gustado que alguien escribiera para nosotros cuando leímos el texto por primera vez: explica quién está in scope (cualquiera cuyo agente alcance usuarios UE, incluso si el operador está en Argentina o California), qué cuenta como high-risk (reclutamiento, educación, scoring crediticio, ID biométrico, servicios públicos esenciales, screening laboral, soporte a fuerzas del orden, infraestructura crítica), los cuatro tiers de riesgo explicados sin legalismos, las siete obligaciones concretas adjuntas a los sistemas high-risk (gestión de riesgo, gobernanza de datos, documentación técnica, logging automático, transparencia, supervisión humana, exactitud/robustez/ciberseguridad), cómo las reglas de transparencia del Artículo 50 aplican a cualquier agente que interactúa con una persona o genera contenido, la estructura de penalties, y un checklist de operador de una página mapeando cada obligación a un artefacto concreto que necesitás producir. Cerramos con cómo Agent Builder de LLM4Agents mapea cada obligación por defecto, de modo que el operador corriendo una flota a través de Agent Builder ya está tres cuartos compliant el día uno.
MCP — Model Context Protocol — es el estándar abierto que le permite a cualquier aplicación LLM conectarse a cualquier herramienta o fuente de datos a través del mismo contrato JSON-RPC, de la misma forma que USB-C le permite a cualquier periférico conectarse a cualquier host. Anthropic lo open-sourceó en noviembre de 2024; a mitad de 2026 toda plataforma LLM principal lo habla nativamente y el registry oficial lista cientos de servidores en producción. Este post es el walkthrough técnico exhaustivo que les debemos a los futuros operadores de agentes: la arquitectura host-client-server, las tres primitivas del lado servidor (Tools, Resources, Prompts) y las tres del lado cliente (Sampling, Roots, Elicitation), los transports stdio y Streamable HTTP, el stack de autorización OAuth 2.1, el handshake de lifecycle, el modelo de seguridad con gates de consentimiento y tool safety, la spec actual 2025-11-25, el release candidate que viene 2026-07-28 (núcleo stateless, MCP Apps con UIs HTML sandboxeadas, Tasks como extensión formal, seis propuestas de endurecimiento OAuth, política formal de deprecación), y las preocupaciones prácticas del operador que la spec no resuelve por vos: gestión de secretos, minimización de scope, observabilidad, audit, y cómo reconocer un servidor al que no deberías conectarte. Cerramos con cómo Agent Builder convierte a MCP de un protocolo que implementás a una superficie de control que configurás.
AP2 — Agent Payments Protocol — fue anunciado por Google el 16 de septiembre de 2025 con 60+ partners (Mastercard, American Express, PayPal, Coinbase, Adyen, Worldpay, Salesforce, ServiceNow, MetaMask, Ethereum Foundation entre ellos), shippeó v0.2 el 28 de abril de 2026 con Human Not Present y Verifiable Intent, y fue donado a la FIDO Alliance para gobernanza comunitaria. Resuelve los tres problemas que los rails de pago clásicos no resuelven cuando el comprador es un agente autónomo: autorización (¿el usuario realmente aprobó esta compra?), autenticidad (¿la solicitud del agente coincide con la intención verdadera del usuario?), y accountability (¿quién es responsable si algo sale mal?). El mecanismo es una cadena de credenciales verificables estilo W3C llamadas Mandates — Intent, Cart, Payment — firmadas por el usuario o el agente según el flujo. Recorremos cada pieza de la spec con ejemplos concretos, mostramos cómo AP2 compone con A2A, MCP y x402, y cerramos con el plan de ingeniería para integrar AP2 en Agent Builder de modo que cualquier agente generado en LLM4Agents pueda transaccionar sobre las redes de pago más grandes del planeta con no-repudio criptográfico incorporado.
La ola de despidos de 2026 no es un accidente del ciclo de negocios. Es el programa involuntario de reciclaje profesional más grande de la historia laboral moderna, y los trabajadores que pagan su costo son los menos equipados — por su empleador o por la red de seguridad social — para gastar un año en un bootcamp. Este es el post que queríamos escribir para ellos: dejá de aplicar a puestos que la IA está vaciando tan rápido como vos podés aplicar; dejá de competir contra un ejército de agentes por costo; empezá a comandar tu propio ejército. Recorremos los cuatro shifts económicos que vuelven esto realista a mitad de 2026 (inferencia barata, protocolos maduros, builders de agentes sin prompt, rails de pago agéntico), los cuatro roles que los trabajadores desplazados deberían considerar realmente (supervisor de agentes, creador de agentes, operador de servicio de nicho, operador-inversor multi-agente), y los fundamentos técnicos que separan a los operadores que lo hacen funcionar de los que se queman en tres semanas: la pericia de dominio va primero, después el oficio de prompting y evaluación, después la operación y observabilidad. Agent Builder es el lugar más barato que conocemos para testear la tesis sobre vos mismo.
A2A — Agent-to-Agent — es el protocolo que Google anunció en abril de 2025, donó a la Linux Foundation en junio de 2025, y shippeó como v1.0 a principios de 2026 con 150+ organizaciones soportándolo. Donde MCP estandariza cómo un agente habla con sus herramientas, A2A estandariza cómo un agente habla con otro agente. La spec le da al campo su primer vocabulario completo para interacción autónoma: Agent Cards publicadas en /.well-known/agent-card.json para descubrimiento, JSON-RPC 2.0 sobre HTTPS con once métodos canónicos, un lifecycle de tasks de ocho estados con estados terminales e interrumpibles, mensajes multi-parte, streaming vía SSE, push notifications asíncronas vía webhooks, y cinco esquemas de auth grado-empresa. Recorremos cada pieza de la spec con ejemplos concretos, explicamos por qué esta era la capa faltante y no MCP, mostramos cómo LLM4Agents cablea endpoints A2A en Agent Gen, registration files ERC-8004, y el rail de pago x402, y cerramos con cuatro mejoras concretas que A2A necesita: métodos payment-aware, primitivas de negociación, alineación semántica, y binding de identidad vía estándares como ERC-8004.