Introducción
Hace poco estuve leyendo el artículo “Guardrails para Agentes de IA que se Autocorrigen en Lugar de Bloquear”, publicado por Elizabeth Fuentes L para AWS Español.
La idea principal me pareció muy interesante: muchos guardrails tradicionales funcionan de forma binaria. Si el agente viola una regla, se bloquea la acción y el usuario tiene que intervenir. Eso es necesario en algunos casos, pero no siempre es la mejor experiencia.
El artículo plantea una alternativa: en vez de solo bloquear, podemos guiar al agente para que corrija su acción. A ese enfoque se le llama steer. El agente recibe una corrección, ajusta los parámetros y continúa el flujo.
Quise llevar esa idea a una demo práctica usando tecnologías que manejo más en mi día a día:
Laravel
Vue
Docker Compose
MySQL
Grok / xAI
OpenSpec
Importante: esta demo no implementa directamente Strands Agents ni Agent Control. Lo que hice fue tomar el patrón conceptual del artículo y llevarlo a un stack Laravel + Vue + Grok.
En lugar de usar Guide() para que el LLM reintente, implementé un GuardrailEngine que corrige el payload de forma determinística y devuelve una propuesta corregida al usuario.
El objetivo fue aprender el patrón, bajarlo a código y demostrar la idea central:
No bloquear por defecto.
Corregir cuando sea seguro.
Bloquear cuando realmente sea necesario.
El problema
Imaginemos un agente de IA para agendar citas.
Un usuario escribe:
Quiero una cita mañana a las 8pm para 3 personas
Pero el negocio tiene estas reglas:
Horario de atención: 8:00 a.m. a 6:00 p.m.
Máximo de personas por cita: 2
Duración de la cita: 30 minutos
No se pueden agendar días bloqueados
No se pueden duplicar slots ocupados
Un guardrail tradicional podría responder:
No puedo agendar esa cita.
Eso funciona, pero corta el flujo.
Una mejor experiencia sería:
No puedo agendar a las 8:00 p.m. ni para 3 personas.
Te puedo ofrecer mañana a las 5:30 p.m. para 2 personas.
¿Deseas confirmar?
Ahí es donde entra la idea de autocorrección.
Qué construí
Construí una demo funcional donde un usuario puede pedir una cita por chat.
La IA interpreta la intención, genera un payload estructurado y luego el GuardrailEngine valida las reglas del negocio.
El usuario no confirma directamente lo que la IA propone. Primero pasa por una capa de control.
También agregué un frontadmin para configurar reglas, servicios, días bloqueados y revisar logs.
En simple:
La IA entiende.
El guardrail decide.
El backend ejecuta.
El admin configura.
Arquitectura de la demo
La demo está compuesta por:
Frontend Cliente
Backend Laravel
GrokAppointmentAgent
GuardrailEngine
AppointmentController
Frontadmin
MySQL
Responsabilidades por componente
| Componente | Responsabilidad |
|---|---|
Frontend Cliente |
Permite al usuario escribir la solicitud y confirmar la cita propuesta. |
Frontadmin |
Permite configurar reglas, servicios, días bloqueados y revisar logs. |
ChatController |
Recibe el mensaje del usuario y coordina el flujo del agente. |
GrokAppointmentAgent |
Convierte lenguaje natural en un payload estructurado. |
GuardrailEngine |
Evalúa reglas y decide ALLOW, STEER o BLOCK. |
AppointmentController |
Crea la cita solo después de confirmación y validación. |
Admin Controllers |
Exponen endpoints para reglas, servicios, días bloqueados y logs. |
MySQL |
Guarda citas, reglas, servicios, días bloqueados y auditoría. |
Flujo principal
Usuario escribe una solicitud
↓
Frontend envía el mensaje al backend
↓
Grok interpreta la intención y genera un payload
↓
GuardrailEngine evalúa reglas de negocio
↓
Si es válido: ALLOW
Si es corregible: STEER
Si no puede continuar: BLOCK
↓
El usuario confirma la propuesta
↓
Laravel crea la cita en MySQL
Flujo de administración
Frontadmin
↓
Admin Controllers
↓
MySQL
↓
Reglas, servicios, días bloqueados y logs
↓
GuardrailEngine usa esas reglas en runtime
La parte importante es que las reglas no viven solamente en el prompt del agente. Se pueden cambiar desde el frontadmin y el GuardrailEngine las usa en tiempo de ejecución.
Decisiones del guardrail
Implementé tres decisiones principales:
ALLOW
La acción es válida y puede continuar.
STEER
La acción tiene errores corregibles. El sistema ajusta los datos y devuelve una propuesta corregida.
BLOCK
La acción no puede continuar porque falta información o hay una regla estricta.
Ejemplo de STEER
Entrada del usuario:
Quiero una cita mañana a las 8pm para 3 personas
Grok genera:
{
"service": "consulta_general",
"date": "2026-05-02",
"time": "20:00",
"people": 3
}
El guardrail evalúa:
20:00 está fuera del horario permitido
3 personas supera el máximo permitido
Respuesta del guardrail:
{
"decision": "STEER",
"reason": "Payload was corrected.",
"corrections": [
{
"field": "time",
"from": "20:00",
"to": "17:30:00",
"reason": "Requested time is after business hours."
},
{
"field": "people",
"from": 3,
"to": 2,
"reason": "Requested people count exceeds maximum allowed."
}
]
}
Respuesta para el usuario:
La hora solicitada no cumple las reglas. Te puedo ofrecer 17:30.
El máximo permitido es 2 persona(s).
¿Deseas confirmar esta propuesta?
Ese es el punto clave: el sistema no bloquea de inmediato, sino que corrige cuando es seguro hacerlo.
Ejemplo de BLOCK
No todo debe autocorregirse.
Si el usuario no proporciona fecha, el sistema no debe inventarla si la intención no está clara.
Payload incompleto:
{
"service": "consulta_general",
"time": "10:00",
"people": 1
}
Respuesta:
{
"decision": "BLOCK",
"reason": "Date is required."
}
Mensaje:
Necesito que me indiques la fecha para revisar disponibilidad.
Este punto también es importante: STEER no reemplaza BLOCK. Los dos se complementan.
El artículo original también lo explica así: los bloqueos son útiles para reglas estrictas, mientras que steer funciona mejor para errores corregibles como ajustar parámetros, redactar información sensible o corregir formatos.
Reglas configurables desde el frontadmin
Una parte que quise destacar fue que las reglas no estuvieran dentro del prompt.
Desde el frontadmin se pueden cambiar:
Hora inicio
Hora fin
Máximo de personas
Duración de cita
Permitir autocorrección
Servicios activos
Días bloqueados
Por ejemplo, si el admin cambia:
Hora fin: 17:00
Máximo personas: 1
El mismo mensaje:
Quiero una cita mañana a las 8pm para 3 personas
ahora se corrige a algo como:
16:30
1 persona
Esto demuestra una idea muy importante: las reglas del negocio pueden cambiar sin tocar el prompt del agente.
¿Dónde entra Grok?
Grok entra como agente de extracción de intención.
Su trabajo es convertir lenguaje natural en un payload estructurado.
Usuario:
Quiero una cita mañana a las 8pm para 3 personas
Grok devuelve:
{
"service": "consulta_general",
"date": "2026-05-02",
"time": "20:00",
"people": 3
}
Pero Grok no decide si eso se puede ejecutar.
Esa responsabilidad queda en el GuardrailEngine.
Grok propone.
Guardrail controla.
Laravel ejecuta.
Esto ayuda a separar responsabilidades y evita que el modelo sea quien tenga la última palabra sobre reglas de negocio.
¿Dónde entra OpenSpec?
Usé OpenSpec para definir el cambio antes de implementarlo.
La demo quedó documentada con:
proposal.md
design.md
tasks.md
specs/ai-guardrails/spec.md
specs/appointment-booking/spec.md
specs/admin-rules/spec.md
Esto me ayudó a mantener trazabilidad:
Requisito → Diseño → Implementación → Prueba
Por ejemplo, el requisito decía:
El sistema debe evaluar todas las acciones generadas por la IA antes de llamar al API de citas.
Y eso terminó implementado en el flujo:
ChatController
↓
GrokAppointmentAgent
↓
GuardrailEngine
↓
AppointmentController
Diferencia con Agent Control y Strands
El artículo original trabaja el concepto desde Strands Agents y Agent Control.
En ese enfoque, el agente puede recibir una instrucción correctiva mediante algo similar a Guide(). Luego el agente reintenta la acción con los parámetros corregidos.
En mi demo hice una adaptación más sencilla:
Grok genera un payload.
GuardrailEngine valida el payload.
Si es corregible, el backend devuelve corrected_payload.
El usuario confirma.
Laravel ejecuta.
Es decir, no hay un reintento automático del LLM guiado por Guide(). La corrección ocurre de forma determinística en el backend.
Aun así, el patrón conceptual se mantiene:
IA propone.
Guardrail evalúa.
Sistema corrige o bloquea.
Backend ejecuta solo si corresponde.
Casos probados
Probé estos escenarios:
ALLOW → cita válida
STEER → hora fuera de horario
STEER → demasiadas personas
STEER → día bloqueado
STEER → slot ocupado con alternativa disponible
BLOCK → falta fecha
BLOCK → servicio inválido
BLOCK → autocorrección desactivada
BLOCK → slot ocupado sin alternativa disponible
Uno de los más interesantes fue el de slot ocupado.
En lugar de bloquear inmediatamente, el guardrail busca el siguiente horario disponible.
Slot solicitado ocupado
↓
Buscar siguiente slot disponible
↓
Si existe: STEER
↓
Si no existe: BLOCK
Eso se acerca mucho a la idea del blog original: si el agente puede corregirse, no detengas el flujo.
Lo que aprendí
La principal lección fue esta:
No todo error del agente debe terminar en bloqueo.
Hay errores que se pueden corregir de forma segura:
Hora fuera de horario
Cantidad mayor al máximo
Formato incorrecto
Día bloqueado
Slot ocupado
Pero también hay casos donde el sistema debe detenerse:
Falta información crítica
Servicio no existe
No hay disponibilidad
Autocorrección desactivada
Regla estricta de negocio
La clave está en clasificar bien las reglas.
Conclusión
Esta demo me ayudó a entender mejor cómo llevar los guardrails más allá del “permitir o bloquear”.
El patrón final quedó así:
Usuario pide algo
↓
IA interpreta
↓
Guardrail evalúa
↓
ALLOW / STEER / BLOCK
↓
Usuario confirma
↓
Backend ejecuta
No es una implementación idéntica a Agent Control, pero sí aplica la misma idea central del artículo original: usar guardrails para guiar al agente cuando la corrección es segura, y bloquear solo cuando realmente es necesario.
Para mí, este enfoque tiene mucho valor en aplicaciones reales: citas, reservas, soporte, cotizaciones, DevOps, APIs internas y cualquier flujo donde una IA pueda intentar ejecutar acciones.
Lo más importante es mantener clara la separación:
La IA entiende.
El guardrail decide.
El backend ejecuta.
El admin configura.
Código fuente
El código de la demo está disponible en GitHub:
https://github.com/fmarchena/appointment-agent-demo/tree/main
En el repositorio se incluye:
Laravel API
Vue frontend
Docker Compose
MySQL
GuardrailEngine
Integración con Grok / xAI
OpenSpec con proposal, design, tasks y specs
Referencias
Artículo base:
Documentación relacionada: