Databricks muestra cómo crear agentes duraderos con Temporal y Lakebase, pero la demostración deja al descubierto la parte difícil

Databricks publicó el 8 de septiembre una implementación de referencia que muestra cómo crear agentes duraderos con Temporal y Lakebase pese a caídas de workers, reintentos y revisiones de varios días. El sistema aplica esta arquitectura a la evaluación de préstamos personales, donde perder una comprobación ya completada puede corromper el rastro de decisiones.

El cambio importante no es otro framework de agentes ni un modelo más grande. Databricks y Temporal han dividido el estado del agente entre dos sistemas con responsabilidades diferentes. Temporal conserva el flujo de control, mientras que Lakebase expone datos operativos que aplicaciones, revisores y analistas pueden consultar.

Esa división también crea la tensión central. La ejecución duradera puede recuperar trabajo registrado, pero no puede garantizar que todos los efectos externos ocurran exactamente una vez. La aplicación aún necesita identificadores estables, escrituras de base de datos protegidas, reglas de versión de políticas y reconciliación cuando los componentes discrepan.

Databricks convierte la durabilidad de los agentes en un sistema comprobable

La implementación de referencia trata a un agente como un proceso empresarial de larga duración, no como una sesión de chat temporal.

La implementación de referencia sigue una solicitud de préstamo desde la recopilación de evidencias hasta una decisión humana. Su agente realiza comprobaciones de crédito, ingresos, relación deuda-ingresos y política de suscripción como operaciones independientes.

El ejemplo utiliza solicitantes y proveedores simulados, por lo que no procesa solicitudes reales de préstamos. Esta decisión mantiene el experimento centrado en el comportamiento de ejecución, en lugar del rendimiento del modelo de crédito.

Un solicitante de ejemplo tiene una puntuación crediticia de 665 y una señal de morosidad no sustancial. El agente recopila las evidencias, evalúa los umbrales de política específicos para el propósito y genera una recomendación. No puede tomar la decisión final de préstamo.

Un suscriptor debe aprobar, denegar o solicitar más información. Esa última opción extiende el mismo caso a otro turno del agente, conservando las evidencias anteriores y la justificación del revisor.

El escenario es deliberadamente más difícil que una única solicitud a un modelo. Un worker puede detenerse después de que se completen varias comprobaciones. Una escritura en la base de datos puede confirmarse antes de que su finalización llegue a Temporal. Un revisor puede dejar el caso abierto durante días.

Un navegador desactualizado también puede enviar un comando obsoleto después de que el caso haya avanzado. Mientras tanto, la política de suscripción puede cambiar sin que se despliegue una actualización de la aplicación.

Estas situaciones generan seis requisitos prácticos: recuperación, reintentos controlados, esperas duraderas, visibilidad operativa, gobernanza en tiempo de ejecución e historial de auditoría. Una transcripción por sí sola no puede cumplirlos.

Una transcripción registra mensajes, pero no necesariamente el flujo de control completo. No muestra automáticamente qué operación se completó, qué resultado fue aceptado ni qué comando hizo avanzar el proceso.

Por ello, la implementación asigna a cada ejecución de préstamo un Temporal Workflow. Un Workflow es un flujo de control duradero cuyo historial registrado permite a otro worker reconstruir su estado.

Las llamadas a modelos, bases de datos y herramientas de suscripción se ejecutan como Activities. Una Activity es una operación reintentable cuyo resultado puede registrarse en el Event History del Workflow.

Las respuestas de los revisores llegan como Signals, que son comandos asíncronos enviados a un Workflow abierto. Temporal puede mantener esa espera sin reservar un proceso worker durante varios días.

React y FastAPI gestionan la aplicación orientada al usuario. Inician ejecuciones, muestran evidencias, listan casos y envían decisiones de revisión. Temporal Cloud almacena el historial de ejecución y distribuye tareas a los workers.

Lakebase Postgres alberga la proyección orientada a la aplicación. Una proyección es una representación consultable del estado actual del workflow, construida a partir de actualizaciones generadas durante la ejecución.

Unity Catalog sigue siendo la fuente de las reglas de suscripción. Una tabla sincronizada continuamente pone esas reglas a disposición mediante Lakebase, de modo que los workers puedan leer políticas actualizadas sin desplegar código.

Esta arquitectura hace visible y reproducible el comportamiento ante fallos de los agentes. Convierte la durabilidad, de una promesa general, en un conjunto de contratos específicos de recuperación y consistencia.

