Cubrir no es pagar: agendar con IA y MCP el servicio funerario que el plan sí cubre

El 14 de agosto de 2026, un desarrollador reportó públicamente un fallo de su agente de voz que vale más que cualquier advertencia genérica sobre los riesgos de la inteligencia artificial. El cliente aceptó el horario propuesto —las 11:15—, el agente respondió que estaba procediendo con la reserva, se despidió confirmando la cita… y nunca la escribió. En lugar de llamar a la función que agenda, llamó una y otra vez a la que consulta disponibilidad. El cliente colgó satisfecho. La agenda quedó vacía.

El agente no alucinó un horario. Alucinó haber escrito. Y ese es exactamente el modo de falla que en una compañía funeraria no se traduce en una cita perdida, sino en una familia esperando en la puerta de un velatorio que nadie reservó.

En casi cualquier ramo de seguros, aprobar la cobertura y liquidar son el mismo acto separado por unos días de tesorería: se determina cuánto se debe y se transfiere. El expediente se cierra cuando el dinero sale. En una compañía funeraria de Latinoamérica, aprobar la cobertura no cierra nada: la abre. Porque lo que el plan cubre no es un monto — es una sala de velación a las tres de la tarde en la sede norte, una carroza con conductor a las siete de la mañana, un turno de crematorio el martes y una misa en una capilla que solo tiene servicio ciertos días.

A eso se le llama prestación en especie: el beneficio no se entrega en dinero sino en servicio ejecutado. Y cambia por completo el problema. Un agente que liquida un siniestro en efectivo solo tiene que acertar el número. Un agente que liquida una prestación en especie tiene que acertar una hora, en una sede concreta, sobre un recurso físico que es uno solo y no se puede partir en dos. Si se equivoca, no hay un ajuste contable: hay dos familias en el mismo velatorio.

Este artículo es el caso de uso completo de ese agente, y su conclusión es más incómoda —y más útil— de lo que suele admitirse: un agente solo puede prometer una hora con la precisión con la que el sistema sabe decir que no. Si el modelo de datos no sabe detectar un choque de agenda, un agente que “verifica disponibilidad” no está verificando nada: está inventando con seguridad. Si vienes del principio de la cadena, la decisión de qué cubre exactamente el contrato y la de cómo se motiva una negativa ya están tratadas. Aquí empieza lo que pasa después del sí.

El problema: el sí que nadie puede ejecutar

El costo de este hueco no aparece en el estado de resultados con su nombre. Aparece disfrazado, y siempre tarde. Un asesor le confirma a la familia que la velación es a las dos; a las once alguien descubre que la sala está tomada y hay que llamar de vuelta a un doliente para moverle el velorio de su padre. Una carroza figuraba libre y estaba a cuarenta kilómetros terminando otro traslado. Un turno de crematorio se prometió sin saber cuántos servicios había ese día, y el cuerpo espera. Un servicio que el plan cubría se ejecutó con un proveedor externo a tarifa de urgencia, porque el recurso propio no estaba, y el margen se evaporó sin que nadie lo registre como pérdida.

Ninguna de esas cuatro cosas es un problema de inteligencia. Las cuatro son el mismo problema: alguien prometió con más precisión de la que el sistema podía sostener. Por eso la pregunta correcta antes de poner un agente a agendar no es qué modelo usar, sino una mucho más aburrida y mucho más rentable: ¿con qué exactitud sabe mi sistema negar una hora?

Lo que ya se sabe de los agentes que agendan

Antes de diseñar nada conviene mirar cómo se comportan estos agentes cuando se los mide en serio. El banco de pruebas τ-bench, que evalúa agentes conversacionales con herramientas en dominios reales, reporta que incluso los agentes de última generación resuelven menos del 50 % de las tareas, y —el dato que importa de verdad— son inconsistentes entre corridas: en el dominio de retail, la proporción de tareas resueltas correctamente en ocho intentos seguidos cae por debajo del 25 %.

La lectura para la dirección no es “no usar agentes”. Es que un agente que falla el 50 % de las veces se descarta solo en la primera semana, mientras que uno que falla a veces es más peligroso: acumula confianza durante dos meses y falla el día del servicio que no se podía fallar. De ahí sale el único diseño defendible en este sector, y es el que sostiene todo lo que sigue: el agente propone, una persona confirma, y la escritura la valida el sistema contra una restricción que puede rechazarla.

