Prompting-Loop Engineering: la forma de aprovechar los modelos avanzados sin perder el rigor

---

---

Protocolo para diseñar flujos iterativos, auditables y autocorrectivos mediante agentes configurados y prompts estructurados

La interacción con la inteligencia artificial generativa (IAgen) ha estado dominada por una idea aparentemente sencilla: cuanto mejor sea el prompt, mejor será la respuesta. Durante los últimos años, esta premisa impulsó la creación de plantillas, estructuras y técnicas orientadas a formular instrucciones —prompts— más precisas. El usuario debía aprender a declarar un rol, proporcionar contexto, establecer restricciones y definir un formato de salida.

Este enfoque continúa siendo útil, sin duda, y entre más estructurado —JSON o MD—, mejor, pero resulta insuficiente cuando la tarea incluye múltiples transformaciones, fuentes documentales, verificaciones o productos intermedios. Un único prompt puede solicitar una búsqueda, organizar documentos, analizar resultados y generar una presentación. Sin embargo, concentrar todas esas operaciones en una sola ejecución aumenta el riesgo de pérdida de contexto, mezcla de funciones, ausencia de trazabilidad y propagación de errores.

La discusión reciente sobre el llamado loop engineering propone un cambio de perspectiva. En lugar de concentrarse exclusivamente en escribir una instrucción perfecta, el diseñador construye un sistema de retroalimentación: un agente produce una salida, otro la audita, los fallos detectados se convierten en nuevas instrucciones y el proceso vuelve a ejecutarse hasta alcanzar los criterios establecidos. La premisa de partida no es que la IA responderá correctamente en el primer intento, sino que cometerá errores y necesitará mecanismos para identificarlos y corregirlos.

Esta lógica se ha popularizado en entornos de programación capaces de ejecutar código, probarlo, leer mensajes de error y producir una nueva versión. No obstante, sus principios también pueden trasladarse a espacios de trabajo no-code, procesos de investigación, gestión documental, producción académica y servicios de información.

El desafío consiste en representar mediante instrucciones declarativas aquello que normalmente se programaría mediante variables, condicionales, ciclos, controladores y gestores de estado.

Este artículo presenta el concepto de Prompting-Loop Engineering no-code, una adaptación orientada a transformar rutas multiagente en procesos iterativos, auditables y autocorrectivos mediante prompts estructurados (Macedo, 2026; Runkle, 2026). La propuesta surge como evolución de una arquitectura previa de orquestación no-code implementada en Proyectos de ChatGPT y organizada mediante agentes configurados en archivos JSON.

Aprenda a generar agentes de IA en formato JSON y sin necesidad de código en el artículo Guía elemental para la creación de agentes de Inteligencia Artificial (IA): Arquitectura, seguridad y portabilidad.

De los agentes aislados a la orquestación no-code

En el artículo La Orquestación de Sistemas Multiagente No-Code en la Inteligencia Artificial se propuso que los agentes especializados podían concentrarse dentro de espacios de trabajo cerrados, como los Proyectos de ChatGPT, mediante archivos de identidad en formatos estructurados y documentos adicionales utilizados como bases de conocimiento (info[rage], 2026). El artículo diferenciaba los archivos que contienen instrucciones operativas de aquellos que proporcionan literatura, datos o información contextual mediante generación aumentada por recuperación.

La arquitectura descrita incluía tres elementos principales:

1. agentes con misiones delimitadas;

2. archivos documentales y bases de conocimiento;

3. un archivo maestro encargado de seleccionar agentes, transferir contexto y ordenar la ejecución.

El principio era equivalente a una cadena de procesamiento:

Solicitud
→ agente especializado
→ producto intermedio
→ siguiente agente
→ producto final

Por ejemplo, una necesidad de investigación activa un agente encargado de normalizar términos y construir ecuaciones de búsqueda. La salida obtenida pasa posteriormente a un agente documental que extrae variables y consolidaba una matriz de revisión. Otro agente podía utilizar esa matriz para generar una visualización, una presentación o un texto académico.

