El ciclo de creación iterativa: Cómo construir mejor con Plan Mode, diálogos multiagente y verificación

Una guía de campo práctica para 2026 sobre codificación, investigación, contenido, productos, sistemas de conocimiento y flujos de trabajo nativos de IA

Hay un punto en el que añadir más inteligencia a un flujo de trabajo de IA deja de ser útil.

No porque el modelo sea débil.

Sino porque el flujo de trabajo es débil.

Puedes darle a un agente una ventana de contexto enorme, una docena de herramientas, una instrucción larga y un prompt cuidadosamente diseñado. Aún así puede malinterpretar el objetivo, confiar demasiado en una suposición, duplicar la investigación, cambiar algo que debía permanecer intacto o declarar éxito antes de que alguien haya verificado el resultado.

La respuesta instintiva suele ser:

Añadir otro agente.

Luego otro.

Luego un revisor.

Luego un “arquitecto senior”.

Luego un editor final.

Eventualmente has construido una pequeña empresa artificial que pasa más tiempo coordinando que realizando el trabajo.

Ese no es el objetivo.

La idea más útil es más simple:

No optimices por la cantidad de agentes. Optimiza por la calidad de las transiciones de estado entre intención, evidencia, acción y finalización verificada.

Esta guía llama a ese sistema el Iterative Creation Loop.

OBSERVE → CONTRACT → PLAN → CHALLENGE → SPECIALIZE
        → REFINE → APPROVE → EXECUTE → VERIFY → LEARN ↺

Los agentes son opcionales.

El bucle no lo es.

Para algunas tareas, un agente fuerte debería ejecutar la mayor parte del bucle. Para otras, investigadores independientes, críticos, especialistas y verificadores merecen sus propios contextos. La arquitectura debe seguir la forma del trabajo.

El resultado no es un “enjambre”. Es algo más útil: un proceso repetible para convertir trabajo incierto en trabajo verificado.

TL;DR

El cambio útil es de generación de respuestas a progresión de artefactos.

En lugar de:

Human → Prompt → Model → Answer

utiliza:

Goal Contract
     ↓
Observe real evidence
     ↓
Create a falsifiable plan
     ↓
Attack the plan
     ↓
Delegate only real uncertainties
     ↓
Execute in checkpoints
     ↓
Verify independently
     ↓
Record what was learned

Algunos hallazgos actuales explican por qué vale la pena tomarse en serio sin convertir el artículo en hype.

Fuentes principales: Anthropic, PACT, MAST, Rethinking Multi-Agent Collaboration.

Regla práctica: comienza con un agente, identifica el cuello de botella, añade la menor cantidad de coordinación que lo elimine y mide si la complejidad adicional se justifica.

Tabla de contenidos

1. 01.La idea central: construir un bucle, no un consejo
2. 02.Cuándo el multi‑agente realmente ayuda — y cuándo empeora las cosas
3. 03.Modo Plan: el límite entre pensar y cambiar el mundo
4. 04.La arquitectura orientada al artefacto
5. 05.Roles y topologías: elegir la estructura según la tarea
6. 06.El protocolo de diálogo: Acción, Estado, Resultado
7. 07.El bucle completo de Creación Iterativa
8. 08.Cómo ejecutar el bucle hoy: Cursor, Claude Code, SDKs y harnesses personalizados
9. 09.Lo que la evidencia de 2025–2026 realmente nos dice
10. 10.Cuatro manuales prácticos: software, investigación, contenido y productos
11. 11.Verificación y medición: hacer “listo” observable
12. 12.Modos de falla: cómo se rompen los sistemas de agentes bien diseñados
13. 13.SEO, GEO y publicación legible por IA sin el folklore
14. 14.El kit operativo reutilizable

1. La idea central: construir un bucle, no un consejo

La expresión “sistema multi‑agente” hace que los agentes parezcan el objeto principal.

No lo son.

El objeto principal es el estado del flujo de trabajo.

Un agente especialista es simplemente una frontera de contexto temporal. Un crítico es un rol con un objetivo adversario. Un verificador es una puerta que requiere evidencia. Un gestor es un mecanismo de enrutamiento.

Lo que sobrevive de una etapa a la siguiente debe ser el estado del trabajo.

INTENTION
   ↓
OBSERVED STATE
   ↓
HYPOTHESIS / PLAN
   ↓
CHALLENGE
   ↓
ACTION
   ↓
NEW OBSERVATION
   ↓
VERIFICATION
   ↓
LEARNING

Ese patrón no es nuevo. La ingeniería de software tiene pruebas y revisión de código. La ciencia tiene hipótesis y experimentos. Las operaciones tienen respuesta a incidentes y postmortems. Los equipos de producto prototipan, observan e iteran.

Los sistemas agenticos hacen que una parte del bucle sea dramáticamente más barata: puedes ejecutar más investigación, crítica, síntesis y verificación sin que un humano realice cada paso intermedio.

El problema difícil, por lo tanto, pasa de “¿Puede un modelo generar algo impresionante?” a:

¿Puede el sistema preservar el estado correcto mientras pasa de una intención incierta a un resultado verificado?

1.1 Generación de respuestas vs. progresión del artefacto

Una respuesta de chat es un objeto terminal. Un artefacto puede inspeccionarse, modificarse, versionarse, probarse y reutilizarse.

Compara:

Question → Answer

con:

Goal Contract
→ Plan
→ Evidence Ledger
→ Decision Log
→ Implementation / Draft
→ Verification Report

La segunda canalización crea objetos con los que futuros agentes y humanos pueden trabajar.

Ese es el cambio de diseño clave.

1.2 Las tres preguntas que cada etapa debe responder

En cualquier punto del bucle, el siguiente participante debe poder responder:

1. 15.¿Qué estamos intentando lograr?
2. 16.¿Qué sabemos actualmente?
3. 17.¿Cuál es la siguiente acción justificada?

La mayoría de los flujos de trabajo con agentes fallan porque una de esas preguntas queda implícita.

El objetivo se pierde en un contexto extenso.

La evidencia se mezcla con la especulación.

La siguiente acción se elige porque el modelo anterior sonó confiado.

El bucle existe para mantener esas tres preguntas explícitas.

1.3 Por qué “más agentes” es el objetivo equivocado

Supongamos que un agente puede resolver una tarea en ocho llamadas a herramientas.

Creas cuatro agentes:

Planner
Researcher
Critic
Verifier

Ahora tienes:

- cinco contextos en lugar de uno,

- más enrutamiento,

- más transferencia de estado,

- más tokens,

- más latencia,

- más oportunidades de contradicción.

A menos que esos contextos adicionales aporten algo real — evidencia independiente, trabajo paralelo, herramientas especializadas, mejor verificación o aislamiento útil — has aumentado la complejidad sin incrementar la capacidad.

Por eso la arquitectura debe ser impulsada por la demanda.

2. Cuándo el multi‑agente realmente ayuda — y cuándo empeora las cosas

La pregunta no es si los sistemas multi‑agente son poderosos.

Lo son.

La pregunta es de dónde proviene el poder.

Un modelo útil es:

Multi-agent benefit
≈
parallelism
+ context isolation
+ specialization
+ independent criticism
+ additional tool capacity
− coordination cost
− token cost
− latency
− new failure modes

No existe una fórmula numérica universal. El punto es arquitectónico: cada agente adicional introduce un costo que debe tener una razón para existir.

2.1 Prueba de topología de tareas

Antes de crear un equipo, clasifique la tarea.