La escalera de la promesa: cinco recursos, cinco precisiones

Aquí está el hallazgo que ordena el caso, y no salió de una idea de producto sino de leer el código que hoy está corriendo. Un mismo servicio funerario toca cinco recursos escasos. El sistema modela la disponibilidad de esos cinco recursos de cinco maneras distintas, con cinco niveles de rigor distintos. Y la promesa que un agente puede hacer sobre cada uno es exactamente la que le permita su nivel — ni una más.

Léelo de arriba abajo y tienes el mapa de trabajo de los próximos dos trimestres, sin una sola mención a un modelo de lenguaje. El escalón de arriba no hay que construirlo: ya está construido y funciona. El de abajo no es un problema de IA: es un objeto que falta en la base de datos.

Por qué una bandera de “libre u ocupado” no puede sostener una promesa

Esto no es una opinión de arquitectura: está resuelto en la literatura desde 1983. El trabajo clásico de James Allen sobre razonamiento temporal establece que entre dos intervalos hay trece relaciones posibles —uno termina justo cuando empieza el otro, uno contiene al otro, se solapan por un extremo, y así—. Un campo que solo dice “ocupado” colapsa esas trece en dos. Un software que modela un recurso con una bandera no está simplificando: está eligiendo no poder responder a la pregunta que el agente necesita hacer.

La forma canónica de resolverlo tampoco es un secreto. PostgreSQL documenta el patrón con el ejemplo literal de una reserva: se guarda el rango de tiempo y se declara una restricción de exclusión que impide que dos rangos se solapen en la misma tabla. Cuando alguien intenta insertar una reserva de 14:45 a 15:45 sobre una que va de 11:30 a 15:00, el motor responde con un error de conflicto. Eso —un sistema demostrando que sabe decir que no— es el prerrequisito de cualquier promesa automática.

Y es el modelo que eligió la industria. La API de calendario más usada del mundo no expone un campo “disponible: sí/no”: su consulta de ocupación devuelve listas de intervalos ocupados, y es el cliente quien calcula los huecos invirtiéndolos. El detalle de que el fin del intervalo sea exclusivo es lo que permite encadenar una velación que termina a las 15:00 con otra que empieza a las 15:00 sin declarar colisión — que en una sede con dos salas es, literalmente, un servicio más al día.

El detalle que lo prueba: la misma misa dura 70 o 90 minutos según a quién le preguntes

Hay una forma de comprobar que el nivel 4 no es una curiosidad teórica, y está a la vista en el mismo archivo. Como las exequias no guardan hora de fin, dos funciones distintas de la misma capa de servicio tienen que inventarse cuánto dura una misa. Una, la que arma el tablero de iglesias del día, asume 70 minutos. La otra, la que arma la agenda semanal del servicio, asume 90 minutos. Mismo objeto, mismo archivo, dos duraciones.

La solución intuitiva —pedirle al asesor que capture la duración estimada— es peor de lo que parece, y hay evidencia directa. En un estudio sobre cien procedimientos con tres cirujanos experimentados, los profesionales acertaron la duración de su propia intervención apenas el 26 % de las veces: la sobreestimaron el 42 % y la subestimaron el 32 %. Es un estudio pequeño y de una sola especialidad, así que sirve como ilustración del sesgo de planificación y no como constante universal; pero la dirección del hallazgo es la que importa. Si el experto que va a ejecutar el procedimiento acierta una de cada cuatro veces, un campo de captura libre no va a arreglar nada: la duración tiene que salir de la mediana medida por sede, no del criterio de quien atiende el mostrador a las tres de la madrugada.

El eslabón que falta: la retención temporal

Hay un mecanismo que todos los sistemas serios de reserva implementan y que en la operación funeraria hoy se resuelve con un mensaje de WhatsApp y una nota adhesiva: la retención con vencimiento automático.