Esta división emula algunas dinámicas de los equipos de investigación reales. Una sola persona no suele ejecutar con el mismo grado de especialización la búsqueda bibliográfica, la evaluación de fuentes, el análisis estadístico, la normalización de referencias y el diseño visual. Del mismo modo, un sistema de IA distribuye esas funciones entre configuraciones especializadas para cada objetivo.

Los Proyectos de ChatGPT ofrecen condiciones útiles para este tipo de experimentación: permiten reunir conversaciones, instrucciones y archivos dentro de un mismo espacio de trabajo; conservan contexto e historial; y pueden priorizar los materiales del proyecto durante las respuestas.

Sin embargo, almacenar agentes en un proyecto y definir una secuencia no resuelve completamente la calidad del flujo. Una cadena tiene la probabilidad de transferir una salida defectuosa al siguiente eslabón. Si una ecuación de búsqueda está mal formulada, el agente documental organizará un corpus irrelevante. Si una matriz omite variables fundamentales, la visualización final representará una estructura incompleta. El último agente puede producir un artefacto estéticamente convincente sin que la información que lo sostiene sea correcta.

Por tanto, el paso siguiente no consistía en añadir más agentes. Consistía en gobernar lo que debía ocurrir cuando una salida fuera insuficiente.

¿Qué es el Prompting-Loop Engineering?

El Prompting-Loop Engineering puede definirse como:

El diseño declarativo de procesos agentivos iterativos mediante prompts estructurados que establecen una misión, distribuyen funciones entre agentes especializados, conservan estados de ejecución, validan productos intermedios, diagnostican errores, activan retornos dirigidos y fijan condiciones verificables de continuidad y parada.

En términos más sencillos:

Consiste en utilizar prompts para convertir una cadena de agentes en un flujo capaz de revisar sus resultados, detectar fallos, regresar al punto responsable y continuar hasta cumplir una condición definida de calidad.

Su estructura básica se expresa de la siguiente manera:

Producir
→ validar
→ diagnosticar
→ corregir o reenrutar
→ ejecutar nuevamente
→ comprobar
→ finalizar

La propuesta conserva el principio central del loop engineering: diseñar sistemas que asumen la posibilidad de error y utilizan la retroalimentación para producir nuevas versiones. Su particularidad radica en que las reglas del bucle se representan mediante lenguaje estructurado dentro de un entorno no-code.

¿Por qué “Prompting”?

Porque la arquitectura se define mediante instrucciones interpretables: lenguaje natural, Markdown, JSON, YAML o combinaciones equivalentes. El prompt deja de ser únicamente una solicitud y se convierte en una especificación del sistema.

¿Por qué “Loop”?

Porque la ejecución no avanza siempre en línea recta. Una salida puede aceptarse, corregirse, reenviarse a un agente anterior, ampliarse con otra capacidad o detenerse por insuficiencia de información.

¿Por qué “Engineering”?

Porque no se trata de repetir respuestas de forma improvisada. El diseñador debe definir componentes, estados, contratos, validadores, errores posibles, reglas de transición, límites y condiciones de cierre.

La fórmula conceptual es:

Orquestación multiagente
+ estado compartido
+ auditoría
+ retorno dirigido
+ iteración
+ condición de parada
=
Prompting-Loop Engineering

No es lo mismo conversar, encadenar y construir un bucle

Conviene distinguir varios niveles de interacción.

Prompting convencional

El usuario formula una instrucción y recibe una respuesta:

Prompt → respuesta

Puede solicitar una nueva versión, pero la iteración depende de intervenciones sucesivas del usuario.

Cadena multiagente

La misión se distribuye entre varias funciones:

Agente A → Agente B → Agente C → producto

Existe especialización, pero la salida suele transferirse automáticamente al siguiente nodo.

Prompting-Loop Engineering

La salida se valida antes de continuar:

Agente A
→ Agente B
→ validación
   ├── aceptar → siguiente agente
   ├── corregir → mismo agente
   ├── reenrutar → agente responsable
   ├── ampliar → agente adicional
   └── bloquear → finalizar con limitación

La diferencia no depende del número de agentes. Una arquitectura con diez agentes puede ser completamente lineal. Otra con solo dos agentes puede constituir un bucle funcional si uno produce, el otro evalúa y existe una nueva ejecución basada en el diagnóstico.

La arquitectura mínima del Prompting-Loop Engineering

Un sistema de Prompting-Loop Engineering requiere, como mínimo, ocho componentes.

1. Una misión verificable

La misión debe especificar qué problema se resolverá y qué producto se espera.

No basta con pedir:

Investiga la inteligencia artificial en bibliotecas.

Una misión más operativa sería:

Identificar, seleccionar y organizar evidencia reciente sobre el uso de inteligencia artificial generativa en servicios de referencia universitaria para producir un informe de tendencias, riesgos y oportunidades, con fuentes académicas verificables y trazabilidad documental.

Esta formulación permite evaluar si el producto responde al objetivo.

2. Agentes con funciones delimitadas

Cada agente debe realizar una transformación identificable.

Un sistema de investigación podría incluir:

Agente	Función
Agente conceptual	Delimita conceptos, dimensiones y relaciones
Agente de búsqueda	Normaliza términos y formula ecuaciones
Agente de recuperación	Localiza fuentes y metadatos
Agente documental	Extrae variables y organiza hallazgos
Agente auditor	Evalúa coherencia, cobertura y trazabilidad
Agente de uso	Convierte los hallazgos en un producto

Los nombres pueden variar. Lo importante es que una misma función no aparezca distribuida de forma ambigua entre varios agentes.

El Ecosistema Info[rage] utilizado en la prueba para realizar este artículo incluye agentes especializados distribuidos en las fases Identificar, Buscar, Almacenar, Evaluar y Usar información, junto con rutas de dos a cinco eslabones para distintos escenarios académicos y documentales.

3. Un estado compartido

El sistema debe conservar lo ocurrido.

Un estado mínimo puede representarse así:

{
  "mission": null,
  "current_agent": null,
  "route": [],
  "inputs": [],
  "intermediate_products": [],
  "findings": [],
  "errors": [],
  "quality_score": null,
  "iteration": 0,
  "status": "initialized"
}

En una implementación no-code puede mantenerse como un bloque estructurado en JSON dentro del prompt, de las instrucciones del proyecto o del registro conversacional.

El estado impide que cada iteración comience sin memoria de las decisiones anteriores.

4. Una ruta inicial

La ruta representa la primera hipótesis de ejecución.

Conceptualización
→ búsqueda
→ extracción
→ auditoría
→ producción final

La ruta no debe entenderse como una secuencia inmutable. Es una propuesta que puede ajustarse durante el proceso.

5. Contratos de entrada y salida

Cada agente necesita saber qué recibe, qué transforma y qué debe entregar.

{
  "agent": "agente_de_busqueda",
  "input": {
    "research_question": "",
    "concepts": [],
    "scope": {}
  },
  "expected_output": {
    "normalized_terms": [],
    "search_equations": [],
    "filters": []
  },
  "quality_criteria": [
    "Representar todos los conceptos centrales",
    "Incluir sinónimos pertinentes",
    "Generar ecuaciones ejecutables",
    "Conservar el alcance de la misión"
  ]
}

Sin contratos, una salida puede parecer útil y aun así resultar incompatible con el siguiente agente.

6. Un mecanismo de evaluación

Toda salida crítica debe compararse con una rúbrica.

Una auditoría puede considerar:

• correspondencia con la misión;

• suficiencia de información;

• trazabilidad;

• consistencia entre entradas y salidas;

• ausencia de contradicciones;

• cumplimiento técnico;

• utilidad del producto.