El artículo de septiembre de 2026 Rethinking Multi-Agent Collaboration: When More Is Less hace esta misma distinción de forma más formal: los beneficios son más fuertes en tareas de largo horizonte con dependencias escasas, mientras que los flujos de trabajo secuenciales fuertemente acoplados pueden favorecer los sistemas de agente único porque la sobrecarga de coordinación se vuelve dominante.

Source: Rethinking Multi-Agent Collaboration: When More Is Less.

2.2 Dependencia escasa vs dependencia densa

Esta distinción es una de las formas más rápidas de decidir.

Dependencia escasa

A ───┐
B ───┼──→ synthesis
C ───┤
D ───┘

A, B, C y D pueden trabajar de forma independiente.

El multi‑agente es atractivo.

Dependencia densa

A → B → C → D
    ↑   ↓
    └───┘

Cada etapa depende de los detalles de la anterior.

Un agente único o un flujo de trabajo determinista puede ser más fácil de gestionar.

2.3 Prueba de independencia

Antes de crear un especialista, pregunte:

¿Podría esta persona trabajar de forma independiente durante diez minutos y devolver algo que otra persona pueda realmente consumir?

Si la respuesta es no, probablemente no sea una buena subtarea paralela.

2.4 Prueba de contexto

Pregunte:

¿El especialista necesita toda la conversación?

Si no, aíslelo.

Un investigador de rendimiento probablemente no necesite todo el resumen del producto.

Un verificador de datos probablemente no necesite toda la transcripción de la lluvia de ideas.

Un especialista en seguridad puede necesitar la arquitectura y los archivos modificados, pero no la discusión de marketing.

El aislamiento de contexto no es solo una optimización de costos. A menudo es una optimización de calidad.

2.5 Regla de “no crear”

No crees un agente extra cuando:

- the task is simple,
- there is no meaningful parallelism,
- all stages need the same context,
- deterministic tools already solve the verification problem,
- or the expected benefit is purely stylistic.

Un buen orquestador puede decir:

No specialist required.
Proceed with single-agent execution.

Eso es una orquestación madura.

3. Modo Plan: el límite entre pensar y cambiar el mundo

El Modo Plan es útil por una razón engañosamente simple: hace que el plan sea visible antes de que la implementación se vuelva costosa de deshacer.

Cursor describe el Modo Plan como un flujo en el que el agente investiga la base de código, hace preguntas, crea un plan detallado, le permite revisarlo o editarlo, y luego construye a partir de ese plan. Los planes pueden guardarse en el espacio de trabajo. La CLI de Cursor también expone el modo plan mediante comandos como /plan y --mode=plan.

Claude Code también admite un modo de permiso de plan, así como subagentes y equipos de agentes para flujos de trabajo más complejos.

Fuentes:

- Modo Plan de Cursor

- CLI de Cursor

- Permisos de Claude Code

- Subagentes de Claude Code

- Equipos de Agentes de Claude Code

3.1 Razonamiento reversible vs acción irreversible

Sin un límite de planificación:

request
  ↓
agent edits
  ↓
discovers constraint
  ↓
edits again
  ↓
discovers dependency
  ↓
repairs previous edit
  ↓
human untangles diff

Con uno:

request
  ↓
inspect
  ↓
identify constraints
  ↓
compare approaches
  ↓
plan
  ↓
review
  ↓
execute

El modelo no se volvió más inteligente.

El flujo de trabajo se volvió más seguro.

3.2 El Contrato de Objetivos

Antes del plan, congele el problema.

goal: "Refactor the authorization layer without changing behavior"
constraints:
  - "preserve public API"
  - "preserve current authorization semantics"
  - "keep existing tests passing"
forbidden:
  - "framework migration"
  - "database schema change"
acceptance:
  - "all existing tests pass"
  - "new regression tests pass"
  - "duplicate authorization branches removed"
unknowns:
  - "legacy route behavior"

El contrato debe ser fácil de citar y difícil de malinterpretar.

3.3 Un plan debe predecir el futuro

Débil:

Mejorar la arquitectura y la fiabilidad.

Falsificable:

Reemplazar la resolución de permisos duplicada en los módulos A y B con el resolutor canónico existente, preservar las firmas públicas, añadir cobertura de regresión para los límites de invitado/administrador, y luego comparar el alcance de los archivos aprobados con el diff final.

La segunda versión puede fallar.

Esa es precisamente la razón por la que es útil.

3.4 Antipatrones de planificación

El problema de la fan fiction de arquitectura

El agente asume que las abstracciones existen porque serían sensatas.

Solución:

Inspect first.
If a component is not found, mark it UNKNOWN.
Do not invent it.

El problema de que “todo está en el alcance”

El usuario pide una refactorización. El agente rediseña silenciosamente tres sistemas.

Solución:

approved files
approved services
forbidden changes

El plan que no se puede probar

Si no puedes explicar cómo se verificará un paso, el paso no está listo.

4. La arquitectura basada en artefactos

La decisión de diseño más importante es hacer visible el estado compartido.

No diseñes en torno a “quién habla con quién”.

Diseña en torno a qué artefactos se mueven a través del sistema.

Recomiendo cinco artefactos canónicos:

1. Goal Contract
2. Plan
3. Evidence Ledger
4. Decision Log
5. Verification Report

4.1 Contrato de Objetivos

Es la definición estable de éxito.

# Goal Contract

Goal:
Refactor the reporting module without changing public behavior.

Constraints:
- preserve API
- preserve error semantics
- preserve current output format

Forbidden:
- schema migration
- framework replacement
- unrelated cleanup

Definition of done:
- existing tests pass
- regression suite passes
- public API diff is zero
- performance remains within target

4.2 Plan

El plan es una hipótesis, no una promesa de que la realidad lo obedecerá.

Debe contener:

- ubicaciones observadas,

- dependencias,

- suposiciones,

- secuencia,

- riesgos,

- pruebas de aceptación,

- ruta de reversión/recuperación.

Cuando nuevas pruebas invaliden el plan, revísalo en lugar de pretender que el anterior sigue describiendo la realidad.

4.3 Libro de Evidencias

Este es el artefacto que evita que la repetición se convierta en verdad.

Ejemplo:

claim: "OAI-SearchBot is relevant to OpenAI web search discovery"
source: "OpenAI Publishers and Developers FAQ"
source_type: "official-documentation"
state: "VERIFIED"
used_for: "AI crawler preflight"

La fuente puede respaldar la afirmación sin respaldar una afirmación mucho más fuerte como “esto garantiza la citación”.

Esa distinción es el objetivo principal de un libro de evidencias.

4.4 Estados de la evidencia

Usa un vocabulario reducido.

Un agente posterior nunca debería poder transformar UNKNOWN en VERIFIED simplemente repitiéndolo.

4.5 Registro de Decisiones

Registra las elecciones y las alternativas rechazadas.

Decision: Use manager + specialist-as-tool orchestration.

Rejected: unrestricted peer handoffs.

Reason: final synthesis needs one owner and specialists have bounded tasks.

Evidence: OpenAI Agents SDK manager-style orchestration guidance.

Los registros de decisiones se vuelven más valiosos con el tiempo porque explican no solo la arquitectura actual, sino por qué existe.

4.6 Informe de Verificación

El informe final debe leerse como una demostración, no como una celebración.

Criterion 1 — PASS
Evidence: 128/128 tests passed.

Criterion 2 — PASS
Evidence: public API snapshot unchanged.

Criterion 3 — FAIL
Evidence: duplicate branch remains in module C.

Decision: NO-GO
Repair: remove duplication and rerun targeted suite.

Ese documento es reutilizable por el siguiente agente, revisor o humano.