Funciona así. Cuando alguien está a punto de reservar, el recurso se retiene por unos minutos: nadie más puede tomarlo, y si la reserva no se confirma, la retención caduca sola. Nadie tiene que acordarse de liberar la sala. Una plataforma de agendamiento de uso masivo retiene el cupo cinco minutos por defecto mientras se completa la reserva. La especificación de reservas de Google lo formaliza como una primitiva del protocolo: crear la retención es el primer paso de una reserva, el sistema verifica que el hueco siga disponible, y la retención expira automáticamente en un momento declarado.

Sin ese mecanismo, la conversación entre el agente y la familia ocurre sobre información vencida. Entre que el agente consulta y que el coordinador confirma pasan minutos, y en esos minutos otro asesor, en otra sede, puede haber tomado la misma sala. La promesa se vuelve una afirmación sobre un pasado de treinta segundos atrás.

Qué datos del ERP intervienen

El caso se arma sobre datos que ya existen. No hay que capturar nada nuevo para empezar; hay que preguntarles de una forma que hoy nadie pregunta.

• La caracterización del servicio, que es el documento donde se compone lo que se le va a entregar a esa familia: qué incluye, en qué sede y con qué productos. Es la unidad que amarra todo lo demás, y de la que cuelgan la velación, las exequias, los traslados y las órdenes de compra.
• La velación, con sala, hora de inicio, hora de fin y estado — el único recurso del servicio con reserva de verdad.
• El traslado, con conductor, carroza, origen, destino, hora de inicio y hora de fin. Ojo con este: el dato de intervalo ya está guardado; lo que falta es que alguien lo use para detectar choques.
• Las exequias y la misa, con iglesia o capilla, sacerdote y hora, más el catálogo de días y cupos de cada capilla.
• La cremación, con fecha, hora de inicio y proveedor del crematorio.
• Las órdenes de compra del servicio, que son la pata de terceros: cuando la funeraria no ejecuta con recurso propio, el compromiso vive en una orden a un proveedor, con su porcentaje recibido. Esto sí está trazado hoy, y es la mitad del problema que casi nadie mira.
• El calendario de mantenimiento de salas, que existe — con una advertencia que importa: hoy es un punto en el tiempo sin duración, y la verificación de choque de la sala no lo consulta. Una sala en mantenimiento no está bloqueada.

Cómo se arma el caso con MCP, paso a paso

El conector MCP de SFUN es lo que permite que un agente lea el ERP con los permisos de un usuario real en lugar de contra una copia desactualizada. La secuencia que sigue es deliberadamente corta, porque la cadena larga es donde estos casos se rompen.

1. Congelar el compromiso antes de moverlo. Qué se le prometió a la familia, a qué hora, en qué sede y quién lo prometió. Sin ese punto fijo no hay forma de medir después si el agendamiento funcionó, porque la promesa se reescribe sola en la memoria de todos.
2. Preguntar disponibilidad con la precisión que cada recurso admite. Para la capilla, el agente consulta el catálogo real de cupos libres del día. Para la sala, trae el calendario de la ventana y calcula el solapamiento. Para la carroza y el crematorio, no pregunta: declara que no puede confirmar. Este es el paso donde se gana o se pierde la confianza del comité.
3. Proponer el plan completo del día, no un recurso suelto. Un servicio funerario es una cadena: recogida, tanatopraxia, velación, misa, cortejo, destino final. Proponer solo la sala y dejar el resto al azar traslada el problema treinta minutos más adelante. El agente arma la secuencia completa y marca explícitamente qué eslabones son firmes y cuáles tentativos.
4. Un humano confirma, y el sistema escribe. El agente no confirma nada a la familia. Propone; el coordinador aprueba; y el guardado pasa por la verificación dura de la sala, que actúa como última red: si algo cambió en los minutos intermedios, el sistema se niega y dice con qué choca.
5. Releer después de escribir. Nada se da por hecho sin identificador de reserva de vuelta y sin una comprobación posterior de que el recurso quedó como se pretendía. Es el control que habría evitado el fallo del agente de voz que abre este artículo.
6. Decir lo que no se puede prometer, en lugar de rellenarlo. “La cremación queda solicitada para el martes; la hora la confirma el crematorio” es una frase honesta que un agente puede emitir. “La cremación es el martes a las 10:00” es una promesa que hoy ningún dato respalda.

Lo que el agente alcanza hoy de verdad, y lo que no