Sin embargo, la demostración no reúne esos contratos en una sola base de datos. Temporal y Lakebase siguen siendo sistemas independientes, y la brecha entre ellos plantea las cuestiones de ingeniería más difíciles.

La memoria del agente no es el estado de ejecución

Un agente duradero necesita decisiones registradas sobre el flujo de control, no solo mensajes almacenados o memorias recuperadas.

Muchos sistemas de agentes describen la persistencia como memoria. Guardan una conversación, recuperan documentos anteriores o colocan un resultado intermedio en una base de datos. Estas capacidades ayudan a los modelos a recuperar contexto, pero no reconstruyen la ejecución.

Supongamos que un worker termina una comprobación crediticia y luego se detiene. Un reemplazo debe determinar si el resultado se registró, si otro intento es seguro y qué operación debe ejecutarse después.

Ese es un problema de flujo de control. Incluye Activities programadas, resultados completados, temporizadores, comandos humanos aceptados, intentos de reintento y la ronda de revisión actual.

Temporal almacena esta información en un Event History ordenado. Durante la reproducción, el código del workflow consume esos eventos registrados y reconstruye variables como las evidencias, el uso de tokens y el estado de revisión.

Un resultado de Activity registrado se devuelve durante la reproducción en lugar de ejecutarse de nuevo. Por lo tanto, una comprobación crediticia completada o una respuesta de modelo registrada permanece fija para esa ejecución del workflow.

Una finalización no registrada plantea un caso diferente. Un proveedor de modelos podría terminar de procesar una solicitud justo antes de que el worker pierda conectividad. Si Temporal nunca recibe el resultado, puede programar otro intento.

Esta limitación importa porque las llamadas a modelos no están libres de efectos secundarios ni se garantiza que sean deterministas. Una segunda respuesta puede diferir de la primera, incluso con una entrada idéntica.

La demostración asigna políticas de reintento a tipos de operación individuales. Las Activities de modelos permiten hasta cuatro intentos dentro de una ventana de tres minutos de programación a cierre.

Las Activities de herramientas permiten hasta tres intentos con un tiempo de espera de inicio a cierre de 60 segundos. Las Activities de Lakebase permiten hasta cinco intentos con un tiempo de espera de inicio a cierre de 15 segundos.

Estas cifras describen la configuración de ejemplo, no valores predeterminados universales de producción. Los equipos deben establecer límites de reintento según el comportamiento del proveedor, los objetivos de latencia, los modos de fallo y las consecuencias posteriores.

El modelo de ejecución duradera de Temporal aborda la recuperación de procesos al conservar el historial necesario para la reproducción. No hace automáticamente que un pago, correo electrónico, mutación de base de datos o solicitud de modelo sea seguro de repetir.

Cada operación externa necesita un contrato de idempotencia. La idempotencia significa que los intentos repetidos convergen en un único resultado previsto, en lugar de producir efectos duplicados.

La demostración de préstamos construye este contrato con identificadores deterministas. Una ejecución, mensaje, llamada de herramienta, evento, ronda de revisión y decisión del revisor reciben cada uno una identidad estable.

Las claves primarias y restricciones de unicidad de Postgres evitan que los reintentos creen copias ilimitadas. Los upserts permiten que un intento repetido se dirija a la misma fila lógica.

Las actualizaciones protegidas añaden otra capa. Solo permiten transiciones de estado válidas, como mover una llamada de herramienta pendiente a completada sin reabrir un registro terminal.

Sin embargo, incluso una actualización protegida necesita una interpretación cuidadosa. PostgreSQL puede afectar cero filas sin generar un error cuando el objetivo ya alcanzó un estado terminal.

El artículo de Databricks reconoce que el wrapper actual de Activity no siempre convierte ese resultado de cero filas en un fallo. El código de producción debería inspeccionar el estado almacenado antes de tratarlo como inofensivo.

Este detalle separa una referencia de ingeniería útil de un patrón de producción terminado. La orquestación duradera proporciona el mecanismo de recuperación, mientras que los desarrolladores de aplicaciones todavía definen una semántica empresarial segura.

El mismo principio se aplica fuera de la suscripción. Los proveedores de pagos necesitan claves de idempotencia, los sistemas de correo electrónico necesitan identificadores de mensaje estables y las herramientas no compatibles necesitan registros de reconciliación.

Los equipos que crean un agente interno también necesitan una capa de evidencias consultable. Una base de conocimiento de ingeniería estructurada puede ayudar a las personas a inspeccionar la documentación, las decisiones y el contexto técnico en torno a esos workflows.

