El agente estaba razonando sobre una cadena de suministro que no podía tocar
Amazing Digital Dentures presentó una historia convincente: tomar el caos de la logística de aparatos dentales—impresiones, fabricación, pruebas, remakes—y entregarlo a un agente de IA que razone a través de flujos de trabajo multipartidistas en tiempo real. El modelo era GPT-4o. La demostración fue fluida. La startup recaudó dinero.
El fracaso no fue el modelo. Fue que el LLM no tenía manos.
El agente podía hablar sobre logística dental, podía describir qué debería hacer a continuación, pero no podía tocar realmente los sistemas que importaban: el software de gestión de laboratorio donde viven los aparatos, las APIs de mensajería que los mueven, los sistemas de gestión de prácticas dentales (Dentrix, Open Dental) donde se originan las prescripciones. Los llamaba como funciones, claro—pero esas funciones llegaban a callejones sin salida, devolvían nulos, y el agente no tenía forma de saber cuáles eran restricciones reales y cuáles eran alucinaciones.
La regla incómoda: si no posees o integras profundamente con el sistema de registro, tu agente es un chatbot con pasos adicionales. Puede razonar hermosamente sobre abstracciones. No puede comandar las operaciones reales que importan.
Restricciones poco glamorosas que la demostración nunca mostró
La logística de aparatos dentales no es un problema de razonamiento disfrazado de uno. Es un dominio donde los pequeños fracasos se componen en desperdicio, y donde el negocio ya sabe exactamente qué sale mal y con qué frecuencia.
Las tolerancias de impresión a ajuste se miden en incrementos de 0,1 mm—no tokens, no comprensión semántica. Un molde de dentadura que está desviado por medio milímetro es un remake, un retraso de dos semanas, un paciente en dolor, y un costo que el laboratorio absorbe a tasas de remake del 15–25% en un mes típico. Un agente no puede razonar su camino alrededor de la realidad dimensional. Tampoco puede un LLM. Ni debería tener que hacerlo.
Luego está la entrega multipartidista: el dentista envía impresión y prescripción; el laboratorio recibe y escanea el molde; el técnico fabrica; el mensajero recoge y envía; el dentista lo prueba; si no encaja, el laboratorio lo rehace y el ciclo se repite. Cada entrega es una transición de estado. Cada transición tiene una ventana (el dentista tiene una ventana de 7 días para probar o todo el caso corre el riesgo de expiración de preautorización de seguros). La codificación de seguros—D5110 para la dentadura, D5120 para remake—tiene ventanas de preautorización. La impresión misma es un dispositivo Clase II de la FDA que requiere seguimiento de lotes y trazabilidad. Nada de esto está en el preentrenamiento del modelo. Todo es innegociable.
Un bucle de agente generalista razonador no puede absorber estas restricciones porque no tiene un ejecutor. Puede producir "remixear el caso" pero no puede garantizar la tolerancia de 0,1 mm. Puede sugerir un mensajero pero no puede probar que el envío cumple con los requisitos de seguimiento de lotes. Alucina. El negocio falla silenciosamente hasta que un paciente se queja.
Esto es lo que el costo oculto de las operaciones manuales se ve en movimiento: alguien verificando manualmente la salida del agente porque el agente no puede ser confiado con los detalles.
Bucles de razonamiento vs. flujos de trabajo propósito-construido: cuándo gana cada uno
Hemos enviado ambos. Aquí está el marco de decisión que ahora usamos internamente.
Si tu problema tiene un espacio de estado acotado y restricciones duras—impresión recibida, escaneada, fabricada, enviada, probada, remake o cerrada—y si las transiciones son deterministas, quieres un flujo de trabajo. Los flujos de trabajo son tontos, rápidos y predecibles. Un flujo de trabajo determinista de seis pasos (recibir → escanear → fabricar → enviar → probar → decidir) cuesta aproximadamente $0,002 por ejecución, se ejecuta con latencia p95 bajo 2 segundos, y falla ruidosamente cuando algo se rompe. Sabes exactamente dónde se rompió y por qué.
Los agentes viven en planificación abierta: "dada esta información incompleta y estas 47 herramientas, averigua qué hacer." Son hermosos cuando genuinamente no sabes el camino por delante. Son caros y lentos cuando el camino está bien trillado. Un bucle de agente promediando 14 llamadas de herramientas cuesta $0,30 por ejecución, la latencia p95 se ejecuta 20–60 segundos con reintentos, y cuando falla, falla silenciosamente en medio del razonamiento. Te enteras cuando un paciente no ha escuchado del laboratorio en tres semanas.
Amazing Digital Dentures debería haber aterrizando en un flujo de trabajo con una llamada LLM estrecha para triaje—"dada esta impresión e historial de este paciente, ¿es este un caso rutinario o necesita escalada?"—no un planificador pretendiendo orquestar una cadena de suministro que no podía tocar. Cuándo construir un agente vs. un flujo de trabajo describe los compromisos con más detalle, pero la lección aquí es más simple: si puedes describir el trabajo como un diagrama de flujo, comienza con un flujo de trabajo.
Lo que la 'integración profunda' realmente se ve en código
La brecha entre un agente de demostración y uno de producción es la profundidad de integración. La mayoría de los equipos se pierden esto completamente.
La integración real significa poseer (o envolver) el sistema de registro. Para logística dental, eso es el software de gestión de laboratorio, las APIs de mensajería, las integraciones de PMS. Significa esquemas de herramientas tipificadas con claves de idempotencia—no "llamar a la API del laboratorio", sino "llamar a create_job con impression_id, dentist_id, material_spec, idempotency_key, y esperar estado 201 o 409 si el trabajo ya existe." Significa máquinas de estado impulsadas por webhook para que el agente reaccione a eventos físicos: "paquete escaneado en origen", "paquete en tránsito", "prueba completada"—no sondeo o espera a que el agente recuerde preguntar.
Significa reintentos idempotentes en 409, 429, 503 con colas de letra muerta para casos que el sistema no puede recuperar automáticamente. Significa arneses de evaluación vinculados a KPIs operacionales—tasa de remake, tiempo de respuesta, tasa de expiración de preautorización de seguros—no puntuaciones BLEU. El "agente" en sí es a menudo 200 líneas de pegamento LLM alrededor de 2.000 líneas de plomería de integración. Las 2.000 líneas es lo que separa un producto de un comunicado de prensa.
Hemos visto lo que la ingeniería de flujo de trabajo agentico realmente requería bajo el capó—los equipos redujeron el tiempo de análisis de requisitos, pero solo porque construyeron el esqueleto de integración primero, lo instrumentaron, y luego añadieron la capa de razonamiento. ¿Los equipos que pegaron razonamiento en sistemas no integrados? Todavía están depurando.
El patrón que ahora usamos antes de escribir un solo prompt
Antes de abrir un editor de texto para especificar un agente, ejecuta esta lista de verificación con tu equipo de operaciones e ingenieros en la misma sala.
Mapea cada sistema externo. Software de gestión de laboratorio: API, scrape, o nada? Mensajería: API o nada? PMS: API, webhook, o nada? Marca cuáles controlas y cuáles son la caja negra de otro. Si más de la mitad son cajas negras, detente aquí.
Enumera los modos de fallo que el negocio ya tolera. ¿Tasa de remake? ¿Retrasos en pruebas? ¿Expiraciones de preautorización de seguros? Si sucede el 3% del tiempo hoy, un agente que alucina el 5% del tiempo es una pérdida neta.
Identifica las 3–5 decisiones que realmente necesitan razonamiento. ¿Enrutar un caso complejo a un especialista? Quizás. ¿Decidir que la calidad de la impresión es aceptable? Probablemente no—eso es una verificación determinista. ¿Escanear para conformidad dimensional? Definitivamente no. La mayoría de los flujos de trabajo operacionales tienen quizás dos o tres decisiones que son genuinamente abiertas. Todo lo demás es plomería.
Construye el esqueleto del flujo de trabajo primero. Conecta los sistemas, prueba las integraciones, instrumenta para KPIs operacionales. Añade nodos LLM solo donde la lógica determinista pierde y la ventaja es clara. Dimensiona correctamente el modelo de razonamiento de tu agente con una auditoría de costos: ¿justifica el valor marginal del mejor razonamiento la latencia y el costo de tokens?
Mata el agente si no gana en los primeros 100 casos. Si un motor de reglas obtiene la decisión correcta el 94% del tiempo y tu agente la obtiene correcta el 93%, has añadido costo y latencia por nada. Envía el motor de reglas. Añade el agente más tarde si el dominio cambia.
Antes de especificar otro agente, lista cada sistema que necesita tocar y marca cuáles realmente controlas. Si más de la mitad son la caja negra de otro, estás construyendo un comunicado de prensa, no un producto. Si quieres un segundo par de ojos en ese mapa, contáctanos.