5. Roles y topologías: elija la estructura según la tarea

Los roles son útiles siempre que representen diferentes responsabilidades, contexto o autoridad.

El modelo clásico de cuatro roles es un buen punto de partida, no una ley:

5.1 Orquestación secuencial

Planner → Specialist → Executor → Verifier

Úselo cuando cada paso dependa de la salida anterior.

5.2 Orquestación concurrente

┌→ Research A ─┐
Planner ┼→ Research B ─┼→ Synthesizer
        └→ Research C ─┘

Úselo cuando las ramas sean independientes.

5.3 Transferencia

Triage → specialist

Úselo cuando un especialista deba asumir el contexto activo o la interacción con el usuario.

5.4 Manager + agentes-como-herramientas

┌→ Specialist A
Manager ─────────┼→ Specialist B
                 └→ Specialist C
                     ↓
                 final synthesis

Úselo cuando un agente deba poseer la respuesta final y decidir cuándo se necesitan especialistas.

El SDK de Agentes de OpenAI documenta explícitamente tanto los patrones de “agentes como herramientas” al estilo manager como los de transferencia, así como la orquestación impulsada por código donde la aplicación posee el flujo de trabajo.

Fuente: OpenAI Agents SDK — Orquestación de agentes.

5.5 Chat grupal

A ↔ B ↔ C ↔ Manager

El chat grupal puede funcionar para una deliberación genuina, pero tiene un modo de falla desagradable: todos siguen hablando porque nadie tiene la responsabilidad de detenerlo.

Utilice límites de rondas explícitos y un propietario de la decisión.

5.6 Orquestación dinámica / magnética

El Agent Framework de Microsoft describe la orquestación magnética como un manager que coordina agentes especializados de forma dinámica basándose en el estado evolutivo de la tarea.

Eso es útil cuando la ruta no se conoce de antemano.

No es automáticamente mejor que una canalización más simple.

Fuente: Microsoft — Orquestación magnética.

5.7 La matriz de decisión de topología

6. El protocolo de diálogo: Acción, Estado, Resultado

Un sistema multi‑agente puede fallar incluso cuando cada respuesta individual del modelo parece correcta.

¿Por qué?

Porque la comunicación misma es un recurso del sistema.

Considere:

Agent A → 2,000-word explanation
Agent B reads it and writes 1,800 words
Agent C receives A+B and writes 1,500 words
Agent D receives everything and decides what matters

Gran parte de ese texto es una explicación del historial de razonamiento, no el estado necesario para continuar.

Un artículo de junio de 2026, What Should Agents Say? Action-state Communication for Efficient Multi-Agent Systems, introduce PACT — Protocolized Action-state Communication and Transmission. El artículo estudia varias estrategias de comunicación y argumenta que los mensajes útiles entre agentes deben preservar el estado centrado en la acción en lugar de reenviar ciegamente resultados de formato libre. Sus experimentos informan una compensación entre rendimiento y costo sustancialmente mejor y un consumo reducido de tokens en los entornos probados. El artículo también enfatiza que ninguna estrategia de comunicación fija es óptima en todas partes.

Fuente: PACT.

La parte que vale la pena adoptar es directa:

Pasa el estado necesario para continuar, no la transcripción que lo produjo.

6.1 El mensaje de Acción-Estado-Resultado (Action-State-Result)

Un registro de transferencia práctico:

### Action-State Message

From: Critic
To: Planner

Action:
Reject plan step 3.2.

State:
The plan assumes generated routes are all crawlable. Repository inspection shows that one route family can produce orphaned URLs without canonical links.

Result:
Add a route-crawlability acceptance test and an explicit canonical URL requirement.

Evidence:
route manifest + crawler output + relevant source file.

Confidence:
High.

Next needed:
Revise step 3.2 before execution.

6.2 Por qué el "Resultado" (Result) es útil

"Acción" (Action) dice lo que sucedió.

"Estado" (State) dice por qué.

"Resultado" (Result) dice qué artefacto o decisión debe llevar adelante el receptor.

Sin el Resultado, el siguiente agente tiene que reconstruir la transferencia prevista.

6.3 Mantén los mensajes orientados al receptor

A un emisor le pueden importar cincuenta detalles.

Es posible que el receptor necesite cinco.

Un buen mensaje responde:

What changed?
Why does it matter?
What should I use?
What remains unresolved?

6.4 No pases cadenas de pensamiento privadas (chain-of-thought)

La coordinación estructurada no requiere pasar rastros de razonamiento ocultos.

Pasa:

- observaciones,

- resultados de herramientas,

- conclusiones,

- evidencia,

- decisiones,

- preguntas sin resolver,

- próximas acciones.

Eso es suficiente para coordinar.

6.5 Un formato JSON compacto

Cuando necesites transferencias legibles por máquina:

{
  "action": "reject_plan_step",
  "state": "route family can produce orphaned URLs",
  "result": "add crawlability + canonical acceptance test",
  "evidence": [
    "route-manifest.json",
    "crawler-output.json"
  ],
  "confidence": "high",
  "next_needed": "revise_plan"
}

Esto es especialmente útil cuando el orquestador está basado en código.

7. El ciclo de creación iterativa completo

El ciclo es una secuencia de puntos de control (gates), no un ritual por capricho.

7.1 Paso 0 — Congelar el contrato

Escribe:

Goal
Constraints
Forbidden changes
Definition of done
Unknowns

Haz esto antes de que el equipo se ponga creativo.

7.2 Paso 1 — Observar

Regla:

Ninguna invención donde la inspección sea posible.

Para software, inspecciona:

- árbol de código fuente,

- archivos relevantes,

- dependencias,

- pruebas,

- configuración,

- abstracciones actuales,

- cambios recientes.

Para investigación, inspecciona:

- fuentes primarias,

- documentación oficial,

- comportamiento actual del producto,

- artículos de investigación,

- evidencia contradictoria.

Para contenido, inspecciona:

- intención de búsqueda,

- referencias autorizadas,

- terminología,

- interpretaciones contrapuestas,

- preguntas de la audiencia.

La salida debe comenzar con Hechos Observados (Observed Facts).

7.3 Paso 2 — Planificar

El planificador (Planner) produce:

observed facts
assumptions
proposed sequence
dependencies
risks
acceptance tests
rollback path

Todo lo que no esté verificado permanece etiquetado.

7.4 Paso 3 — Desafiar

El crítico (Critic) recibe una sola instrucción:

Asume que el plan está mal. Encuentra la menor cantidad de razones de alto impacto por las que puede fallar.

Prioriza:

goal violations
wrong assumptions
hidden dependencies
missing tests
security/reliability risks
scope creep
unnecessary complexity

No le pidas al crítico que reescriba el plan.

Pídele que destruya el plan.

7.5 Paso 4 — Especializar

Genera especialistas solo para la incertidumbre no resuelta.

Ejemplos:

Performance question
Security question
Framework compatibility question
Research evidence question
Accessibility question
Crawler behavior question

La asignación de un especialista debe ser lo suficientemente específica como para caber en una sola oración.

7.6 Paso 5 — Resolver desacuerdos

No utilices:

latest response wins

Utiliza una jerarquía de prioridad de evidencias:

1. direct mechanical evidence
2. reproducible experiment
3. official / primary documentation
4. source-code inspection
5. peer-reviewed or clearly identified research
6. strong secondary analysis
7. expert judgment
8. model intuition

Este es un heurístico práctico, no una clasificación científica universal. Su función es evitar que la confianza retórica supere a la evidencia.

7.7 Paso 6 — Refinar el plan canónico

No adjuntes más debates a una transcripción gigante.