La lección más amplia es precisa: la memoria ayuda a un modelo a recordar, mientras que la ejecución duradera ayuda a un sistema a continuar. Los agentes de producción normalmente necesitan ambas, pero no son intercambiables.

Cree agentes duraderos con Temporal y Lakebase separando responsabilidades

El diseño funciona porque Temporal y Lakebase contienen distintos tipos de verdad para distintos consumidores.

Temporal posee la verdad de ejecución. Su historial determina qué tareas se completaron, qué temporizadores se activaron, qué Signals llegaron y qué debe hacer después un worker durante la reproducción.

Lakebase posee la vista actual de la aplicación. Almacena el estado de ejecución, mensajes, evidencias de herramientas, registros de revisión, eventos operativos, metadatos de recomendaciones y métricas de reintentos en tablas relacionales.

Esta división permite que la interfaz de usuario consulte casos actuales mediante patrones SQL convencionales. Los revisores pueden encontrar casos pendientes, inspeccionar una recomendación o comparar mediciones operativas entre ejecuciones.

Las evidencias aparecen antes de que se cierre un Workflow. Una vez finalizada la consulta de política, el resultado estructurado está disponible junto con los umbrales, valores reales, resultados de reglas, justificación y fuente de la política.

Esto importa en sistemas con revisión humana. Un revisor no debería esperar a que finalice todo el proceso antes de ver las evidencias detrás de una recomendación.

La aplicación utiliza dos esquemas de Lakebase. El esquema agent_ops contiene registros operativos, mientras que agent_policy incluye una copia de solo lectura de la política de suscripción gobernada.

Cada Activity escribe filas mediante identificadores alineados con el Workflow. Por lo tanto, un reintento puede actualizar el mismo registro lógico mientras la proyección de la base de datos se pone al día.

Lakebase no forma parte de la reproducción de Temporal. Ese límite evita que las consultas ordinarias de la aplicación decidan la ejecución del workflow, pero también significa que las actualizaciones no son atómicas entre ambos sistemas.

Un evento de Temporal puede registrarse mientras una proyección de Lakebase permanece temporalmente retrasada. Una escritura de base de datos también puede confirmarse antes de que Temporal registre la finalización de la Activity correspondiente.

La arquitectura acepta esta brecha y utiliza consistencia eventual. La consistencia eventual significa que vistas separadas pueden discrepar brevemente, pero convergen mediante reintentos y escrituras deterministas.

Es un diseño razonable para paneles y listas de casos. Exige más cautela cuando se utiliza una vista de base de datos para validar un comando que afecta al estado empresarial.

Lakebase aporta acceso Postgres conocido e indexación orientada a aplicaciones. Su modelo de base de datos operativa también admite memoria de agentes, estado actual y cargas de trabajo de servicio de características.

Su cómputo puede escalar automáticamente dentro de límites configurados. El escalado a cero puede suspender el cómputo inactivo, aunque la primera consulta tras un periodo de inactividad puede experimentar latencia de activación.

Estas características de base de datos ayudan con tráfico desigual de agentes. No eliminan la planificación de capacidad, los límites de conexiones, la configuración de pools ni las pruebas de recuperación.

La vía de las políticas es igualmente importante. Unity Catalog almacena umbrales específicos por propósito, incluidas reglas de crédito y relación deuda-ingresos. Una tabla sincronizada de forma continua presenta esos valores dentro de Lakebase.

Los responsables de las políticas pueden actualizar la fuente sin volver a desplegar el worker ni la API. Una consulta posterior puede leer las reglas propagadas desde Postgres.

Esto evita incorporar cada umbral de negocio en el código de la aplicación. También introduce una cuestión sobre el momento de aplicación de las políticas que la capa de orquestación debe resolver explícitamente.

¿Debe un caso abierto conservar las reglas aplicadas al iniciarse, o adoptar una política más reciente durante un turno posterior? Ambas opciones tienen consecuencias para la coherencia, la auditabilidad y el trato al cliente.

La demostración registra los umbrales aplicados y la fuente junto con la recomendación. Esa evidencia permite a los revisores reconstruir qué política fundamentó un resultado concreto.

Cuando Lakebase no está disponible, el ejemplo puede usar políticas de prueba y registrar esa vía de respaldo. El artículo señala correctamente que un flujo de trabajo regulado podría, en cambio, fallar de forma cerrada.

