Estamos construyendo sistemas de IA equivocados. Fundamentalmente, estructuralmente, catastróficamente equivocado. El patrón es siempre el mismo. Un equipo descubre la magia de un modelo de lenguaje grande. Lo envuelven en un script de Python. Le dan acceso a la base de datos, la puerta de acceso a la API y los registros de soporte al cliente. Desechan tres gigabytes de documentación en la ventana de contexto porque "1 millón de tokens" suena como almacenamiento infinito. Lo llaman “un agente”. En realidad, han construido un agente de Dios.Un monolítico, omnisciente, blob de lógica sin diferenciación que intenta ser el CEO, el janitor y el administrador de la base de datos simultáneamente. Y eso fracasó. Se alucina. Se confunde. Cuesta una fortuna en el uso de token. La latencia crece hasta que la experiencia del usuario se siente como esperando una conexión de llamada en 1999. Cuando se rompe (y siempre se rompe) los ingenieros no pueden deshacerlo porque la lógica no está en el código. Está en una neblina probabilística de ingeniería rápida y contaminación de contexto. He pasado el último año rompiendo estos sistemas.La solución no es una mejor prompt.No es un modelo más grande.La solución es la arquitectura. Análisis técnico completo con código y benchmarks → Análisis técnico completo con código y benchmarks → ¿Por qué estamos tratando 1 millón de tokens como Infinite RAM? La actual ortodoxia en el desarrollo de la IA es seducida por el "mito de la ventana de contexto". Se nos ha vendido una mentira. La mentira es que si damos un modelo suficiente contexto, puede resolver cualquier problema. Los vendedores empujan el "contexto infinito" como la característica final. 128k. 1 millón. 2 millones de tokens. La implicación es seductora. No te preocupes por la arquitectura. No te preocupes por la curación de datos. Simplemente descargue todo. El modelo lo descubrirá. Esto ha llevado al surgimiento del paradigma del agente de Dios. En esta visión del mundo, un "agente" es una entidad singular. Tiene el estado completo de la aplicación. Tiene acceso a todas las herramientas de la biblioteca. Cuando un usuario hace una pregunta, el agente de Dios recibe la consulta, mira su enorme contexto (que contiene toda la historia del universo), y intenta razonar su camino a una respuesta. Se siente como el progreso.Parece el sueño de ciencia ficción de una IA singular y consciente. Pero en la producción, esto es una pesadilla. Efectivamente, estamos pidiendo a un desarrollador junior que memorice toda la base de código, el manual de la empresa y los archivos legales, y luego le pedimos que corrija un bug de CSS en 30 segundos. No van a corregir el bug. Tendrán un ataque de pánico. ¿Por qué mi agente cuesta $50 para decir 'No sé'? Las grietas en la arquitectura del agente de Dios son visibles para cualquiera que empuje el código a la producción. Cuanto más información proporcione, menos atención presta el modelo a los bits críticos. Esto no es sólo una sensación. Es un defecto arquitectónico. La investigación muestra que los modelos tienen dificultades para recuperar información desde el medio de contextos largos. Al no curar, dañamos activamente el rendimiento. Creamos sistemas donde el "ruido" de la documentación irrelevante sobrepone el "sinal" de la intención específica del usuario. 1. Context Pollution (The Needle in the Haystack) Cada token cuesta dinero. Cada token toma tiempo para procesar. Un agente de Dios que lee de nuevo un contexto de token de 50k para cada turno de conversación está quemando dinero. Es computacionalmente desperdicioso. Estamos ejecutando un superordenador para responder "sí" o "no" porque no nos molestamos en filtrar las entradas. 2. Latency and Cost Cuando un agente de Dios falló, ¿por qué falló? ¿Fue el prompt? El paso de recuperación? La salida de la herramienta? O simplemente se distrajo por un pedazo de texto irrelevante de la página 405 de la documentación? ¿No se puede ensayar un prompt que cambie su comportamiento basado en la sopa variable de una enorme ventana de contexto. 3. The Debugging Black Hole Un único agente con acceso a todo es una pesadilla de seguridad. Si la inyección instantánea funciona, el atacante posee el castillo. No hay bulkheads. No hay "cero confianza" porque la arquitectura se basa en la confianza máxima en un modelo probabilístico. 4. The Governance Void ¿La solución es simplemente microservicios (de nuevo)? Y sí. es El camino hacia adelante es Y el . Aggressive Context Curation Agentic Mesh Debemos reemplazarlo por una red de agentes pequeños, especializados y altamente restringidos que comunican a través de protocolos estandarizados. En una arquitectura de redes, ningún agente sabe todo. El agente de router sabe cómo clasificar la intención. El agente de soporte conoce la política de devolución. El agente de codificación conoce Python. El agente SQL conoce el esquema de la base de datos. No comparten una ventana de contexto, comparten mensajes. Esta es la transición de un monolito a microservicios. Es la única manera de escalar la complejidad. Cuando el Agente de soporte está trabajando, no necesita conocer el esquema de la base de datos. No necesita las bibliotecas de Python. Su contexto es primitivo. Es curado. Veamos la diferencia en la estructura del código. La Vieja Vía: El Dios Pronto Esto es lo que la mayoría de la gente está escribiendo hoy en día. # GOD AGENT - ANTI-PATTERN # We dump everything into one system prompt. system_prompt = """ You are an omniscient AI assistant for Acme Corp. You have access to: 1. The User Database (Schema: users, orders, items...) 2. The Codebase (Python, React, TypeScript...) 3. The Company Handbook (HR policies, returns, holidays...) 4. The Marketing Style Guide Instructions: - If the user asks about SQL, write a query. - If the user asks for a refund, check the handbook policy then query the DB. - If the user asks for code, write Python. Current Context: {entire_rag_retrieval_dump} {last_50_messages} """ # Result: The model gets confused. # It tries to apply HR policies to SQL queries. # It hallucinates tables that don't exist. Python El nuevo camino: la red de agentes Aquí, dividimos la lógica. El router no hace el trabajo. # MESH ARCHITECTURE - PATTERN # Step 1: The Router Agent # Its only job is to classify and route. It has NO domain knowledge. router_prompt = """ You are a routing system. Analyze the user input and route to the correct agent. Available Agents: 1. billing_agent (Refunds, invoices, payments) 2. tech_support_agent (Python, SQL, Bug fixes) 3. general_chat_agent (Casual conversation) Output JSON only: {"target_agent": "name", "reasoning": "string"} """ # Step 2: The Specialist Agent (Billing) # This agent loads ONLY when called. # It has zero knowledge of Python or SQL. billing_agent_prompt = """ You are a Billing Specialist. You handle refunds and invoices. Tools available: [stripe_api, invoice_db] Context: {user_transaction_history_only} {refund_policy_summary} """ Python ¿Ves la diferencia? → No puede alucinar la sintaxis de SQL porque no sabe lo que es SQL. Su universo es pequeño. billing_agent ¿Cómo hablan los agentes sin halucinar? He sido escéptico acerca de los grandes marcos tecnológicos. generalmente añaden bloat. me gusta el código crudo. Pero el kit de desarrollo de agentes de Google (ADK) y el protocolo de agente a agente (A2A) son diferentes. Google se ha dado cuenta de que si queremos que los agentes trabajen, necesitan hablar entre sí como software, no como chatbots. El Protocolo A2A Este es el cambio de juego. El protocolo A2A es un estándar neutro del vendedor para que los agentes descubran y hablen entre sí. Utiliza "cartas de agentes". Estos son ficheros de metadatos JSON estandarizados que describen lo que un agente puede hacer. Piensa en esto así: { "agent_id": "billing_specialist_v1", "capabilities": ["process_refund", "check_invoice_status"], "input_schema": { "type": "object", "properties": { "transaction_id": {"type": "string"}, "user_intent": {"type": "string"} } }, "output_schema": { "type": "object", "properties": { "status": {"type": "string", "enum": ["success", "failed"]}, "refund_amount": {"type": "number"} } } } JSON Cuando un agente de router necesita procesar un reembolso, no intenta alucinar la llamada de la API. , agita las manos a través de A2A, pasa la carga útil estructurada y espera una respuesta estructurada. billing_specialist Esta es la estandarización. nos permite construir un donde agentes de diferentes equipos, o incluso diferentes empresas, pueden colaborar. Agentic Mesh En la actualidad, un agente de OpenAI no puede hablar con un agente de Vertex AI. Con A2A, comparten un protocolo. ¿Qué significa esto en realidad La adopción de una arquitectura de malla cambia todo sobre cómo construimos. No se pueden captar los registros de una red probabilística.La observabilidad tradicional (logs, métricas, rastros) es insuficiente. Necesitamos ver la ¿Por qué el Router se entregó al Agente de facturación? ¿Por qué el Agente de facturación rechazó la solicitud? Necesitamos rastrear el coste y la latencia por nodo en la red. Si no tienes esto, no estás construyendo un sistema. 1. Observability is Mandatory Agentic Observability Razonamiento en cadena En un modelo de agente de Dios, la seguridad es un interruptor binario. El agente de facturación no confía implícitamente en el agente del router. Verifica la carga útil. Verifica la política. Limita el radio de explosión. 2. Zero Trust Security Zero Trust La ingeniería instantánea como disciplina independiente está muriendo. El prompt es sólo una configuración de funciones.El trabajo real está en la lógica de enrutamiento, la definición de esquema y la estrategia de curado de contexto. 3. The End of "Prompt Engineering" System Engineering Debemos convertirnos en editores despiadados. El objetivo no es llenar la ventana de contexto. El objetivo es vacilarla. Necesitamos comprimirla. Necesitamos resumirla. Necesitamos inyectar sólo exactamente lo que es necesario para el siguiente paso inmediato. Si un agente está encargado de escribir SQL, necesita el esquema. need the company mission statement. 4. Aggressive Context Curation no (Suena obvio, pero lo veo ignorado en el 90% de las bases de código.) Leer la descomposición técnica completa → Leer la descomposición técnica completa → TL;DR para los Scrollers El fracaso de God Agents: la confusión de la ventana de contexto conduce a la confusión, los altos costos y la imposibilidad de deshabilitar. Separación de Preocupaciones: Construye agentes especializados (Billing, SQL, Chat) que hagan una cosa bien. Protocolos de uso: los agentes deben comunicarse a través de
