Agentes horizontales vs. agentes verticales: cómo diseñar el loop engineering

TL;DR

• Los agentes horizontales abarcan más: un sistema de propósito general se encarga de redacción, investigación, enrutamiento y tareas entre equipos. Los agentes verticales profundizan: se enfocan en un flujo de trabajo de dominio (revisión legal, documentación clínica, controles de fraude) con restricciones de cumplimiento, esquema y sistema de registro incorporadas.
• Estas son decisiones de producto, no de modelo. El LLM suele ser la parte más pequeña de un agente vertical en producción; las políticas deterministas, los registros de auditoría y los adaptadores de dominio hacen el trabajo fundamental.
• El loop engineering se aplica a ambos, pero el loop que diseñas cambia de forma. Los loops horizontales optimizan el enrutamiento, la higiene del contexto y la amplitud segura. Los loops verticales optimizan la verificación contra reglas de dominio, los puntos de control humanos y la evidencia de auditoría reproducible.
• No confundas horizontal y vertical en producto con horizontal y vertical en integración. En términos de protocolos, MCP es la capa de integración vertical (agente → herramientas/datos) y A2A es la capa de coordinación horizontal (agente ↔ agente). Los sistemas maduros suelen necesitar ambas.
• La mayoría de las empresas terminan con un modelo híbrido: un coordinador horizontal (un router al estilo de Copilot, un orquestador interno o un harness de agentes de código) que delega el trabajo de alto impacto a especialistas verticales.
• Empieza por lo horizontal para abarcar tareas exploratorias de bajo riesgo. Pasa a lo vertical cuando el costo de fallar, la regulación o los datos propietarios del flujo de trabajo hagan que los modelos genéricos sean insuficientes. Diseña el loop antes de escalar cualquiera de los dos.
• Entrega especificaciones en cinco capas de plantillas (contrato del loop → integración → superficie de dominio → verificación → estado persistente). Los PMs empiezan por la Capa 1; los ingenieros agregan capas a medida que el flujo de trabajo demuestra que merece autonomía.

Qué aprenderás aquí

• Qué significan los agentes horizontales y verticales en las conversaciones de producto y arquitectura de 2026, y qué no significan.
• Cómo cambia el loop engineering (el ciclo percibir → planear → actuar → verificar) cuando optimizas para amplitud frente a profundidad de dominio.
• Una arquitectura híbrida de referencia: router horizontal, workers verticales, herramientas MCP y transferencias opcionales por A2A.
• Una matriz de decisión para PMs y una lista de verificación de diseño de loops para ingenieros.
• Capas de plantillas: cinco artefactos (contrato del loop → integración → superficie de dominio → verificación → estado persistente), con una ruta de «empezar por la Capa 1» para PMs.
• Hasta dónde llega este artículo y qué publicaciones relacionadas del devlog profundizan más.

Este artículo está dirigido a ingenieros y PMs que planean sistemas de agentes más allá de un solo prompt de chat. Si ya usas agentes de código a diario, piensa en esto como la capa por encima de la elección de herramientas: qué tipo de agente merece autonomía y qué loop hace que sea seguro.

Dos vocabularios, un solo stack

«Horizontal» y «vertical» aparecen en dos conversaciones distintas. Confundirlos lleva a malas revisiones de arquitectura.

Ambos son útiles. No son el mismo eje.

Las guías de arquitectura de fuentes primarias (Anthropic, Google A2A, Microsoft Copilot Studio) enfatizan enrutamiento/orquestación más especialistas —un loop híbrido—, no una elección obligada entre «Copilot en todas partes» y «un proveedor vertical por dominio».

                    PRODUCT VIEW
        ┌──────────────────────────────────────┐
        │  Horizontal agent (wide coordinator) │
        │    routes ──► vertical specialists   │
        └──────────────────────────────────────┘
                              │
                    INTEGRATION VIEW
        ┌─────────── A2A (agent ↔ agent) ───────────┐
        │                                              │
   Horizontal router                          Vertical worker
        │                                              │
        └──── MCP (agent → tools/SOR) ────────────────┘
                              │
                     EHR / CRM / Git / ledger