Esa decisión no puede delegarse en una biblioteca de reintentos. Los responsables de producto, los equipos de cumplimiento y los ingenieros deben definir si una política obsoleta o de respaldo es legal y operativamente aceptable.

La ruta de retorno propuesta utiliza Lakebase Change Data Feed. Una vez habilitada, puede capturar mutaciones de la base de datos y publicarlas en tablas de historial Delta gestionadas por Unity Catalog.

Databricks afirma que el feed agrupa los cambios aproximadamente cada 15 segundos. Ese intervalo es adecuado para auditorías y análisis retrospectivos, mientras que la aplicación lee el estado actual directamente desde Lakebase.

Sin embargo, el repositorio solo prepara sus esquemas para esa ruta. No contiene una ejecución de feed integral observada en el entorno objetivo.

Por tanto, crear agentes duraderos con Temporal y Lakebase requiere tres límites claros: la verdad de ejecución, la verdad operativa y el historial analítico gobernado.

El patrón adquiere valor cuando esos límites son explícitos. Se vuelve peligroso cuando los equipos suponen que la palabra “duradero” significa que todos los componentes siempre concuerdan.

La revisión humana revela la disyuntiva de coherencia

La espera del suscriptor muestra por qué la durabilidad debe incluir la identidad de los comandos, el rechazo de estado obsoleto y la validación independiente del Workflow.

Después de que el modelo produce una recomendación, el Workflow crea un identificador de revisión a partir de la ejecución y el turno actual. Registra la revisión pendiente en Lakebase y entra en AWAITING_REVIEW.

Temporal espera entonces una condición sin mantener ocupado a un worker. El Workflow abierto puede sobrevivir al reemplazo del proceso mientras la persona tarda en responder.

La API acepta aprobación, denegación o una solicitud de más información. Primero comprueba si Lakebase todavía muestra la revisión correspondiente como pendiente.

También compara el identificador de revisión enviado con la ronda de revisión actual. Una discrepancia genera un conflicto en lugar de reenviar una decisión claramente obsoleta.

Esta comprobación previa en la base de datos mejora la experiencia de usuario, pero no es autoritativa. La proyección de Lakebase puede retrasarse respecto de Temporal, especialmente mientras una Activity se reintenta.

Por ello, la API envía el comando como una Signal, y el Workflow lo valida de nuevo frente al estado de ejecución. Las decisiones duplicadas u obsoletas se ignoran dentro del flujo de control duradero.

Esa segunda comprobación es esencial. Una pestaña del navegador podría permanecer abierta mientras otro revisor hace avanzar el caso, o una solicitud anterior podría llegar después de que comience una nueva ronda de revisión.

Una respuesta HTTP 202 solo confirma que Temporal recibió la Signal. No significa que el Workflow haya aceptado la decisión de negocio.

El cliente debe actualizar la vista de Lakebase para observar el estado resultante. Esa distinción evita confundir el acuse de recibo del transporte con la aprobación del préstamo.

Cuando el Workflow acepta una decisión, una Activity idempotente de Lakebase la persiste. La aprobación o la denegación completan la ejecución.

Una solicitud de más información reanuda la ejecución. La justificación del revisor se convierte en un nuevo mensaje de usuario, el turno avanza y la siguiente recomendación recibe un nuevo identificador de revisión.

Este mecanismo da a cada ronda de revisión un límite estable. También hace visible la principal disyuntiva: el estado reactivo de la aplicación está separado del estado de ejecución autoritativo.

Los equipos deben diseñar teniendo en cuenta desacuerdos temporales. Las interfaces deben comunicar claramente los comandos pendientes, los conflictos, las proyecciones retrasadas y las acciones obsoletas rechazadas.

Los paneles operativos también deben distinguir la espera intencional de una falla. Un caso que espera a un suscriptor está en buen estado, mientras que una Activity atrapada en reintentos requiere intervención.

La demostración expone métricas en los niveles de Workflow, turno e intento de Activity. Los operadores pueden inspeccionar el historial de Temporal, consultar el estado de Lakebase y comprobar el entorno del worker por separado.

Esta separación ayuda a diagnosticar si una demora proviene de la revisión humana, la disponibilidad del modelo, la autenticación de la base de datos o una herramienta fallida.

También añade superficie operativa. Los equipos deben supervisar Temporal, Lakebase, los despliegues de workers, los grupos de conexiones, los trabajos de sincronización y los contratos que los unen.

La autenticación introduce otra preocupación de larga duración. El cliente de Lakebase utiliza OAuth de máquina a máquina y actualiza su grupo de conexiones antes de que expiren las credenciales temporales de la base de datos.

