DEV Community: Francisco

De bloquear a autocorregir: una demo práctica de guardrails para agentes de IA con Laravel, Grok y OpenSpec

Francisco — Fri, 01 May 2026 23:30:15 +0000

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.

Artículo original:

https://dev.to/aws-espanol/guardrails-para-agentes-de-ia-que-se-autocorrigen-en-lugar-de-bloquear-3n32

Quise llevar esa idea a una demo práctica usando tecnologías que manejo más en mi día a día:

Laravel
Laravel AI SDK
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 + Laravel AI SDK + 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
Laravel AI SDK
AppointmentIntentAgent
LaravelAiAppointmentAgent
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.
`LaravelAiAppointmentAgent`	Servicio wrapper que invoca el agente creado con Laravel AI SDK.
`AppointmentIntentAgent`	Agente estructurado que convierte lenguaje natural en un payload de cita.
`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, conversaciones del SDK y auditoría.

Flujo principal

Usuario escribe una solicitud
        ↓
Frontend envía el mensaje al backend
        ↓
ChatController recibe el mensaje
        ↓
LaravelAiAppointmentAgent invoca AppointmentIntentAgent
        ↓
Laravel AI SDK usa xAI / Grok como provider
        ↓
El agente devuelve un payload estructurado
        ↓
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.

Implementación con Laravel AI SDK

Inicialmente tenía una integración directa con la API de xAI / Grok usando HTTP.

Luego migré la extracción de intención a Laravel AI SDK, para trabajar con un agente más alineado al ecosistema Laravel.

La documentación oficial indica que el SDK se instala así:

composer require laravel/ai

Luego se publican archivos de configuración, stubs y migraciones:

php artisan vendor:publish --provider="Laravel\Ai\AiServiceProvider"

Y se ejecutan las migraciones:

php artisan migrate

En mi caso, esto creó la tabla usada por el SDK para conversaciones de agentes:

agent_conversations

Después generé un agente estructurado:

php artisan make:agent AppointmentIntentAgent --structured

El objetivo de este agente es claro: extraer intención, no validar reglas de negocio.

Ejemplo conceptual:

$response = (new AppointmentIntentAgent)->prompt(
    'Quiero una cita mañana a las 8pm para 3 personas'
);

La respuesta esperada es un payload estructurado:

[
    "service" => "consulta_general",
    "date" => "2026-05-03",
    "time" => "20:00",
    "people" => 3,
]

Para mantener el controller limpio, creé un servicio wrapper:

class LaravelAiAppointmentAgent
{
    public function extractPayload(string $message): array
    {
        $response = (new AppointmentIntentAgent)->prompt($message);

        return [
            'service' => $response['service'] ?? 'consulta_general',
            'date' => $response['date'] ?? null,
            'time' => $response['time'] ?? null,
            'people' => (int) ($response['people'] ?? 1),
        ];
    }
}

Así el flujo queda más ordenado:

ChatController
        ↓
LaravelAiAppointmentAgent
        ↓
AppointmentIntentAgent
        ↓
Laravel AI SDK
        ↓
xAI / Grok
        ↓
Payload estructurado
        ↓
GuardrailEngine

La IA no decide si la cita es válida. Solo transforma lenguaje natural en datos estructurados.

La validación queda en el GuardrailEngine.

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

El agente estructurado con Laravel AI SDK genera:

{
  "service": "consulta_general",
  "date": "2026-05-03",
  "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 proveedor del modelo usado por Laravel AI SDK.

Antes lo estaba llamando directamente por HTTP. Ahora el flujo pasa por un agente estructurado:

Laravel AI SDK
        ↓
AppointmentIntentAgent
        ↓
xAI / Grok

Su trabajo es convertir lenguaje natural en un payload estructurado.

Usuario:

Quiero una cita mañana a las 8pm para 3 personas

El agente devuelve:

{
  "service": "consulta_general",
  "date": "2026-05-03",
  "time": "20:00",
  "people": 3
}

Pero Grok no decide si eso se puede ejecutar.

Esa responsabilidad queda en el GuardrailEngine.

Laravel AI SDK estructura.
Grok interpreta.
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
↓
LaravelAiAppointmentAgent
↓
AppointmentIntentAgent
↓
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:

Laravel AI SDK genera un payload estructurado.
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.

También me gustó mucho trabajar con Laravel AI SDK porque permite encapsular la interacción con el modelo en clases de agentes. Eso hace que el código sea más mantenible y más cercano a cómo normalmente organizamos responsabilidades en Laravel.

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
↓
Laravel AI SDK invoca el agente
↓
IA interpreta y genera payload
↓
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
Laravel AI SDK
Vue frontend
Docker Compose
MySQL
GuardrailEngine
Integración con xAI / Grok
OpenSpec con proposal, design, tasks y specs

Referencias

Artículo base:

Guardrails para Agentes de IA que se Autocorrigen en Lugar de Bloquear — Elizabeth Fuentes L, AWS Español.

https://dev.to/aws-espanol/guardrails-para-agentes-de-ia-que-se-autocorrigen-en-lugar-de-bloquear-3n32

Documentación relacionada:

Laravel AI SDK

https://laravel.com/docs/13.x/ai-sdk

Laravel

https://laravel.com/

xAI / Grok API

https://docs.x.ai/

OpenSpec

https://openspec.dev/

Automatización de Publicaciones en LinkedIn con Make - Segunda Parte

Francisco — Sat, 22 Feb 2025 08:20:12 +0000

Dando seguimiento al artículo Automatización de publicaciones en LinkedIn parte 1, donde exploramos la creación de una cuenta en el servicio Make y la configuración de Google Sheets (GS), en esta segunda parte profundizaremos en la integración con los servicios de Perplexity, OpenAI y LinkedIn. Además, compartiré algunas recomendaciones clave para optimizar el proceso.

Módulo de Perplexity

Utilizaremos el módulo de Perplexity para realizar búsquedas en Internet a partir de la URL extraída del paso anterior.

Para ello, será necesario crear una cuenta. Una vez creada, será imprescindible adquirir créditos; el mínimo disponible es de $3.

Después de obtener los créditos, se requiere generar una clave API para vincular el servicio con Make. Esto solo será necesario una vez, a menos que deseemos separar los proyectos con diferentes claves API.

Generar API

Colocar la clave API generada

Nota: Esto también será necesario para utilizar OpenAI.

El consumo de tokens dependerá del modelo utilizado. En este caso, estoy empleando llama-3.1-sonar-small-128k-online. Si deseas consultar los modelos disponibles, puedes revisar el siguiente enlace.

Para procesar el texto del enlace, se define un límite máximo de tokens a gastar. El prompt utilizado es:

**Necesito que me resumas el siguiente artículo en español: {{1.0}}**

Donde {{1.0}} es el parámetro de salida del módulo trigger en el paso anterior. 0 representa la columna A de la hoja de GS.

Datos de entrada

Hasta el momento, he realizado aproximadamente entre 15 y 20 ejecuciones (~30,000 tokens) con un costo total de solo $0.08. Para más detalles sobre precios, consulta aquí.

Datos de salida importantes

Uso de tokens:
- Prompt Tokens (49): Tokens utilizados en la entrada (prompt enviado).
- Terminación Tokens (759): Tokens generados en la respuesta.
- Total Tokens (808): Suma de los tokens utilizados en la entrada y en la respuesta.
Contenido: Contiene el resumen y traducción del artículo procesado.

Módulo de OpenAI

Usaremos el módulo de OpenAI para la redacción automatizada de publicaciones.

Para comenzar, es necesario crear una cuenta y adquirir créditos. En este caso, la inversión mínima fue de $10, pero el consumo por generación de contenido es bastante bajo (~$0.01 por artículo).

Luego, se debe generar una clave API para conectar el servicio con Make. La primera vez será necesario crear un proyecto y posteriormente generar la clave API.

Generar API y ubicar el Organization ID

Colocar la clave API y Organization ID

Definir el contenido del prompt en el módulo de OpenAI:

**Actúa como un gerente de redes sociales y genera una publicación de LinkedIn. La publicación debe involucrar a la audiencia con una introducción atractiva, proporcionar detalles esenciales y fomentar la interacción a través de 'me gusta', comentarios y compartidos. Termina con un llamado a la acción claro y al final coloca la fuente. Incluye hashtags opcionales [#Hashtag1, #Hashtag2]. Aquí hay un resumen del artículo que quiero que readaptes: {{4.choices[].message.content}}** .

Nota: El prompt puede ser ajustado según las necesidades específicas del usuario.

Resultado de ejecución:

Módulo de LinkedIn

Para automatizar la publicación en LinkedIn, utilizaremos el módulo correspondiente en Make.

Pasos a seguir:

Añadir conexión de LinkedIn.
Seleccionar el tipo de conexión.
Asignar un nombre a la conexión.
Guardar y autenticarse en LinkedIn.
Conceder permisos a Make.
Configurar el texto de la publicación, seleccionando la salida del módulo OpenAI {{7.choices[].message.content}}.
Ajustar la visibilidad de la publicación (pública).
Ejecutar el flujo.

Una vez completado el proceso, la publicación en LinkedIn tendrá el siguiente formato:

Conclusión

Esta segunda parte del proceso de automatización de publicaciones en LinkedIn demuestra cómo herramientas como Make pueden simplificar y optimizar la creación de contenido en redes sociales. La plataforma es bastante intuitiva, aunque la integración con algunos servicios, como Google Suite, puede requerir configuraciones adicionales que pueden ser algo complejas debido a la documentación desactualizada.

Me ha gustado la amplia variedad de servicios que Make ofrece incluso en su plan gratuito, lo que lo convierte en una opción viable para diferentes niveles de automatización. En futuras actualizaciones, planeo mejorar el flujo de trabajo incluyendo la generación de imágenes adjuntas a las publicaciones y explorando la posibilidad de agregar un paso de aprobación antes de la publicación final.

Automatización de Publicaciones en LinkedIn con Make - Primera Parte

Francisco — Sun, 19 Jan 2025 15:00:00 +0000

Problema que queremos resolver: Ahorro de tiempo en la gestión de publicaciones en LinkedIn

Para profesionales, emprendedores y empresas, LinkedIn es una plataforma esencial para compartir contenido, interactuar con su red y fortalecer su presencia en línea. Sin embargo, la gestión manual de publicaciones puede ser un desafío, especialmente cuando se busca mantener consistencia y optimizar el alcance.

¿El problema principal?

Falta de tiempo para programar publicaciones manualmente.
Inconsistencia en el calendario de publicaciones.
Dificultad para centralizar procesos en una sola herramienta.

Aquí es donde Make (anteriormente Integromat) se convierte en una solución poderosa al automatizar la creación y publicación de contenido en LinkedIn.

Make

Para resolver el problema que queremos abordar, utilizaremos la suscripción gratuita, ya que permite tener hasta 2 escenarios activos.

Imagen tomada en enero 2025 - https://www.make.com/en/pricing

Componentes base

Escenario: un escenario es el espacio donde se crea y gestiona un flujo de trabajo automatizado. Es el "proyecto" que contiene todas las conexiones y configuraciones necesarias para resolver un problema o automatizar una tarea.
Flujo: el flujo es el conjunto de acciones y procesos que ocurren dentro de un escenario, desde el inicio hasta el final. Es el camino que los datos recorren para completar una tarea.
Módulos: son las "piezas" que componen un flujo dentro del escenario. Cada módulo realiza una acción específica, como obtener datos, procesarlos, aplicar condiciones o enviarlos a otro servicio.
Módulo Trigger (Disparador): el módulo inicial que activa el flujo. Ejemplo: "Watch New Rows" en Google Sheets.
Módulo de Procesamiento: Transforman o filtran los datos a medida que avanzan. Ejemplo: Formatear texto o aplicar cálculos.
Módulo de Acción (Salida): Envía datos al destino final. Ejemplo: Publicar en LinkedIn.
Conexiones: son los vínculos entre los módulos y los servicios externos. Representan la autorización o autenticación necesaria para que Make pueda interactuar con servicios como Google Drive, LinkedIn o OpenAI.

Requerimientos principales

Como requerimientos principales, necesitaremos:

Una cuenta de Gmail para utilizar Google Drive y Google Sheets.
Una cuenta de LinkedIn para registrar los posts.
Perplexity y OpenAI (Token) para generar el contenido final del post.

Nota:
Make ofrece variedad de servicios a los cuales podemos utilizar los requerimientos anteriores no son las únicas opciones disponibles pero para efectos de esta serie de post estaremos utilizando esos.

Pasos

1. Crear un escenario nuevo

Make trabaja principalmente con escenarios, donde se crea el flujo. En estos escenarios es posible agrupar o guardar diferentes flujos dentro de carpetas.

2. Configurar módulos

Los escenarios se construyen con 2 o más módulos, que representan los servicios disponibles en Make.

El punto inicial, conocido como módulo disparador (trigger), tiene funciones especiales para iniciar el flujo. Para este proyecto, utilizaremos el servicio Google Sheets (GS), que contiene una hoja con los enlaces que serán procesados por el escenario.

Módulo Trigger: Google Sheets

El módulo disparador (trigger) se activa cuando se añade un nuevo registro en el archivo que deseamos observar.

Configuración inicial:

Vincula o selecciona una cuenta de Google que tenga el archivo a utilizar.
Selecciona el método de búsqueda del archivo:
- Buscar por ruta: Navega hasta el archivo.
- Buscar en todo: Busca en todas las carpetas del Drive.
- Colocar manualmente: Proporciona la URL generada por Google Sheets.
Selecciona el tipo de Drive:
- Mi Drive.
- Compartidos conmigo.
- Google Shared Drive (disponible en planes Business y Enterprise).

Configuración final:

Selecciona el archivo mediante la navegación (en este caso, “Buscar por ruta”).
Indica el nombre de la hoja donde se encuentran los datos a procesar.
Configura los detalles:
- Si la tabla tiene cabecera.
- Desde qué columna inicia y termina la cabecera.
- El límite de registros que se analizarán en cada ejecución.
Ejecuta el flujo manualmente la primera vez para obtener los parámetros de salida necesarios para los siguientes módulos.

De la salida del módulo, lo más relevante será el enlace obtenido:

Configuraciones adicionales

El escenario puede programarse para ejecutarse de manera automática en diferentes horarios. Esto se realiza configurando el ícono del reloj en el módulo disparador.

Opciones de programación:

A intervalos regulares (cada X minutos).
Una vez (por ejemplo: '18/01/2025 23:47').
Todos los días (a una hora específica).
Días de la semana (puedes elegir uno o más días y horas específicas).
Días del mes.
En fechas específicas.
A demanda (útil para pruebas).

Próximos pasos

En publicaciones futuras, profundizare en las configuración de los siguientes elementos clave para completar el flujo de automatización:

Perplexity: Cómo configurar este servicio para generar ideas o información relevante que pueda incluirse en los posts.
OpenAI: Detalles sobre la generación de contenido con un token personalizado y cómo integrarlo en Make.
LinkedIn: La configuración específica para publicar automáticamente el contenido generado en tu perfil .

*¡No te pierdas estas guías para completar la automatización y maximizar tu presencia en LinkedIn!
*

Taller Kinesis Data Firehose y S3

Francisco — Sun, 19 Feb 2023 04:36:58 +0000


Arquitectura del Taller de Python + Kinesis Firehose + S3

En este taller, aprenderemos cómo procesar archivos CSV con AWS utilizando Kinesis Data Firehose y S3. Además, utilizaremos Python como fuente de datos desde una maquina externa para enviar los datos al flujo de Firehose.

Requisitos previos:

Una cuenta de AWS con acceso a Kinesis Data Firehose y S3.
Python 3.x instalado en local.
Tener instalada la liberias boto3 y pandas

Paso 1: Configurar el bucket de S3

Lo primero que debemos hacer es crear un bucket de S3 donde almacenaremos nuestros datos. Para hacer esto, vamos a la consola de AWS y seleccionamos S3. Luego, hacemos clic en el botón "Crear bucket" y seguimos las instrucciones para nombrar el bucket y establecer las opciones de configuración.

Paso 2: Configurar el flujo de Kinesis Data Firehose

A continuación, creamos un flujo de Kinesis Data Firehose que recibirá los datos de nuestra fuente de datos y los almacenará en nuestro bucket de S3. Para hacer esto, vamos a la consola de AWS y seleccionamos Kinesis Data Firehose. Luego, hacemos clic en "Crear flujo de Firehose" y seguimos las instrucciones para nombrar nuestro flujo y establecer las opciones de configuración.

Para la opciones de configuración:

Seleccionaremos en origen como Direct PUT
Destino S3
Nombre de la secuencia de entrada cualquier nombre para el ejemplo colocare taller1-csv. El nombre que se coloque se convertira en el identificacion del servicio el cual recibira la trama que enviemos mas adelante.
Prefijo de bucket de S3
data/input/firehose/movie/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/
Prefijo de salida de error de bucket S3
data/input/firehose/error

Los prefijos crear las carpetas necesarias de no existir al momento de recibir la trama o caer en error.

Tamaño del búfer 1 MiB (datos)
Intervalo de almacenamiento en el búfer 60 segundos

Para las configuraciones del búfer para que la trama sea procesada debe cumplir cualquiera de las dos opciones el tamaño o el intervalo

Paso 3: Configurar la fuente de datos

Antes de configurar la fuente de datos requerimosPara poder conectarnos a servicio de AWS desde una maquina externa necesitaremos crear una clave de acceso para esto se debe realizar los siguientes pasos:

Haz clic en tu nombre de usuario en la esquina superior derecha de la página y selecciona "My Security Credentials" (Mis credenciales de seguridad).
Si se te solicita, ingresa tu nombre de usuario y contraseña de AWS nuevamente.
En la pestaña "Access keys" (Claves de acceso), haz clic en "Create New Access Key" (Crear nueva clave de acceso).
Haz clic en el botón "Download Key File" (Descargar archivo de clave) para descargar la clave de acceso en un archivo .csv. También puedes copiar y pegar la clave de acceso y la clave secreta en un lugar seguro.
Asegúrate de guardar el archivo de la clave de acceso de manera segura, ya que no se mostrará nuevamente. Si pierdes la clave de acceso, deberás crear una nueva.

Una vez que hemos creada la clave de acceso y nuestro flujo de Kinesis Data Firehose, debemos configurar la fuente de datos para que sepa de dónde tomar los datos. En este caso, utilizaremos Python como fuente de datos. Para hacer esto, escribiremos un script Python que lea los datos del archivo CSV y los envíe al flujo de Kinesis Data Firehose utilizando la biblioteca Boto3 de AWS para interactuar con los servicios de AWS desde nuestro código Python.

import boto3
import time
import json
import pandas as pd

AWS_ACCESS_KEY = #credenciales
AWS_SECRET_KEY = #credenciales
REGION_NAME = #Region

DeliveryStreamName = 'taller1-csv' #paso 2
firehose = boto3.client('firehose',aws_access_key_id=AWS_ACCESS_KEY,
    aws_secret_access_key=AWS_SECRET_KEY,
    region_name=REGION_NAME
)


record = {}
bad_lines = []
column_names = ["MovieID", "YearOfRelease", "Title" ]
df = pd.read_csv("movie_titles.csv",  encoding = "ISO-8859-1" , names=column_names , error_bad_lines=False)
for index, row in df.iterrows():
 record = {'MovieID':row[0],
    'YearOfRelease':row[1],
    'Title':row[2] 
    }
 response = firehose.put_record(
        DeliveryStreamName = DeliveryStreamName,
        Record = {
            'Data': json.dumps(record)
        }
    )      
print('Dato de movie enviado a Kinesis Data Firehose : \n' + str(record))
time.sleep(.5)

Paso 4: Enviar los datos al flujo de Kinesis Data Firehose
Ahora, podemos ejecutar nuestro script Python y enviar los datos al flujo de Kinesis Data Firehose. Los datos serán transformados y almacenados en nuestro bucket de S3 según las configuraciones establecidas en los pasos anteriores.

Paso 5: Verificar los datos almacenados en S3
Finalmente, podemos verificar que nuestros datos se han almacenado correctamente en nuestro bucket de S3. Podemos acceder a nuestro bucket desde la consola de AWS y verificar que el archivo CSV se ha transformado en el formato deseado.

Conclusión
En este taller, hemos aprendido cómo procesar archivos CSV utilizando AWS con Kinesis Data Firehose y S3. Además, hemos utilizado Python como fuente de datos para enviar los datos al flujo de Firehose. AWS ofrece una amplia gama de servicios y herramientas para procesar y analizar datos, lo que hace que sea fácil y escalable trabajar con grandes volúmenes de datos en la nube.

** Despligue con Cloudformation**

Description: Stack Lab Firehose
Parameters:
  NombreBucket:
    Description: bucketS3
    Type: String
    Default: aws-firehose
Resources:
  deliverystream:
    DependsOn:
      - deliveryPolicy
    Type: AWS::KinesisFirehose::DeliveryStream
    Properties:
      DeliveryStreamName: taller1-csv
      ExtendedS3DestinationConfiguration:
        BucketARN: !Join 
          - ''
          - - 'arn:aws:s3:::'
            - !Ref s3bucket
        BufferingHints:
          IntervalInSeconds: '60'
          SizeInMBs: '1'
        CompressionFormat: UNCOMPRESSED
        Prefix: data/input/firehose/movie/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/
        ErrorOutputPrefix: data/input/firehose/error
        RoleARN: !GetAtt deliveryRole.Arn
  s3bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Join [ -, [ !Ref NombreBucket, !Ref AWS::AccountId , 'movie' ] ]
  deliveryRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Sid: ''
            Effect: Allow
            Principal:
              Service: firehose.amazonaws.com
            Action: 'sts:AssumeRole'
            Condition:
              StringEquals:
                'sts:ExternalId': !Ref 'AWS::AccountId'
  deliveryPolicy:
    Type: AWS::IAM::Policy
    Properties:
      PolicyName: firehose_delivery_policy
      PolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Action:
              - 's3:AbortMultipartUpload'
              - 's3:GetBucketLocation'
              - 's3:GetObject'
              - 's3:ListBucket'
              - 's3:ListBucketMultipartUploads'
              - 's3:PutObject'
            Resource:
              - !Join 
                - ''
                - - 'arn:aws:s3:::'
                  - !Ref s3bucket
              - !Join 
                - ''
                - - 'arn:aws:s3:::'
                  - !Ref s3bucket
                  - '*'
      Roles:
        - !Ref deliveryRole

DEV Community: Francisco

De bloquear a autocorregir: una demo práctica de guardrails para agentes de IA con Laravel, Grok y OpenSpec

Introducción

El problema

Qué construí

Arquitectura de la demo

Responsabilidades por componente

Flujo principal

Flujo de administración

Implementación con Laravel AI SDK

Decisiones del guardrail

ALLOW

STEER

BLOCK

Ejemplo de STEER

Ejemplo de BLOCK

Reglas configurables desde el frontadmin

¿Dónde entra Grok?

¿Dónde entra OpenSpec?

Diferencia con Agent Control y Strands

Casos probados

Lo que aprendí

Conclusión

Código fuente

Referencias

Automatización de Publicaciones en LinkedIn con Make - Segunda Parte

Módulo de Perplexity

Módulo de OpenAI

Módulo de LinkedIn

Conclusión

Automatización de Publicaciones en LinkedIn con Make - Primera Parte

Problema que queremos resolver: Ahorro de tiempo en la gestión de publicaciones en LinkedIn

¿El problema principal?

Make

Requerimientos principales

Pasos

1. Crear un escenario nuevo

2. Configurar módulos

Módulo Trigger: Google Sheets

Configuraciones adicionales

Próximos pasos

Taller Kinesis Data Firehose y S3

`ALLOW`

`STEER`

`BLOCK`

Ejemplo de `STEER`

Ejemplo de `BLOCK`