La puntuación puede ayudar a resumir la revisión, pero no debe sustituir el diagnóstico. Decir que una salida obtuvo 0,78 no explica qué debe corregirse. El auditor debe identificar errores concretos y convertirlos en instrucciones.

7. Reglas de retorno

El sistema necesita saber a dónde regresar.

Problema	Retorno sugerido
Conceptos ambiguos	Agente conceptual
Ecuación demasiado amplia	Agente de búsqueda
Fuentes insuficientes	Agente de recuperación
Variables incompletas	Agente documental
Referencias incorrectas	Agente normativo
Relación no sustentada	Agente documental o conceptual
Gráfico inadecuado	Agente de visualización
Contradicción transversal	Agente auditor

El retorno dirigido es una de las diferencias más importantes entre un bucle y una simple repetición.

8. Condiciones de parada

El proceso debe saber cuándo terminar.

Una parada exitosa puede exigir:

{
  "minimum_quality_score": 0.85,
  "critical_error_tolerance": 0,
  "traceability_required": true,
  "mission_alignment_required": true
}

También debe existir una parada forzada:

• máximo de iteraciones alcanzado;

• ausencia de mejora;

• herramienta no disponible;

• entrada indispensable ausente;

• evidencia insuficiente;

• continuación dependiente de información inventada.

Detenerse con un producto parcial y declarar sus limitaciones es preferible a fabricar una sensación de éxito.

Protocolo general para implementar Prompting-Loop Engineering

El siguiente procedimiento puede adaptarse a distintos sistemas de agentes.

Paso 1. Inventariar los agentes

Construya una tabla con:

• nombre;

• misión;

• entradas;

• salidas;

• restricciones;

• herramientas;

• dependencias.

No atribuya a un agente capacidades que no estén declaradas o disponibles.

Paso 2. Clasificar sus funciones

Los agentes pueden agruparse mediante el ciclo de la información:

Identificar
→ Buscar
→ Evaluar
→ Almacenar
→ Usar

Este esquema resulta especialmente útil en investigación y bibliotecas porque observa dónde se origina una necesidad, cómo se recupera la evidencia, bajo qué criterios se evalúa, de qué manera se organiza y en qué producto se transforma.

No obstante, el protocolo puede utilizar otras arquitecturas: entrada, procesamiento, evaluación y salida; planificación, ejecución y verificación; o cualquier clasificación compatible con la misión.

Paso 3. Formular la misión

La misión debe incluir:

• objetivo;

• entradas;

• restricciones;

• producto final;

• audiencia;

• criterios de aceptación.

Paso 4. Seleccionar la ruta mínima suficiente

No active todos los agentes por defecto.

La incorporación de agentes innecesarios aumenta el consumo de contexto, la complejidad y las posibilidades de contradicción. El propio debate sobre loop engineering advierte que la ejecución de múltiples subagentes puede incrementar considerablemente el consumo de recursos.

Paso 5. Declarar el estado compartido

Defina qué variables deben conservarse:

• misión;

• ruta;

• resultados;

• fuentes;

• errores;

• versiones;

• decisiones;

• iteración;

• razón de parada.

Paso 6. Establecer contratos

Para cada transición, indique:

• entrada aceptada;

• salida esperada;

• formato;

• criterios de calidad;

• errores que bloquean el avance.

Paso 7. Diseñar la auditoría

La auditoría no debe limitarse a preguntar si la respuesta “está bien”.

Debe comprobar dimensiones específicas:

¿Responde a la misión?
¿Se deriva de las entradas?
¿Está respaldada?
¿Puede rastrearse?
¿Es compatible con la siguiente fase?
¿Contiene contradicciones?
¿Declara sus limitaciones?

Paso 8. Mapear errores y retornos

Elabore una tabla previa de fallos previsibles.

Esto permite evitar que todo problema termine en una regeneración completa.

Paso 9. Definir iteraciones y estancamiento

Ejemplo:

{
  "maximum_global_iterations": 5,
  "maximum_same_agent_retries": 2,
  "minimum_meaningful_change": true,
  "stagnation_limit": 2
}

El número exacto dependerá del costo y del riesgo de la tarea.

Paso 10. Construir el prompt maestro

El prompt debe declarar:

1. identidad del orquestador;

2. misión;

3. agentes disponibles;

4. estado compartido;

5. ruta inicial;

6. contratos;

7. validaciones;

8. retornos;

9. condiciones de continuidad;

10. condiciones de parada;

11. formato del registro.

Una versión reducida de un prompt maestro:

ACTÚA COMO ORQUESTADOR DE PROMPTING-LOOP ENGINEERING.

MISIÓN:
[Objetivo y producto]

AGENTES:
- [Agente A]: [función]
- [Agente B]: [función]
- [Auditor]: [función]
- [Agente final]: [función]

RUTA INICIAL:
A → B → Auditor → Agente final → Auditoría final

REGLAS:
1. Ejecuta una transformación a la vez.
2. Valida cada salida antes de transferirla.
3. No aceptes productos con errores críticos.
4. Regresa al agente responsable del error.
5. Registra el motivo y el cambio solicitado.
6. No inventes herramientas, fuentes ni acciones.
7. Detente cuando se cumplan los criterios de aceptación.
8. Finaliza con limitaciones si el proceso se bloquea.

CRITERIOS:
- puntuación mínima: [valor];
- errores críticos permitidos: cero;
- iteraciones máximas: [valor].

INICIAR ORQUESTACIÓN.

Recuerde que esto se ejecuta dentro del Proyecto de ChatGPT, en un chat nuevo o en uno con contexto.

Paso 11. Activar explícitamente la arquitectura

Un archivo cargado no siempre será interpretado como una instrucción operativa. Puede ser tratado como un documento para resumir, revisar o analizar. Cada agente debe estar previamente cargado en el Proyecto.

Por ello, conviene utilizar un mensaje de activación:

El archivo adjunto contiene la arquitectura operativa de esta conversación. Léalo completamente, adopte sus estados, agentes, rutas, auditorías y condiciones de parada. Interprete el bloque de misión como una orden inmediata y comience la ejecución sin solicitar una operación adicional.

Esta capa diferencia la definición del sistema de su activación.

Paso 12. Registrar las versiones

Cada iteración debe conservar:

• producto anterior;

• diagnóstico;

• agente de retorno;

• instrucción correctiva;

• producto nuevo;

• diferencia observable;

• decisión final.

Paso 13. Auditar la parada

El último agente no debe cerrar el proceso por el hecho de ser el último.

El producto final necesita una revisión separada que confirme:

• cumplimiento de la misión;

• ausencia de errores críticos;

• trazabilidad;

• declaración de limitaciones;

• utilidad para el usuario.

Tres ejemplos de aplicación

El protocolo no está diseñado exclusivamente para mapas conceptuales.

Ejemplo 1. Revisión de literatura

Misión: construir un estado del arte sobre IAgen en servicios bibliotecarios universitarios.

Agente conceptual
→ agente de búsqueda
→ agente de recuperación
→ agente documental
→ auditor
→ agente de redacción
→ auditoría final

Posibles retornos:

• Si la búsqueda omite términos bibliotecológicos, regresar al agente de búsqueda.

• Si el corpus carece de estudios empíricos, regresar a recuperación.

• Si las categorías mezclan resultados y conclusiones, regresar al agente documental.

• Si el texto atribuye causalidad sin respaldo, regresar al agente de redacción y al auditor.

Ejemplo 2. Análisis de encuestas

Misión: analizar una encuesta sobre competencias digitales y producir un dashboard.

Agente conceptual
→ agente estadístico
→ auditor
→ agente de visualización

Posibles retornos:

• Una dimensión mal definida vuelve al agente conceptual.

• Una suma de frecuencias inconsistente vuelve al agente estadístico.

• Una visualización que utiliza porcentajes sobre bases distintas vuelve al agente de visualización.

• Una contradicción entre el instrumento y el análisis activa al auditor.