Equivalencia para equipos de desarrollo: Claude Code o Cursor como harness horizontal; un subagente o skill específico de dominio (pagos, infraestructura, cumplimiento) como componente vertical, con CI o evals de escenarios como capa de verificación vertical. El ejemplo de RR. HH. a continuación usa el mismo patrón en un contexto de operaciones empresariales.

Agentes horizontales: optimiza la amplitud y el enrutamiento

Un agente horizontal es de propósito general por diseño. Algunos ejemplos reales son Microsoft Copilot, Google Gemini for Workspace, Claude Code como harness general de código o un «copilot de la empresa» interno conectado a Slack, documentos y sistemas de tickets.

Los agentes horizontales destacan cuando:

• las categorías de tareas varían de una semana a otra (investigación, borradores, resúmenes, automatización ligera)
• la exposición regulatoria es moderada y la revisión humana es aceptable
• las integraciones son principalmente con SaaS estándar (correo electrónico, calendario, GitHub, Notion)
• el tiempo hasta obtener valor importa más que la precisión perfecta de dominio desde el primer día

Las guías de Anthropic para producción consideran el enrutamiento y los patrones de orquestador-workers como patrones fundamentales: clasificar la entrada, delegar al prompt especialista o subagente adecuado y sintetizar el resultado. Eso es arquitectura horizontal en la práctica, incluso cuando los «workers» son solo instancias del mismo modelo con prompts distintos.

Qué debe resolver bien un loop horizontal

El loop engineering para agentes horizontales consiste principalmente en no contaminar tu propio router:

Anthropic describe el ciclo central de un solo agente así: recibir la tarea → planear → actuar con herramientas → observar → repetir hasta terminar o pausar para revisión humana. Los sistemas horizontales agregan una capa de supervisión encima cuando la clasificación es lo suficientemente confiable.

Agentes verticales: optimiza la profundidad, las políticas y la evidencia

Un agente vertical se hace cargo de un flujo de trabajo acotado dentro de un dominio regulado o de alto impacto: autorización previa, redacción de notas clínicas, extracción de cláusulas contractuales, verificación de ingresos para hipotecas o resolución de casos de fraude.

Los agentes verticales en producción convergen en una anatomía similar, independientemente de si el proveedor vende al sector de salud, legal o financiero (las descripciones varían; los componentes se repiten):

1. Router / orquestador dentro del flujo de trabajo del dominio
2. Modelos o prompts especialistas con supervisores
3. Capa de políticas deterministas que conserva la autoridad sobre la decisión final
4. Adaptador de esquema de dominio hacia el sistema de registro
5. Almacén de estado de larga duración (expedientes de casos, no historial de chat)
6. Router de puntos de control humanos
7. Registro de auditoría reproducible para reguladores

La lección recurrente de los despliegues regulados (resumida en análisis de la industria que citan a proveedores como Abridge, Anterior, Sierra y Harvey) es: el LLM no es el sistema. El harness lo es.

Qué debe resolver bien un loop vertical

El loop engineering vertical sacrifica flexibilidad a cambio de capacidad de demostrar el cumplimiento:

Un framework de arXiv (May 2026) separa la función cognitiva (razonamiento, acción, gobernanza) de la topología de ejecución (cadena, ruta, loop, jerarquía). Los sistemas verticales en producción suelen combinar Route (clasificación inicial) + Loop (borrador/revisión iterativos) + Hierarchy (especialistas supervisores), con Governance implementada fuera del modelo.

Loop engineering: mismo nombre, distinto énfasis

El loop engineering es la práctica de diseñar el entorno de ejecución alrededor de un agente —la programación, las herramientas, la memoria, la verificación y las reglas de parada—, en lugar de escribir a mano cada turno. Addy Osmani dio nombre a la práctica en June 2026, a partir de la idea de Boris Cherny de que «mi trabajo es escribir loops» y de la convergencia de harnesses al estilo de Claude Code / Codex.

Los seis elementos básicos de Osmani se aplican claramente a ambos tipos de agentes:

Para loops de agentes de código específicamente, consulta Cómo crear un agente de nivel ingeniero sénior: ese artículo profundiza en la orquestación, la separación entre creador y revisor, y la confianza en los PRs automáticos. Este artículo se mantiene en la capa de producto/arquitectura: elegir entre horizontal y vertical antes de ajustar el harness.