Conviene ser exacto aquí, porque es donde la mayoría de los proyectos de IA se venden de más. Verificado contra el catálogo del conector el 26 de agosto de 2026:

La capacidad tiene un techo, y es más bajo de lo que parece

Hay una tentación previsible cuando la dirección empieza a ver la ocupación de sus salas en un tablero: llenarlas. Vale la pena adelantarse con un dato de una industria que lleva décadas midiendo exactamente esto. En quirófanos, el estudio clásico sobre utilización óptima concluye que una ocupación del 85 % al 90 % es la más alta que se puede alcanzar sin retrasos ni horas extra — con objetivos explícitos: que el caso empiece dentro de los quince minutos de la hora agendada y termine no más de quince minutos pasado el fin de jornada.

Pero el hallazgo que de verdad aplica a una funeraria es el segundo: a mayor variabilidad de la duración, menor es la ocupación máxima sostenible. Y una velación tiene muchísima más varianza que una cirugía programada — depende de la familia, de la hora del fallecimiento, de si viene gente de otra ciudad, de la tradición religiosa. El número que aplica a una sala de velación no es 85 %: es peor que 85 %. Eso no lo dice un proveedor de software: lo dice la relación entre varianza y capacidad, que es la misma en cualquier recurso con hora de inicio y de fin.

La consecuencia operativa es directa y contraintuitiva: una sala llena no es rentable, es impredecible. Y un agente que agenda contra un recurso saturado va a producir promesas incumplidas por mucho que su lógica sea correcta, porque el problema deja de ser de información y pasa a ser de capacidad física. Es la misma discusión que sostiene el dimensionamiento del parque de salas.

El bucle de mejora continua

Un agente que agenda no se “entrena”: se calibra contra lo que realmente pasó. El bucle es diario y cabe en quince minutos de un coordinador.

• Cada día: comparar lo prometido con lo ejecutado. Qué se movió de hora, qué se movió de sala, qué se ejecutó con un tercero por falta de recurso propio. Cada diferencia es un dato, no un regaño.
• Cada semana: revisar los choques que el sistema no atajó — los que solo se detectaron porque una persona los vio. Cada uno identifica exactamente qué recurso necesita subir un escalón en la tabla de arriba.
• Cada mes: recalibrar los márgenes con medianas medidas, no con estimaciones. Cuánto dura de verdad una velación en cada sede, cuánto tarda de verdad un traslado urbano, cuánto tiempo hay que dejar entre dos usos de la misma sala para limpieza y adecuación. Aquí es donde las constantes inventadas se van reemplazando por datos.
• Cada trimestre: decidir qué recurso sube de nivel. No los cinco a la vez: el que más reprogramaciones haya causado.

El orden importa. Medir la duración real de las cosas es lo que convierte el nivel 4 en nivel 1 sin escribir una línea de inteligencia artificial, y es también lo que hace que el cuadro de mando del grupo deje de estar construido sobre supuestos.

Gobierno y límites: qué nunca se automatiza

Este caso toca a una familia en el peor día de su vida, y por eso los límites no son una formalidad de cumplimiento: son parte del diseño. Conviene además saber que la propia especificación del protocolo MCP lo prescribe: dice que por seguridad y confianza siempre debería haber una persona en el ciclo con capacidad de denegar la invocación de una herramienta, y que el cliente debería pedir confirmación en operaciones sensibles y mostrar al usuario los datos con los que se va a llamar. La confirmación humana no es desconfianza en la IA ni un parche: es lo que el estándar prescribe. El marco general está en el gobierno de agentes de IA en el ERP funerario; estos son los límites propios de agendar.