Sin rotación de credenciales, un worker puede fallar según un calendario predecible incluso si su Workflow sigue siendo recuperable. Un flujo de control duradero no hace utilizables las conexiones vencidas.

Por ello, los desarrolladores que comparan marcos de agentes duraderos deberían mirar más allá de la compatibilidad con puntos de control. Deben preguntarse cómo se identifican los comandos, cómo se desduplican los efectos secundarios y dónde reside el estado autoritativo.

También deberían probar deliberadamente las interacciones obsoletas. Abran dos sesiones de revisión, hagan avanzar una y, después, envíen la decisión más antigua.

Una implementación correcta debería rechazar o ignorar de forma segura ese comando. Debería conservar suficiente evidencia para explicar posteriormente el resultado.

El ejemplo del préstamo es útil porque conecta estos detalles con una decisión de consecuencias importantes. La aprobación humana no es una pausa decorativa entre llamadas al modelo.

Es una transición de estado con identidad, autorización, contexto de políticas y requisitos de auditoría. Eso la convierte en una prueba de durabilidad más exigente que un asistente conversacional que se reinicia tras un error.

La demostración no prueba que esté lista para producción

Databricks presenta una arquitectura creíble, pero su propia evidencia deja sin resolver el cumplimiento normativo de préstamos, la escala y la validación completa del ciclo de datos.

El repositorio informa de 21 pruebas superadas que cubren la secuenciación del flujo de trabajo, el comportamiento de revisión, la construcción de OAuth, la persistencia idempotente, los contratos de métricas, el inicio de la API y la configuración del worker.

Un ejercicio de recuperación ante fallos utiliza un proveedor determinista. Detiene la ejecución del worker y verifica que el progreso registrado sobrevive tras el regreso del proceso.

Estas pruebas respaldan la afirmación limitada sobre durabilidad. Muestran que el flujo de control y los contratos de persistencia del ejemplo se comportan según lo previsto ante fallos seleccionados.

No validan al agente como sistema de préstamos. Los registros de solicitantes y las respuestas de proveedores son datos de prueba, mientras que el proveedor predeterminado con guion evita una dependencia de un modelo activo.

El repositorio no demuestra la calidad del modelo de préstamos, el cumplimiento normativo, la seguridad de producción, la disponibilidad regional ni el rendimiento a escala. Databricks declara directamente estas limitaciones.

El ejercicio local de fallos también se ejecutó con Lakebase deshabilitado. Aísla la recuperación de Temporal, pero no verifica la recuperación a través de la ruta de datos integrada completa.

Del mismo modo, la ruta de Change Data Feed sigue siendo una tarea de habilitación y despliegue. El ejemplo prepara las tablas, pero no muestra la llegada observada del historial de extremo a extremo.

Change Data Feed estaba en vista previa pública cuando apareció el artículo. El estado de vista previa importa para equipos que requieren compromisos de soporte maduros o cobertura regional validada.

La base de datos y el Workflow no comparten una transacción. Los identificadores estables y los reintentos aportan convergencia, pero los equipos aún necesitan reconciliación ante divergencias prolongadas o inesperadas.

Un proceso de reconciliación de producción debería localizar Workflows sin proyecciones coincidentes. También debería detectar efectos de base de datos confirmados cuyos resultados de Activity nunca entraron en el historial de eventos.

La sincronización de políticas merece el mismo escrutinio. Una ejecución posterior puede consumir políticas actualizadas sin despliegue, pero una ejecución abierta necesita una regla documentada de versión de política.

El comportamiento de respaldo crea otro riesgo. La demostración puede sustituir políticas de prueba cuando Lakebase está deshabilitado o una fila de política no está disponible.

Ese comportamiento ayuda al desarrollo local, pero un respaldo silencioso sería inaceptable en muchos entornos regulados. El sistema registra el respaldo, aunque los responsables de las políticas deben decidir si la ejecución debe continuar.

El rendimiento sigue sin probarse en la evidencia publicada. Las cargas de trabajo de agentes pueden generar escrituras en ráfagas, historiales extensos, transcripciones voluminosas y colas de revisión desiguales.

La retención de historial de Temporal, el volumen de reintentos, la latencia del modelo, la concurrencia de workers, los límites de conexión de la base de datos y las actualizaciones de proyecciones afectan al comportamiento del sistema.