Loop horizontal (forma de referencia)

 Trigger (schedule, webhook, user)
        │
        ▼
 ┌──────────────┐     classify      ┌─────────────────┐
 │  Horizontal  │ ────────────────► │ Route to worker │
 │  supervisor  │                   │ prompt/subagent │
 └──────┬───────┘                   └────────┬────────┘
        │                                    │
        │         MCP tools (Git, docs, CI)  │
        ▼                                    ▼
 ┌──────────────┐   verify (tests/lint)   ┌──────────────┐
 │ Act + observe│ ◄────────────────────── │ Loop until   │
 └──────┬───────┘                         │ stop rule    │
        │                                 └──────────────┘
        ▼
  Summarize to user / open PR / post Slack

Loop vertical (forma de referencia)

 Case opened in system of record
        │
        ▼
 ┌──────────────┐   deterministic    ┌──────────────┐
 │ Intake +     │ ────────────────► │ Policy gate  │
 │ schema bind  │   eligibility     │ (allow/deny) │
 └──────┬───────┘                   └──────┬───────┘
        │                                  │
        ▼                                  ▼
 ┌──────────────┐   draft/revise     ┌──────────────┐
 │ Vertical LLM │ ◄───────────────── │ Domain eval  │
 │   loop       │   until pass       │ + human HITL │
 └──────┬───────┘                   └──────────────┘
        │
        ▼
 Writeback + immutable audit event (who/what/when/evidence)

El loop vertical es más lento por diseño. Eso es una ventaja cuando una automatización incorrecta sale cara.

Arquitectura híbrida: cómo entregan sistemas los equipos maduros

Las guías empresariales de Microsoft Copilot Studio, Google A2A y los patrones multiagente de Anthropic convergen en un modelo por capas:

1. Punto de entrada horizontal — chat de usuario, copilot u orquestador interno
2. Router / supervisor — clasifica la intención y el riesgo
3. Workers verticales — agentes de dominio con sus propios loops y capas de políticas
4. MCP — cada worker accede a herramientas y sistemas de registro
5. A2A (opcional) — agentes de distintos equipos o proveedores delegan sin compartir sus detalles internos

El protocolo A2A de Google (anunciado el April 9, 2025 y donado a la Linux Foundation) existe precisamente para esta capa de coordinación horizontal: Agent Cards en /.well-known/agent-card.json, JSON-RPC sobre HTTPS y modelos de tareas y artefactos para trabajos de larga duración. A2A complementa explícitamente a MCP: MCP proporciona herramientas a un agente; A2A permite que agentes opacos colaboren.

 Employee / customer
        │
        ▼
 ┌─────────────────────┐
 │ Horizontal copilot  │  Loop: route + summarize + guard
 └──────────┬──────────┘
            │ A2A task: "process LOA case"
            ▼
 ┌─────────────────────┐        MCP         ┌─────────────┐
 │ Vertical LOA        │ ─────────────────► │ Workday /   │
 │ case worker         │                    │ policy DB   │
 └──────────┬──────────┘                    └─────────────┘
            │ A2A result artifact
            ▼
 Horizontal copilot explains outcome + links audit ID

Para PMs: No estás eligiendo entre Copilot o Harvey. Estás eligiendo dónde vive el punto de entrada y qué flujos de trabajo merecen un entorno de ejecución vertical.

Para ingenieros: Mantén los agentes verticales opacos para el router horizontal (el punto fuerte de A2A). No filtres PHI ni prompts privilegiados a través del contexto compartido del chat.

Marco de decisión

Ruta rápida para PMs: ¿con qué tipo empezar?

 Can you name the eval, human checkpoint, and audit artifact upfront?
        │
        no ──► start horizontal (suggest-only, low write access)
        │
       yes
        │
        ▼
 Is failure cost high (legal, clinical, financial, safety)?
        │
        no ──► horizontal + strong verification may be enough
        │
       yes
        │
        ▼
 Do you need system-of-record writeback or regulated replay?
        │
        no ──► horizontal with gated tools + human approval
        │
       yes ──► vertical worker (buy or build) + Layer 1 loop contract

Si el flujo de trabajo todavía es exploratorio, mantente en lo horizontal incluso cuando el dominio suene «serio». La inversión vertical rinde frutos cuando se repiten los mismos tipos de casos y puedes probarlos con escenarios. Consulta Cuándo basta un prompt para agentes de IA antes de agregar complejidad al loop.