• El agente jamás confirma a la familia. Propone al coordinador; el coordinador confirma. Una hora comunicada al doliente es un compromiso institucional, y un compromiso lo asume una persona con nombre.
• El agente jamás mueve un servicio ya confirmado. Puede detectar un conflicto y alertar; reprogramar algo que una familia ya organizó —que ya avisó a los suyos, que ya compró pasajes— no es una operación de sistema.
• Usuario propio del agente, con alcance limitado. Nunca la cuenta de una persona. Para agendar necesita leer calendarios y estados de recursos; no necesita la causa de muerte, ni el historial de salud, ni el detalle financiero del contrato. En los países con norma de protección de datos vigente, los datos del fallecido y de los deudos son categoría sensible, y la minimización aplica también a los procesos internos.
• Ninguna promesa por encima del nivel del recurso. Es la regla operativa central de este artículo y la más fácil de violar sin darse cuenta: basta con que alguien pida “que también diga la hora del crematorio”.
• Toda propuesta deja traza. Qué propuso el agente, con qué datos, quién aprobó y si el humano cambió el resultado. Esa última señal —la tasa de discrepancia entre lo propuesto y lo confirmado— es el mejor indicador temprano de que algo se está degradando.

KPIs: línea base y meta

Ninguno de estos indicadores necesita el agente para medirse. Al contrario: hay que medirlos antes, durante al menos un mes, o no habrá forma de saber si el caso sirvió.

Hoja de ruta de adopción

Lo que hoy falta en el producto, dicho sin adornos

Estas son brechas abiertas y verificadas, no funciones disponibles. Se publican como tales porque un caso de uso que oculta sus prerrequisitos no es un caso de uso: es un folleto.

• No existe el recurso “horno” de cremación. Sin un objeto contra el cual chocar, ninguna promesa de hora de cremación es verificable, ni por una persona ni por un agente. Es la brecha más grande y la más simple de enunciar.
• La carroza y el conductor se controlan con una bandera, no con una agenda. Y cuando el recurso no está libre, el sistema avisa pero deja continuar. La asimetría que lo vuelve barato de resolver: el traslado ya guarda hora de inicio y de fin; la verificación de solapamiento que hace falta ya está escrita a unos pocos archivos de distancia, para las salas.
• No hay retención temporal de ningún recurso. Ni holds, ni vencimiento automático. Mientras no exista, toda conversación con la familia ocurre sobre información que puede haber cambiado hace treinta segundos.
• Las exequias no tienen hora de fin. Mientras la duración sea una constante en el código, seguirá habiendo dos constantes distintas para el mismo objeto.
• La verificación de choque de la sala no mira el mantenimiento. Una sala programada para mantenimiento puede recibir una velación sin una sola objeción; y el propio registro de mantenimiento no tiene duración, solo un instante.
• La sala no tiene aforo. Se sabe si está libre, no si alcanza. Para un servicio con asistencia masiva, esa es la reserva que se convierte en un problema el mismo día.
• El traslado no tiene sede. Sin ella no se puede dirigir cada propuesta o cada alerta al coordinador que la resuelve, que es la única forma conocida de que un aviso se atienda en vez de acumularse.

Cinco errores que hacen fracasar este caso

• Dejar que el agente confirme a la familia. Es el único error de esta lista que empeora activamente la situación de partida: convierte un problema de coordinación interna en una promesa institucional incumplida ante un doliente.
• Prometer con más precisión que el recurso. Suele entrar por la puerta de una petición razonable —“ya que estamos, que diga también la hora del crematorio”— y termina con el comité perdiendo la confianza en todo el programa de IA por una hora que nunca existió.
• Dar por escrita una reserva porque el agente dijo que la hizo. Es el fallo documentado que abre este artículo, y se previene con una sola regla: sin identificador de reserva de vuelta y sin relectura posterior, no hay confirmación.
• Empezar por el recurso más difícil. La tentación es atacar la carroza, porque es donde más duele. Pero el caso se demuestra donde el sistema ya sabe decir que no; si empiezas donde no sabe, el primer mes produce exactamente los errores que venías a evitar.
• Medir solo la velocidad. Un agente que agenda rapidísimo y reprograma el 20 % de los servicios es peor que el proceso manual que reemplazó. El indicador principal es la promesa que se sostiene, no el tiempo hasta la primera respuesta.

Preguntas frecuentes

¿Qué es exactamente una prestación en especie en un servicio funerario?

Es el beneficio que el plan entrega en servicio ejecutado y no en dinero: la sala de velación, el traslado, el cofre, la carroza, la cremación o la inhumación. La diferencia con un reembolso no es contable sino operativa. Un reembolso se liquida cuando hay fondos; una prestación en especie se liquida cuando hay una sala libre a esa hora en esa sede. Por eso la cobertura aprobada no cierra el expediente: lo pasa de finanzas a operaciones.

