<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Workflows on The lost reference</title><link>https://blog.santiagoporras.com/tags/workflows/</link><description>Recent content in Workflows on The lost reference</description><generator>Hugo</generator><language>es</language><lastBuildDate>Mon, 02 Nov 2026 14:00:00 +0100</lastBuildDate><atom:link href="https://blog.santiagoporras.com/tags/workflows/index.xml" rel="self" type="application/rss+xml"/><item><title>No construyas un agente cuando un workflow es suficiente</title><link>https://blog.santiagoporras.com/no-construyas-un-agente-cuando-un-workflow-es-suficiente/</link><pubDate>Mon, 02 Nov 2026 14:00:00 +0100</pubDate><guid>https://blog.santiagoporras.com/no-construyas-un-agente-cuando-un-workflow-es-suficiente/</guid><description>&lt;p&gt;Te piden automatizar la gestión de devoluciones. La primera propuesta suele sonar muy bien en una demo: «Dale un agente acceso al correo, al sistema de pedidos y a la API de reembolsos. Que lea la solicitud y resuelva el caso».&lt;/p&gt;
&lt;p&gt;También puede salir bien. Hasta que el agente interpreta mal una política, encuentra dos pedidos parecidos y devuelve el dinero del equivocado. La pregunta importante no es si podemos construir ese agente. Es si necesitamos darle tanta libertad para resolver el problema.&lt;/p&gt;</description></item></channel></rss>