Material de apoyo del encuentro, para volver sobre el criterio, completar el formulario y aplicarlo a una tarea concreta de tu negocio.
La herramienta que vimos hoy puede cambiar. El valor de una mejora, menos tiempo, menos errores, mejor atención, no se borra porque aparezca otra plataforma. Completá el formulario sobre un proceso tuyo. Si más adelante hay archivos, aparecen al final de esta página.
Tres ideas que quedan
La IA es una herramienta, no el objetivo. Si una fórmula de Excel resuelve el problema, agregar un modelo puede hacerlo más caro, más lento y menos predecible. Hablar de agentes no significa que todas las personas de la sala necesiten uno.
Si una regla alcanza, la regla suele ser mejor. Cada decisión que delegamos a un modelo suma flexibilidad, y también costo, tiempo de espera y chances de error. No ganamos puntos por meter más tecnología.
Un agente útil no es un chat con un prompt largo. Es software: objetivo, datos, instrucciones, herramientas, límites, pruebas y personas alrededor.
Quién define el camino
Tres modelos para pensar. No hay una frontera universal perfecta. Se combinan, y hay grados de autonomía.
Le damos información a un modelo, pedimos una tarea y recibimos una respuesta. La persona lleva el intercambio.
pedido modelo respuesta
Una secuencia definida de antemano. Nosotros diseñamos el recorrido. Puede incluir un paso de IA sin delegar qué camino tomar.
formulario planilla correo
Le damos un objetivo, contexto, instrucciones y herramientas. Dentro de lo permitido, el modelo puede decidir qué paso o herramienta usar, observar el resultado y seguir, terminar o derivar a una persona.
objetivo decidir actuar observar
El modelo, en general, no “hace” la acción por sí solo. Produce una decisión estructurada. La aplicación valida, ejecuta la herramienta y le devuelve el resultado.
Un mismo comercio alcanza para contrastar: redactar una respuesta a un cliente es chat; registrar cada consulta en una planilla es automatización; decidir qué fuente consultar según el pedido, y armar una propuesta, ya pide algo más parecido a un agente.
Anatomía
Cinco piezas. Si falta una, el sistema improvisa y difícilmente funcione como esperamos.
Objetivo
Qué resultado buscamos, de forma observable. “Ayudá con ventas” no se puede evaluar. “Prepará una propuesta con hasta tres alternativas y marcá la información faltante” sí. También hay que decir cuándo debe detenerse.
Contexto
Qué necesita saber para esta tarea: el mensaje, datos del cliente, documentos, resultados de herramientas, políticas. Aportar contexto no es entrenar el modelo. Más información no siempre ayuda: importa vigencia y fuentes. Los modelos tienen una ventana de contexto finita.
Instrucciones
Cómo debe trabajar: prioridades, tono, criterios, qué hacer si falta un dato, cuándo usar cada herramienta, cuándo escalar. Un prompt vago (“hacé lo mejor posible”) no alcanza. Las reglas críticas también necesitan controles en el sistema, no solo una frase.
Herramientas
Capacidades concretas: consultar stock, calcular un total, armar un documento, escribir en una planilla. El modelo elige la herramienta y los parámetros. La aplicación valida y ejecuta. Una herramienta debería hacer una cosa clara. Los cálculos exactos y las autorizaciones conviene resolverlos con reglas, aunque el modelo interprete el pedido.
Límites
Dónde termina su autoridad. Preparar una propuesta no es lo mismo que enviarla al cliente. El control más fuerte no es decirle “no hagas X”: es no darle esa capacidad, o exigir aprobación. Human-in-the-loop: el sistema prepara, una persona revisa, y recién entonces se ejecuta si existe esa capacidad.
RAG, retrieval-augmented generation, es ir a buscar fragmentos relevantes en nuestras fuentes y dárselos al modelo para esa tarea. No entrena el modelo. No garantiza verdad. No reemplaza documentos correctos y actualizados. Tampoco implica, siempre, una base vectorial.
Más autonomía no es más inteligencia. Suma flexibilidad ante entradas variables, y también incertidumbre, costo y superficie de error. Diseñar solo la autonomía que aporta valor, y poder observar los pasos.
¿Realmente necesito un agente?
Copiar las ventas a una planilla todos los días a las seis: probablemente una automatización. No hace falta.
Enviar el mismo recordatorio de pago cada vez que vence una cuota: una regla y una plantilla. Tampoco.
Solicitudes escritas de formas distintas, que hay que interpretar, consultar fuentes según el caso y decidir los siguientes pasos, si el resultado se puede verificar. Ahí sí es candidato.
Señales de que no conviene empezar por un agente:
- El proceso todavía no está definido ni para las personas.
- Los datos no existen o están muy desordenados.
- La tarea es una regla fija.
- El error es inaceptable y no hay forma de validar.
- El volumen no justifica la complejidad.
Con qué se construye
La plataforma es una decisión de implementación. No define qué es un agente, y esta lista no es un ranking.
- n8n permite armar flujos visuales y ver las piezas. Sirve para prototipar e ilustrar. No es la identidad tecnológica de un agente ni de FORVEX.
- Copilot Studio puede encajar en organizaciones que ya viven en el ecosistema Microsoft.
- Make cubre automatizaciones visuales de complejidad baja o media.
- Código y APIs permiten control, pruebas e integraciones que una plataforma no da. Eso no los vuelve automáticamente más seguros ni mejores. Software propio también cuesta sostenerlo.
Un problema simple puede resolverse con low-code. Uno particular, combinando plataforma y código. Uno crítico o muy específico puede justificar desarrollo a medida. La implementación correcta es la que resuelve el problema con una complejidad razonable.
Cuando el problema pide más
Un agente de demostración cabe en un flujo visual. Una implementación real a veces pide otra capa: permisos, recuperación de documentos, planillas, generación de archivos, avisos, una aplicación alrededor del modelo.
En FORVEX desarrollamos un hub de Higiene y Seguridad. El agente vive dentro de ese producto, no solo en un chat. Está desplegado y en validación: no es un caso de éxito ni un catálogo de capacidades prometidas. El salto de una demo a una solución no es agregar más prompts. Es diseñar software alrededor del modelo.
Mini glosario
- LLM
- Modelo de lenguaje. Procesa contexto y genera una salida probabilística.
- Tool
- Función externa que el agente puede invocar: buscar, calcular, escribir, consultar una API.
- RAG
- Recuperar información relevante y agregarla al contexto del modelo en el momento de la tarea.
- HITL
- Human-in-the-loop. Puntos deliberados de validación o aprobación humana.
- Guardrail
- Control para limitar acciones o salidas indeseadas. El más fuerte es no dar la capacidad, o exigir aprobación en el sistema.
- Eval
- Prueba sistemática: ¿eligió la herramienta correcta, inventó datos, escaló cuando correspondía?
- Alucinación
- Una salida plausible que no está respaldada por los datos disponibles.
- Orquestación
- La lógica que coordina modelo, herramientas, estado y flujo.
Un demo muestra que puede funcionar. Las evals ayudan a ver si funciona de manera suficientemente consistente.
Por dónde seguir
Identificá el problema, elegí la herramienta, medí el resultado. Empezá con una tarea concreta. Ampliar solo si la mejora justifica la complejidad.
El formulario reúne las siete preguntas de la actividad. Completalo sobre un proceso tuyo. Si hace falta acompañamiento, más abajo está cómo conversar con FORVEX.
Formulario
Elegí una tarea repetitiva, lenta o que genera errores. Todavía no elijas plataforma. Completalo en papel o imprimí esta página. Nada de lo que escribas se envía ni se guarda.
¿Qué problema quiero resolver?
¿Qué resultado quiero obtener?
¿Qué información necesitaría el sistema?
¿A qué herramientas tendría que acceder?
¿Qué podría hacer solo?
¿Dónde quiero que intervenga una persona?
¿Realmente necesito un agente?
Descargas
Cuando haya un archivo para bajar, va a aparecer acá. Esta página es el resumen.