Para PMs: ¿con qué tipo empezar?

Opción práctica por defecto en 2026: despliega agentes horizontales para las interfaces de productividad; agrega agentes verticales solo para flujos de trabajo en los que puedas definir de antemano el eval, el punto de control humano y el artefacto de auditoría. Los pronósticos de analistas (Gartner y otros, early 2026) apuntan a un rápido crecimiento de agentes integrados y específicos para tareas dentro de aplicaciones empresariales, principalmente como componentes verticales, no como chat genérico en todas partes.

Para ingenieros: lista de verificación del loop antes de producción

Preparación del loop horizontal

• Precisión del router medida en un conjunto etiquetado (precision/recall por ruta)
• Máximo de iteraciones, presupuesto de tokens y tiempo límite real configurados
• Permisos de herramientas con privilegio mínimo por ruta
• Resúmenes de subagentes limitados (evitar que crezca demasiado el contexto del agente padre)
• Hook de verificación para cada ruta que modifica el estado
• Interruptor de emergencia y límite de gasto (organización de sandbox, alarma de presupuesto)

Preparación del loop vertical

• El motor de políticas puede vetar acciones del modelo antes de escribir cambios
• Estado del caso almacenado fuera del modelo con historial de versiones
• Suite de evals de dominio (tests de escenarios, no un solo caso ideal)
• Punto de control humano definido para las rutas de escalamiento
• Registro de auditoría inmutable (hash del prompt, llamadas a herramientas, resultados, responsable de aprobación)
• Procedimiento de reproducción documentado para reguladores o revisión interna

Si no puedes marcar los puntos de la lista vertical, probablemente tienes un loop de demostración, no uno de producción.

Capas de plantillas: cinco artefactos, un loop híbrido

Los ejemplos siguientes no son un único archivo de framework. Son cinco capas que puedes adoptar de forma independiente, usando en todas el mismo escenario de beneficios para empleados: un copilot horizontal enruta preguntas frecuentes y delega solicitudes de licencia laboral (LOA) a un agente vertical de gestión de casos.

 Layer 1  Loop contract (PM)     ──► what routes exist, what "done" means
 Layer 2  Integration spec       ──► how workers are invoked (brief or A2A)
 Layer 3  Domain surface         ──► what tools/data each worker may touch
 Layer 4  Verification           ──► how you prove the loop worked
 Layer 5  Durable state          ──► what survives between loop runs

PMs: empiecen por la Capa 1. No necesitan YAML, Agent Cards ni archivos de evals desde el primer día. Completen la tabla del contrato del loop en un documento o ticket, obtengan la aprobación de ingeniería sobre las reglas de parada y los controles humanos, y luego agreguen las capas 2–5 a medida que el flujo de trabajo demuestre que merece autonomía. Si la Capa 1 es vaga («atender preguntas de RR. HH.»), todas las capas inferiores se desviarán.

Escalera de madurez:

Capa 1 — Contrato del loop (resumen de una página para PMs)

Usa una tabla de Markdown —o los campos equivalentes en Jira/Linear— antes de que alguien escriba la configuración del agente. Esta es la especificación que acuerdan los responsables horizontal y vertical.

La Capa 1 está lista cuando: ambas rutas tienen responsables definidos, condiciones de parada binarias y una ruta explícita «sin automatización».

Capa 2 — Especificación de integración (ingeniería)

La Capa 2 responde cómo el supervisor horizontal invoca a los workers. Elige uno o ambos patrones según la forma del despliegue.

2a. Brief de subagente en el mismo proceso (mismo harness: Claude Code, Cursor, orquestador interno):

Usa el brief de seis campos de Cómo crear un agente de nivel ingeniero sénior. El supervisor horizontal lo emite cuando enruta al worker vertical de LOA:

ROLE: LOA case worker. Evaluate eligibility, draft case, escalate borderline outcomes.
       You do not answer general HR policy questions.

CONTEXT:
- Policy bundle: opa_bundle_hr_loa v2026.06
- Employee record: read via workday_hr_readonly MCP
- Case writeback: workday_case_write MCP (LOA objects only)

GOAL: Produce a policy-checked LOA draft or escalate with evidence.