Actualiza el Plan.

El plan debe seguir siendo el estado actual canónico.

7.8 Paso 7 — Aprobar un punto de control

No apruebes una implementación riesgosa completa como una sola promesa atómica.

Aprueba una unidad pequeña:

Checkpoint 1
→ execute
→ verify
→ update state

Checkpoint 2
→ execute
→ verify
→ update state

7.9 Paso 8 — Ejecutar

La ejecución ahora debe contar con un contrato, un alcance y condiciones de prueba.

7.10 Paso 9 — Verificar

El verificador debe ver:

- Contrato de objetivos,

- criterios de aceptación,

- el artefacto resultante,

- la evidencia sin procesar relevante,

- el resultado de la prueba determinista.

No se le debe decir la conclusión de antemano.

7.11 Paso 10 — Aprender

Registra:

what failed
which assumption was wrong
which test caught it
which communication was wasteful
whether the specialist was necessary
whether the overall topology paid off

Eso se convierte en la memoria organizacional del futuro.

7.12 El diagrama de estado completo

┌──────────┐
│  OBSERVE │
└────┬─────┘
     ↓
┌──────────┐
│ CONTRACT │
└────┬─────┘
     ↓
┌──────────┐
│   PLAN   │
└────┬─────┘
     ↓
┌──────────┐
│ CHALLENGE│
└────┬─────┘
     ↓
┌──────────┐
│SPECIALIZE│  only where needed
└────┬─────┘
     ↓
┌──────────┐
│  REFINE  │
└────┬─────┘
     ↓
┌──────────┐
│ APPROVE  │
└────┬─────┘
     ↓
┌──────────┐
│ EXECUTE  │
└────┬─────┘
     ↓
┌──────────┐
│ VERIFY   │
└────┬─────┘
     ↓
┌──────────┐
│  LEARN   │
└────┬─────┘
     │
     └────────────→ OBSERVE

8. Cómo ejecutar el ciclo hoy: Cursor, Claude Code, SDKs y arneses personalizados

El marco de trabajo debe venir después del flujo.

8.1 Cursor

El modo Plan (Plan Mode) de Cursor es un entorno natural para la primera mitad del ciclo:

Plan Mode
→ inspect repository
→ ask questions
→ create/edit Markdown plan
→ review
→ build
→ review diff
→ run checks

La documentación de Cursor recomienda específicamente el modo Plan para funciones complejas, cambios en múltiples archivos, requisitos inciertos y decisiones de arquitectura. Para ediciones pequeñas y familiares, señala que el modo Agente (Agent mode) puede ser más apropiado.

Referencias útiles:

- Cursor Plan Mode

- Cursor Plan Mode help

- Cursor CLI

- Cursor quickstart

Configuración práctica

1. Write Goal Contract.
2. Enter Plan Mode.
3. Ask for observed facts first.
4. Ask for plan + acceptance tests.
5. Run a fresh-context Critic pass.
6. Revise the plan.
7. Build one checkpoint.
8. Run deterministic checks.
9. Run verifier.

8.2 Claude Code

Claude Code admite control de permisos orientado a planes, subagentes con contextos de trabajo separados y equipos de agentes para una coordinación más independiente.

La distinción útil es:

Subagent
= isolated worker for a bounded task

Agent team
= multiple independent sessions coordinating on a broader problem

Utiliza subagentes cuando el trabajo intermedio sea grande pero solo sea necesario devolver el resultado al contexto principal.

Utiliza equipos cuando los trabajadores independientes necesiten coordinarse en torno a una tarea compartida.

Referencias útiles:

- Claude Code Subagents

- Claude Code Agent Teams

- Claude Code Permissions

8.3 OpenAI Agents SDK

La documentación actual del SDK de OpenAI describe dos estrategias generales de orquestación:

Impulsada por LLM: el modelo decide qué agentes/herramientas invocar.

Impulsada por código: la lógica de la aplicación determina el flujo.

También distingue entre:

Agentes como herramientas: el administrador conserva el control.

Transferencias (Handoffs): el especialista toma el relevo.

Los mismos documentos describen el encadenamiento, los bucles de evaluación y la ejecución de agentes en paralelo como patrones comunes impulsados por código.

Esto te proporciona una implementación directa del Ciclo de Creación Iterativa:

planner
→ critic
→ refiner
→ executor
→ evaluator
→ repair/replan

References:

- OpenAI Agents SDK

- Orquestación de agentes

- Guía de multi‑agentes en JavaScript

8.4 LangChain y LangGraph

La documentación actual de LangChain trata explícitamente el diseño multi‑agente como un problema de ingeniería de contexto y documenta patrones como:

- subagentes,

- transferencias,

- enrutadores,

- habilidades.

LangGraph brinda un control más explícito de grafos/estados para aplicaciones que requieren transiciones de flujo de trabajo persistentes e inspeccionables.

References:

- LangChain multi‑agente

- LangGraph

8.5 CrewAI

CrewAI es una forma orientada a roles y tareas para prototipar flujos de trabajo de equipos.

La pregunta importante no es si el framework llama a su proceso una “crew”. La pregunta importante es si puede representar:

Goal
→ task decomposition
→ ownership
→ dependencies
→ outputs
→ verification

Reference: documentación de CrewAI.

8.6 Microsoft Agent Framework

La documentación actual del Agent Framework de Microsoft expone varios patrones de orquestación:

Sequential
Concurrent
Handoff
Group Chat
Magentic

También admite interacciones de flujo de trabajo con humanos en el bucle.

Este vocabulario es útil incluso si nunca usa el framework porque le brinda nombres para diferentes formas de coordinación.

References:

- Orquestaciones de flujo de trabajo

- Orquestación Magéntica

- Patrones de orquestación de agentes de IA

8.7 Tabla de selección de frameworks

Esto no es una clasificación. Es un mapa de ajuste.

9. Lo que la evidencia de 2025–2026 realmente nos dice

El campo de los multi‑agentes ha acumulado suficiente evidencia de que “más agentes = más inteligente” ya no es un principio de diseño serio.

La pregunta interesante es de dónde provienen las ganancias y dónde desaparecen.

9.1 Anthropic: más cómputo puede comprar más capacidad de investigación

El informe de ingeniería de Anthropic sobre su sistema de Investigación multi‑agente es uno de los ejemplos públicos más claros.

La arquitectura utiliza un agente principal para planificar la investigación y delega direcciones a subagentes que investigan en paralelo.

Anthropic informa:

- 90,2 % de mejora respecto a su línea base de un solo agente en su evaluación interna BrowseComp,

- aproximadamente 15× el uso de tokens del chat ordinario,

- grandes ganancias por la paralelización y la capacidad de contexto adicional,

- poco adecuado para algunas tareas estrechamente acopladas donde los agentes necesitan un contexto compartido intensivo.

La lección correcta no es “usar muchos agentes”.

Es:

Cuando una tarea tiene alto valor, gran cantidad de recopilación de información paralelizables y un cuello de botella en un contexto, la ejecución multi‑agente puede comprar capacidad de razonamiento adicional útil.

Source: Anthropic — How we built our multi-agent Research system.

9.2 PACT: la comunicación es una superficie de optimización

PACT plantea una pregunta más concreta:

¿Qué deberían decir realmente los agentes entre sí?

La respuesta no es “enviar todo”.

El artículo evalúa múltiples estrategias y propone la comunicación Acción‑Estado como una forma de preservar la información relevante para la decisión mientras se reduce la transferencia de contexto innecesario. Informa ahorros sustanciales de tokens en sus experimentos, incluyendo mejoras en los harnesses de codificación evaluados.