Ejemplo 3. Presentación académica

Misión: transformar una tesis en una presentación de veinte diapositivas.

Agente documental
→ agente de síntesis
→ agente de presentación
→ auditor

Posibles retornos:

• Un resultado central ausente vuelve al agente documental.

• Una diapositiva saturada pero correcta vuelve al agente de presentación.

• Una cita no verificable vuelve al agente normativo.

• Una conclusión que excede la evidencia vuelve al agente de síntesis.

En todos los casos, la inteligencia del sistema no radica únicamente en distribuir tareas. Radica en reconocer el origen del error y dirigir allí la corrección.

Prueba de concepto en Proyectos de ChatGPT

La primera prueba se ejecutó en un Proyecto de ChatGPT que contenía archivos JSON correspondientes a agentes especializados, un inventario de rutas y un modelo conceptual del ecosistema.

El entorno reunía:

• agentes de conceptualización;

• agentes de búsqueda;

• agentes de análisis documental;

• agentes de evaluación;

• agentes de visualización;

• un auditor del sistema.

Los Proyectos de ChatGPT permiten concentrar instrucciones, archivos, conversaciones y contexto relacionado dentro de un espacio de trabajo persistente. Esta característica hizo posible cargar las identidades agentivas y utilizar un prompt maestro como capa de coordinación.

La misión experimental consistió en identificar, buscar y utilizar información científica para construir un mapa conceptual sobre el impacto de la IAgen en la alfabetización informacional universitaria.

La ruta inicial fue:

ConceptCraft
→ SearchMaster
→ recuperación de información
→ Matriz Builder
→ Orchestrator Auditor
→ VisualSynthesizer
→ auditoría final

La arquitectura definió:

• pregunta orientadora;

• alcance temporal;

• idiomas;

• tipos documentales;

• dimensiones iniciales;

• criterios de trazabilidad;

• máximo de iteraciones;

• errores críticos permitidos;

• condiciones de parada.

El primer fallo no ocurrió en el contenido

El prompt maestro fue guardado como Markdown y cargado en el proyecto. La respuesta inicial del sistema fue solicitar al usuario que indicara si deseaba revisar, corregir, resumir o procesar el archivo.

El entorno había interpretado el archivo como contenido documental, no como instrucción activa.

La corrección consistió en añadir un mensaje externo que señalaba expresamente:

• que el archivo contenía instrucciones operativas;

• que debía adoptarse como arquitectura de la conversación;

• que la misión debía ejecutarse inmediatamente;

• que no debía solicitarse una operación adicional;

• que la ejecución debía comenzar mostrando la ruta y los criterios de parada.

Este episodio permitió identificar cuatro capas diferentes:

Prompt maestro
→ define la arquitectura

Mensaje de activación
→ inicia el sistema

Misión
→ proporciona el objetivo

Entradas
→ inicializan el estado

La distinción es relevante para cualquier persona que intente implementar el protocolo. Un diseño correcto puede no activarse si el entorno interpreta sus instrucciones como material de referencia.

El papel de ChatGPT en el proceso

ChatGPT intervino en tres niveles:

1. Conceptualización asistida: ayudó a comparar la orquestación multiagente previa con el concepto emergente de loop engineering.

2. Co-diseño: colaboró en la formalización del estado, las reglas de retorno, la rúbrica y las condiciones de parada.

3. Ejecución contextual: interpretó la arquitectura y produjo las versiones del artefacto dentro del Proyecto.

La arquitectura del ecosistema, los archivos de agentes, la organización mediante el ciclo de la información, la misión experimental y las decisiones de aceptación fueron dirigidas por mí, Julián Arturo Castillo Velásquez. ChatGPT se utilizó como herramienta de formalización y ejecución asistida.

Esta distinción resulta necesaria para conservar la trazabilidad de la autoría y evitar presentar el resultado como una creación autónoma del sistema.

¿Cómo reconocer un bucle funcional?