¿Puede un agente de IA reservar una sala de velación por su cuenta?

Técnicamente sí, porque la sala es el único recurso con reserva firme y verificación de choque: si el agente intentara escribir sobre una sala tomada, el sistema se negaría. Pero la recomendación es que no lo haga solo. La verificación protege la integridad del dato, no la relación con la familia: evita que dos velaciones coincidan, no que se le prometa a un doliente algo que después haya que deshacer por una razón que el sistema no conoce. Y la especificación del propio protocolo MCP recomienda que una persona pueda denegar la invocación. El agente propone; una persona confirma.

¿Por qué no basta con poner todos los recursos en un calendario compartido?

Porque un calendario muestra, y lo que hace falta es que el sistema se niegue. Ver que la carroza tiene dos servicios superpuestos es útil si alguien está mirando la pantalla a esa hora; el valor real está en que el sistema no permita guardar el segundo, o al menos lo declare imposible. La diferencia entre visualizar un conflicto y bloquearlo es exactamente la diferencia entre los niveles de la escalera, y es la que determina qué puede prometer un agente sin mentir.

¿Cuánto margen hay que dejar entre dos velaciones en la misma sala?

Es una decisión de la dirección, no un parámetro técnico, y hay que tomarla explícitamente porque hoy el sistema no impone ninguno: dos velaciones pegadas al minuto se guardan sin objeción. Empieza con un número por sede basado en lo que de verdad tarda la adecuación de la sala, mídelo durante un trimestre contra los tiempos reales y recalíbralo. Un margen demasiado corto produce servicios encimados; uno demasiado largo desperdicia capacidad en las sedes que más facturan. Y no lo estimes de memoria: la evidencia sobre predicción de duraciones es que hasta los expertos aciertan poco.

¿Esto sirve si buena parte de la operación se ejecuta con terceros?

Sirve, y con un matiz importante: para los recursos de terceros la promesa nunca puede ser firme, porque la agenda no es tuya. Lo que sí cambia es la honestidad del compromiso. En lugar de prometer una hora que depende de un crematorio o una floristería, el agente propone el servicio marcando qué eslabones dependen de un tercero y deja el seguimiento de esas órdenes en un solo sitio. Esa pata sí está trazada hoy: la orden de compra queda amarrada al servicio y al fallecido, con su porcentaje recibido. El marco completo está en la recepción de facturas de proveedores y en compras e inventarios con IA y MCP.

¿Sirve en una funeraria de una sola sede?

El mecanismo sirve, pero el retorno no lo justifica igual. Con dos salas y una carroza, la coordinación ocurre de forma informal y con bastante fiabilidad: todo el mundo sabe lo que hay. El caso empieza a pagar cuando hay varias sedes, turnos que no se cruzan, terceros que ejecutan parte del servicio y un volumen en el que nadie tiene el día entero en la cabeza. Es un caso de grupo funerario, igual que la operación multiempresa.

¿Hay que cambiar el ERP para empezar?

No para empezar. El primer mes se hace entero sobre lo que ya existe: la sala tiene reserva firme, la capilla tiene disponibilidad consultable y los calendarios de velación, exequias y traslados están al alcance del conector. Lo que sí hay que decidir desde el día uno es no prometer por encima del nivel de cada recurso. Las brechas de la lista de arriba se cierran después, en el orden que dicten las reprogramaciones reales — no en el orden en que las cuenta un artículo.

Referencias