La idea más transferible es:

public state update
> conversation transcript

Source: PACT.

9.3 MAST: la coordinación crea modos de falla

El artículo Why Do Multi-Agent LLM Systems Fail? analizó más de 150 rastros en detalle para construir una taxonomía de 14 modos de falla agrupados en:

1. 18.especificación y diseño del sistema,
2. 19.desalineación entre agentes,
3. 20.verificación y terminación de tareas.

El proyecto posteriormente puso a disposición un conjunto de datos de rastros anotados más grande para una evaluación más amplia.

El punto importante es arquitectónico:

Un sistema multiagente es un sistema nuevo. Necesita su propia ingeniería de confiabilidad.

Fuente: MAST.

9.4 MultiAgentBench: la coordinación misma puede medirse

El trabajo MultiAgentBench de ACL 2025 evalúa no solo la finalización de tareas, sino también el comportamiento de coordinación. Estudia protocolos de coordinación en estrella, cadena, árbol y grafo, y utiliza métricas orientadas a hitos.

Esto es útil porque la precisión final por sí sola oculta el comportamiento del sistema.

Un flujo de trabajo puede producir la respuesta correcta por las razones equivocadas.

También puede gastar enormes recursos para producir un resultado modesto.

Fuente: MultiAgentBench.

9.5 Septiembre de 2026: “cuando más es menos” se convierte en la pregunta central

El estudio de septiembre de 2026 Rethinking Multi-Agent Collaboration: When More Is Less examina directamente la escalabilidad de los grupos de agentes y la profundidad de recursión.

Su mensaje clave es que la estructura de la tarea define el límite de capacidad. Más agentes no siempre generan mejores resultados.

Esa es casi exactamente la razón por la que esta guía se niega a convertir “cuatro agentes” o “diez agentes” en una receta universal.

Fuente: Rethinking Multi-Agent Collaboration.

9.6 El patrón de evidencia

A través de estas fuentes, emerge una imagen de ingeniería coherente:

Multi-agent helps when:
+ work can be decomposed
+ branches are reasonably independent
+ contexts benefit from isolation
+ additional tool capacity matters
+ independent checking has real value

Multi-agent hurts when:
− dependencies are dense
− everyone needs the same context
− communication dominates work
− verification is weak
− agents duplicate each other
− the task is too small to justify the overhead

Esa es una conclusión mucho más útil que “el multiagente es el futuro”.

10. Cuatro manuales prácticos: software, investigación, contenido y productos

El ciclo es abstracto. Estos manuales lo hacen concreto.

10.1 Software: refactorizar sin desviación de comportamiento

Objetivo

Dividir un módulo de informes grande sin cambiar su comportamiento público.

Planificador

Inspeccionar:

- exportaciones públicas,

- llamadores,

- estado compartido,

- pruebas,

- rutas sensibles al rendimiento,

- configuración.

Salida:

current boundaries
candidate extraction points
dependency order
regression tests
rollback path

Crítico

Atacar:

hidden coupling
changed error behavior
circular dependencies
performance regressions
snapshot drift
unapproved files

Especialista

El especialista en rendimiento recibe una pregunta:

¿Extraer el formateador traslada el trabajo a una ruta crítica o duplica la serialización?

Ejecutor

Cambia solo los archivos aprobados.

Verificador

Preferir puertas deterministas:

unit tests
integration tests
type checking
lint
build
API snapshot
benchmark
diff scope

Ejemplo de registro de verificación

PASS — 128/128 unit tests
PASS — 24/24 integration tests
PASS — 0 type errors
PASS — public API unchanged
PASS — benchmark within target
PASS — changed files within approved scope

El LLM no es el verificador completo.

Es la capa que interpreta los resultados que las herramientas deterministas no pueden interpretar completamente.

10.2 Investigación: construir un mapa de evidencia en lugar de una pila de resúmenes

Pregunta:

¿Cómo descubren y utilizan las fuentes web los sistemas de búsqueda de IA actuales?

No lance seis “investigadores” genéricos.

Divida la incertidumbre:

Cada trabajador devuelve registros estructurados:

claim: "X"
source: "https://example.com/source"
source_type: "official-docs"
published: "2026-08-12"
evidence: "exact observation"
state: "SUPPORTED"
limitations:
  - "platform-specific"

El rol de investigación más valioso a menudo no es otro investigador.

Es el investigador de desconfirmación.

Asigne este trabajo a un trabajador:

Encuentre evidencia que haga que la conclusión emergente sea incorrecta o sustancialmente más débil.

Eso reduce las cascadas de confirmación.

10.3 Contenido: separar el trabajo epistémico del trabajo de estilo

Un artículo técnico sólido puede usar este flujo de trabajo:

Question map
    ↓
Evidence map
    ↓
Argument map
    ↓
Outline
    ↓
Draft
    ↓
Fact check
    ↓
Human-voice edit
    ↓
SEO/GEO preflight

El flujo de trabajo deficiente es:

SEO agent
→ writer
→ humanizer
→ GEO agent
→ headline agent
→ final polish agent

¿Por qué?

Porque cada agente está optimizando la forma superficial. Nadie es claramente responsable de la verdad epistémica.

Etiquetas de reclamos de contenido

Un conjunto de etiquetas internas útil:

FACT
REPORTED RESULT
OBSERVATION
INTERPRETATION
OPINION
PROPOSAL
UNKNOWN

El artículo publicado no necesita mostrar cada etiqueta. El flujo de trabajo interno debe conocerlas.

10.4 Creación de producto: asignar a cada rol un objetivo de falla diferente

Utilice cuatro perspectivas:

El User Advocate debe tener una asignación concreta:

Encuentre cada lugar donde el producto le pide al usuario que entienda nuestra arquitectura interna en lugar de comprender su propio trabajo.

Eso genera retroalimentación mucho más accionable que “revisar UX”.

11. Verificación y medición: hacer que el “listo” sea observable

Un flujo de trabajo se convierte en un sistema de ingeniería cuando puede explicar por qué cree que está completo.

11.1 Jerarquía de verificación

Use la puerta fiable más barata primero.

LEVEL 1 — Mechanical
schema validation
unit tests
type checks
lint
HTTP checks
file existence

LEVEL 2 — Deterministic comparison
snapshots
diffs
benchmarks
invariants
regression datasets

LEVEL 3 — Model evaluation
semantic quality
classification
summarization fidelity
comparative judgment
style compliance

LEVEL 4 — Human review
high-stakes decisions
ambiguous interpretation
final publication
material production changes

No use un modelo para responder una pregunta que un compilador puede responder.

11.2 Verificación criterio por criterio

Malo:

Todo se ve bien.

Bueno:

Criterion: Preserve public API
Status: PASS
Evidence: API snapshot diff = 0

Criterion: Remove duplication
Status: FAIL
Evidence: legacy branch remains in src/auth/legacy.ts

Criterion: Existing tests pass
Status: PASS
Evidence: 128/128

11.3 PASS / FAIL / UNKNOWN

UNKNOWN es importante.

A un verificador se le debe permitir decir:

No pude establecer este criterio.

Eso es mejor que un PASS fabricado.

11.4 Un contexto nuevo no implica automáticamente independencia

Un verificador nuevo aún puede estar sesgado si le alimenta la conclusión del creador.

Evite:

The implementation succeeded. Please verify it.

Prefiera:

Original goal:
...

Acceptance criteria:
...

Result:
...

Raw test evidence:
...

Determine PASS / FAIL / UNKNOWN.

El verificador recibe evidencia, no el veredicto.