El escalado automático de Lakebase puede responder a la demanda, pero las nuevas conexiones y los datos precalentados siguen siendo importantes. El escalado a cero también puede intercambiar eficiencia en inactividad por latencia de reactivación.

Los requisitos de seguridad van más allá de TLS y las credenciales temporales. Una plataforma real de suscripción necesitaría autorización estricta, controles de datos sensibles, reglas de retención y límites de acceso de auditoría.

La recomendación del modelo también necesita gobernanza independiente. Registrar evidencia y políticas mejora la trazabilidad, pero no demuestra que la recomendación sea justa o precisa.

Una evaluación completa probaría el razonamiento sobre acciones adversas, la evidencia faltante, los datos contradictorios de proveedores, los cambios de políticas y los intentos de manipular las entradas de las herramientas.

También probaría incidentes operativos que atraviesen los límites entre componentes. Los ejemplos incluyen sincronización de políticas no disponible, proyecciones retrasadas, rotación parcial de credenciales y proveedores externos no disponibles.

Por tanto, la arquitectura debe interpretarse como orientada a producción, no certificada para producción. Esa distinción fortalece la referencia porque hace visible el trabajo pendiente.

Databricks ha mostrado cómo asignar responsabilidades entre la orquestación, el almacenamiento operativo y los datos gobernados. No ha eliminado la necesidad de validar cada contrato bajo carga real.

Tres señales mostrarán si este patrón se sostiene

La próxima evidencia debería probar la recuperación integrada, la coherencia de políticas y la adopción más allá de la demostración controlada de suscripción.

La primera señal es un despliegue integral observado de Change Data Feed. El sistema publicado prepara las tablas operativas, pero deja sin terminar la activación del feed y la verificación del destino.

Una validación satisfactoria debería rastrear una ejecución desde la evidencia de herramientas, pasando por la revisión humana, hasta el historial gestionado por Unity Catalog. También debería documentar el retraso, los duplicados, los cambios de esquema y la recuperación tras una interrupción.

Ese resultado reforzaría la afirmación de que la actividad operativa puede volver al historial analítico gobernado. La dependencia continuada de una ruta no verificada debilitaría la narrativa del ciclo de datos completo.

La segunda señal es un estudio público de carga y fallos que utilice Lakebase durante toda la prueba de recuperación. Debería incluir fallos de workers, reintentos de base de datos, rotación de credenciales y retraso de proyecciones.

Los resultados útiles informarían sobre el comportamiento de finalización, la distribución de reintentos, el rechazo de comandos obsoletos y el tiempo necesario para que el estado de la aplicación converja.

Esto probaría la arquitectura como sistema combinado en lugar de validar la recuperación de Temporal de forma aislada. También revelaría dónde aparecen límites de escalado o cuellos de botella operativos.

La tercera señal es la adopción en un flujo de trabajo real con revisión humana. Los préstamos son solo una demostración, pero requisitos similares aparecen en el procesamiento de reclamaciones, las compras, la respuesta de seguridad y las aprobaciones reguladas.

Un despliegue creíble debe explicar cómo versiona las políticas, reconcilia el estado, controla el comportamiento de respaldo y audita la intervención humana. Esas prácticas importan más que el proveedor de modelos concreto.

La evidencia de un despliegue así respaldaría el juicio central del artículo. Los agentes duraderos son aplicaciones distribuidas cuyos fallos deben modelarse explícitamente.

Un despliegue que reduzca la durabilidad a puntos de control de la conversación apuntaría en la dirección opuesta. Dejaría los efectos secundarios, las esperas prolongadas y las políticas cambiantes fuera del contrato de recuperación.

Para los desarrolladores, la pregunta inmediata no es si todos los agentes necesitan Temporal y Lakebase. Muchas tareas breves y de solo lectura no justifican dos sistemas gestionados y una capa de proyección.

La pregunta es si un agente puede sobrevivir a su worker, modificar el estado externo, esperar a personas o aplicar políticas que cambian de forma independiente. Esas características crean la necesidad de una ejecución duradera.

Si describen su sistema, revisen la arquitectura del agente, reproduzcan sus pruebas de fallos y cuestionen cada efecto secundario susceptible de reintentos. Después, prueben qué ocurre cuando la verdad de ejecución y la verdad operativa discrepan temporalmente.

Ese es el estándar práctico para los equipos que intentan construir agentes duraderos con Temporal y Lakebase. Empiecen con un flujo de trabajo relevante, definan la autoridad de cada sistema y conviertan la evidencia de recuperación en parte de la revisión del producto.