Cuándo utilizar reglas, workflows o agentes

Describe el trabajo antes de elegir la herramienta

«Poner IA en el CRM» no define una tarea. «Recibir una solicitud, extraer cuatro campos y entregar un borrador que una persona pueda aprobar» sí permite diseñar un proceso. Identifica la entrada, la salida observable y quién responde por un error. Decide también qué ocurre cuando falta información. Una salida vacía con un motivo puede ser más útil que un registro aparentemente completo con datos inventados.

En esta guía utilizamos una solicitud sintética: «Soy Ana de Taller Norte. Quiero revisar nuestras campañas. Escríbeme a [email protected]». Preparar un borrador exige extraer empresa, contacto y necesidad. No exige elegir una oferta, buscar información de la empresa ni enviar un correo. Esas acciones amplían el alcance y deben justificarse por separado.

La pregunta de diseño es qué parte del trabajo admite un contrato estable. Si el origen ya proporciona nombre, email, empresa y servicio en campos separados, interpretar todo de nuevo con un modelo introduce otra fuente de error sin una necesidad demostrada.

Tres formas de organizar el proceso

Usamos la distinción de Anthropic entre workflows y agentes: en un workflow el recorrido está definido en código; un agente decide dinámicamente cómo avanzar y utilizar herramientas. Un workflow puede incluir un modelo sin convertirse por ello en un agente autónomo.

Ninguna de estas categorías es una puntuación de calidad. Una regla puede estar mal escrita y un agente puede ser adecuado para una exploración. Las alternativas del Atlas permiten comparar formas de resolver la misma tarea. En estas tareas, los pasos se pueden definir de antemano.

Un árbol de decisión aplicable

Primero, pregunta si la salida se obtiene mediante transformaciones y condiciones conocidas. Para un formulario con campos controlados, prueba la configuración de reglas. Un esquema describe claves, tipos y obligatoriedad; JSON Schema documenta cómo restringir propiedades. Esa validación no demuestra que el dato sea verdadero.

Si hay interpretación de lenguaje pero el recorrido es estable, utiliza una secuencia acotada: extracción, validación y revisión. El modelo puede proponer valores, pero no debería decidir silenciosamente qué hacer con los errores. Define rutas diferentes para «falta el email», «hay dos empresas posibles» y «la salida no cumple el esquema».

Reserva la exploración agentiva para casos donde el siguiente paso dependa de lo descubierto y no sea razonable enumerarlo previamente. Antes de introducirla, escribe una condición de terminación, un presupuesto y una lista de acciones permitidas. Si no puedes reconocer el resultado correcto, aumentar autonomía hará más difícil diagnosticar el sistema.

No todas las tareas necesitan generación

Para consultar procedimientos, empieza por recuperar fragmentos. SQLite FTS5 proporciona búsqueda de texto; el Atlas propone devolver cada resultado con documento, sección y versión. El lector puede abrir la fuente y decidir si responde a su pregunta. Esta alternativa permite descubrir problemas del corpus antes de añadir síntesis.

En campañas, separa «falta un texto obligatorio» de «la promesa contradice el briefing». Lo primero puede formularse como una regla. Lo segundo requiere una interpretación que conviene presentar como hallazgo pendiente de confirmación. No agregues ambos en un semáforo que oculte qué se comprobó.

Ejemplo de contrato editorial, no código de una automatización ejecutada:

{
  "task": "preparar_registro",
  "allowed_actions": ["extract", "validate", "queue_for_review"],
  "on_missing_data": "abstain",
  "external_writes": false
}

Compara el coste del proceso completo

La opción con menos coste por llamada puede exigir más revisión. La solución sin modelo puede necesitar más trabajo de mantenimiento cuando cambian las reglas. Compara el mismo volumen, criterio de aceptación y política de revisión en la calculadora. Introduce estimaciones identificadas hasta tener mediciones propias.

No conviertas «horas potencialmente liberadas» en ahorro de caja automático. El tiempo de revisar excepciones, mantener catálogos y resolver incidencias forma parte de la decisión operativa. Si una excepción aparece con frecuencia, puede ser mejor mejorar la entrada que añadir otra llamada a un modelo.

Qué dejar escrito antes del piloto

Prepara una página con el contrato de la tarea, dos alternativas y los casos que podrían hacerte cambiar de opción. Asigna a una persona la revisión de discrepancias. Usa el protocolo de extracción para comparar candidatos antes de conectar sistemas reales.

Conserva los resultados fallidos junto a los aceptados. Si cambias el prompt, el esquema o el modelo, registra una nueva versión. La conclusión útil puede ser «las reglas bastan para el formulario y el texto libre sigue necesitando revisión». Ese resultado ayuda a delimitar un proceso sin forzar una arquitectura más compleja.