NON-GOALS:
- Do not modify payroll, termination, or benefits enrollment directly.
- Do not bypass human_required when policy_result is borderline.
- If eligibility is unclear, stop and queue hr_specialist_review.

TOOLS: workday_hr_readonly, workday_case_write (scoped), policy_check_loa.
        No Slack, no generic web search.

DONE-WHEN:
- policy_result is pass AND draft case written, OR
- policy_result is borderline/fail AND human_required queued with audit event.

Para la ruta de FAQ de bajo riesgo, el mismo harness usa un brief más corto:

ROLE: HR handbook assistant. Answer general policy questions with citations only.

GOAL: Answer from handbook/FAQ sources, or escalate if the question needs employee-specific data.

NON-GOALS: Do not open LOA cases. Do not read employee records.

TOOLS: notion_handbook, slack_hr_faq (read-only).

DONE-WHEN: Answer includes ≥1 citation OR escalate_to_loa_route with reason.

2b. A2A Agent Card (worker vertical como servicio independiente):

Cuando el agente de LOA se ejecuta fuera del entorno de ejecución del copilot, exponlo mediante A2A. El copilot horizontal se convierte en un cliente A2A; el agente vertical publica sus capacidades en /.well-known/agent-card.json:

{
  "name": "loa-case-worker",
  "description": "Processes leave-of-absence requests with policy checks, human escalation, and audit trail.",
  "url": "https://hr-agents.example.com/a2a/v1",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "process_loa_request",
      "name": "Process LOA request",
      "description": "Evaluate eligibility, draft case, escalate borderline cases to HR.",
      "examples": [
        "Employee requests 6-week medical leave starting July 1",
        "Check FMLA eligibility for employee ID E-1042"
      ]
    }
  ]
}

Regla práctica: briefs de subagentes para equipos que trabajan en un solo repositorio; Agent Cards cuando los agentes verticales son opacos, están alojados por un proveedor o pertenecen a otro equipo.

Capa 3 — Superficie de dominio (límite vertical)

Antes de conectar servidores MCP, define a qué puede acceder cada worker. Este YAML es un contrato de seguridad y producto, no configuración de orquestación; es similar al patrón de capa semántica de Cómo preparar bases de datos para agentes de IA seguros:

# domain-surface-loa.yaml — vertical worker boundary
domain: leave_of_absence
worker: vertical_loa_agent

allowed_actions:
  - check_eligibility
  - create_draft_case
  - append_case_note
  - request_human_review

blocked_actions:
  - terminate_employee
  - modify_payroll
  - change_benefits_enrollment
  - cross_employee_queries

mcp_servers:
  - name: workday_hr_readonly
    scopes: [hr.employee.read, hr.loa.read]
  - name: workday_case_write
    scopes: [hr.loa.draft]  # not hr.loa.submit until human approves

approval_required:
  - submit_case_to_workday
  - writeback_final_decision

audit_fields:
  - case_id
  - policy_version
  - inputs_hash
  - tool_calls
  - decision
  - approver

El worker horizontal de FAQ recibe una superficie más ligera: MCP de solo lectura para el manual, sin herramientas de escritura ni objetos de casos.

# domain-surface-faq.yaml — horizontal route boundary
domain: hr_faq
worker: hr_faq_worker

allowed_actions:
  - search_handbook
  - cite_source
  - escalate_to_loa_route

blocked_actions:
  - read_employee_record
  - create_case
  - any_write_to_workday

mcp_servers:
  - name: notion_handbook
    scopes: [hr.docs.read]
  - name: slack_hr_faq
    scopes: [hr.faq.read]

Capa 4 — Verificación (ganarse la autonomía)

Los loops horizontales y verticales necesitan pruebas distintas. En la Capa 4, la «demostración» se convierte en «producción».

Horizontal (FAQ): comprobaciones de esquema y citas: económicas, se ejecutan en cada turno.

# verify-faq.yaml
route: hr_faq_worker
checks:
  - type: json_schema
    schema: hr_response_v2.json
  - type: citation_required
    sources: [notion_handbook, slack_hr_faq]
  - type: refusal
    when: question_requires_case_specific_data
    action: escalate_to_loa_route

Vertical (LOA): evals de escenarios antes del despliegue; consulta Cómo probar skills de agentes de IA con LangWatch Scenario para ver el flujo completo.