11.5 Métricas centrales

11.6 Realice una prueba A/B de su flujo de trabajo

En lugar de debatir si el multi‑agente es “mejor”, compare:

A — one agent
B — planner + critic
C — planner + critic + specialist

Para la misma clase de tarea, mida:

cost
latency
pass/fail
rework
defects
verification catches
human interventions

Mantenga la coordinación adicional solo si mejora el resultado verificado lo suficiente como para justificar su costo.

12. Modos de falla: cómo los sistemas de agentes de aspecto atractivo se rompen

Agregar agentes crea un nuevo sistema. Los nuevos sistemas generan nuevos modos de falla.

MAST formalizó este problema con 14 modos de falla que abarcan el diseño de especificaciones/sistemas, el desalineamiento entre agentes y la verificación/terminación de tareas.

Source: ¿Por qué fallan los sistemas LLM multiagente?.

La siguiente tabla operativa convierte esa investigación en verificaciones de ingeniería.

12.1 Diálogo infinito

Set:

max_rounds = 3

Then:

if no acceptance-blocking issue remains:
    approve
else:
    escalate

No permita que el sistema invente razones para seguir debatiendo.

12.2 Teatro de consenso

Se debe permitir que un crítico rechace un plan.

Pero también se debe permitir que el Planificador rechace al Crítico cuando la objeción no está respaldada.

Una buena colaboración adversarial no es “todos están en desacuerdo”.

Es:

claim
→ evidence
→ challenge
→ resolution

12.3 Cascadas de alucinación

Una afirmación no respaldada se vuelve peligrosa cuando pasa por múltiples agentes:

UNKNOWN
 ↓
plausible
 ↓
supported-sounding
 ↓
“fact”
 ↓
implementation decision

Su modelo de estado debe hacer explícita esa conversión.

12.4 Corrupción de estado compartido

Para artefactos importantes, use un único escritor canónico.

Critic      → proposes change
Specialist  → proposes evidence
Planner     → updates canonical plan
Verifier    → updates verification report
Human       → approves/rejects high-impact decisions

Otros proponen. Un propietario confirma.

12.5 Alucinación de herramienta

Mantenga un registro de mundo cerrado:

tool: run_tests
description: "Runs the repository's configured test suite"
permissions: [read, execute]
side_effects: "may create temporary files"

No permita que un agente asuma que “debe haber una herramienta para eso”.

12.6 Economía de tokens

Un flujo de trabajo puede ser técnicamente exitoso y económicamente absurdo.

La cifra de tokens 15× publicada por Anthropic para la investigación multiagente es una advertencia útil, aunque es específica de la arquitectura y evaluación de Anthropic.

Measure:

cost per verified success

not merely:

cost per run

13. SEO, GEO y publicación legible por IA sin el folclore

El trabajo creado por agentes se convierte cada vez más en contenido público.

Eso crea un segundo problema: una vez que el flujo de trabajo produce un gran artículo, ¿cómo facilitar que personas, motores de búsqueda y sistemas de IA lo descubran y comprendan sin convertir el artículo en “sopa de SEO”?

La respuesta comienza con una distinción:

La arquitectura de información legible por máquinas es útil. Los trucos mágicos de GEO no la sustituyen.

13.1 Lo que Google realmente dice en 2026

La guía actual de Google sobre funciones de IA es inusualmente directa:

- las prácticas recomendadas de SEO existentes siguen siendo relevantes,

- las páginas deben estar indexadas y ser elegibles para la Búsqueda para poder respaldar enlaces en AI Overviews o AI Mode,

- no existen requisitos técnicos adicionales específicos requeridos para esas funciones de IA,

- el contenido importante debe estar disponible en formato de texto,

- los enlaces internos, la capacidad de rastreo, la experiencia de la página y el contenido original útil siguen siendo importantes,

- no se requiere ningún marcado Schema.org especial para AI Overviews o AI Mode.

Google también afirma que cumplir con las prácticas recomendadas no garantiza el rastreo, la indexación ni el servicio.

Fuentes:

- Google — AI Features and Your Website

- Google — Optimizing for generative AI features

Ese último punto importa porque acaba con una de las peores formas de marketing de búsqueda por IA:

“Haz estas tres cosas y la IA de Google te citará”.

No existe tal garantía universal.

13.2 Search Console ahora ofrece una mejor capa de medición

Google introdujo los informes de rendimiento de la IA generativa de búsqueda en junio de 2026 y afirmó que había implementado dichos conocimientos en todo el mundo para el 31 de agosto de 2026.

Los informes exponen la visibilidad dentro de las funciones de IA generativa en la Búsqueda, incluidos AI Overviews y AI Mode, dentro del sistema de informes de rendimiento de Search Console.

Ese es un importante avance práctico porque proporciona a los editores una superficie de medición propia en lugar de obligar a realizar todos los análisis de búsqueda por IA basándose en estimaciones de terceros.

Fuente: Google Search Central — Search Generative AI performance reports.

Usa esos datos donde estén disponibles.

13.3 Lo que debe significar “legible por IA”

Una página útil debería permitir que una máquina responda:

What is this page about?
Who wrote it?
When was it published/updated?
What are the major claims?
What evidence supports them?
Which sections answer which questions?
Which parts are facts versus interpretations?
Where are the primary sources?
What is the canonical version?

Eso no es un formato especial para IA.

Es una buena arquitectura de información.

13.4 Estructura para contenido de referencia de formato largo

Una estructura de artículo duradera:

Title
↓
TL;DR
↓
Table of Contents
↓
Definition / thesis
↓
Evidence
↓
Counterexamples
↓
Architecture
↓
Implementation
↓
Examples
↓
Failure modes
↓
Measurement
↓
Limitations
↓
Templates
↓
Sources

Esa estructura ayuda a los humanos y a los sistemas de recuperación por la misma razón fundamental: reduce la ambigüedad.

13.5 Datos estructurados: útiles, no mágicos

Para un artículo, las propiedades relevantes de Schema.org pueden incluir:

Article
author
datePublished
dateModified
headline
image
mainEntityOfPage

Pero el marcado debe describir el contenido visible con precisión.

No afirmes que el esquema Article garantiza citas o clasificaciones en la IA.

La documentación de datos estructurados de Google indica explícitamente que los datos estructurados le ayudan a comprender el contenido, mientras que la elegibilidad y la aparición dependen de sistemas y requisitos adicionales.

Fuentes:

- Google — Structured data policies

- Schema.org — Article

13.6 robots.txt es una capa, no toda la pila tecnológica

Google afirma que robots.txt controla el acceso de los rastreadores; no es un mecanismo general de noindex.

Para evitar que las páginas aparezcan en la Búsqueda de Google, Google señala el uso de noindex o la autenticación en lugar de depender únicamente de robots.txt.

Fuentes:

- Google — robots.txt

- Google — meta tags and attributes

Para los rastreadores de IA, se aplica la misma verdad práctica: la página puede estar permitida por robots.txt y aun así fallar a través de otra infraestructura.

Piensa en capas:

robots.txt
   ↓
WAF / CDN
   ↓
bot mitigation
   ↓
authentication
   ↓
rate limiting
   ↓
JavaScript challenges
   ↓
HTTP response
   ↓
rendering / retrieval

OpenAI documenta OAI-SearchBot para el descubrimiento relacionado con la búsqueda web y proporciona orientación a los editores sobre cómo permitir el acceso. Anthropic documenta identidades de rastreadores separadas como ClaudeBot, Claude-User y Claude-SearchBot.

Fuentes:

- OpenAI — Preguntas frecuentes para editores y desarrolladores