No toda respuesta que mencione auditorías e iteraciones demuestra que exista un bucle.

Un bucle ceremonial ocurre cuando el sistema afirma que revisó y mejoró un producto, pero no puede mostrar:

• qué error encontró;

• qué agente debía corregirlo;

• qué instrucción cambió;

• qué diferencia existe entre versiones;

• por qué se detuvo.

Un bucle funcional necesita al menos siete evidencias:

1. producto inicial;

2. error específico;

3. diagnóstico;

4. agente de retorno;

5. instrucción correctiva;

6. cambio observable;

7. nueva decisión de aceptación o retorno.

El registro puede adoptar esta forma:

Iteración	Error	Retorno	Cambio	Decisión
1	Afirmación absoluta sin evidencia suficiente	Agente conceptual	Reformulación condicional	Reauditar
2	Sin errores críticos	No aplica	Producto aceptado	Finalizar

La calidad de la evidencia no depende de incluir toda la conversación en el artículo. Puede demostrarse mediante un extracto del prompt, una tabla de transición, dos versiones comparables y el registro de parada.

El prompt completo, los archivos JSON, las salidas extensas y las auditorías pueden publicarse como materiales complementarios.

Supervisión humana: dentro, sobre y por encima del bucle

La automatización no elimina la responsabilidad humana.

El artículo anterior de Info[rage] ya destacaba los modelos Human-in-the-loop y Human-on-the-loop para mantener la autoridad epistémica en el profesional responsable del flujo. El Prompting-Loop Engineering añade una tercera perspectiva útil: la persona que diseña el sistema permanece por encima del bucle.

Human in the loop

La persona aprueba determinados productos antes de continuar.

Human on the loop

La persona supervisa la ejecución e interviene ante desviaciones.

Human over the loop

La persona define:

• misión;

• agentes;

• herramientas;

• límites;

• criterios de aceptación;

• autoridad para detener el proceso.

En investigación, esta supervisión no es un detalle opcional. La selección de evidencia, la interpretación de resultados y la formulación de conclusiones implican decisiones epistemológicas que no deben delegarse por completo.

En las bibliotecas, donde la mediación de información ha estado vinculada históricamente con la selección, organización, acceso, evaluación y uso responsable de fuentes, la ingeniería de bucles puede entenderse como una extensión técnica de una práctica ya conocida:

no basta con recuperar información; es necesario verificar su pertinencia, procedencia y capacidad para responder a una necesidad concreta.

Límites y precauciones

El Prompting-Loop Engineering no-code presenta varias limitaciones.

Los agentes pueden no ser procesos independientes

En un Proyecto de ChatGPT, distintos archivos pueden representar identidades y funciones especializadas, pero la ejecución puede seguir dependiendo del mismo modelo subyacente y de una ventana contextual compartida.

Por ello, resulta más preciso hablar de orquestación semántica o contextual que de una arquitectura distribuida equivalente a un framework programado.

El evaluador puede compartir sesgos con el generador

Si el mismo modelo produce y audita, la revisión no es completamente independiente. Un agente auditor reduce algunos errores, pero no constituye una garantía objetiva.

Las puntuaciones son orientativas

Un valor como 0,85 puede ayudar a regular el flujo, pero carece de sentido si no se acompaña de criterios observables.

La memoria es contextual

Los Proyectos pueden conservar conversaciones, archivos e instrucciones, pero el comportamiento final continúa sujeto a las capacidades, límites y configuración del producto.

Los bucles consumen recursos

Cada nueva ejecución utiliza contexto y capacidad de procesamiento. Un sistema mal diseñado puede repetir tareas sin producir mejoras.

La reproducción exacta no está garantizada

Los modelos generativos son probabilísticos. La misma arquitectura puede producir variaciones entre ejecuciones.

El sistema no debe inventar acciones

Si una herramienta no está disponible, el orquestador debe declararlo. No puede afirmar que buscó una base, procesó un archivo o ejecutó un agente externo si esas acciones no ocurrieron.