# scenarios-loa.yaml
scenarios:
  - name: eligible_medical_loa
    input: { tenure_months: 14, reason: medical, duration_weeks: 6 }
    expect: { policy_result: pass, human_required: false }

  - name: borderline_tenure
    input: { tenure_months: 11, reason: medical, duration_weeks: 12 }
    expect: { policy_result: borderline, human_required: true }

  - name: ineligible_short_tenure
    input: { tenure_months: 2, reason: personal, duration_weeks: 4 }
    expect: { policy_result: fail, human_required: false }

Ejecuta las suites de escenarios con cada cambio en el paquete de políticas. Las rutas horizontales pueden apoyarse en comprobaciones puntuales; las rutas verticales no deberían desplegarse sin cobertura de evals en las rutas de escalamiento.

Capa 5 — Estado persistente (memoria fuera del modelo)

Los modelos olvidan entre ejecuciones. En particular, el trabajo sobre casos verticales no debe existir solo en el historial del chat. Persiste el estado para que la siguiente iteración del loop (o el revisor humano) pueda recuperarlo:

{
  "case_id": "loa-2026-0142",
  "route": "vertical_loa_agent",
  "status": "awaiting_human_review",
  "attempts": 2,
  "policy_version": "opa_bundle_hr_loa@2026.06",
  "policy_result": "borderline",
  "open_questions": [
    "FMLA overlap with existing PTO balance"
  ],
  "last_tool_calls": ["check_eligibility", "create_draft_case"],
  "human_queue": "hr_specialist_review",
  "last_verified_at": "2026-06-25T14:30:00Z"
}

Los turnos horizontales de FAQ pueden seguir siendo efímeros. Una vez que un usuario pasa a LOA, promueve la conversación a estado de caso (Capa 5) y transfiérela al loop vertical.

Cómo se conectan las capas

 User: "I need 6 weeks medical leave"
        │
        ▼
 [Layer 1] Router picks LOA route (not FAQ)
        │
        ▼
 [Layer 2] Supervisor delegates via subagent brief OR A2A task
        │
        ▼
 [Layer 3] LOA worker sees only allowed_actions + scoped MCP
        │
        ▼
 [Layer 4] policy_check → scenario eval on CI; borderline → human gate
        │
        ▼
 [Layer 5] case JSON persisted; loop pauses until HR approves writeback
        │
        ▼
 Horizontal copilot summarizes outcome + audit ID for the employee

Decisiones de diseño que este stack hace explícitas:

• La capa horizontal se encarga del enrutamiento, el resumen para el usuario y las rutas de FAQ de bajo costo.
• La capa vertical se encarga de la superficie de dominio, las políticas, el escalamiento humano, la auditoría y el estado persistente del caso.
• La verificación varía según la ruta: no reutilices un mismo harness de pruebas para ambas.
• Los PMs aprueban la Capa 1; los ingenieros implementan 2–5 de forma incremental a medida que aumenta la confianza.

Para la delegación dentro de un solo harness de código, consulta también Cuándo usar subagentes en lugar del hilo principal de chat.

Riesgos y límites reales

• Los agentes horizontales exceden su alcance. Incluso un router capaz alucina etiquetas de clasificación. Mide la precisión del enrutamiento antes de automatizar acciones de escritura.
• Los agentes verticales se vuelven rígidos con el tiempo. Los adaptadores de dominio y los paquetes de políticas son costosos. Comprar SaaS vertical o construirlo es una decisión de portafolio, no una prueba de pureza.
• Sopa de protocolos. MCP más A2A más la orquestación nativa del proveedor pueden duplicar la gobernanza si no tienes un plano de control. La guía de IBM sobre la proliferación de agentes (2026) señala que la mayoría de las grandes empresas ya ejecutan agentes de alguna forma, pero muchas carecen de un inventario completo. La proliferación aumenta el riesgo de seguridad e integración cuando los equipos despliegan más rápido de lo que pueden gobernar.
• Expresividad del loop frente a control. Las investigaciones sobre ejecución de agentes (April–May 2026) señalan que los loops de agentes sin restricciones ocultan dependencias y reintentan indefinidamente; los enfoques de harness basados en grafos sacrifican flexibilidad a cambio de facilidad de inspección. Los flujos verticales de alto impacto suelen beneficiarse de una estructura más explícita que la de un solo loop opaco.
• Crecimiento prematuro de las capas de plantillas. Agregar las Capas 2–5 antes de que la Capa 1 sea estable produce YAML atractivo y comportamiento inestable en producción. Mantén las rutas de FAQ en las Capas 1–2 hasta medir la precisión del enrutamiento.
• La convergencia es real, pero desigual. Las plataformas horizontales agregan módulos para industrias específicas (Copilot for Finance, funciones de salud de Gemini). Eso puede retrasar el gasto en proveedores verticales, pero rara vez elimina la necesidad de datos propietarios para evals en tu entorno.