- Anthropic — Rastreadores web y robots.txt

13.7 llms.txt: experimento razonable, no SEO mágico

El proyecto llms.txt es una propuesta comunitaria para presentar información curada orientada a máquinas sobre un sitio.

Puede ser útil como documentación.

No es un requisito universal de Google.

La guía actual de Google sobre IA generativa indica explícitamente que no es necesario crear archivos de texto especiales de IA, como llms.txt, para aparecer en sus funciones de búsqueda con IA generativa.

Fuentes:

- llms.txt

- Google — guía de IA generativa

Úselo porque cumple una función clara de arquitectura de la información, no porque alguien lo haya vendido como un interruptor de posicionamiento.

13.8 La medición GEO es más que el recuento de citas

Investigaciones recientes de 2026 están avanzando hacia un modelo más preciso de visibilidad en búsquedas con IA.

Un estudio de abril de 2026 separa:

citation selection
≠
citation absorption

Una página puede ser recuperada y citada sin contribuir materialmente a la respuesta generada.

Una encuesta de julio de 2026 describe de manera similar a GEO como un proceso de múltiples etapas que involucra descubribilidad, recuperación, reordenamiento, citación, prominencia, absorción factual y comportamiento del usuario posterior.

Fuentes:

- De la selección de citas a la absorción de citas

- Optimización de la visibilidad en motores generativos: una encuesta crítica

Esto sugiere una pila de medición mejor:

Discoverability
↓
Retrieval
↓
Citation
↓
Citation position / prominence
↓
Answer contribution
↓
Factual fidelity
↓
Traffic / conversions

Eso es mucho más informativo que “puntuación de visibilidad de IA = 83.”

13.9 Lo que sugiere la investigación reciente de GEO — con cautela

Los estudios de 2026 están encontrando asociaciones y efectos controlados que involucran factores como la relevancia temática, la posición del contexto, la información factual explícita, la estructura y la riqueza de la evidencia. Un estudio competitivo de GEO evaluó 252,000 ensayos controlados en seis LLM; otro amplio estudio ACL de 2026 explora la alineación latente de la demanda del usuario; un marco separado estudia cómo la influencia de la cita difiere de la selección de citas.

Estas son direcciones de investigación valiosas.

Pero no deberían simplificarse en consejos universales como:

“Escribe exactamente X palabras, agrega Y encabezados, y toda IA te citará.”

La afirmación práctica más fuerte es más segura:

Haz que la información importante sea explícita, relevante, bien respaldada, fácil de recuperar y fiel al material fuente.

Fuentes:

- Qué se cita: GEO competitivo en motores de respuesta de IA

- Mind Reader — ACL 2026

- De la experiencia a la habilidad — hallazgos de ACL 2026

13.10 Prevuela práctico de GEO/SEO

TECHNICAL
[ ] Crawlable when intended
[ ] Indexable when intended
[ ] Canonical URL is correct
[ ] Important text is accessible
[ ] No accidental noindex
[ ] Internal links are present
[ ] HTTP responses are healthy

CONTENT
[ ] Clear title
[ ] One clear H1
[ ] Coherent heading hierarchy
[ ] Direct answers to major questions
[ ] Definitions before jargon
[ ] Material claims supported by sources
[ ] Facts separated from interpretation
[ ] Publication/update date
[ ] Author / provenance

AI ACCESS
[ ] Intended AI crawler policy is deliberate
[ ] WAF/CDN does not silently block intended access
[ ] Authentication is understood
[ ] Rate limits are sane
[ ] JavaScript challenges are not accidental blockers

STRUCTURE
[ ] Accurate Article/Organization/etc. structured data where appropriate
[ ] Structured data matches visible content
[ ] Stable URLs
[ ] Duplicate versions controlled
[ ] Sources are easy to follow

Para una prevuela práctica de página pública, AuditMe's Website SEO Checker puede inspeccionar una URL y detectar problemas en SEO técnico, estructura de contenido, schema, rendimiento y dimensiones relacionadas de preparación.

Eso lo hace útil como una pasada diagnóstica.

No es una prueba de que un sistema de IA citará la página.

Enlaces de AuditMe para el flujo de trabajo

- AuditMe — SEO & Website Intelligence Audit

- AuditMe — Website SEO Checker

- AuditMe — SEO Score Checker

La forma correcta de utilizar una herramienta de auditoría en este proceso es como evidencia previa al lanzamiento: encontrar problemas técnicos y estructurales antes de pedirle a un motor de búsqueda o a un sistema de IA que descubra la página.

14. El kit operativo reutilizable

Esta sección está diseñada para ser copiada.

Puedes colocar las plantillas en un repositorio, una base de conocimientos, una biblioteca de prompts o un motor de flujos de trabajo.

14.1 Plantilla de contrato de objetivos

# Goal Contract

## Goal
[One precise sentence]

## Why
[Why the work matters]

## Constraints
- [constraint]
- [constraint]

## Forbidden Changes
- [forbidden change]
- [forbidden change]

## Definition of Done
- [measurable criterion]
- [measurable criterion]

## Unknowns
- [unknown]
- [unknown]

14.2 Prompt del planificador

You are the Planner.

Goal:
[goal]

Constraints:
[list]

Forbidden changes:
[list]

Definition of done:
[criteria]

First inspect the real evidence available to you.
Do not execute implementation.
Do not invent architecture.
Mark assumptions and unknowns explicitly.

Return:
1. Observed facts
2. Assumptions
3. Proposed plan
4. Dependencies
5. Risks
6. Acceptance tests
7. Rollback/recovery path

14.3 Prompt del crítico

You are the Critic.

Assume the current plan is wrong.
Find the smallest number of high-impact reasons it could fail.

Prioritize:
- goal violations
- incorrect assumptions
- hidden dependencies
- missing tests
- security/reliability risks
- unnecessary complexity
- scope creep

Do not rewrite the plan.
Return each issue as:

Action:
State:
Result:
Evidence:
Confidence:
Next needed:

14.4 Prompt del especialista

You are a domain specialist.

Question to resolve:
[one specific question]

Do not review the entire project.
Do not redesign unrelated systems.
Prefer primary documentation, code inspection, tests, or reproducible measurements.

Return:
Action:
State:
Result:
Evidence:
Confidence:
Open questions:

14.5 Prompt del verificador

You are the Verifier.

Original Goal:
[goal]

Definition of Done:
[criteria]

Inspect the result independently.
Do not rely on the creator's explanation.
Prefer deterministic evidence whenever available.

For every criterion return:
PASS / FAIL / UNKNOWN

For each result include:
- evidence
- blockers
- defects found
- repair needed

Final decision:
GO / CONDITIONAL GO / NO-GO

14.6 Prompt del editor con voz humana

You are the final human-voice editor.

Do not make the article more enthusiastic.
Make it more credible and authored.

Remove:
- generic AI transitions
- inflated adjectives
- repeated conclusions
- fake certainty
- unnecessary headings
- repetitive sentence rhythms

Preserve:
- technical specificity
- source attribution
- disagreement
- uncertainty
- concrete examples
- author judgment

Do not invent personal experience, clients, benchmarks, or case studies.

14.7 Esquema de transferencia entre agentes

from: "critic"
to: "planner"
action: "reject_plan_step"
state: "orphaned routes are possible"
result: "add crawlability and canonical acceptance test"
evidence:
  - "route-manifest.json"
  - "crawler-output.json"
confidence: "high"
next_needed: "revise_plan"

14.8 Estructura sugerida para el repositorio