Materiales para documentar una prueba

Una implementación reproducible debería conservar:

01_prompt_maestro.md
02_mensaje_activacion.md
03_mision.md
04_inventario_agentes.json
05_estado_inicial.json
06_producto_version_1.md
07_auditoria_iteracion_1.json
08_instruccion_retorno.md
09_producto_version_2.md
10_auditoria_final.json
11_registro_ejecucion.csv
12_limitaciones.md

El artículo principal puede incluir solo:

• la arquitectura reducida;

• una tabla de agentes;

• un diagrama del bucle;

• un ejemplo de retorno;

• una comparación entre versiones;

• la razón de parada.

La evidencia completa puede alojarse en un repositorio o paquete descargable.

De coordinar agentes a gobernar sus resultados

La orquestación multiagente no-code permite distribuir una misión entre especialistas artificiales. El Prompting-Loop Engineering añade una capa de control sobre esa distribución.

La orquestación responde:

¿Qué agente debe actuar y en qué orden?

El Prompting-Loop Engineering añade:

¿Debe aceptarse su salida?¿Qué error contiene?¿Quién puede corregirlo?¿Qué debe cambiar?¿Cuándo debe terminar el proceso?

Esta evolución transforma una secuencia de agentes en una arquitectura que utiliza la evaluación como parte del flujo.

No se trata de esperar que la IA produzca una respuesta perfecta. Se trata de diseñar un sistema en el que los errores puedan convertirse en señales operativas. El Prompting-Loop Engineering no reemplaza los frameworks programados ni ofrece el mismo grado de control técnico. Su aporte se encuentra en otro lugar: reduce la barrera de entrada para experimentar con estados, auditorías, retornos y condiciones de parada dentro de entornos conversacionales que ya admiten archivos, instrucciones y memoria de proyecto.

Para investigadores, profesionales de la información y equipos que gestionan grandes volúmenes documentales, esta posibilidad abre una vía práctica. Los mismos entornos utilizados para reunir literatura, matrices, agentes y productos pueden convertirse en espacios de ejecución iterativa, siempre que sus reglas estén claramente declaradas y la supervisión humana permanezca activa.

El artículo anterior mostró cómo condensar agentes dentro de un proyecto y hacerlos trabajar en conjunto. Esta nueva propuesta incorpora el paso que faltaba: conseguir que el sistema revise lo producido, regrese al origen de los errores y avance únicamente cuando existan condiciones suficientes para hacerlo.

En síntesis:

Una cadena entrega.
Un bucle comprueba.
Un sistema bien diseñado sabe cuándo regresar y cuándo detenerse.

Declaración sobre el uso de inteligencia artificial

Este artículo fue concebido y dirigido por Julián Arturo Castillo Velásquez, bibliotecólogo y CEO de Info[rage], a partir de su arquitectura previa de orquestación multiagente no-code y de su ecosistema de agentes organizado mediante el ciclo de la información. ChatGPT se utilizó como herramienta de co-diseño para reconstruir la prueba de ejecución. La selección conceptual, la orientación metodológica, la revisión y la aprobación del contenido permanecieron bajo supervisión humana.

Referencias

Info[rage]. (2026, 13 de abril). La orquestación de sistemas multiagente no-code en la inteligencia artificial. Info[rage].

OpenAI. (2026, 10 de abril). Uso de proyectos en ChatGPT. OpenAI Academy.

OpenAI. (s. f.). Proyectos en ChatGPT. OpenAI Help Center.

Pastor, J. (2026, 29 de junio). La moda del prompt engineering ya pasó. Ahora lo que se lleva es el loop engineering. Xataka.

Macedo, S. (2026). Stop hand-holding your coding agent: Engineering the loops that replace step-by-step prompting (Versión 1). arXiv. https://doi.org/10.48550/arXiv.2607.00038

Runkle, S. (2026, junio 16). The art of loop engineering. LangChain Blog. https://www.langchain.com/blog/the-art-of-loop-engineering