• D. C. Tyler, C. A. Pasquariello y C. H. Chen — Determining optimum operating room utilization, Anesthesia & Analgesia, 2003;96(4):1114-1121. Fuente del techo de ocupación del 85 % al 90 % sin retrasos ni horas extra, y del hallazgo de que a mayor variabilidad de la duración menor es la ocupación sostenible: doi:10.1213/01.ane.0000050561.41552.a6.
• D. M. Laskin, A. O. Abubaker y R. A. Strauss — Accuracy of predicting the duration of a surgical operation, Journal of Oral and Maxillofacial Surgery, 2013;71(2):446-447. Fuente del 26 % de acierto, 42 % de sobreestimación y 32 % de subestimación sobre 100 casos con tres cirujanos experimentados. Estudio pequeño y de una sola especialidad: se cita como ilustración del sesgo de planificación, no como constante universal: doi:10.1016/j.joms.2012.10.009.
• J. F. Allen — Maintaining knowledge about temporal intervals, Communications of the ACM, 1983;26(11):832-843. Fuente de las trece relaciones posibles entre dos intervalos, que es el marco formal de por qué una bandera de libre u ocupado no puede responder una pregunta de agenda: doi:10.1145/182.358434.
• PostgreSQL — Range Types: Constraints on Ranges. Fuente del patrón canónico de restricción de exclusión sobre rangos temporales y del error de conflicto que devuelve el motor al intentar solapar dos reservas: postgresql.org.
• Google Workspace — Calendar API v3, Freebusy: query. Fuente de que la consulta de ocupación devuelve listas de intervalos ocupados con inicio inclusivo y fin exclusivo, en lugar de una bandera de disponibilidad: developers.google.com.
• Cal.com — API v2, Reserve a slot. Fuente de la retención temporal del cupo con vencimiento automático y del valor por defecto de cinco minutos: cal.com/docs.
• Google Developers — Actions Center Reservations, Lease specification. Fuente de que crear la retención es el primer paso de una reserva, de la verificación explícita de que el hueco sigue disponible y de la expiración automática: developers.google.com.
• Salesforce — Field Service Developer Guide, AppointmentBookingService. Fuente de que el método que devuelve los huecos disponibles no agenda la cita y de que agendar requiere una llamada distinta: developer.salesforce.com.
• S. Yao, N. Shinn, P. Razavi y K. Narasimhan — τ-bench: a benchmark for tool-agent-user interaction in real-world domains, arXiv:2406.12045 (2024), aceptado en ICLR 2025. Fuente de que los agentes de última generación resuelven menos del 50 % de las tareas, de la inconsistencia entre corridas (por debajo del 25 % en ocho intentos, en el dominio de retail) y del criterio de evaluar contra el estado final de la base de datos: arxiv.org/abs/2406.12045.
• Model Context Protocol — Specification 2025-06-18, Server Features: Tools. Fuente de la recomendación normativa de mantener siempre una persona en el ciclo con capacidad de denegar la invocación de una herramienta, pedir confirmación en operaciones sensibles y mostrar los datos de la llamada: modelcontextprotocol.io.
• N. Shah, L. Latifovic, C. Meaney, R. Moineddin, M. B. Derocher, M. Alhaj y T. Kiran — Association between clinic-reported third next available appointment and patient-reported access to primary care, JAMA Network Open, 2022. Fuente de la métrica del tercer siguiente turno disponible y de la advertencia de los propios autores de no usarla como métrica única: doi:10.1001/jamanetworkopen.2022.46397.
• D. Hosseini, B. Rostami y M. Araghi — Service time window design in last-mile delivery, arXiv:2508.01032 (2025). Fuente del planteamiento de la ventana horaria prometida como decisión de riesgo y del hallazgo de que el modelo optimizado para el caso promedio incumple fuera de muestra. Es un preprint, no un artículo revisado por pares: arxiv.org/abs/2508.01032.
• Retell AI Community — reporte del 14 de agosto de 2026 sobre un agente de voz que confirmó verbalmente una cita y llamó repetidamente a la función de consulta de disponibilidad en lugar de a la de reserva. Es un reporte de usuario fechado, no una investigación de incidente oficial ni una estadística; se cita como escena ilustrativa del modo de falla: community.retellai.com.
• Las capacidades y las brechas de SFUN descritas en este artículo se verificaron el 26 de agosto de 2026 contra el código de las aplicaciones de servicios funerarios, control de traslados, parque cementerio y el conector MCP. La reserva de sala con detección de conflicto y los estados de sala provienen del rework de velación y logística integrado el 26 de junio de 2026. Lo que aquí aparece como brecha —el recurso de cremación, la agenda de carroza y conductor, la retención temporal, la hora de fin de las exequias, el mantenimiento que no bloquea, el aforo de sala y la sede del traslado— se presenta explícitamente como hoja de ruta, no como función disponible.