.agent/
├── goal-contract.md
├── plan.md
├── evidence-ledger.md
├── decisions.md
├── verification.md
├── prompts/
│   ├── planner.md
│   ├── critic.md
│   ├── specialist.md
│   ├── verifier.md
│   └── human-voice-editor.md
└── runs/
    ├── 2026-09-22-run-001.md
    └── 2026-09-23-run-002.md

El directorio exacto no importa.

La separación sí.

14.9 Bucle mínimo viable (Minimum Viable Loop) — De 15 a 30 minutos

0–5 minutos

Escribe:

Goal
Constraints
Forbidden changes
Definition of done
Unknowns

5–10 minutos

Modo de planificación / pasada del planificador.

10–15 minutos

Crítico con contexto fresco.

15–20 minutos

Resuelve las correcciones respaldadas por evidencia.

20–25 minutos

Ejecuta un punto de control.

25–30 minutos

Verifica con respecto al contrato original.

Eso es suficiente para empezar.

No necesitas una plataforma de orquestación distribuida para obtener el beneficio principal.

14.10 Lista de comprobación compacta

Antes de la ejecución

[ ] Goal Contract exists
[ ] Constraints explicit
[ ] Forbidden changes explicit
[ ] Definition of done measurable
[ ] Real evidence inspected
[ ] Unknowns labeled
[ ] Plan falsifiable
[ ] Critic allowed to reject
[ ] Specialists have narrow assignments
[ ] Canonical plan has one owner

During execution

[ ] Independent work parallelized only where useful
[ ] Handoffs pass state, not speeches
[ ] Evidence provenance preserved
[ ] Tool permissions scoped
[ ] Checkpoints explicit
[ ] Scope remains inside contract
[ ] Raw test outputs retained

Before shipping

[ ] Deterministic checks passed
[ ] Material claims verified
[ ] Contradictions resolved or labeled
[ ] Final artifact matches Goal Contract
[ ] Unknowns documented
[ ] Verification is independent enough to matter
[ ] Cost / latency / rework measured
[ ] Final artifact is reusable

14.11 Las 12 reglas que vale la pena recordar

1. Comienza con un agente.

No diseñes un consejo de agentes antes de poder nombrar el cuello de botella.

2. Divide por incertidumbre, no por cargo.

Un especialista existe porque algo requiere un contexto, herramientas, experiencia o un juicio independiente diferentes.

3. Paraleliza el trabajo independiente.

Esa es una de las razones más claras para usar múltiples agentes.

4. Mantén estable el Goal Contract.

De lo contrario, el sistema puede "triunfar" cambiando el problema.

5. Haz que el plan sea canónico.

No conviertas el historial de chat en tu base de datos.

6. Pasa estado, no discursos.

Acción + Estado + Resultado es un estándar práctico.

7. Ataca antes de ejecutar.

Una suposición errónea en Markdown es barata. Una suposición errónea dentro de un diff de producción no lo es.

8. Verifica con el método confiable más económico.

Compilador por encima de conversación. Prueba por encima de opinión. Fuente por encima de memoria.

9. Trata a DESCONOCIDO (UNKNOWN) como un estado válido.

La evidencia faltante es información.

10. Mide los resultados verificados.

Las llamadas a herramientas son actividad. Una prueba de aceptación superada es evidencia de progreso.

11. Mantén el marco de trabajo más pequeño que el problema.

Si la orquestación es más difícil que la tarea subyacente, simplifica.

12. Detente cuando se cumpla la meta.

Más diálogo no significa automáticamente más calidad.

14.12 Reflexión final

La era de los agentes producirá una gran cantidad de demostraciones espectaculares.

Algunas de ellas serán útiles.

Muchas otras también confundirán la actividad con el progreso.

Diez agentes pueden hablar durante veinte minutos y no producir nada que un humano pueda enviar a producción de forma segura.

Un agente puede resolver un problema difícil con un buen plan y una prueba real.

Por lo tanto, el problema de ingeniería interesante no es:

¿Cuántos agentes puedo hacer que colaboren?

Es:

¿Qué información debe sobrevivir de una etapa a la siguiente para que el sistema pueda pasar de la intención a la acción respaldada por evidencia y, finalmente, a la finalización verificada?

Ese es el Iterative Creation Loop.

La implementación más sencilla suele seguir siendo la mejor:

Goal Contract
→ Plan
→ Adversarial Critique
→ Narrow Specialist when needed
→ Checkpoint
→ Deterministic Verification
→ Independent Review
→ Learn

Comienza por ahí.

Mídela frente a la versión de un solo agente.

Añade complejidad únicamente cuando aporte algo que puedas observar.

Esa es la parte que vale la pena escalar.

No el número de agentes.

La calidad del ciclo.

Lecturas adicionales y fuentes primarias

Orquestación y planificación de agentes

- Cursor — Modo de planificación

- Cursor — Ayuda del modo de planificación

- Cursor — CLI

- Claude Code — Subagentes

- Claude Code — Equipos de agentes

- Claude Code — Permisos

- OpenAI Agents SDK

- OpenAI — Orquestación de agentes

- OpenAI — Orquestación multi‑agente en JavaScript

- LangChain — Sistemas multi‑agente

- LangGraph

- Documentación de CrewAI

- Microsoft — Patrones de orquestación de agentes de IA

- Microsoft Agent Framework — Orquestaciones de flujos de trabajo

- Microsoft Agent Framework — Orquestación Magentic

Investigación y evaluación multi‑agente

- Anthropic — Cómo construimos nuestro sistema de investigación multi‑agente

- PACT — ¿Qué deberían decir los agentes? Comunicación de acción‑estado para sistemas multi‑agente eficientes

- ¿Por qué fallan los sistemas LLM multi‑agente?

- MultiAgentBench

- Repensando la colaboración multi‑agente: Cuando más es menos

SEO, búsqueda con IA y acceso web

- Google — Funciones de IA y su sitio web

- Google — Optimización para funciones generativas de IA

- Google — Cómo funciona la búsqueda

- Google — robots.txt

- Google — Metatags y atributos

- Google — Políticas de datos estructurados

- Google — Informes de rendimiento de IA generativa en la búsqueda

- OpenAI — Preguntas frecuentes para editores y desarrolladores

- Anthropic — Rastreadores web y robots.txt

- Propuesta llms.txt

Investigación y medición GEO

- GEO: Optimización de motores generativos

- De la selección de citas a la absorción de citas

- Qué se cita: GEO competitivo en motores de respuesta de IA

- Optimización de la visibilidad en motores generativos: Una encuesta crítica

- Mind Reader — ACL 2026

- De la experiencia a la habilidad — Hallazgos de ACL 2026

Prevuelo práctico

- AuditMe — Auditoría de SEO e inteligencia de sitios web

- AuditMe — Verificador de SEO de sitios web

- AuditMe — Verificador de puntuación SEO

Nota editorial

Esta guía separa intencionalmente los resultados de ingeniería reportados por los proveedores, los hallazgos académicos, la documentación oficial del producto y las heurísticas prácticas.

Las métricas de los proveedores no son puntos de referencia universales. Los resultados académicos dependen del diseño del benchmark y de las condiciones experimentales. La documentación del producto describe el comportamiento declarado actualmente por el editor, no todos los posibles resultados en el mundo real. Las mediciones GEO pueden variar según la consulta, el motor, el conjunto de fuentes, el proceso de recuperación, el modelo y el tiempo.

El experimento más útil sigue siendo el menos glamoroso:

Ejecuta la misma clase de tarea con y sin coordinación adicional. Mide el resultado verificado. Conserva solo la complejidad que realmente lo mejora.