Notas editoriales y sobre las fuentes

Este artículo evita deliberadamente afirmaciones sobre ingresos de proveedores (ARR, múltiplos de valoración), salvo que estén vinculadas a evidencia arquitectónica. Se omiten cifras de mercado de blogs secundarios cuando no cambian las decisiones de diseño.

Diferencias frente a otras publicaciones del devlog en este repositorio:

• Agente de nivel ingeniero sénior — orquestación de código y confianza en PRs automáticos
• Subagentes vs. hilo principal — delegación dentro de un mismo harness
• Cuándo basta un prompt — cuándo es prematura la complejidad del loop
• Cómo preparar bases de datos para agentes de IA seguros — superficie de dominio y profundidad de autorización de herramientas
• Cómo probar skills de agentes de IA con LangWatch Scenario — evals de escenarios de la Capa 4 en la práctica
• Cómo liderar sistemas agénticos de sandbox → beta — controles para avanzar de etapa en producto

Fuentes

Fuentes primarias y secundarias sólidas que respaldan las afirmaciones principales:

• Anthropic: Cómo crear agentes efectivos — enrutamiento, orquestador-workers, cuándo agregar complejidad agéntica; loop de percibir-actuar de un solo agente con condiciones de parada.
• Anthropic: Cómo crear agentes de IA efectivos (PDF) — patrones de supervisión jerárquica, enfoque vertical en servicios financieros, economía multiagente.
• Anthropic: Cómo crear agentes con Claude Agent SDK — loop recopilar contexto → actuar → verificar; subagentes para paralelización y aislamiento de contexto.
• Protocolo A2A de Google — interoperabilidad entre agentes; función complementaria frente a MCP; gestión por parte de la Linux Foundation.
• Repositorio de A2A en GitHub — Agent Cards, transporte JSON-RPC, modelo de tareas; aportado originalmente por Google.
• Google for Developers: Anuncio del protocolo Agent2Agent (A2A) — contexto del lanzamiento del April 9, 2025.
• Microsoft Learn: Patrones multiagente para Copilot Studio — MCP para herramientas, A2A para mensajería entre agentes de distintas plataformas; orquestación frente a detalles internos opacos de los agentes.
• Model Context Protocol — estándar de integración entre agentes y herramientas.
• Addy Osmani: Loop Engineering — denominación de loop engineering en June 2026; automatizaciones, worktrees, skills, conectores, subagentes, estado persistente.
• Un framework bidimensional para patrones de diseño de agentes de IA (arXiv, May 2026) — función cognitiva × topología de ejecución (cadena, ruta, loop, jerarquía).
• De loops de agentes a grafos estructurados (arXiv, April 2026) — límites de los loops opacos de agentes; compromisos de control.
• La anatomía de un agente vertical en producción (The AI Runtime, 2026) — patrón vertical regulado de siete componentes; el LLM como la parte más pequeña (análisis de la industria que cita a proveedores con sistemas en producción).
• IBM: ¿Qué es la proliferación de agentes de IA? — brechas de gobernanza, desafíos de inventario y riesgo de proliferación a medida que se democratiza el despliegue de agentes.

Criterio, no afirmación de un proveedor: La opción híbrida por defecto de «punto de entrada horizontal + workers verticales» refleja la convergencia de las guías sobre patrones de enrutamiento de Anthropic, la documentación de arquitectura multiagente de Microsoft y la complementariedad de A2A/MCP. Es una recomendación de diseño para lectores que planean despliegues en 2026, no una afirmación de que todas las empresas ya la hayan implementado.