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.
---
Prueba AuditMe en vivo — Escaneo instantáneo gratuito
Pega cualquier URL a continuación y obtén una puntuación SEO real en unos 60 segundos. Sin registro: es el mismo motor descrito en este artículo.
TL;DR
El cambio útil es de generación de respuestas a progresión de artefactos.
En lugar de:
Human → Prompt → Model → Answerutiliza:
Goal Contract
↓
Observe real evidence
↓
Create a falsifiable plan
↓
Attack the plan
↓
Delegate only real uncertainties
↓
Execute in checkpoints
↓
Verify independently
↓
Record what was learnedAlgunos hallazgos actuales explican por qué vale la pena tomarse en serio sin convertir el artículo en hype.
| Evidencia actual | Lo que realmente respalda |
|---|---|
| Anthropic informó una mejora del 90,2 % respecto a su línea base de un solo agente en una evaluación interna de investigación | La investigación multi‑agente puede producir grandes ganancias en la clase de tareas adecuada. No es un benchmark universal para todas las cargas de trabajo de agentes. |
| Anthropic reportó aproximadamente 15× el uso de tokens del chat normal para su sistema de investigación multi‑agente | La coordinación compra capacidad, pero el costo es real. La tarea debe justificarlo. |
| El artículo PACT 2026 informó un costo de comunicación sustancialmente menor cuando las salidas de los agentes se proyectan en registros compactos de acción‑estado | El diseño de la comunicación es parte de la arquitectura del agente; reenviar transcripciones completas no es la única opción. |
| La investigación MAST identificó 14 modos de falla en sistemas multi‑agente, abarcando diseño del sistema, desalineación entre agentes y verificación de tareas | Añadir agentes introduce nuevas superficies de falla en lugar de eliminar todas las fallas. |
| Un estudio de septiembre de 2026 argumenta que las ganancias multi‑agente son más fuertes en trabajos de horizonte largo y dependencia escasa, y pueden disminuir en tareas secuenciales estrechamente acopladas | La topología de la tarea importa más que la cantidad de agentes. |
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
- 01.La idea central: construir un bucle, no un consejo
- 02.Cuándo el multi‑agente realmente ayuda — y cuándo empeora las cosas
- 03.Modo Plan: el límite entre pensar y cambiar el mundo
- 04.La arquitectura orientada al artefacto
- 05.Roles y topologías: elegir la estructura según la tarea
- 06.El protocolo de diálogo: Acción, Estado, Resultado
- 07.El bucle completo de Creación Iterativa
- 08.Cómo ejecutar el bucle hoy: Cursor, Claude Code, SDKs y harnesses personalizados
- 09.Lo que la evidencia de 2025–2026 realmente nos dice
- 10.Cuatro manuales prácticos: software, investigación, contenido y productos
- 11.Verificación y medición: hacer “listo” observable
- 12.Modos de falla: cómo se rompen los sistemas de agentes bien diseñados
- 13.SEO, GEO y publicación legible por IA sin el folklore
- 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
↓
LEARNINGEse 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 → Answercon:
Goal Contract
→ Plan
→ Evidence Ledger
→ Decision Log
→ Implementation / Draft
→ Verification ReportLa 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:
- 15.¿Qué estamos intentando lograr?
- 16.¿Qué sabemos actualmente?
- 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
VerifierAhora 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 modesNo 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.
| Característica de la tarea | Agente único | Multi‑agente |
|---|---|---|
| Corta y autónoma | Usualmente suficiente | A menudo innecesario |
| Secuencia fuertemente acoplada | A menudo preferible | Puede añadir costo de sincronización |
| Muchas ramas de investigación independientes | Limitado por tiempo/contexto secuencial | Muy adecuado |
| Dominios/herramientas diferentes | Posible pero con mucho contexto | Muy adecuado cuando los límites son reales |
| Necesita revisión adversarial independiente | Auto‑revisión posible | Un crítico separado puede ayudar |
| Ejecución de alto riesgo | Requiere controles | Un verificador separado/HITL puede ayudar |
| Gran contexto supera un conjunto de trabajo útil | Más difícil | La partición de contexto puede ayudar |
| Pipeline determinista | Usualmente mejor en código | Multi‑agente puede ser excesivo |
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:
- 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 diffCon uno:
request
↓
inspect
↓
identify constraints
↓
compare approaches
↓
plan
↓
review
↓
executeEl 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 changesEl 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 Report4.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 target4.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.
| Campo | Propósito |
|---|---|
| Afirmación | La declaración exacta que se afirma |
| Fuente | URL, archivo, prueba, benchmark, resultado de herramienta |
| Tipo de fuente | Documentación oficial / código / experimento / investigación / secundaria |
| Publicado / observado | Actualidad |
| Evidencia | Lo que la fuente realmente establece |
| Estado | VERIFICADO / APOYADO / PLAUSIBLE / DESCONOCIDO |
| Conflictos | Evidencia contradictoria |
| Usado para | Decisión o paso del plan |
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.
| Estado | Significado | Uso permitido |
|---|---|---|
| VERIFICADO | Observado directamente, probado mecánicamente o claramente establecido por una fuente primaria para la afirmación exacta | Puede impulsar decisiones |
| APOYADO | Evidencia sólida, pero no completamente reproducida o más limitada que la afirmación | Puede informar decisiones |
| PLAUSIBLE | Interpretación razonable | Debe permanecer etiquetado |
| DESCONOCIDO | Falta evidencia | No debe convertirse en un hecho silenciosamente |
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:
| Rol | Trabajo principal | Entrada | Salida | Límite de autoridad |
|---|---|---|---|---|
| Planificador | Descomponer el objetivo y proponer la secuencia | Objetivo + evidencia | Plan + riesgos + criterios | No puede redefinir el objetivo en silencio |
| Crítico | Cuestionar suposiciones y el plan | Objetivo + plan | Modos de falla + evidencia | No puede reescribir los requisitos |
| Especialista | Resolver una incertidumbre estrecha | Pregunta + contexto delimitado | Recomendación respaldada por evidencia | No puede expandir el alcance |
| Ejecutor | Realizar cambios aprobados | Plan aprobado | Implementación/borrador | No puede redefinir el contrato |
| Verificador | Probar el resultado contra el contrato | Objetivo + resultado + evidencia cruda | APROBADO/RECHAZADO/DESCONOCIDO | No puede renunciar a los criterios en silencio |
| Humano | Autoridad final en decisiones ambiguas o de alto impacto | Estado completo y relevante | Decisión vinculante | — |
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 ↔ ManagerEl 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
| Pregunta | Si SÍ | Si NO |
|---|---|---|
| ¿Pueden ejecutarse las ramas de forma independiente? | Considerar agentes concurrentes | Preferir secuencial/un agente |
| ¿Necesita un especialista contexto/herramientas únicos? | Aislar al especialista | Mantener el contexto unificado |
| ¿Debe un agente poseer la respuesta final? | Manager + agentes-como-herramientas | Posible topología de transferencia/pares |
| ¿Puede codificarse el siguiente paso de forma determinista? | Orquestar en código | El LLM puede ayudar a enrutar |
| ¿Es inevitable la planificación abierta? | Un manager dinámico puede ser adecuado | Se prefiere una topología más simple |
| ¿Puede una prueba responder la pregunta? | Usar verificación determinista | Puede ser necesaria evaluación de modelo/humano |
---
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 mattersGran 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
UnknownsHaz 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 pathTodo 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 complexityNo 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 questionLa 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 winsUtiliza 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 intuitionEste 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 state7.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 offEso 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 checksLa 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:
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 problemUtiliza 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:
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/replanReferences:
- 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:
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
→ verificationReference: 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
MagenticTambié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
- Patrones de orquestación de agentes de IA
8.7 Tabla de selección de frameworks
| Necesidad | Punto de partida razonable | Fortaleza principal |
|---|---|---|
| Codificación interactiva + planificación | Cursor | Plan → Construir flujo de trabajo |
| Codificación centrada en terminal + workers | Claude Code | Subagentes / equipos / controles de permisos |
| Flujo de trabajo de agente Python personalizado y ligero | OpenAI Agents SDK | Pequeñas primitivas + trazado/orquestación |
| Gráfico de flujo de trabajo con estado | LangGraph | Transiciones explícitas y estado |
| Prototipo rápido estilo Crew | CrewAI | Abstracción de rol/tarea |
| Patrones de orquestación empresarial | Microsoft Agent Framework | Vocabulario de topología rico + HITL |
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 transcriptSource: 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:
- 18.especificación y diseño del sistema,
- 19.desalineación entre agentes,
- 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 overheadEsa 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 pathCrítico
Atacar:
hidden coupling
changed error behavior
circular dependencies
performance regressions
snapshot drift
unapproved filesEspecialista
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 scopeEjemplo 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 scopeEl 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:
| Trabajador | Pregunta |
|---|---|
| A | ¿Qué dicen los documentos oficiales de búsqueda/plataforma? |
| B | ¿Qué miden los estudios académicos primarios? |
| C | ¿Qué controles de rastreador/acceso existen actualmente? |
| D | ¿Qué contradice la interpretación optimista? |
| E | ¿Cómo debería medirse realmente la visibilidad de las citas? |
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 preflightEl 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
UNKNOWNEl 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:
| Rol | Pregunta |
|---|---|
| Planner | ¿Qué debería existir? |
| User Advocate | ¿Dónde los usuarios pueden malinterpretar o abandonar el producto? |
| Technical Specialist | ¿Qué es costoso, arriesgado o frágil? |
| Verifier | ¿Qué evidencia demuestra que el producto resolvió el problema planteado? |
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 changesNo 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/12811.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
| Métrica | Definición | Por qué importa |
|---|---|---|
| First-pass success | Éxitos verificados en la primera ejecución importante | Calidad de la planificación |
| Rework ratio | Cambios rehechos / cambios totales | Desperdicio downstream |
| Verification catch rate | Defectos encontrados por verificación / defectos descubiertos después | Valor de la verificación |
| Tokens per successful task | Tokens totales / éxitos verificados | Economía |
| Time to verified result | Inicio → pase de verificación | Velocidad real |
| Human escalation rate | Intervenciones humanas / tareas | Autonomía y ambigüedad |
| Scope violation rate | Cambios fuera de contrato / tareas | Especialmente importante para codificación |
| Evidence coverage | Reclamaciones de material con fuente / reclamaciones de material | Calidad de investigación/contenido |
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 + specialistPara la misma clase de tarea, mida:
cost
latency
pass/fail
rework
defects
verification catches
human interventionsMantenga 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.
| Modo de falla | Síntoma típico | Prevención |
|---|---|---|
| Diálogo infinito | Los agentes continúan discutiendo después de que la información deja de cambiar | Límite estricto de rondas + condición de parada |
| Colapso de rol | Cada agente produce la misma revisión genérica | Objetivos estrechos + límites de autoridad |
| Investigación duplicada | Varios trabajadores investigan lo mismo | Particiones de investigación explícitas |
| Fuga de contexto | Los agentes pierden el foco en historial irrelevante | Contexto delimitado + entregas estructuradas |
| Teatro de consenso | Los agentes están de acuerdo porque el texto previo sonaba confiado | Crítico adversario + jerarquía de evidencia |
| Desviación del plan | El objetivo cambia silenciosamente durante la implementación | Contrato de objetivo inmutable |
| Propagación de alucinaciones | Una afirmación no respaldada se vuelve aceptada aguas abajo | Estados de evidencia |
| Verificación solo con LLM | “PASS” fluido sin evidencia real de prueba | Puertas determinísticas |
| Alucinación de herramienta | El agente inventa o usa incorrectamente herramientas | Registro de herramientas de mundo cerrado |
| Corrupción de estado compartido | Varios trabajadores sobrescriben artefactos canónicos | Regla de propiedad / escritor único |
| Explosión de tokens | Los costos de comunicación superan el trabajo útil | Compresión de acción-estado |
| Cascada de latencia | Los trabajadores secuenciales multiplican el tiempo de espera | Paralelizar tareas independientes |
| Terminación prematura | El gestor detiene antes de que se cumplan los criterios | Pruebas de aceptación explícitas |
| Gravedad del framework | La infraestructura del flujo de trabajo supera la complejidad de la tarea | Comenzar más simple |
12.1 Diálogo infinito
Set:
max_rounds = 3Then:
if no acceptance-blocking issue remains:
approve
else:
escalateNo 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
→ resolution12.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 decisionSu 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 decisionsOtros 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 successnot 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
↓
SourcesEsa 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
mainEntityOfPagePero 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
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 — 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 / retrievalOpenAI 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 absorptionUna 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 / conversionsEso 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
- 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 followPara 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
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 path14.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-GO14.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.mdEl 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
Unknowns5–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 ownerDuring 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 retainedBefore 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 reusable14.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
→ LearnComienza 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
- Claude Code — Equipos de agentes
- OpenAI — Orquestación de agentes
- OpenAI — Orquestación multi‑agente en JavaScript
- LangChain — Sistemas multi‑agente
- 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
- ¿Por qué fallan los sistemas LLM multi‑agente?
- 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 — 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
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
- 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.
Eduard Tymchenko
SEO Expert & Founder of AuditMe
“I built AuditMe after 10+ years of manual SEO audits — every check in this report is one I used to run by hand.”
Specializes in technical SEO, Core Web Vitals, and WordPress optimization.
Ejecuta tu auditoría SEO gratuita
Obtén un análisis SEO completo de cualquier URL en 60 segundos. Sin registro.
O abre el analizador completo con más detalles
Analiza tu sitio gratisHerramientas SEO gratuitas
Artículos relacionados
Continúa aprendiendo con estas guías y tutoriales de SEO:
SEO Didn't Die. Websites Got Harder to Understand.
A human-written, evidence-first field guide to SEO, GEO, AI search visibility, agent readiness and website intelligence.
35 min read
Your Website Was Seen 116,181 Times and Clicked 9 Times. Here's What Search Engines and AI Systems Are Actually Doing.
A first-party 2026 investigation from AuditMe into the Visibility Gap: how crawling, indexing, retrieval, ranking, AI citations, clicks, trust, and conversions form one measurable website intelligence system.
21 min read
How AI Systems Read the Web in 2026: Discovery, Retrieval, Citations and Agents
An evidence-first guide to AI search, GEO, retrieval, entity clarity, citations and agent-ready websites — with a practical framework, implementation patterns and a proposed open benchmark methodology.
45 min read
The PAOVR Loop: The Real Agent Loop That Actually Finishes Jobs
Stop building agents that narrate completion. A production-grade field guide to loop engineering, JSON contracts, and reliable AI systems.
20 min read